Homematic: wie überprüfen, ob Befehl ausgeführt?

gestein · 27 Juli 2020, 18:45:14

Hallo,

Ich habe eine VCCU (mit einem HM-UART und einem HM-USB).

Wie kann man in fhem sichergehen, dass der Befehl ausgeführt wurde und nicht irgendwie ,,hängen" geblieben ist?
Gibt es da einen anderen Weg als auf das ,,Missing Ack." im jeweiligen Device zu warten?

Danke im Voraus
Lg, Gerhard

MadMax-FHEM · 27 Juli 2020, 19:29:37

Homematic ist BIDIREKTIONAL!

Also:

fhem (oder "irgendwas anderes") sendet einen Befehl zum Aktor (dann steht das Reading auf set_Befehl) und wartet (BIDIREKTIONAL) auf ein ACK.

Kommt das ACK -> geht das Reading auf Befehl (also set_ ist weg)...

Kommt kein ACK wird (evtl. je nach Einstellung) wiederholt...
...oder eben: Missing ACK...

Gruß, Joachim

gestein · 27 Juli 2020, 21:32:12

Hallo Joschim,

Danke für die Erklärung.
Gäbe es da einen Beispielcode in fhem bzw. Perl, wie man das dann am besten anfängt?

Denn wenn ich in fhem einfach warte, bis das Device ,,Missing Ack." liefert, dann weiß ich ja nicht, welcher Befehl zu dem Fehler geführt hat. Oder?

Danke, Lg, Gerhard

MadMax-FHEM · 27 Juli 2020, 22:20:31

Wüsste kein Beispiel.

ABER: wenn alles sauber eingerichtet ist und keine Störungen auftreten, dann ist eine (autom.) Reaktion/Beobachtung von JEDEM Befehl unnötig.

Ansonsten gibt es nur die Möglichkeit(en):

jeden Aufruf zu "wrappen", also einen eigenen set-Befehl "implementieren", der dann aufgrufen wird. Intern dann z.B. mit Watchdog oder eines at oder oder oder prüft, ob nach einer bestimmten Zeit das set_ weg ist und kein Missing Ack kam...

das Modul (CUL_HM denke ich) erweitern und eben genau das in jeden set einbauen...

Ich hatte noch nie Not eine solche Überprüfung zu brauchen...

Gruß, Joachim

frank · 28 Juli 2020, 00:07:28

wozu genau soll die aktion benutzt werden.
wie sehen die rssi werte aus.

gestein · 28 Juli 2020, 10:42:08

Hallo,

Danke für die Antworten.

Ich steuere meine Bewässerung mit insgesamt 3 HM-MOD-RE-8.
Manchmal (selten aber doch) geht zumindest ein ,,on-for-timer" nicht durch und dann hängt die Bewässerung.
Warum weiß ich (noch) nicht.
Zumindest passiert es immer wieder, wenn ich auf Urlaub bin. So wie jetzt auch.
Gestern haben auf einmal die beiden HM-MOD-RE-8 nicht mehr reagiert, die über den HMUART eingebunden sind.
Dieser HMUART ist aufgrund der Entfernung per ser2net an mein fhem angebunden.
Und der pi Zero mit dem HMUART reagiert manchmal nicht mehr.

Da hilft dann nur ein hard-reset des pi Zero und dann (nach dem Hochfahren) ein ,,getconfig" bei den HM-MOD-RE-8.
Woran der Fehler des pi Zero liegt, weiß ich nicht.
Den werde ich mal tauschen müssen.

Wahrscheinlich ist es am einfachsten zu prüfen, ob der HMUART auf disconnected ist um dann den pi zu reseten.
Aber dann weiß ich halt nicht, welche Bewässerung schon durchgelaufen ist.

Den rssi-Wert kann ich erst nach meinem Urlaub schicken.

Lg, Gerhard

frank · 28 Juli 2020, 10:46:06

ich "rieche" wlan.

