[gelöst] MAX device is already defined, ich kann es aber nicht finden

[Uef]

Hallo zusammen,

ich komme hier leider nicht mehr weiter und brauche Eure Hilfe.
ich habe die Tage einen meiner MAX Heizkörperthermostate aus der Kiste gekramt, um ihn in der Küche wieder zu montieren.
Durch mechanische Einwirkung war bei dem HKT das Gehäuse mehrfach beschädigt und daher hatte ich das gegen Gehäuse getauscht, die ich von defekten Thermostaten (bei ebay gekauft) genommen hatte. Ich erwähne das, weil ich mich dadurch nicht mehr auf die ID auf dem Aufkleber am Gehäuse verlassen konnte.

Daher wollte ich das HKT neu pairen.
Grundsätzlich funktioniert das Pairen wohl auch, da der Pair-Countdown am HKT bereits nach 2 Sekunden endet.
Allerdings taucht dann kein entsprechendes Device dazu auf (autocreate steht auf 1).
Mit verbose auf 5 für CUL_MAX findet sich im log dann folgendes:

Code: [Auswählen]

2022.05.08 11:10:12.711 5: CUL_MAX, IODev CUL_0, len 23, msgcnt 00, msgflag 04, msgType PairPing, src 0991f5, dst 123456, group 0, payload 1801FF4B455130343539343737, rssi -92.5
2022.05.08 11:10:12.712 4: CUL_MAX, PairPing (dst 123456, pairmode 1), firmware 24, type HeatingThermostat, testresult 255, serial KEQ0459477
2022.05.08 11:10:12.713 3: CUL_MAX, Re-Pairing device MAX_0991f5 of type HeatingThermostat with serial KEQ0459477
2022.05.08 11:10:12.714 5: CUL_MAX: dispatch MAX,1,define,0991f5,HeatingThermostat,KEQ0459477,0
2022.05.08 11:10:12.714 5: MAX_Parse, MAX,1,define,0991f5,HeatingThermostat,KEQ0459477,0
2022.05.08 11:10:12.715 1: MAX_Parse, ohne Namen msg: MAX,1,define,0991f5,HeatingThermostat,KEQ0459477,0
2022.05.08 11:10:12.740 1: ERROR: empty name in readingsBeginUpdate
2022.05.08 11:10:12.740 1: stacktrace:
2022.05.08 11:10:12.741 1:     main::readingsBeginUpdate           called by ./FHEM/14_CUL_MAX.pm (862)
2022.05.08 11:10:12.741 1:     main::CUL_MAX_Parse                 called by fhem.pl (4128)
2022.05.08 11:10:12.742 1:     main::Dispatch                      called by ./FHEM/00_CUL.pm (975)
2022.05.08 11:10:12.742 1:     main::CUL_Parse                     called by ./FHEM/00_CUL.pm (840)
2022.05.08 11:10:12.743 1:     main::CUL_Read                      called by fhem.pl (3932)
2022.05.08 11:10:12.743 1:     main::CallFn                        called by fhem.pl (781)
2022.05.08 11:10:12.744 1: readingsUpdate(,firmware,1.8) missed to call readingsBeginUpdate first.
2022.05.08 11:10:12.744 1: stacktrace:
2022.05.08 11:10:12.745 1:     main::readingsBulkUpdate            called by ./FHEM/14_CUL_MAX.pm (863)
2022.05.08 11:10:12.745 1:     main::CUL_MAX_Parse                 called by fhem.pl (4128)
2022.05.08 11:10:12.746 1:     main::Dispatch                      called by ./FHEM/00_CUL.pm (975)
2022.05.08 11:10:12.746 1:     main::CUL_Parse                     called by ./FHEM/00_CUL.pm (840)
2022.05.08 11:10:12.747 1:     main::CUL_Read                      called by fhem.pl (3932)
2022.05.08 11:10:12.747 1:     main::CallFn                        called by fhem.pl (781)
2022.05.08 11:10:12.748 1: readingsUpdate(,testresult,255) missed to call readingsBeginUpdate first.
2022.05.08 11:10:12.748 1: stacktrace:
2022.05.08 11:10:12.749 1:     main::readingsBulkUpdate            called by ./FHEM/14_CUL_MAX.pm (864)
2022.05.08 11:10:12.749 1:     main::CUL_MAX_Parse                 called by fhem.pl (4128)
2022.05.08 11:10:12.750 1:     main::Dispatch                      called by ./FHEM/00_CUL.pm (975)
2022.05.08 11:10:12.750 1:     main::CUL_Parse                     called by ./FHEM/00_CUL.pm (840)
2022.05.08 11:10:12.751 1:     main::CUL_Read                      called by fhem.pl (3932)
2022.05.08 11:10:12.751 1:     main::CallFn                        called by fhem.pl (781)
2022.05.08 11:10:12.752 1: readingsUpdate(,PairedTo,123456) missed to call readingsBeginUpdate first.
2022.05.08 11:10:12.753 1: stacktrace:
2022.05.08 11:10:12.753 1:     main::readingsBulkUpdate            called by ./FHEM/14_CUL_MAX.pm (865)
2022.05.08 11:10:12.753 1:     main::CUL_MAX_Parse                 called by fhem.pl (4128)
2022.05.08 11:10:12.754 1:     main::Dispatch                      called by ./FHEM/00_CUL.pm (975)
2022.05.08 11:10:12.754 1:     main::CUL_Parse                     called by ./FHEM/00_CUL.pm (840)
2022.05.08 11:10:12.755 1:     main::CUL_Read                      called by fhem.pl (3932)
2022.05.08 11:10:12.755 1:     main::CallFn                        called by fhem.pl (781)
2022.05.08 11:10:12.756 1: readingsUpdate(,SerialNr,KEQ0459477) missed to call readingsBeginUpdate first.
2022.05.08 11:10:12.756 1: stacktrace:
2022.05.08 11:10:12.757 1:     main::readingsBulkUpdate            called by ./FHEM/14_CUL_MAX.pm (866)
2022.05.08 11:10:12.757 1:     main::CUL_MAX_Parse                 called by fhem.pl (4128)
2022.05.08 11:10:12.758 1:     main::Dispatch                      called by ./FHEM/00_CUL.pm (975)
2022.05.08 11:10:12.758 1:     main::CUL_Parse                     called by ./FHEM/00_CUL.pm (840)
2022.05.08 11:10:12.759 1:     main::CUL_Read                      called by fhem.pl (3932)
2022.05.08 11:10:12.759 1:     main::CallFn                        called by fhem.pl (781)
2022.05.08 11:10:12.760 4: CUL_MAX, send -> cmd:PairPong, msgcnt:02, flags:00, Cmd2id:01, src:MAX_123456 , dst:MAX_0991f5 , gid:00 , payload:00 , cul:none
2022.05.08 11:10:12.761 5: CUL_MAX, send packet: 0b0200011234560991f50000
2022.05.08 11:10:12.762 5: CUL_MAX, Send Queue 1 packet in queue
2022.05.08 11:10:12.827 5: CUL_MAX, Send Queue CUL_0 -> needPreamble: 1, necessaryCredit: 110, credit10ms: 900, CUL_0 CMD_LAST_H: 5
2022.05.08 11:10:12.829 4: CUL_MAX, Send Queue packet send : Zs0b0200011234560991f50000 to MAX_0991f5 with CUL_0
2022.05.08 11:10:13.764 5: CUL_MAX, Send Queue 1 packet in queue
2022.05.08 11:10:13.899 3: CUL_MAX, source device 0991f5 has no name !
2022.05.08 11:10:13.899 5: CUL_MAX, IODev CUL_0, len 14, msgcnt 02, msgflag 02, msgType Ack, src 0991f5, dst 123456, group 0, payload 01193E2D, rssi -90.5
2022.05.08 11:10:13.900 5: CUL_MAX, ACK from MAX_0991f5 for cmd PairPong , packet will be removed soon
2022.05.08 11:10:13.900 5: CUL_MAX, delete packet Index 0 in SendQueue direct !
2022.05.08 11:10:13.901 5: CUL_MAX: dispatch MAX,1,Ack,0991f5,01193E2D
2022.05.08 11:10:13.902 5: MAX_Parse, MAX,1,Ack,0991f5,01193E2D
2022.05.08 11:10:13.902 1: MAX_Parse, ohne Namen msg: MAX,1,Ack,0991f5,01193E2D

