[gelöst] IODev nach Update falsch zugeordnet

[Nobbynews]

Guten Morgen,

seit dem Update vom 9.5. (aus meiner Erinnerung heraus) habe ich nach einem Update bzw. nach einem Neustart das Poblem, das bei allen FS20 devices das Reading und das Internal IODev nicht mehr richtig gesetzt werden (bei mir auf radinoCC1101), während das Attribut aber weiterhin stimmt (nanoCUL).
Hier mal ein Beispiel:

Code: [Auswählen]

Internals:
   BTN        a1
   DEF        1881 a1
   FUUID      5c430361-f33f-8873-35a8-8e18c81381ff97a0
   FVERSION   10_FS20.pm:0.148880/2017-08-13
   IODev      radinoCC1101
   NAME       Baum
   NR         96
   STATE      off
   STILLDONETIME 0
   TYPE       FS20
   XMIT       1881
   CODE:
     1          1881 a1
   READINGS:
     2021-05-15 07:33:59   IODev           radinoCC1101
     2021-01-16 14:42:00   state           off
Attributes:
   IODev      nanoCUL
   model      fs20st
   room       FS20,WeihnachtenAls Ergebnis lassen sich die devices nicht mehr schalten.
Wählt man dann das Attribut IODev aus, um es zu ändern, wird keine Änderung erkannt (rotes Fragenzeichen neben 'Save config' fehlt) aber Internal und Reading IODev wieder richtig gesetzt und alles ist wieder OK.
Zunächst habe ich mir nichts dabei gedacht, doch musste ich meinen Pi gestern neu starten und hatte den Effekt wieder.
Es sind definitv nur die FS20-devices betroffen. Alles andere wie EnOcean, Z-Wave, RSL etc. sind nicht betroffen.
Einen Defekt der SD-Karte würde ich auch erst einmal ausschließen (Log-Files werden auf eine USB-Festplatte geschrieben).

Ideen???

Schönen Sonntag
Norbert

[elektron-bbs]

Das war bei mir bei FS10 genau so. Allerdings hat bei mir das einmalige Neusetzten des Attributes IODev scheinbar geholfen.
Es wurde irgend etwas am Handling geändert: https://forum.fhem.de/index.php/topic,120603.0/all.html

Code: [Auswählen]

Internals
IODev          sduinoEasyPico434
LASTInputDev   sduino434

Readings
IODev          sduino868           2021-05-15 17:32:37

Attributes
IODev          sduinoEasyPico434

Im Reading steht irgendein Device, was beim Neustart gesetzt wurde. Bei set wird bei mir aber das richtige Gerät verwendet.

[rudolfkoenig]

Wie @elektron-bbs das gezeigt hat, wurde das Handling leicht modifiziert: die automatische IODev Zuweisung setzt kein Attribut mehr, sondern ein Reading, da mAn Attribute exklusiv dem Benutzer gehoeren. Sowohl Reading wie auch Attribut setzen weiterhin das IODev Internal, was wiederum von dem FHEM-Framework verwendet wird, und auch von den Modulen verwendet werden sollte.

Wie immer gibt es Ausnahmen, z.Bsp. das XiaomiMQTTDevice Modul, das explizit das Attribut prueft, und deswegen gefixt werden muss.

Womoeglich habe ich auch was uebersehen, deswegen untersuche ich das Problem gerne, wenn man mir was zum Nachstellen gibt.

[Nobbynews]

Womoeglich habe ich auch was uebersehen, deswegen untersuche ich das Problem gerne, wenn man mir was zum Nachstellen gibt.

Mache ich gerne, nur weis ich adhoc nicht was benötigt wird.

[rudolfkoenig]

Idealerweise ein fhem.cfg, was nach dem Start das Problem zeigt: das IODev Indernal fuer FS20XX ist nicht das, was man "bestellt" hat.
Ansonsten so viel Beschreibung, dass ich das nachbauen kann, womit das der obigen Variante entspricht, nur dass ich die fhem.cfg baue.

[Nobbynews]

Idealerweise ein fhem.cfg, was nach dem Start das Problem zeigt: das IODev Indernal fuer FS20XX ist nicht das, was man "bestellt" hat.

Kommen per PM.
Ich schicke die fhem.cfg vor und nach dem Update.

Norbert

Edit:
Irgendwie finde ich die Möglichkeit eines Anhangs nicht. Daher dann doch hier.
Gutes Beispiel ist z.B. das device Fikus_neu.
vorher: alles OK
nachher: Device auf radinoCC1101 gesetzt und damit ohne Funktion.
Der radinoCC1101 ist halt für 433 MHz.

