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

Einrichtung, Nutzung und Hilfe zu RaspberryMatic (OCCU auf Raspberry Pi)

Moderatoren: jmaus, Co-Administratoren

Antworten
Benutzeravatar
Roland M.
Beiträge: 9807
Registriert: 08.12.2012, 15:53
System: CCU
Wohnort: Graz, Österreich
Hat sich bedankt: 252 Mal
Danksagung erhalten: 1381 Mal

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

Beitrag von Roland M. » 27.03.2024, 00:06

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) 255 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
Zur leichteren Hilfestellung bitte unbedingt beachten:
  • Bezeichnung (HM-... bzw. HmIP-...) der betroffenen Geräte angeben (nicht Artikelnummer)
  • Kurzbeschreibung des Soll-Zustandes (Was soll erreicht werden?)
  • Kurzbeschreibung des Ist-Zustandes (Was funktioniert nicht?)
  • Fehlermeldungen genau abschreiben, besser noch...
  • Screenshots von Programmen, Geräteeinstellungen und Fehlermeldungen (direkt als jpg/png) einstellen!

-----------------------------------------------------------------------
1. CCU2 mit ~100 Geräten (in Umstellung auf RaspberryMatic-OVA auf Proxmox-Server)
2. CCU2 per VPN mit ~50 Geräten (geplant: RaspberryMatic auf Charly)
3. CCU2 per VPN mit ~40 Geräten (geplant: RaspberryMatic auf CCU3)
CCU1, Test-CCU2, Raspi 1 mit kleinem Funkmodul, RaspberryMatic als VM unter Proxmox, Access Point,...

MichaelN
Beiträge: 9685
Registriert: 27.04.2020, 10:34
System: CCU
Hat sich bedankt: 700 Mal
Danksagung erhalten: 1627 Mal

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

Beitrag von MichaelN » 27.03.2024, 00:31

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.
LG, Michael.

Wenn du eine App zur Bedienung brauchst, dann hast du kein Smarthome.

Wettervorhersage über AccuWeather oder OpenWeatherMap+++ Rollladensteuerung 2.0 +++ JSON-API-Ausgaben auswerten +++ undokumentierte Skript-Befehle und Debugging-Tipps +++

Xel66
Beiträge: 14170
Registriert: 08.05.2013, 23:33
System: Alternative CCU (auf Basis OCCU)
Wohnort: Nordwürttemberg
Hat sich bedankt: 587 Mal
Danksagung erhalten: 1501 Mal

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

Beitrag von Xel66 » 27.03.2024, 08:56

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
-------------------------------------------------------------------------------------------
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch

Antworten

Zurück zu „RaspberryMatic“