edit: und oder ein burst problem mit overload.
zeig mal ein "get hminfo protoEvents".

gestein · 28 Juli 2020, 11:25:35

Ja, der Duft von WLAN täuscht Dich nicht

Ser2net läuft über WLAN.

Die Werte etc. kann ich leider erst am Wochenende zeigen.

Lg, Gerhard

martinp876 · 31 Juli 2020, 10:57:21

Das Prüfen der sicheren Kommunikation ist prio 1 einer Automatisierung - und das Problem ist vielschichtiger. Je nach device und schon erlebten Bugs.
1) Kommunikation (comm-state)
1a) ich entschuldige mich erst einmal für die schlechte Semantic. Die Begriffe comminication(commState) protoEvents (Protokoll in HMInfo) und msgEvents (im clear Kommando von messages) sind definitiv schlecht gewählt. Es ist quasi immer das gleiche...
1b) ob die (alle) kommandos problemlos übertragen sind lässt sich am Reading "commState" des Device ablesen. "CMDs_done" ist hier gewünscht.
1bI) Es bezieht sich auf die letzte Sequenz. Länger zrückliegende Fehler sind in den Internals (protCmdDel) anzulesen
1bII) mit "set clear msgErrors" kann man alte fehler quitieren/löschen und die Überwachnung neu starten
1c) Bei trägen Devices (wakeup,...) kann das Senden etwas dauern....
1d) faktisch lässt sich somit der Stand der Kommunikation prüfen. Fehler sollte erkennbar sein => wenn nicht, bitte melden

2) fehlreaktionen
2a) Kommando ist korrekt übertragen und quittiert - aber nicht wie gewünscht bearbeitet. Die Überwachung des Protokols ist also nicht immer hinreichend. Blinds sind bspw nicht in die übertragene Position gefahren.
2b) Eine Prüfung des Resultstat ist notwendig. Bei "level" Aktoren wie Dimmer/Blind wird dies (aufgrund bekannter fehlreaktionen der Devices) überwacht und das Kommando ggf wiederholt (1-mal!) Eine weitergehende Überwachung ist nicht vorgesehen und muss selbst eingebaut werden
2bI) Zu beachten ist, dass die Aktoren nicht nur durch Kommandos sondern auch durch trigger verändert werden können... Überwachung ist somit nur bedingt möglich
2c) Register-settings werden nach dem Setzen zwingend zurück-gelesen, nicht aber geprüft.
2cI) Nutzt man templates für Register-settings ist eine Komplett-überwachung inklusive. Allerdings nur bis zu dem Punkt, dass das Device nicht intern umprogrammiert wird (reset oder bei RTs möglich)

Ich bin sehr an einer möglichst exakten und sicheren Kommunikation interessiert. sollte es also zu Problemen kommen bitte Details sammeln und vermelden. Mal sehen, was man machen kann.

micky0867 · 31 Juli 2020, 11:14:40

Ich habe bei meiner Bewässerung auch so eine Problematik.
Verursacht durch Wifi und Powerlan.

Der Ablauf der Bewaesserung ist so:
Schritt 1: Ventil öffnen (on-for-timer)
Schritt 2: Pumpe einschalten (on-for-timer), aber nur, wenn Ventil offen

Ich habe dazu eine Perlfunktion gemacht, die mit Parameter "1" aufgerufen wird, um das Ventil zu öffnen.
Dadurch wird das Ventil (hoffentlich) geöffnet und die Funktion ruft sich mit sleep 10 und Parameter "2" selbst wieder auf.
Bei Parameter "2" wird dann geprüft, ob das Ventil geöffnet ist und ggf die Pumpe gestartet.
Ist das Ventil nicht geöffnet, wird der Admin per Telegram benachrichtigt und kann nachschauen.

Da das eine wichtige (für den Garten überlebens-wichtige) Funktion ist, habe ich mittlerweile 4 HMUARTLGWs im Einsatz...just in case

gestein · 31 Juli 2020, 11:30:24

Hallo,

