Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.41

[noansi]

Hallo Cube,

ich habe hier https://forum.fhem.de/index.php/topic,24436.msg891756.html#msg891756 die FHEM Module aktualisiert, um undefinierte PrioQueue Funktionsaufrufe abzufangen.

Ich habe 10_MQTT2_DEVICE.pm möglicherweise in Verbindung mit der perl Version in Verdacht. Daher antworte bitte noch auf meine Fragen oben.

Gruß, Ansgar.

[noansi]

Hallo Zusammen,

ich habe hier https://forum.fhem.de/index.php/topic,24436.msg891756.html#msg891756 die FHEM Module nochmals aktualisiert weil ich feststellen musste, dass PrioQueues gar nicht korrekt abgearbeitet wurden.

Das fällt aber nur auf, wenn 10_MQTT2_DEVICE.pm zur Anwendung kommt, was ggf. schon mit aktivem autocreate unbewust passieren kann.

Gruß, Ansgar.

[Cube]

Einzige Verwendung von Prioritätswarteschlangen finde ich in 10_MQTT2_DEVICE.pm Zeile 167ff.
Verwendest Du MQTT2_DEVICE?
Hast Du autocreate aktiv?
Welche perl Version verwendest Du?

Ja, ich verwende MQTT2_DEVICE für zigbee2mqtt. Autocreate ist aktiv, neue Geräte sind aber nicht hinzugekommen. Ich habe allerdings an dem Tag, an dem das Problem aufgetreten ist, zigbee2mqtt aktualisiert und Einstellungen geändert. Ich verwende Perl v5.24.1.

ich habe hier https://forum.fhem.de/index.php/topic,24436.msg891756.html#msg891756 die FHEM Module nochmals aktualisiert weil ich feststellen musste, dass PrioQueues gar nicht korrekt abgearbeitet wurden.

Ich habe die Module aktualisiert und der Fehler tritt nicht mehr auf. Super. 

[noansi]

Hallo Cube,

danke!

Hier https://forum.fhem.de/index.php/topic,97159.msg903510.html#msg903510 hoffe ich mal, dass Rudolf es liest und in fhem.pl ebenfalls Veränderungen vornimmt.

Gruß, Ansgar.

[noansi]

Hallo Zusammen,

wie ab hier https://forum.fhem.de/index.php/topic,97159.msg903956.html#msg903956 in Diskussion mit Rudolf zu lesen ist, tritt das oben genannte potentielle Crash Problem nur mit der bisherigen Version von timerTS auf.

Also bitte die aktuellen Module mit aktueller Firmware nutzen https://forum.fhem.de/index.php/topic,24436.msg891756.html#msg891756.

Gruß, Ansgar.

[ram]

Hallo.

Hallo ram,
danke für's Feedback.

gerne!

Was hatte den der alte CUL3.x für eine Krankheit?
Nutzt Du den CUL auch, um 433.92MHz Geräte zu schalten?
Gruß, Ansgar.

Ich denke die alte CUL hat einen Hardwareschaden... könnte eine Spannungspitze gewesen sein Jedenfalls sendet sie nicht mehr (SDR gecheckt), meldet aber auch kein CCA Fehler.

Für 433 MHz habe ich eine weitere CUL.

Ich habe aber aktuell ein einziges HM-Gerät, mit welchem wohl die Kommunikation nicht mehr funktioniert. FHEM scheint das Gerät nicht mehr pairen zu können. Ich weiss aber nicht, ob das ein "normales" Problem, z.B. Abstand CUL/Antenne zu HM-Gerät ist, oder doch ggf. auch etwas mit der tsculfw zu tun haben könnte.

Code Auswählen Erweitern


