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

[frank]

hallo martin,
mal ein paar fragen zu den queues aus protoevent, siehe meinen vorherigen post:

1.

Code Auswählen Erweitern

    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.

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

    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

[Pfriemler]

Wieder der PWM-CV (EsstischDeckeLED)

@Pfriemler
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))}

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.

Code Auswählen Erweitern

      1:CUL_HM_qStateUpdatIfEnab sUpdt:EsstischDeckeLED


d)

Code Auswählen Erweitern

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

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

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

[martinp876]

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

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

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

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

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

was, wann und warum wird genau bei autoreadTest gemacht?

Commandref:

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

status request       : DimPBU01

Zu sehen sein sollte

CUL_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?

[martinp876]

@Pfriemler: Ich komme noch nicht ganz mit
1)

Mit 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)

Mit 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)

Sie 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)

dass 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

[frank]

So, zum Problem:
Ungünstig, dass ein device in der Queue ist und kein Timer zu sehen ist.

status request       : DimPBU01

Zu sehen sein sollte

CUL_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

Code Auswählen Erweitern

1:CUL_HM_qStateUpdatIfEnab sUpdt:DimPBU01_chn01

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

[Pfriemler]

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.

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.

Ja, also ich denke doch, dass das

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

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.

Da sind wir uns doch einig: bei Wiederkehr. Es werden aber - bei autoReadReg - auch ständig und beinahe penetrant getConfigs an Geräte gesendet,

Code Auswählen Erweitern

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.

[martinp876]

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!

[frank]

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.

[martinp876]

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

[martinp876]

@frank
Hatte ich mittlerweile vermutet. Bitte ein list der cul. Meine ist mittlerweile Schrott. Ich kann es nicht mehr testen

[frank]

list von cul und vccu

Code Auswählen Erweitern

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

Code Auswählen Erweitern

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

[Pfriemler]

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

[frank]

hast du denn nun das update?

[frank]

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

[Pfriemler]

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