HomeMatic-Forum / FHZ-Forum

Xel66 hat geschrieben: ↑

07.12.2021, 13:24

uspbc hat geschrieben: ↑

07.12.2021, 12:36

Das Problem tritt aber bei allen Gruppen auf, also alle Gruppen zeigen manchmal einfach alte Werte an.

Das ist wohl auch das, was Du eingestellt hast. Die Frage ist, wird dieses nur im Webinterface so eingestellt oder sind diese unterschiedlichen Werte auch auf den Geräten nachvollziehbar (sprich, die Bude ist kalt). Stimmt letztes, ist es ein Konfigurationsproblem des Anwenders.* Im Moment, wenn das virtuelle Gerät die Werte an die Einzelgeräte verteilt, wird relativ viel gefunkt. Prinzipbedingt kann es dort zu Überlagerungen von Quittierungen kommen (aka Funkstörungen, die sich aber nicht in Kommunikationsstörungen äußern müssen, da die CCU diese Werte nicht erwartet), so dass der Status in der WebUI nicht an die tatsächlichen Einstellungen des Gerätes angepasst werden kann.

EDIT: * laut Posting von 07.12.2021, 13:04 Uhr scheint es wohl so zu sein.

Nein, meine Heizung macht alles so wie sie soll. Nur Werte im virtuellen Gerät werden falsch (veraltet) angezeigt. Und die Funkeinstellungen hab ich in ruhe gelassen, dass sind die ganz normalen von Homematic IP Geräten.

Ich bin sehr neu bei den Homematic Geräten und der CCU. Am ende will ich auch nicht ständig in das WebGUI schauen. Ich will aber erstmal alles so haben wie es sein soll und dann halt gelegentlich mal sachen per App nachsteuern, dafür müssen natürlich die Werte für die Sachen die ich steuern will stimmen. Und dabei ist mir aufgefallen, dass eben einige werte der virtuellen Geräte, also der Heizungsgruppe nicht stimmen, sondern um mehrere Stunden veraltet sind.

uspbc hat geschrieben: ↑

07.12.2021, 13:48

Nein, meine Heizung macht alles so wie sie soll.

Dann haben wir jetzt die ganze Zeit am Thema vorbei geredet.
Und nein, es ist keinesfalls für Heizgruppen normal, dass Daten des Gruppengeräts nicht aktuell sind, das ist dann kein systematisches Problem, sondern dein ganz eigenes, woran immer es auch liegt. Du hast die Konfiguration der Statusmeldungen des virtuellen Geräts auf Standard belassen?

Ich habe allerdings auch schon lange nicht mehr in die Daten des Gruppengeräts geschaut - wozu auch, wenn alles geht.

uspbc hat geschrieben: ↑

07.12.2021, 13:48

Nein, meine Heizung macht alles so wie sie soll. Nur Werte im virtuellen Gerät werden falsch (veraltet) angezeigt.

Dann ist die Lösung, die Aktualisierungsfrequenz durch Abschalten/Reduktion der Statusunterdrückungen zu erhöhen. Ob das die Defaultwerte sind, kann ich mangels HmIP-Heizungsequipment nicht beurteilen. Ich kann mich bei meinen klassischen Thermostaten aber nicht erinnern, dort bewusst die "0" eingetragen zu haben. Ist aber allerdings schon eine ganze Weile her (2013). Da ich ein Statusscript im System habe, welches mir nach großen Änderungen im Heizungssystem (Heizperiodenwechsel, Rückkehr aus längeren Abwesenheiten etc.) eine Statusmail mit einer Zusammenfassung schickt, weiß ich auch, dass manchmal das ein oder andere (gruppierte) Thermostat im CCU-Status (speziell Betriebsart) hinterherhinkt.

Den Duty Cycle pusht es dabei auch über meine erste Meldeschwelle (25%) für ungewöhnliche Systemaktivitäten. Aber bei mir richtet sich das spätestens drei Minuten wieder bzw. ist schon gerichtet, bevor ich mich drum kümmern kann. Würde ich das Script um einen Zyklus verzögern, bekäme ich bis auf den DC davon wahrscheinlich gar nichts mit. Meine Heizungssteuerung läuft größtenteils autark, so dass ich mich nicht drum kümmern muss. Es berücksichtigt meinen Schichtplan, genauso wie Feiertage und Urlaub völlig automatisch. Sogar meine außergewöhnliche heutige krankheitsbedingte Anwesenheit an einer Sollfrühschicht hat es automatisch erkannt und am Vormittag die Solltemperaturen hochgesetzt.

Gruß Xel66

uspbc hat geschrieben: ↑

07.12.2021, 13:11

Ich dachte nicht, dass die so tief in das System eingreifen, sondern nur eine API nutzen würden und nichts kaputt machen.