...
2019.02.11 20:52:54 3 : TSCUL_ParseTsHM: CUL_868 HM repeat failed to 543764/HM_543764: 433222 A F109 14603916 00 10 31 A001 54F2B3 543764 00040000000000 _sfail _noAnsw
2019.02.11 20:52:56 4 : TSCUL_XmitAwaitHMTo CUL_868: timeout - 543764
2019.02.11 20:52:59 4 : TSCUL_send: CUL_868 437999 As 10 31 A001 54F2B3 543764 00040000000000
2019.02.11 20:52:59 4 : TSCUL_XmitDlyHM: CUL_868 id:543764 rtoms:2328
2019.02.11 20:52:59 4 : TSCUL_Parse: CUL_868 438036 A F103 14608700 02 10 31 A001 54F2B3 543764 00040000000000 _CCAdly:8
2019.02.11 20:52:59 4 : TSCUL_Parse: CUL_868 438309 A F103 14608972 01 10 31 A001 54F2B3 543764 00040000000000 _CCAdly:4
2019.02.11 20:52:59 4 : TSCUL_Parse: CUL_868 438581 A F103 14609244 01 10 31 A001 54F2B3 543764 00040000000000 _CCAdly:4
2019.02.11 20:53:00 3 : LogHist CUL_868: 427277 As 10 31 A001 54F2B3 543764 00040000000000
2019.02.11 20:53:00 3 : LogHist CUL_868: 427315 A F103 14597976 01 10 31 A001 54F2B3 543764 00040000000000 _CCAdly:4
2019.02.11 20:53:00 3 : LogHist CUL_868: 427589 A F103 14598252 01 10 31 A001 54F2B3 543764 00040000000000 _CCAdly:4
2019.02.11 20:53:00 3 : LogHist CUL_868: 427861 A F103 14598524 01 10 31 A001 54F2B3 543764 00040000000000 _CCAdly:4
2019.02.11 20:53:00 3 : LogHist CUL_868: 428098 A F109 14598792 00 10 31 A001 54F2B3 543764 00040000000000 _sfail _noAnsw
2019.02.11 20:53:00 3 : LogHist CUL_868: 432403 As 10 31 A001 54F2B3 543764 00040000000000
2019.02.11 20:53:00 3 : LogHist CUL_868: 432440 A F103 14603104 02 10 31 A001 54F2B3 543764 00040000000000 _CCAdly:8
2019.02.11 20:53:00 3 : LogHist CUL_868: 432713 A F103 14603376 01 10 31 A001 54F2B3 543764 00040000000000 _CCAdly:4
2019.02.11 20:53:00 3 : LogHist CUL_868: 432985 A F103 14603648 01 10 31 A001 54F2B3 543764 00040000000000 _CCAdly:4
2019.02.11 20:53:00 3 : LogHist CUL_868: 433222 A F109 14603916 00 10 31 A001 54F2B3 543764 00040000000000 _sfail _noAnsw
2019.02.11 20:53:00 3 : LogHist CUL_868: 437999 As 10 31 A001 54F2B3 543764 00040000000000
2019.02.11 20:53:00 3 : LogHist CUL_868: 438036 A F103 14608700 02 10 31 A001 54F2B3 543764 00040000000000 _CCAdly:8
2019.02.11 20:53:00 3 : LogHist CUL_868: 438309 A F103 14608972 01 10 31 A001 54F2B3 543764 00040000000000 _CCAdly:4
2019.02.11 20:53:00 3 : LogHist CUL_868: 438581 A F103 14609244 01 10 31 A001 54F2B3 543764 00040000000000 _CCAdly:4
2019.02.11 20:53:00 3 : TSCUL_ParseTsHM: CUL_868 HM repeat failed to 543764/HM_543764: 438818 A F109 14609512 00 10 31 A001 54F2B3 543764 00040000000000 _sfail _noAnsw
2019.02.11 20:53:01 4 : TSCUL_XmitAwaitHMTo CUL_868: timeout - 543764


Mir sagt das "raw" Log aber leider nicht viel

Viele Grüße
Reza

[noansi]

Hallo Reza,

das log sagt, Du sendest an das Gerät mit der ID 543764 (immer wieder 3x), aber es antwortet nicht, bzw. CUL empfängt keine Antwort.

Entweder es ist außer Reichweite (eventuell ist der neue CUL etwas schlechter, als der alte) oder es ist defekt oder die Batterien sind leer/zu schwach.
Oder es schläft schon wieder und du musst eventuell immer wieder das Knöpfchen drücken.
Mehr Infos zum Gerät erhellen meist die Glaskugel.

