[solved] CUL - Problem nach letztem FHEM-Update (23.08.)

Begonnen von SusisStrolch, 24 August 2016, 20:23:36

Vorheriges Thema - Nächstes Thema

SusisStrolch

Seit meinem letzten FHEM-Update (23.08.) habe ich ein Problem mit meinem Funkthermometer.
Bis zu diesem Zeitpunkt problemlos mit folgender Definition:
Internals:
   CFGFN
   CODE       SD_WS07_TH_511
   DEF        SD_WS07_TH_511
   IODev      cul.LCG
   NAME       Temperatur.Keller
   NR         52
   STATE      Defined
   TYPE       SD_WS07
   bitMSG
   lastMSG
   Readings:
     2016-08-23 15:19:32   battery         ok
     2016-08-23 15:19:32   channel         1
     2016-08-23 15:19:32   humidity        68
     2016-08-23 15:19:32   state           T: 19.3 H: 68
     2016-08-23 15:19:32   temperature     19.3
Attributes:
   IODev      cul.LCG
   event-min-interval .*:300
   event-on-change-reading .*


Nach dem Update wurden vom Device keine Daten mehr geliefert, dafür wurde durch die Autoconfig folgendes Gerät angelegt:
Internals:
   CFGFN
   CHANGED
   CODE       CUL_TCM97001_81
   DEF        CUL_TCM97001_81
   LASTInputDev cul.LCG
   MSGCNT     4
   NAME       Rubicson_81
   NR         86
   RSSI       -72.5
   STATE      T: 19.1
   TYPE       CUL_TCM97001
   cul.LCG_MSGCNT 4
   cul.LCG_RAWMSG s5180BFF44003
   cul.LCG_TIME 2016-08-24 13:18:07
   lastH      0
   lastT      1472037487
   Helper:
     Dblog:
       T:
         Logdb:
           TIME       1472037316.6916
           VALUE      19.1
       Temperature:
         Logdb:
           TIME       1472037316.6916
           VALUE      19.1
   Readings:
     2016-08-24 13:18:07   state           T: 19.1
     2016-08-24 13:18:07   temperature     19.1
Attributes:
   event-min-interval .*:300
   event-on-change-reading .*


Wie bekomme ich wieder mein altes WS-Device zurück?