Edit 2:
Es ist zum Mäusemelken.
Hab´s gerade noch einmal getest. Das Reading IODev zwar immer noch falsch aber das Internal IODev ist (nicht bei allen devices) korrekt und Schalten geht jetzt.
Weis der Geier warum.....

Edit 3: Dateianhang gelöscht

[Nobbynews]

Idealerweise ein fhem.cfg, was nach dem Start das Problem zeigt: das IODev Indernal fuer FS20XX ist nicht das, was man "bestellt" hat.

So, heute Morgen nach dem Update war es mal wieder soweit.
Vor dem Update: Alles OK
Nach dem Update: keine Funktion mehr beim Schalten

Erst nach Auswahl des Attribut IODev und Bestätigung funktioniert das device wieder.
Eine Veränderung der Config wurde nicht angezeigt und trotz Speicherns wurde auch keine neue fhem.cfg geschrieben.

Die beiden fhem.cfg vor und nach dem Update habe ich mal beigefügt.

Durch

Code: [Auswählen]

attr TYPE=FS20 IODev nanoCUL lässt sich das Problem natürlich schnell beheben.
Ist aber eigentlich unschön.

Norbert

Edit: Dateianhang gelöscht

[rudolfkoenig]

Die beiden fhem.cfg vor und nach dem Update habe ich mal beigefügt.

Da habe ich mich falsch ausgedrueckt: ich haette gerne eine minimale fhem.cfg, was das Problem demonstriert, nicht zwei komplett identische Dateien, mit jeweils 4300+ Zeilen.

In der Datei sind zwei CULs definiert (CUL1 und nanoCUL), dazwischen sind 16 FS20 Geraete. Jedem FS20 Geraet wird per IODev Attribut das nanoCUL zugeordnet, nach dem Starten zeigt das IODev Internal richtigerweise auch dahin. Nach "attr global verbose 5" und "set Baum on" sieht man in FHEM log, dass das nanoCUL sich zustaendig fuehlt:

Code: [Auswählen]

2021.05.23 12:00:14 5: Cmd: >set Baum on<
2021.05.23 12:00:14 3: FS20 set Baum on
2021.05.23 12:00:14 5: nanoCUL sending F1881a111
=> Ich sehe kein Problem.

[elektron-bbs]

Ich hatte ja ursprünglich geglaubt, das sich das Problem nach einmaligem Speichern des Attributes erledigt hätte. Das ist aber leider nicht so. Nach einem Update heute wird wieder das falsche IODev verwendet:

Code: [Auswählen]

2021.05.23 16:35:17 3: sduino868: FS10 set FS10_3_13 on FS10_3_13 - WZ Fernsehleuchte
2021.05.23 16:37:33 3: sduinoEasyPico434: FS10 set FS10_3_13 off FS10_3_13 - WZ Fernsehleuchte
2021.05.23 16:37:58 3: sduinoEasyPico434: FS10 set FS10_3_13 on FS10_3_13 - WZ Fernsehleuchte
2021.05.23 16:38:01 3: sduinoEasyPico434: FS10 set FS10_3_13 off FS10_3_13 - WZ Fernsehleuchte
2021.05.23 16:38:04 3: sduino868: FS10 set FS10_3_14 on FS10_3_14 - WZ Neonröhre
2021.05.23 16:38:07 3: sduino868: FS10 set FS10_3_14 off FS10_3_14 - WZ Neonröhre
2021.05.23 16:38:26 3: sduinoEasyPico434: FS10 set FS10_3_14 on FS10_3_14 - WZ Neonröhre
2021.05.23 16:38:31 3: sduinoEasyPico434: FS10 set FS10_3_14 off FS10_3_14 - WZ Neonröhre
2021.05.23 16:38:36 3: sduinoEasyPico434: FS10 set FS10_3_14 off FS10_3_14 - WZ Neonröhre
2021.05.23 16:40:09 3: sduino868: FS10 set FS10_5_12 on FS10_5_12 - WZ Brunnen
2021.05.23 16:40:14 3: sduino868: FS10 set FS10_5_12 off FS10_5_12 - WZ Brunnen
2021.05.23 16:40:29 3: sduinoEasyPico434: FS10 set FS10_5_12 on FS10_5_12 - WZ Brunnen
2021.05.23 16:40:36 3: sduinoEasyPico434: FS10 set FS10_5_12 off FS10_5_12 - WZ Brunnen
2021.05.23 16:40:49 3: sduino868: FS10 set FS10_5_13 on FS10_5_13 - WZ Schwibbogen
2021.05.23 16:40:54 3: sduino868: FS10 set FS10_5_13 off FS10_5_13 - WZ Schwibbogen
2021.05.23 16:41:05 3: sduinoEasyPico434: FS10 set FS10_5_13 on FS10_5_13 - WZ Schwibbogen
2021.05.23 16:41:08 3: sduinoEasyPico434: FS10 set FS10_5_13 off FS10_5_13 - WZ Schwibbogen

