gelöst: CUL_433 kein Autocreate

Begonnen von jhohmann, 18 Juni 2020, 13:52:24

Vorheriges Thema - Nächstes Thema

jhohmann

Hallo,
ich meine, dass mir früher Geräte, die vom CUL empfangen werden konnten, automatisch als Device in FHEM angelegt worden sind, z.B. Thermo-Sensoren aus der Nachbarschaft.
Seit einiger Zeit passiert das nicht mehr, wobei ich den Zeitpunkt nicht benennen kann.
Zwischenzeitig habe ich meinen Pi von stretch auf buster aktualisiert, FHEM wurde auch mehrfach aktualisiert. Und ich meine, dass ich meinen CUL von culfw auf aculfw neu geflasht hatte (um mehr Credits verbrauchen zu können, die ich aber momentan gar nicht brauchen würde).
Hat jemand was ähnliches zu berichten oder kann mir einen Tipp geben, was ich wo umstellen müsste?
Hier ein List von meinem CUL:
Internals:
   CMDS       ABCeFfGiKLlMNRTtUVWXxY
   CUL_433_MSGCNT 200
   CUL_433_TIME 2020-06-18 13:35:44
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS:FS20V: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   DEF        /dev/serial/by-id/usb-SHK_NANO_CUL_433-if00-port0@38400 0000
   DeviceName /dev/serial/by-id/usb-SHK_NANO_CUL_433-if00-port0@38400
   FD         48
   FHTID      0000
   FUUID      5c822528-f33f-98e0-b19d-8d969ed5f01eed72
   NAME       CUL_433
   NR         166
   PARTIAL   
   RAWMSG     i0AF2A92B
   RSSI       -52.5
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.26.04 a-culfw Build: private build (unknown) nanoCUL433 (F-Band: 433MHz)
   initString X21
   MatchList:
     0:FS20V    ^81..(04|0c)..0101a001......00[89a-f]...
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04......a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2020-05-26 11:47:02   ccconf          freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB
     2020-06-18 09:17:20   cmds             A B C e F f G i K L l M N R T t U V W X x Y
     2020-05-26 11:47:19   credit10ms      2622
     2020-06-18 13:38:18   raw             isF0FF00FFFFF0
     2020-06-18 13:35:44   state           Initialized
     2020-05-26 11:47:24   version         V 1.26.04 a-culfw Build: private build (unknown) nanoCUL433 (F-Band: 433MHz)
Attributes:
   icon       cul_cul
   rfmode     SlowRF

Und ein aktueller Eintrag aus meinem Log, der kein Gerät angelegt hat:
2020.06.18 13:05:38 2: CUL_433 IT: 30583_14 not defined (HE800)
Raspberry Pi 4 - bookworm / EnOcean - Rollo+Licht, deCONZ - Licht+Sensoren, ZWave - CO Messung, HMCCU mit piVCCU - Heizung+Rollo
plus dovecot, minidlna

Beta-User

Was kommt bei
list TYPE=autocreate
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

jhohmann

Internals:
   FUUID      5c82251d-f33f-98e0-76ee-8fb7c897ef006177
   NAME       autocreate
   NOTIFYDEV  global
   NR         13
   NTFY_ORDER 50-autocreate
   STATE      active
   TYPE       autocreate
   received:
     IT:
       HE800 30583 14:
         1592481738.28082 1
Attributes:
   disable    0
   filelog    ./log/%NAME-%Y-%m.log
   room       System

Bei anderen Anschlüssen wie deconz werden mir neue Geräte automatisch angelegt, sollte also prinzipiell passen.
Raspberry Pi 4 - bookworm / EnOcean - Rollo+Licht, deCONZ - Licht+Sensoren, ZWave - CO Messung, HMCCU mit piVCCU - Heizung+Rollo
plus dovecot, minidlna

Beta-User

Hmm, das ist seltsam, zumal er ja ausweislich des log was zu empfangen scheint.

Eventuell firmware nochmal aktualisieren (.08, siehe https://github.com/heliflieger/a-culfw), oder gleich auf (Developer-) Signalduino wechseln, ist für 433MHz-Zeug mMn. mittlerweile die deutlich bessere Wahl (hat nichts mit credits zu tun, das stammt aus der 868MHz-Welt, siehe 1%-Regel im Wiki).
Kann natürlich auch sein, dass der Nano einen Hau hat. "Initialized" muß nicht optimal sein, diese Statusmeldung kann aber auch an der Art der Einbindung liegen (FTDI) und völlig iO. sein. Optisch ist alles ok? (Insbesondere: keine schnell blinkende LED).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

jhohmann

Die LED blinkt dauerhaft, sollte also alles gut sein.
Das mit der Signalduino FW habe ich jetzt hier auch gerade entdeckt und werde es mir anschauen.
Danke
Raspberry Pi 4 - bookworm / EnOcean - Rollo+Licht, deCONZ - Licht+Sensoren, ZWave - CO Messung, HMCCU mit piVCCU - Heizung+Rollo
plus dovecot, minidlna

Beta-User

Dauerhaft: schnell? Dann hast du eventuell das Test-PIN-Problem. Wenn überhaupt, sollte das gemütlich hin und wieder blinken bzw. beim empfangen (ich habe aber nur einen als Signalduino geflashten Nano und einen Busware-CUL; die reagieren beide eventuell etwas anders).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

jhohmann

Die LED ist immer an, kein flackern.
Und wenn eine Steckdose, die bekannt ist, geschaltet wird, blinkt es kurz und dann wieder durchgehend an.
Es scheint aber so, als ob da zwei LEDs in dem Stick drin sind, einer für das dauerhafte und der andere bei Tätigkeit.
Ist aber schwer zu erkennen, da die Folie über den LEDs mit einem Stift mehr schlecht als recht undurchsichtig gemacht ist.
Raspberry Pi 4 - bookworm / EnOcean - Rollo+Licht, deCONZ - Licht+Sensoren, ZWave - CO Messung, HMCCU mit piVCCU - Heizung+Rollo
plus dovecot, minidlna

Beta-User

Das klingt tatsächlich unauffällig, mMn. (in diese Richtung) no action required.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

jhohmann

Habe nun den CUL gemäß Anleitung im Wiki auf Signalduino umgelernt und läuft  8)!
Meine bisherigen Steckdosen funktionieren weiterhin, nachdem ich das IODev auf den sduino umgestellt hatte.
Und ein neues Außenthermometer, welches vorher nicht erkannt wurde, wurde jetzt direkt in FHEM sauber angelegt und bekommt Daten.
Also alles im grünen Bereich.
Danke für den Tipp mit der Firmware für SignalDuino.
Raspberry Pi 4 - bookworm / EnOcean - Rollo+Licht, deCONZ - Licht+Sensoren, ZWave - CO Messung, HMCCU mit piVCCU - Heizung+Rollo
plus dovecot, minidlna

Beta-User

Danke für die Rückmeldung  :) .

Einen Tipp habe ich noch: Wenn du den Thread-Titel im ersten Post änderst, ist der Thread wirklich als [gelöst] gekennzeichnet ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files