Schaltzustand HM-MOD-Re-8

Begonnen von betamax, 10 Juli 2016, 11:32:27

Vorheriges Thema - Nächstes Thema

betamax

Hallo,

wie kann es sein da das System ja Bidirektional arbeitet das keine Fehlermeldung ausgegeben wird?

Folgendes, meine Bewässerung schaltet sich mehrmals am Tag ein.
Um 10 Uhr funktionierte es, um 14 Uhr nicht. Im Logfile kein Fehler.
(Bild1 unten)

Bei CUL_HM (Rel_1) ist nicht wie üblich die Glühbirne zu sehen sondern "set_on-for-timer 60"
(Bild2 unten)

Nur bei CUL_HM switch ist der Fehler "Missing ACK" zu sehen.
(Bild3 unten)

RSSI liegt so bei -71 bis -75.
Ohne mein zutun startete der nächste Schaltvorgang wieder Fehlerfrei.
Das heißt aber auch, hätte ich es nicht zufällig bemerkt wäre es nie aufgefallen da kein Fehler im Logfile und bei CUL_HM auch wieder alles ok. 

Gruß
betamax
FHEM: 6.1 Raspberry Pi 3 mit Bullseye 64-bit (Debian11), CUL V3.4, 4 x HM-MOD-Re-8 V1.2, 2 x HM-CC-RT-DN V1.5, 1 x HM-RC-8 V1.1

Pfriemler

Bidirektional heißt nicht automatisch "Zustandsüberwachung". FHEM zeigt aber deutlich, dass es die Rückmeldung des Aktors vermisst. Du kannst mit einem DOIF oder notify darauf reagieren und den Befehl wiederholt absetzen, bis eine Bestätigung kommt. Automatisch passiert das aber nicht.
Der Zustand des Aktors ist aus Sicht von FHEM in Deinem Fall unklar: das set on-for-timer wird nach Empfang zunächst quittiert und anschließend mit dem neuen Status "on" bestätigt. In Deinem Fall fehlt bereits die Bestätigungsmeldung (MISSING ACK). Hier würde ich eher davon ausgehen, dass der Befehl nicht einmal angekommen ist.

geht nich Gips nich ...

"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

betamax

Zitat von: Pfriemler am 10 Juli 2016, 14:52:23
FHEM zeigt aber deutlich, dass es die Rückmeldung des Aktors vermisst.

Hallo Pfriemler,

ja macht es nur wenn man nicht jeden Schaltvorgang kontrolliert, so bekommt man der Fehler ja gar nicht mit
der wird nur kurzzeitig bei "CUL_HM switch" angezeigt.
Laut Logfile ist ja alles ok.
Die Schaltung mehrmals täglich kommt über einen DOIF Befehl.

Ich hätte vermutet das wenn zwei Geräte miteinander kommunizieren und es zu einem Fehler kommt dieser auch im Logfile protokolliert wird.
FHEM: 6.1 Raspberry Pi 3 mit Bullseye 64-bit (Debian11), CUL V3.4, 4 x HM-MOD-Re-8 V1.2, 2 x HM-CC-RT-DN V1.5, 1 x HM-RC-8 V1.1

Pfriemler

Fehlermöglichkeiten gibt es viele. Auch wenn der CUL sein Sendezeitlimit überschritten hätte würde genau das passieren. Aber wie schon gesagt: eine ausbleibende Quittung auf einen Schaltbefehl ist derzeit in FHEM kein Fehler. Bei sicherheitskritischen Anwendungen würde ich mir aber eine Kontrolle bauen mit entsprechenden Aktionen.

geht nich Gips nich ...

"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

martinp876

Es wird angezeigt wenn kommandos der zentrale nicht -oder scheinbar nicht- angenommen werden. Das gibt ein missing ack. Fhem wiederholt. Sollte dies nicht helfen werden kommandos verworfen. Irgenwann muss man stoppen und die aktion dem operator und application programmer ueberlassen, dir also.
Hminfo zeigt dir was bei welchen devices aufgetreten ist. Protoevents. Notwendige wiederholer oder gescheiterte anfragen.

Die kommunikation zwischen devices wird nicht ueberwacht. Moeglich waere es bei triggern wenn ein ack gefordert ist. Periodische msg haben kein ack, da geht es nicht.
Mal sehen, dass ich die ueberwachung nachtrage.

betamax

#5
Hallo,

heute um 10 Uhr funktionierte es nicht und um 14 Uhr ging es dann wieder.
Es scheint also öfter vorzukommen.

