[Gelöst] Unklarer State

Begonnen von manne44, 17 Januar 2022, 01:32:43

Vorheriges Thema - Nächstes Thema

manne44

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.
RPI4-Buster mit SSD, RPI-Zero mit Bookworm

rudolfkoenig

#1
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() }

Damian

::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.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

manne44

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.
RPI4-Buster mit SSD, RPI-Zero mit Bookworm

Damian

#4
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.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

manne44

#5
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.
RPI4-Buster mit SSD, RPI-Zero mit Bookworm

Damian

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.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF