FHEM.cfg save - plötzlich Fehler (CCU)

[remo]

Hallo zusammen,

seit gestern bekomme ich beim Speichern der fhem.cfg folgende Fehlermeldung:

Code Auswählen Erweitern

CCU: unknown attribute ccudef-readingfilter. Type 'attr CCU ?' for a detailed list. CCU: unknown attribute ccudef-readingname. Type 'attr CCU ?' for a detailed list. CCU: unknown attribute rpcport. Type 'attr CCU ?' for a detailed list.

An der Konfiguration habe ich nichts geändert.
Schalten von Aktoren funktioniert auch nicht.

Am Mittwoch lief noch alles.
Donnerstag dann nicht mehr.

OHNE ÄNDERUNGEN VORGENOMMEN ZU HABEN!

Über die CCU direkt lassen sich aber alle Aktoren schalten.
Die CCU selbst ist unauffällig und bringt keine Fehler.

Habt ihr eventuell einen Tipp für mich?

Liebe Grüße



Definition der CCU:

Code Auswählen Erweitern

define CCU HMCCU 192.168.x.x
attr CCU ccudef-readingfilter ^(LOW_?BAT|UNREACH)$
attr CCU ccudef-readingname ^(.+\.)?LOW_?BAT$:battery;;^(.+\.)?UNREACH$:activity
attr CCU ccudef-substitute AES_KEY!(0|false):off,(1|true):on;;LOWBAT,LOW_BAT!(0|false):ok,(1|true):low;;UNREACH!(0|false):alive,(1|true):dead;;MOTION!(0|false):noMotion,(1|true):motion;;DIRECTION!0:stop,1:up,2:down,3:undefined;;WORKING!0:false,1:true;;INHIBIT!(0|false):unlocked,(1|true):locked
attr CCU ccuflags procrpc
attr CCU event-on-change-reading .*
attr CCU rpcinterfaces BidCos-RF,HmIP-RF
attr CCU rpcport 2001,2010
attr CCU rpcserver on
attr CCU stripnumber 1

define d_rpc001117BidCos_RF HMCCURPCPROC http://192.168.x.x BidCos-RF
define d_rpc001117HmIP_RF HMCCURPCPROC http://192.168.x.x HmIP-RF

[Beta-User]

OHNE ÄNDERUNGEN VORGENOMMEN ZU HABEN!

...auch nicht zufällig ein update...?

Siehe https://forum.fhem.de/index.php/topic,123686.msg1182541.html#msg1182541

[remo]

...auch nicht zufällig ein update...?

Doch! Das lief so nebenbei, dass ich es "verdrängt" hatte.

Die drei bemängelten attr habe ich herauskommentiert.
Speichern wieder möglich.

Meine Aktoren kann ich aber nicht mehr schalten (zB Lichtschalter):

Code Auswählen Erweitern

Unknown argument on choose one of clear defaults:reset,update,old readingFilter:multiple-strict,0.AES_KEY,0.CONFIG_PENDING,0.DEVICE_IN_BOOTLOADER,0.DUTYCYCLE,0.LOWBAT,0.RSSI_DEVICE,0.RSSI_PEER,0.STICKY_UNREACH,0.UNREACH,0.UPDATE_PENDING,1.INHIBIT,1.STATE,1.WORKING config datapoint

Toll.
Den Thread habe ich inzwischen auch gefunden.

Muss bei Gelegenheit mal durchforsten, was genau ich jetzt abändern muss, dass es wieder wie gewohnt funktioniert.


Stinkt mich aber gerade schon etwas an!
Ich habe das System, um mir gewisse Abläufe zu erleichtern - nicht um mich überraschen zu lassen, dass es plötzlich nicht mehr funktioniert.
Dann noch Fehlersuche und eventuelle Anpassungen.
Ich will mir Zeit sparen und nicht noch ständig eine weitere "Baustelle" im Blick behalten ...

[marvin78]

Augen auf beim Update. Bei mir steht das Modul aktuell auf "exlude_from_update", bis ich Zeit habe, mich mit den Anpassungen zu beschäftigen. Aber ich mache ein Update auch nicht nebenbei. Das wäre nicht clever

[Beta-User]

Ergänzend: Die Testphase dauert schon länger, das ist keine Überraschung!
Also: Entweder rechtzeitig mit testen, oder dann eben Vorbereitungen treffen, oder eben (mehr oder weniger) ungeplant Nacharbeiten. Stillstand ist auch keine Option...

(Aber die Reaktion ist ein gutes Beispiel dafür, wie "normal" es bei FHEM ist, dass man in der Regel völlig gefahrlos "nebenbei" updaten kann ).

[remo]

Genau. Der Fehler saß zwischen Bildschirm und Rückenlehne

1. Update: lief sauber
2. Update: lief sauber
ab dem 3. schaut man dann nicht mehr so genau hin.
und das 4. läuft dann "nebenbei" ...

Dass es kommuniziert wurde ging an mir vorbei.
Auch die Testphase.

Da muss ich in Zkunft wohl etwas achtsamer sein...

[Otto123]

... und wenn nicht viel Zeit ist, auch wissen wie restore funktioniert
https://wiki.fhem.de/wiki/Update#R.C3.BCcksichern_beim_Update_.C3.BCberschriebener_Dateien
Dann hat man das Problem fast genauso schnell behoben wie update ausgeführt