Seite 1 von 1

HmIP-PS / PS-2 - fehlerhafter Status in Programmen

Verfasst: 27.03.2024, 00:06
von Roland M.
Hallo!

Habe Problem! :mrgreen:

Hintergrund:
Mein Bruder und ich möchten die Amateurfunkstation in unserem Wochenendhaus so umgestalten, dass sie auch remote bedienbar wird. Dazu wird auch ein wesentlicher Teil per HM geschaltet, konkret mit einem HmIP-PS. Um in einer Visualisierung dem jeweilig anderen anzeigen zu können, ob die Station gerade lokal oder remote benutzt wird, werden die virtuellen Kanäle und eine Systemvariable genutzt, die den Status des Aktors abbildet. Hier ist mir aufgefallen, dass auch bei lokaler Bedienung "remote" angezeigt wird. Da das Projekt erst im Entstehen ist und ich z.B. einem Raspi mit einem kalten Abschalten nicht den Boden unter den Füßen wegziehen möchte, habe ich das nun zu Hause auf der Test-CCU mit einem HmIP-PS-2 nachgebildet.


Vorbemerkung:

Jeweils aktuelle Raspberrymatic-Version (3.75.6.20240316) und aktuelle Firmware der Aktoren (PS & PS-2: 2.24.2).

Der Status des Aktors, genauer gesagt der ersten beiden virtuellen Kanäle soll auf eine Systemvariable abgebildet werden.
Dabei ist sowohl der dritte virtuelle Kanal (immer aus, ODER-verknüpft), als auch die Priorität der ersten beiden Kanäle zu vernachlässigen.
Die Systemvariable ist eine Werteliste mit den Werten "undefiniert;aus;ein lokal;ein remote" und wird protokolliert.
Alle Varianten wurden durch Löschen des vorigen Programms und neu Anlegen (ohne Editieren) des nächsten Programms durchgeführt.


Erster Test:
Status Steckdose v1.png
Über die WebUI wird zwei Mal abwechselnd der erste VK (lokal) ein- und ausgeschaltet, dann der zweite VK (remote), einige Sekunden Pause zwischen den Schaltbefehlen.

Das zugehörige Protokoll:
protokoll v1 .png
Hier fällt auf, dass trotz Auslösen auf Änderung "lokal ein" zwei Mal hintereinander protokolliert wird.


Da ich schon einmal einen merkwürdigen Fehler durch Umkehren der Logik nachweisen/beheben konnte, das zweite Programm


Zweiter Test:

Einfach nur die Abfrage lokal/remote umgekehrt.
Status Steckdose v2.png
protokoll v2.png
protokoll v2.png (16.58 KiB) 448 mal betrachtet
Im Protokoll fällt auf, dass nun der "remote"-Eintrag doppelt geführt wird (erste Bedingung im Programm!)


Dritter Test:

Programm komplett umgestellt und auch den Statuskanal genutzt.
Ganz besonders sei hier nochmals hingewiesen, dass auf den 3. VK keine Rücksicht genommen wird!
Status Steckdose v3.png
protokoll v3.png
Tja - Bingo! - "ein lokal - ein remote" in kurzer Abfolge, obwohl der 2. VK definitiv nicht eingeschaltet ist! Die SV stellt natürlich den Status falsch dar!
Und auch hier wird wieder die erste Abfrage im Programm, das "aus" doppelt protokolliert!


Ergänzung:

Dieses dritte Programm ist aktuell auch am produktivem System in Betrieb. Auffällig hier ist das Systemprotokoll:
protokoll original.png
Trotz "Auslösen auf Änderung" wird der Status "aus" etwa jede Stunde ins Protokoll geschrieben, obwohl sich der Status nicht geändert hat.


Fragen:

Warum wird - auffällig! - die erste Bedingung im Programm doppelt protokolliert?
Warum wird der Status "ein remote" angezeigt, obwohl der virtuelle Kanal definitiv aus ist?
Warum wird "aus" etwa jede Stunde (zyklische Statusmeldung!) protokolliert, obwohl sich am Status nicht geändert hat?
And last but not least: Wie lässt sich das ganze beheben?! ;)


Roland

Re: HmIP-PS / PS-2 - fehlerhafter Status in Programmen

Verfasst: 27.03.2024, 00:31
von MichaelN
Das bedingungslose SONST kann dazu führen das sich das Programm wie "bei Aktualisierung" verhält.

Mach da mal lieber ein logisch passendes SONST WENN raus.

Re: HmIP-PS / PS-2 - fehlerhafter Status in Programmen

Verfasst: 27.03.2024, 08:56
von Xel66
In dem Falle nicht nur "kann", sondern führt definitiv dazu. Damit das SONST funktionieren kann, muss ja der Statuswechsel des Aktorkanals in beiden Zuständen ausgewertet (an die CCU übermittelt) und die Bedingungsprüfung durchlaufen werden. Und die Programme arbeiten nun mal "von oben nach unten" ab, egal wo der Trigger im Programm sitzt (doppelte Protokollierung der Systemvariable und das erste Match wird ausgeführt). Das stündliche Log kommt von der zyklischen Statusübermittlung. Diese stößt wieder eine Bedingungsprüfung an, dessen Ergebnis eben ausgeführt/protokolliert wird.