Der Pair-request des KHT wird also erkannt und dann versucht, das Device anzulegen. Dann wird festgestellt, dass es ein Device mit der addr 0991f5 bereits gibt.

Eine entsprechende Meldung erhalte ich auch, wenn ich versuche, das Device manuell anzulegen:

Code: [Auswählen]

define MAX_0991f5 MAX HeatingThermostat 0991f5
--> MAX_Define, a MAX device with address 0991f5 is already defined as (auffällig ist, dass nach dem 'as' nichts mehr folgt)

Soweit wäre das ja noch ok, wenn ich auf die device Definition zugreifen könnte.
Allerdings taucht das device nirgendwo auf; vielleicht wegen des leeren Namens; der Umstand steht in der Zeile des MAX_Parse ja auch explizit drin.

Alle MAX devices in list haben andere addr.
In fhem.cfg konnte ich den String '0991f5' ebenfalls nicht finden.

Testweise habe ich dann noch versucht, das Device mit delete MAX_0991f5 zu löschen mit folgendem Ergebnis (als Namen habe ich das Default-Pattern für die MAX devices verwendet):

Code: [Auswählen]

Please define MAX_0991f5 first
Jetzt bin ich mit meinem Latein am Ende.

Hat jemand einen Tipp, wie ich die anscheinend irgendwo doch vorhandene device Definition finde und wieder los werde ?

Gruß aus Aachen
Uwe

[willyk]

Hi,
theoretisch sollte doch die Konfiguration in der fhem.cfg gespeichert sein? Was steht denn da zu dem Device drin?
Gruss
Willy

[Uef]

Hallo Willy,

