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
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 ...
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.
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 ...
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.
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)
Mache ein update von fhem. Dann probier noch einmal.
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.
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
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.
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
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
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.
Zitatkönnte man nicht die Anzahl der "Resnd" erhöhen
was hält dich ab? , es per attr msgRepeat zu erhöhen?
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.
Hallo,
so seit 11 Tagen läuft es ohne ein "ResndFail".
Aktuell 114 "Snd" und davon 6 "Resend" siehe Bild6.
Bis "Snd" 92 sogar nur 1 "Resend".
Warum läuft es? Keine Ahnung ich habe nichts geändert außer attr msgRepeat von 1 auf 3 erhöht.
Update 2016-07-31
Zu früh gefreut heute wieder "Missing ACK, ResndFail"
Die Erhöhung von "attr msgRepeat" von 1 auf 3 hat nichts bewirkt.
Wahrscheinlich sendet der "msgRepeat" sofort hintereinander und verpufft dann sozusagen.
Kann man das nicht definieren, z.B. wenn fehlgeschlagen, warte 5 Minuten, sende erneut?
5 min warten? Generell? gefährlich - sehr lange!
Du schaltest Licht ein - klappt nicht. du schaust die Birne nach - 5 min später plötzlich Spannung - ui.
was machen wir in der zwischenzeit? Werden die Kommandos requeued? Du musst 5 min warten bis wieder etwas geht?
Lege ein konzept vor mit dem man allgemein arbeiten kann. Also klären was wann passieren soll - und mit was die Leute rechnen. Wenn du ein gesondertes Problem hast könnte man einen trigger suchen, mit dem du wiederholst. Das ist dann Eigenverantwortung - damit habe ich kein Problem, musst du dann wissen.
Sollte das Device nicht "hören" ist ein Repeat auf CUL_HM level definitiv nicht der Level für die Impementierung
Zitat von: martinp876 am 31 Juli 2016, 19:45:11
5 min warten? Generell? gefährlich - sehr lange!
Hallo martinp876,
das bezieht sich in erster Linie auf meinen Fall der Bewässerung, da kommt es nur darauf an dass es überhaupt funktioniert
und das möglichst zuverlässig. Das ist bei mir leider nicht der Fall.
Löten kein Problem aber Programmieren da möge man mir meine Unwissenheit verzeihen.
Ich tue mir damit sehr schwer das fängt schon damit das es heißt
DOIF ([06:00:00] or [10:00:00] or [14:00:00] or [18:00:00] or [22:00:00])(set Kiz_Bew_Rel_1 on-for-timer 50)Wiso heißt es 06:00 oder 10:00? Logisch wäre 06:00 und 10:00, das macht es für Anfänger nicht leichter.
Aus irgendeinem Grund funktioniert die Schaltung nicht zuverlässig, immer wieder "Missing ACK, ResndFail"
Die Erhöhung von "attr msgRepeat" von 1 auf 3 hat rein gar nichts gebracht und damit bin ich mit meinem Latein wieder am Ende.
Ich habe keine Ahnung wie man eine sichere Befehlswiederholung erreicht. :(
Zitat von: betamax am 01 August 2016, 11:01:47
Wiso heißt es 06:00 oder 10:00? Logisch wäre 06:00 und 10:00, das macht es für Anfänger nicht leichter.
Hallo betamax
Logisch kann es niemals 6:00
und 10:00 Uhr am selben Ort sein! Du moechtest aber, dass um 6:00 Uhr
oder um 10:00 Uhr gewaessert wird!
Gruss Christoph