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

[Merlin]

Hallo Leute,
ich bastle seit ein paar Monaten an meiner Hausautomatisierung und habe auch schon so einiges hier gefunden und umgesetzt. Jetzt allerdings bi ich auf folgendes Problem gestoßen:
Die HM-CC-RT-DN gepeert mit einem virtuellen Temperaturdevice schalten zwischendurch immer wieder auf den internen Temperaturfühler um, Mehrmals täglich, manchmal nur für ein paar Minuten, zwischendurch aber auch mal für 1 oder 2 Stunden. Der Fehler tritt unregelmässig und nicht gleichzeitig auf allen 11 Geräten auf.

Konfiguration:
11 Stk HM-CC-RT-DN an einem Raspberry mit CUL Stick V 1.61 CUL868. Kommunikation funktioniert seit Monaten problemlos. Einige RSSI sind zwar nicht berauschend aber Der Fehler tritt überall auf. Auch dort wo der Heizkörper und Sender nur 3 Meter entfernt sind. Ich hab mir die Temperaturplots von den internen Sensoren angesehen: Keine Spikes oder Abrisse -> Kommunikation stabil

11 Stk TX29DTH werden empfangen über einen JeeLink [LaCrosseITPlusReader.10.1q (RFM69 f:868280 t:30~3)] am gleichen Raspberry. Auch hier zeigen die Plots seit Monaten keine Unterbrechungen.

Seit einigen Tagen habe ich nun laut WIKI virtuelle Temperatur Devices erstellt und gepeert. Grundsätzlich funktionierts auch, aber es kommt zu oben beschriebenen Unterbrechungen. Da je nach Betriebszustand der Heizung die Differenz zwischen internen und externen Fühler schonmal +/- 2 Grad in beide Richtungen betragen kann entsteht dann beginnt der Öffnungsfaktor der Ventile zu "springen"

Ich versuch den Fehler mal zu visualisieren (Siehe Bild): die grüne Fläche ist der Plot direkt aus dem Log der externen Sensoren so wie der Temperaturverlauf auch tatsächlich stattfindet. Die rote Linie ist die "measured-temp" vom HM-CC-RT-DN. Wenn alles OK ist liegen die Linien übereinander. Im Fehlerfall springt die rote Line davon. Und zwar nach unten wenn der Raum relativ war und die Heizung/Wand kalt ist und nach oben  wenn der Heizkörper grade heiss ist.

Die Übertragung der TX29 readings zum virtuellen Device funktioniert übrigends auch. Im virtuellen Device steht die richtige Temperatur drinnen auch wenn sie im HM nicht ankommt.

Hat jemand eine Idee dazu oder zumindest einen Such/Debugging Ansatz wo ich ansetzen kann? Bin mit meiner Weisheit erstmal am Ende.

Schon mal Danke für die Hilfe und liebe Grüße
Merlin

[frank]

die kommunikation fhem mit dem rt ist gestört.
wenn die temp sich unterscheidet hat der rt keine temp erhalten und nimmt seine eigene.
was sagen die rssi?

[FHEMbeta]

Ich habe das gleiche Phänomen hier mit vier HM-CC-RT-DN, die ihre Temperaturen über virtuelle HomeMatic Geräte von Jeelink Temperatursensoren erhalten. Die virtuellen HomeMatic Sensoren habe immer die korrekte Temperatur wie die Jeelink Temperatursensoren. Die measured-temp im Weather-Kanal der HM-CC-RT-DN weicht jedoch immer mal wieder von diesen Werten ab und fällt auf den Sensor des HM-CC-RT-DN zurück.

Die RSSI-Werte der einzelnen HM-CC-RT-DN am HM-USB2 Adapter sind:
avg:-55.73 min:-77 max:-51 lst:-56
avg:-53.31 min:-74 max:-49 lst:-56
avg:-61.89 min:-79 max:-53 lst:-58
avg:-63.1   min:-78 max:-59 Ist:-65


Sind diese Werte besonders schlecht, sodass eine gestörte Kommunikation zustande kommt?

[Merlin]

Also och meine ja auch das es irgendeine Art Störung sein muß. Aber ganz so einfach ist es nicht weil:
1. Tritt der Fehler beim besten Wert (RSSI -45, 3 Meter entfernt) genau so auf wie beim schlechtesten (RSSI -80, 2 Stockwerke dazwischen) und
2. Hab ich interne Temperatur Plots der letzten 3 Monaten vor dem peering wo keine Fehler drinnen sind. Also müsste nur der Kanal in die andere Richtung gestört sein. Gibt's das? Normale Aktivitäten in diese Richtung (Temperaturänderungen, Zeitpläne, Umschalten Auto/Manuell) gehen durch.

