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

[Merlin]

So, mal sehen was sich über Nacht und Morgen noch tut. Aber im Moment würde ich sagen so geht es. Mit dem Versuchsaufbau habe ich jetzt die durchschnittlichen Laufzeiten der ganzen Tasks auf 15-20ms herunten und den max Delay auf 50ms.

Das löst zwar noch nicht das eigentliche Problem aber bringt uns zu der Erkenntnis, dass hier offensichtlich das Timing noch viel kritischer ist als angenommen. Mein voriger Aufbau mit 100ms Laufzeiten und 350ms max Delay brachte schon Probleme auf der selben Hardware.
Ob und wenn ja wie uns das jetzt weiter bringt wird sich zeigen und hängt einerseits davon ab was uns Martin noch zu möglichen Verbesserungen beim Timing sagen kann (ist das wirklich soo heikel? Kennen wir das Zeitfenster für eine korrekte Übertragung?) und andererseits von der Frage ob es irgendwie möglich wäre diesen Sendebefehl zu priorisieren (fürchte auch nicht so einfach).

Ich lass meinen Versuchsaufbau erstmal noch ein paar Tage laufen und sehe obs stabil bleibt und Berichte weiter.

[Merlin]

Also nach mehr als 4 Tagen kann ich sagen, dass meine Aussage von oben sich bestätigt hat.
Es ist sehr viel besser aber halt nicht perfekt.
Ich weis jetzt einerseits keine weiter Optimierungsmöglichkeit und habe andererseits überhaupt keine Idee wie ich diesen jetzt aber schon recht guten Zustand auf einer gemeinsamen Produktivumgebung abbilden könnte.
Hat noch jemand weitere Vorschläge oder Ideen?

[martinp876]

Mit dem Versuchsaufbau habe ich jetzt...

was ist der Versuchsaufbau?

dass hier offensichtlich das Timing noch viel kritischer ist als angenommen.

keine Ahnung, was du angenommen hast.

Kennen wir das Zeitfenster für eine korrekte Übertragung?

ja

und andererseits von der Frage ob es irgendwie möglich wäre diesen Sendebefehl zu priorisieren

nein. zum einen kann (soll/muss) man in FHEM prozesse mit langer laufzeit forken (auslagern in subprozess) zum anderen ist es möglich, dass die CPU(s) am ende sind. Dann wäre eine Priorisierung auf OS-level notwendig. Viel Spass.

Hat noch jemand weitere Vorschläge oder Ideen?

wenn du erst einmal darlegst
- was du gemacht hast
- welche Tasks zu langsam sind
- ob es FHEM tasks sind oder du einen Server allgemein überlastest
kann jemand mitdenken. Dann kann man überlegen, wo man prioritäten schieben kann, ob es eim problem eines blocking wait oder einer echten Aufgabe ist,....
FHEM läuft nicht beliebig mit anderen Applikationen  - wie auch?

[Merlin]

was ist der Versuchsaufbau?
.. zum anderen ist es möglich, dass die CPU(s) am ende sind...
wenn du erst einmal darlegst
- was du gemacht hast
- welche Tasks zu langsam sind
- ob es FHEM tasks sind oder du einen Server allgemein überlastest
...

Martin, mir ist schon klar das du bei der Menge von Postings nicht alles im Kopf haben kannst. Aber es wäre schon hilfreich in einem Thread wo du Antwortest auch die Postings dazu zu lesen. Ich habe das alles in meinen Postings hier schon beschrieben.

Nochmal die Kurzversion: Der jetzige Aufbau ist nur die für HM notwendige Mindestkonfiguration ganz alleine auf einem PC. Ohne irgendwelche Logs, IF's oder sonstige Berechnungen. Nur die RT's und die VT's (welche die Daten per FHEM2FHEM bekommen).