Im Prinzip hatte ich bei den HMs nur wenig Probleme (bisher).
Die Auswirkungen waren bisher auch nicht wirklich dramatisch.
Schlimm wird es allerdings, wenn es um Bewässerung geht.

1) Da ich immer on-for-timer verwende, gehe ich davon aus, dass die Ventile auch wieder nach einer gegebenen Zeit schließen.
Damit sollte kein Wasser verschwendet werden und die Blumen auch nicht ,,absaufen".
Von einem Hardware-Defekt der Ventile will ich mal nicht ausgehen.
2) eigentlich müsste ich den Vorschlag von Joachim aufgreifen und eine Art Wrapper für meinen HM-MOD-RE-8 schreiben.
Richtig?

Das müsste wahrscheinlich wie folgt passieren (grob gesprochen):
1) prüfen, ob HM-MOD-RE-8 einsatzbereit ist oder bereits einen Fehler liefert.
2) prüfen, ob der entsprechende Kanal einsatzbereit bzw. ob nicht schon auf einen anderen Befehl gewartet wird (auch auf Device-Ebene bzgl. der anderen Kanäle).
3) set Befehl absetzen und auf Ergebnis warten.

Aufgrund der Device-Struktur kann so immer nur ein Befehl abgearbeitet werden, die anderen müssen warten.

Stimmt das so?

Das wird für mich ziemlich kompliziert 😉
Mal sehen, was ich da bis wann schaffe.

Die Idee mit einem zweiten redundanten HMUSB für den Garten ist natürlich auch nicht schlecht.

Danke, Lg, Gerhard

MadMax-FHEM · 31 Juli 2020, 12:07:58

Zitat von: gestein am 31 Juli 2020, 11:30:24
2) eigentlich müsste ich den Vorschlag von Joachim aufgreifen und eine Art Wrapper für meinen HM-MOD-RE-8 schreiben.
Richtig?

Das müsste wahrscheinlich wie folgt passieren (grob gesprochen):
1) prüfen, ob HM-MOD-RE-8 einsatzbereit ist oder bereits einen Fehler liefert.
2) prüfen, ob der entsprechende Kanal einsatzbereit bzw. ob nicht schon auf einen anderen Befehl gewartet wird (auch auf Device-Ebene bzgl. der anderen Kanäle).
3) set Befehl absetzen und auf Ergebnis warten.

Aufgrund der Device-Struktur kann so immer nur ein Befehl abgearbeitet werden, die anderen müssen warten.

Stimmt das so?

Das wird für mich ziemlich kompliziert 😉
Mal sehen, was ich da bis wann schaffe.

Oder eben sowas:

Zitat von: micky0867 am 31 Juli 2020, 11:14:40
Ich habe dazu eine Perlfunktion gemacht, die mit Parameter "1" aufgerufen wird, um das Ventil zu öffnen.
Dadurch wird das Ventil (hoffentlich) geöffnet und die Funktion ruft sich mit sleep 10 und Parameter "2" selbst wieder auf.
Bei Parameter "2" wird dann geprüft, ob das Ventil geöffnet ist und ggf die Pumpe gestartet.
Ist das Ventil nicht geöffnet, wird der Admin per Telegram benachrichtigt und kann nachschauen.

Ob das:

Zitat von: micky0867 am 31 Juli 2020, 11:14:40
Da das eine wichtige (für den Garten überlebens-wichtige) Funktion ist, habe ich mittlerweile 4 HMUARTLGWs im Einsatz...just in case

oder das:

Zitat von: gestein am 31 Juli 2020, 11:30:24
Die Idee mit einem zweiten redundanten HMUSB für den Garten ist natürlich auch nicht schlecht.

Immer eine gute (die richtige) Wahl ist...
...gut die vccu kümmert sich aber bei zu vielen redundanten IOs (für die selbe Aufgabe/Aktoren -> wirklich redundant) das nicht (irgendwann) kontraptoduktiv wird...