Sicherheitshalber trotzdem alle RSSI hier:

rssi done:
    Device          receive         from             last   avg      min<max    count
    hk_badog        endor.cul1      hk_badog         -61.5  -61.2  -66.0< -59.0   663
    hk_badog        hk_badog        endor.cul1       -57.0  -57.1  -58.0< -56.0    12
    hk_buero        endor.cul1      hk_buero         -58.5  -51.2  -65.0< -47.0   659
    hk_buero        hk_buero        endor.cul1       -47.0  -47.9  -49.0< -47.0    12
    hk_ez           endor.cul1      hk_ez            -43.0  -43.9  -47.0< -41.0   614
    hk_ez           hk_ez           endor.cul1       -41.0  -43.6  -44.0< -41.0    14
    hk_gz           endor.cul1      hk_gz            -58.0  -58.7  -62.5< -56.0   603
    hk_gz           hk_gz           endor.cul1       -56.0  -56.2  -57.0< -56.0     6
    hk_k            endor.cul1      hk_k             -62.5  -63.1  -69.5< -60.5   714
    hk_k            hk_k            endor.cul1       -59.0  -59.0  -59.0< -59.0    12
    hk_ks           endor.cul1      hk_ks            -46.0  -47.6  -52.0< -44.5   602
    hk_ks           hk_ks           endor.cul1       -50.0  -50.0  -50.0< -50.0     6
    hk_so           endor.cul1      hk_so            -67.5  -65.5  -71.5< -63.0   598
    hk_so           hk_so           endor.cul1       -63.0  -63.2  -64.0< -63.0    12
    hk_su           endor.cul1      hk_su            -69.5  -72.5  -91.5< -67.0   627
    hk_su           hk_su           endor.cul1       -71.0  -71.2  -72.0< -71.0    12
    hk_sz           endor.cul1      hk_sz            -62.0  -60.5  -65.5< -57.0   711
    hk_sz           hk_sz           endor.cul1       -62.0  -62.0  -62.0< -62.0     6
    hk_wk           endor.cul1      hk_wk            -71.0  -79.8  -89.5< -70.0   602
    hk_wk           hk_wk           endor.cul1       -76.0  -75.3  -76.0< -75.0     6
    hk_wz           endor.cul1      hk_wz            -61.0  -62.2  -72.0< -59.0   719
    hk_wz           hk_wz           endor.cul1       -61.0  -60.8  -61.0< -60.0    12
    hm.pmsw1        endor.cul1      hm.pmsw1         -79.0  -78.0  -83.5< -72.0   537
    hm.pmsw1        hm.pmsw1        endor.cul1       -73.0  -73.0  -73.0< -73.0     1
    hm.pmsw2        endor.cul1      hm.pmsw2         -78.0  -78.6  -84.5< -73.5   521
    hm.pmsw2        hm.pmsw2        endor.cul1       -78.0  -78.0  -78.0< -78.0     1
    hm.stromzaehler endor.cul1      hm.stromzaehler  -71.0  -78.3  -89.5< -69.5   530

[Merlin]

@Alexander: Hast du zu dem Problem schon weitergehende Analysen oder Ideen die du mir mir teilen willst?
Damit ich nicht ganz von vorne mit Grundlagenforschung anfangen muß...

[frank]

die rssi sind generell schon ok, wobei es bein einigen schon "knirschen" könnte. ich weiss jetzt aber nicht was hier was ist.

nutzt du auch für jeden virtuellen tempfühler ein eigenes virtuelles device?

[Merlin]

Ja alles eigene virtuelle Devices:

Hier auch das peering dazu:

peerXref done:
x-ref list
    hk_badog_Weather => vt_badog_ts
    hk_buero_Weather => vt_buero_ts
    hk_ez_Weather => vt_ez_ts
    hk_gz_Weather => vt_gz_ts
    hk_k_Weather => vt_k_ts
    hk_ks_Weather => vt_ks_ts
    hk_so_Weather => vt_so_ts
    hk_su_Weather => vt_su_ts
    hk_sz_Weather => vt_sz_ts
    hk_wk_Weather => vt_wk_ts
    hk_wz_Weather => vt_wz_ts
    hm.pmsw1_Sw => self01
    hm.pmsw2_Sw => self01
    vt_badog_ts => hk_badog_Weather
    vt_buero_ts => hk_buero_Weather
    vt_ez_ts => hk_ez_Weather
    vt_gz_ts => hk_gz_Weather
    vt_k_ts => hk_k_Weather
    vt_ks_ts => hk_ks_Weather
    vt_so_ts => hk_so_Weather
    vt_su_ts => hk_su_Weather
    vt_sz_ts => hk_sz_Weather
    vt_wk_ts => hk_wk_Weather
    vt_wz_ts => hk_wz_Weather

