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

Begonnen von Merlin, 15 Dezember 2015, 19:10:39

Vorheriges Thema - Nächstes Thema

sinus61

Mit den HM Sensoren gibt es das Problem ja nicht.

Mit den LaCrosse Sensoren und dem virtuelle Device sind die Probleme ja recht verbreitet. Wenn da die Verbindung eine zeitlang nicht klappt nutzt der RT ja wieder den internen Sensor und es gibt einen Sprung nach oben. Die Auswirkungen sind aber unterschiedlich, wenn es  nur kurze Peaks sind merkt es mancher ja vielleicht nicht, bei mir war es auch total unterschiedlich.
Aber so macht das wenig Sinn, die RTs müssen dann viel mehr hin- und herfahren und die Batterie ist schneller alle und die Raumtemperatur stimmt kja am Ende auch oft nicht.

Fredi69

Ob LaCrosse oder jedes andere beliebige Thermometer ist ja völlig egal. Das Problem scheinen ja die virtuellen Devices zu sein.
fhem auf Raspberry Pi 3
FRITZ!Box7490, Fritz!Box 3270 AP, 3xHMLAN, CUL868, nanoCUL 433 für IT, JeeLink für LaCrosse, HUE Bridge 2.0, Samsung UE46C8790 (STV), mehrere Homematic, Intertechno, Shelly und LaCrosse Komponenten

fhainz

Ich habe das selbe Problem, verwende aber andere sensoren. Habe sogar versucht per at jede minute die temperatur ins virtuelle device zu schicken, aber das Problem besteht weiterhin.
Das Ventil übernimmt die temp vom virtuellen device nicht immer.

andi11

ich verwendete Panstamp Boards als Sensoren. Egal ob per AT Notifiy oder sonstwas, die Werte vom virtuellen Sensor landen nie beim RT.

frank

Zitat von: andi11 am 10 Januar 2017, 12:40:12
ich verwendete Panstamp Boards als Sensoren. Egal ob per AT Notifiy oder sonstwas, die Werte vom virtuellen Sensor landen nie beim RT.
dann machst du wohl etwas falsch. was sagt hminfo configCheck?
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

andi11

Zitat von: frank am 10 Januar 2017, 13:40:08
dann machst du wohl etwas falsch. was sagt hminfo configCheck?
Arg Mist,Schreibfehler: Die Werte landen sporadisch (zwischen 0 und 2h pro Tag) nicht  beim RT. Prinzipiell geht es.

Fredi69

Der Thread und das Problem besteht seit über einem Jahr. Das Problem das der HM-CC-RT-DN die Daten der virtuellen Devices nicht immer übernimmt müssten doch noch mehr haben, oder?
fhem auf Raspberry Pi 3
FRITZ!Box7490, Fritz!Box 3270 AP, 3xHMLAN, CUL868, nanoCUL 433 für IT, JeeLink für LaCrosse, HUE Bridge 2.0, Samsung UE46C8790 (STV), mehrere Homematic, Intertechno, Shelly und LaCrosse Komponenten

Gerd

Ich denke das haben alle die als externen Sensor kein HM Device nutzen.

Fredi69

Es hat doch nichts mit den genutzten Sensoren zu tun. Die Übetragung vom Sensor zum virtuellen Device muss man ja selbst realisieren. Die funktioniert ja auch. Die Übertragung zwischen virtuellem Device und dem
gepeerten Homematic Gerät setzt ja immer mal aus!
fhem auf Raspberry Pi 3
FRITZ!Box7490, Fritz!Box 3270 AP, 3xHMLAN, CUL868, nanoCUL 433 für IT, JeeLink für LaCrosse, HUE Bridge 2.0, Samsung UE46C8790 (STV), mehrere Homematic, Intertechno, Shelly und LaCrosse Komponenten

Gerd

Ja da hast Du recht, aber das meinte ich. Externer Sensor(nicht HM) benötigt virtuelles Device und schon haben wir den Salat.

