Liebe Leuts,
das Thema wurde eigentlich hier schon einmal erwähnt: https://forum.fhem.de/index.php/topic,17012.0.html ...
Ich dachte erst es wäre meine Blödheit, aber das Problem manifestiert sich inzwischen auf allen meinen Dimmern mit virtuellen Kanälen. (Dim1PBU-FM, Dim1T-DR, Dim1T-Pl-x)
Im Kern geht es darum, dass bei einem Schalten des Kanals über on/off/toggle in FHEM keine klare Meldung im STATE und im Reading state ankommt, sondern etwas im Stil "chn:on phys:0". Aus dem o.g. Thread habe ich die Empfehlung, alle Readings einmal zu löschen, umgesetzt - und in der Tat lässt sich anschließend mit on/off/toggle schalten und der Status kommt ordentlich an.
Setzt man hingegen einmalig den Level per "pct", erfolgt vom Dimmer eine Rückmeldung über den physischen Level als Sofortantwort (z.B. "chn:on phys:0.5" beim Rampenstart) und späterhin als echtes Ergebnis "chn:on phys:100". Stimmen beide Level überein, wird es einheitlich (hier also "on") angezeigt. Bleibt man jetzt beim Setzen per pct, kommen immer saubere Rückmeldungen über "on" und "off".
Schaltet man nun aber über on/off/toggle, wird das Reading "phyLevel" nicht aktualisiert. , und das bei mir unabhängig von der Einstellung in autoReadReg. Entspricht das Schaltergebnis dem phyLevel, erfolgt weiterhin die Umsetzung in sauberen Status - bei phyLevel 0 wird der Aktor also immer "off". Schaltet man ihn aber ein, entspricht nun pyhLevel nicht dem tatsächlichen Rückgabewert des Aktors mehr und es erscheint "chn:on phys:0" als Ergebnis. Das geht auch andersrum.
Löscht man phyLevel nun händisch, gibt es wieder keine Probleme bis zum nächsten set ... pct.
Anscheinend ist das Problem auch nach sechs Jahren noch nicht gelöst, oder habe ich was übersehen?
Ist das nachvollziehbar? Wie kann man es - außer meinen Würgaround - abstellen?
1) der Status
Bei Virtual-Channel-Devices hat man per definition das Problem zu entschieden, was man im Status darstellt. Mein Auswahl für de Default halte ich immer noch für korrekt.
- "level" und "pct" stellen den Level des (virtuellen) kanals dar
- "phyLevel" ist der reale Zustand der Glühbirne
- "State" zeigt ggf die Mischung, so sich die Level unterscheiden.
Der Anwender kann state jederzeit nach seinen Bedürfnissen "umbiegen". Es ist dann seine Entscheidung, wo er den resultierenden und wo den partiellen Level darstellen will. Der Default macht ihn ggf auf eine Diskrepanz aufmerksam, was ich für wichtig halte.
2) Update phyLevel
in meinen Tests wird phyLevel bei on/off/toggle der phyLevel immer aktualisiert. Das kann leicht verzögert stattfinden, da dies nicht im "ack" sondern in der Statusabfrage geliefert wird. Diese wird(sollte) automatisch geschehen. Ich hoffe, alle möglichen Schlupflöcher gefunden zu haben....
Sniffe doch einmal den Ablauf, dann versuche ich es nachzuvollzeihen.
Martin, alles zu 1) habe ich schon so verstanden. Es ist auch prinzipiell gut so.
Aber zu 2) wird bei mir phyLevel eben NICHT aktualisiert. Es manifestiert sich bei mir offenbar so, dass diese Aktoren eben KEINE Statusmeldung zurücksenden - oder die irgendwo verlorengeht.
Infolgedessen gibt es keine phyLevel-Aktualisierung.
nachfolgend ein Dimmaktor (chn1 - physischer) aus FHEM per "on" eingeschaltet, 10s später per "pct 0" ausgeschaltet:
2020.06.13 12:35:35 1: **************************** HM-Logging für HM_414004_Dim gestartet
2020.06.13 12:35:35 1: HM_414004_Dim model HM-LC-DIM1T-PL-3
2020.06.13 12:35:40.885 0: HMUARTLGW HMUART send: 01 02 00 00 00 msg: 26 A0 11 1411AB 414004 0201C80000
2020.06.13 12:35:41.044 0: HMUARTLGW HMUART recv: 01 04 03 00 24 msg: 26 80 02 414004 1411AB 0101C8002700
2020.06.13 12:35:50.585 0: HMUARTLGW HMUART send: 01 02 00 00 00 msg: 27 A0 11 1411AB 414004 0201000320FFFF
2020.06.13 12:35:50.745 0: HMUARTLGW HMUART recv: 01 04 03 00 24 msg: 27 80 02 414004 1411AB 0101C72027C8
2020.06.13 12:35:55.656 0: HMUARTLGW HMUART recv: 01 05 01 00 24 msg: 28 A4 10 414004 1411AB 060100008000
2020.06.13 12:36:02 1: **************************** HM-Logging beendet
FHEM ist aktuell (von vorgestern).
autoReadReg steht im Device auf 4_. Im channel fehlt es und kann nicht gesetzte werden ("only valid for devices"). (hier hinkt die commandref noch, btw).
Hier wurde der Dimmer per "on" eingeschaltet und anschließend ein manuelles getConfig nachgesetzt.
2020.06.13 12:41:03 1: **************************** HM-Logging für HM_414004_Dim gestartet
2020.06.13 12:41:03 1: HM_414004_Dim model HM-LC-DIM1T-PL-3
2020.06.13 12:41:09.715 0: HMUARTLGW HMUART send: 01 02 00 00 00 msg: 37 A0 11 1411AB 414004 0201C80000
2020.06.13 12:41:09.874 0: HMUARTLGW HMUART recv: 01 04 03 00 24 msg: 37 80 02 414004 1411AB 0101C8002800
2020.06.13 12:41:55.357 0: HMUARTLGW HMUART send: 01 02 00 00 00 msg: 38 A0 01 1411AB 414004 01040000000001
2020.06.13 12:41:55.625 0: HMUARTLGW HMUART recv: 01 05 01 00 23 msg: 38 A0 10 414004 1411AB 02300632503364344B3550560057245901
2020.06.13 12:41:55.778 0: HMUARTLGW HMUART recv: 01 05 01 00 23 msg: 39 A0 10 414004 1411AB 020800
2020.06.13 12:41:56.011 0: HMUARTLGW HMUART recv: 01 05 01 00 22 msg: 3A A0 10 414004 1411AB 030000
2020.06.13 12:41:56.308 0: HMUARTLGW HMUART send: 01 02 00 00 00 msg: 3B A0 01 1411AB 414004 0103
2020.06.13 12:41:56.476 0: HMUARTLGW HMUART recv: 01 05 01 00 23 msg: 3B A0 10 414004 1411AB 014140040100000000
2020.06.13 12:41:57.103 0: HMUARTLGW HMUART send: 01 02 00 00 00 msg: 3C A0 01 1411AB 414004 01044140040103
2020.06.13 12:41:57.274 0: HMUARTLGW HMUART recv: 01 05 01 00 22 msg: 3C A0 10 414004 1411AB 0301000000326400FF00FF011452632000
2020.06.13 12:41:57.518 0: HMUARTLGW HMUART recv: 01 05 01 00 21 msg: 3D A0 10 414004 1411AB 031014C80A050500C80A0A0404
2020.06.13 12:41:57.761 0: HMUARTLGW HMUART recv: 01 05 01 00 22 msg: 3E A0 10 414004 1411AB 032600145263
2020.06.13 12:41:58.019 0: HMUARTLGW HMUART recv: 01 05 01 00 21 msg: 3F A0 10 414004 1411AB 0381000000326400FF00FF261452632000
2020.06.13 12:41:58.265 0: HMUARTLGW HMUART recv: 01 05 01 00 23 msg: 40 A0 10 414004 1411AB 039014C80A050500C80A0A0404
2020.06.13 12:41:58.506 0: HMUARTLGW HMUART recv: 01 05 01 00 23 msg: 41 A0 10 414004 1411AB 03A620145263
2020.06.13 12:41:58.752 0: HMUARTLGW HMUART recv: 01 05 01 00 22 msg: 42 A0 10 414004 1411AB 030000
2020.06.13 12:42:31 1: **************************** HM-Logging beendet
Aus meiner Sicht bedeutet das:
- trotz autoReadReg wird der Status nicht automatisch abgefragt (oder wie lange hätte ich warten sollen?)
- auch bei einem getConfig wird hier phyLevel nicht aktualisiert
Wenn Du etwas anderes aus den Daten herauslesen kannst, ...?
edit: Stop: statusRequest aktualisiert richtig! getConfig tut es nicht. Schade eigentlich...
10_CUL_HM.pm 22098 2020-06-02 18:42:46Z martinp876
...
HMConfig.pm 20888 2020-01-05 06:59:29Z martinp876
So, jetzt Du :-)
Das Problem will ich nicht in Abrede stellen
Was ist sehe ist ein schalten u und dann ein getconfig. Woher kommt das?
Ich vermute, dass bei dieser Sequenz das Statusrequest verloren geht.
1) ich werde das Verhalten bei dieser Sequenz prüfen
2) ist die config des device komplett?
3) ist die cmdqueue zu Beginn leer? Also kein e cmds pending?
Habe ich erläutert, Martin. Schau auf die Zeiten.
Ein "set ... on" und dann 45 sek später ein manuell ausgelöstes getConfig.
Möglich, dass ich das statusRequest durch das manuelle getConfig gestört habe. In welcher Zeit sollte CUL_HM das statusRequest abgesetzt haben?
Natürlich ist die config des Device ist komplett, und es waren auch keine CMDs im Queue. Auf sowas achte ich doch.
Ok.
Ein getconfig liest die configuration, also register. Der level ist nicht konfiguriert, es ist ein operational Parameter.
Ein statusrequest muss helfen. Der aber sollte typisch automatisch nachgefragt werden. Die details sind lange her, der grund war nicht nur physlevel, vielmehr schlechtes dimmverhalten einiger device welche bei falschem Level stehen geblieben sind.
Das getconfig in diesem fall hatte ich überlesen und es hat mich verwirrt
Ich helf ja gern beim Mitsuchen, aber 10_CUL_HM ist nicht gerade mein Heimatland ;D
Ich wollte nicht patzig sein, 'tschulljung.
Was mich nur wundert: keine Rückmeldungen von anderen. Der Sachlage nach kann ich doch kaum der Einzige sein. Die Hänger im Status existieren schon seit Jahren, können also auch kein Ergebnis jüngerer Umstrukturierungen sein.
Man könnte sich mit einem Notify behelfen, was bei "chn.." Stati ein Statusrequest nachschiebt. Sinnvoller wäre wenn das CUL_HM macht. Offenbar hast Du es sogar längst eingebaut, aber es funktioniert noch nicht richtig.
Andere Lösungen sehe ich nicht. phyLevel bei on/off/toggle selbst zu setzen war erst meine Idee, ist aber Quatsch.
Unsicher bin ich, ob man bei einer Differenz von pct und phyLevel immer sofort statusRequest senden oder warten sollte. Ersteres würde bei Schaltaktionen umgehend helfen, wäre bei laufenden Rampen aber vermutlich zu häufig angefordert.
Vielleicht wäre es wirklich erst mal hilfreich, bei on/off/toggle zumindest nach dem ACK des Aktors unverzögert statusRequest zu machen.
Wie gesagt: mit Rampen jedweder Geschwindigkeit, auch wenn sie von peers getriggert werden, gibt es null Probleme.
wie aktuell ist denn dein fhem?
gestern gab es einen fix, der eine mögliche blockade in der queue beseitigt hat.
zu deinen beobachtungen kann ich zur zeit nichts sagen.
von gestern eher nicht, siehe 3. Beitrag.
Einfach mal einen Dimmer mit virtuellen Kanälen (einkanalige haben das Problem nicht) wechselseitig mit pct und on/off steuern. Wenn phyLevel beim Schalten über on/off/toggle nicht aktualisiert wird, ...
Ich habe hier gerade mal mit einem HM-LC-DIM1PWM-CV herumgespielt. Es werden alle Readings korrekt aktualisiert.
ich habe mal meinen dim1tpbu bestromt und kann die fehlende status berechnung bestätigen.
eventmonitor inklusive sniff von "on, off, toggle, statusrequest und set pct 33"
2020.06.13 23:32:40.678 3 : CUL_HM set DimPBU01_chn01 on
2020-06-13 23:32:40.633 CUL_HM DimPBU01 commState: CMDs_pending
2020-06-13 23:32:40.659 CUL_HM DimPBU01 CMDs_pending
2020-06-13 23:32:40.678 CUL_HM DimPBU01_chn01 set_on
2020-06-13 23:32:40.707 CUL_HM DimPBU01 commState: CMDs_processing...
2020.06.13 23:32:40.722 0 : HMLAN_Parse: hmlan1 R:E1ACE1F stat:0000 t:30A8D5B6 d:FF r:FFCC m:8A A011 1ACE1F 266A86 0201C80000
2020.06.13 23:32:40.908 0 : HMLAN_Parse: hmlan1 R:E266A86 stat:0000 t:30A8D634 d:FF r:FFC6 m:8A 8002 266A86 1ACE1F 0101C800376C
2020-06-13 23:32:40.873 CUL_HM DimPBU01 commState: CMDs_done
2020-06-13 23:32:40.873 CUL_HM DimPBU01 CMDs_done
2020-06-13 23:32:40.901 CUL_HM DimPBU01_chn01 deviceMsg: on (to ccu)
2020-06-13 23:32:40.901 CUL_HM DimPBU01_chn01 dim: stop:on
2020-06-13 23:32:40.901 CUL_HM DimPBU01_chn01 level: 100
2020-06-13 23:32:40.901 CUL_HM DimPBU01_chn01 pct: 100
2020-06-13 23:32:40.901 CUL_HM DimPBU01_chn01 chn:on phys:84
2020.06.13 23:35:22.109 3 : CUL_HM set DimPBU01_chn01 off
2020-06-13 23:35:22.066 CUL_HM DimPBU01 commState: CMDs_pending
2020-06-13 23:35:22.090 CUL_HM DimPBU01 CMDs_pending
2020-06-13 23:35:22.109 CUL_HM DimPBU01_chn01 set_off
2020-06-13 23:35:22.137 CUL_HM DimPBU01 commState: CMDs_processing...
2020.06.13 23:35:22.154 0 : HMLAN_Parse: hmlan1 R:E1ACE1F stat:0000 t:30AB4C63 d:FF r:FFCC m:8B A011 1ACE1F 266A86 0201000000
2020.06.13 23:35:22.338 0 : HMLAN_Parse: hmlan1 R:E266A86 stat:0000 t:30AB4CE0 d:FF r:FFC6 m:8B 8002 266A86 1ACE1F 0101000036EC
2020-06-13 23:35:22.304 CUL_HM DimPBU01 commState: CMDs_done
2020-06-13 23:35:22.304 CUL_HM DimPBU01 CMDs_done
2020-06-13 23:35:22.330 CUL_HM DimPBU01_chn01 deviceMsg: off (to ccu)
2020-06-13 23:35:22.330 CUL_HM DimPBU01_chn01 dim: stop:off
2020-06-13 23:35:22.330 CUL_HM DimPBU01_chn01 level: 0
2020-06-13 23:35:22.330 CUL_HM DimPBU01_chn01 pct: 0
2020-06-13 23:35:22.330 CUL_HM DimPBU01_chn01 chn:off phys:84
2020.06.13 23:36:43.811 3 : CUL_HM set DimPBU01_chn01 toggle
2020-06-13 23:36:43.769 CUL_HM DimPBU01 commState: CMDs_pending
2020-06-13 23:36:43.793 CUL_HM DimPBU01 CMDs_pending
2020-06-13 23:36:43.811 CUL_HM DimPBU01_chn01 set_toggle
2020-06-13 23:36:43.839 CUL_HM DimPBU01 commState: CMDs_processing...
2020.06.13 23:36:43.855 0 : HMLAN_Parse: hmlan1 R:E1ACE1F stat:0000 t:30AC8B94 d:FF r:FFCC m:8C A011 1ACE1F 266A86 0201C80000
2020.06.13 23:36:44.161 0 : HMLAN_Parse: hmlan1 R:E266A86 stat:0000 t:30AC8C12 d:FF r:FFC6 m:8C 8002 266A86 1ACE1F 0101C800376C
2020-06-13 23:36:44.005 CUL_HM DimPBU01 commState: CMDs_done
2020-06-13 23:36:44.005 CUL_HM DimPBU01 CMDs_done
2020-06-13 23:36:44.031 CUL_HM DimPBU01_chn01 deviceMsg: on (to ccu)
2020-06-13 23:36:44.031 CUL_HM DimPBU01_chn01 dim: stop:on
2020-06-13 23:36:44.031 CUL_HM DimPBU01_chn01 level: 100
2020-06-13 23:36:44.031 CUL_HM DimPBU01_chn01 pct: 100
2020-06-13 23:36:44.031 CUL_HM DimPBU01_chn01 chn:on phys:84
2020.06.13 23:38:04.169 3 : CUL_HM set DimPBU01_chn01 statusRequest
2020-06-13 23:38:04.142 CUL_HM DimPBU01 commState: CMDs_pending
2020-06-13 23:38:04.168 CUL_HM DimPBU01 CMDs_pending
2020-06-13 23:38:04.200 CUL_HM DimPBU01 commState: CMDs_processing...
2020.06.13 23:38:04.212 0 : HMLAN_Parse: hmlan1 R:E1ACE1F stat:0000 t:30ADC582 d:FF r:FFCC m:8D A001 1ACE1F 266A86 010E
2020.06.13 23:38:04.525 0 : HMLAN_Parse: hmlan1 R:E266A86 stat:0000 t:30ADC602 d:FF r:FFC6 m:8D A410 266A86 1ACE1F 0601C80035C8
2020.06.13 23:38:04.528 0 : HMLAN_Parse: hmlan1 R:E1ACE1F stat:0000 t:30ADC682 d:FF r:FFCC m:8D 8002 1ACE1F 266A86 00
2020-06-13 23:38:04.462 CUL_HM DimPBU01 commState: CMDs_done
2020-06-13 23:38:04.462 CUL_HM DimPBU01 CMDs_done
2020-06-13 23:38:04.481 CUL_HM DimPBU01_Sw1_V01 phyLevel: 100
2020-06-13 23:38:04.481 CUL_HM DimPBU01_Sw1_V01 chn:off phys:100
2020-06-13 23:38:04.499 CUL_HM DimPBU01_Sw1_V02 phyLevel: 100
2020-06-13 23:38:04.499 CUL_HM DimPBU01_Sw1_V02 chn:off phys:100
2020-06-13 23:38:04.522 CUL_HM DimPBU01_chn01 phyLevel: 100
2020-06-13 23:38:04.522 CUL_HM DimPBU01_chn01 on
2020.06.13 23:55:37.954 3 : CUL_HM set DimPBU01_chn01 pct 33
2020-06-13 23:55:37.899 CUL_HM DimPBU01 commState: CMDs_pending
2020-06-13 23:55:37.918 CUL_HM DimPBU01 CMDs_pending
2020-06-13 23:55:37.936 CUL_HM DimPBU01_chn01 level: set_33
2020-06-13 23:55:37.954 CUL_HM DimPBU01_chn01 set_33
2020-06-13 23:55:37.977 CUL_HM DimPBU01 commState: CMDs_processing...
2020.06.13 23:55:38.000 0 : HMLAN_Parse: hmlan1 R:E1ACE1F stat:0000 t:30BDDA69 d:FF r:FFCC m:90 A011 1ACE1F 266A86 0201420320FFFF
2020.06.13 23:55:38.170 0 : HMLAN_Parse: hmlan1 R:E266A86 stat:0000 t:30BDDAE4 d:FF r:FFC6 m:90 8002 266A86 1ACE1F 0101291035AC
2020-06-13 23:55:38.141 CUL_HM DimPBU01 commState: CMDs_done
2020-06-13 23:55:38.141 CUL_HM DimPBU01 CMDs_done
2020-06-13 23:55:38.167 CUL_HM DimPBU01_chn01 deviceMsg: 20.5 (to ccu)
2020-06-13 23:55:38.167 CUL_HM DimPBU01_chn01 dim: up:20.5
2020-06-13 23:55:38.167 CUL_HM DimPBU01_chn01 level: 20.5
2020-06-13 23:55:38.167 CUL_HM DimPBU01_chn01 pct: 20.5
2020-06-13 23:55:38.167 CUL_HM DimPBU01_chn01 chn:20.5 phys:20
2020-06-13 23:55:42.541 CUL_HM DimPBU01_Sw1_V01 phyLevel: 33
2020-06-13 23:55:42.541 CUL_HM DimPBU01_Sw1_V01 chn:off phys:33
2020-06-13 23:55:42.559 CUL_HM DimPBU01_Sw1_V02 phyLevel: 33
2020-06-13 23:55:42.559 CUL_HM DimPBU01_Sw1_V02 chn:off phys:33
2020-06-13 23:55:42.587 CUL_HM DimPBU01_chn01 deviceMsg: 33 (to ccu)
2020-06-13 23:55:42.587 CUL_HM DimPBU01_chn01 dim: stop:33
2020-06-13 23:55:42.587 CUL_HM DimPBU01_chn01 level: 33
2020-06-13 23:55:42.587 CUL_HM DimPBU01_chn01 pct: 33
2020-06-13 23:55:42.587 CUL_HM DimPBU01_chn01 phyLevel: 33
2020-06-13 23:55:42.587 CUL_HM DimPBU01_chn01 33
2020.06.13 23:55:42.590 0 : HMLAN_Parse: hmlan1 R:E266A86 stat:0000 t:30BDEBB7 d:FF r:FFC7 m:91 A410 266A86 1ACE1F 060142008042
2020.06.13 23:55:42.593 0 : HMLAN_Parse: hmlan1 R:E1ACE1F stat:0000 t:30BDEC38 d:FF r:FFCC m:91 8002 1ACE1F 266A86 00
edit:
direkt nach dem "set on" kommt der dimmer in die queue, wird aber nicht abgearbeitet.
manueller statusrequest entfernt den dimmer wieder aus der queue.
requests pending
----------------
autoReadReg :
recent : none
status request : DimPBU01
autoReadReg wakeup :
status request wakeup: Wetter.Sued
autoReadTest :
IODevs:cul868:Initialized condition:-
hmlan1:opened pending=0 condition:ok
hmuart1:disconnected condition:disconnected
edit2:
scheinbar ist es viel komplizierter.
man muss den status aller 3 chn im auge haben. sobald mindestens ein chn diesen kombinierten status zeigt, wird das hauptdevice in die queue eingetragen. ist das überhaupt richtig? warum nicht die entsprechenden chn?
allerdings "repariert" kein statusrequest die virtuellen chn, sondern zb ein set on. erst wenn alle 3 chn einen korrekten status zeigen, verschwindet das hauptdevice aus der queue.
ZitatIch wollte nicht patzig sein, 'tschulljung.
hatte nichts bemerkt - alles gut. Das Problem muss geklärt werden, keine Frage.
Zur Technik:
- der Phy-Level wird mit StatusInfo gemeldet. Der Channel-Level mit StatusInfo UND dem Ack
. mein Aktr liefert nach dem ack automatisch eine StatusInfo. Nicht alle aktoren arbeiten gleich. Es ist ein TBU, also wie bei Frank
- Die Status-Queue wird bedient, wenn attr autoReadReg >3 ist!!! Wurde auf Wunsch von Anwendern eingebaut, welche glaubten, alles einzeln steuern zu wollen.
- Ein Status-Request wird nach 5s in die Status-queue eingehängt wenn nach 5s keine Status gekommen ist.
- mit einem StatusInfo wird der Phys-Level aller (typisch 3) virtueller Kanäle auf Stand gebracht.
Stellt sich die Frage
1) ist das Device ein der Status Queue - und hängt dort.
1a) timer der Status-Queue ausgeben
{join("\n",sort grep/CUL_HM/,map{sprintf("%8d",int($intAt{$_}{TRIGGERTIME}-gettimeofday())).":$intAt{$_}{FN}\t$intAt{$_}{ARG}"} (keys %intAt))}1b) wer ist gelistet
{join(" ",@{$modules{CUL_HM}{helper}{qReqStat}})}2) timer: ist die Wartezeit zu lange
=> prüfen ich, wenn die ergebnisse vorliegen
Ich verstehe nur Bahnhof.
@frank: Danke für's Nachstellen. Liegt's also nicht an mir und meiner Installation.
1. Habe auch meinen HM-LC-DIM1PWM-CV gecheckt: Anders als bei Gernott zeigt er hier das gleiche Verhalten, also keine Aktualisierung.
2. Gerade bei den logischen Kanälen wird eine Differenz von Kanal- und physischem Wert eher der Regelfall sein. Diese werden aber auch eher nicht zur tatsächlichen Visualisierung verwendet - bei mir schlummern sie irgendwo im Background.
3. wäre die Frage: ein statusRequest liefert doch einen phyLevel? und der ist für alle Kanäle gleich? Ein Request mehrerer Kanäle wäre dann doch eher sinnlos...
4. "wer ist gelistet": Ein laaaanger Rattenschwanz von Geräten, die eigentlich alle erreichbar sein sollten, aber offenbar nicht abgearbeitet werden.
Gleiches Problem? Ich werde die Liste mal abarbeiten.
@Pfriemler
a) kommando ausführen "on"
b) 5 sec warten
c)
{join("\n",sort grep/CUL_HM/,map{sprintf("%8d",int($intAt{$_}{TRIGGERTIME}-gettimeofday())).":$intAt{$_}{FN}\t$intAt{$_}{ARG}"} (keys %intAt))}
d)
{join(" ",@{$modules{CUL_HM}{helper}{qReqStat}})}
1) verstanden
2) klar
3) ja, StatusRequest liefert den physikalischen Level. Nur StatusRequest tut dies (wird ggf. vom Device automatisch geschickt)
ja, ist für alle virtuellen Kanäle gleich - muss ja. Phylikalisch ist: "Was an die Lampe geschickt wird". und es ist aja nur eine Lampe
Das Reading werden für alle Kanäle aktualisiert.
Schön (technisch) wäre eine "Physikalische" Entity - das hätte allerdings die Anwender erfahungsgemäß überfordert...
4) Offensichtlich hängt die StatusQueue, wenn die Liste so lang ist. Eigentlich sollte diese Q leer sein - nach einer min.
=> bei den Hängenden Devices in der Status-Q:
- sind die IOs operational?
- wie steht der Timer? Kommandos siehe oben
- autoreadreg=5_missing
- prefered io: cul868, kennt kein overload, batchlevel sollte also keine rolle spielen.
Zitat von: martinp876 am 14 Juni 2020, 09:11:54
a) kommando ausführen "on"
b) 5 sec warten
c)
{join("\n",sort grep/CUL_HM/,map{sprintf("%8d",int($intAt{$_}{TRIGGERTIME}-gettimeofday())).":$intAt{$_}{FN}\t$intAt{$_}{ARG}"} (keys %intAt))}
d)
{join(" ",@{$modules{CUL_HM}{helper}{qReqStat}})}
c.
0:CUL_HM_procQs CUL_HM_procQs
0:CUL_HM_valvePosUpdt valvePos:B5B5B501
30:CUL_HM_valvePosUpdt valvePos:B1B1B101
33:CUL_HM_valvePosUpdt valvePos:B6B6B601
91:CUL_HM_valvePosUpdt valvePos:B2B2B201
102:CUL_HM_valvePosUpdt valvePos:B3B3B301
150:CUL_HM_valvePosUpdt valvePos:B4B4B401
489:CUL_HM_ActCheck ActionDetector
1681:CUL_HM_qStateUpdatIfEnab sUpdt:SwitchPBU01_Sw_01
1682:CUL_HM_qStateUpdatIfEnab sUpdt:SwitchPBU01_Sw_02
37084:CUL_HM_statCntRfresh StatCntRfreshd. "DimPBU01" => der böse dimmer.
e.
autoReadReg :
recent : none
status request : DimPBU01
autoReadReg wakeup :
status request wakeup: Thermostat.AZ Thermostat.Bad Thermostat.Bad.OG Thermostat.GZ Thermostat.SZ Thermostat.WZ
autoReadTest :
hallo martin,
mal ein paar fragen zu den queues aus protoevent, siehe meinen vorherigen post:
1.
status request wakeup: Thermostat.AZ Thermostat.Bad Thermostat.Bad.OG Thermostat.GZ Thermostat.SZ Thermostat.WZ
warum werden die nicht abgearbeitet, oder besser: warum dauert das so lange? irgendwann ist diese queue leer, aber es dauert ewig und ich kenne keinen grund für dieses zögerliche verhalten.
ich denke die stehen da seit gestern wegen fhem restart plus autoreadreg=5. soweit ok.
aber warum bekommen die keinen statusrequest cmd in die cmd-queue gelegt, der dann beim nächsten wakeup gesendet wird? ich sollte doch pending cmds sehen können, oder nicht? seit dem restart sind mindestens 12 std vorbei und bei allen thermostaten, die noch in der queue zu sehen sind, wurde noch kein versuch gestartet (6 von 9).
eventuell hat das auch mit dem "klemmer" beim dimmer zu tun.
protoEvents send to devices done:
name :State |CmdPend |Snd |Resnd #CmdDel |ResndFail |Nack |IOerr
Thermostat.AZ : - | - | - | - # - | - | - | -
Thermostat.Bad : - | - | - | - # - | - | - | -
Thermostat.Bad.OG : - | - | - | - # - | - | - | -
Thermostat.GZ : - | - | - | - # - | - | - | -
Thermostat.Keller : done | - | 5 | 1 # - | - | - | -
Thermostat.Kueche : done | - | 7 | 1 # - | - | - | -
Thermostat.OZ : done | - | 5 | 1 # - | - | - | -
Thermostat.SZ : - | - | - | - # - | - | - | -
Thermostat.WZ : - | - | - | - # - | - | - | -
2. aus der timer tabelle:
1681:CUL_HM_qStateUpdatIfEnab sUpdt:SwitchPBU01_Sw_01
1682:CUL_HM_qStateUpdatIfEnab sUpdt:SwitchPBU01_Sw_02
warum finden sich diese requests nicht in der queue tabelle von protoevents?
eventuell solltest du eine weitere kategorie dort einfügen.
dieser switch hat ein problem wegen einem nicht vorhanden statusrequest-cmd in einem channel (unreachable).
allerdings wird alle 20 sekunden eine powermessage gesendet vom channel gesendet
3. was, wann und warum wird genau bei autoreadTest gemacht?
edit:
das rätsel aus punkt 1. habe ich herausgefunden.
das hat mit einer falschen io zuteilung nach fhem restart zu tun. näheres habe ich ausgelagert. siehe https://forum.fhem.de/index.php/topic,112117.0.html (https://forum.fhem.de/index.php/topic,112117.0.html)
Wieder der PWM-CV (EsstischDeckeLED)
Zitat von: martinp876 am 14 Juni 2020, 09:11:54
@Pfriemler
a) kommando ausführen "on"
b) 5 sec warten
c)
{join("\n",sort grep/CUL_HM/,map{sprintf("%8d",int($intAt{$_}{TRIGGERTIME}-gettimeofday())).":$intAt{$_}{FN}\t$intAt{$_}{ARG}"} (keys %intAt))}
Ja ne, nich 5s warten. Der statusRequest wird sofort als Timer gesetzt und nur wenn man unter 5s bleibt, erwischt man ihn noch in der Liste.
1:CUL_HM_qStateUpdatIfEnab sUpdt:EsstischDeckeLED
Zitat
d)
{join(" ",@{$modules{CUL_HM}{helper}{qReqStat}})}
leer (und bleibt leer, nachdem ich bei diversen temporär benutzten Geräten autoReadReg = 0 und clear msgEvents gemacht habe).
Zitat4) Offensichtlich hängt die StatusQueue, wenn die Liste so lang ist. Eigentlich sollte diese Q leer sein - nach einer min.
=> bei den Hängenden Devices in der Status-Q:
- sind die IOs operational?
- wie steht der Timer? Kommandos siehe oben
Die IOs sind bis auf temporäre Ausnahmen (das WLAN-Modul ist mehrmals am Tag kurz disconnectet, juckt mich schon nicht mehr) immer verfügbar und praktisch nie in Overload. Bezüglich der fraglichen Dimmer ohnehin unerheblich, weil die Schaltbefehle aus FHEM ja immer sauber abgearbeitet wurden.
Und das ist die Lösung: Mit leerem Queue scheinen die immer im Timer korrekt gesetzten statusRequests auch tatsächlich zeitnah prozessiert zu werden. Denn tatsächlich ändert sich der Status nach gut 5s jetzt stabil zu "on" bzw. "off", d.h. die Aktualisierung von phyLevel passiert nun. (Dass ein Slider im WebUI nicht aktualisiert wird, ist wohl eine andere Baustelle.)
Damit ist für mich auch klar, warum manche das nachstellen können und manche eben nicht.
Daraus entstehen bei mir zwei Änderungswünsche für die Zukunft:
1. temporär benutzte Geräte (wie etwa Zwischenstecker zum Messen oder für die Weihnachtsbeleuchtung) sollten ganz prinzipiell, nicht nur bei autoReadReag=0, nur eine bestimmte Zeitlang "angepiept" werden. Mit dem Setzen von "unreachable" sollten die Sendeversuche eingestellt und alle automatischen Kommunikationsversuche aus dem Cache gelöscht werden (also ein clear msgEvents) bis das Gerät wieder irgendein Lebenszeichen von sich gibt. Explizite Schaltbefehle sollten dennoch immer gesetzt werden, aber auch für sie sollte es sowas wie ein TimeOut geben. Sie gehören nach einer bestimmten Zeit genauso wie statusRequests oder getConfigs im Queue bei Überalterung entsorgt (imho).
NB: ich hatte hier gerade den Fall, dass ein HM-LC-Sw1-Ba-PCB nach drei Monaten Nichtbenutzung über Funk nicht mehr erreichbar war, weder über FHEM noch über Peers. Eingestromt war er die ganze Zeit. Eine lokale Tastenbetätigung hat ihn wieder verfügbar gemacht. Auch in diesem Fall war der ständige Versuch der Erreichbarkeit nicht nur nicht erfolgreich, sondern schlicht unnütz.
2. Ich weiß nicht, ob es im Queue irgendeine Prioritätenliste gibt, aber aktuelle statusRequests wegen Schaltfunktionen wie hier gehören für mich immer vorrangig prozessiert, egal wie voll der Queue tatsächlich ist. Im Moment sorgt nämlich eine weitab des fraglichen Dimmers verursachte Verstopfung offenbar für das eingangs monierte Verhalten. Kann man natürlich auch als Frühwarnsystem sehen: wenn sich der Status der Lampe nicht wie gewünscht ändert, besteht in FHEM Handlungsbedarf ;D ...
Zitatstatus request wakeup:
warum werden die nicht abgearbeitet, oder besser: warum dauert das so lange?
in dieser Queue sind nur devices welche nicht abgefragt werden können sondern welche selbst aufwachen und sich dann melden. So sie das tun wird das Kommando abgesetzt. Zu beachten ist, dass das device, so es etwas sendet nicht unbedingt auch der Zentrale mitteilt, dass es wach ist. Und erzwingen kann es die Zentrale nicht.
=> die Queue kann ewig hängen - bin ich machtlos. Dennoch wird jede Gelegenheit genutzt, es zu probieren.
=> die Verzögerung ist nicht gewünscht sondern notwendig.
=> manche Devices wachen einmal täglich auf.
Zitatwarum bekommen die keinen statusrequest cmd in die cmd-queue gelegt, der dann beim nächsten wakeup gesendet wird?
hatte ich dir schon erklärt: Diese Queues arbeiten im Hintergrund. Alle (ALLE) Manuell abgesetzten kommandos werden in die cmd-queue geschrieben. Status-updates "im Batch" werden getaktet ausgegeben. Bspw wird nach den Systemstart bei gesetzten AutoReadReg ein Statusrequest für jeden (JEDEN) channel abgesetzt, welcher statusrequest unterstützt. Das macht aus meiner sicht sinn (unabdingbar) da nach einem system-down dinge passiert sein können welche wir nicht mitbekommen haben. Das sind dann einige. Diese werden daher verzögert gesendet.
Zitatwarum finden sich diese requests nicht in der queue tabelle von protoevents?
Dieser Timer wirs aufgezogen, wenn ein Device nicht erreichbar war. Dann wird in 30min noch einmal probiert. Das kommt selten vor - ist quasi im back-background. Es werden nicht-erreichbare Devices gepollt. Sehr langsam!
Hier habe ich einen Bug gesehen - der Timer wird nicht immer gelöscht - kommt heute Abend.
Zitatdieser switch hat ein problem wegen einem nicht vorhanden statusrequest-cmd in einem channel (unreachable).
Was heist "nicht vorhandenes Kommando"? Ein Channel kann nicht unreachable sein, ein Device schon.
Zitatallerdings wird alle 20 sekunden eine powermessage gesendet vom channel gesendet
Power-Message? Meinst du power-up? Ist das Device defekt? Dann kann ich sicher wenig machen....
Zitatwas, wann und warum wird genau bei autoreadTest gemacht?
Commandref:
ZitatautoReadReg
'0' autoReadReg will be ignored.
'1' will execute a getConfig for the device automatically after each reboot of FHEM.
'2' like '1' plus execute after power_on.
'3' includes '2' plus updates on writes to the device
'4' includes '3' plus tries to request status if it seems to be missing
'5' checks reglist and peerlist. If reading seems incomplete getConfig will be scheduled
'8_stateOnly' will only update status information but not configuration data like register and peer
Execution will be delayed in order to prevent congestion at startup. Therefore the update of the readings and the display will be delayed depending on the size of the database.
Recommendations and constrains upon usage:
use this attribute on the device or channel 01. Do not use it separate on each channel of a multi-channel device to avoid duplicate execution
usage on devices which only react to 'config' mode is not recommended since executen will not start until config is triggered by the user
usage on devices which support wakeup-mode is usefull. But consider that execution is delayed until the device "wakes up".
So, zum Problem:
Ungünstig, dass ein device in der Queue ist und kein Timer zu sehen ist.
Zitatstatus request : DimPBU01
Zu sehen sein sollte
ZitatCUL_HM_procQs
im Timer
=> Ich gehe davon aus, dass die Logs quasi zeitgleich waren
Ich suche nach den verlorenen Timer. Nebenbei: Phys war nicht etwa schon gesetzt und korrekt?
Wie sieht das bei Pfriemler aus?
@Pfriemler: Ich komme noch nicht ganz mit
1)
ZitatMit leerem Queue scheinen die immer im Timer korrekt
welche Queue ist leer= Die Status-Request queue? Wenn es hier zu hängern kommt würde ich es gerne wissen und es optimieren. Diese Queue ist schnell, und es sollte in keinem Fall lange dauern, bis alle status eingeholt sind.
2)
ZitatMit dem Setzen von "unreachable" sollten die Sendeversuche
oder redest du von der msg Queue des device. Wenn hier kommandos hängen sollte man dies beheben - das ist FIFO Prinzip. Allerdings werden nach ein paar versuchen die messages gelöscht. Hier sollte sich nichts unabsehbar "stauen". Setzt du kommandos bei unreachable ab hängen diese, ok. Aber das sollte nicht dein Problem gewesen sein, der Aktor war reachable.
3)
ZitatSie gehören nach einer bestimmten Zeit genauso wie statusRequests
Es gehören schaltkommandos entsorgt - und konfigurations-kommandos. Allerdings Statusabfragen (Status-Request und getConfig) sollten bei wiederkehr ausgeführt werden. Sogar eigentlich zwingend. Das device muss bei wiederkehr kontrolliert werden.
4)
Zitatdass ein HM-LC-Sw1-Ba-PCB nach drei Monaten Nichtbenutzung über Funk
a) ich nutze den ActionDetector - manuell eingestelle - um alle Devices auf Erreichbarkeit abzuprüfen. Ich stelle 24h ein. Bekomme ich keine Nachricht setzt CUL_HM einen Statusrequest ab. Wird er nicht beantwortet wird das device als "dead" marktiert. => Über den activits state sehe ich damit (auch in HMInfo) alle nicht erreichbaren (toten) devices. Ausnahme sind remotes, welche nicht gepollt werden können.
b) in HMInfo haben ich einen "ping" eingebaut. Du kannst alle Devices auf erreichbarkeit prüfen. Alle? nein - nur alle welche in einem Kanal StatusRequest oder sysTime unterstützen. Ablauf: set hm clearG msgErrors;set hm cmdRequestG ping
wenn fertig sollte in allen readings "commState = CMDs_done" stehen
c) wenn das device hängt kann ich nichts machen, es nur orten.
zu 2)
die Prio ist, dass die StatusQ vorrang hat. es werden - wenn du über HMInfo keine Bremse einlegst - jede sec ein Kanal geprüft. Das ist eigentlich schon schnell und bedarf keiner weiteren priorisierung.
Vertopfung ist erwas anderes. Das darf nicht vorkommen. Kannst du mir details nennen, dann werde ich dies beheben. Hilfreiche info für mich
- welche Devices/Kanäle sind in der Queue?
- was verhindert das senden? IO-fehler, fehlendes IO, device antwortet nicht
ZitatSo, zum Problem:
Ungünstig, dass ein device in der Queue ist und kein Timer zu sehen ist.
Zitatstatus request : DimPBU01
Zu sehen sein sollte
ZitatCUL_HM_procQs
im Timer
=> Ich gehe davon aus, dass die Logs quasi zeitgleich waren
Ich suche nach den verlorenen Timer. Nebenbei: Phys war nicht etwa schon gesetzt und korrekt?
CUL_HM_procQs ist doch in der timerliste zu sehen, mit 0 sekunden ganz oben, also abgelaufen.
allerdings ist kein device zu sehen, sondern nur erneut der funktionsname.
das zeigt mir, dass da etwas schiefgegangen ist.
phys war noch falsch.
1. bevor phys falsch wird, also richtig ist, gibt es keinen CUL_HM_procQs timer in der liste.
2. wenn phys falsch ist und ich schnell genug die timerliste abrufe, findet sich dieser timer
1:CUL_HM_qStateUpdatIfEnab sUpdt:DimPBU01_chn013. erneuter timer listenabruf zeigt dann den "kaputten", abgelaufenen CUL_HM_procQs timer.
4. zum löschen des CUL_HM_procQs timers reicht kein manueller set statusrequest.
erst nach clear msgEvents wird der timer aus der liste genommen.
1. frank meint - vermutlich - seinen Sw1PBU mit alternativer Firmware. Die hat Probleme mit statusRequest (reagiert nicht darauf), sendet aber - wie ein Powermonitor - alle 20 Sekunden ein POWER_EVENT zum Strom über den Aktor - der hat ja einen Stromsensor eingebaut, der mit der Werksfirmware aber brach liegt. Das als Erläuterung.
zu mir.
Zitatwelche Queue ist leer= Die Status-Request queue? Wenn es hier zu hängern kommt würde ich es gerne wissen und es optimieren. Diese Queue ist schnell, und es sollte in keinem Fall lange dauern, bis alle status eingeholt sind.
Ja, also ich denke doch, dass das
Zitat{join(" ",@{$modules{CUL_HM}{helper}{qReqStat}})}
der statusRequest-Queue ist. Und der ist eben - nach dem manuellen Killen - jetzt leer und alles, was dort auftaucht, wird offenbar zügig abgearbeitet, also auch die statusRequest an die Dimmer beim on/off/toggle.
Dort hatte ich aber vorher zum Teil unerreichbare Geräte - ich experimentiere hier gerade mit einigen Geräten herum und sie sind nur sporadisch am Stromnetz. Die Liste führte so ein "unreachable" an, aber weiter hinten waren lauter Geräte, die durchaus erreichbar sind (ein 4-Kanal-Hutschienenaktor, Rauchmelder etc.). FHEM hatte sich offenbar an dem unerreichbaren festgebissen und die anderen solange ignoriert. Denn als ich dessen statusRequest (ich nehme noch mal an, mit einem clear msgEvents lösche ich auch statusRequests?) so gekillt hatte, war die Liste ratzfatz leer.
Ich versuche das nochmal nachzustellen, aber nicht heute oder morgen.
ZitatEs gehören schaltkommandos entsorgt - und konfigurations-kommandos. Allerdings Statusabfragen (Status-Request und getConfig) sollten bei wiederkehr ausgeführt werden. Sogar eigentlich zwingend. Das device muss bei wiederkehr kontrolliert werden.
Da sind wir uns doch einig: bei Wiederkehr. Es werden aber - bei autoReadReg - auch ständig und beinahe penetrant getConfigs an Geräte gesendet,
2020.06.14 14:27:54 3: CUL_HM set HM_376BB2 statusRequest
2020.06.14 14:27:56 3: CUL_HM set HM_414004_Dim statusRequest
2020.06.14 14:27:57 3: CUL_HM set HM_49E7AB statusRequest
2020.06.14 14:27:58 3: CUL_HM set HM_Universalschalter2 statusRequest
weitab jedes FHEM-Neustarts oder irgendwelcher powerOns der Geräte) die schon lange down sind, was längst bekannt sein sollte.
Ich würde erwarten, dass neue statusRequests erst gesendet werden, wenn sich das Gerät irgendwie selbst gemeldet hat.
Und der ActionDetector auf den HM-LC-Sw-BA-PCB manuell ... ja, das hätte mir mitgeteilt, dass das Gerät nicht antwortet. Aber der hing auch so mit MISSING_ACK im Status, trotzdem wurde weiter munter versucht ihn zu erreichen, offenbar über Monate. Nutzlos, weil er eben nie von allein aufgewacht wäre.
Ok, mit dem Timer hast du Recht. Schief gegangen ist da nichts, der Timer funktioniert anders.
Wenn der Timer abgelaufen ist sollte der Eintrag getilgt werden und der statusrequest gesendet!
1) so schnell bist du nicht. Der Eintrag wird so 1s in der q verweilen. Die Wartezeit von 5s vorher hat einen anderen Hintergrund und ist nicht in der q zu sehen.
Das mit phys falsch wird und richtig ist verstehe ich nicht.
2) korrekt. Du hast 5s zeit.
So soll es sein
3) da ist nichts kaputt
4) auch klar. Wird statusrequest manuell aufgerufen wird der Eintrag in der q gelöscht. Keine unnötigen Messages. So ist es gedacht.
Bleibt die Frage ob und warum die q bei dir hängt. Also
A) hängt die q dauerhaft?
B) wenn's hängt bitte ein list des device ( nicht Channel)
C) mehrfach den Timer prüfen. Steht der immer auf 0? Über längere Zeit?
D) ein list des Io device welches zugewiesen ist. Das ist das wahrscheinliche Problem!
ich werd verrückt! :)
meine blockade wird durch den cul verursacht.
sobald ich den hmlan als prefered io setze, kommt umgehend der automatische status request und alles ist gut.
erneutets ändern auf cul und schon blockiert es wieder.
@martin
die andere blockade in der vccu zum statusrequest-wakeup timer hast du gesehen?
siehe mein neuer vccu-problem-thread.
Bei Frank tippe ich aktuell auf ein mir neues Io. Ich werde sehen.
Bei dir gehen ich davon aus, dass klemmende devices mit der neusten SW dies nicht mehr tun. Devices hängen, wenn es Probleme mit dem Io gibt.
Ist das Io funktional wird gesendet. Möglich, dass keine Antwort kommt. Dann eben Fehler.
Das hängen wegen Io Problemen ist seit ein paar Tagen Geschichte. Natürlich hängen die devices mit Io Problemen. Die anderen aber nicht.
Bei nicht reagierenden devices wird alle30min gepolt. Halte ich für vertretbar. Das ist kein config sondern statusrequest. Es wird keinen overload auslösen, also ok.
Über attr ignore kannst du das device ignorieren lassen
@frank
Hatte ich mittlerweile vermutet. Bitte ein list der cul. Meine ist mittlerweile Schrott. Ich kann es nicht mehr testen
list von cul und vccu
Internals:
CMDS BCFiAZEGMKURTVWXefmltux
Clients :CUL_HM:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
DEF /dev/serial/by-id/usb-busware.de_CUL868-if00@38400 0000
DeviceName /dev/serial/by-id/usb-busware.de_CUL868-if00@38400
FD 59
FHTID 0000
FUUID 5c4ce2ef-f33f-09c4-2286-e28f74f38d805cca
NAME cul868
NR 647
NR_CMD_LAST_H 24
PARTIAL
RAWMSG A0C0F867020621900000000A456EF
RSSI -82.5
STATE Initialized
TYPE CUL
VERSION V 1.58 CUL868
cul868_MSGCNT 2044
cul868_TIME 2020-06-14 21:03:46
initString X21
Ar
owner_CCU ccu
.attraggr:
.attrminint:
.clientArray:
CUL_HM
MatchList:
1:CUL_HM ^A....................
8:HMS ^810e04....(1|5|9).a001
D:CUL_IR ^I............
H:STACKABLE_CC ^\*
M:TSSTACKED ^\*
N:STACKABLE ^\*
READINGS:
2018-08-12 13:50:22 ccconf freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
2020-06-14 18:17:22 cmds B C F i A Z E G M K U R T V W X e f m l t u x
2020-06-14 21:03:46 state Initialized
2018-01-29 14:42:06 version V 1.58 CUL868
XMIT_TIME:
1592157785.94077
1592157943.24042
1592158085.11538
1592158280.55812
1592158460.31651
1592158624.6466
1592158773.29137
1592158906.23668
1592159093.01914
1592159263.84846
1592159419.24889
1592159559.24259
1592159752.77648
1592159930.63794
1592160092.8039
1592160239.55735
1592160370.61355
1592160535.23338
1592160555.23906
1592160724.43754
1592160877.95221
1592161015.77411
1592161207.11594
1592161383.08383
helper:
1F64D8:
QUEUE:
20DFE1:
QUEUE:
266A86:
QUEUE:
6869B6:
QUEUE:
Attributes:
group IO-Devices
hmId 1ACE1F
model CUL
rfmode HomeMatic
room 90_Technik
Internals:
CHANGED
DEF 1ACE1F
FUUID 5c4ce2e8-f33f-09c4-c674-df552a0e9d590f71
IODev hmlan1
LASTInputDev hmlan1
MSGCNT 259
NAME ccu
NOTIFYDEV global
NR 47
NTFY_ORDER 50-ccu
STATE hmuart1:disconnected,hmlan1:ok,hmusb1:dummy,cul868:ok
TYPE CUL_HM
assignedIOs cul868,hmlan1,hmuart1,hmusb1
channel_01 ccu_Btn1
channel_02 ccu_Btn2
channel_03 ccu_Btn3
channel_04 ccu_Btn4
channel_05 ccu_Btn5
cul868_MSGCNT 116
cul868_RAWMSG A0FA9943F1ACE1F00000002042679303F::-53.5:cul868
cul868_RSSI -53.5
cul868_TIME 2020-06-14 21:00:15
hmlan1_MSGCNT 143
hmlan1_RAWMSG E1ACE1F,0000,3548CE4E,FF,FFCC,E080021ACE1F6869B600
hmlan1_RSSI -52
hmlan1_TIME 2020-06-14 21:05:43
lastMsg No:E0 - t:02 s:1ACE1F d:6869B6 00
protLastRcv 2020-06-14 21:05:43
protRcv 238 last_at:2020-06-14 21:05:43
protRcvB 11 last_at:2020-06-14 21:00:15
rssi_at_cul868 cnt:116 min:-55 max:-51.5 avg:-54.73 lst:-53.5
rssi_at_hmlan1 cnt:143 min:-52 max:-41 avg:-50.85 lst:-52
.attraggr:
.attreocr:
.*
.attreour:
system_attack
.attrminint:
.attrtocr:
.*
READINGS:
2020-06-14 21:05:43 .protLastRcv 2020-06-14 21:05:43
2019-05-22 12:36:21 CommandAccepted yes
2020-06-14 18:19:54 IOopen 2
2019-11-09 16:52:49 aesKeyNbr 00
2019-11-09 16:53:22 aesReqTo Tuer.SZ
2020-05-25 14:28:46 commState CMDs_done
2020-04-23 11:25:24 fhemuptime_text_last 8 days, 19 hours, 20 minutes
2020-04-23 11:25:38 fork ok
2020-06-14 20:58:09 hmlan1_Load 7
2019-10-29 10:54:49 hmuart1_Load ???
2019-05-22 12:36:15 hmusb1_Load 0
2020-06-14 18:19:58 init off
2019-05-13 17:51:19 rt0_hmuart1 0.0030
2020-06-14 18:19:54 state hmuart1:disconnected,hmlan1:ok,hmusb1:dummy,cul868:ok
2020-06-04 18:30:05 system_attack off
2020-06-05 16:33:36 unknown_1454E2 received
2020-06-02 13:00:12 unknown_36834C received
2020-05-18 12:39:33 unknown_3AC6F1 received
2020-05-18 03:14:42 unknown_3AE18A received
2020-06-11 11:31:13 unknown_400624 received
helper:
HM_CMDNR 224
mId FFF0
peerFriend peerSens,peerAct
peerOpt -:virtual
regLst 0
rxType 1
supp_Pair_Rep 0
ack:
cmds:
TmplKey :1592151590.91496:1592151590.93281
TmplTs 1592151590.93281
cmdKey :0:1:1::FFF0:01
TmplCmds:
cmdList:
assignHmKey:
assignIO:-IO- [set|unset]...
clear:[readings|rssi|msgErrors|msgErrors|unknownDev]
defIgnUnknown:
deviceRename:newName
fwUpdate:-filename- -bootTime- ...
getDevInfo:
hmPairForSec:-sec- ...
hmPairSerial:-serial-
peerSmart:[DimPBU01_Sw1_V01|DimPBU01_Sw1_V02|DimPBU01_chn01|DimUP01|Fenster.Bad|HM_114B05|SwitchES01_SenF|SwitchES01_SenI|SwitchES01_SenPwr|SwitchES01_SenU|SwitchES01_Sw|SwitchPBU01_Btn_01|SwitchPBU01_Btn_02|SwitchPBU01_Sw_01|SwitchPBU01_Sw_02|SwitchPBU02_Btn_01|SwitchPBU02_Btn_02|SwitchPBU02_Sw_01|SwitchPBU02_Sw_02|SwitchPBU03|SwitchPBU04|SwitchPBU05|SwitchPBU06|SwitchPBU08|SwitchPBU09|SwitchUP01|SwitchUP02|Tuer.SZ|Tuer.WZ.Terrasse]
raw:data ...
reset:
unpair:
update:
virtual:-noButtons-
expert:
def 1
det 0
raw 0
tpl 0
io:
nextSend 1592161543.2735
vccu ccu
ioList:
hmuart1
hmlan1
hmusb1
cul868
prefIO:
hmlan1
mRssi:
mNo E0
io:
cul868:
hmlan1:
-46
-46
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
dev 1
vrt 1
rssi:
at_cul868:
avg -54.7327586206896
cnt 116
lst -53.5
max -51.5
min -55
at_hmlan1:
avg -50.8531468531469
cnt 143
lst -52
max -41
min -52
shadowReg:
tmpl:
Attributes:
.mId FFF0
IODev hmlan1
IOList hmuart1,hmlan1,hmusb1,cul868
IOgrp ccu:hmlan1
event-on-change-reading .*
event-on-update-reading system_attack
group IO-Devices
model CCU-FHEM
room 90_Technik
subType virtual
timestamp-on-change-reading .*
webCmd virtual:update
Es ist wie verhext. Zwei Dimmer, einer mit autoReadReg 4_, einer mit 0. Mal eingesteckt, mal nicht.
Ich kriege keinen Stau im statusRequest-Queue mehr provoziert...
hast du denn nun das update?
wenn du noch kein update hast, und die gefixte blockade1 die ursache war, ist hier die anleitung zum installieren der blockade. https://forum.fhem.de/index.php/topic,107137.msg1060771.html#msg1060771 (https://forum.fhem.de/index.php/topic,107137.msg1060771.html#msg1060771)
Zitat von: frank am 15 Juni 2020, 18:02:49
hast du denn nun das update?
Ich hab nichts neueres als vom 2.6.
Interessante Sache, werde ich mal morgen nachstellen. edit: Mist, ich habe mein System bei einer Kopieroperation in die falsche Richtung zerschossen und habe es mit einem Update repariert. Kann es also nicht mehr nachstellen...
nun, ist ok nicht zu reproduzieren.
Habe gerade ein weiteres Update eingestellt:
- CUL liefert einen Status nicht, welchen in abgefragt habe. Jetzt sollte CUL immer senden.
- es hätte m.E. vorkommen können, dass ein Senden des Status in einer schnellen endlos-schleife läuft. Ist nun sinnvoll gedrosselt. Wahrscheinlichkeit des Auftretens: (sehr) gering
ok,
der automatische statusrequest kommt nun auch beim cul.