Gruß, Ansgar.

[noansi]

Hallo Zusammen,

ich habe die Module nochmals aktualisiert https://forum.fhem.de/index.php/topic,24436.msg891756.html#msg891756.
Ich habe aus den letzten Testerfahrungen heraus unnötige use vars rausgeworfen.

Gruß, Ansgar.

[ram]

Hallo Ansgar,

Hallo Reza,

das log sagt, Du sendest an das Gerät mit der ID 543764 (immer wieder 3x), aber es antwortet nicht, bzw. CUL empfängt keine Antwort.

Entweder es ist außer Reichweite (eventuell ist der neue CUL etwas schlechter, als der alte) oder es ist defekt oder die Batterien sind leer/zu schwach. Oder es schläft schon wieder und du musst eventuell immer wieder das Knöpfchen drücken.

Würde mich tatsächlich nicht wundern, wenn das Geräte und nicht die CUL ein Problem hat. Konnte ich aber nicht unterscheiden, und daher habe ich gerne das Log angeboten.

Mehr Infos zum Gerät erhellen meist die Glaskugel.

Gruß, Ansgar.

Okay.. etwas mehr Licht in der Glaskugel

Code Auswählen Erweitern


Internals:
   CFGFN     
   CUL_868_MSGCNT 7
   CUL_868_RAWMSG A0D38841054376400000006010000::-58.5:CUL_868:
   CUL_868_RSSI -58.5
   CUL_868_TIME 2019-02-11 21:01:16
   DEF        543764
   IODev      CUL_868
   LASTInputDev CUL_868
   MSGCNT     7
   NAME       HM_543764
   NOTIFYDEV  global
   NR         311
   STATE      MISSING ACK
   TYPE       CUL_HM
   lastMsg    No:38 - t:10 s:543764 d:000000 06010000
   protCmdDel 8
   protLastRcv 2019-02-11 21:01:16
   protResnd  12 last_at:2019-02-11 21:26:43
   protResndFail 4 last_at:2019-02-11 21:26:48
   protSnd    6 last_at:2019-02-11 21:26:27
   protState  CMDs_done_Errors:1
   rssi_CUL_868 min:-52 lst:-52 avg:-52 max:-52 cnt:1
   rssi_at_CUL_868 min:-58.5 lst:-58.5 avg:-55.99 cnt:7 max:-53
   READINGS:
     2019-02-11 20:44:19   D-firmware      2.8
     2019-02-11 20:44:19   D-serialNr      OEQ0181580
     2019-02-11 21:28:14   RegL_00.       
     2019-02-11 21:01:16   deviceMsg       off (to broadcast)
     2019-02-11 21:01:16   level           0
     2019-02-11 21:01:16   pct             0
     2019-02-11 21:01:16   recentStateType info
     2019-02-11 21:26:48   state           MISSING ACK
     2019-02-11 21:01:16   timedOn         off
   helper:
     HM_CMDNR   57
     cSnd       0154F2B354376400040000000000,1154F2B35437640201C80000
     dlvl       C8
     dlvlCmd    ++A01154F2B35437640201C80000
     getCfgList all
     getCfgListNo ,3
     mId        0069
     regLst     ,0,1,3p
     rxType     1
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       lstRecType 10
       newChn     +543764,00,00,00
       nextSend   1549915276.34045
       nxtSndMcnt 38
       prefIO     
       rxt        0
       tgtDly     88
       vccu       VCCU
       lRcTm:
         CUL_868    300318260
         tnms       505824220
       p:
         543764
         00
         00
         00
     mRssi:
       mNo        38
       io:
         CUL_868:
           -52.5
           -52.5
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       prs        1
     rssi:
       CUL_868:
         avg        -52
         cnt        1
         lst        -52
         max        -52
         min        -52
       at_CUL_868:
         avg        -56
         cnt        7
         lst        -58.5
         max        -53
         min        -58.5
     tmpl:
Attributes:
   IODev      CUL_868
   IOgrp      VCCU
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   2.8
   model      HM-LC-Sw1PBU-FM
   room       CUL_HM
   serialNr   OEQ0181580
   subType    switch
   webCmd     statusRequest:toggle:on:off


