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

frank · 20 Januar 2016, 12:39:00

Zitat von: Merlin am 17 Januar 2016, 15:15:22
Weißt du zufällig wann/wie oft?

bei meinen hm-cc-tc immer kurz nach mitternacht. beim rt wahrscheinlich anders. sniffe mal nach folgenden messages: typ A03F zeitanfrage an zentrale, 803F antwort an tc.

Code Auswählen

2016.01.01 00:01:07.266 0: HMLAN_Parse: hmlan1 R:E206487   stat:0000 t:BFF8BDC9 d:FF r:FFB9     m:BA A03F 206487 1ACE1F 
2016.01.01 00:01:07.432 0: HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:BFF8BE6F d:FF r:FFE1     m:BA 803F 1ACE1F 206487 02041E186223

etwas lektüre: http://forum.fhem.de/index.php/topic,28088.0.html

andi11 · 12 Februar 2016, 11:01:02

die Kommunikation zum RT-DN hat funktioniert (konnte Solltemperatur setzen) und aktuelle Werte habe ich auch erhalten. Trotzdem hat das RT-DN mit seinem eigenen Messwert gearbeitet, nicht mit dem vom virtuellen Sensor. Entfernen der Batterie am RT-DN => danach wurde wieder der Wert vom virtuellen Sensor verwendet.
Ist es ggf. besser per Notify die Werte vom Sensor an den virtuellen Sensor zu übertragen? Oder gar nur, wenn der Wert vom Sensor ein anderer ist, wie der vom virtuellen Sensor?

frank · 12 Februar 2016, 11:07:56

ZitatIst es ggf. besser per Notify die Werte vom Sensor an den virtuellen Sensor zu übertragen? Oder gar nur, wenn der Wert vom Sensor ein anderer ist, wie der vom virtuellen Sensor?

eigentlich genügt es mit einem notify nur geänderte werte an den virtuellen sensor zu senden, da dieser sowieso regelmässig an den rt sendet.

andi11 · 19 Februar 2016, 16:11:48

hat irgendjemand schon eine neue Erkenntnis, wie man die Stabilität erhöhen könnte? Hilft evl das vorschalten der VCCU vor meinem HMLan. Das bietet ja soweit ich gelesen habe auch virtuelle Kanäle an.

Hollo · 19 Februar 2016, 20:09:40

Neue Erkenntnisse nicht, ausser dass
- bei meinem "schlechtesten" Thermostat die Batterie so ca. 4 Wochen hält
- eine VCCU das Verhalten nicht verändert (zumindest nicht positiv)

Ich finde es einfach nicht und es nervt.

martinp876 · 19 Februar 2016, 21:45:24

Wenn die bat so schnell leer ist hat das device einen schaden oder es wird Staendig burst ausgelöst.
Hast du burst im griff?

Hollo · 20 Februar 2016, 15:20:04

Zitat von: martinp876 am 19 Februar 2016, 21:45:24
Hast du burst im griff?

Blöde Frage... wie kann ich das prüfen/erkennen?

thaliondrambor · 17 Juni 2016, 15:21:50

Nach dem sich hier eine Weile nichts getan hat, möchte ich kurz berichten, wie es momentan bei mir mit den Aussetzern aussieht und erfragen, ob sich bei euch was getan hat.

Grundsätzlich hat sich bei mir für das Problem keine Lösung ergeben. Ich lasse in einem Log Abweichungen zwischen Temperatursensor und Thermostat von >= 0,5K aufzeichen, um so zuerkennen, dass die Übertragen zum Thermostat nicht klappt. Ich hatte davon täglich sehr sehr viele bei allen Thermostaten.

Jetzt habe ich mein FHEM von meinem QNAP-NAS (Linux VM in der Virtualization Station) auf einen Intel NUC (i5-5250U, 16GB RAM, SSD) umgezogen. Der Einfachheit halber habe ich einfach die VM exportiert und auf dem NUC mit Windows 10 in der VirtualBox wieder importiert. Das gesamte System ist nun deutlich schneller. Das Zusammenfügen der CommandRef nach einem Update dauert nur 4-5 Sekunden, während es auf dem alten System zwischen einer halben Minute bis einer Minute gedauert hat.

Eher durch Zufall, habe ich mal wieder in den Log zur Fehlerauswertung geschaut und dieser ist in den letzten Tagen deutlich geschrumpft. Es sind nur noch zwei bis vier Einträge pro Tag (vorher waren es 200 und mehr). Die Einträge sind alle kurz nacheinander, so dass sie quasi als eine Störung zu betrachten sind. Außerdem betreffen sie fast nur die beiden am weitest entfernten Thermostat in Bad und WC.

Für mich sieht es deswegen nach einem Timinig-Problem aus, wenn FHEM gerade was anderes macht und es somit zu Verzögerungen beim Senden kommt.

Fredi69 · 09 Januar 2017, 11:10:36

Gibt es hier Neuigkeiten?
Ich habe aktuelle das gleiche Problem, der HM-CC-RT-DN übernimmt die Temperatur nicht mehr vom Virtual Device.

andi11 · 09 Januar 2017, 11:36:10

ich habe immer mal wieder Aussetzer. Mal für 1Messwert, mal für 2Stunden. Habe aber keine Lösung gefunden.

sinus61 · 09 Januar 2017, 18:25:19

Ich konnte das auch nie lösen. Bei meinem älteren RTs mit FW 1.0-1.1 gab es immer nur kurze Aussetzer, bei den neueren mit FW 1.3. aber relativ lange Aussetzer über teilweise 1-2 Stunden. Ich ersetze jetzt nach und nach alle durch HM Sensoren.

Fredi69 · 09 Januar 2017, 18:28:34

Zitat von: sinus61 am 09 Januar 2017, 18:25:19Ich ersetze jetzt nach und nach alle durch HM Sensoren.

Hmm, ich habe gerade in 10 LaCrosse Sensoren investiert, das ist ja jetzt extrem unerfreulich.
Sonst niemand mit den Problemen oder gar Lösungen?

CBSnake · 09 Januar 2017, 18:34:08

Hi,
Ich hab 7 CC-RT-DN und 4 la crosse und eigentlich keine Probleme, ich müsste das mal prüfen

wo bleibt der Wert den stehen/hängen? Beim lacrosse oder im virtuellen Device?
Grüße
Achim

Gesendet von meinem SM-P605 mit Tapatalk

Fredi69 · 09 Januar 2017, 18:38:15

Zitat von: CBSnake am 09 Januar 2017, 18:34:08
Hi,
Ich hab 7 CC-RT-DN und 4 la crosse und eigentlich keine Probleme, ich müsste das mal prüfen wo bleibt der Wert den stehen/hängen? Beim lacrosse oder im virtuellen Device?
Grüße
Achim

Gesendet von meinem SM-P605 mit Tapatalk

Im virtuellen Device!
Für die Übertragung vom LaCrosse in das virtuelle Device muss man ja selbst sorgen.

Gerd · 09 Januar 2017, 19:03:22

Zitat von: sinus61 am 09 Januar 2017, 18:25:19
Ich konnte das auch nie lösen. Bei meinem älteren RTs mit FW 1.0-1.1 gab es immer nur kurze Aussetzer, bei den neueren mit FW 1.3. aber relativ lange Aussetzer über teilweise 1-2 Stunden. Ich ersetze jetzt nach und nach alle durch HM Sensoren.

Funktioniert das denn Fehlerfrei ?

Ich habe mit den RT's und LaCrosse auch Aussetzter auch mal längere.