Änderung am Hauptdevice - Speicherreihenfolge in fhem.cfg falsch -> device weg

[chris1284]

hi,

mir ist es bsher nu bei hm-devices aufgefallen:

-ändert man an einem bestehen hm device etwas  am device ohne channel passt die reihenfolge in der cfg nicht mehr
- hat zur folge dass das device nicht mehr in fhem ist und man per hand die cfg gerade ziehen muss

beispiel: hm-cc-rt-db mit namen az_hz

Code Auswählen Erweitern

define az_hz CUL_HM 222275
attr az_hz IOgrp vccu
attr az_hz actCycle 000:10
attr az_hz actStatus alive
attr az_hz autoReadReg 4_reqStatus
attr az_hz expert 1_on
attr az_hz firmware 1.3
attr az_hz model HM-CC-RT-DN
attr az_hz room Heizung
attr az_hz serialNr KEQ0514304
attr az_hz subType thermostat
attr az_hz webCmd getConfig:clear msgEvents:burstXmit
define az_hz_Weather CUL_HM 22227501
attr az_hz_Weather DbLogExclude .*
attr az_hz_Weather model HM-CC-RT-DN
attr az_hz_Weather peerIDs 00000000,
define az_hz_Climate CUL_HM 22227502
attr az_hz_Climate DbLogExclude .*
attr az_hz_Climate model HM-CC-RT-DN
attr az_hz_Climate peerIDs 00000000,
define az_hz_WindowRec CUL_HM 22227503
attr az_hz_WindowRec model HM-CC-RT-DN
attr az_hz_WindowRec peerIDs 00000000,
attr az_hz_WindowRec stateFormat last:trigLast
define az_hz_Clima CUL_HM 22227504
attr az_hz_Clima expert 3_all
attr az_hz_Clima model HM-CC-RT-DN
attr az_hz_Clima peerIDs 00000000,
attr az_hz_Clima room AZ,Heizung
define az_hz_ClimaTeam CUL_HM 22227505
attr az_hz_ClimaTeam model HM-CC-RT-DN
attr az_hz_ClimaTeam peerIDs 00000000,
define az_hz_remote CUL_HM 22227506
attr az_hz_remote DbLogExclude .*
attr az_hz_remote model HM-CC-RT-DN
attr az_hz_remote peerIDs 00000000,2FBD0701,2F

nun habe ich gestern attr az_hz IOgrp vccu geändert, gespeichert, alles gut. heute neugstartet ist das gerät weg weil er die channels nicht definieren kann, weil das device nicht da ist.
ein blick in die cfg:

Code Auswählen Erweitern


define az_hz_Weather CUL_HM 22227501
attr az_hz_Weather DbLogExclude .*
attr az_hz_Weather model HM-CC-RT-DN
attr az_hz_Weather peerIDs 00000000,
define az_hz_Climate CUL_HM 22227502
attr az_hz_Climate DbLogExclude .*
attr az_hz_Climate model HM-CC-RT-DN
attr az_hz_Climate peerIDs 00000000,
define az_hz_WindowRec CUL_HM 22227503
attr az_hz_WindowRec model HM-CC-RT-DN
attr az_hz_WindowRec peerIDs 00000000,
attr az_hz_WindowRec stateFormat last:trigLast
define az_hz_Clima CUL_HM 22227504
attr az_hz_Clima expert 3_all
attr az_hz_Clima model HM-CC-RT-DN
attr az_hz_Clima peerIDs 00000000,
attr az_hz_Clima room AZ,Heizung
define az_hz_ClimaTeam CUL_HM 22227505
attr az_hz_ClimaTeam model HM-CC-RT-DN
attr az_hz_ClimaTeam peerIDs 00000000,
define az_hz_remote CUL_HM 22227506
attr az_hz_remote DbLogExclude .*
attr az_hz_remote model HM-CC-RT-DN
attr az_hz_remote peerIDs 00000000,2FBD0701,2F

ca 100 zeilen weiter wird dann erst das device definiert, zum schlusss!!!!!!!!!

Code Auswählen Erweitern

define az_hz CUL_HM 222275
attr az_hz IOgrp vccu
attr az_hz actCycle 000:10
attr az_hz actStatus alive
attr az_hz autoReadReg 4_reqStatus
attr az_hz expert 1_on
attr az_hz firmware 1.3
attr az_hz model HM-CC-RT-DN
attr az_hz room Heizung
attr az_hz serialNr KEQ0514304
attr az_hz subType thermostat
attr az_hz webCmd getConfig:clear msgEvents:burstXmit

hier wäre es sinnvoller die channels dann auch am ende nochmal anzuhängen (da logischerweise ohne das device die channels nicht geladen werden).
das ist nicht das erste mal das ich das feststelle nur bisher hatte ich micht nicht so geärgert 

[franky08]

ist mir auch schon passiert, seit dem sehe ich mir immer die cfg an und rücke es dahin wo es hingehört 

VG
Frank

[chris1284]

als workaround sicher gut aber nicht die endlösung  ich kopier mir immer das device aus dem backup 

[frank]

das attr IODev fehlt auch, oder ist es die letzten 2 wochen entfallen?
oder gibt es da einen zusammenhang?

[chris1284]

das war was anderes. ich wollte testen wie sich das device verhält wenn es eine iogroup hat aber kein iodev = es funktioniert, es kommuniziert mit fhem OHNE iodev (und hat nicht mit dem fehler zu tun).
fhem meckert das es ein device_channel anlegen soll, es aber kein device dazu gibt. das device wird später einzeln ohne channel sauber angelegt.

[frank]

na dann noch fröhliches testen. das sollte mit attr dummy so ähnlich funktionieren.

[martinp876]

Iodev wird automatisch angelegt, wenn iogrp gesetzt ist und du Sendest. Ist alles beschrieben, kann man auch lesen.

[postman75]

Nun, es wird schon etwas mit dem IODev zu tun haben. Ich habe nämlich ebenfalls dieses Attribut gelöscht bei einigen Geräten und hatte nach einem Update (und insbesondere einem Neustart) genau dasselbe Problem. Vorher nie gehabt. Es ging auch mit der alten Version nicht mehr, die Reihenfolge in der fhem.cfg war schlicht falsch.
Hab jetzt auch ein Backup bemüht, immerhin ist seitdem sonst nicht viel passiert.

Also besser stehenlassen, das IODev, auch wenn es bei mir einen HMLAN enthält, der eigentlich gar nicht mehr erreichbar ist. Unter welchen Umständen aktualisiert sich das Attribut denn? IOGrp ist auf dem aktuellen Stand, Kommunikation tuts auch, aber wozu gibt es IODev, wenn es einen tatsächlich ungültigen Wert enthält?

[martinp876]

Wenn iogrp, dann iodev automatisch.
Warum wollt ihr iodev löschen? Es gehört nun der vccu, also. Finger weg. Es geht euch nichts an.
Dass ein save die Reihenfolge der seines aendert ist über. Es sei denn ihr macht etwas anderes und verschuldet dies.
Solange ich nicht im fhem.gfc editiere hat sich noch nie die Reihenfolge der define geändert.
Sollte dies der Fall sein muss Rudi nach bessern. Bitte im entsprechenden great vorbringen

[chris1284]

ok, dann an rudi melden. da ich es nur bei hm hatte habe ich es erstm hier gepostet.

ich editiere NIE in der cfg außer es muss sein wie der "bugfix" mit der reihen folge.