Absturz durch Fehler in 10_CUL_HM.pm ?

[Otto123]

oder einfach die alte Version vor dem Update wieder herstellen. Das geht mit dem Befehl restore, hier eine kurze Beschreibung:

Per default werden vor dem Überschreiben durch update alle Dateien in einem neuen Verzeichnis (restoreDir/update/YYYY-MM-DD) gesichert. Diese Dateien kann man einzeln oder komplett mit dem Befehl restore zurücksichern (z.Bsp.: restore update/2014-08-19 oder restore update/2014-08-19/fhem.pl) .

https://wiki.fhem.de/wiki/Update#R.C3.BCcksichern_beim_Update_.C3.BCberschriebener_Dateien

Mit dem Befehl restore list kannst Du Dir anschauen was Du hast.

[Pfriemler]

Weckt Ihr mich bitte, wenn wir mal wieder einen halbwegs verlässlichen Funktionsstand bei CUL_HM haben? Ich traue mich seit Monaten kein Update mehr zu machen.
Bin deswegen auch in hm.js und Co temporär abgemeldet. Ich habe leider nicht den Luxus eines Testsystems...

Also was ich suche, ist eine funktionsfähige long-term-Lösung ohne Fehlerrisiko. Welcher Stand war das zuletzt? Kann ich mir ja im SVN ziehen...

[martinp876]

fix eingecheckt

[martinp876]

virtTemp möchte ich nicht auf 2 Nachkommastelle erweitern, da es a) unnötig ist und b) die OptionList endlos macht.

Man kann es bei Bedarf selbst ändern (wie alles in FHEM).
1) Kommando ändern:

Code Auswählen Erweitern

{$HMConfig::culHmFunctSets{virtThSens}{virtTemp}="(off|-20.0..50.0;;0.01)"}

2) re-setup commands for device

Code Auswählen Erweitern

{$defs{NAME}{helper}{cmds}{cmdKey}=""}

wobei "NAME" durch den Namen des/der Devices zu ersetzen ist. Also einmal für jede entity ausführen.

Kann man natürlich im UserConfig ausführen, was sonnvoller Weise nach dem System-Init stattfiden sollte.

[betateilchen]

fix eingecheckt

getestet, scheint zu funktionieren.

Danke.

[noansi]

Hallo Martin,

