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

[vbs]

Hm, sehr interessant. Hab nochmal eine Kleinigkeit geändert, eine Beschreibung für die commandref hinzugefügt und den Default-Wert auf 200 geändert.

[Fredi69]

Wie testet ihr das ?

[JoeALLb]

Schick dem Martin doch eine PN, damit er sich den Patch mal ansieht....

Habt ihr eigentlich mit dieser Firmware getestet, ode rnutzt ihr die normale Firmware?
https://forum.fhem.de/index.php/topic,31421.0.html

[vbs]

Hab Martin heute morgen schon geschrieben. Ich benutze einen HM-CFG-USB mit hmland.

[Fredi69]

ich kann ebenfalls fehlerfreiheit seit 24h vermelden mit einem Offset von 500ms.

Wie stellst Du fest, das es fehlerfrei läuft?

[andi11]

Wie stellst Du fest, das es fehlerfrei läuft?

ich schau mir die Istwerte vom Stellantrieb an. Wenn die plötzlich stark steigen hatte ich einen Kommunikationsfehler. Die Temperaturerfassung vom Stellantrieb funktioniert bei dem einem nicht so gut, daher verwende ich den virtuellen Sensor. Ggf. könnte  man die Abweichung auch mit einem großen Temperaturoffset manuell erzeugen.

Was ich damit vermutlich nicht festellstellen kann, wenn nur mal ein paar Werte nicht übertragen werden.

[vbs]

Martin hat das so in das Modul übernommen (danke dafür) und das ist jetzt im Update verfügbar. Default für den Offset ist jetzt 200 ms. Falls es User gibt, bei denen es bisher funktionierte (und jetzt nicht mehr), dann bitte erstmal händisch den Wert auf 0 setzen (ist dann wie vorher) und hier Bescheid sagen. Evtl. müssten wir den Default dann noch anpassen.

[sinus61]

Funktioniert sehr gut, danke dafür. Bis auf einen liefen hier alle mit dem Default gut, nur einen hab ich auf 500 gesetzt, jetzt sieht es auch gut aus.

Das hat den LaCrosse Sensoren das Leben gerettet

[andi11]

hab nur einen im Einsatz. Default 200ms 1 sichtbarer Ausfall im Chart.  300ms bisher fehlerfrei

[Fredi69]

Einen RT im Einsatz, mit 250ms 48h fehlerfrei.
Top Job, vielen Dank für den Einsatz!!!

[vbs]

Prima, freut mich zu hören!

Bei mir läufts auch stabil, aber ich hatte jedoch tatsächlich zwischendurch wieder Probleme. Aber das lag daran, dass die Systemuhr meines Rechners (VM) nicht rund lief (lief zu langsam) und dann der ntpd alle paar Minuten die Zeit hart verstellt hat.
Es wurde im Thread schon erwähnt aber ich wollte auch nochmal bekräftigen, dass es wirklich wichtig ist, dass im System keine Zeitsprünge passieren und dass die Systemuhr mit korrekter Geschwindigkeit läuft. Ansonsten führt das wirklich zu Timingproblemen in diesem Zusammenhang.

[Linef]

Freut mich ebenfalls, daß mein Tip jetzt so vielen geholfen hat - vielen Dank auch an vbs für die Implementierung in FHEM!

Ich werd's jetzt bei meinen Temperatursensoren auch flexibel konfigurierbar machen - hier ist die Konfigurierbarkeit noch wichtiger, da die Genauigkeit der RC-Oszillatoren nicht sehr groß ist und man deshalb auch mal schnell außerhalb des Empfangsfensters landet...

Martin

[vbs]

Leider etwas unbefriedigend, dass weiterhin unklar ist, warum es eigentlich funktioniert bzw. was da überhaupt passiert. So ein richtiges gutes Gefühl hab ich nicht bei der ganzen Sache, aber soll man machen 

[duke]

Hallo zusammen,

ich habe die gleichen Probleme mit einem LaCrosse Temperatursensor.

Mir ist jedoch nicht ganz klar, in welchem Modul ich das Attribut setzen muss. Ich habe FHEM aktualisiert und alle HM-Kanäle, etc. durchsucht. Könnt ihr mir einen Tipp geben, wo ich genau schauen muss.

Zur Info: Ich benutze das Funkmodul für die GPIO Schnittstelle des Raspberry Pi (https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi)

Vielen Dank im Voraus!

Gruß

Duke

[vbs]

Musst du in dem virtueller Sensor setzen.