HM-CC-RT-DN mit LaCrosse virtuelle Temperatur Sensoren hat Aussetzer

[Hollo]

Wo ist das Problem?
Wenn man einen externen Sensor nutzt um die temp an den virtuellen Sensor zu schicken und der virtuelle Sensor schließlich die temp an den realen aktor uebermittelt sollte das timing identisch sein...

Da ich es noch immer nicht verstehe... wird die Temperatur an den Thermostat gesendet, oder von ihm abgerufen?
Das virtuelle Device oder auch das Wandthermostat hat ja quasi immer eine Temp, egal ob die nun aktualisiert wurde oder nicht.
Virtuelles Device und Wandthermostat müssen diese Temp nun an den gepeerten Thermostatkanal über geben... woher weiss jetzt das Wandthermostat "besser" wann der passende Zeitpunkt ist?

Rein subjektiv würde ich sogar behaupten, dass das schon mal reibungslos funktioniert hat.

[Merlin]

Wo ist das Problem?

Das Problem ist das es nicht funktioniert. Ich stelle hier jetzt sogar die Behauptung auf das es mit dieser Konfig niemande gibt wo es funktioniert! Man möge das Gegenteil beweisen.

Wenn die Zeit gekommen ist, schreibt der in den RT.

Da ist es. Genau da würde ich das Problem vermuten. Laut meinen Logs sendet der virtuelle Aktor nämlich immer wieder zu Zeiten wo der RT im schlafmodus ist. das meinte ich mit ins leere gehen. Und wenn das ein paar mal passiert schaltet der RT wohl auf den internen Sensor um.

Ich frage mich gerade ob meine Ausführungen dazu wirklich so schwer zu verstehen sind

Da ich es noch immer nicht verstehe... wird die Temperatur an den Thermostat gesendet, oder von ihm abgerufen?

Ich hab in all meinen RAW Logs nirgends einen Abruf gesehen. Die Temp geht einfach "irdendwann" als Broadcast raus.

... woher weiss jetzt das Wandthermostat "besser" wann der passende Zeitpunkt ist?

Hollo hat mich verstanden genau das war auch meine Frage. wie ich verstanden habe wird dieser Zeitpunkt berechnet (2,5-3min) nach irgendeiner Formel. Vermutlich die selbe Formel die dem RT sagt wann er aufwachen und Statusbericht senden soll. So weit so gut. Aber wie erfolgt die synchronisation dieser Zeiten am Anfang? Kann da das Problem sein?

[martinp876]

Die wandthermostate errechnen es nach dem gleichen algo wie er im virto genutzt wird. Und der RT wacht entsprechend auf.
Der RT fragt nicht. Aber das alles kannst du sehen, wenn du 20 min logst. Dazu braucht du keine 50h Arbeit.

Der algo steht im code  culhm wenn du ihn suchst. Nur ist es brotlose Kunst. Ist implementiert, du kannst es einfach nutzen. Es wird nicht schneller werden.

[Gerd]

Wenn ich mal laienhaft fragen darf, was macht ein Wandthermostat denn anders als der virtuelle Sensor, wenn es der selbe Algorythmus ist ? Irgendwas muss da doch anders sein.
Ich sehe in meinen Plots auch immer mal einzelne Aussetzer, bei allen RT mit externem LaCrosse Sensor, in denen dann der interne Temperaturwert genommen wird, manchmal auch über einen längeren Zeitraum.
Wie deckelsmouk geschrieben hat hat er die Aussetzter nur mit den virtuellen Sensoren nicht mit den Raumthermostaten, somit ist es kein grundsätzliches Problem sondern es hängt mit dem Zusammenspiel virtuelles Device und RT zusammen.

[tpm88]

Das Problem ist das es nicht funktioniert. Ich stelle hier jetzt sogar die Behauptung auf das es mit dieser Konfig niemande gibt wo es funktioniert! Man möge das Gegenteil beweisen.