vielen Dank für Deine Antwort.

In der fhem.cfg taucht die addr 0991f5 gar nicht auf - das ist, woran ich ebenfalls zuerst gedacht habe.
Und die jeweils entsprechende addr findet sich ja sonst bei allen MAX-Devices in der fhem.cfg. D.h. sollte das Device korrekt definiert sein, müsste es hier auftauchen.
Der Code im MAX-Modul scheint aber irgendwo eine - wenn auch unvollständige - Definition mit dieser addr zu finden, sonst gäbe es ja die Fehlermeldung nicht.

Den Code habe ich mir noch nicht angeschaut (bei meinen Perl-Kenntnissen weiß ich auch nicht, ob das wirklich Sinn macht  ). Zudem denke ich, dass nicht der Code das Problem ist, sondern die Daten, die herangezogen werden, um zu prüfen, ob es das Device schon gibt (das zu verstehen, habe ich bei einem anderen Modul schon nicht geschafft; mit Hashes stehe ich Kriegsfuß). Aber aus der fhem.cfg können diese Daten ja eigentlich nicht gelesen werden (s.o.), obwohl das genau meine Annahme wäre.

Nach einem Namen kann ich nicht suchen, weil der gemäss der Fehlermeldungen leer zu sein scheint (womit das MAX-Module ja anscheinend auch nicht gut zurecht kommt; sollte auch eigentlich nicht auftreten).
Leider habe ich auch in alten fhem.cfg (bis zurück nach 2018) nichts dazu gefunden - als hätte es das Gerät nie gegeben.

Das einzige was es als Hinweis in der fhem.cfg gibt, ist, dass ich wohl mal einen Kommentar reingeschrieben hatte für die Definition eines FileLog für ein Device mit dieser addr. Aber das ist alles auskommentiert.

Es grüßt ein ratloser Uwe

[Esjay]

Schau dir mal den "grap" Befehl auf Linux Ebene an. Damit mal das opt/fhem Verzeichnis nach deinem Gerät durchsuchen.

Grüße

[Uef]

Hallo Esjay,

Danke für den Tipp, aber grep bringt leider auch keine anderen Treffer als die bereits genannten in fhem.cfg und den *.log Dateien.
Aber aus irgendeinem Grund muss FHEM doch glauben, dass es das Device schon gibt.

Alles nur wegen dieses einen Devices neu aufsetzen und damit bereinigen, kommt mir jetzt doch (noch  ) etwas übertrieben vor. 

Gruß
Uwe

[DetlefR]

Hallo Uwe,

hast du schon mal versucht, den Thermostaten "abzulernen"?

Sie müssen die Batterien einsetzen, während Sie alle drei Tasten noch gedrückt halten.

aus https://de.elv.com/forum/ablernen/reset-des-max-heizkoerperthermostats-3819.

In deinem Log steht auch was, dass er noch irgendwo bekannt sein muss.

2022.05.08 11:10:12.713 3: CUL_MAX, Re-Pairing device MAX_0991f5 of type HeatingThermostat with serial KEQ0459477

Gruß
Detlef

[gestein]

Was passiert denn nach einem Neustart von fhem?

Gibt es ein Device mit "KEQ0459477" in Deiner fhem.cfg?

lg, Gerhard

[Uef]

Hallo Gerhard, Hallo Detlef,

leider bin ich erst heute wieder dazu gekommen, mich wieder mit dem Problem zu befassen.
@Detlef: leider hat das Ablernen nicht funktioniert (vielleicht liegt das aber auch daran, dass ich einen Cul nutze).
@Gerhard: es gibt in der fhem.cfg keinen Hinweis auf irgendein Attribut dieses HKTs.

Mit etwas mentalem Abstand zu den letzten Versuchen konnte ich das Problem jetzt aber doch beseitigen:
das Ventil hing früher mal im Badezimmer und aus dieser Zeit gab es noch eine Definition des entsprechenden FileLogs (eigentlich sogar noch ein zweites, mit dem ich damals getestet hatte).
Auch in den Defines der FileLogs konnte ich nichts zu dem HKT finden (auch nicht im Regex, falls ich nicht komplett blind bin).

Dann habe ich entschieden, doch auch gleich etwas aufzuräumen und beide FileLog Devices gelöscht.

Und was soll ich sagen: danach konnte ich auf Anhieb den HKT wieder als neues Device anlegen.
Anscheinend haben die Defines der FileLogs no irgendwelche Referenzen auf den HKT enthalten, wieso auch immer.
Vermutlich ist es eine gute Idee, beim Löschen eines Devices auch gleich alle Referenzen zu ihm zu löschen. Klar macht das eh Sinn, aber dass es solche Auswirkungen haben kann, wenn man es nicht macht, hätte ich nicht gedacht.
Vielleicht war auch nur in meiner Konfig irgendwas korrupt.

Egal, jetzt ist das Problem gelöst (wenn auch nicht die Ursache gefunden).
Vielen Dank für Eure Ideen.

LG
Uwe

[DetlefR]

Hauptsache es funktioniert wieder.