Ich habe etwas von einem missing acks Problem gelesen "Ein Problem bzgl. missing acks wurde vor ~2 Monaten gefixed."
Könnte das auch mein Problem sein?
FHEM 5.7 habe ich vor 2 Wochen auf der FB neu installiert.
Muß man danach noch ein Update machen?


Zitat von: Pfriemler am 11 Juli 2016, 10:36:05
Bei sicherheitskritischen Anwendungen würde ich mir aber eine Kontrolle bauen mit entsprechenden Aktionen.
Hallo Pfriemler,

das ist alles relativ, wenn es mal nicht geht ist es verkraftbar.
Bin ich an einem heißen Tag nicht da und die Schaltungen erfolgen nicht ist das Grünzeug wohl hin.
Als Kontrolle könnte ich am Wochenende meine Frau hinstellen.
Mehr ist mit meinen Programmierkenntnissen im Moment nicht machbar.

Zitat von: martinp876 am 11 Juli 2016, 16:32:46
Es wird angezeigt wenn kommandos der zentrale nicht -oder scheinbar nicht- angenommen werden. Das gibt ein missing ack. Fhem wiederholt. Sollte dies nicht helfen werden kommandos verworfen. Irgenwann muss man stoppen und die aktion dem operator und application programmer ueberlassen, dir also.

Hallo martinp876,

ok, verstanden.

Zitat von: martinp876 am 11 Juli 2016, 16:32:46
Hminfo zeigt dir was bei welchen devices aufgetreten ist. Protoevents. Notwendige wiederholer oder gescheiterte anfragen.
Ich habe define CUL_HM HMinfo angelegt und set CUL_HM update gemacht.
Daraufhin erschien im Logfile: 2016.07.12 12:26:29 1: PERL WARNING: Use of uninitialized value in split at ./FHEM/98_HMinfo.pm line 240.
Hier der Inhalt er Zeile 240:  push @updates,"I_actTotal:".join",",(split" ",$modules{CUL_HM}{defptr}{"000000"}{STATE});

protoEvents habe ich angehängt, es geht um den name: "Kue".
(Bild4 unten)
FHEM: 6.1 Raspberry Pi 3 mit Bullseye 64-bit (Debian11), CUL V3.4, 4 x HM-MOD-Re-8 V1.2, 2 x HM-CC-RT-DN V1.5, 1 x HM-RC-8 V1.1

martinp876

Mache ein update von fhem. Dann probier noch einmal.

Pfriemler

Abgesehen von martin's eleganter Version, auf Fehlermeldungen zentral zu reagieren: Ein "Wachhund", der im Hintergrund den Status des Magnetventilschalters checkt und auf ein "set on-for-timer" im Status reagiert, das länger als sagen wir mal 10 Sekunden dauert, ist eine nette Fingerübung für ein DOIF etwa. Was danach passiert, liegt in Deinem Ermessen: Nachricht aufs Handy, Wiederholung des Schaltversuchs für eine bestimmte Anzahl, der Frau das Licht in der Küche ausschalten - eines davon oder alles ...

Ich finde es aber komisch, dass gerade die 10-Uhr-Versuche fehlschlagen. Sind FHEM oder der CUL um 10 Uhr durch irgendetwas besonders absorbiert, gibt es Hinweise zu einem Funk-Overload, ...? Manchmal hilft die Verschiebung um eine Minute.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

betamax

Zitat von: martinp876 am 12 Juli 2016, 16:35:38
Mache ein update von fhem. Dann probier noch einmal.

Update gestern gemacht, hat nichts verbessert.
Heute um 10 Uhr funktionierte es wieder nicht, die Schaltbefehle davor und danach waren ok.

protoEvents habe ich angehängt.
(Bild5 unten)

Zitat von: Pfriemler am 12 Juli 2016, 23:09:39
Ich finde es aber komisch, dass gerade die 10-Uhr-Versuche fehlschlagen.

Es ist nicht immer 10 Uhr, das erste mal war 14 Uhr.

Zitat von: Pfriemler am 12 Juli 2016, 23:09:39
Sind FHEM oder der CUL um 10 Uhr durch irgendetwas besonders absorbiert, gibt es Hinweise zu einem Funk-Overload, ...? Manchmal hilft die Verschiebung um eine Minute.

Funk-Overload, ...? Gute Frage, ich denke nicht.
Ich habe ja 2 von den HM-MOD-Re-8 Aktoren im Betrieb.
Der zweite HM-MOD-Re-8 der bisher scheinbar keine Probleme macht schaltet 1 Minute nach dem ersten.
Ich werde die Zeiten der zwei mal tauschen und beobachten was passiert.