Das Peering eines RT-DN mit einem virtuellen Temperatursensor hat bei mir über Monate (nahezu) reibungslos funktioniert. Hierzu verweise ich auf folgenden Thread: http://forum.fhem.de/index.php/topic,19686.msg260702.html#msg260702
Aus persönlicher Erfahrung würde ich sagen, daß diese Aussetzer (die ich anfangs auch beobachtet habe) grundsätzlich auf Verzögerungen innerhalb des FHEM-Servers, die andere Module verursachen, zurückzuführen sind. Der o.a. Algorithmus berechnet dann zwar den richtigen Sendezeitpunkt, dieser wird aber aufgrund einer Verzögerung (=> über apptime aufspürbar) verpasst. Da das Timing bei HM sehr kritisch ist, kommt es zu den Aussetzern.

Seit einigen Monaten habe ich den virtuellen Temperatursensor durch Dirks Universalsensor ersetzt. Dort gab es anfangs beim Peering mit dem RT-DN ähnliche Aussetzer. Meines Wissens verwendet Dirk in der Firmware  (ab v14) des Sensors aber den gleichen Algorithmus zur Berechnung des Sendezeitpunkts.

Trotzdem kann ich daher nicht mit Sicherheit sagen, daß das Peering mit einem virtuellen Sensor mit den aktuellen Modulversionen immer noch reibungslos funktioniert.

@Merlin - Du schreibst, du hast bereits eine Testumgebung aufgebaut. Um Verzögerungen durch andere Module auszuschließen, würde ich einen Test mit Minimalkonfiguration wie folgt machen
- neue FHEM Instanz (default fhem.cfg) mit aktuellen Updates auf sonst möglichst unbenutzter Hardware installieren
- Einbinden JeeLink für LaCrosse Empfang und HM CUL / CFG-USB2 für HM Kommunikation
- Einrichten VCCU
- Pairen von 1x RT-DN
- Einrichten virtuellen Temperatursensor
- Einrichten Peering zw. virt. Tempsensor und RT-DN
- Kontrolle mit HMINFO configCheck und peerXref, ob Peering ok
- ggf. apptime starten

=> Wenn es dann immer noch zu Aussetzern kommt, einen PacketSniff aufsetzen und Martin bitten, diesen zu analysieren.

Tobias

[Merlin]

Der o.a. Algorithmus berechnet dann zwar den richtigen Sendezeitpunkt, dieser wird aber aufgrund einer Verzögerung (=> über apptime aufspürbar) verpasst. Da das Timing bei HM sehr kritisch ist, kommt es zu den Aussetzern.

OK ein weiterer Ansatz.
Kann ich davon ausgehen das der "richtig Zeitpunkt" der ist wo der RT wach ist? Also kurz nach seinem Statusbericht?
Falls ja: Dann liege ich laut meinen Logs oftmals auch um 1-2 Minuten daneben. Und: Wieso verwendet man dann nicht den Statusbericht als Trigger so wie es andere "non Burst" Übertragungen zum RT erfolgreich machen?
Falls nein: Ich versteh die Welt nicht mehr und geb auf wenn ich keine logische Erklärung finde 

Und wegen der Testumgebung: Da muss ich mir noch einen 2. CUL besorgen für losgelöste Tests...

[tpm88]

Kann ich davon ausgehen das der "richtig Zeitpunkt" der ist wo der RT wach ist? Also kurz nach seinem Statusbericht?
Falls ja: Dann liege ich laut meinen Logs oftmals auch um 1-2 Minuten daneben. Und: Wieso verwendet man dann nicht den Statusbericht als Trigger so wie es andere "non Burst" Übertragungen zum RT erfolgreich machen?
Falls nein: Ich versteh die Welt nicht mehr und geb auf wenn ich keine logische Erklärung finde 

Ein klares NEIN. Nach meinem Verständnis von Martins Ausführungen (weiter oben hier und in zahlreichen anderen Stellen im Forum) ist der Zeitpunkt zum Senden der "pending commands" bei non-burst Befehlen nicht identisch mit dem Senden der Ist-Temperatur für das Peering.

Und wegen der Testumgebung: Da muss ich mir noch einen 2. CUL besorgen für losgelöste Tests...