Dass auch bei der Verwendung anderer Kanäle Bedingungsprüfungen getriggert werden, die eigentlich auf andere Kanäle lauschen, ist auch plausibel, weil bei der Statusübermittlung alle Kanäle gesendet werden. Ich habe gerade mal den Kanal 4 meines Steckdosenaktors per WebUI geschaltet und das Systemlog beinhaltet u.a. den Status aller Kanäle zzgl. zusätzlicher Infos.

Code: Alles auswählen

Mar 27 08:40:36 homematic-raspi local0.info ReGaHss: Info: Event="XXXXXXXXXX08E:0"."CONFIG_PENDING"=false [execute():iseXmlRpc.cpp:321]
Mar 27 08:40:36 homematic-raspi local0.info ReGaHss: Info: Event="XXXXXXXXXX08E:0"."RSSI_DEVICE"=-61 [execute():iseXmlRpc.cpp:321]
Mar 27 08:40:36 homematic-raspi local0.info ReGaHss: Info: Event="XXXXXXXXXX08E:0"."DUTY_CYCLE"=false [execute():iseXmlRpc.cpp:321]
Mar 27 08:40:36 homematic-raspi local0.info ReGaHss: Info: Event="XXXXXXXXXX08E:0"."UNREACH"=false [execute():iseXmlRpc.cpp:321]
Mar 27 08:40:36 homematic-raspi local0.info ReGaHss: Info: Event="XXXXXXXXXX08E:2"."SECTION_STATUS"=0 [execute():iseXmlRpc.cpp:321]
Mar 27 08:40:36 homematic-raspi local0.info ReGaHss: Info: Event="XXXXXXXXXX08E:2"."STATE"=true [execute():iseXmlRpc.cpp:321]
Mar 27 08:40:36 homematic-raspi local0.info ReGaHss: Info: Event="XXXXXXXXXX08E:2"."SECTION"=2 [execute():iseXmlRpc.cpp:321]
Mar 27 08:40:36 homematic-raspi local0.info ReGaHss: Info: Event="XXXXXXXXXX08E:2"."PROCESS"=0 [execute():iseXmlRpc.cpp:321]

Mar 27 08:40:36 homematic-raspi local0.info ReGaHss: Info: Event="XXXXXXXXXX08E:3"."SECTION_STATUS"=0 [execute():iseXmlRpc.cpp:321]
Mar 27 08:40:36 homematic-raspi local0.info ReGaHss: Info: Event="XXXXXXXXXX08E:3"."STATE"=false [execute():iseXmlRpc.cpp:321]
Mar 27 08:40:36 homematic-raspi local0.info ReGaHss: Info: Event="XXXXXXXXXX08E:3"."SECTION"=0 [execute():iseXmlRpc.cpp:321]
Mar 27 08:40:36 homematic-raspi local0.info ReGaHss: Info: Event="XXXXXXXXXX08E:3"."PROCESS"=0 [execute():iseXmlRpc.cpp:321]
Mar 27 08:40:36 homematic-raspi local0.info ReGaHss: Info: Event="XXXXXXXXXX08E:4"."SECTION_STATUS"=0 [execute():iseXmlRpc.cpp:321]
Mar 27 08:40:36 homematic-raspi local0.info ReGaHss: Info: Event="XXXXXXXXXX08E:4"."STATE"=true [execute():iseXmlRpc.cpp:321]
Mar 27 08:40:36 homematic-raspi local0.info ReGaHss: Info: Event="XXXXXXXXXX08E:4"."SECTION"=2 [execute():iseXmlRpc.cpp:321]
Mar 27 08:40:36 homematic-raspi local0.info ReGaHss: Info: Event="XXXXXXXXXX08E:4"."PROCESS"=0 [execute():iseXmlRpc.cpp:321]
Mar 27 08:40:36 homematic-raspi local0.info ReGaHss: Info: Event="XXXXXXXXXX08E:5"."SECTION_STATUS"=0 [execute():iseXmlRpc.cpp:321]
Mar 27 08:40:36 homematic-raspi local0.info ReGaHss: Info: Event="XXXXXXXXXX08E:5"."STATE"=false [execute():iseXmlRpc.cpp:321]
Mar 27 08:40:36 homematic-raspi local0.info ReGaHss: Info: Event="XXXXXXXXXX08E:5"."SECTION"=0 [execute():iseXmlRpc.cpp:321]
Mar 27 08:40:36 homematic-raspi local0.info ReGaHss: Info: Event="XXXXXXXXXX08E:5"."PROCESS"=0 [execute():iseXmlRpc.cpp:321]
Gruß Xel66