Dimmer: keine Aktualisierung von phyLevel bei on/off/toggle -> chn:xx phys:xx

Pfriemler · 10 Juni 2020, 20:45:34

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?

martinp876 · 13 Juni 2020, 07:42:27

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.

Pfriemler · 13 Juni 2020, 12:51:21

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:

Code Auswählen

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.

Code Auswählen

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...

Code Auswählen

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

martinp876 · 13 Juni 2020, 14:28:18

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?

Pfriemler · 13 Juni 2020, 15:42:09

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.

martinp876 · 13 Juni 2020, 16:33:22

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

Pfriemler · 13 Juni 2020, 18:00:00

Ich helf ja gern beim Mitsuchen, aber 10_CUL_HM ist nicht gerade mein Heimatland

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.

frank · 13 Juni 2020, 18:31:56

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.

Pfriemler · 13 Juni 2020, 21:21:42

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, ...

Gernott · 13 Juni 2020, 23:26:58

Ich habe hier gerade mal mit einem HM-LC-DIM1PWM-CV herumgespielt. Es werden alle Readings korrekt aktualisiert.

frank · 13 Juni 2020, 23:58:04

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"

Code Auswählen

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.

Code Auswählen

    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.

martinp876 · 14 Juni 2020, 08:10:16

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

Code Auswählen

{join("\n",sort grep/CUL_HM/,map{sprintf("%8d",int($intAt{$_}{TRIGGERTIME}-gettimeofday())).":$intAt{$_}{FN}\t$intAt{$_}{ARG}"} (keys %intAt))}

1b) wer ist gelistet

Code Auswählen

{join(" ",@{$modules{CUL_HM}{helper}{qReqStat}})}
2) timer: ist die Wartezeit zu lange
=> prüfen ich, wenn die ergebnisse vorliegen

Pfriemler · 14 Juni 2020, 08:57:31

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.

martinp876 · 14 Juni 2020, 09:11:54

@Pfriemler
a) kommando ausführen "on"
b) 5 sec warten
c)

Code Auswählen

{join("\n",sort grep/CUL_HM/,map{sprintf("%8d",int($intAt{$_}{TRIGGERTIME}-gettimeofday())).":$intAt{$_}{FN}\t$intAt{$_}{ARG}"} (keys %intAt))}

d)

Code Auswählen

{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

frank · 14 Juni 2020, 10:24:56

- 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)
Code Auswählen Erweitern
{join("\n",sort grep/CUL_HM/,map{sprintf("%8d",int($intAt{$_}{TRIGGERTIME}-gettimeofday())).":$intAt{$_}{FN}\t$intAt{$_}{ARG}"} (keys %intAt))}
d)
Code Auswählen Erweitern
{join(" ",@{$modules{CUL_HM}{helper}{qReqStat}})}

c.

Code Auswählen

       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	StatCntRfresh

d. "DimPBU01" => der böse dimmer.

e.

Code Auswählen

    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         :