Nicht unbedingt. Wenn Du es dir leisten kannst, die produktive Umgebung z.B. über Nacht einmal stillzulegen, könntest Du auch eine zweite FHEM Instanz in einen anderen Pfad auf der gleichen Hardware installieren und mit dieser testen.

Noch etwas anderes. Das HM-Timing bei Verwendung eines CULs ist für FHEM noch schwieriger einzuhalten, da die Standard CUL Firmware keine Timestamps (im ms Bereich) liefert. Hier empfiehlt sich dringend die von noansi entwickelte Firmware für HM mit Timestamps: http://forum.fhem.de/index.php/topic,31421.0.html Bei mir hat diese FW erst ein vernünftiges HM-Timing meiner FHEM-Instanz auf einem Raspberry PI (1. Generation - vergleichsweise langsame Hardware) ermöglicht.

Gruß,
Tobias

[Merlin]

Ein klares NEIN. Nach meinem Verständnis von Martins Ausführungen (weiter oben hier und in zahlreichen anderen Stellen im Forum) ist der Zeitpunkt zum Senden der "pending commands" bei non-burst Befehlen nicht identisch mit dem Senden der Ist-Temperatur für das Peering.

OK nehme ich mal so leicht verwirrt hin. Was allerdings insofern mein "Weltbild" von den RT's erschüttert, weil ich dachte das die in der Zeit zwischen ihren Übertragungen schlafen...
Ist das eigentlich alles irgendwo niedergeschrieben? Oder woher habt ihr dieses Wissen? Würde mich da gerne auch mal schlau machen dazu.

Das HM-Timing bei Verwendung eines CULs ist für FHEM noch schwieriger einzuhalten, ...

Hmm Frage: Wenn das alles bei mir mal im endgültigen, dauerhaften Echtbetrieb ist brauch ich sowieso ein Reservedevice. Wäre es nach deiner Aussage besser statt einen 2. CUL ein HMLAN anzuschaffen?

[tpm88]

Ist das eigentlich alles irgendwo niedergeschrieben? Oder woher habt ihr dieses Wissen? Würde mich da gerne auch mal schlau machen dazu.

naja, irgendwo schon  Hier im Forum. Aber üblicherweise nicht an einem Ort. Generell viele Infos findest Du natürlich auch im Wiki. Wenn man eine Weile im Forum interessiert mitliest, wird man schlauer...

Was das Schlafen/Aufwachen des RT angeht. Gefühlt muß ich bei dem RT mit "gepeerten" Temperatursensor deutlich häufiger die Batterien wechseln als bei denen ohne. Offenbar wacht er deutlich häufiger auf (oder ist länger wach).

Hmm Frage: Wenn das alles bei mir mal im endgültigen, dauerhaften Echtbetrieb ist brauch ich sowieso ein Reservedevice. Wäre es nach deiner Aussage besser statt einen 2. CUL ein HMLAN anzuschaffen?

Meiner Meinung macht ein echtes, separates FHEM-Testsystem (z.B. zweiter RPi ) definitiv Sinn.  Statt eines HMLAN würde ich den HM CFG USB 2 nehmen in Verbindung mit dem hmland. Der ist billiger und kann im Gegensatz zum HMLAN auch OTA Firmware Updates bei HM Devices durchführen. Ich habe auch mit einem CUL begonnen und bin später auf dem Produktivsystem auf dem HM-CFG-USB2 umgestiegen. Den CUL nutze ich auf dem Testsystem - siehe auch meine Signature.

[Hollo]

Das Peering eines RT-DN mit einem virtuellen Temperatursensor hat bei mir über Monate (nahezu) reibungslos funktioniert. ...
Aus persönlicher Erfahrung würde ich sagen, daß diese Aussetzer (die ich anfangs auch beobachtet habe) grundsätzlich auf Verzögerungen innerhalb des FHEM-Servers, die andere Module verursachen, zurückzuführen sind...

Da stimme ich Dir generell zu.
Ich glaube/meine auch, dass das eine lange Zeit problemlos funktioniert hat.
Nur weiss ich nicht, was ich sich in der Zwischenzeit alles geändert hat. 

