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:
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,Weihnachten
Als 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
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 (https://forum.fhem.de/index.php/topic,120603.0/all.html)
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.
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.
Zitat von: rudolfkoenig am 16 Mai 2021, 12:18:33
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.
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.
Zitat von: rudolfkoenig am 16 Mai 2021, 13:21:21
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
Zitat von: rudolfkoenig am 16 Mai 2021, 13:21:21
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
attr TYPE=FS20 IODev nanoCUL
lässt sich das Problem natürlich schnell beheben.
Ist aber eigentlich unschön.
Norbert
Edit: Dateianhang gelöscht
ZitatDie 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:
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.
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:
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.
Zitat von: rudolfkoenig am 23 Mai 2021, 12:03:09
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
attr TYPE=FS20 IODev nanoCUL
war in einem FS20-device alles in Ordnung.
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:
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:
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:
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 5
Das Reading IODev ist falsch, aber das device funktioniert.
List vom nanoCUL nach Neustart:
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:
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:
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:
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
In 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
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.
Zitat von: rudolfkoenig am 24 Mai 2021, 15:32:23
ich meine es gefixt zu haben. Bitte testen.
Sieht gut aus. Nach dem Update ist jetzt auch das Reading IODev wieder richtig.
Danke.
Norbert