MAX Thermostate verlieren IODev

[McUles]

Ich habe mein Haus mit den MAX Heizungsthermostaten ausgestattet und mit Fhem verbunden. Nach ein paar Minuten verlieren diese jedoch ihr IODev in den Internals, das Attribut bleibt bestehen.
Wenn ich dann das Attribut neu setze, funktioniert es wieder für ein paar Minuten und verliert es dann einfach wieder.
In den Logs taucht nichts zu dem Problem auf.
Scanner habe ich bereits installiert. Hier genau das selbe. Der Scanner macht einen Durchlauf und verliert das Thermostat dann auch wieder als assoziertes Device.

Stelle ich mich gerade einfach nur zu blöde an oder woran kann das liegen?

[zweiundzwanzig]

Das hatte ich auch mal... erinnere mich aber dummer Weise nicht mehr an die Lösung. Versuch erstmal fhem.cfg abzuspeichern und einen Neustart.

[McUles]

fhem.cfg hab ich keine, habe vor einer Weile auf configDB umgestellt. Neustart von Fhem habe ich ebenfalls schon versucht

[McUles]

Hat da echt keiner eine Idee dazu?

[Atouk]

Ideen viele, nur kenne ich dazu die spezielle Materie noch zu wenig. Aber manchmal helfen ja gerade die dummen Fragen - und DAS kann ich schon ganz gut:

- Seit wann tritt das Problem auf - vielleicht zufällig ungefähr, seitdem Du auf configDB umgestellt hast? Oder was hat sich sonst geändert? (Aus Deinem Post geht nicht hervor, ob die MAX-Thermostaten alle neu sind, oder schon mal unter FHEM liefen).

- Könnte es sein, dass hier zwei parallel laufende Prozesse auf dieselbe DB / Werte zugreifen und jeweils mit "ihren" Werten überschreiben? FHEM dürfte ja nicht zweimal gestartet sein - zumindest nicht auf derselben Maschine. Aber hast Du vielleicht die configDB auf einem gemeinsamen (gemounteten) Laufwerk und mehrere FHEM-Server im Netz, die sich hier in die Quere kommen?

Viel Erfolg!
- Atouk

[McUles]

Hallo Atouk,

das Problem habe ich seit ich die Thermostate eingebunden habe. Habe ich neu gekauft.
Zwei Prozesse laufen nicht, läuft nur ein Fhem auf der VM, ansonsten würde er theoretisch auch das meckern anfangen das Ports belegt sind.

Ich habe die Thermostate ganz normal über den Maxcube angebunden, jedoch direkt über FHEM und den Cube nur als Gateway genutzt.

[Atouk]

Ich hatte meinen MaxCube zuerst in einer DMZ (zwischen zwei Routern) betrieben, da hatte ich mit der Max-Software zwar Zugriff, musste aber die IP jedesmal neu eingeben. (FHEM lasse ich bisher nur "lauschen", mache noch keine Wochensteuerung darüber - ist erst seit ca. 2 Wochen probe-aufgebaut).

Aufgrund eines Reichweitenproblems steht der Cube jetzt im Heimnetz, und wundersamerweise hat die Max-Software erst jetzt den Bedarf eines Firmware-Updates festgestellt (mehrfach hintereinander, hat aber dann aufgehört).

Wenn Du den Cube nicht umgeflasht hast, also noch die Original-Firmware benutzt, dann könnte man ihn mal über die Max-Software updaten lassen. Die Wahrscheinlichkeit einer Besserung ist zwar gering (erkannt wird er ja, aber irgendwas überbügelt ja die erkannten Werte), aber die Alternative wäre wohl, Dein System in umgekehrter Reihenfolge neu aufzusetzen - und Deiner Fußzeile zufolge könnte das wohl etwas länger dauern...

Oder den Cube mal in einer separaten, "nackten" Umgebung prüfen?

[McUles]

Ja, alles neu aufsetzen würde tatsächlich ein wenig dauern, ist eigentlich noch mehr vorhanden aber das Profil lässt nicht mehr Zeichen zu
Cube läuft noch auf Stock FW, hab von acul erst später gelesen. Könnte ich über die Feiertage aber mal flashen und noch mal neu einbinden.
Alles neu möchte ich eigentlich vermeiden

Aber was könnte den einen Verlust des iodev verursachen?
Habe von so einem Problem noch nie gelesen hier.

[Werner_Hannover]

Ich hatte das Problem auch.
Minimal invasive Lösung:
- Boost Taste auf dem Max Thermostat länger drücken (bis count down zum Anlernen von 30 runterzählt)
- Innerhalb der 30s im FHEM -> MAXLAN -> set <name of your maxcube> -> pairmode => Set & Save

[Wzut]

oh ha , da hat aber einer eine schöne Leiche ausgegraben ....
Warum die Ihr Internal IOdev verlieren ist relativ simpel zu beantworten :
Weil der Modulautor es damals  so wollte bei jedem Connect in 00_MAXLAN :

# We first reset the IODev for all MAX devices using this MAXLAN as a backend.
# Parsing the "C:" responses later on will set IODev correctly again.
# This effectively removes IODev from all devices that are not longer paired to our Cube.

D.h. wenn die nach dem Empfang der C: Nachricht und Auswertung mittels 10_MAX nicht wieder da sind muss man da auf die Suche gehen

@Werner_Hannover, dein Posting ist ein gutes Beispiel dafür wie man es nicht machen sollte.
Deine Lösung bekämpft das Symptom, aber sinnvoller wäre es sich mit der Ursache zu befassen und diese dann dauerhaft und zum Nutzen aller herauszufinden.