Das funktioniert recht gut im Verhältnis zu allem anderen aber auch nicht zu 100%.
Sobald man auch nur ein wenig andere Last drauflegt wird es sofort schlimmer. (Dazu reicht schon das einlesen der Lacrosse Sensoren mit Laufzeiten von 100ms)

Es gibt also keinen bestimmten Task der zu langsam läuft und auch sonst keine Applikationen drauf.

Das ganze System wird offensichtlich mit zunehmender Anzahl von zu bedienenden RT's/VT's (hier 12 Stk.) so zeitkritisch das es schon mit sich alleine die Stabilitätsgrenze erreicht.

[Hollo]

Dann will ich mal gerade meinen aktuellen Stand ergänzen.

...
Das ganze System wird offensichtlich mit zunehmender Anzahl von zu bedienenden RT's/VT's (hier 12 Stk.) so zeitkritisch das es schon mit sich alleine die Stabilitätsgrenze erreicht.

Ich habe:
- 1x HM-CC-RT-DN "nackt", also interner Sensor
- 1x HM-CC-RT-DN mit Wandthermostat als externem Sensor
- 2x HM-CC-RT-DN mit LaCrosse-Sensoren
Das sollte problemlos gehen bzw. hat ja auch schon problemlos gelaufen.

Ein Downgrade des "schlechtesten" Thermostaten auf FW 1.3 hat keine subjektiv keine Veränderung gebracht.
Ich habe 2 Thermostate mit jeweils LaCrosse-Sensor als externem Temp.-Wert.
Nur bei diesem schlechtesten (Küche) habe ich so häufig das blinkende Antennensymbol und die ständige "Fenster-offen-Erkennung" durch Wechsel vom internen zum externen Sensor.

Meine aktuellen Überlegungen:
- haben die beiden Thermostate wirklich Empfangsprobleme?
- Büro und Küche sind die Thermostate, die ich zuletzt gekauft habe;
  gibt es Unterschiede (Produktionszeitraum, Charge, Generation)?
- ich habe meinen Jeelink-Clone auf "Superjee" umgebaut; welchen Einfluss hat das evtl. ?

und nochmal bzgl. Timing...
Wenn Hzgs.-Thermostat, Wand-Thermostat und virtueller Kanal den selben Algorithmus zur Berechnung des Zeitpunktes benutzen, so müssten sie aber auch alle über die selbe Systemzeit verfügen, damit es einen einheitlichen Start-/Triggerzeitpunkt gibt, oder nicht?

Die "Delay-Zeiten" der FHEM-Installation schwanken IMHO je nach gleichzeitiger Aktionen und Updates von Modulen sehr stark; erkennen kann ich das an der mehr oder weniger flüssigen Aktualisierung meines RSS-Tablets.

[frank]

Die "Delay-Zeiten" der FHEM-Installation schwanken IMHO je nach gleichzeitiger Aktionen und Updates von Modulen sehr stark; erkennen kann ich das an der mehr oder weniger flüssigen Aktualisierung meines RSS-Tablets.

zeig mal ein fhem.log mit gestartetem perfmon modul und global verbose 1.

[Merlin]

Dann will ich mal gerade meinen aktuellen Stand ergänzen.Ich habe:
- 1x HM-CC-RT-DN "nackt", also interner Sensor
- 1x HM-CC-RT-DN mit Wandthermostat als externem Sensor
- 2x HM-CC-RT-DN mit LaCrosse-Sensoren
Das sollte problemlos gehen bzw. hat ja auch schon problemlos gelaufen.

Würde es vermutlich wenn auf dem Server sonst nix läuft und der Empfang ok ist.
Meiner Erkenntnis nach kann jeder Task, jedes DOIF, Notify, usw das zum genau richtigen Zeitpunkt das system für nur ca 100ms blockiert schon zu Problemen führen. So stellt es sich zumindest bei mir dar. Schlechter Empfang kann natürlich auch was zum Problem beitragen. Dann kommt zwar der VT send zum richtigen Zeitpunkt, aber der RT vertehts halt wege neinem Empfangsprobem nicht. Auch des Empfangen und abarbeiten einer Statussendung eines anderen RT zur falschen Zeit kann möglicherweise schon eine Verzögerung hervorrufen. Daher ja meine (noch unbeantwortete) Frage wie groß eigentlich das Zeitfenster ist.