Nach einmaliger Auswahl und Setzen des Attributes IODev (es erfolgt keine Änderung der fhem.cfg, rotes Fragezeichen erscheint nicht) wird dann wieder das richtige IODev verwendet.

[Nobbynews]

Da habe ich mich falsch ausgedrueckt: ich haette gerne eine minimale fhem.cfg, was das Problem demonstriert, nicht zwei komplett identische Dateien, mit jeweils 4300+ Zeilen.
In der Datei sind zwei CULs definiert (CUL1 und nanoCUL),

Kann ich nachvollziehen und hätte ich auch selber drauf kommen können. Der CUL1 läuft im rfMode MAX und zeigt keine Probleme.
Daher habe ich das jetzt mal Schritt für Schritt versucht nachzustellen.
Nach dem gestrigen

Code: [Auswählen]

attr TYPE=FS20 IODev nanoCULwar in einem FS20-device alles in Ordnung.

Code: [Auswählen]

Internals:
   BTN        11
   DEF        1881 11
   FUUID      5c430360-f33f-8873-7bf4-1c17e0654171288d
   FVERSION   10_FS20.pm:0.148880/2017-08-13
   IODev      nanoCUL
   NAME       Fikus_neu
   NR         66
   STATE      off
   STILLDONETIME 0
   TYPE       FS20
   XMIT       1881
   CODE:
     1          1881 11
   READINGS:
     2021-05-23 10:45:19   IODev           nanoCUL
     2021-05-24 05:12:02   state           off
Attributes:
   IODev      nanoCUL
   appOptions { "template": "switch",
  "dashboard": "true"}
   model      fs20st
   room       FS20
   userattr   lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0 structexclude v1 v1_map v2 v2_map
   verbose    5
List vom nanoCUL:

Code: [Auswählen]

Internals:
   CMDS       ABCEeFfGhiKklMmRTtUVWXxYZz
   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-1a86_USB2.0-Serial-if00-port0@38400 0000
   DeviceName /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@38400
   FD         51
   FHTID      0000
   FUUID      5dcd1a33-f33f-8873-e8d9-9490a5bb786fd5cd
   FVERSION   00_CUL.pm:0.237270/2021-02-12
   NAME       nanoCUL
   NR         232
   NR_CMD_LAST_H 6
   PARTIAL   
   RAWMSG     F18810111F4
   RSSI       -80
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.67 nanoCUL868
   initString X21
   nanoCUL_MSGCNT 12
   nanoCUL_TIME 2021-05-24 05:04:24
   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:
     2021-05-09 09:10:09   ccconf          freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB
     2021-05-23 08:29:46   cmds             A B C E e F f G h i K k l M m R T t U V W X x Y Z z
     2021-05-09 09:25:59   credit10ms      900
     2021-05-09 08:22:30   raw             No answer
     2021-05-24 05:04:24   state           Initialized
     2021-05-09 08:16:58   uptime          0 00:03:27
     2021-05-09 08:07:13   version         V 1.67 nanoCUL868
   XMIT_TIME:
     1621825542.81494
     1621825545.06079
     1621825587.72911
     1621825593.05316
     1621825913.84416
     1621825922.54477
Attributes:
   icon       cul_cul
   model      nanoCUL
   rfmode     SlowRF
   room       10_I/O-Geräte
   verbose    5
Im Log steht:

Code: [Auswählen]

2021.05.24 05:11:53 3: FS20 set Fikus_neu on
2021.05.24 05:11:53 5: nanoCUL sending F18811111
2021.05.24 05:11:53 5: SW: F18811111
2021.05.24 05:12:02 3: FS20 set Fikus_neu off
2021.05.24 05:12:02 5: nanoCUL sending F18811100
2021.05.24 05:12:02 5: SW: F18811100
Nach dem Neustart sieht das list so aus:

Code: [Auswählen]

Internals:
   BTN        11
   DEF        1881 11
   FUUID      5c430360-f33f-8873-7bf4-1c17e0654171288d
   FVERSION   10_FS20.pm:0.148880/2017-08-13
   IODev      nanoCUL
   NAME       Fikus_neu
   NR         66
   STATE      off
   STILLDONETIME 0
   TYPE       FS20
   XMIT       1881
   CODE:
     1          1881 11
   READINGS:
     2021-05-24 05:16:23   IODev           radinoCC1101
     2021-05-24 05:18:05   state           off
