[cul_hm] probleme mit wakeup und/oder lazyConfig und/oder A112

[frank]

noch ein schöne entdeckung, nach dem letzten restart vorhin


zu beginn dieses threads habe ich ja intensiv über den sinn und unsinn von A112 spekuliert. hier mal ein ausschnitt:

3. antwortverhalten für WAKEMEUP messages
ich versuche ja immer noch heraus zu finden, wann genau die ccu A112 (HAVEDATA) benutzt.
ich habe nämlich das gefühl, dass A112 in fhem zu oft genutzt wird und daher auch manchmal die kommunikation eher behindert.

theoretisch sind mir bisher 3 methoden bekannt, ein device zu wecken:

Code Auswählen Erweitern

  1.     2.     3.
A610 - A610 - A610  => WAKEMEUP
-------------------------------
A112   8102   A101  => WAKEUP
8002   A001
A001

am effektivsten und elegantesten ist natürlich methode 3. direktes antworten mit dem gewünschten cmd, das mit dem WAKEUP flag gesendet wird.

nun existiert bei fhem restart ja noch das problem mit der statusrequest-wakeup-queue, dass dort die io zu spät präpariert werden, wodurch die A112 messages erst gar nicht erzeugt werden, was wiederum zu vielen resends führt.

wahrscheinlich durch den hmlan-patch und das umstellen des IODev aller thermostate auf hmlan, hatte ich vorhin nur noch bei einem thermostat ein resend. denn das statusrequest cmd kommt nun so fix, dass es auch ohne A112 funktioniert hat. 

Code Auswählen Erweitern

2021.04.29 14:55:31.959 4: CUL_Parse: cul868 A 0C 6F 8670 1DFDA5 000000 009D3A14 -64
2021.04.29 14:55:31.963 3: CUL_HM set Thermostat.SZ_Climate statusRequest noArg
2021.04.29 14:55:31.964 0: HMLAN_Send:  hmlan1 I:+1DFDA5,02,00,00
2021.04.29 14:55:32.061 0: HMLAN_Send:  hmlan1 S:S1DB2DEF7 stat:  00 t:00000000 d:01 r:1DB2DEF7 m:70 A001 1ACE1F 1DFDA5 020E
2021.04.29 14:55:32.096 4: CUL_Parse: cul868 A 0B 70 A001 1ACE1F 1DFDA5 020E40 -42
2021.04.29 14:55:32.100 0: HMLAN_Parse: hmlan1 R:E1DFDA5   stat:0000 t:156F0183 d:FF r:FFC4     m:6F 8670 1DFDA5 000000 009D3A
2021.04.29 14:55:32.104 0: HMUARTLGW hmuart1 recv: 01 05 00 00 3F msg: 6F 86 70 1DFDA5 000000 009D3A
2021.04.29 14:55:32.107 0: HMUARTLGW hmuart1 recv: 01 05 00 00 2C msg: 70 A0 01 1ACE1F 1DFDA5 020E
2021.04.29 14:55:32.222 4: CUL_Parse: cul868 A 0E 70 8002 1DFDA5 1ACE1F 01020C003E14 -64
2021.04.29 14:55:32.227 0: HMLAN_Send:  hmlan1 I:+1DFDA5,00,00,00
2021.04.29 14:55:32.255 0: HMLAN_Parse: hmlan1 R:R1DB2DEF7 stat:0001 t:156F028E d:FF r:FFC4     m:70 8002 1DFDA5 1ACE1F 01020C003E
2021.04.29 14:55:32.259 0: HMUARTLGW hmuart1 recv: 01 05 00 00 42 msg: 70 80 02 1DFDA5 1ACE1F 01020C003E



wie vermutet ist das A112 also scheinbar völlig überflüssig.
wie du siehst macht es die kommunikation unnötig kompliziert und wird wohl nicht gebraucht.
ich denke, wenn ich allen thermostaten meinen cul zuweise, gibt es hier gar keine probleme mehr. 


gruss frank

[papa]

Könnte es sein, das HAVEDATA nach einer Peer-Message gesendet wird, um dem Gerät zu signalisieren, dass die Zentrale noch Daten hat und das Gerät nicht sofort nach dem ACK vom Peer wieder in den Sleep geht?

[noansi]

Hallo Frank,

zusammenfassung des led verhaltens (inkl meines sc/fw2.4):

Warum dachte ich mir schon, dass da noch mehr kommen würde. 
Schöne Aufstellung. Und auch ein schöner link. 

da vermute ich mal, dass der "zickige" sc-2 mit fw 2.2 mit diesem switch gepeert, ebenfalls grün zeigen würde.

Du wirst doch den Konjunktiv nicht so im Raum stehen lassen?

wie vermutet ist das A112 also scheinbar völlig überflüssig.
wie du siehst macht es die kommunikation unnötig kompliziert und wird wohl nicht gebraucht.

Wenn das IO es nach Vorbereitung autonom sendet und FHEM grad schwer beschäftigt ist, dann ist schon gleich viel weniger überflüssig.

Gruß, Ansgar.

[frank]

Wenn das IO es nach Vorbereitung autonom sendet und FHEM grad schwer beschäftigt ist, dann ist schon gleich viel weniger überflüssig.

nein, das sehe ich anders.

wenn fhem grundsätzlich ein problem mit "überbeschäfftigung" hat, dann besteht dieses problem ja weiterhin auch nach einem erfolgreichen, autonomen A112.

das potentielle problem wurde lediglich verschoben, aber nicht umgangen.

[frank]

hallo papa,

Könnte es sein, das HAVEDATA nach einer Peer-Message gesendet wird, um dem Gerät zu signalisieren, dass die Zentrale noch Daten hat und das Gerät nicht sofort nach dem ACK vom Peer wieder in den Sleep geht?

wenn du mit "Peer-Message" den trigger vom sensor an den aktor meinst, dürfte es eigentlich nicht funktionieren, da ich beim trigger an den peer noch kein WAKEMEUP flag gesehen habe.
ausserdem senden meine sensoren sowieso zusätzlich jeden trigger mit WAKEMEUP an die zentrale, wodurch das unnötig wäre.

direkt nach der "Peer-Message" wäre das risiko einer msg-collision mit dem ACK des aktors auch ziehmlich hoch.