Was mich in dem Zusammenhang auch noch interessieren würde: Wenn der RT nun alle 2,5 Min einen Temperatur Empfang erwartet und  dieser kommt nicht/falsch/zu spät daher, wieviele solcher 2,5 Minuten Fenster wartet er bevor er auf den internen Sensor zurück springt? Ich fürchte gar nicht oder nicht oft....

[martinp876]

Jedenfalls nicht sofort. Ich denke wir haben mit 3 bis 5 Aussetzern erfolgreich experimentiert.

[Merlin]

Kann sich das mit einem FW update verändert/verschlechtert haben?

[Merlin]

Kann sich das mit einem FW update verändert/verschlechtert haben?

Wohl nicht. Nach nochmaligem durchlesen von http://forum.fhem.de/index.php/topic,19686.0.html
komme ich zu dem Schluss, dass es in einer Produktivumgebung noch nie wirklich stabil funktioniert hat.

Ich beginne jetzt wohl damit über Alternativen nachzudenken um diese Konfiguration wieder abzulösen. Auf den 1. Blick bleibt da wohl nur entweder teure HM Sensoren oder die komische Regelung mit den internen Temp. Sensoren. Und meine 12 IT Funkfühler kann ich wohl auch einmotten.

[Hollo]

Auch wenn sich evtl. herausstellt, dass die Kombination nicht zuverlässig stabil zufriedenstellend läuft, möchte ich trotzdem gerne erst erst die Ursachen der Probleme erkennen und verstehen.

Aktuell habe ich 2 Beobachtungen, die ich noch nicht einordnen kann...

1. bei meinem Thermostat im Büro habe ich meiner Meinung nach noch nie die Fenster-offen-Absenkung gesehen

Evtl. reichen die Sprünge beim Wechsel Tempsensor extern-intern-extern nicht aus;
Offset und Schwelle sind momentan identisch zur Küche; Rahmenbedingungen sind auch nahezu identisch.

2. mein Thermostat in der Küche hat heute morgen zwischendurch wieder auf "Fenster-offen-12°C" umgeschaltet, OHNE das ein Srung in der IST-Temp zu sehen ist!

2016-01-08_06:11:04 Sensor_05 humidity: 43
2016-01-08_06:11:12 ku_Heizung actuator: 92
2016-01-08_06:11:12 ku_Heizung desired-temp: 21.0
2016-01-08_06:11:12 ku_Heizung measured-temp: 19.5
2016-01-08_06:13:45 ku_Heizung actuator: 0
2016-01-08_06:13:45 ku_Heizung desired-temp: 12.0
2016-01-08_06:13:45 ku_Heizung measured-temp: 19.6
2016-01-08_06:14:04 Sensor_05 humidity: 43
2016-01-08_06:15:19 ku_Heizung actuator: 0
2016-01-08_06:15:19 ku_Heizung desired-temp: 12.0
2016-01-08_06:15:19 ku_Heizung measured-temp: 19.6
2016-01-08_06:17:05 Sensor_05 humidity: 43
2016-01-08_06:17:24 ku_Heizung actuator: 0
2016-01-08_06:17:24 ku_Heizung desired-temp: 12.0
2016-01-08_06:17:24 ku_Heizung measured-temp: 19.6
2016-01-08_06:20:05 Sensor_05 humidity: 43
2016-01-08_06:20:18 ku_Heizung actuator: 0
2016-01-08_06:20:18 ku_Heizung desired-temp: 12.0
2016-01-08_06:20:18 ku_Heizung measured-temp: 19.6
2016-01-08_06:22:58 ku_Heizung actuator: 0
2016-01-08_06:22:58 ku_Heizung desired-temp: 12.0
2016-01-08_06:22:58 ku_Heizung measured-temp: 19.6
2016-01-08_06:23:10 Sensor_05 humidity: 43
2016-01-08_06:25:24 ku_Heizung actuator: 0
2016-01-08_06:25:24 ku_Heizung desired-temp: 12.0
2016-01-08_06:25:24 ku_Heizung measured-temp: 19.6
2016-01-08_06:26:19 Sensor_05 humidity: 43
2016-01-08_06:27:35 ku_Heizung actuator: 0
2016-01-08_06:27:35 ku_Heizung desired-temp: 12.0
2016-01-08_06:27:35 ku_Heizung measured-temp: 19.6
2016-01-08_06:29:24 Sensor_05 humidity: 43
2016-01-08_06:30:35 ku_Heizung actuator: 95
2016-01-08_06:30:35 ku_Heizung desired-temp: 21.0
2016-01-08_06:30:35 ku_Heizung measured-temp: 19.6