Das es Unterschiede im Zeitverhalten gibt, sehe ich gelegentlich bei der Aktualisierung meines RSS-Tablets.
Das geht lange problemlos ohne sichtbare Verzögerungen, und dann plötzlich gibt es beim Laden/Aktualisieren "Verzögerungen".
Auch ohne Änderungen an der Konfiguration in der Zwischenzeit.

"Leider" mache ich natürlich häufig Updates. Ich werde das mal ein wenig genauer beobachten und öfter die Logfiles kontrollieren.

[martinp876]

also eins nach dem anderen.
der Virtuelle Temp-Sensor sendet immer nach dem gleichen Timing. Idee ist, dass man per Kommando die Temp setzt. Irgendwann. Diese wird dann beim nächsten Senden übertragen.
Woher die temp kommt ist egal.
Wenn man genau zum Sendezeitpunkt anfängt, eine temp zu ermitteln wird dies schief gehen. Das Timing ist zu eng.

somit die erste Frage:
- geht der virtuelle Sensor - ohne extra Firlefanz?

dann 2.
- wollt ihr synchron zum virtuellen Aktor aktionen ergreifen? Ich hoffe nicht.

und 3.
- ist 1 und 2 erledigt: geht es immer noch nicht? Wird tatsächlich das Timing verändert durch das setzen der temp?

[Merlin]

OK Martin.Soweit verstanden. Zu deinen Fragen:

1 und 2. : Ja Sensor geht, und bewusst eine Aktion synchron starten will ich nicht (könnte ich ja gar nicht weil das Timing ja unbekannt ist). Die Temp Daten sind schon im virtuellen Sensor drinnen und zwar per at. Wobei es vollkommen egal ist ob der setzende at alle 1,2, oder 3 Minuten läuft oder auch garnicht - denn es wird ja sowieso immer das letzte Reading vom virtuellen sensor übertragen. Egal wie alt es ist.

3.: Ich glaube nicht das sich das timing verändert durch das setzten. Es stimmt halt dann irgendwie plötzlich einfach nicht mehr.

Eine Interessante Beobachtung habe ich aber jetzt gemacht:
Wenn so ein Aussetzer auftritt, dann oft gleich in Gruppen aber nicht immer. Also dann setzt die Übertragung gleichzeitig auch mal bei 3 oder 4 RT's aus und kommt zb nach 15 min zur gleichen Zeit wieder...

[martinp876]

OK, dann ist es ein Problem des virtuellen Sensors.
Es kann auch ein performance Problem sein. Fhem hat keine strikte Periodisierung. Eigentlich garkeine.
Timer kommen immer nur dran, wenn der"os-level" dran ist. Läuft ein job zu lange verschiebt er das timing.
Apptime gibt dir Auskunft, ob delays auftreten und\oder Langläufer unterwegs sind. Prüfen das einmal.

[Merlin]

Update:
Habe jetzt testweise mal von cul auf hmusb gewechselt. Keine Verbesserung. Im Gegenteil scheint sogar etwas schlimmer geworden zu sein.
Was mich irgendwie dazu bringt doch die Systemhardware (Raspberry 2) zu verdächtigen. Scheint als hätte der weitere zusätzliche Dienst (der hmland) für eine Verschlimmerung gesorgt. Was mich zwar wundert den es ist eine schneller Raspberry und da läuft nur die HM und Lacrosse Funksache drauf. Keine einzige Berechnung, kein Log, nix. Kommt alles vom virtuellen Haupt-fhem Rechner über fhem2fhem.

Nächster Test:
portieren der Raspberry Installation auf eine andere, stärkere Hardware (altes Notebook). Mal sehen...

[frank]

Nächster Test:
portieren der Raspberry Installation auf eine andere, stärkere Hardware (altes Notebook). Mal sehen...

oder hat dein fhem hänger? => siehe apptime, perfmon.

Apptime gibt dir Auskunft, ob delays auftreten und\oder Langläufer unterwegs sind. Prüfen das einmal.