Sie machen auch nichts kaputt. Tatsächlich ist es ein Bug im Virtual-Devices-Teil des HmIP-Server.
Vereinfacht gesagt meldet sich die externe Logik am Server an und sagt "alle Events bitte an meine Anmeldeadresse schicken". Meldet sich die externe Logik später nicht korrekt ab (weil sie abgestürzt ist, wegen Netzwerkproblemen oder was auch immer) versucht der Server immer weiter die Events zuzustellen und wird sie aber nicht los. Das führt vermutlich zu einem Puffer-Überlauf und zeigt sich in der verzögerten Aktualisierung der virtuellen Geräte.

Edit: Der eigentliche Bug liegt darin daß der Server die nicht erreichbaren Clients nicht nach einem Timeout selbstständig rauswirft. Soweit ich weiß funktioniert das bei allen Schnittstellen korrekt, nur eben bei den virtuellen IP-Devices nicht.

Grüße, Baxxy

Baxxy hat geschrieben: ↑

07.12.2021, 14:03

uspbc hat geschrieben: ↑

07.12.2021, 13:11

Ich dachte nicht, dass die so tief in das System eingreifen, sondern nur eine API nutzen würden und nichts kaputt machen.

Sie machen auch nichts kaputt. Tatsächlich ist es ein Bug im Virtual-Devices-Teil des HmIP-Server.
Vereinfacht gesagt meldet sich die externe Logik am Server an und sagt "alle Events bitte an meine Anmeldeadresse schicken". Meldet sich die externe Logik später nicht korrekt ab (weil sie abgestürzt ist, wegen Netzwerkproblemen oder was auch immer) versucht der Server immer weiter die Events zuzustellen und wird sie aber nicht los. Das führt vermutlich zu einem Puffer-Überlauf und zeigt sich in der verzögerten Aktualisierung der virtuellen Geräte.

Edit: Der eigentliche Bug liegt darin daß der Server die nicht erreichbaren Clients nicht nach einem Timeout selbstständig rauswirft. Soweit ich weiß funktioniert das bei allen Schnittstellen korrekt, nur eben bei den virtuellen IP-Devices nicht.

Grüße, Baxxy

Okay, das ist natürlich doof. Also kann ich keine virtuellen IP-Devices nutzen wenn ich externe Software nutzen möchte, die auf die Geräte zugreift.

Gibt es einen Bug Report für das Problem?

uspbc hat geschrieben: ↑

07.12.2021, 15:02

Also kann ich keine virtuellen IP-Devices nutzen wenn ich externe Software nutzen möchte, die auf die Geräte zugreift.

Falscher Schluss. Du musst dafür sorgen, dass extern genutzte Software, die direkt über ein Interface andockt, sich ordungsgemäß wieder abmeldetet, so dass die CCU nicht vegeblich versucht, ihre Kommunikation auf einem toten Pfad zuzustellen. Bei Apps, die die XMLAPI benutzen, sollte das Problem nicht auftreten.

Gruß Xel66

uspbc hat geschrieben: ↑

07.12.2021, 15:02

Also kann ich keine virtuellen IP-Devices nutzen wenn...

Zunächst mal sollte sichergestellt sein das dieser Bug ursächlich für deine Probleme war.
Wenn die Zentrale neu gestartet wurde, alle externe Steuerung deaktiviert ist und nach paar Tagen die virtuellen IP-Geräte immer noch "synchron" sind kann man das als gegeben sehen.

Für "später" gilt dann das was @Xel66 über mir schrieb.

uspbc hat geschrieben: ↑

07.12.2021, 15:02

Gibt es einen Bug Report für das Problem?

#103

Baxxy hat geschrieben: ↑

07.12.2021, 16:27

Zunächst mal sollte sichergestellt sein das dieser Bug ursächlich für deine Probleme war.

Stimmt, ich sollte nicht zu schnell denken das Problem gefunden zu haben.

Aber dadurch, dass ich wirklich viele verschiedene Apps und Anwendungen getestet und nicht immer alles normal gestoppt habe, kommt es mir sehr wahrscheinlich vor. Aber jetzt habe ich eine gute Theorie bekommen, die ich erstmal überprüfen kann. Danke für die gute hilfe!

uspbc hat geschrieben: ↑

07.12.2021, 17:48

Aber jetzt habe ich eine gute Theorie bekommen, die ich erstmal überprüfen kann.

Kannst du mir sagen, ob du das Problem in der Form bestätigen konntest? Ich bin bei meinem System seit Tagen auf Fehlersuche und habe nach dem Abschalten diverser Faktoren nun noch das Verhalten, das du auch hier beschrieben hast (Raum zeigt nicht die Soll-Werte, die auf den Geräten ankommen)

Vielen Dank dir schon mal fürs Update!