[Merlin]

2. mein Thermostat in der Küche hat heute morgen zwischendurch wieder auf "Fenster-offen-12°C" umgeschaltet, OHNE das ein Srung in der IST-Temp zu sehen ist!

Kannst du mal im Logfile noch um ein paar Minuten zurückgehen? Die Temp Änderung könnte schon knapp vorher erfolgt sein.

Eine Umschaltung auf 12° ohne Anlass habe ich noch nicht beobachtet.

[Hollo]

Desired-temp wurde um 6 Uhr auf 21°C gesetzt.

Kleine Ergänzung:
Bei dem o.g. Vorgang fehlt im Log zwischendurch sogar mal ein komplettes Intervall; Zeitabstand also ca. 5 Minuten.

Heute Nachmittag dann erneut "Fenster offen", weil zwischendurch der interne Sensor aktiv war.
Dazwischen fehlt aber nix, Zeit-Abstände der LOG-Einträge passen.

2016-01-08_15:22:50 ku_Heizung actuator: 27
2016-01-08_15:22:50 ku_Heizung desired-temp: 21.0
2016-01-08_15:22:50 ku_Heizung measured-temp: 21.0
2016-01-08_15:23:21 Sensor_05 humidity: 41
2016-01-08_15:25:45 ku_Heizung actuator: 0
2016-01-08_15:25:45 ku_Heizung desired-temp: 21.0
2016-01-08_15:25:45 ku_Heizung measured-temp: 23.3
2016-01-08_15:26:30 Sensor_05 humidity: 41
...
2016-01-08_16:24:01 Sensor_05 humidity: 41
2016-01-08_16:24:11 ku_Heizung actuator: 7
2016-01-08_16:24:11 ku_Heizung desired-temp: 21.0
2016-01-08_16:24:11 ku_Heizung measured-temp: 22.8
2016-01-08_16:26:40 ku_Heizung actuator: 0
2016-01-08_16:26:40 ku_Heizung desired-temp: 12.0
2016-01-08_16:26:40 ku_Heizung measured-temp: 21.0

[martinp876]

Ich habe einmal einen virtuellen Sensor aufgesetzt. Hat geklappt, habe keine Aussetzer bemerkt.
Wach dem abschalten hat es keine 30 min gedauert bis der RT auf intern betrieb geschaltet hat. Das antennensymbol blinkt, leider kann ich keine statusmeldung sehen. Ich kann es also nicht anzeigen

[ext23]

Ich habe auch die Probleme mit FW 1.3 und HMLAN und als Sensor ein panStamp Temp/Hum Sensor. Aber bei mir ist das eher selten, also maximal 2 mal am Tag. Ich merke es dann auch nur wenn die Temp für 15 Minuten auf 12 Grad geht, also Fenster offen...

Ich habe die Differenztemp für die Fenster Auf Erkennung erhöht. Ich finde das sowieso Schwachsinn, aber gut, Geschmackssache.

/Daniel