martinp876 vermutete ja ein Timingproblem zwischen dem Virtuellen Device und dem RT. Das ist ja auch plausibel.

sinus61

Die meisten die sowas einsetzen werden sich wohl damit abgefunden haben, dass es ein nicht lösbares Problem ist. Ich hab ja daher die problematischten Sensoren durch HM Geräte ersetzt, bei ein paar anderen RTs sind die Aussetzter ja so kurz, dass man es kaum merkt wenn man nicht mal die Temperaturen des Sensors und die Temperatur am RT loggt und vergleicht.

Rückwirkend betrachtet hätte ich mir natürlich JeeLink und LaCrosse Sonsoren sparen können und gleich die HM Sensoren nehmen können.

Fredi69

Zitat von: sinus61 am 12 Januar 2017, 14:44:40...Ich hab ja daher die problematischten Sensoren durch HM Geräte ersetzt ...

Wir drehen uns hier im Thread dauernd im Kreis.

Die Sensoren, welche auch immer, sind nicht das Problem!!!
Das Problem sind die virtuellen HM Devices!

Vielleicht kann sich das jemand der CUL_HM Entwickler noch mal ansehen.

Vielen Dank
fhem auf Raspberry Pi 3
FRITZ!Box7490, Fritz!Box 3270 AP, 3xHMLAN, CUL868, nanoCUL 433 für IT, JeeLink für LaCrosse, HUE Bridge 2.0, Samsung UE46C8790 (STV), mehrere Homematic, Intertechno, Shelly und LaCrosse Komponenten

sinus61

Das ersetze halt "problematischten Sensoren" durch "problematischten Kombinationen" oder sonstwas. Mir ist schon klar, dass es am virtuellen Sensor liegt, aber wenn der nicht funktioniert nützen mir die günstigen LaCrosse Sensoren überhaupt nichts. Und wenn das Wohnzimmer kalt ist brauche ich hier zuhause auch nicht anfangen von virtuellen Sensoren zu reden ;)

Die HM Sensoren lösen das Problem und fertig.

vbs

Ja Mensch, bin seit dem Wochenende auch stolzer Besitzer eines virtuellen Temperaturgebers an einem CC-RT. Bin leider auch auf das Problem gestoßen und hab es hier beschrieben:
https://forum.fhem.de/index.php/topic,65619.0.html

Deckt sich aber 1:1 mit dem, was ich hier lesen musste. Funktioniert alles wunderbar mit einem CC-TC, jedoch nicht mit einem virtuellen Device :(

frank

ZitatFunktioniert alles wunderbar mit einem CC-TC, jedoch nicht mit einem virtuellen Device :(
grundsätzlich funktioniert ja der virtuelle fühler, aber auf längere sicht gibt es irgendwann das timing problem.

ich vermute, dass fhem noch ein synchronisationsmechanismus fehlt.

wenn ich einen rt und einen tc hätte, würde ich folgendes testen. vielleicht kann man daran schon etwas erkennen:

1. wie lange dauert es, bis der rt auf interne temperatur zurückschaltet. => batterie aus dem tc entfernen und rt beobachten. ich kann mir nicht vorstellen, dass das fehlen einer einzigen temp message vom tc bereits zu einer umschaltung führt. der rt wartet sicherlich ein paar zyklen.

2. angenommen, man hat 5 zyklen zeit. dann würde ich zb nach 2 zyklen dem tc wieder die batterien einlegen und beobachten, ob die beiden es schaffen, sich wieder zu synchronisieren, ohne dass der rt auf interne temp umschaltet.
der sniff müsste dann eigentlich die synchronisierung zeigen.

3. ein ähnliches scenario müsste dann eigentlich auch passieren, wenn man dem rt eine zeit lang die batterien entfernt.

wichtig sind hierbei sicherlich die messagenummern, da sie zur berechnung des timings benutzt werden und nach batterie einlegen bestimmt zunächst mit 0x00 starten.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html