Hier noch ein Auszug aus einem alten Log:
2016.08.01 00:00:46 4: CUL_Parse: cul.LCG s5180C4F45005
2016.08.01 00:00:46 4: SD_WS07_Parse  SD_WS07 (P7#5180C4F450) length: 10
2016.08.01 00:00:46 4: SD_WS07_TH decoded protocolid: 7 sensor id=51, channel=1, temp=19.6, hum=69, bat=ok
2016.08.01 00:00:46 4: cul.LCG using longid: 1 model: SD_WS07_TH


Und hier ein aktueller:

2016.08.24 20:10:25 5: CUL/RAW: /s
2016.08.24 20:10:25 5: CUL/RAW: s/5180B7F45004^M

2016.08.24 20:10:25 4: CUL_Parse: cul.LCG s5180B7F45004
2016.08.24 20:10:25 5: cul.LCG dispatch s5180B7F45004
2016.08.24 20:10:25 4: CUL_TCM97001 Rubicson_81 81 (5180B7F45004) length: 12 RSSI: -72
2016.08.24 20:10:25 4: CUL_TCM97001 Parse Name: Rubicson_81 , devicecode: CUL_TCM97001_81 , Model defined: Prologue

Synology DS1515+, 16GB RAM, 4x 6TB WD-Red
- Docker (FHEM), MariaDB, MariaDB10, Surveillance Station
Gateways: LCG miniCUL433, LCG miniCUL868, AVR-X4000, VU-Solo SE, Kodi
ESP8266: ESPEasy (S0-Counter, Temp/Hum), Sonoff TH, Sonoff 4ch

SusisStrolch

Nachtrag:
hier noch ein Screenshot, anhand dessen man sieht das der Device-Typ nahtlos gewechselt wurde...
Synology DS1515+, 16GB RAM, 4x 6TB WD-Red
- Docker (FHEM), MariaDB, MariaDB10, Surveillance Station
Gateways: LCG miniCUL433, LCG miniCUL868, AVR-X4000, VU-Solo SE, Kodi
ESP8266: ESPEasy (S0-Counter, Temp/Hum), Sonoff TH, Sonoff 4ch

SusisStrolch

Und noch eine Korrektur...
das Problem trat anscheinend beim Update am 22.08. auf:
2016.08.22 21:56:28 2: CUL_TCM97001 Unknown device CUL_TCM97001_81, please define it
2016.08.22 22:15:28 2: CUL_TCM97001 Unknown device CUL_TCM97001_81, please define it
2016.08.22 22:22:07 2: CUL_TCM97001 Unknown device CUL_TCM97001_81, please define it


Aktualisert wuden
2016.08.22 21:18:15 1: UPD ./CHANGED
2016.08.22 21:18:15 1: UPD ./fhem.pl
2016.08.22 21:18:16 1: UPD FHEM/00_CUL.pm
2016.08.22 21:18:16 1: UPD FHEM/00_FBAHAHTTP.pm
2016.08.22 21:18:16 1: UPD FHEM/00_HMUARTLGW.pm
2016.08.22 21:18:16 1: UPD FHEM/00_TCM.pm
2016.08.22 21:18:16 1: UPD FHEM/01_FHEMWEB.pm
2016.08.22 21:18:16 1: UPD FHEM/10_CUL_HM.pm
2016.08.22 21:18:17 1: UPD FHEM/10_EnOcean.pm
2016.08.22 21:18:18 1: UPD FHEM/10_OWServer.pm
2016.08.22 21:18:18 1: UPD FHEM/10_RESIDENTS.pm
2016.08.22 21:18:18 1: UPD FHEM/10_ZWave.pm
2016.08.22 21:18:18 1: UPD FHEM/11_OWDevice.pm
2016.08.22 21:18:18 1: UPD FHEM/20_GUEST.pm
2016.08.22 21:18:18 1: UPD FHEM/20_ROOMMATE.pm
2016.08.22 21:18:19 1: UPD FHEM/26_KM273.pm
2016.08.22 21:18:19 1: UPD FHEM/38_netatmo.pm
2016.08.22 21:18:19 1: UPD FHEM/50_HP1000.pm
2016.08.22 21:18:19 1: UPD FHEM/55_PIFACE.pm
2016.08.22 21:18:20 1: UPD FHEM/60_allergy.pm
2016.08.22 21:18:20 1: UPD FHEM/70_ENIGMA2.pm
2016.08.22 21:18:20 1: UPD FHEM/70_ONKYO_AVR.pm
2016.08.22 21:18:20 1: UPD FHEM/70_PHTV.pm
2016.08.22 21:18:20 1: UPD FHEM/70_Pushover.pm
2016.08.22 21:18:21 1: UPD FHEM/70_VolumeLink.pm
2016.08.22 21:18:21 1: UPD FHEM/71_ONKYO_AVR_ZONE.pm
2016.08.22 21:18:21 1: UPD FHEM/72_FRITZBOX.pm
2016.08.22 21:18:21 1: UPD FHEM/75_MSG.pm
2016.08.22 21:18:21 1: UPD FHEM/75_msgConfig.pm
2016.08.22 21:18:21 1: UPD FHEM/76_MSGFile.pm
2016.08.22 21:18:22 1: UPD FHEM/76_MSGMail.pm
2016.08.22 21:18:22 1: UPD FHEM/90_at.pm
2016.08.22 21:18:22 1: UPD FHEM/93_DbRep.pm
2016.08.22 21:18:22 1: UPD FHEM/98_GEOFANCY.pm
2016.08.22 21:18:22 1: UPD FHEM/98_JsonList.pm
2016.08.22 21:18:22 1: UPD FHEM/98_exportdevice.pm
2016.08.22 21:18:23 1: UPD FHEM/HMConfig.pm
2016.08.22 21:18:23 1: UPD FHEM/RESIDENTStk.pm
2016.08.22 21:18:23 1: UPD FHEM/lib/fhem_zwave_deviceconfig.xml.gz
2016.08.22 21:18:23 1: UPD FHEM/lib/openzwave_deviceconfig.xml.gz
2016.08.22 21:18:24 1: UPD FHEM/lib/openzwave_manufacturer_specific.xml
2016.08.22 21:18:24 1: UPD contrib/commandref_modular.pl
2016.08.22 21:18:24 1: UPD www/pgm2/fhemdoc_modular.js


Ein Kandidat für mich wäre 2016.08.22 21:18:16 1: UPD FHEM/00_TCM.pm

Was mich allerdings verwundert -  bis zum 23. wurden noch Daten vom alten Device geliefert...
Synology DS1515+, 16GB RAM, 4x 6TB WD-Red
- Docker (FHEM), MariaDB, MariaDB10, Surveillance Station
Gateways: LCG miniCUL433, LCG miniCUL868, AVR-X4000, VU-Solo SE, Kodi
ESP8266: ESPEasy (S0-Counter, Temp/Hum), Sonoff TH, Sonoff 4ch

SusisStrolch

Und noch mal zum Thema:
seit heute Nachmittag liefert auch dieser Rubicon-Device keine Daten mehr.
Dafür habe ich ein Unknown, welches regelmäßig
2016-08-24_13:19:04 Unknown Code: 5180BFF440
2016-08-24_13:20:02 Unknown Code: 5180BFF440
2016-08-24_13:20:58 Unknown Code: 5180BFF440
2016-08-24_13:21:55 Unknown Code: 5180BFF440
2016-08-24_13:22:52 Unknown Code: 5180BFF440
2016-08-24_13:23:49 Unknown Code: 5180BFF440
2016-08-24_13:24:46 Unknown Code: 5180BFF440
2016-08-24_13:25:43 Unknown Code: 5180BFF440
2016-08-24_13:26:40 Unknown Code: 5180BFF440
2016-08-24_13:27:37 Unknown Code: 5180BFF440
2016-08-24_13:28:34 Unknown Code: 5180BFF440
2016-08-24_13:29:31 Unknown Code: 5180BFF440
2016-08-24_13:30:28 Unknown Code: 5180BFF440
2016-08-24_13:31:25 Unknown Code: 5180BFF440
2016-08-24_13:32:22 Unknown Code: 5180BFF440
2016-08-24_13:33:19 Unknown Code: 5180C0F440
2016-08-24_13:34:16 Unknown Code: 5180C0F440
2016-08-24_13:35:13 Unknown Code: 5180C0F440
2016-08-24_13:36:10 Unknown Code: 5180C0F440
2016-08-24_13:37:07 Unknown Code: 5180C0F440
2016-08-24_13:37:07 Unknown Code: 5180C0F440
2016-08-24_13:38:04 Unknown Code: 5180C0F440
2016-08-24_13:39:01 Unknown Code: 5180C0F440
2016-08-24_13:39:59 Unknown Code: 5180C0F440
2016-08-24_13:40:55 Unknown Code: 5180C0F440
2016-08-24_13:41:52 Unknown Code: 5180C0F440
2016-08-24_13:42:49 Unknown Code: 5180C0F440
2016-08-24_13:43:46 Unknown Code: 5180C0F440
2016-08-24_13:44:43 Unknown Code: 5180C0F440
2016-08-24_13:45:40 Unknown Code: 5180C0F440
2016-08-24_13:46:37 Unknown Code: 5180C0F440
2016-08-24_13:47:34 Unknown Code: 5180C0F440


liefert. Was ist denn da verklemmt?
Synology DS1515+, 16GB RAM, 4x 6TB WD-Red
- Docker (FHEM), MariaDB, MariaDB10, Surveillance Station
Gateways: LCG miniCUL433, LCG miniCUL868, AVR-X4000, VU-Solo SE, Kodi
ESP8266: ESPEasy (S0-Counter, Temp/Hum), Sonoff TH, Sonoff 4ch

SusisStrolch

Erledigt - nach Löschen des "Undefined" und des "TCM..." lief wieder alle Daten auf das ursprüngliche Device.  ???
Synology DS1515+, 16GB RAM, 4x 6TB WD-Red
- Docker (FHEM), MariaDB, MariaDB10, Surveillance Station
Gateways: LCG miniCUL433, LCG miniCUL868, AVR-X4000, VU-Solo SE, Kodi
ESP8266: ESPEasy (S0-Counter, Temp/Hum), Sonoff TH, Sonoff 4ch

rudolfkoenig

Auch wenn das Problem verschwunden ist, waere nett zu wissen, was die Ursache war.
- Nachrichten fuer das Geraet vom Typ SD_WS07 werden vom CUL als o.* gemeldet, und per CUL_REDIRECT an das SD_WS07 Modul (als umformatierte P.* Nachricht) verteilt
- Nachrichten der Form s.* werden vom culfw/CUL.pm als TCM97001 erkannt, deswegen wird auch ein entsprechendes Geraet angelegt bzw. als undefined gemeldet.

Das kann sich mWn nicht mit dem FHEM update zusammenhaengen. Moeglichkeiten, die ich sehe:
- dein Geraet hat temporaer das verwendete Funkprotokoll geaendert
- culfw ist fehlerhaft
- Alt-Geraet (SD.*) war stumm, und temporaeres(?) Neu-Geraet (TCM.*) hat gesendet

SusisStrolch

Keine Idee wo die Problemursache liegt...
Zitat- dein Geraet hat temporaer das verwendete Funkprotokoll geaendert
fällt aus - steht im Keller hinter der Wärmepumpe. Kein Batteriewechsel, nichts...
Zitat- Alt-Geraet (SD.*) war stumm, und temporaeres(?) Neu-Geraet (TCM.*) hat gesendet
fällt aus - identisches Gerät - sieht man am Plot...
Zitatculfw ist fehlerhaft
culfw unverändert, kein Software-Update seit Inbetriebnahme.

Wie schon gesagt, die einzige Korrelation die ich sehe ist der Software-Update vom 22.08, bei dem der TCM-Treiber aktualisiert wurde.
Nach dem Reboot am 23. wurde das neue Device erzeugt, alle Daten wurden dann zum Rubicon geroutet.
Nach dem Löschen von "Undefined" und "Rubicon" lief wieder alles auf den ursprünglich definierten SD_WS07.

Logfiles sind bedingt vorhanden - ich brauche nur nen Anhalt welche Infos gebraucht werden / hilfreich sind.
Synology DS1515+, 16GB RAM, 4x 6TB WD-Red
- Docker (FHEM), MariaDB, MariaDB10, Surveillance Station
Gateways: LCG miniCUL433, LCG miniCUL868, AVR-X4000, VU-Solo SE, Kodi
ESP8266: ESPEasy (S0-Counter, Temp/Hum), Sonoff TH, Sonoff 4ch