EDIT: was man so noch nicht raus kriegt, ob der Aktor das auch gemacht hat, also physisch

Ich habe das ab und an bei meinen Steckdosenaktoren mit Leistungsmessung: die "hängen". Da habe ich also ein notify auf off und prüfe dann nach einiger Zeit (glaub 30sec oder so), ob tatsächlich keine Leistung mehr "genutzt" wird. Wenn doch -> Telegram Nachricht, dass die Steckdose wohl (wieder mal) "hängt"... Jaja, Symtombekämpfung aber für das Wechseln der relais etc. hatte ich noch keine Zeit/Lust. Auch nicht für Alternativen, evtl. sind ja die Schaltaktoren von anderen Herstellern besser...

Gruß, Joachim

martinp876 · 31 Juli 2020, 13:59:45

Was auch immer überlebensnotwendig ist - den Schärfegrad muss jeder selbst festlegen.
Die Alarn-hierarchie ist immer die gleiche

1) sind die devices einsatzbereit / fehlerfrei
a) action detector
b) commState
c) Fehlermeldungen
2) sind die Sensoren ok? Diese kann man oft nicht ansprechen
a) Action-detector
b) fehlermeldungen
3) hat der Aktor meine Kommandos erhalte (siehe auch 1b)
4) hat der Aktor den korrekten Status gemeldet (bei on-for-timer auch wieder ausgeschaltet?)

Und nun die "externen" prüfungen.
5) Ist das Gerät, welches der Aktor steuert aktiv? Wenn ich ein Licht einschalten und die Birne ist kaputt ist es dennoch dunkel
a) Stromverbrauch messen (mess-aktor) wäre eine Option.
b) weitere Sensoren
c) bei Bewässerung den Wasserstand oder die feuchte?
=> das kann man nun endlos vorantreiben...

Jetzt kennen wir den Status recht sicher. Nun die Fehlerbehandlung
I) das IO funktioniert nicht
a) über VCCU ein 2. einbauen. fehlerfall testen
=> wenn der Aktor ein Problem hat hilft das nichts!
II) aktoren doppeln - 2 Einschalter.
III) der Motor ist defekt - Motor doppeln

Sicherheitstechnik ist wunderbar.
Hoffentlich stirbt die Himbeere nicht. Dafür müsste das Konzept geändert werden

frank · 31 Juli 2020, 14:23:57

und als aller erstes ein passendes "umfeld" schaffen.

1. freeze freies fhem, das sich nur auf die lebenswichtigen dinge konzentrieren muss.
2. passende ios nutzen, die timing beherschen.
3. kabelgebundene anbindung der ios, um latenzen zu minimieren. also kein wlan/powerlan.
4. 230v aktoren nutzen, die immer wach sind.
5. gute rssi werte einhalten.

wenn das alles passt, sollten die vorhandenen massnahmen von eq3 und cul_hm in der regel völlig genügen.

martinp876 · 31 Juli 2020, 16:43:54

Frank hat natürlich recht - um Problemen vorzubeugen.
Die "Sicherheitstechnik" (und davon sind wir sowieso weit entfernt

) setzt aber immer auf ein prüfen, nur in Notfällen auf ein 3-fachen (doppeln reicht für Gartenbewässerung auch)

HM (andere auch) bietet recht gute Möglichkeiten zu prüfen, dass die Devices korrekt arbeiten. Man muss sie allerdings nutze.
Immer bedenken, dass die Zentrale ein single-point of failure ist - und eine Himbeere ist keine Sicherheitstechnik! Daher nutze ich direktes peeren und device-eigene Funktionen wo immer es möglich ist. Meine alte Himbeere hatte mehrfach Probleme und Ausfälle (möglich die SD-Karte!?) .... wenn ich dann nicht da bin und meine Frau das Licht nicht an oder aus bekommt wird es für mich ungemütlich (egal wo ich bin

)

Und wie gesagt - wenn die Steuerung funktioniert sind die Motoren noch nicht geprüft