[noansi]

Hallo Reza,

also Du hast heute schon was von dem device empfangen (21:01:16), siehe readings und der RSSI ist auch nicht schlecht.
Der Register Read misslingt aber offenbar.

Das Pairing war wohl nicht erfolgreich und daher fühlt er sich eventuell nicht angesprochen.

Hast Du das Pairing korrekt angestoßen?

Das Pairing war nicht im Logauszug, nur der Registerreadversuch von FHEM.

Pairing mit Serienummer kannst Du auch mal probieren.

Gruß, Ansgar.

[Bastel-Frank]

Hallo Ansgar,

meine Installation mit den mittlerweile 6 CUL's läuft sehr gut  .

Mir ist jetzt aufgefallen, dass nach einem Reboot des fhem-Servers das Attribut "rfmode = Homematic" nicht mehr gesetzt wurde, d.h. das Attribut war nicht mehr definiert. Dies führte (anscheinend) dazu, dass die Kommunikation nicht mehr sauber lief. Es kam zu Aussetzern und nicht erreichbaren Devices. Hinweis: Bei einem "shutdown restart" hingegen bleibt "rfmode" erhalten.
Hast Du eine Idee dazu?

Viele Grüße
Frank

[noansi]

Hallo Frank,

Mir ist jetzt aufgefallen, dass nach einem Reboot des fhem-Servers das Attribut "rfmode = Homematic" nicht mehr gesetzt wurde, d.h. das Attribut war nicht mehr definiert.

Nur wenn in dem Fall die Kommunikation bei der CUL Initialisierung nicht sauber laufen würde, dann könnte es passieren, dass das Attribut nicht gesetzt wird. Dann würde beim CUL cmds kein A enthalten oder die Version nicht gelesen werden können und VERSION_TS wäre nicht yes.
Ein List nach dem Reboot könnte mehr Klarheit bringen.

Dein fhem-server läuft auf was für einem System?
Bei einem Raspi können die USB Schnittstellzuordnungen bei Reboot anders sein, als bei Runterfahren und Abschalten mit anschließendem Einschalten. Das ist nur mit 99-usb-serial.rules mit eindeutiger Seriennummerzuordnung gelöst werden. USB-Ports sind nach meiner Erfahrung nicht eindeutig. Dann können andere serielle USB devices unerwartet auf den CUL Schnittstellen landen.

Gruß, Ansgar.

[Bastel-Frank]

Hallo Ansgar,

der fhem-Server läuft auf Ubuntu 18.10. Nochmal zur Erinnerung: Meine CULs (bis auf Einen) sind per ser2net von externen Raspi's angebunden.

List eines mit ser2net angebundenen CULs:

Code Auswählen Erweitern

Internals:
   CMDS       ABCEFGJKMNRUVWXYZeilmtx
   Clients    STACKABLETS:STACKABLE:TSCUL_WS:IT:CUL_FHTTK:CUL_HOERMANN:TSCUL_TX:CUL_IR:SOMFY:Revolt:ESA2000:TSCUL_EM:BS:USF1000:FS20:FHT.*:TSKS300:HMS:CUL_TCM97001:CUL_REDIRECT
   DEF        raspi-og:2003 1447
   DeviceName raspi-og:2003
   FD         389
   FHTID      1447
   FUUID      5c813716-f33f-3d91-1023-56993d29182ce4a6
   NAME       CUL_OG
   NR         287
   PARTIAL   
   RAWMSG     
   STATE      Initialized
   SlowRF_BitBufferOvrfl 0
   SlowRF_BucketOvrfl 0
   TYPE       TSCUL
   VERSION    VTS 0.29 CSM868
   VERSION_HW nanoCUL_V1.x
   VERSION_TS yes AES ChTblSize:220
   XmitOpen   0
   assignedIDsCnt 18
   initString X21
