Sterbender Cube?

[Nuems]

Ich betreibe mein MAX-System mit zwei Cubes, die als IOGroup zusammenarbeiten:

Code Auswählen Erweitern

define CUL_oben CUL 192.168.2.39:2323 0000
setuuid CUL_oben 63039981-f33f-eda4-dd68-b9c2af44cb310f57
attr CUL_oben maxid 091c98
attr CUL_oben rfmode MAX

define CUL_unten CUL 192.168.2.40:2323 0000
setuuid CUL_unten 6303aa2f-f33f-eda4-d078-f8441a0a23b82104
attr CUL_unten maxid 091c98
attr CUL_unten rfmode MAX

define CM_Unten CUL_MAX 091c98
setuuid CM_Unten 6303b106-f33f-eda4-c352-b68c9ad1acd9f5eb
attr CM_Unten IOgrp CUL_unten,CUL_oben
attr CM_Unten fakeSCaddr 222222
attr CM_Unten fakeWTaddr 111111
Das funktioniert im Allgemeinen auch wie erwartet. Allerdings wird "CUL_unten" alle paar Tage unerreichbar, was sich zuerst durch unplausible Werte bei anderen MAX-Geräten im Webinterface bemerkbar macht. Wenn ich ihn dann kurz stromlos mache, geht es anschließend wieder korrekt weiter, nur um sich wenige Tage später zu wiederholen.
Ist das ein bekanntes Phänomen? Der betroffene Cube ist von 2016 - gibt es Erfahrungen zur Lebensdauer? Und: Kennt jemand eine wirksame Abhilfe?

[Wzut]

Ich habe auch einen der irgendwann etwas zickig wurde, der kam dann in die Bastelkiste.
Für schnelle Tests ist er noch gut zu gebrauchen, als Dauerläufer setzte ich ihn aber nicht mehr ein.

[Nuems]

He's not dead yet...
Irgendwie wollte ich mich mit dem Sterben des Cubes nicht abfinden, insbesondere auch deshalb, weil ich vermeintlich unabhängig von dem oben beschriebenen Fehlerbild diverse weitere MAX-bezogene Fehlermeldungen im Log vorfand, z.B. zu angeblichen Nachrichten unbekannter MAX-Geräte, deren plötzliches Auftauchen ich im Jahr 2025 und angesichts der wohnlichen Gegebenheiten unwahrscheinlich fand. Also habe ich mich in meiner FHEM-Installation auf die Suche gemacht und bin relativ schnell auf die Ursache allen Übels gestoßen: Ich hatte diverse at-Befehle mit getStatus-Abfragen für die MAX-Heizungsthermostate definiert, damit ich immer relativ aktuelle Temperatur- und Ventilstellungsdaten (insbesondere im TabletUI) zu sehen bekomme. Da ich die at-Befehle mehr oder weniger per Copy&Paste mit Anpassung des jeweiligen Namens gesetzt hatte, wurden die ganzen Abfragen fast zeitgleich abgeschickt, was offensichtlich zu Chaos geführt hat. Seit ich die Zeiten für die at-Befehle angepasst habe, läuft der Cube wieder stabil und das Log wird nicht mehr vollgespamt. Fazit: Selbstgemachte Leiden.

[Peer.Gynt]

Hierzu auch meine 2 cents, weil gleiche Erkenntnis:

Nachdem ich den MaxScanner in Rente geschickt habe, 3 CULs und 2 Cubes in Arbeitsteilung den Funkverkehr regeln lasse und mittels at und getStatus die gewünschten Daten für Logs und Plots abfrage, verweigerten immer wieder einzelne Thermostate mehrere Stunden bis halbe Tage die Antwort und es tauchten fehlerhafte Nachrichten auf, die entweder zu falschen Readings führten oder nicht existente Geräte ansprachen. Bei manuellem Abruf oder at->execNow wurde aber immer korrekt und sofort geantwortet.
Dabei hatte ich schon die Zeiten der at gleichmäßig verteilt, so dass die CULs und Cubes immer mindestens 80-90% credits übrig haben, um manuelle Einstellungen vornehmen zu können.
Auffällig war, dass ausgerechnet um 12 und 24 Uhr einige Thermostate aufhörten zu antworten.
Offenbar ist es schädlich, wenn die Thermostate intern schalten und gleichzeitig eine getStatus-Abfrage reinkommt.

Nun habe ich bei allen at das Attribut alignTime auch auf individuelle, krumme Sekunden gesetzt, so dass die Wahrscheinlichkeit, dass diese mit den Schaltpunkten (ganze Minuten) kollidieren, gleich Null ist.

Nun sind sämtliche Plots ohne Unterbrechungen, keine wirren Nachrichten kommen mehr rein und somit bleibt das Log auch übersichtlich.