Gruß
betamax
FHEM: 6.1 Raspberry Pi 3 mit Bullseye 64-bit (Debian11), CUL V3.4, 4 x HM-MOD-Re-8 V1.2, 2 x HM-CC-RT-DN V1.5, 1 x HM-RC-8 V1.1

martinp876

Overload ist es nicht. Kein io err. Koennte man auch in io events sehen.
Es kann eine lokale ueberlast sein - wenn hier mehrere aktionen stattfinden. Ist dies moeglich?
Einmal alle msgs loggen um das umfeld zu sehen.

gompf

Moin,

Bei mir war das RE-8 mit nanoCUL/FW 1.66 nicht stabil, Wechsel auf das RPI-Modul brachte Abhilfe.
Der Zustand in FHEM ist gelegentlich mal nicht bekannt, reagiert aber immer auf Status request/Schaltkommando.

Vorher öfters "hängen geblieben" (kein Status/Reaktion). Meist half CUL reopen, teils nur HW-Reset am RE-8. Teils hing nur die Kommunikation mit RE-8, Teils CUL komplett geblockt. Dann lief es mal wieder 5 Tage durch... FW-Update des RE-8 war erfolgt.

Gruß,
Michael

Philipp

Ich hab hier auch ein RE-8 mit 4 24V Ventilen. Sporadisch ohne Muster reagiert meiner nicht mehr auf jegliche Funkanfragen, immer Missing_ACK. Sobald ich dann auf irgendeinem Kanal manuell die Taste drücke ist er auch wieder über Funk steuerbar.
Firmware ist auch aktualisiert, hat nichts geändert.
Vielleicht liegts an den geschaltenen 24V, was weiß ich....

Ich habe jetzt einen normalen 230V Funk-Schaltaktor als Ventilmaster davor, damit kann ich reseten....

lg
philipp

betamax

Zitat von: martinp876 am 14 Juli 2016, 23:42:34
Es kann eine lokale ueberlast sein - wenn hier mehrere aktionen stattfinden. Ist dies moeglich?

Hallo martinp876,
lokale Ueberlast? Durch mich eher nicht, ich habe ja nur zwei HM-MOD-Re-8 von denen aktuell nur jeweils ein Kanal benutzt wird.
Jeder Kanal schaltet 5 mal am Tag.
Es könnten nur fremde Geräte sein die auf der selben Frequenz arbeiten.
msgs loggen habe ich jetzt eingerichtet.

Hat man einen Einfluss auf die Wiederholung der Befehle die nicht ausgeführt werden?
Wenn ich protoEvents richtig deute findet auf ein "Snd" das nicht richtig ausgeführt wird nur ein einziges "Resnd" statt.
Selbst wenn aus dem "Resnd" ein "ResndFail" wird.

Um die Zuverlässigkeit generell zu erhöhen, könnte man nicht die Anzahl der "Resnd" erhöhen wenn ein "ResndFail" eintritt?
"ResndFail" dann erneut nach Zeit "x" "Snd" oder "Resnd"?


Zitat von: Pfriemler am 12 Juli 2016, 23:09:39
Manchmal hilft die Verschiebung um eine Minute.
Ich hab ja die Schaltzeiten der beiden HM-MOD-Re-8 getauscht.
Hat nicht geholfen, am Problem hat sich nichts geändert.

@gompf
@Philipp
danke für das Feedback.
Ganz hängen macht mein HM-MOD-Re-8 zu Glück bisher nicht er schaltet nur ab und zu nicht.

FHEM: 6.1 Raspberry Pi 3 mit Bullseye 64-bit (Debian11), CUL V3.4, 4 x HM-MOD-Re-8 V1.2, 2 x HM-CC-RT-DN V1.5, 1 x HM-RC-8 V1.1

LuckyDay

Zitatkönnte man nicht die Anzahl der "Resnd" erhöhen

was hält dich ab? , es per attr msgRepeat zu erhöhen?

betamax

Zitat von: fhem-hm-knecht am 17 Juli 2016, 16:59:18
was hält dich ab? , es per attr msgRepeat zu erhöhen?

Die Unwissenheit!
Danke für die Info, habe es von 1 auf 3 erhöht.
FHEM: 6.1 Raspberry Pi 3 mit Bullseye 64-bit (Debian11), CUL V3.4, 4 x HM-MOD-Re-8 V1.2, 2 x HM-CC-RT-DN V1.5, 1 x HM-RC-8 V1.1