HM-RC-19 Fernbedienung - Detailkonfiguration

[martinp876]

Hallo Michael,

nun, das habe ich dann schon alles gesehen. Gut erst einmal.
Dass es etwas mit einer ueberlast zu tun hat war klar, der Hinweis mit msgs/h hatte ich nicht im Blick

xx08 bedeuted normal: message mit ack request gesendet aber kein ACK erhalten
somit ist
0008 : 3 mal gesendet, kein ACK
0408 : nicht gesendet, kein ACK (klar)

Mit dem erweiterten Hintergrung werde ich Versuche anstellen...
Auf jeden Fall werde ich einen entsprechendes Status-reading einbauen.

Kommandos 1h queuen halte ich fuer nicht sinnvoll, ggf sogar gefaehrlich. Da koennten ploetzlich Lichter ein/ausgeschaltet werden, Steckdosen unter spannung kommen, 1h nach der Aktion... Rollos fahren in ungewuenschte Positionen, Tueren werden verschlossen... Das kann man nicht machen.

Generell sind die 'proto...' parameter geeignet, es abzubilden. Ausserdem braucht man noch ein Reading, um notifies anbinden zu koennen.

Jetzt aber erst einmal den Mechanismus verstehen und ausmessen

Gruss Martin

[wkarl]

Hallo Martin,

hast Du damit alles was Du brauchst oder soll ich Dir noch die Log-Informationen zusammenstellen?

ciao walter

[martinp876]

soweit habe ich alles, danke.

Die Messungen werden etwas dauern...

[martinp876]

so, hier mal ein Zwischenstatus - fuer den Fall dass jemand noch Erkentnisse oder Ideen hat

- es gibt 2 'status' 02 und 04, welche beiden einen Overload-level anzeigen
- ich kann beiden reproduzieren, aber nicht sehr gezielt. Eine klare Formel konnte ich nicht identifizieren.
- 02 koennte ein warning-level sein. Im Prinzip funktioniert noch alles
- 04 ist ein error-level. Der Transmitter sendet nicht mehr (main process und LAN interface scheinen immer noch 'normal' zu arbeiten)
- HMLAN ist in beiden Faellen immer noch in der Lage, alles zu monitoren. Empfangen ist also kein Problem, nur der Transmitter ist betroffen.

Recovery
- power-down funktioniert
- ein reset kommando gibt es sicher... leider kenne ich es nicht
- HMLAN erholt sich selbstaendig, je nach Level so nach 5-10 min. In dieser Zeit duerfen keine Sendeauftraege stattfinden.

Geplante Implementierung
+ unstrittig
- HMLAN wird ein Reading erhalten, dass den Transmitter-Zustand darstellt. Somit kann man mit notifies arbeiten
- FHEM wird bei erreichen des error-level fuer eine gegebene Zeit das Senden blockieren. Das wird nach bisherigen Messungen so bei 3-5min liegen.
- ein power-down des HLMAN wird auch den timer loeschen
- Es wird Zaehler in HMLAN geben, die Auskunft ueber die Haefigkeit der Problem gibt

+ (etwas) fraglich
- da eine Wartezeit von 5 min erheblich ist stellt sich die Frage, was man mit wartenden oder eingehenden Kommandos zu machen ist. Aktuell plane ich, alle Kommandos, die in der fraglichen Zeit kommen zu loeschen.
- Im CUL_HM Device wird es einen Zaehler "protoIOerr" geben, der dies erfasst.

Das Senden zu verzoegern halte ich fuer unklug/gefaehrlich. Es sind nicht nur getConfig oder peering kommandos sondern auch schalt-kommandos , incl tuerverriegelungen. Auch wenn jemand etwas an der Steckdose macht und diese ploetzlich einschaltet...

Das ganze wird freundlicher, falls wir entsprechende rueckstell kommandos des HMLAN finden

Gruss
Martin