Attributes:
   IODev      nanoCUL
   appOptions { "template": "switch",
  "dashboard": "true"}
   model      fs20st
   room       FS20
   userattr   lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0 structexclude v1 v1_map v2 v2_map
   verbose    5Das Reading IODev ist falsch, aber das device funktioniert.

List vom nanoCUL nach Neustart:

Code: [Auswählen]

Internals:
   CMDS       ABCEeFfGhiKklMmRTtUVWXxYZz
   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-1a86_USB2.0-Serial-if00-port0@38400 0000
   DeviceName /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@38400
   FD         51
   FHTID      0000
   FUUID      5dcd1a33-f33f-8873-e8d9-9490a5bb786fd5cd
   FVERSION   00_CUL.pm:0.237270/2021-02-12
   NAME       nanoCUL
   NR         232
   NR_CMD_LAST_H 3
   PARTIAL   
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.67 nanoCUL868
   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:
     2021-05-09 09:10:09   ccconf          freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB
     2021-05-24 05:16:33   cmds             A B C E e F f G h i K k l M m R T t U V W X x Y Z z
     2021-05-09 09:25:59   credit10ms      900
     2021-05-09 08:22:30   raw             No answer
     2021-05-24 05:16:33   state           Initialized
     2021-05-09 08:16:58   uptime          0 00:03:27
     2021-05-09 08:07:13   version         V 1.67 nanoCUL868
   XMIT_TIME:
     1621826285.11406
     1621826286.10961
     1621826324.41491
Attributes:
   icon       cul_cul
   model      nanoCUL
   rfmode     SlowRF
   room       10_I/O-Geräte
   verbose    5
Im Log steht:

Code: [Auswählen]

2021.05.24 05:20:38 3: FS20 set Fikus_neu on
2021.05.24 05:20:38 5: nanoCUL sending F18811111
2021.05.24 05:20:38 5: SW: F18811111
2021.05.24 05:20:42 3: FS20 set Fikus_neu off
2021.05.24 05:20:42 5: nanoCUL sending F18811100
2021.05.24 05:20:42 5: SW: F18811100
Die cfg vor dem Neustart:

Code: [Auswählen]

define nanoCUL CUL /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@38400 0000
setuuid nanoCUL 5dcd1a33-f33f-8873-e8d9-9490a5bb786fd5cd
attr nanoCUL icon cul_cul
attr nanoCUL model nanoCUL
attr nanoCUL rfmode SlowRF
attr nanoCUL room 10_I/O-Geräte
attr nanoCUL verbose 5

define Fikus_neu FS20 1881 11
setuuid Fikus_neu 5c430360-f33f-8873-7bf4-1c17e0654171288d
attr Fikus_neu userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0 structexclude v1 v1_map v2 v2_map
attr Fikus_neu IODev nanoCUL
attr Fikus_neu appOptions { "template": "switch",\
  "dashboard": "true"}
attr Fikus_neu model fs20st
attr Fikus_neu room FS20
attr Fikus_neu verbose 5
Die cfg nach dem Neustart:

Code: [Auswählen]

define nanoCUL CUL /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@38400 0000
setuuid nanoCUL 5dcd1a33-f33f-8873-e8d9-9490a5bb786fd5cd
attr nanoCUL icon cul_cul
attr nanoCUL model nanoCUL
attr nanoCUL rfmode SlowRF
attr nanoCUL room 10_I/O-Geräte
attr nanoCUL verbose 5

define Fikus_neu FS20 1881 11
setuuid Fikus_neu 5c430360-f33f-8873-7bf4-1c17e0654171288d
attr Fikus_neu userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0 structexclude v1 v1_map v2 v2_map
attr Fikus_neu IODev nanoCUL
attr Fikus_neu appOptions { "template": "switch",\
  "dashboard": "true"}
attr Fikus_neu model fs20st
attr Fikus_neu room FS20
attr Fikus_neu verbose 5In den cfg-Dateien erfolgt die Definition vom device vor der Definition des nanoCUL.

Es scheint aktuell so zu sein, dass lediglich das Reading IODev falsch belegt wird, aber keine Auswirkungen auf die Funktion hat.

Norbert

[rudolfkoenig]

Die Konfiguration der einzelnen Geraete ist mehr oder weniger uninteressant (bis auf dem IODev Attribut), worauf es ankommt ist die Reihenfolge der Geraete im Verhaeltnis zu den IODev-Definitionen. Ich habe in diesem Thema: https://forum.fhem.de/index.php?topic=121213 eine Beispielkonfiguration bekommen, was das Problem demonstriert, ich meine es gefixt zu haben. Bitte testen.

[Nobbynews]

ich meine es gefixt zu haben. Bitte testen.

Sieht gut aus. Nach dem Update ist jetzt auch das Reading IODev wieder richtig.
Danke.

Norbert