AM5
AH738396
   owner_CCU  vccu
   MatchList:
     1:STACKABLETS ^\*
     2:STACKABLE ^\*
     A:TSCUL_WS ^K.....
     B:IT       ^i.(:.|.....)
     C:CUL_FHTTK ^T[\dA-F][\dA-F][\dA-F][\dA-F][\dA-F][\dA-F][\dA-F][\dA-F]
     D:CUL_HOERMANN ^R..........
     E:TSCUL_TX ^TXA.........
     F:CUL_IR   ^I............
     G:SOMFY    ^Y[r|t|s]:?[\dA-F]+
     H:Revolt   ^r......................$
     I:ESA2000  ^S................................$
     K:TSCUL_EM ^E0.0[\dA-F]..............
     L:BS       ^81..(04|0c)..0101a001a5cf
     M:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     N:FS20     ^81..(04|0c)..0101a001
     O:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     P:TSKS300  ^810d04..4027a001
     Q:HMS      ^810e04......a001
     R:CUL_TCM97001 ^s[\dA-F]+
     S:CUL_REDIRECT ^o
   READINGS:
     2018-11-05 20:32:08   Ints_per_sec    SI: 3192.20748  TI: 2.06736  S: 763.20699  L: 2.06736  U: 34.60319  M: 5.74713
     2019-04-06 11:47:24   Xmit-Events     non-HM:1 disconnected:1
     2018-11-07 07:47:02   ccconf          freq:868.300MHz freqOffs:-20.630kHz bWidth:101kHz freqIF:152.34kHz rAmpl:33dB sens:8dB dRate:9.993kBit/s
agcPrio:1 agcWait:16 agcHyst:2 agcMaxLNA:0.0dB agcMaxDVGA:1 AGC_FREEZE:0
CCAmode:3 csRelThr:10dB csAbsThr:7dB
     2019-04-06 11:47:23   cmds             A B C E F G J K M N R U V W X Y Z e i l m t x
     2019-04-06 11:47:24   cond            non-HM
     2017-01-31 20:35:05   credit10ms      1800
     2019-01-28 09:16:34   prot_ERROR-Overload last
     2018-11-08 16:02:36   prot_Warning-HighLoad last
     2019-04-06 11:46:20   prot_disconnected last
     2019-04-03 11:26:57   prot_init       last
     2019-04-06 11:47:24   prot_non-HM     last
     2019-04-03 11:26:57   prot_ok         last
     2019-04-06 11:38:34   scF             0.999593593134096
     2019-04-06 11:47:24   state           Initialized
   helper:
     ChkPart    0
     RA_Timeout 0
     VTS        1
     VTS_ACK    1
     VTS_AES    1
     assIdCnt   18
     assIdRep   18
     hmTSAt1Add
     recd       0
     tbuf       
     DEVIO:
       RXfailTO   
     HM:
       ChTblSize  220
       HMactive   0
       hmCrdts    9
       ChTbl:
         254C4C3F   00
         2710FA3F   00
         27128B3F   00
         2CABFE3F   00
         2CAC613F   00
         2CAC743F   00
         2CAC993F   00
         2E51C93F   00
         3032663F   00
         31D0AD3F   00
         384B403F   00
         384B4D3F   00
         384B523F   00
         384B573F   00
         384DE53F   00
         3C8D913F   00
         3C8D9D3F   00
         56543D3F   00
     cnd:
       250        1
       253        1
     ids:
       254C4C:
         cfg        +254C4C,00,00,00
         name       OG.hz.01
       2710FA:
         cfg        +2710FA,00,00,00
         name       OG.k2.TH
       27128B:
         cfg        +27128B,00,00,00
         name       OG.wz.TH
       2CABFE:
         cfg        +2CABFE,00,00,00
         name       OG.wz.l.RO
       2CAC61:
         cfg        +2CAC61,00,00,00
         name       OG.sz.l.RO
       2CAC74:
         cfg        +2CAC74,00,00,00
         name       OG.wz.m.RO
       2CAC99:
         cfg        +2CAC99,00,00,00
         name       OG.wz.r.RO
       2E51C9:
         cfg        +2E51C9,00,00,00
         name       OG.hz.02
       303266:
         cfg        +303266,00,00,00
         name       OG.sz.TH
       31D0AD:
         cfg        +31D0AD,00,00,00
         name       OG.k1.TH
       384B40:
         cfg        +384B40,00,00,00
         name       OG.th.r.RO
       384B4D:
         cfg        +384B4D,00,00,00
         name       OG.k1.l.RO
       384B52:
         cfg        +384B52,00,00,00
         name       OG.k2.RO
       384B57:
         cfg        +384B57,00,00,00
         name       OG.k1.r.RO
       384DE5:
         cfg        +384DE5,00,00,00
         name       OG.kueche.RO
       3C8D91:
         cfg        +3C8D91,00,00,00
         name       EG.sz.FK
       3C8D9D:
         cfg        +3C8D9D,00,00,00
         name       OG.th.l.FK
       56543D:
         cfg        +56543D,00,00,00
         name       OG.sz.r.RO
     q:
       HMcndN     250
       hmLanQlen  1
       cap:
         sum        0
     ref:
       doNbyterate 50
       ioByteRate 1000000
       ioByteRateMeas 0
       lHMt       4294967295
       lSys       1640943980.30327
       pngFrc     1
       pngLm      70
       pngMax     -100000000
       pngMaxTot  -100000000
       pngMin     100000000
       pngRef     100000000
       scF        1
       scFN       1
       scHT       4294967295
       scST       1640943980.30327