hier noch eine grep Alternative, da Du vermutlich aus Perfomance Erwägungen den $foo match minimiert hast, was aber noch Crashpotential offen lässt (beispielsweise einzelne '(', ')' oder '[':

Code Auswählen Erweitern

          my ($tmp1) = map{my $foo=$_;$foo =~ s/([\?*+[()\\])/\\$1/g;$foo}($parIn[$pCnt]); # we need to consider special chars not to crash
          if( $parIn[$pCnt] !~ m/[:\{\[\(]/ && grep/^\{?$tmp1\}?$/,@parLst){ # parameter not comparable or matched
          }

und

Code Auswählen Erweitern

    return "$regName failed: supported register are ".join(" ",sort @regArr)
            if (!grep $_ eq $regName,@regArr );


Das macht es sicherer auch für Typos bei der Eingabe.

Gruß, Ansgar.

[Beta-User]

virtTemp möchte ich nicht auf 2 Nachkommastelle erweitern, da es a) unnötig ist und b) die OptionList endlos macht.

Na ja, es ging nicht um's Erweitern, es hatte ja funktioniert...

Aber egal, ich habe den Eventhandler jetzt angepaßt, ist einfacher als alles andere

[noansi]

Hallo Jörg,

2020.11.02 08:04:56 3: CUL_HM reject-set Fake_Fenster_SZ_Temp virtHum: param 0:'(off|0.0..99.0;0.1)' =>  not numeric
virtHum: (off|0.0..99.0;0.1)

was wird denn als virtHum gesetzt? Das steht ja nicht in Deinem Log. Ggf. mal das Logging ab Zeile 4637++ modifizieren/erweitern.

Gruß, Ansgar.

Edit: Sorry, ich war beim falschen Beta...

[Beta-User]

Bin zwar nicht Udo, aber das war mir gar nicht aufgefallen, dass das notify scheinbar dazu geführt hatte, dass auch noch ein virtueller Hum-Wert erzeugt wurde - sowas gab es im Log vorher und nachher nicht wieder, nur in der kurzen Zeit nach dem update und vor der Rückkehr zur Vorversion...

Das notify reagiert auch nur auf "temperature"-Events, von daher... k.A., was das war.

Letztlich ist es mir auch egal, ob ich jetzt vorher runden muss oder nicht, das Thema ist eher, dass "jemand" dann noch entsprechende Hinweise ins Wiki einbauen sollte...

[noansi]

Hallo Jörg,

Zeile 4601 10_CUL_HM.pm:

Code Auswählen Erweitern

            if ($parIn[$pCnt] !~ m/^[-+]?[0-9]+\.?[0-9]*$/){
              $paraFail = "$parIn[$pCnt] not numeric";
            }

matched auf beliebig viele Nachkommastellen! Das sollte Deinem Wunsch entsprechen.

Martin schrieb von der Anzahl Nachkommastellen bei der Auswahlliste (im Browser sichtbar) für set virtTemp. Und die auf 2 oder mehr aufzublasen kostet viel Speicher.

@Martin: Wie auch immer, hilfreich wäre, den Log Eintrag 4637++ um den "fehlerhaften" Parameterwert zu ergänzen.

Gruß, Ansgar.

[Beta-User]

Moin, irgendwie bin ich grade ständig auf dem Holzweg ...

Der setter in FHEMWEB ist in der Tat uninteressant, und lt. Log wurde ja auch die virtTemp korrekt weitergegeben. Zum Hintergrund: das notify reagiert auf einen Mix aus HUEDevice und MQTT2_DEVICE und sah ursprünglich so aus:

Code Auswählen Erweitern

define n_Virtual_Temp_notify notify Temperatur_Schlafzimmer:temperature:.*|Raumfuehler_.*:temperature:.* set myRealTempSensor=$NAME virtTemp $EVTPART1

configdb search %virtHum% liefert keinen Treffer, allerdings ergab dann ein Blick ins Log vom Vormonat, dass da durchaus bereits schon schon entsprechende Einträge drin waren - aber (bezogen auf eines der Devices) nur in ca. 35 v. 1900 Fällen, und darunter sind auch Einträge, bei denen die Temp. einstellig war... (Und immer zusammen mit der betreffenden virtTemp-Anweisung, wobei das nur die MQTT2_DEVICE-Instanzen betrifft, da nur bei denen auch der Humidity-Wert mit im readingsBulkUpdate drin ist - die kommen von BT-Xiaomis über ein OpenMQTTGateway).
Schräger Zufall, dass das ausgerechnet "gepaßt hat", während  ich gestern die paar Minuten im Log angesehen habe...

Für den Moment gehen mir die Ideen aus, und tendenziell ist es auch kein Thema für diesen Thread. Der ist [gelöst], oder?

[RobRoy]

Hallo zusammen,

ich bin neu hier im Forum, habe ein ähnliches Problem.
Ich denke das hängt zusammen, wollte euch aber die Info zukommen lassen, evtl. hilft das.

Bei mir stürzt FHEM ab, wenn ich für einen Homematic Dimmer einen Wert setze:
set Licht_Esstisch 50
set Licht_Esstisch 50 0 0
set Licht_Esstisch pct 50

Logfile:
2020.11.03 07:42:04 2: AttrTemplates: got 194 entries
Reference to nonexistent group in regex; marked by <-- HERE in m/\5 <-- HERE \0/ at /opt/fhem//FHEM/10_CUL_HM.pm line 4597.

Viele Grüße
Rob

[Beta-User]

Hab's eben mit der heutigen CUL_HM kurz angetestet: Das mit den pct klappt bei einem PBU-Dimmer ohne Absturz, ABER ohne Rückmeldung über die ausgeführte Schaltaktion, FHEM meint, das Ding wäre nicht erreichbar (Hauptkanal steht auf "MISSING ACK"). Kann grade nicht sagen, ob das ein spezielles Thema bei diesem Aktor ist, die beiden Rollladenaktoren direkt darunter funktionieren jedenfalls problemlos.


Zu dem anderen Thema noch: Kann es sein, dass das mit dem restart zusammenhängt und dann einfach die Daten aus der statefile missinterpretiert wurden? Das taucht nämlich bei näherer Betrachtung "im Pulk" auf - und nicht beschränkt auf "ungültige" Werte, wobei als "Anlass" nur ein Element gelistet ist. Hier mal ein auszugsweises log von einem Startvorgang im Oktober (den hatte ich halt grade zur Hand):

Code Auswählen Erweitern


2020.10.03 08:46:49 3: Device Tuer_unten added to ActionDetector with 028:00 time
2020.10.03 08:46:49 3: CUL_HM set Fake_Fenster_Kind3_Temp virtTemp 22.6
2020.10.03 08:46:49 3: CUL_HM reject-set Fake_Fenster_Kind3_Temp virtHum: param 0:'(off|0.0..99.0;0.1)' =>  not numeric
virtHum: (off|0.0..99.0;0.1)
2020.10.03 08:46:49 3: CUL_HM reject-set Fake_Fenster_SZ_Temp virtTemp: param 0:'(off|-20.0..50.0;0.1)' =>  not numeric
virtTemp: (off|-20.0..50.0;0.1)
2020.10.03 08:46:49 3: CUL_HM reject-set Fake_Fenster_SZ_Temp virtHum: param 0:'(off|0.0..99.0;0.1)' =>  not numeric
virtHum: (off|0.0..99.0;0.1)
2020.10.03 08:46:49 3: CUL_HM reject-set Fake_Tuere_WZ_Temp virtTemp: param 0:'(off|-20.0..50.0;0.1)' =>  not numeric
virtTemp: (off|-20.0..50.0;0.1)
2020.10.03 08:46:49 3: CUL_HM reject-set Fake_Tuere_WZ_Temp virtHum: param 0:'(off|0.0..99.0;0.1)' =>  not numeric
virtHum: (off|0.0..99.0;0.1)
2020.10.03 08:46:55 3: FB_CALLMONITOR (Callmonitor) - found 1 phonebooks

[RobRoy]

Ja, Rolladenaktor (HM-LC-BL1PBU-FM) läuft bei mir auch ohne Probleme.

Mein Dimmer ist: HM-LC-DIM1TPBU-FM
Da stürzt FHEM ab.

[DIK]

Bei mir läuft es wieder nach dem update 

DANKE!

Und auch danke für den Tipp mit dem restore (trotz bald 10 Jahren fhem war mir das neu - DAU halt), das hat mein System bis zum update wieder zum laufen gebracht.
Aber eigentlich ja ein gutes Zeichen, dass ich das restore in fast 10 Jahren noch nicht gebraucht hatte.

Jedenfalls vielen Dank an alle Profis, die mir so schnell und erfolgreich geholfen haben!
Gruß
Ingo