CUL Name geändert --> Fehlermeldung obwohl der Name überall geändert steht

[walterschmitz]

Hallo zusammen,

ich habe - aufgrund von Bezeichnungsproblemen zukünftigerweise durch Systemerweiterung - den Namen vom CUL ändern wollen... und es auch getan
Dazu habe ich sowohl den CUL von CUL_1 auf CUL868 umbenannt, aber auch den CULMAX_1 auf CULMAX868.

Dabei habe ich immer das rename Tool innerhalb von FHEM genutzt und nix von Hand an den Config-Files verändert.
Jeweils anschließend habe ich dann die Änderungen mit Save abgespeichert und anschließend neugestartet.

Dann hab ich kontrolliert, dass die Einstellungen auch überall übernommen wurden, was auch so war.

Jetzt erhalte ich beim Neustart immer folgende Meldungen, direkt auf der ersten Seite:

Error messages while initializing FHEM:
configfile: Wohnzimmer.Wandthermostat: unknown IODev specified
Schlafzimmer.Wandthermostat: unknown IODev specified
Bad.Wandthermostat: unknown IODev specified
Kinderzimmer.Heizthermostat: unknown IODev specified
Schlafzimmer.Heizthermostat: unknown IODev specified
Wohnzimmer.Heizthermostat: unknown IODev specified
Bad.Heizthermostat: unknown IODev specified
Bad.Fensterkontakt: unknown IODev specified
Schlafzimmer.Fensterkontakt: unknown IODev specified
Wohnzimmer.Fenster_links: unknown IODev specified
Kinderzimmer.Wandthermostat: unknown IODev specified
Kinderzimmer.Fensterkontakt: unknown IODev specified
Arbeitszimmer.Balkonfenster: unknown IODev specified

Drängt sich der Arbeitsauftrag auf, die IODEV zu kontrollieren:
Unter Everything steht jetzt folgendes:
CUL:

Code Auswählen Erweitern

IODev CUL868
LASTInputDev CUL868
...
STATE Defined
TYPE CUL_MAX
In den Einstellungen von CULMAX868 steht u.a. bei IODev CUL868 und LastInputDev CUL868
Auch bei den Attribute steht IODev CUL868.

Scheint mir richtig zu sein.

Also weiter zu CUL868.
Hier steht folgendes:

Code Auswählen Erweitern

DEF /dev/ttyACM0@9600 1234
DeviceName /dev/ttyACM0@9600
...
STATE Initialized
TYPE CUL

Und exemplarisch schau ich mal bei einem Wandthermostat nach, was oben angegeben wurde:
Bad.Wandthermostat: unknown IODev specified wurde ja angegeben:
Also...

Code Auswählen Erweitern

CULMAX868_MSGCNT 8
CULMAX868_TIME 2016-02-13 07:57:35
DEF WallMountedThermostat 0a10ee
IODev CULMAX868
LASTInputDev CULMAX868

und reagieren tut das Wandthermostat auch momentan augenscheinlich problemlos.
Habe es gerade mal via FHEM auf Boost gesetzt

Das hier steht im normalen Logfile:
hat meiner Meinung nach aber nix mit der Rename-Umstellung zu tun...

2016.02.13 07:42:59 1: PERL WARNING: Argument "boost" isn't numeric in numeric gt (>) at ./FHEM/98_SVG.pm line 1483.
2016.02.13 07:42:59 1: PERL WARNING: Argument "boost" isn't numeric in subtraction (-) at ./FHEM/98_SVG.pm line 1963.

Filelog von BadWanthermostat:

Code Auswählen Erweitern

2016-02-13_08:00:59 Bad.Wandthermostat mode: boost
2016-02-13_08:00:59 Bad.Wandthermostat battery: ok

was kann ich machen.

[Icinger]

Evtl. hast du die "unknown....."-Meldungen im global:motd stehn?

motd
Message Of The Day. Displayed on the homescreen of the FHEMWEB package, or directly after the telnet logon, before displaying the fhem> prompt. SecurityCheck is setting motd if it is not defined upon startup, to avoid this set the motd value to none. motd is also used to show collected error messages upon fhem start.

lg, Stefan

[walterschmitz]

aus der fhem.cfg habe ich mal alles mit Global vorne entnommen:

Code Auswählen Erweitern

attr global userattr DbLogExclude DbLogInclude cmdIcon devStateIcon devStateStyle icon sortby webCmd widgetOverride
attr global autoload_undefined_devices 1
attr global language DE
attr global logfile ./log/fhem-%Y-%m.log
attr global modpath .
attr global motd Error messages while initializing FHEM:\
configfile: CULMAX0: unknown IODev specified
attr global statefile ./log/fhem.save
attr global updateInBackground 1
attr global verbose 3


Dort steht irgendwas mti motd... ja und was von CULMAX0... den gibt es nicht mehr.
Da ich aber jetzt nix falsch verändern soll....

was mach ich jetzt?
Configfile: CULMAX868 eintragen oder was? Oder einfach löschen?

Danke für den Hinweis, und hoffentlich weitere Ratschläge

[ernst1024]

also ich würde ne Kopie von fhem.cfg und probieren. Kann ja nix passieren

[Icinger]

Code Auswählen Erweitern

attr global motd none

[marvin78]

