Hallo,
ich habe einige Dummies mit Readings, in denen sich Konfigurationswerte befinden.
Internals:
CFGFN ./FHEM/99_myMQTT.cfg
FUUID 5de3d9a0-f33f-c599-e6e6-6f5a348abb2591eb
NAME So4ch2_set
NR 2818
STATE ::ReadingValDoIf(HASH(0x57f0190),'So4ch2','state')
TYPE dummy
Helper:
DBLOG:
state:
fhemDbLog:
TIME 1642379102.57523
VALUE ::ReadingValDoIf(HASH(0x57f0190),'So4ch2','state')
READINGS:
2022-01-12 17:18:57 Text ausschalten
2021-12-12 20:53:25 hide OFF
2022-01-06 06:31:13 mode HAND
2022-01-06 06:31:13 presence NONE
2022-01-02 14:17:20 sec_on 300
2022-01-02 14:17:20 sec_on_time 00:05:00
2022-01-17 01:25:02 state ::ReadingValDoIf(HASH(0x57f0190),'So4ch2','state')
2021-12-31 14:08:04 temp_max_off 10.0
2021-12-31 14:08:04 temp_max_on 15.0
2021-12-31 14:08:04 temp_min_off 3.0
2021-12-31 14:08:04 temp_min_on 1.0
2022-01-03 19:18:17 time_off 07:38:05
2022-01-03 19:18:13 time_on 16:42:27
Attributes:
event-on-change-reading .*
readingList Text hide mode mode_x presence sec_on sec_on_time state temp_max_off temp_max_on temp_min_off temp_min_on time_off time_on
room SW-SET
Der STATE wird dort nicht benutzt. Zugleich habe ich einige DOIF-Templates, die u.a. auch diese Dummies abfragen.
Seit einiger Zeit bekomme ich als STATE die folgenden Werte
::ReadingValDoIf(HASH(0x57f0190),'So4ch2','state') in So4ch2_set:state
oder
::ReadingValDoIf(HASH(0x57f0190),'swS20_2','state') in swS20_2_set:state
Alles läuft rund, keine Fehler im Log-File, alles okay, aber wo können denn diese Werte herkommen und warum werden sie wann gebildet?
stacktrace steht schon auf 1, aber nichts wird angezeigt.
Wenn niemand das auf den ersten Blick weiß, dann scheint das so bleiben zu können, denn es läuft alles rund. Ist nur nicht so schön und scheint einen Hinweis zu zeigen, dass doch etwas nicht so richtig ist.
Vielen Dank.
Womoeglich kann man aus dem Zeitstempel von state, und gleichzeitig anderswo gesetzten Readings die Quelle ableiten.
Dabei koennte auch ein "attr global verbose 5" Log helfen.
Vermutlich ist das Thema im DOIF Abschnitt des Forums besser aufgehoben, evtl. hat der DOIF Maintainer eine Idee, was die Ursache ist.
Nachtrag: eine andere Moeglichkeit ist in stateFormat ein stacktrace auszuloesen:
attr So4ch2_set stateFormat { stacktrace() }
::ReadingValDoIf(HASH(0x57f0190),'So4ch2','state')
ist im DOIF die interne Abfrage eine Readings, es entspricht der Angabe [So4ch2:state]
DOIF schreibt nicht eigenständig etwas in fremde Module, ich gehe davon aus, dass in einer DOIF-Definition mit dem hash 0x57f0190 der Status statt mit einem bestimmten Wert mit dem übersetzten Perlausdruck beschrieben wird.
Vielen Dank für die detaillierten Antworten.
Zitatattr So4ch2_set stateFormat { stacktrace() }
und attr So4ch2_set verbose 5
hat schon mal etwas geholfen, weil es doch einen tiefen Einblick in das Laufzeitverhalten gibt, auch das devicespezifische verbose 5.
Aber bei attr global verbose 5 wird man von den Daten erschlagen.
Ich habe die Ursache dieser falschen states (noch) nicht gefunden, aber es scheint wohl einen Unterschied zu sein, ob bei den DOIFs auf state oder beliebiges Reading getriggert oder zugewiesen wird. Das habe ich noch nicht so richtig gerafft.
Es scheint einen Unterschied zu machen, ob
[So4ch1:connected] eq "Online") (set So4ch1_set [So4ch1:state]) DOELSE (set So4ch1_set Offline) oder
[So4ch1:connected] eq "Online") (set So4ch1_set [So4ch1]) DOELSE (set So4ch1_set Offline) geschrieben wird, um den Status des einen Device auf das andere zu übertragen.
Vielleicht habe ich hier an irgendeiner Stelle noch einen Fehler. Muss ich suchen, aber ich vermute mal, dass so etwas die Ursache sein wird.
Also im DOIF-FHEM-Modus
ist das:
(set So4ch1_set [So4ch1:state])
ok.
im DOIF-Perl-Modus:
würde das:
fhem("set So4ch1_set [So4ch1:state]")
das geschilderte Problem darstellen.
Es muss dann so aussehen:
fhem("set So4ch1_set ".[So4ch1:state])
Weil ja [So4ch1:state] intern in ::ReadingValDoIf(HASH(0x57f0190),'So4ch1','state') übersetzt wird.
Im FHEM-Modus wird es mit eval noch ausgewertet, bevor es ersetzt wird, daher ist es dort kein Problem.
Vielen Dank, jetzt ist es etwas klarer, obwohl ich mich so manchmal noch unsicher fühle.
Der Fehler lag an
define _di_TPL_sw_Hand DOIF DEF TPL_SW_HAND (
{ if ([$2:state]) { fhem_set"$1 [$2:state]" }})
TPL_SW_HAND(So4ch1_set,So4ch1)
...
Mit der Änderung zu
DEF TPL_SW_HAND ( {
if ([$2:state]) {
fhem("set $1 ".[$2:state]);
}
})
TPL_SW_HAND(So4ch1_set,So4ch1)
...
scheint es jetzt geklärt.
Vielen Dank nochmals, auch für DOIF insgesamt und auch dem DOIF-Template, was alles etwas vereinfacht, obwohl die Beachtung der verschiedenen Ebenen, Klammern usw. schon tiefere Kenntnisse verlangen, aber dafür gibt es auch das ausgezeichnete Forum und die gute Dokumentation.
Zitat von: manne44 am 18 Januar 2022, 00:47:13
Vielen Dank, jetzt ist es etwas klarer, obwohl ich mich so manchmal noch unsicher fühle.
Der Fehler lag an
define _di_TPL_sw_Hand DOIF DEF TPL_SW_HAND (
{ if ([$2:state]) { fhem_set"$1 [$2:state]" }})
TPL_SW_HAND(So4ch1_set,So4ch1)
...
Mit der Änderung zu
DEF TPL_SW_HAND ( {
if ([$2:state]) {
fhem("set $1 ".[$2:state]);
}
})
TPL_SW_HAND(So4ch1_set,So4ch1)
...
scheint es jetzt geklärt.
Vielen Dank nochmals, auch für DOIF insgesamt und auch dem DOIF-Template, was alles etwas vereinfacht, obwohl die Beachtung der verschiedenen Ebenen, Klammern usw. schon tiefere Kenntnisse verlangen, aber dafür gibt es auch das ausgezeichnete Forum und die gute Dokumentation.
ja, ein gewisser Klammercheck erfolgt bei der Definition, eine richtige Ausführung per Perl-eval geschieht erst beim Schalten. Wenn man sich die Blöcke benennt, dann kann man sie besser erkennen und auch einzeln per set-Kommando testen. Ich denke, ich werde noch eine Perl-set Funktion einbauen, dann kann man mit der Syntax
set(<devices>,<value>)es einfacher handhaben, hier dann:
set ($1,[$2:state])und muss sich nicht um die perlspezifische Syntax kümmern.