Attributes:
   hmId       738396
   hmLanQlen  1_min
   model      CUL
   room       CUL_TS
   verbose    0

Hinweis, nachdem Reboot bekommt ich von fhem auch folgende Fehlermeldung:

Code Auswählen Erweitern

configfile: ASKSIN not supported
ASKSIN not supported
CUL_KG: Mode HomeMatic not supported, wrong firmware?!?
ASKSIN not supported
ASKSIN not supported
CUL_EG: Mode HomeMatic not supported, wrong firmware?!?
ASKSIN not supported
ASKSIN not supported
CUL_OG: Mode HomeMatic not supported, wrong firmware?!?
ASKSIN not supported
ASKSIN not supported
CUL_GH: Mode HomeMatic not supported, wrong firmware?!?
ASKSIN not supported
ASKSIN not supported
CUL_DG: Mode HomeMatic not supported, wrong firmware?!?
ASKSIN not supported


Wenn ich dann fhem per "shutdown restart" nochmal neu starte, kommen diese Fehlermeldung meistens nicht mehr.

[RaspiLED]

Hi,
Ser2net braucht das netz, kann es sein, dass dein FHEM vor der Init des Netzwerks gestartet wird?
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...

[noansi]

Hallo Frank,

Nochmal zur Erinnerung: Meine CULs (bis auf Einen) sind per ser2net von externen Raspi's angebunden.

Die biologische SSD hat leider auch die Funktion, nicht mehr benötigte und veränderliche Informationen auch wieder zu löschen. 
Und die Funktion funktioniert von Jahr zu Jahr immer besser und aktiviert sich früher.   
Wäre hilfreich, wenn Du Systemdaten immer direkt mit erwähnst.

Sehe ich das richtig, das nur die per ser2net angebundenen CULs betroffen sind?

Dann tippe ich beim Reboot darauf, dass ser2net beim fhem Start noch nicht oder nicht vollständig aktiv ist die Kommunikation zu den per ser2net angebundenen CULs beim fhem Start gestört ist.
Mit einem globalen verbose 5 und einem reboot könnte man im log sehen, was dabei an Daten zum CUL ausgetauscht werden kann.

Die Meldungen "Mode HomeMatic not supported, wrong firmware?!?" können nur dann kommen, wenn beim Setzen des Attributs beim fhem Start die Version und Fähigkeiten des CULs noch nicht korrekt bestimmt werden können (aber eine Verbindung geöffnet werden kann?). Die Funktion/Prüfung soll verhindern, dass ein CUL ohne HM Support auf HomeMatic gesetzt wird und damit andere Fehler auftreten.

Vielleicht musst Du auch noch irgendwie eine Verzögerung einbauen? Da ich ser2net nicht nutze, kann ich Dir konkretere Tips dazu nicht geben.

Gruß, Ansgar.