[frank]

Ja alles eigene virtuelle Devices:

wirklich? oder nur eigene channels vom selben device?

[Merlin]

ja wirklich

[frank]

na gut... 

fw rt ist neu?

[frank]

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

[Gerd]

Ich darf mich da mal mit dran hängen habe das selbe Problem mit 3 HM-CC-RT-DN.
Bei einem der HM-CC-RT-DN ist mir zu dem Zeitpunkt der Abweichung ein blinkendes Funksymbol aufgefallen was laut Anleitung eine Kommunikationsstörung ist.
Werteänderungen der Channels_Clima per Fhem sind auch in dem Zeitraum ohne Probleme angekommen. Ansonsten gibt es da keine Probleme.
Firmware ist 1.3 gesteuert wird es über einen HM-CFG-USB2.

[Merlin]

Ich habe eine CUL mit FW 1.61 und auf den HM-CC-RT-DN ist FW 1.4 drauf.

Wenn das bei Gerd auch auf einem HM-CFG auftritt kann man wohl diesen und den CUL ausschließen. Bleibt der HM-CC-RT-DN.
Wenn ich das richtig verstehe wird die Temp ja übertragen nachdem der HM-CC-RT-DN aufgewacht ist (so ca alle 2-3 Min denke ich).
Also der HM-CC-RT-DN überträgt seinen Staus und fhem antwortet mit einer Temperatur des virtuellen Devices. Stimmt das so? Falls ja könnte es hier ein Timing Problem geben? Wie lange wartet der Thermostat auf eine Antwort?
Bei wem funktionieren solche virtuellen Temperatur Devices in Kombination mit einem HM-CC-RT-DN problemlos? Was ist dort anders?

Ich würde mich ja gerne an weitergehenden Analysen beteiligen aber mir fehlt irgendwie der Ansatz. Kann man den Funkverkehr vernünftig protokollieren?

[Hollo]

Dann hänge ich mich auch mal dran und wir sammeln Infos zum Eingrenzen der möglichen Ursachen.

- HM-CC-RT-DN haben Firmwarestand 1.4
- Ansteuerung erfolgt über vccu mit HM-CFG-USB2 und HM-CFG-LAN
- beide haben IOdev HMLAN1 und IOgrp vccu:hmusb
- rssi_at_HMLAN1 avg:-45 max:-45 lst:-45 cnt:14 min:-45
- rssi_at_hmusb min:-40 cnt:14 avg:-39.57 max:-39 lst:-39
- LaCrosse-Sensoren mit Luftfeuchtigkeit
- Jeelink-Clone [LaCrosseITPlusReader.10.1p (RFM12B f:868300 r:17241) + (RFM12B f:868300 r:8842) + BMP180]
- jeweils eigenes virtuelles Device mit Aktualisierung vom Sensor per at

- Antennensymbol blinkt beim Thermostat häufiger
- Nutzung der internen Temperatur erkennbar, da Wert dann höher
- Wenn wieder der korrekte externe Sensorwert genutzt wird, geht der Thermostat vonn "Fenster offen" aus

- rein subjektiv hat das "vorher" schon problemlos funktioniert (aber im Sommer/Herbst war ja eher messen als heizen)
- rein subjektiv verbrauchen die beiden Thermostate viel mehr Batterie (oder die eingesetzten waren schlecht)

[Merlin]

- rein subjektiv hat das "vorher" schon problemlos funktioniert (aber im Sommer/Herbst war ja eher messen als heizen)
- rein subjektiv verbrauchen die beiden Thermostate viel mehr Batterie (oder die eingesetzten waren schlecht)

Was hat vorher funktioniert und was hat sich geändert? (Oder meinst du vor dem peering mit den externen Sensoren? Da gings bei mir auch...)
Der Batterieverbrauch ist klar. Wenn ich mir ansehe wie die Ventile zappeln seit ich den externen Tempsensor geepert habe wundert mich da nicht.