Ich mache mich mal unbeliebt: Lerne die Grundlagen, bevor du solche tiefgreifenden Dinge machst!

[walterschmitz]

Hi, ich weiß nicht ob die Antwort von Marvin an mich gerichtet ist aber es steht in der Doku zu Rename nirgendwo eine Einschränkung, dass man einen CUL oder CULMAX nicht umbenennen darf. Ausserdem hab ich nicht wirklich auf dem Schirm, wenn es für mich als Anwender nur das Frontend und die fhem.cfg gibt, dass rename ein tiefgreifendes "Ding" sein sollte... aber da geht die Meinung anscheinend aus einander.

rename <oldname> <newname>

Benennt ein Gerät von <oldname> in <newname>, einschliesslich der Attribute, um. Das globale Ereignis "RENAMED" wird erstellt, Lesen Sie bitte den Abschnitt "notify" durch um Details zu erfahren.

Beispiel:
rename FHT_1234 fht.kitchen

Hab ich entsprechend so gemacht und vor allem versteh ich nicht, warum danach ein Fehler gezeigt wurde... also nachdem beide umbenannt wurden.
Die Zuordnungen sind wieder richtig und nach einem Restart gibt es eigentlich keinen Grund, warum MOTD mir den Fehler noch anzeigt.

Bei der ersten Umbenennung okay... aber spätestens, wenn die Fehler behoben sind und die Korrekturen wieder da sind, dann sollten die angezeigten Fehler auch aktuell sein. Sind sie aus meiner Sicht aber nicht (mehr).
Daher funktioniert ja auch alles noch und wieder.

Das einzige was halt noch falsch ist, ist der Eintrag

Code Auswählen Erweitern

configfile: CULMAX0: unknown IODev specified.
Da müsste man aber sagen, dass die Funktion RENAME nicht richtig bzw. vollständig gearbeitet hat.

Kann ich das einfach ändern? Wurde die ggf. auch auf der Festplatte umbenannt? Warum wurde die dann nicht auch in der fhem.cfg geändert?
Lt. Doku steht unter dem Punkt motd

configfile
Enthält den Namen der FHEM Konfigurationsdatei. Wenn save ohne Argumente aufgerufen wird dann wird die Ausgabedatei unter diesem Dateinamen gespeichert.

Ich finde es irgendwie komisch. Mal wird einem abgeraten direkt in den Verzeichnissen zu arbeiten. In dem Fall geht es anscheinend nicht anders... naja.
Daher frag ich ja.

Ausserdem ist dann die Error-Meldung missverständlich für einen Anwender:

configfile: Wohnzimmer.Wandthermostat: unknown IODev specified

da sucht man eher beim Wandthermostat, als im MOTD-Bereich. Aus meiner Sicht nicht ganz Nutzer freundlich erklärt.

Trotzdem in der Hoffnung, weitere Antworten zu bekommen, damit man es versteht... das Ziel, was Marvin ja auch will

[walterschmitz]

So... bin dann dem ganzen mal hardwareseitig auf dem Raspberry auf den Grund gegangen.

Im Frontend auf raspberry:8083 wurden jeweils bei den Devices die IODev-Einträge mit CULMAX868 angezeigt.
Auf File-Ebene auf dem Raspberry direkt wurden in der fhem.cfg bei einer Suche nach CULMAX0 aber mehrere Einträge angezeigt... und da wirklich auch da, wo die Fehler angezeigt waren.

Also...
Der Fehler ist für den Anwender, der auf Fileebene gar nicht arbeiten soll auch gar nicht auffindbar
Nur nachdem ich das von Hand geändert habe, ist die Meldung von MOTD auch - jetzt richtigerweise - weg.

Fazit:
1.) Die RENAME-Funktion arbeitet hier überhaupt nicht richtig. Oder es muss in der Doku ein Hinweis gegeben werden, dass es beim CUL / CULMAX halt nicht funktioniert
2.) Warum werden unterschiedliche Daten angezeigt zwischen Frontend-Devices und der fhem.cfg --> nicht zielführend bei einer Fehlersuche und wenn man danach geht, dass im Frontend alles (richtig) angezeigt wird, die Hardware auch noch das macht, was ich gerade anklickere, dann kann ich als Anwender nur unterstellen, dass alles richtig eingestellt ist und dann passt der Fehler halt nicht zu den angezeigten Werten! Ich denke, dass sollte aber mal von den Programmierern entsprechend angepasst werden!

[marvin78]

Wie mit motd umgegangen werden muss, steht in der Doku. Dass man ein IODev (als sehr zentrales Device) eventuell nicht einfach ohne Nebenweirkungen umbenennen kann, kann man sich denken, wenn man die Grundlagen von FHEM begriffen hat. rename arbeiter richtig und genau, wie in der Doku beschrieben.

FHEM ist und bleibt kein Kilcki-Bunti System. Die Doku ist gut und richtig, die Struktur klar. Wenn man unsicher ist, fragt man, bevor man etwas macht oder man sucht im Forum nach ähnlichen Erfahrungen. Ich sehe hier das Problem alleine auf Anwenderseite.

Edit: Und wenn man Misstände beheben will, die nur aus eigener Sicht überhaupt welche sind, reicht man übrlicherweide einen entsprechenden Patch ein oder fragt nett, ob das geändert werden kann (im richtigen Forum).