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
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?
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?
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
@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ß... ;-)
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?
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
ZitatJa alles eigene virtuelle Devices:
wirklich? oder nur eigene channels vom selben device?
ja wirklich ;-)
na gut... :)
fw rt ist neu?
oder hat dein fhem hänger? => siehe apptime, perfmon.
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.
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?
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)
Zitat von: Hollo am 16 Dezember 2015, 09:09:04
- 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.
Also ganz aktuell habe ich seit 15 Minuten mit einem Thermostat das Problem.
- Virtuelle Sensor = Temperatur vom Lacrosse
- Funksymbol am Thermostat blinkt
- State vom Channel Weather scheint der Interne Temperatur wert zu sein, dh. 1,4° Grad höher als der Sensor
Rssi von dem entsprechendem Device
rssi done:
Device receive from last avg min
uSpz_heiz uSpz_heiz hmusb -68.0 -71.7 -81.0< -66.0 11
- peerXref und ConfigCheck sind ok
Also es stimmt alles nur das nicht der Externe Sensorwert benutzt wird.
Gibt es etwas was ich jetzt wo der Fehler gerade da ist testen kann/soll? Bin da noch neu im fhem.
Schau mal am Thermostat Device im FHEM die protLastRcv, protResnd, protSnd jetzt und und dann wenns wieder geht bitte.
ihr müsst rawmessages sniffen, wie im wiki homematic sniffen beschrieben. dann sieht man zwar die probleme, aber gelöst sind sie noch lange nicht. vielleicht ein anfang.
und ja, es können timingprobleme sein. beim cul wahrscheinlicher, als mit homematic io's. für den cul ist eine fw angepinnt, die das timing verbessern kann. deshalb der hinweis mit apptime/perfmon hänger von fhem zu identifizieren.
@hollo
nicht mit der vccu peeren.
Ein paar Daten zu meinem Setup:
- HM-CFG USB 2 Adapter
- Plattform: Banana Pi mit HDD (load unter 0,5 im Schnitt, maximal ca. 1,5 - also nicht wirklich überlastet)
- FHEM 5.7 mit aktuellem Stand
- HM-CC-RT-DN mit neuester Firmware 1.4
- Jeweils ein virtuelles Device für jeden HM-CC-RT-DN, jeder HM-CC-RT-DN ist auch mit einem davon gepeert
- Die Abweichungen treten in unregelmäßigen Abständen auf, spätestens aber nach zwei Stunde
- Ebenfalls eine subjektiv hoher Energieverbrauch, weil das Ventil oft zwischen auf/zu wechselt
Zitat von: Merlin am 16 Dezember 2015, 09:25:23
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 Betrieb mit externem Sensor hat funktioniert, bis mir vor Kurzem die Probleme aufgefallen sind.
ZitatDer Batterieverbrauch ist klar. Wenn ich mir ansehe wie die Ventile zappeln seit ich den externen Tempsensor geepert habe wundert mich da nicht.
Ganz im Gegenteil. Die Regelung ist mit externem Sensor eigentlich wesentlich genauer und "ruhiger"; also kein ständiges hoch- und runterregeln. Mal abgesehen von dem Küchenthermostat, der jetzt meint, das Fenster wäre offen und dann zwischendurch zumacht.
Zitat von: frank am 16 Dezember 2015, 09:55:19
@hollo
nicht mit der vccu peeren.
Was meinst Du damit ???
Ich habe seinerzeit 2 virtuelle Devices angelegt und alles konfiguriert.
Der HM-CFG-USB und damit die vccu kamen später hinzu.
So nun habe ich Raw gesnifft, was mir aber nix sagt, und ich habe auch mitbekommen wie ich das Problem temporär lösen kann, wen nich am RT die Boosttaste >3sek Drücke (Anlernmodus) dann nimmt er sofort wieder den externen Sensor
Das Rawlogging und die von Merlin gewünschten Vorher/Nachher Werte mal als txt angehängt.
Vielleicht hilft das ja das Problem zu entdecken.
@gerd
1. dein hmusb braucht neue fw 0.967, sonst kann fhem keine loadinfo empfangen. für das tempproblem wahrscheinlich nachrangig.
2. wenn F14712/4 deine 2 virtuellen temps sind. die senden anfänglich einfach garnicht. von 10:23 bis 10:43 wird nichts gesendet. kein wunder, wenn der rt seine eigene temp nimmt.
vielleicht overload?
Ich habe auch Raw-Messages mitgeschnitten und tatsächlich ist ca. um 11:27 Uhr ein Wechsel auf den Temperatursensor des HM-CC-RT-DN und eine um 2°C erhöhte Temperatur. Zwei Minuten später wird wieder der korrekte Wert des externen Sensors empfangen. Kann man anhand der Nachrichten erkennen, war hier schief läuft?
Der HM-USB Adapter ist zu keiner Zeit im overload.
2015.12.16 10:22:05 0: HMLAN_Send: hmusb I:K
2015.12.16 10:22:05 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1256AD43 IDcnt:000D L:38 %
2015.12.16 10:22:30 0: HMLAN_Send: hmusb I:K
2015.12.16 10:22:30 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12570EA1 IDcnt:000D L:38 %
2015.12.16 10:22:56 0: HMLAN_Send: hmusb I:K
2015.12.16 10:22:56 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:125773FF IDcnt:000D L:36 %
2015.12.16 10:22:59 0: HMLAN_Send: hmusb I:K
2015.12.16 10:22:59 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1257813F IDcnt:000D L:36 %
2015.12.16 10:23:24 0: HMLAN_Send: hmusb I:K
2015.12.16 10:23:24 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1257E2BC IDcnt:000D L:36 %
2015.12.16 10:23:26 0: HMLAN_Send: hmusb I:K
2015.12.16 10:23:27 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1257EB7C IDcnt:000D L:36 %
2015.12.16 10:23:47 0: HMLAN_Parse: hmusb R:E2B6D2B stat:0000 t:12583B1B d:FF r:FFCD m:15 8610 2B6D2B 000000 0A90B40C1F00
2015.12.16 10:23:51 0: HMLAN_Send: hmusb I:K
2015.12.16 10:23:51 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12584CDA IDcnt:000D L:36 %
2015.12.16 10:24:14 0: HMLAN_Send: hmusb I:K
2015.12.16 10:24:14 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1258A6F8 IDcnt:000D L:37 %
2015.12.16 10:24:39 0: HMLAN_Send: hmusb I:K
2015.12.16 10:24:39 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12590876 IDcnt:000D L:37 %
2015.12.16 10:25:04 0: HMLAN_Send: hmusb I:K
2015.12.16 10:25:04 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12596A15 IDcnt:000D L:37 %
2015.12.16 10:25:14 0: HMLAN_Send: hmusb I:K
2015.12.16 10:25:14 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12598F34 IDcnt:000D L:37 %
2015.12.16 10:25:39 0: HMLAN_Send: hmusb I:K
2015.12.16 10:25:39 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1259F092 IDcnt:000D L:38 %
2015.12.16 10:26:04 0: HMLAN_Send: hmusb I:K
2015.12.16 10:26:04 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:125A5251 IDcnt:000D L:38 %
2015.12.16 10:26:10 0: HMLAN_Send: hmusb I:K
2015.12.16 10:26:11 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:125A6C50 IDcnt:000D L:38 %
2015.12.16 10:26:35 0: HMLAN_Send: hmusb I:K
2015.12.16 10:26:35 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:125ACB8E IDcnt:000D L:38 %
2015.12.16 10:26:41 0: HMLAN_Parse: hmusb R:E2B6D2B stat:0000 t:125AE3C4 d:FF r:FFCD m:16 8610 2B6D2B 000000 0A90B80C1200
2015.12.16 10:27:01 0: HMLAN_Send: hmusb I:K
2015.12.16 10:27:01 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:125B30EB IDcnt:000D L:38 %
2015.12.16 10:27:27 0: HMLAN_Send: hmusb I:K
2015.12.16 10:27:27 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:125B9789 IDcnt:000D L:39 %
2015.12.16 10:27:36 0: HMLAN_Send: hmusb I:K
2015.12.16 10:27:36 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:125BBB68 IDcnt:000D L:39 %
2015.12.16 10:28:01 0: HMLAN_Send: hmusb I:K
2015.12.16 10:28:01 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:125C1CC6 IDcnt:000D L:35 %
2015.12.16 10:28:27 0: HMLAN_Send: hmusb I:K
2015.12.16 10:28:27 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:125C8343 IDcnt:000D L:35 %
2015.12.16 10:28:52 0: HMLAN_Send: hmusb I:K
2015.12.16 10:28:52 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:125CE4E1 IDcnt:000D L:35 %
2015.12.16 10:28:57 0: HMLAN_Send: hmusb I:K
2015.12.16 10:28:57 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:125CF681 IDcnt:000D L:35 %
2015.12.16 10:29:10 0: HMLAN_Send: hmusb I:K
2015.12.16 10:29:10 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:125D29DF IDcnt:000D L:36 %
2015.12.16 10:29:21 0: HMLAN_Parse: hmusb R:E2B6D2B stat:0000 t:125D54C2 d:FF r:FFCD m:17 8610 2B6D2B 000000 0A90B80C0000
2015.12.16 10:29:35 0: HMLAN_Send: hmusb I:K
2015.12.16 10:29:35 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:125D8B3E IDcnt:000D L:36 %
2015.12.16 10:29:41 0: HMLAN_Send: hmusb I:K
2015.12.16 10:29:41 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:125DA2BE IDcnt:000D L:36 %
2015.12.16 10:30:06 0: HMLAN_Send: hmusb I:K
2015.12.16 10:30:06 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:125E043B IDcnt:000D L:37 %
2015.12.16 10:30:31 0: HMLAN_Send: hmusb I:K
2015.12.16 10:30:31 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:125E6839 IDcnt:000D L:37 %
2015.12.16 10:30:49 0: HMLAN_Send: hmusb I:K
2015.12.16 10:30:49 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:125EAD57 IDcnt:000D L:37 %
2015.12.16 10:31:15 0: HMLAN_Send: hmusb I:K
2015.12.16 10:31:15 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:125F1355 IDcnt:000D L:37 %
2015.12.16 10:31:40 0: HMLAN_Send: hmusb I:K
2015.12.16 10:31:40 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:125F7513 IDcnt:000D L:37 %
2015.12.16 10:31:46 0: HMLAN_Parse: hmusb R:E2B6D2B stat:0000 t:125F8D1A d:FF r:FFCD m:18 8610 2B6D2B 000000 0A90B80C0000
2015.12.16 10:31:50 0: HMLAN_Send: hmusb I:K
2015.12.16 10:31:50 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:125F99D2 IDcnt:000D L:37 %
2015.12.16 10:32:06 0: HMLAN_Send: hmusb I:K
2015.12.16 10:32:06 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:125FD951 IDcnt:000D L:38 %
2015.12.16 10:32:31 0: HMLAN_Send: hmusb I:K
2015.12.16 10:32:31 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12603AAF IDcnt:000D L:38 %
2015.12.16 10:32:56 0: HMLAN_Send: hmusb I:K
2015.12.16 10:32:56 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12609C4D IDcnt:000D L:35 %
2015.12.16 10:33:06 0: HMLAN_Send: hmusb I:K
2015.12.16 10:33:06 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1260C42C IDcnt:000D L:35 %
2015.12.16 10:33:31 0: HMLAN_Send: hmusb I:K
2015.12.16 10:33:31 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:126125EA IDcnt:000D L:35 %
2015.12.16 10:33:56 0: HMLAN_Send: hmusb I:K
2015.12.16 10:33:56 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12618788 IDcnt:000D L:35 %
2015.12.16 10:33:57 0: HMLAN_Parse: hmusb R:E2B6D2B stat:0000 t:12618CD2 d:FF r:FFCD m:19 8610 2B6D2B 000000 0A90B80C0000
2015.12.16 10:34:21 0: HMLAN_Send: hmusb I:K
2015.12.16 10:34:21 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1261E926 IDcnt:000D L:36 %
2015.12.16 10:34:22 0: HMLAN_Send: hmusb I:K
2015.12.16 10:34:22 0: HMLAN_Send: hmusb I:K
2015.12.16 10:34:22 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1261EDA6 IDcnt:000D L:36 %
2015.12.16 10:34:22 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1261EE66 IDcnt:000D L:36 %
2015.12.16 10:34:47 0: HMLAN_Send: hmusb I:K
2015.12.16 10:34:48 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12625043 IDcnt:000D L:36 %
2015.12.16 10:35:12 0: HMLAN_Send: hmusb I:K
2015.12.16 10:35:12 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1262B1A1 IDcnt:000D L:36 %
2015.12.16 10:35:23 0: HMLAN_Send: hmusb I:K
2015.12.16 10:35:23 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1262DA20 IDcnt:000D L:37 %
2015.12.16 10:35:48 0: HMLAN_Send: hmusb I:K
2015.12.16 10:35:48 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12633B7E IDcnt:000D L:37 %
2015.12.16 10:36:13 0: HMLAN_Send: hmusb I:K
2015.12.16 10:36:13 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12639D3C IDcnt:000D L:37 %
2015.12.16 10:36:30 0: HMLAN_Send: hmusb I:K
2015.12.16 10:36:31 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1263E25B IDcnt:000D L:37 %
2015.12.16 10:36:55 0: HMLAN_Send: hmusb I:K
2015.12.16 10:36:55 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:126443B9 IDcnt:000D L:37 %
2015.12.16 10:36:58 0: HMLAN_Parse: hmusb R:E2B6D2B stat:0000 t:12644EDD d:FF r:FFCD m:1A 8610 2B6D2B 000000 0A90B80C0000
2015.12.16 10:37:20 0: HMLAN_Send: hmusb I:K
2015.12.16 10:37:20 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1264A577 IDcnt:000D L:37 %
2015.12.16 10:37:27 0: HMLAN_Send: hmusb I:K
2015.12.16 10:37:27 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1264BFD7 IDcnt:000D L:38 %
2015.12.16 10:37:41 0: HMLAN_Send: hmusb I:K
2015.12.16 10:37:41 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1264F7B6 IDcnt:000D L:38 %
2015.12.16 10:38:06 0: HMLAN_Send: hmusb I:K
2015.12.16 10:38:07 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:126559F4 IDcnt:000D L:35 %
2015.12.16 10:38:31 0: HMLAN_Send: hmusb I:K
2015.12.16 10:38:32 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1265BB92 IDcnt:000D L:35 %
2015.12.16 10:38:39 0: HMLAN_Send: hmusb I:K
2015.12.16 10:38:39 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1265D751 IDcnt:000D L:35 %
2015.12.16 10:39:04 0: HMLAN_Send: hmusb I:K
2015.12.16 10:39:04 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:126638CF IDcnt:000D L:35 %
2015.12.16 10:39:29 0: HMLAN_Send: hmusb I:K
2015.12.16 10:39:29 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12669A6D IDcnt:000D L:35 %
2015.12.16 10:39:44 0: HMLAN_Parse: hmusb R:E2B6D2B stat:0000 t:1266D846 d:FF r:FFCD m:1B 8610 2B6D2B 000000 0A90C00C0000
2015.12.16 10:39:54 0: HMLAN_Send: hmusb I:K
2015.12.16 10:39:54 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1266FC0C IDcnt:000D L:36 %
2015.12.16 10:39:59 0: HMLAN_Send: hmusb I:K
2015.12.16 10:39:59 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1267112C IDcnt:000D L:36 %
2015.12.16 10:40:10 0: HMLAN_Send: hmusb I:K
2015.12.16 10:40:10 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12673CEB IDcnt:000D L:36 %
2015.12.16 10:40:35 0: HMLAN_Send: hmusb I:K
2015.12.16 10:40:35 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12679E69 IDcnt:000D L:37 %
2015.12.16 10:40:42 0: HMLAN_Send: hmusb I:K
2015.12.16 10:40:43 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1267BB49 IDcnt:000D L:37 %
2015.12.16 10:41:07 0: HMLAN_Send: hmusb I:K
2015.12.16 10:41:07 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12681CA6 IDcnt:000D L:37 %
2015.12.16 10:41:32 0: HMLAN_Send: hmusb I:K
2015.12.16 10:41:32 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12687E67 IDcnt:000D L:37 %
2015.12.16 10:41:33 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12687E67 IDcnt:000D L:37 %
2015.12.16 10:41:57 0: HMLAN_Send: hmusb I:K
2015.12.16 10:41:57 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1268E002 IDcnt:000D L:37 %
2015.12.16 10:42:13 0: HMLAN_Send: hmusb I:K
2015.12.16 10:42:14 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12691EA0 IDcnt:000D L:37 %
2015.12.16 10:42:16 0: HMLAN_Parse: hmusb R:E2B6D2B stat:0000 t:1269290B d:FF r:FFCD m:1C 8610 2B6D2B 000000 0A90C00C0000
2015.12.16 10:42:38 0: HMLAN_Send: hmusb I:K
2015.12.16 10:42:38 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12697FFE IDcnt:000D L:37 %
2015.12.16 10:42:49 0: HMLAN_Send: hmusb I:K
2015.12.16 10:42:50 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1269AA7D IDcnt:000D L:35 %
2015.12.16 10:43:13 0: HMLAN_Send: hmusb I:K
2015.12.16 10:43:13 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:126A061B IDcnt:000D L:35 %
2015.12.16 10:43:38 0: HMLAN_Send: hmusb I:K
2015.12.16 10:43:38 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:126A6798 IDcnt:000D L:35 %
2015.12.16 10:44:03 0: HMLAN_Send: hmusb I:K
2015.12.16 10:44:03 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:126AC936 IDcnt:000D L:36 %
2015.12.16 10:44:17 0: HMLAN_Send: hmusb I:K
2015.12.16 10:44:17 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:126B0095 IDcnt:000D L:36 %
2015.12.16 10:44:34 0: HMLAN_Parse: hmusb R:E2B6D2B stat:0000 t:126B4224 d:FF r:FFCD m:1D 8610 2B6D2B 000000 0A90C00C0000
2015.12.16 10:44:42 0: HMLAN_Send: hmusb I:K
2015.12.16 10:44:42 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:126B61F2 IDcnt:000D L:36 %
2015.12.16 10:44:54 0: HMLAN_Send: hmusb I:K
2015.12.16 10:44:54 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:126B9191 IDcnt:000D L:36 %
2015.12.16 10:45:19 0: HMLAN_Send: hmusb I:K
2015.12.16 10:45:19 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:126BF2EF IDcnt:000D L:36 %
2015.12.16 10:45:44 0: HMLAN_Send: hmusb I:K
2015.12.16 10:45:44 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:126C54AD IDcnt:000D L:36 %
2015.12.16 10:45:54 0: HMLAN_Send: hmusb I:K
2015.12.16 10:45:54 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:126C7D0C IDcnt:000D L:37 %
2015.12.16 10:46:19 0: HMLAN_Send: hmusb I:K
2015.12.16 10:46:19 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:126CDE69 IDcnt:000D L:37 %
2015.12.16 10:46:37 0: HMLAN_Parse: hmusb R:E2B6D2B stat:0000 t:126D2299 d:FF r:FFCD m:1E 8610 2B6D2B 000000 0A90C40C0000
2015.12.16 10:46:44 0: HMLAN_Send: hmusb I:K
2015.12.16 10:46:44 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:126D4028 IDcnt:000D L:37 %
2015.12.16 10:46:47 0: HMLAN_Send: hmusb I:K
2015.12.16 10:46:48 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:126D49A8 IDcnt:000D L:37 %
2015.12.16 10:47:05 0: HMLAN_Send: hmusb I:K
2015.12.16 10:47:05 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:126D9106 IDcnt:000D L:38 %
2015.12.16 10:47:30 0: HMLAN_Send: hmusb I:K
2015.12.16 10:47:30 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:126DF264 IDcnt:000D L:38 %
2015.12.16 10:47:55 0: HMLAN_Send: hmusb I:K
2015.12.16 10:47:55 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:126E5422 IDcnt:000D L:35 %
2015.12.16 10:48:20 0: HMLAN_Send: hmusb I:K
2015.12.16 10:48:20 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:126EB5BF IDcnt:000D L:35 %
2015.12.16 10:48:26 0: HMLAN_Send: hmusb I:K
2015.12.16 10:48:26 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:126ECDBF IDcnt:000D L:35 %
2015.12.16 10:48:51 0: HMLAN_Send: hmusb I:K
2015.12.16 10:48:51 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:126F2F1D IDcnt:000D L:35 %
2015.12.16 10:48:55 0: HMLAN_Send: hmusb I:K
2015.12.16 10:48:55 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:126F3DBE IDcnt:000D L:35 %
2015.12.16 10:49:20 0: HMLAN_Send: hmusb I:K
2015.12.16 10:49:20 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:126F9F1C IDcnt:000D L:36 %
2015.12.16 10:49:22 0: HMLAN_Send: hmusb I:K
2015.12.16 10:49:22 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:126FA9FC IDcnt:000D L:36 %
2015.12.16 10:49:29 0: HMLAN_Parse: hmusb R:E2B6D2B stat:0000 t:126FC46C d:FF r:FFCD m:1F 8610 2B6D2B 000000 0A90C80C0000
2015.12.16 10:49:47 0: HMLAN_Send: hmusb I:K
2015.12.16 10:49:47 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12700B79 IDcnt:000D L:36 %
2015.12.16 10:50:12 0: HMLAN_Send: hmusb I:K
2015.12.16 10:50:12 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12706D17 IDcnt:000D L:36 %
2015.12.16 10:50:33 0: HMLAN_Send: hmusb I:K
2015.12.16 10:50:33 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1270BED5 IDcnt:000D L:36 %
2015.12.16 10:50:58 0: HMLAN_Send: hmusb I:K
2015.12.16 10:50:58 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12712054 IDcnt:000D L:36 %
2015.12.16 10:51:23 0: HMLAN_Send: hmusb I:K
2015.12.16 10:51:23 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:127181F2 IDcnt:000D L:37 %
2015.12.16 10:51:46 0: HMLAN_Send: hmusb I:K
2015.12.16 10:51:46 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1271DB50 IDcnt:000D L:37 %
2015.12.16 10:52:07 0: HMLAN_Parse: hmusb R:E2B6D2B stat:0000 t:12722D9B d:FF r:FFCD m:20 8610 2B6D2B 000000 0A90C80C0000
2015.12.16 10:52:11 0: HMLAN_Send: hmusb I:K
2015.12.16 10:52:11 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12723CAE IDcnt:000D L:37 %
2015.12.16 10:52:36 0: HMLAN_Send: hmusb I:K
2015.12.16 10:52:36 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12729E8C IDcnt:000D L:38 %
2015.12.16 10:53:01 0: HMLAN_Send: hmusb I:K
2015.12.16 10:53:01 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1272FF09 IDcnt:000D L:35 %
2015.12.16 10:53:26 0: HMLAN_Send: hmusb I:K
2015.12.16 10:53:26 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12736067 IDcnt:000D L:35 %
2015.12.16 10:53:51 0: HMLAN_Send: hmusb I:K
2015.12.16 10:53:51 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1273C225 IDcnt:000D L:35 %
2015.12.16 10:54:06 0: HMLAN_Send: hmusb I:K
2015.12.16 10:54:06 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1273FEA3 IDcnt:000D L:35 %
2015.12.16 10:54:30 0: HMLAN_Send: hmusb I:K
2015.12.16 10:54:30 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12745C81 IDcnt:000D L:36 %
2015.12.16 10:54:31 0: HMLAN_Parse: hmusb R:E2B6D2B stat:0000 t:12745F1E d:FF r:FFCD m:21 8610 2B6D2B 000000 0A90C80C0000
2015.12.16 10:54:55 0: HMLAN_Send: hmusb I:K
2015.12.16 10:54:55 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1274BDFF IDcnt:000D L:36 %
2015.12.16 10:55:19 0: HMLAN_Send: hmusb I:K
2015.12.16 10:55:19 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12751A5D IDcnt:000D L:36 %
2015.12.16 10:55:44 0: HMLAN_Send: hmusb I:K
2015.12.16 10:55:44 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12757BBA IDcnt:000D L:37 %
2015.12.16 10:56:09 0: HMLAN_Send: hmusb I:K
2015.12.16 10:56:09 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1275DD78 IDcnt:000D L:37 %
2015.12.16 10:56:10 0: HMLAN_Send: hmusb I:K
2015.12.16 10:56:10 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1275E298 IDcnt:000D L:37 %
2015.12.16 10:56:35 0: HMLAN_Send: hmusb I:K
2015.12.16 10:56:35 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:127643F6 IDcnt:000D L:37 %
2015.12.16 10:56:40 0: HMLAN_Parse: hmusb R:E2B6D2B stat:0000 t:127657FD d:FF r:FFCD m:22 8610 2B6D2B 000000 0A90C80C0000
2015.12.16 10:57:00 0: HMLAN_Send: hmusb I:K
2015.12.16 10:57:00 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1276A593 IDcnt:000D L:37 %
2015.12.16 10:57:06 0: HMLAN_Send: hmusb I:K
2015.12.16 10:57:06 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1276BE13 IDcnt:000D L:37 %
2015.12.16 10:57:28 0: HMLAN_Send: hmusb I:K
2015.12.16 10:57:28 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:127713F3 IDcnt:000D L:38 %
2015.12.16 10:57:53 0: HMLAN_Send: hmusb I:K
2015.12.16 10:57:53 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12777551 IDcnt:000D L:35 %
2015.12.16 10:58:18 0: HMLAN_Send: hmusb I:K
2015.12.16 10:58:18 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1277D6EF IDcnt:000D L:35 %
2015.12.16 10:58:25 0: HMLAN_Send: hmusb I:K
2015.12.16 10:58:25 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1277F26E IDcnt:000D L:35 %
2015.12.16 10:58:50 0: HMLAN_Send: hmusb I:K
2015.12.16 10:58:50 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:127853ED IDcnt:000D L:36 %
2015.12.16 10:59:15 0: HMLAN_Send: hmusb I:K
2015.12.16 10:59:15 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1278B58C IDcnt:000D L:36 %
2015.12.16 10:59:39 0: HMLAN_Parse: hmusb R:E2B6D2B stat:0000 t:1279123C d:FF r:FFCD m:23 8610 2B6D2B 000000 0A90C80C0000
2015.12.16 10:59:41 0: HMLAN_Send: hmusb I:K
2015.12.16 10:59:41 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1279194A IDcnt:000D L:36 %
2015.12.16 10:59:44 0: HMLAN_Send: hmusb I:K
2015.12.16 10:59:44 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12792729 IDcnt:000D L:36 %
2015.12.16 11:00:09 0: HMLAN_Send: hmusb I:K
2015.12.16 11:00:09 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12798887 IDcnt:000D L:36 %
2015.12.16 11:00:14 0: HMLAN_Send: hmusb I:K
2015.12.16 11:00:14 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12799B46 IDcnt:000D L:36 %
2015.12.16 11:00:32 0: HMLAN_Send: hmusb I:K
2015.12.16 11:00:32 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1279E205 IDcnt:000D L:37 %
2015.12.16 11:00:57 0: HMLAN_Send: hmusb I:K
2015.12.16 11:00:57 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:127A4362 IDcnt:000D L:37 %
2015.12.16 11:01:22 0: HMLAN_Send: hmusb I:K
2015.12.16 11:01:22 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:127AA520 IDcnt:000D L:37 %
2015.12.16 11:01:46 0: HMLAN_Send: hmusb I:K
2015.12.16 11:01:46 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:127B03BE IDcnt:000D L:37 %
2015.12.16 11:02:11 0: HMLAN_Send: hmusb I:K
2015.12.16 11:02:11 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:127B651C IDcnt:000D L:37 %
2015.12.16 11:02:23 0: HMLAN_Parse: hmusb R:E2B6D2B stat:0000 t:127B94CD d:FF r:FFCC m:24 8610 2B6D2B 000000 0A90C80C0000
2015.12.16 11:02:36 0: HMLAN_Send: hmusb I:K
2015.12.16 11:02:36 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:127BC6D9 IDcnt:000D L:37 %
2015.12.16 11:02:47 0: HMLAN_Send: hmusb I:K
2015.12.16 11:02:47 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:127BF138 IDcnt:000D L:38 %
2015.12.16 11:02:56 0: HMLAN_Send: hmusb I:K
2015.12.16 11:02:57 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:127C15B8 IDcnt:000D L:35 %
2015.12.16 11:03:21 0: HMLAN_Send: hmusb I:K
2015.12.16 11:03:22 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:127C77B7 IDcnt:000D L:35 %
2015.12.16 11:03:47 0: HMLAN_Send: hmusb I:K
2015.12.16 11:03:47 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:127CDCB6 IDcnt:000D L:35 %
2015.12.16 11:03:51 0: HMLAN_Send: hmusb I:K
2015.12.16 11:03:51 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:127CEC95 IDcnt:000D L:35 %
2015.12.16 11:04:16 0: HMLAN_Send: hmusb I:K
2015.12.16 11:04:16 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:127D4DF3 IDcnt:000D L:35 %
2015.12.16 11:04:41 0: HMLAN_Send: hmusb I:K
2015.12.16 11:04:41 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:127DAF91 IDcnt:000D L:36 %
2015.12.16 11:04:53 0: HMLAN_Parse: hmusb R:E2B6D2B stat:0000 t:127DDEBC d:FF r:FFCD m:25 8610 2B6D2B 000000 0A90C80C0000
2015.12.16 11:05:02 0: HMLAN_Send: hmusb I:K
2015.12.16 11:05:02 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:127E004F IDcnt:000D L:36 %
2015.12.16 11:05:27 0: HMLAN_Send: hmusb I:K
2015.12.16 11:05:27 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:127E61CD IDcnt:000D L:36 %
2015.12.16 11:05:46 0: HMLAN_Send: hmusb I:K
2015.12.16 11:05:47 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:127EAE0B IDcnt:000D L:36 %
2015.12.16 11:06:11 0: HMLAN_Send: hmusb I:K
2015.12.16 11:06:11 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:127F0F88 IDcnt:000D L:37 %
2015.12.16 11:06:20 0: HMLAN_Send: hmusb I:K
2015.12.16 11:06:20 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:127F3288 IDcnt:000D L:37 %
2015.12.16 11:06:45 0: HMLAN_Send: hmusb I:K
2015.12.16 11:06:45 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:127F93E5 IDcnt:000D L:37 %
2015.12.16 11:07:09 0: HMLAN_Send: hmusb I:K
2015.12.16 11:07:09 0: HMLAN_Parse: hmusb R:E2B6D2B stat:0000 t:127FF006 d:FF r:FFCE m:26 8610 2B6D2B 000000 0A90C60C0000
2015.12.16 11:07:11 0: HMLAN_Send: hmusb I:K
2015.12.16 11:07:11 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:127FF065 IDcnt:000D L:37 %
2015.12.16 11:07:11 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:127FF885 IDcnt:000D L:37 %
2015.12.16 11:07:36 0: HMLAN_Send: hmusb I:K
2015.12.16 11:07:36 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12805A23 IDcnt:000D L:37 %
2015.12.16 11:08:01 0: HMLAN_Send: hmusb I:K
2015.12.16 11:08:01 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1280BBC0 IDcnt:000D L:35 %
2015.12.16 11:08:06 0: HMLAN_Send: hmusb I:K
2015.12.16 11:08:06 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1280CEA0 IDcnt:000D L:35 %
2015.12.16 11:08:31 0: HMLAN_Send: hmusb I:K
2015.12.16 11:08:31 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12812FFE IDcnt:000D L:35 %
2015.12.16 11:08:52 0: HMLAN_Send: hmusb I:K
2015.12.16 11:08:53 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1281847D IDcnt:000D L:35 %
2015.12.16 11:09:10 0: HMLAN_Parse: hmusb R:E2B6D2B stat:0000 t:1281C9A8 d:FF r:FFCD m:27 8610 2B6D2B 000000 0A90C60C0000
2015.12.16 11:09:17 0: HMLAN_Send: hmusb I:K
2015.12.16 11:09:17 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1281E5FA IDcnt:000D L:36 %
2015.12.16 11:09:24 0: HMLAN_Send: hmusb I:K
2015.12.16 11:09:24 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1282003A IDcnt:000D L:36 %
2015.12.16 11:09:49 0: HMLAN_Send: hmusb I:K
2015.12.16 11:09:49 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12826197 IDcnt:000D L:36 %
2015.12.16 11:10:14 0: HMLAN_Send: hmusb I:K
2015.12.16 11:10:14 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1282C355 IDcnt:000D L:36 %
2015.12.16 11:10:24 0: HMLAN_Send: hmusb I:K
2015.12.16 11:10:24 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1282EA74 IDcnt:000D L:36 %
2015.12.16 11:10:49 0: HMLAN_Send: hmusb I:K
2015.12.16 11:10:49 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12834BD2 IDcnt:000D L:36 %
2015.12.16 11:11:14 0: HMLAN_Send: hmusb I:K
2015.12.16 11:11:14 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1283AD91 IDcnt:000D L:37 %
2015.12.16 11:11:20 0: HMLAN_Send: hmusb I:K
2015.12.16 11:11:20 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1283C490 IDcnt:000D L:37 %
2015.12.16 11:11:36 0: HMLAN_Send: hmusb I:K
2015.12.16 11:11:36 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12840490 IDcnt:000D L:37 %
2015.12.16 11:12:01 0: HMLAN_Parse: hmusb R:E2B6D2B stat:0000 t:128464A5 d:FF r:FFCD m:28 8610 2B6D2B 000000 0A90C60C0000
2015.12.16 11:12:02 0: HMLAN_Send: hmusb I:K
2015.12.16 11:12:02 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1284680E IDcnt:000D L:38 %
2015.12.16 11:12:27 0: HMLAN_Send: hmusb I:K
2015.12.16 11:12:27 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1284C9AD IDcnt:000D L:38 %
2015.12.16 11:12:52 0: HMLAN_Send: hmusb I:K
2015.12.16 11:12:52 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12852CEA IDcnt:000D L:35 %
2015.12.16 11:13:11 0: HMLAN_Send: hmusb I:K
2015.12.16 11:13:11 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12857569 IDcnt:000D L:35 %
2015.12.16 11:13:36 0: HMLAN_Send: hmusb I:K
2015.12.16 11:13:36 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1285D6C8 IDcnt:000D L:35 %
2015.12.16 11:13:50 0: HMLAN_Send: hmusb I:K
2015.12.16 11:13:50 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12860F07 IDcnt:000D L:35 %
2015.12.16 11:14:07 0: HMLAN_Send: hmusb I:K
2015.12.16 11:14:08 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12865167 IDcnt:000D L:36 %
2015.12.16 11:14:32 0: HMLAN_Send: hmusb I:K
2015.12.16 11:14:32 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1286B2E4 IDcnt:000D L:36 %
2015.12.16 11:14:37 0: HMLAN_Parse: hmusb R:E2B6D2B stat:0000 t:1286C700 d:FF r:FFCC m:29 8610 2B6D2B 000000 0A90C60C0000
2015.12.16 11:14:44 0: HMLAN_Send: hmusb I:K
2015.12.16 11:14:44 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1286E364 IDcnt:000D L:36 %
2015.12.16 11:15:09 0: HMLAN_Send: hmusb I:K
2015.12.16 11:15:09 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:128744C2 IDcnt:000D L:36 %
2015.12.16 11:15:34 0: HMLAN_Send: hmusb I:K
2015.12.16 11:15:34 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1287A65F IDcnt:000D L:36 %
2015.12.16 11:15:59 0: HMLAN_Send: hmusb I:K
2015.12.16 11:15:59 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1288081D IDcnt:000D L:37 %
2015.12.16 11:16:05 0: HMLAN_Send: hmusb I:K
2015.12.16 11:16:05 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12881F9D IDcnt:000D L:37 %
2015.12.16 11:16:30 0: HMLAN_Send: hmusb I:K
2015.12.16 11:16:30 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:128880FA IDcnt:000D L:37 %
2015.12.16 11:16:40 0: HMLAN_Send: hmusb I:K
2015.12.16 11:16:41 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1288A8B9 IDcnt:000D L:37 %
2015.12.16 11:16:59 0: HMLAN_Parse: hmusb R:E2B6D2B stat:0000 t:1288F1AE d:FF r:FFCD m:2A 8610 2B6D2B 000000 0A90C60C0000
2015.12.16 11:17:05 0: HMLAN_Send: hmusb I:K
2015.12.16 11:17:05 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12890A17 IDcnt:000D L:38 %
2015.12.16 11:17:13 0: HMLAN_Send: hmusb I:K
2015.12.16 11:17:13 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:128928B6 IDcnt:000D L:38 %
2015.12.16 11:17:38 0: HMLAN_Send: hmusb I:K
2015.12.16 11:17:38 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12898A34 IDcnt:000D L:38 %
2015.12.16 11:18:03 0: HMLAN_Send: hmusb I:K
2015.12.16 11:18:03 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1289EBD2 IDcnt:000D L:35 %
2015.12.16 11:18:27 0: HMLAN_Send: hmusb I:K
2015.12.16 11:18:27 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:128A48F1 IDcnt:000D L:35 %
2015.12.16 11:18:52 0: HMLAN_Send: hmusb I:K
2015.12.16 11:18:52 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:128AAA6E IDcnt:000D L:36 %
2015.12.16 11:19:07 0: HMLAN_Parse: hmusb R:E2B6D2B stat:0000 t:128AE3B9 d:FF r:FFCD m:2B 8610 2B6D2B 000000 0A90C60C0000
2015.12.16 11:19:17 0: HMLAN_Send: hmusb I:K
2015.12.16 11:19:17 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:128B0C0D IDcnt:000D L:36 %
2015.12.16 11:19:29 0: HMLAN_Send: hmusb I:K
2015.12.16 11:19:29 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:128B3A4C IDcnt:000D L:36 %
2015.12.16 11:19:54 0: HMLAN_Send: hmusb I:K
2015.12.16 11:19:54 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:128B9BAA IDcnt:000D L:36 %
2015.12.16 11:19:54 0: HMLAN_Send: hmusb I:K
2015.12.16 11:19:54 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:128B9D4A IDcnt:000D L:36 %
2015.12.16 11:20:19 0: HMLAN_Send: hmusb I:K
2015.12.16 11:20:19 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:128BFEA8 IDcnt:000D L:36 %
2015.12.16 11:20:37 0: HMLAN_Send: hmusb I:K
2015.12.16 11:20:37 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:128C4587 IDcnt:000D L:37 %
2015.12.16 11:21:02 0: HMLAN_Send: hmusb I:K
2015.12.16 11:21:02 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:128CA704 IDcnt:000D L:37 %
2015.12.16 11:21:27 0: HMLAN_Send: hmusb I:K
2015.12.16 11:21:27 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:128D08A2 IDcnt:000D L:37 %
2015.12.16 11:21:29 0: HMLAN_Send: hmusb I:K
2015.12.16 11:21:29 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:128D0FE2 IDcnt:000D L:37 %
2015.12.16 11:21:54 0: HMLAN_Send: hmusb I:K
2015.12.16 11:21:54 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:128D715F IDcnt:000D L:37 %
2015.12.16 11:22:04 0: HMLAN_Parse: hmusb R:E2B6D2B stat:0000 t:128D971E d:FF r:FFCD m:2C 8610 2B6D2B 000000 0A90C60C0000
2015.12.16 11:22:19 0: HMLAN_Send: hmusb I:K
2015.12.16 11:22:19 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:128DD2DD IDcnt:000D L:38 %
2015.12.16 11:22:22 0: HMLAN_Send: hmusb I:K
2015.12.16 11:22:22 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:128DDD5D IDcnt:000D L:38 %
2015.12.16 11:22:47 0: HMLAN_Send: hmusb I:K
2015.12.16 11:22:47 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:128E3EBB IDcnt:000D L:38 %
2015.12.16 11:22:52 0: HMLAN_Send: hmusb I:K
2015.12.16 11:22:53 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:128E561B IDcnt:000D L:35 %
2015.12.16 11:23:17 0: HMLAN_Send: hmusb I:K
2015.12.16 11:23:17 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:128EB779 IDcnt:000D L:35 %
2015.12.16 11:23:42 0: HMLAN_Send: hmusb I:K
2015.12.16 11:23:43 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:128F1976 IDcnt:000D L:35 %
2015.12.16 11:24:07 0: HMLAN_Send: hmusb I:K
2015.12.16 11:24:08 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:128F7AF5 IDcnt:000D L:36 %
2015.12.16 11:24:32 0: HMLAN_Send: hmusb I:K
2015.12.16 11:24:33 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:128FDC93 IDcnt:000D L:36 %
2015.12.16 11:24:46 0: HMLAN_Parse: hmusb R:E2B6D2B stat:0000 t:129011E1 d:FF r:FFCD m:2D 8610 2B6D2B 000000 0A90C60C0000
2015.12.16 11:24:57 0: HMLAN_Send: hmusb I:K
2015.12.16 11:24:58 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12903E31 IDcnt:000D L:36 %
2015.12.16 11:25:03 0: HMLAN_Send: hmusb I:K
2015.12.16 11:25:03 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12905510 IDcnt:000D L:36 %
2015.12.16 11:25:21 0: HMLAN_Send: hmusb I:K
2015.12.16 11:25:21 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:129099AE IDcnt:000D L:36 %
2015.12.16 11:25:46 0: HMLAN_Send: hmusb I:K
2015.12.16 11:25:46 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1290FB2C IDcnt:000D L:37 %
2015.12.16 11:26:03 0: HMLAN_Send: hmusb I:K
2015.12.16 11:26:03 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12913DEA IDcnt:000D L:37 %
2015.12.16 11:26:28 0: HMLAN_Send: hmusb I:K
2015.12.16 11:26:28 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12919F69 IDcnt:000D L:37 %
2015.12.16 11:26:53 0: HMLAN_Send: hmusb I:K
2015.12.16 11:26:53 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12920107 IDcnt:000D L:37 %
2015.12.16 11:27:14 0: HMLAN_Parse: hmusb R:E2B6D2B stat:0000 t:129254F8 d:FF r:FFCD m:2E 8610 2B6D2B 000000 0A90DB0C0000
2015.12.16 11:27:18 0: HMLAN_Send: hmusb I:K
2015.12.16 11:27:18 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:129262A6 IDcnt:000D L:37 %
2015.12.16 11:27:27 0: HMLAN_Send: hmusb I:K
2015.12.16 11:27:27 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12928585 IDcnt:000D L:37 %
2015.12.16 11:27:52 0: HMLAN_Send: hmusb I:K
2015.12.16 11:27:52 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1292E702 IDcnt:000D L:38 %
2015.12.16 11:27:54 0: HMLAN_Send: hmusb I:K
2015.12.16 11:27:55 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1292F1A2 IDcnt:000D L:35 %
2015.12.16 11:28:19 0: HMLAN_Send: hmusb I:K
2015.12.16 11:28:19 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12935320 IDcnt:000D L:35 %
2015.12.16 11:28:34 0: HMLAN_Send: hmusb I:K
2015.12.16 11:28:35 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12938DDE IDcnt:000D L:35 %
2015.12.16 11:28:59 0: HMLAN_Send: hmusb I:K
2015.12.16 11:28:59 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1293EF5D IDcnt:000D L:35 %
2015.12.16 11:29:24 0: HMLAN_Send: hmusb I:K
2015.12.16 11:29:24 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:129450FB IDcnt:000D L:36 %
2015.12.16 11:29:28 0: HMLAN_Parse: hmusb R:E2B6D2B stat:0000 t:12945F6D d:FF r:FFCD m:2F 8610 2B6D2B 000000 0A90C40C0000
2015.12.16 11:29:39 0: HMLAN_Send: hmusb I:K
2015.12.16 11:29:39 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12948A19 IDcnt:000D L:36 %
2015.12.16 11:29:58 0: HMLAN_Send: hmusb I:K
2015.12.16 11:29:58 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1294D478 IDcnt:000D L:36 %
2015.12.16 11:30:23 0: HMLAN_Send: hmusb I:K
2015.12.16 11:30:23 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:129535D5 IDcnt:000D L:36 %
2015.12.16 11:30:48 0: HMLAN_Send: hmusb I:K
2015.12.16 11:30:48 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12959793 IDcnt:000D L:36 %
2015.12.16 11:31:12 0: HMLAN_Send: hmusb I:K
2015.12.16 11:31:12 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1295F391 IDcnt:000D L:37 %
2015.12.16 11:31:37 0: HMLAN_Send: hmusb I:K
2015.12.16 11:31:37 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:129654EF IDcnt:000D L:37 %
2015.12.16 11:31:47 0: HMLAN_Send: hmusb I:K
2015.12.16 11:31:47 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12967ECE IDcnt:000D L:37 %
2015.12.16 11:32:12 0: HMLAN_Send: hmusb I:K
2015.12.16 11:32:12 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:1296E04B IDcnt:000D L:38 %
2015.12.16 11:32:22 0: HMLAN_Send: hmusb I:K
2015.12.16 11:32:22 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:129705CA IDcnt:000D L:38 %
2015.12.16 11:32:33 0: HMLAN_Parse: hmusb R:E2B6D2B stat:0000 t:12972B3C d:FF r:FFCD m:30 8610 2B6D2B 000000 0A90C40C0000
2015.12.16 11:32:47 0: HMLAN_Send: hmusb I:K
2015.12.16 11:32:47 0: HMLAN_Parse: hmusb V:03C7 sNo:KEQ1110682 d:26362E O:426242 t:12976729 IDcnt:000D L:38 %
Gibts eigentlich irgendwo eine Doku was die nun gesnifften RAW Msgs bedeuten? Feldinhalte, Datensatzaufbau usw. Gefunden hab ich nix.
Zitat von: Alexander am 16 Dezember 2015, 11:38:04
Ich habe auch Raw-Messages mitgeschnitten und tatsächlich ist ca. um 11:27 Uhr ein Wechsel auf den Temperatursensor des HM-CC-RT-DN und eine um 2°C erhöhte Temperatur. Zwei Minuten später wird wieder der korrekte Wert des externen Sensors empfangen. Kann man anhand der Nachrichten erkennen, war hier schief läuft?
Der HM-USB Adapter ist zu keiner Zeit im overload.
mit der richtigen fw ist bei dir die load ja auch zu sehen, 36-38%.
trotzdem wird überhaupt nichts gesendet.
nur keepalive an den hmusb. die sollten mit default einstellung exact alle 25 sek gesendet werden. das ist aber nicht immer der fall. manchmal extrem verkürzt. seltsam. ist logids richtig eingestellt?
also apptime anschmeissen, verbose=5 bei virtuellem device und channel, und mal get hminfo configcheck.
Zitat von: frank am 16 Dezember 2015, 11:36:00
@gerd
1. dein hmusb braucht neue fw 0.967, sonst kann fhem keine loadinfo empfangen. für das tempproblem wahrscheinlich nachrangig.
2. wenn F14712/4 deine 2 virtuellen temps sind. die senden anfänglich einfach garnicht. von 10:23 bis 10:43 wird nichts gesendet. kein wunder, wenn der rt seine eigene temp nimmt.
vielleicht overload?
Frank vielen Dank für den Hinweis mit der Firmware, ich habe die nun mal auf den neuesten Stand gebracht und nun habe ich auch eine Info über den Loadwert.
Ich werde das mal weiter beobachten.
Eine Frage zu der Kommunikation zwischen den Teilen:
Wann erfolgt die Übertragung der Temperatur aus dem virtuellen Device zum RT?
Der RT wacht ja alle 2-3 Min auf und postet eine Statusnachricht. Wartet der CUL darauf und antwortet mit der aktuellen Temperatur? Oder kommt durch das peering mit einem externen Sensor aktiv eine Anfrage vom RT oder dessen Wetterkanal an das Device nach der aktuellen Temperatur? Oder geht das ganz anders?
Wer kann hier aufklären?
Update:
Beobachtung von Gerd mit der blinkenden Antenne kann ich bestätigen.
Hab dann was versucht:
getconfig undburstXmit auf das Device. Befehle gehen durch, die Antwort kommt auch -> kommunikation in beide richtungen funktioniert also. Nur der externe Sensor ist noch immer offline und das blinkende Antennesymbol ist noch immer da. Jetzt bin ich erstmal ratlos.
Wenn ich nicht bald was finde bleibt mir vor den Feiertagen nichts anders übrig als zurückzubauen :(
Ich habe es eine vorher mit dem internen Sensor laufen gehabt das geht auch, habe dann den offset(je nach Raum waren es 2-3K) so angepasst das die extern gemessene Raumtemperatur der desired-temp sehr nahe kommt und gut. Die intern gemessene Temperatur war mir dann egal ;). Die Regelung läuft aber mit einem externen Sensor deutlich besser.
So, hab jetzt auch mal ein wenig Protokolle gesnifft und dabei einen RT erwischt der fast eine Stunde lang nicht funktionierte und dann plötzlich, ohne erkennbaren Grund wieder auf externen Sensor umschaltet.
Hier der entsprechende RAW Log der eigentlich nichts zeigt:
2015.12.16 18:57:51.306 4: CUL_Parse: endor.cul1 A 0F 58 8610 3B02A8 000000 0AB8F10F35003B -44.5 <--- RT meldet 24.1 von intern obwohl es nur 22.4 extern hat
2015.12.16 18:59:13.355 3: CUL_HM set vt_ez_ts virtTemp 22.4 <--- der AT schreibt die aktuelle externe Temp neu
2015.12.16 18:59:36.299 5: CUL_HM vt_ez_ts m:19 ->20 t:1450288776.29674->1450288922.54674 M:1450288776.29945 :146.25
2015.12.16 18:59:36.332 5: CUL_HM vt_ez protEvent:CMDs_pending pending:1
2015.12.16 18:59:36.334 4: CUL_send: endor.cul1As 0B 14 8670 BF0003 000000 00E0 <--- Es werden die 22.4 übertragen
2015.12.16 18:59:36.371 5: CUL_HM vt_ez protEvent:CMDs_done
2015.12.16 19:00:22.303 4: CUL_Parse: endor.cul1 A 0F 59 8610 3B02A8 000000 0AB8F10F35003C -44 <--- RT meldet 1 Minute später trotzdem wieder 24.1
das ging gut 50 Minuten lang so. Dann plötzlich unten in der Üertragung kein Unterschied aber der RT meldet die richtige Temp vom externen Sensor
2015.12.16 19:02:02.552 5: CUL_HM vt_ez_ts m:20 ->21 t:1450288922.54945->1450289054.29945 M:1450288922.55195 :131.75
2015.12.16 19:02:02.585 5: CUL_HM vt_ez protEvent:CMDs_pending pending:1
2015.12.16 19:02:02.587 4: CUL_send: endor.cul1As 0B 15 8670 BF0003 000000 00E0 <--- Übertrage 22.4
2015.12.16 19:02:02.631 5: CUL_HM vt_ez protEvent:CMDs_done
2015.12.16 19:02:38.800 4: CUL_Parse: endor.cul1 A 0F 5A 8610 3B02A8 000000 0A60E00F00003B -44.5 <-- plötzlich sind die richtigen Werte wieder da...
2015.12.16 19:04:14.304 5: CUL_HM vt_ez_ts m:21 ->22 t:1450289054.30195->1450289235.80195 M:1450289054.30415 :181.5
2015.12.16 19:04:14.337 5: CUL_HM vt_ez protEvent:CMDs_pending pending:1
2015.12.16 19:04:14.339 4: CUL_send: endor.cul1As 0B 16 8670 BF0003 000000 00E0
2015.12.16 19:04:14.382 5: CUL_HM vt_ez protEvent:CMDs_done
2015.12.16 19:04:41.067 4: CUL_Parse: endor.cul1 A 0F 5B 8610 3B02A8 000000 0A60E00F00003A -45
Ich verstehs nicht ....
Was mir total schleierhaft ist: Das Timing! Wann wird dieser externe Sensorwert übertragen? Der RT schläft doch zwischendurch. Sollte diese Übertragung nicht direkt im Anschluß an einen Statusreport vom Rt erfolgen?
Zitat von: Merlin am 16 Dezember 2015, 15:10:10
...Wann erfolgt die Übertragung der Temperatur aus dem virtuellen Device zum RT?
...Wer kann hier aufklären?
Das ist eine gute Frage.
Wenn man den Ablauf richtig versteht, bringt das vielleicht auch Hinweise zum Problem.
Wie oft muss man den virtuellen Sensor aktualisieren bzw. gibt es beim Timing zwischen Thermostat und virtuellem Sensor etwas zu beachten?
Der update kommt alle 2.5min plus minus 30sec. Das muss schwanken und wird nach komplexem algo errechnet
Zitat von: martinp876 am 16 Dezember 2015, 21:30:38
Der update kommt alle 2.5min plus minus 30sec. Das muss schwanken und wird nach komplexem algo errechnet
Der Update vom RT? Ja klar. Aber auch vom externen Sensor? Wann antwortet die Zentrale mit der externen Sensortemperatur? Meine bescheidene Erkenntnis dazu ist:
Bei einer normalen Änderung zb der Solltemperatur im fhem geht der status auf CMD pending aber es wird nicht sofort etwas gesendet. Erst wenn der nächste Status Broadcast vom RT empfangen wurde antwortet die Zentrale mir dem Kommando, und zwar adressiert an genau den RT. Logisch und funktioniert auch.
Bei virtuellen temperatursensoren wird einfach alle ca 2,5 Min ein Broadcast generiert und sofort gesendet. Unabhängig davon ob der zu erreichende RT nicht gerade schläft. Wieso wartet der nicht auch auf das Wakeup vom RT? Wie kann das überhaupt klappen?
Schaut mal hier:Statusmeldung vom RT und Broadcast vom dazugehörigen externen Sensor. Ganz unterschiedliche Zeiten. Wie können die überhaupt zusammenfinden???
2015.12.16 18:35:02.828 4: CUL_Parse: endor.cul1 A 0F 4F 8610 3B02A8 000000 0AB8F00F350038 -46
2015.12.16 18:36:24.541 4: CUL_send: endor.cul1As 0B 0B 8670 BF0003 000000 00DE
2015.12.16 18:37:37.874 4: CUL_Parse: endor.cul1 A 0F 50 8610 3B02A8 000000 0AB8F00F350036 -47
2015.12.16 18:38:52.544 4: CUL_send: endor.cul1As 0B 0C 8670 BF0003 000000 00DE
2015.12.16 18:39:54.072 4: CUL_Parse: endor.cul1 A 0F 51 8610 3B02A8 000000 0AB8F00F350038 -46
2015.12.16 18:41:06.309 4: CUL_send: endor.cul1As 0B 0D 8670 BF0003 000000 00DE
2015.12.16 18:41:58.070 4: CUL_Parse: endor.cul1 A 0F 52 8610 3B02A8 000000 0AB8F00F350036 -47
2015.12.16 18:44:09.550 4: CUL_send: endor.cul1As 0B 0E 8670 BF0003 000000 00DE
2015.12.16 18:44:51.568 4: CUL_Parse: endor.cul1 A 0F 53 8610 3B02A8 000000 0AB8F00F350036 -47
2015.12.16 18:46:58.315 4: CUL_send: endor.cul1As 0B 0F 8670 BF0003 000000 00DEWo habe ich hier den Denk/Verständnisfehler?
Bitte um Aufklärung.
Hallo,
also ich finds echt schade das hier keine Antworten kommen. Ich erwarte keine fertige Lösung, sondern will ja sogar selber suchen. Nur ohne ein paar Hintergrundinfos ist das unmöglich. Für jemanden der sich schon intensiv mit dem Modul beschäftigt hat oder gar den Entwickler sollte es doch ein leichtes sein meine Fragen zu beantworten...
Zitat von: Merlin am 16 Dezember 2015, 15:10:10
Eine Frage zu der Kommunikation zwischen den Teilen:
Wann erfolgt die Übertragung der Temperatur aus dem virtuellen Device zum RT?
Der RT wacht ja alle 2-3 Min auf und postet eine Statusnachricht. Wartet der CUL darauf und antwortet mit der aktuellen Temperatur? Oder kommt durch das peering mit einem externen Sensor aktiv eine Anfrage vom RT oder dessen Wetterkanal an das Device nach der aktuellen Temperatur? Oder geht das ganz anders?
Wer kann hier aufklären?
Zitat von: Merlin am 16 Dezember 2015, 22:03:34
Bei einer normalen Änderung zb der Solltemperatur im fhem geht der status auf CMD pending aber es wird nicht sofort etwas gesendet. Erst wenn der nächste Status Broadcast vom RT empfangen wurde antwortet die Zentrale mir dem Kommando, und zwar adressiert an genau den RT. Logisch und funktioniert auch.
Bei virtuellen temperatursensoren wird einfach alle ca 2,5 Min ein Broadcast generiert und sofort gesendet. Unabhängig davon ob der zu erreichende RT nicht gerade schläft. Wieso wartet der nicht auch auf das Wakeup vom RT? Wie kann das überhaupt klappen?
Ich würde es auch gut finden wenn es hier mit fachkundiger Hilfe weiter gehen könnte, den so ist es eigentlich nicht nutzbar und anscheinend hat ja jeder dieses Problem.
Bei mir treten diese Verbindungsprobleme sporadisch auf und verschwinden mal nach einer gewissen Zeit.
Es hat sich ja auch noch keiner gemeldet bei dem das ohne Probleme funktioniert.
Mir kommt es so vor als wenn der RT wenn er mal den Wert vom externen Sensor nicht bekommt sofort auf den internen Sensor umschaltet. Ich habe auch beobachtet das während 1 RT den externen Sensor nicht erkennt , andere ohne Probleme laufen.
Gibt es so ein Problem auch mit den HM Wandthermostaten ?
Wenn nicht dann muss es am virtuellen Sensor liegen, oder ?
Bei mir tritt das Problem übrigens auch auf. Kann jemand vergleichen, ob ein Wandtermostat andere Intervalle sendet?
Kann ich also davon ausgehen das dieses Problem niemanden (der zur Lösung beitragen könnte) ernsthaft interessiert?
>:( >:( >:(
Leider scheint das so zu sein. :-\
Ich würde auch einen Wandthermostaten kaufen wenn es zur Lösung beiträgt. Aber mein Wissen um das analysieren des Homematic Protokolls ist leider zu gering als wenn ich da wirklich was raus bekommen würde.
Ich hoffe das sich vielleicht irgendwer mit dem Fachwissen meldet um der Problematik mal auf den Grund zu gehen, wenn nicht empfehle ich den Wikieintrag um die Verwendung anderer Temperatursensoren zu löscchen da es irre führend ist wenn es nirgends reibungslos funktioniert.
Ich habe leider auch das gleiche Problem mit der gleichen Konfiguration wie beschrieben und so wie es aussieht gibt es keine richtige Lösung für diese spontanen
Aussetzer mit der Kommunikation zwischen virtuellem Temperatursensor und dem HM-CC-RT-DN (3x Lacrosse auf 3x HM-CC-RT-DN gepeert).
Ich habe auch ein Heizkörperthermostat HM-CC-RT-DN mit einem Innentemperatursensor HM-WDS40-TH-I-2 gepeert und dies funktionnier zu 100%.
Ebenfalls habe ich ein Heizkörperthermostat HM-CC-RT-DN mit einem Wandthermostat HM-TC-IT-WM-W-EU gepeert und dies funktionnier auch zu 100%.
So wie es aussieht bleibt nur der Weg über die teuren Homematic-Thermostate und nicht die billige Variante mit LaCrossesensoren, schade >:(
ZitatIch habe auch ein Heizkörperthermostat HM-CC-RT-DN mit einem Innentemperatursensor HM-WDS40-TH-I-2 gepeert und dies funktionnier zu 100%.
Ebenfalls habe ich ein Heizkörperthermostat HM-CC-RT-DN mit einem Wandthermostat HM-TC-IT-WM-W-EU gepeert und dies funktionnier auch zu 100%.
Das ist doch aber mal eine Aussage, jetzt müsste man nur raus bekommen was die Sensoren anders machen als das Virtuelle Device das mit dem HM-CC-RT-DN gepeert wird.
Zitat von: Gerd am 26 Dezember 2015, 10:58:56
Das ist doch aber mal eine Aussage, jetzt müsste man nur raus bekommen was die Sensoren anders machen als das Virtuelle Device das mit dem HM-CC-RT-DN gepeert wird.
Ich hab hier sogar schon einen Verdacht.
Das Ärgerlich an der Sache ist halt das ich schon gut 30-50 Stunden an Zeit mit Aufbau einer Testumgebung, einlesen in einen völlig fremden und unbekannten Sourcecode usw verbracht habe und noch immer in der Forschungsphase bin für Fragen die vom Entwickler oder jemanden der den Code kennt in 5 Minuten beantwortet wären.
Trotzdem denke ich es gibt noch Hoffnung.
Wo ist das Problem?
Wenn man einen externen Sensor nutzt um die temp an den virtuellen Sensor zu schicken und der virtuelle Sensor schließlich die temp an den realen aktor uebermittelt sollte das timing identisch sein. Kann man testen. Wenn es mit dem rein virtuellen Sensor klappt, klappt es auch wie oben.
Wenn damit dem virtuellen nicht klappt ist es auch für die Entwickler eine entsprechend lange Untersuchung.
Also: klappt schritt 1?
Zitat von: martinp876 am 27 Dezember 2015, 08:09:40
Wo ist das Problem?
Wenn man einen externen Sensor nutzt um die temp an den virtuellen Sensor zu schicken und der virtuelle Sensor schließlich die temp an den realen aktor uebermittelt sollte das timing identisch sein. Kann man testen. Wenn es mit dem rein virtuellen Sensor klappt, klappt es auch wie oben.
Wenn damit dem virtuellen nicht klappt ist es auch für die Entwickler eine entsprechend lange Untersuchung.
Also: klappt schritt 1?
Ok ich versuchs nochmal:
Der viruelle Sensor wird mit Temp Daten befüllt. Mittels at ,notifiy, von mir aus auch per Hand. Wüsste nicht wo ich hier ein timing Problem haben könnte, denn die Daten sind ja dann im virtuellen Device vorhanden.
Aber:
Das virtuelle Device sendet dann seine Temp Daten an den RT weiter. Und zwar alle 2,5-3 min aber halt irgendwann, und in keiner Abhängigkeit davon wann die Daten eintreffen(zb eben alle 2 Min per at). Unabhängig davon ob der empfangende RT gerade wach ist oder nicht. Somit geht diese Übertragung vermutlich oftmals ins Leere.
Hierzu habe ich weiter oben auch schon Logs gepostet.Meine Vorstellung wie es sein könnte/sollte: (Bitte um Korrektur wenn ich das System falsch verstanden habe)
Der RT wacht alle 2,5 bis 3 min auf und sendet seinen Statusbericht. Genau dann, nach Empfang dieser Statusnachricht, sollte die Übertragung der Temp Sensor Daten erfolgen. Genau so wie es zb bei einer Übertragung der Solltemperatur oder eine Zeitliste passiert wenn man ohne Burst schickt und die Zentrale die Nachricht aufhebt bis der nächste Statusbericht eintrifft und dann sendet.
Wäre es nicht möglich die Übertragung an oben beschriebene Logik anzupassen?
Kann ich irgendwie weiter was zu Lösung betragen? Tests, Logs , usw? Falls ja bitte um Info.
Danke
Klar geht das ins leere. Der virtuelle aktor macht das timing.
Du Schreiber in den virtuellen aktor. Wenn die Zeit gekommen ist, schreibt der in den RT.
Das timing ist asynchron - und kann nicht geändert werden.
Wenn der Sensor sendetkann es bis zu 3min dauern, bis es beim RT ist.
Wo ist das Problem?
Die Zeit wird nach einem algo errechnet. Der algo kommt von eq3.
Lass es einfach so arbeiten. Rechnen musst du nichts. Eigentlich doch einfach.
Das senden des RT status hat nichts mit den Wetterdaten zu tun.
Zitat von: martinp876 am 27 Dezember 2015, 08:09:40
Wo ist das Problem?
Wenn man einen externen Sensor nutzt um die temp an den virtuellen Sensor zu schicken und der virtuelle Sensor schließlich die temp an den realen aktor uebermittelt sollte das timing identisch sein...
Da ich es noch immer nicht verstehe... wird die Temperatur an den Thermostat gesendet, oder von ihm abgerufen?
Das virtuelle Device oder auch das Wandthermostat hat ja quasi immer eine Temp, egal ob die nun aktualisiert wurde oder nicht.
Virtuelles Device und Wandthermostat müssen diese Temp nun an den gepeerten Thermostatkanal über geben... woher weiss jetzt das Wandthermostat "besser" wann der passende Zeitpunkt ist?
Rein subjektiv würde ich sogar behaupten, dass das schon mal reibungslos funktioniert hat.
Zitat von: martinp876 am 27 Dezember 2015, 19:45:25
Wo ist das Problem?
Das Problem ist das es nicht funktioniert. Ich stelle hier jetzt sogar die Behauptung auf das es mit dieser Konfig niemande gibt wo es funktioniert! Man möge das Gegenteil beweisen.
Zitat von: martinp876 am 27 Dezember 2015, 19:45:25
Wenn die Zeit gekommen ist, schreibt der in den RT.
Da ist es. Genau da würde ich das Problem vermuten. Laut meinen Logs sendet der virtuelle Aktor nämlich immer wieder zu Zeiten wo der RT im schlafmodus ist. das meinte ich mit ins leere gehen. Und wenn das ein paar mal passiert schaltet der RT wohl auf den internen Sensor um.
Ich frage mich gerade ob meine Ausführungen dazu wirklich so schwer zu verstehen sind
Zitat von: Hollo am 27 Dezember 2015, 19:55:52
Da ich es noch immer nicht verstehe... wird die Temperatur an den Thermostat gesendet, oder von ihm abgerufen?
Ich hab in all meinen RAW Logs nirgends einen Abruf gesehen. Die Temp geht einfach "irdendwann" als Broadcast raus.
Zitat von: Hollo am 27 Dezember 2015, 19:55:52
... woher weiss jetzt das Wandthermostat "besser" wann der passende Zeitpunkt ist?
Hollo hat mich verstanden ;-) genau das war auch meine Frage. wie ich verstanden habe wird dieser Zeitpunkt berechnet (2,5-3min) nach irgendeiner Formel. Vermutlich die selbe Formel die dem RT sagt wann er aufwachen und Statusbericht senden soll. So weit so gut. Aber wie erfolgt die synchronisation dieser Zeiten am Anfang? Kann da das Problem sein?
Die wandthermostate errechnen es nach dem gleichen algo wie er im virto genutzt wird. Und der RT wacht entsprechend auf.
Der RT fragt nicht. Aber das alles kannst du sehen, wenn du 20 min logst. Dazu braucht du keine 50h Arbeit.
Der algo steht im code culhm wenn du ihn suchst. Nur ist es brotlose Kunst. Ist implementiert, du kannst es einfach nutzen. Es wird nicht schneller werden.
Wenn ich mal laienhaft fragen darf, was macht ein Wandthermostat denn anders als der virtuelle Sensor, wenn es der selbe Algorythmus ist ? Irgendwas muss da doch anders sein.
Ich sehe in meinen Plots auch immer mal einzelne Aussetzer, bei allen RT mit externem LaCrosse Sensor, in denen dann der interne Temperaturwert genommen wird, manchmal auch über einen längeren Zeitraum.
Wie deckelsmouk geschrieben hat hat er die Aussetzter nur mit den virtuellen Sensoren nicht mit den Raumthermostaten, somit ist es kein grundsätzliches Problem sondern es hängt mit dem Zusammenspiel virtuelles Device und RT zusammen.
Zitat von: Merlin am 27 Dezember 2015, 20:24:32
Das Problem ist das es nicht funktioniert. Ich stelle hier jetzt sogar die Behauptung auf das es mit dieser Konfig niemande gibt wo es funktioniert! Man möge das Gegenteil beweisen.
Das Peering eines RT-DN mit einem virtuellen Temperatursensor hat bei mir über Monate (nahezu) reibungslos funktioniert. Hierzu verweise ich auf folgenden Thread: http://forum.fhem.de/index.php/topic,19686.msg260702.html#msg260702 (http://forum.fhem.de/index.php/topic,19686.msg260702.html#msg260702)
Aus persönlicher Erfahrung würde ich sagen, daß diese Aussetzer (die ich anfangs auch beobachtet habe) grundsätzlich auf Verzögerungen innerhalb des FHEM-Servers, die andere Module verursachen, zurückzuführen sind. Der o.a. Algorithmus berechnet dann zwar den richtigen Sendezeitpunkt, dieser wird aber aufgrund einer Verzögerung (=> über apptime aufspürbar) verpasst. Da das Timing bei HM sehr kritisch ist, kommt es zu den Aussetzern.
Seit einigen Monaten habe ich den virtuellen Temperatursensor durch Dirks Universalsensor ersetzt. Dort gab es anfangs beim Peering mit dem RT-DN ähnliche Aussetzer. Meines Wissens verwendet Dirk in der Firmware (ab v14) des Sensors aber den gleichen Algorithmus zur Berechnung des Sendezeitpunkts.
Trotzdem kann ich daher nicht mit Sicherheit sagen, daß das Peering mit einem virtuellen Sensor mit den aktuellen Modulversionen immer noch reibungslos funktioniert.
@Merlin - Du schreibst, du hast bereits eine Testumgebung aufgebaut. Um Verzögerungen durch andere Module auszuschließen, würde ich einen Test mit Minimalkonfiguration wie folgt machen
- neue FHEM Instanz (default fhem.cfg) mit aktuellen Updates auf sonst möglichst unbenutzter Hardware installieren
- Einbinden JeeLink für LaCrosse Empfang und HM CUL / CFG-USB2 für HM Kommunikation
- Einrichten VCCU
- Pairen von 1x RT-DN
- Einrichten virtuellen Temperatursensor
- Einrichten Peering zw. virt. Tempsensor und RT-DN
- Kontrolle mit HMINFO configCheck und peerXref, ob Peering ok
- ggf. apptime starten
=> Wenn es dann immer noch zu Aussetzern kommt, einen PacketSniff aufsetzen und Martin bitten, diesen zu analysieren.
Tobias
Zitat von: tpm88 am 27 Dezember 2015, 23:07:31
Der o.a. Algorithmus berechnet dann zwar den richtigen Sendezeitpunkt, dieser wird aber aufgrund einer Verzögerung (=> über apptime aufspürbar) verpasst. Da das Timing bei HM sehr kritisch ist, kommt es zu den Aussetzern.
OK ein weiterer Ansatz.
Kann ich davon ausgehen das der "richtig Zeitpunkt" der ist wo der RT wach ist? Also kurz nach seinem Statusbericht?
Falls ja: Dann liege ich laut meinen Logs oftmals auch um 1-2 Minuten daneben. Und: Wieso verwendet man dann nicht den Statusbericht als Trigger so wie es andere "non Burst" Übertragungen zum RT erfolgreich machen?
Falls nein: Ich versteh die Welt nicht mehr und geb auf wenn ich keine logische Erklärung finde :'(
Und wegen der Testumgebung: Da muss ich mir noch einen 2. CUL besorgen für losgelöste Tests...
Zitat von: Merlin am 28 Dezember 2015, 11:23:05
Kann ich davon ausgehen das der "richtig Zeitpunkt" der ist wo der RT wach ist? Also kurz nach seinem Statusbericht?
Falls ja: Dann liege ich laut meinen Logs oftmals auch um 1-2 Minuten daneben. Und: Wieso verwendet man dann nicht den Statusbericht als Trigger so wie es andere "non Burst" Übertragungen zum RT erfolgreich machen?
Falls nein: Ich versteh die Welt nicht mehr und geb auf wenn ich keine logische Erklärung finde :'(
Ein klares NEIN. Nach meinem Verständnis von Martins Ausführungen (weiter oben hier und in zahlreichen anderen Stellen im Forum) ist der Zeitpunkt zum Senden der "pending commands" bei non-burst Befehlen nicht identisch mit dem Senden der Ist-Temperatur für das Peering.
Zitat
Und wegen der Testumgebung: Da muss ich mir noch einen 2. CUL besorgen für losgelöste Tests...
Nicht unbedingt. Wenn Du es dir leisten kannst, die produktive Umgebung z.B. über Nacht einmal stillzulegen, könntest Du auch eine zweite FHEM Instanz in einen anderen Pfad auf der gleichen Hardware installieren und mit dieser testen.
Noch etwas anderes. Das HM-Timing bei Verwendung eines CULs ist für FHEM noch schwieriger einzuhalten, da die Standard CUL Firmware keine Timestamps (im ms Bereich) liefert. Hier empfiehlt sich dringend die von noansi entwickelte Firmware für HM mit Timestamps: http://forum.fhem.de/index.php/topic,31421.0.html (http://forum.fhem.de/index.php/topic,31421.0.html) Bei mir hat diese FW erst ein vernünftiges HM-Timing meiner FHEM-Instanz auf einem Raspberry PI (1. Generation - vergleichsweise langsame Hardware) ermöglicht.
Gruß,
Tobias
Zitat von: tpm88 am 28 Dezember 2015, 17:05:30
Ein klares NEIN. Nach meinem Verständnis von Martins Ausführungen (weiter oben hier und in zahlreichen anderen Stellen im Forum) ist der Zeitpunkt zum Senden der "pending commands" bei non-burst Befehlen nicht identisch mit dem Senden der Ist-Temperatur für das Peering.
OK nehme ich mal so leicht verwirrt hin. Was allerdings insofern mein "Weltbild" von den RT's erschüttert, weil ich dachte das die in der Zeit zwischen ihren Übertragungen schlafen...
Ist das eigentlich alles irgendwo niedergeschrieben? Oder woher habt ihr dieses Wissen? Würde mich da gerne auch mal schlau machen dazu.
Zitat von: tpm88 am 28 Dezember 2015, 17:05:30
Das HM-Timing bei Verwendung eines CULs ist für FHEM noch schwieriger einzuhalten, ...
Hmm Frage: Wenn das alles bei mir mal im endgültigen, dauerhaften Echtbetrieb ist brauch ich sowieso ein Reservedevice. Wäre es nach deiner Aussage besser statt einen 2. CUL ein HMLAN anzuschaffen?
Zitat von: Merlin am 28 Dezember 2015, 18:36:24
Ist das eigentlich alles irgendwo niedergeschrieben? Oder woher habt ihr dieses Wissen? Würde mich da gerne auch mal schlau machen dazu.
naja, irgendwo schon :D Hier im Forum. Aber üblicherweise nicht an einem Ort. Generell viele Infos findest Du natürlich auch im Wiki. Wenn man eine Weile im Forum interessiert mitliest, wird man schlauer...
Was das Schlafen/Aufwachen des RT angeht. Gefühlt muß ich bei dem RT mit "gepeerten" Temperatursensor deutlich häufiger die Batterien wechseln als bei denen ohne. Offenbar wacht er deutlich häufiger auf (oder ist länger wach).
Zitat
Hmm Frage: Wenn das alles bei mir mal im endgültigen, dauerhaften Echtbetrieb ist brauch ich sowieso ein Reservedevice. Wäre es nach deiner Aussage besser statt einen 2. CUL ein HMLAN anzuschaffen?
Meiner Meinung macht ein echtes, separates FHEM-Testsystem (z.B. zweiter RPi ) definitiv Sinn. Statt eines HMLAN würde ich den HM CFG USB 2 nehmen in Verbindung mit dem hmland. Der ist billiger und kann im Gegensatz zum HMLAN auch OTA Firmware Updates bei HM Devices durchführen. Ich habe auch mit einem CUL begonnen und bin später auf dem Produktivsystem auf dem HM-CFG-USB2 umgestiegen. Den CUL nutze ich auf dem Testsystem - siehe auch meine Signature.
Zitat von: tpm88 am 27 Dezember 2015, 23:07:31
Das Peering eines RT-DN mit einem virtuellen Temperatursensor hat bei mir über Monate (nahezu) reibungslos funktioniert. ...
Aus persönlicher Erfahrung würde ich sagen, daß diese Aussetzer (die ich anfangs auch beobachtet habe) grundsätzlich auf Verzögerungen innerhalb des FHEM-Servers, die andere Module verursachen, zurückzuführen sind...
Da stimme ich Dir generell zu.
Ich glaube/meine auch, dass das eine lange Zeit problemlos funktioniert hat.
Nur weiss ich nicht, was ich sich in der Zwischenzeit alles geändert hat. :-[
Das es Unterschiede im Zeitverhalten gibt, sehe ich gelegentlich bei der Aktualisierung meines RSS-Tablets.
Das geht lange problemlos ohne sichtbare Verzögerungen, und dann plötzlich gibt es beim Laden/Aktualisieren "Verzögerungen".
Auch ohne Änderungen an der Konfiguration in der Zwischenzeit.
"Leider" mache ich natürlich häufig Updates. Ich werde das mal ein wenig genauer beobachten und öfter die Logfiles kontrollieren.
also eins nach dem anderen.
der Virtuelle Temp-Sensor sendet immer nach dem gleichen Timing. Idee ist, dass man per Kommando die Temp setzt. Irgendwann. Diese wird dann beim nächsten Senden übertragen.
Woher die temp kommt ist egal.
Wenn man genau zum Sendezeitpunkt anfängt, eine temp zu ermitteln wird dies schief gehen. Das Timing ist zu eng.
somit die erste Frage:
- geht der virtuelle Sensor - ohne extra Firlefanz?
dann 2.
- wollt ihr synchron zum virtuellen Aktor aktionen ergreifen? Ich hoffe nicht.
und 3.
- ist 1 und 2 erledigt: geht es immer noch nicht? Wird tatsächlich das Timing verändert durch das setzen der temp?
OK Martin.Soweit verstanden. Zu deinen Fragen:
1 und 2. : Ja Sensor geht, und bewusst eine Aktion synchron starten will ich nicht (könnte ich ja gar nicht weil das Timing ja unbekannt ist). Die Temp Daten sind schon im virtuellen Sensor drinnen und zwar per at. Wobei es vollkommen egal ist ob der setzende at alle 1,2, oder 3 Minuten läuft oder auch garnicht - denn es wird ja sowieso immer das letzte Reading vom virtuellen sensor übertragen. Egal wie alt es ist.
3.: Ich glaube nicht das sich das timing verändert durch das setzten. Es stimmt halt dann irgendwie plötzlich einfach nicht mehr.
Eine Interessante Beobachtung habe ich aber jetzt gemacht:
Wenn so ein Aussetzer auftritt, dann oft gleich in Gruppen aber nicht immer. Also dann setzt die Übertragung gleichzeitig auch mal bei 3 oder 4 RT's aus und kommt zb nach 15 min zur gleichen Zeit wieder...
OK, dann ist es ein Problem des virtuellen Sensors.
Es kann auch ein performance Problem sein. Fhem hat keine strikte Periodisierung. Eigentlich garkeine.
Timer kommen immer nur dran, wenn der"os-level" dran ist. Läuft ein job zu lange verschiebt er das timing.
Apptime gibt dir Auskunft, ob delays auftreten und\oder Langläufer unterwegs sind. Prüfen das einmal.
Update:
Habe jetzt testweise mal von cul auf hmusb gewechselt. Keine Verbesserung. Im Gegenteil scheint sogar etwas schlimmer geworden zu sein.
Was mich irgendwie dazu bringt doch die Systemhardware (Raspberry 2) zu verdächtigen. Scheint als hätte der weitere zusätzliche Dienst (der hmland) für eine Verschlimmerung gesorgt. Was mich zwar wundert den es ist eine schneller Raspberry und da läuft nur die HM und Lacrosse Funksache drauf. Keine einzige Berechnung, kein Log, nix. Kommt alles vom virtuellen Haupt-fhem Rechner über fhem2fhem.
Nächster Test:
portieren der Raspberry Installation auf eine andere, stärkere Hardware (altes Notebook). Mal sehen...
ZitatNächster Test:
portieren der Raspberry Installation auf eine andere, stärkere Hardware (altes Notebook). Mal sehen...
???
Zitat von: frank am 15 Dezember 2015, 23:29:42
oder hat dein fhem hänger? => siehe apptime, perfmon.
Zitat von: martinp876 am 29 Dezember 2015, 18:02:03
Apptime gibt dir Auskunft, ob delays auftreten und\oder Langläufer unterwegs sind. Prüfen das einmal.
Ja schon klar frank.
da kommt nicht viel, scheint alles ok, desshalb der versuch mit dem Notebook.
Das einzige was mir manchmal auffällt im apptime ist der jeelink read. Und den bekomme ich sowieso nur weg wenn ich die Systeme testweise trenne.
ZitatDas einzige was mir manchmal auffällt im apptime ist der jeelink read. Und den bekomme ich sowieso nur weg wenn ich die Systeme testweise trenne.
zum testen reicht es doch erst einmal, "verdächtige" devices/module abzuschalten, zb mit attr disable.
oder mit einer minimalen fhem.cfg zu arbeiten.
Ja aber wenn ich den Jeelink Empfang abdrehe bekommen die RT nurnoch falsche/statische Temp Werte und dann tickt die Heizung aus - und kurz danach die Frau ;-)
Da is ein Test auf einer schnelleren Hardware leichter (bin gleich fertig mit aufsetzen ...)
ZitatJa aber wenn ich den Jeelink Empfang abdrehe bekommen die RT nurnoch falsche/statische Temp Werte und dann tickt die Heizung aus - und kurz danach die Frau ;-)
Da is ein Test auf einer schnelleren Hardware leichter (bin gleich fertig mit aufsetzen ...)
ich glaube nicht, dass das etwas ändern wird.
wenn schon, dann lagere zb nur die verdächtigen aus und verbinde sie über fhem2fhem mit der hauptinstanz auf dem pi.
grundsätzlich muss dein pi genug power haben, denn sogar meine fritzbox schafft das sensible timing beim ansteuern von hm-cc-vd.
Frank hat leider recht. Keine Änderung.
Nächster Versuch: Alles andere (eigentlich nur Jeelink/Lacrosse weil sonst ist ja garnix drauf) runter und mittels fhem2fhem verbinden.
Aber erst morgen... Grüße und guten Rutsch.
du kannst doch alle problematischen RTs mit ihrem internen Seonsor arbeiten lassen. Wenn ein RT gepeert ist (Weather) und keine Daten bekommt sollte er auf den internen Sensor umschalten. Das ist nicht, was du final willst, aber es sollte halbwegs regeln.
dann kannst du einen RT rauspicken und dem per Script immer neue werte einfüttern. Diese lassen sich dann vergleichen. Ich werde mir wohl eine testbench aufbauen müssen.
Ich habs auf einem Intel Atom 4-core laufen und habe auch die Aussetzer. Ich hoffe nicht, dass fhem einmal mehr CPU erfordert ;-)
Zitat von: JoeALLb am 01 Januar 2016, 13:54:30
Ich habs auf einem Intel Atom 4-core laufen und habe auch die Aussetzer. Ich hoffe nicht, dass fhem einmal mehr CPU erfordert ;-)
nochmal im klartext:
timingprobleme werden in aller regel nicht durch mehr power behoben.
So, ich habe jetzt alles so aufgetrennt, das nur noch der CUL ganz alleine mit den RT's und den VT's auf einem Notebook sind. Die Temp Readings bekommen die VT's per FHEM2FHEM. Somit sollte jeglicher Fremdeinfluss durch andere Komponenten ausgeschlossen sein. Mal sehen. Ist seit 30 Min in Betrieb.
vielen Dank das Du dich da so intensiv drum kümmerst!
Hoffentlich führt es zu einer Lösung des Problems.
So neueste Beobachtungen nach den ersten 12 Stunden:
Am Notebook (alter I5 mit Debian jessie Minimalinstallation und nur fhem+cul) ist es sehr viel besser aber nicht ganz weg.
Erkenntnis daraus:
Schnelle HW bringt nur indirekt etwas weil dadurch möglich Hänger leichter übergangen werden, aber das Grundsätzlich Problem mit dem extrem heiklen Timing bleibt.
Ich hab jetzt am Notebook noch ein wenig optimiert. Der VT Temperatur pusch mittels at läuft nämlich für 11 VT's noch immer über 100ms und verursachen manchmal ein delay von 350ms. Ich hab die jetzt geteilt auf 11 einzelne at wo jeder jeweils 5 sek zeitversetzt läuft.
Mal sehen..
Hast du die TempÜbergabe auch mal mit einem Notify versucht?
Ich habe das mit einem "event-on-change" am laufen und habe dadurch noch kürzere delays und relativ seltene Temperaturänderungen. Jedoch hatte ich keinen
exakten Versuchsaufbau.
Zitat von: Merlin am 02 Januar 2016, 11:53:19
So neueste Beobachtungen nach den ersten 12 Stunden:
Am Notebook (alter I5 mit Debian jessie Minimalinstallation und nur fhem+cul) ist es sehr viel besser aber nicht ganz weg.
Nochmal die Frage - verwendest Du die CUL Firmware mit Timestamps ( siehe http://forum.fhem.de/index.php/topic,31421.0.html (http://forum.fhem.de/index.php/topic,31421.0.html) ) ?
Damit ist die Verwendung des CUL für Homematic bezüglich des Timing IMHO erst vernünftig möglich. Teste einfach mal!
Tobias
Ich verwende den HM-LAN und habe die Probleme auch!
Zitat von: JoeALLb am 02 Januar 2016, 15:29:59
Ich verwende den HM-LAN und habe die Probleme auch!
Mit dem HM-USB2 hab ichs auch getestet. Auch das gleiche Problem.
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.
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?
ZitatMit dem Versuchsaufbau habe ich jetzt...
was ist der Versuchsaufbau?
Zitatdass hier offensichtlich das Timing noch viel kritischer ist als angenommen.
keine Ahnung, was du angenommen hast.
ZitatKennen wir das Zeitfenster für eine korrekte Übertragung?
ja
Zitatund 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.
ZitatHat 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?
Zitat von: martinp876 am 06 Januar 2016, 14:51:41
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.
Dann will ich mal gerade meinen aktuellen Stand ergänzen.
Zitat von: Merlin am 06 Januar 2016, 17:42:05
...
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.
ZitatDie "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.
Zitat von: Hollo am 06 Januar 2016, 19:47:24
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....
Jedenfalls nicht sofort. Ich denke wir haben mit 3 bis 5 Aussetzern erfolgreich experimentiert.
Kann sich das mit einem FW update verändert/verschlechtert haben?
Zitat von: Merlin am 07 Januar 2016, 12:57:35
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
(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.
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!
Zitat2016-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
Zitat von: Hollo am 08 Januar 2016, 09:25:03
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.
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.
Zitat
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
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
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
Zitat von: martinp876 am 10 Januar 2016, 09:28:34
Ich habe einmal einen virtuellen Sensor aufgesetzt. Hat geklappt, habe keine Aussetzer bemerkt.
Ich fürchte unter Laborbedingungen mit nur einem VT/RT wird das schwer nachzustellen. Das macht ja vermutlich auch die Analyse so schwert.
Meine Erkenntnis ist je mehr Last, Funkverkehr usw anstehen umso öfter tritt der Fehler auf.
Das ist wohl korrekt.
Laborbedingungen habe ich keine.
Ich beobachte das Problem auch schon seit längerer Zeit. Da ich nach einer Lösung bereits im letzten Jahr gesucht hatte, wo es diesen Post noch nicht gab, habe ich gestern Abend einen neuen aufgemacht. Dieser ist hier zu finden: http://forum.fhem.de/index.php?topic=47379.msg391051 (http://forum.fhem.de/index.php?topic=47379.msg391051)
Ich habe heute Nacht mal Apptime laufen gelassen:
name function max count total average maxDly
SqueezeServer SB_SERVER_Read 1151 1347 9712 7.21 0 HASH(SqueezeServer)
tmr-at_Exec HASH(0x5696060) 1091 1 1091 1091.00 4 HASH(AquariumHeizungEin)
SK_Temp_Verlauf dummy_Set 1089 1 1089 1089.00 0 HASH(SK_Temp_Verlauf); SK_Temp_Verlauf; on
SK_Schalten notify_Exec 1081 1 1081 1081.00 0 HASH(SK_Schalten); HASH(SK_Temp_Verlauf)
tmr-CUL_HM_updateConfig updateConfig 1051 1 1051 1051.00 0 updateConfig
myJeeLink_866 JeeLink_Define 1027 1 1027 1027.00 0 HASH(myJeeLink_866); myJeeLink_866 JeeLink /dev/ttyUSB0@57600
tmr-Calendar_Wakeup HASH(0x5111a58) 413 15 5008 333.87 2 HASH(Abfall)
PushBullet Pushbullet_Define 408 1 408 408.00 0 HASH(PushBullet); PushBullet Pushbullet lPwQydXJnTsmYvQFgKe9wOAjSQZi200h
myJeeLink_866 JeeLink_Read 337 7 814 116.29 0 HASH(myJeeLink_866)
SK_AQ2_Heizen THRESHOLD_Set 279 1 279 279.00 0 HASH(SK_AQ2_Heizen); SK_AQ2_Heizen; desired; 22.1
SK_AQ1_Heizen THRESHOLD_Set 278 6 278 46.33 0 HASH(SK_AQ1_Heizen); SK_AQ1_Heizen; desired; 22.1
HMLAN1 HMLAN_Read 271 7678 61631 8.03 0 HASH(HMLAN1)
SK_AQ1_Heizen THRESHOLD_Notify 268 30129 777 0.03 0 HASH(SK_AQ1_Heizen); HASH(SK_AQ1_TemperaturSensor)
SK_AQ2_Heizen THRESHOLD_Notify 264 30129 678 0.02 0 HASH(SK_AQ2_Heizen); HASH(SK_AQ2_TemperaturSensor)
tmr-at_Exec HASH(0x4d061a0) 258 860 91914 106.88 5 HASH(VirtuelleTemperatur)
SK_AQ1_Heizung IT_Set 257 3 767 255.67 0 HASH(SK_AQ1_Heizung); SK_AQ1_Heizung; off
CUL_433 CUL_Get 256 8 2029 253.62 0 HASH(CUL_433); ; raw; is0FFFF00FFFF0
SK_AQ1_Licht IT_Set 254 1 254 254.00 0 HASH(SK_AQ1_Licht); SK_AQ1_Licht; on
SK_AQ2_Licht IT_Set 254 1 254 254.00 0 HASH(SK_AQ2_Licht); SK_AQ2_Licht; on
SK_AQ2_Heizung IT_Set 253 3 759 253.00 0 HASH(SK_AQ2_Heizung); SK_AQ2_Heizung; off
tmr-at_Exec HASH(0x53391c8) 201 1 201 201.00 1 HASH(SK_Temp_berechnen)
Ich habe übrigens Thermostate mit 1.3 und 1.4 und der Fehler tritt bei allen auf.
Ich hänge mal noch meinen Log dran, wo alle Abweichungen zwischen Thermostat und Sensor größer als 0.5K erfasst werden.
Gibt es etwas was ich zur Unterstützung der Fehlersuche beitragen kann? Infos, Versuche?
SK_AQ1_Heizen THRESHOLD_Notify 268 30129 777 0.03 0 HASH(SK_AQ1_Heizen); HASH(SK_AQ1_TemperaturSensor)
SK_AQ2_Heizen THRESHOLD_Notify 264 30129 678 0.02 0 HASH(SK_AQ2_Heizen); HASH(SK_AQ2_TemperaturSensor)
in einer nacht jeweils über 30000 aufrufe ist sicherlich zuviel und unnötig. :)
Hallo,
ich habe bei der "erweiterten Fehlersuche" etwas entdeckt:
der NTP daemon beeinflusst das Timigverhalten extrem negativ! Da hier ja das Timing sehr eng ist und sehr exakt sein muss, sind permanante Aktualiesierungen der Systemzeit wohl sehr kontraproduktiv!
Hab das durch Zufall entdeckt. Auf einem Testsystem mit Minimalkonfiguration hab ich inzwischen mit der Timig Firmware Erweiterung vom CUL eine recht stabile Konfiguration. Dann ist mir aufgefallen das die Uhrzeiten im Log nicht 100% passen und ich den ntp vergessen hatte zu installieren. Hab den nachinstalliert und das System ist wieder komplett ausgeflippt! Wieder deinstalliert und alles ist wieder gut.
Kann das jemand nachstellen/bestätigen?
Zitat von: Merlin am 14 Januar 2016, 13:59:13
...der NTP daemon beeinflusst das Timigverhalten extrem negativ! ...
Kann das jemand nachstellen/bestätigen?
Dann war ich hier http://forum.fhem.de/index.php/topic,45735.msg386221.html#msg386221 (vorletzter Absatz) ja schon auf der richtigen Spur.
Mein BananaPro wird übrigens auch per ntp-Daemon von meinem Server "syncronisiert".
Werde den Dienst mal stoppen und beobachten.
Parallel ist mir aufgefallen, dass die zyklische Aktualisierung des MPD (anderer Rechner) ganz schön bremst.
Da gab es auch schon mal Meldungen, dass fhem quasi einfriert, wenn ein MPD-Server nicht mehr erreichbar ist... ???
Zitat von: frank am 14 Januar 2016, 13:44:49
SK_AQ1_Heizen THRESHOLD_Notify 268 30129 777 0.03 0 HASH(SK_AQ1_Heizen); HASH(SK_AQ1_TemperaturSensor)
SK_AQ2_Heizen THRESHOLD_Notify 264 30129 678 0.02 0 HASH(SK_AQ2_Heizen); HASH(SK_AQ2_TemperaturSensor)
in einer nacht jeweils über 30000 aufrufe ist sicherlich zuviel und unnötig. :)
Ich sehe ein, dass es etwas viel ist, aber ich weiß gerade nicht, wie ich daran was ändern soll. Eine Ausgabe von Apptime sortiert nach der Häufigkeit der Counts ergibt, dass alle Dinge die auf Ereignisse warten, so oft ausgeführt werden (notifys, thresholds, logs).
name function max count total average maxDly
AlleHeizungen structure_Notify 14 1427 85 0.06 0 HASH(AlleHeizungen); HASH(ZE.Batterie)
FileLog_bz_Temperatur FileLog_Log 14 1427 180 0.13 0 HASH(FileLog_bz_Temperatur); HASH(wc_Temperatur)
FileLog_ez_Temperatur FileLog_Log 12 1427 87 0.06 0 HASH(FileLog_ez_Temperatur); HASH(ku_Temperatur)
FileLog_ke_Temperatur FileLog_Log 6 1427 107 0.07 0 HASH(FileLog_ke_Temperatur); HASH(SchildkroetenWarnung_2)
FileLog_ku_Temperatur FileLog_Log 18 1427 129 0.09 0 HASH(FileLog_ku_Temperatur); HASH(ZE.Batterie)
FileLog_os_Temperatur FileLog_Log 13 1427 127 0.09 0 HASH(FileLog_os_Temperatur); HASH(bz_v_Temperatur)
FileLog_sz_Temperatur FileLog_Log 10 1427 95 0.07 0 HASH(FileLog_sz_Temperatur); HASH(sz_v_Temperatur)
FileLog_wc_Temperatur FileLog_Log 22 1427 125 0.09 0 HASH(FileLog_wc_Temperatur); HASH(ZE.Batterie)
HMLAN1 HMLAN_Notify 5 1427 7 0.00 0 HASH(HMLAN1); HASH(ZE.Batterie)
Logfile FileLog_Log 24 1427 156 0.11 0 HASH(Logfile); HASH(SensorFehler)
SB_Kindle SB_PLAYER_Notify 35 1427 942 0.66 0 HASH(SB_Kindle); HASH(ZE.Batterie)
SB_S5_Norman SB_PLAYER_Notify 29 1427 987 0.69 0 HASH(SB_S5_Norman); HASH(ZE.Batterie)
SK_AQ1_Heizen THRESHOLD_Notify 6 1427 25 0.02 0 HASH(SK_AQ1_Heizen); HASH(ZE.Batterie)
SK_AQ2_Heizen THRESHOLD_Notify 5 1427 15 0.01 0 HASH(SK_AQ2_Heizen); HASH(sz_v_temp)
SchildkroetenWarnung_0 THRESHOLD_Notify 33 1427 259 0.18 0 HASH(SchildkroetenWarnung_0); HASH(ke_TemperaturSensor)
SchildkroetenWarnung_1 THRESHOLD_Notify 28 1427 245 0.17 0 HASH(SchildkroetenWarnung_1); HASH(ke_TemperaturSensor)
SchildkroetenWarnung_2 THRESHOLD_Notify 29 1427 236 0.17 0 HASH(SchildkroetenWarnung_2); HASH(ke_TemperaturSensor)
SchildkroetenZuKalt_0 THRESHOLD_Notify 559 1427 777 0.54 0 HASH(SchildkroetenZuKalt_0); HASH(ke_TemperaturSensor)
SchildkroetenZuKalt_1 THRESHOLD_Notify 566 1427 846 0.59 0 HASH(SchildkroetenZuKalt_1); HASH(ke_TemperaturSensor)
SchildkroetenZuKalt_2 THRESHOLD_Notify 59 1427 239 0.17 0 HASH(SchildkroetenZuKalt_2); HASH(ke_TemperaturSensor)
SqueezeServer SB_SERVER_Notify 8 1427 32 0.02 0 HASH(SqueezeServer); HASH(kz_TemperaturSensor)
WA_Handy_Norman_Log FileLog_Log 31 1427 2378 1.67 0 HASH(WA_Handy_Norman_Log); HASH(ZE.Batterie)
WEB FW_Notify 2 1427 7 0.00 0 HASH(WEB); HASH(ku_v_Temperatur)
WEB_192.168.100.37_54565 FW_Notify 8 1427 19 0.01 0 HASH(WEB_192.168.100.37_54565); HASH(kz_v_temp)
WEB_192.168.100.37_54566 FW_Notify 13 1427 19 0.01 0 HASH(WEB_192.168.100.37_54566); HASH(ZE.Batterie)
WEB_192.168.100.37_54567 FW_Notify 5 1427 9 0.01 0 HASH(WEB_192.168.100.37_54567); HASH(os_TemperaturSensor)
WEB_192.168.100.37_54568 FW_Notify 14 1427 26 0.02 0 HASH(WEB_192.168.100.37_54568); HASH(ZE.Batterie)
WEBphone FW_Notify 3 1427 7 0.00 0 HASH(WEBphone); HASH(wz_TemperaturSensor)
WEBtablet FW_Notify 2 1427 4 0.00 0 HASH(WEBtablet); HASH(SensorFehler)
ZE.Activity readingsGroup_Notify 46 1427 5390 3.78 0 HASH(ZE.Activity); HASH(ez_Thermostat)
ZE.Batterie readingsGroup_Notify 122 1427 19677 13.79 0 HASH(ZE.Batterie); HASH(ez_TemperaturSensor)
ZE.Empfaenger readingsGroup_Notify 32 1427 80 0.06 0 HASH(ZE.Empfaenger); HASH(global)
ZE.MotorError readingsGroup_Notify 84 1427 5810 4.07 0 HASH(ZE.MotorError); HASH(ku_Thermostat)
ZE.WatchCUL_433 watchdog_Notify 10 1427 116 0.08 0 HASH(ZE.WatchCUL_433); HASH(ez_TemperaturSensor)
ZE.WatchCUL_433_long watchdog_Notify 14 1427 52 0.04 0 HASH(ZE.WatchCUL_433_long); HASH(os_TemperaturSensor)
ZE.WatchHMLAN1 watchdog_Notify 11 1427 100 0.07 0 HASH(ZE.WatchHMLAN1); HASH(wc_TemperaturSensor)
ZE.WatchHMLAN1_long watchdog_Notify 11 1427 51 0.04 0 HASH(ZE.WatchHMLAN1_long); HASH(wc_Thermostat_Weather)
ZE.WatchmyJeeLink_866 watchdog_Notify 11 1427 73 0.05 0 HASH(ZE.WatchmyJeeLink_866); HASH(bz_v_Temperatur)
ZE.WatchmyJeeLink_866_long watchdog_Notify 14 1427 63 0.04 0 HASH(ZE.WatchmyJeeLink_866_long); HASH(Verbrauch)
eventTypes eventTypes_Notify 23 1427 117 0.08 0 HASH(eventTypes); HASH(bz_Thermostat)
n_FTUI_Thermostat notify_Exec 28 1427 1877 1.32 0 HASH(n_FTUI_Thermostat); HASH(ZE.Batterie)
n_weatherNow notify_Exec 28 1427 1706 1.20 0 HASH(n_weatherNow); HASH(kz_Thermostat)
wc_n_PIR notify_Exec 22 1427 261 0.18 0 HASH(wc_n_PIR); HASH(ez_TemperaturSensor)Das ist in geschätzen 15 Minuten nach Start von Apptime zusammen gekommen.
Edit: Ich habe apptime gerade mal gestartet und nach wenigen Sekunden das Ergebnis angesehen. ALLE notifys und logs haben nach wenigen Sekunden bereits vier Aufrufe. Die meisten davon haben zusammen 0ms Dauer. Ich mache mir über die 30000 erstmal keine Gedanken.
name function max count total average maxDly
myJeeLink_866 JeeLink_Read 17 10 57 5.70 0 HASH(myJeeLink_866)
AlleHeizungen structure_Notify 0 4 0 0.00 0
FileLog_bz_Temperatur FileLog_Log 0 4 0 0.00 0
FileLog_ez_Temperatur FileLog_Log 0 4 0 0.00 0
FileLog_ke_Temperatur FileLog_Log 0 4 0 0.00 0
FileLog_ku_Temperatur FileLog_Log 0 4 0 0.00 0
FileLog_os_Temperatur FileLog_Log 0 4 0 0.00 0
FileLog_sz_Temperatur FileLog_Log 1 4 1 0.25 0 HASH(FileLog_sz_Temperatur); HASH(ku_TemperaturSensor)
FileLog_wc_Temperatur FileLog_Log 0 4 0 0.00 0
HMLAN1 HMLAN_Notify 0 4 0 0.00 0
Logfile FileLog_Log 0 4 0 0.00 0
SB_Kindle SB_PLAYER_Notify 0 4 0 0.00 0
SB_S5_Norman SB_PLAYER_Notify 0 4 0 0.00 0
SK_AQ1_Heizen THRESHOLD_Notify 0 4 0 0.00 0
SK_AQ2_Heizen THRESHOLD_Notify 0 4 0 0.00 0
SchildkroetenWarnung_0 THRESHOLD_Notify 0 4 0 0.00 0
SchildkroetenWarnung_1 THRESHOLD_Notify 0 4 0 0.00 0
SchildkroetenWarnung_2 THRESHOLD_Notify 0 4 0 0.00 0
SchildkroetenZuKalt_0 THRESHOLD_Notify 0 4 0 0.00 0
SchildkroetenZuKalt_1 THRESHOLD_Notify 0 4 0 0.00 0
SchildkroetenZuKalt_2 THRESHOLD_Notify 1 4 1 0.25 0 HASH(SchildkroetenZuKalt_2); HASH(ke_TemperaturSensor)
SqueezeServer SB_SERVER_Notify 0 4 0 0.00 0
WA_Handy_Norman_Log FileLog_Log 3 4 3 0.75 0 HASH(WA_Handy_Norman_Log); HASH(wz_TemperaturSensor)
WEB FW_Notify 0 4 0 0.00 0
WEB_192.168.100.21_51796 FW_Notify 1 4 1 0.25 0 HASH(WEB_192.168.100.21_51796); HASH(wz_TemperaturSensor)
WEB_192.168.100.21_51859 FW_Notify 0 4 0 0.00 0
WEB_192.168.100.37_55726 FW_Notify 0 4 0 0.00 0
WEB_192.168.100.37_55727 FW_Notify 1 4 1 0.25 0 HASH(WEB_192.168.100.37_55727); HASH(ke_TemperaturSensor)
WEB_192.168.100.37_55728 FW_Notify 0 4 0 0.00 0
WEB_192.168.100.37_55729 FW_Notify 0 4 0 0.00 0
WEBphone FW_Notify 0 4 0 0.00 0
WEBtablet FW_Notify 0 4 0 0.00 0
ZE.Activity readingsGroup_Notify 0 4 0 0.00 0
ZE.Batterie readingsGroup_Notify 0 4 0 0.00 0
ZE.Empfaenger readingsGroup_Notify 0 4 0 0.00 0
ZE.MotorError readingsGroup_Notify 0 4 0 0.00 0
ZE.WatchCUL_433 watchdog_Notify 0 4 0 0.00 0
ZE.WatchCUL_433_long watchdog_Notify 0 4 0 0.00 0
ZE.WatchHMLAN1 watchdog_Notify 0 4 0 0.00 0
ZE.WatchHMLAN1_long watchdog_Notify 1 4 1 0.25 0 HASH(ZE.WatchHMLAN1_long); HASH(ku_TemperaturSensor)
ZE.WatchmyJeeLink_866 watchdog_Notify 0 4 0 0.00 0
ZE.WatchmyJeeLink_866_long watchdog_Notify 0 4 0 0.00 0
eventTypes eventTypes_Notify 1 4 1 0.25 0 HASH(eventTypes); HASH(ke_TemperaturSensor)
n_FTUI_Thermostat notify_Exec 1 4 1 0.25 0 HASH(n_FTUI_Thermostat); HASH(ke_TemperaturSensor)
n_weatherNow notify_Exec 0 4 0 0.00 0
wc_n_PIR notify_Exec 1 4 1 0.25 0 HASH(wc_n_PIR); HASH(sz_TemperaturSensor) Ich habe mal von meinen 7 Thermostaten von 6 Stück das Peering rückgängig gemacht und schaue, ob das Einfluss auf den Fehler hat.
[Update]: Fehler ist nach circa 18 Stunden wieder aufgetaucht.
Gleich zum Anfang die gute Nachricht: Die virtuellen Devices arbeiten bereits die ganze Nacht (9 Stunden) fehlerfrei mit den Thermostaten zusammen.
Das Unpeering der 6 Thermostate hat leider nichts gebracht. Dafür habe ich aber durch diesen Versuch trotzdem das ganze zum Laufen gebracht, ich bin mir ziemlich sicher, dass ich das Problem identifiziert habe.
Aber erstmal beim Anfang beginnen.
Ich habe bis auf das Wohnzimmerthermostat alle Thermostate von den virtuellen Devices getrennt (set virtuelles_Device_Channel peerChan 0 thermostat_Weather single unset). Leider hat das nicht zum Erfolg geführt. Das Wohnzimmerthermostat hat für eine Stunde nahezu durchgängig nicht die richtige Temperatur gehabt.
Ich habe weiter nach einer Lösung gesucht und unter anderem das Attribut "hmLanQlen" vom HMLAN von "low" (0) auf "normal" (3) gesetzt. Ich glaube, dass dies nicht die Lösung war, denn das Wohnzimmerthermostat hat weiterhin Fehler produziert. Ich kann es aber auch nicht zu 100% ausschließen, dass dies nicht geholfen hat.
Außerdem habe ich FHEM neugestartet. Dies hatte zur Folge das der Channel vom virtuellen Device seine Eigenschaft als "virtTemp" verloren hat. ("set XXX virtTemp XX führt zu einer Fehlermeldung).
Da dies alles nicht geholfen hat, habe ich die Channel wieder miteinander gepeert (set virtuelles_Device_Channel peerChan 0 thermostat_Weather single). Und siehe da, die 6 zuvor getrennten Thermostate haben einwandfrei die Temperatur aus dem virtuellen Device übernommen. Nur das Wohnzimmerthermostat war weiterhin fehlerhaft.
Also habe ich nach einer Beobachtungszeit das gleiche für das Wohnzimmer gemacht. Peering aufheben, FHEM neustarten (kein virtTemp mehr), wieder gepeer und schon lief auch das Wohnzimmerthermostat einwandfrei. Und sie tun es auch weiterhin.
Meine Schlussfolgerungen:
Ich habe also über die Ursache nachgedacht. Der Zeitraum zur Kommunikation wird ja vom Modul berechnet, aber irgendwoher muss das Modul ja wissen, was es berechnen muss. Dies muss ihm irgendwie einmalig mitgeteilt werden. Ich gehe davon aus, dass das beim "ersten Kontakt" also beim Peering stattfindet.
Nun läuft nach einer gewissen Zeit, aber die Uhrzeit zwischen FHEM und Thermostat auseinander, da Uhren nie hundertprozentig synchron laufen. Deswegen laufen die Thermostate eine Weile gut, aber irgendwann treten diese Fehler auf.
Wie kann dem Abhilfe geschaffen werden? Eine regelmäßige Synchronisation der Uhrzeit sollte helfen. Diese hatte ich eh schon vor ein paar Wochen eingerichtet, da das Thermostat im Badezimmer morgens auch immer als Uhr genutzt wird. Da ich dort ein paar Minuten Abweichung hatte, lasse ich mittels at um Mitternacht die Uhrzeit der Thermostate auf die Uhrzeit von FHEM setzen (set thermostat_Clima sysTime).
Wie macht dies denn eigentlich Homematic selbst? Es ist eher unwahrscheinlich, dass die Uhrzeit von automatisierten Geräten von Hand gesetzt werden müssen. Also kurz gegoogelt und auch die CCUs von Homematic synchronisieren die Uhrzeit um Mitternacht.
Also nochmal zusammen gefasst.
Problem beheben durch Aufheben des Peerings. Mittels HMINfO überprüfen (configCheck), ob das Peering auch wirklich in beiden Channels gelöscht wurde. Zwischendrin Neustart (eventuell nicht nötig). Peering der Channels wiederherstellen.
Damit das Problem nicht erneut auftritt, die Uhrzeit regelmäßig synchronisieren. (Um den Fehler beim Uhrzeit setzen nicht selber zu erzeugen, sollte die Uhrzeit beim Peering schon synchron sein.)
Langfristig wäre es sinnvoll, wenn das CUL_HM-Modul das synchroniseren der Uhrzeit übernimmt, damit es die selbe Funktionalität wie die CCU hat.
Es wäre sogar zu überlegen, ob nicht FHEM selber alle Devices (nicht nur HM), die die Möglichkeit haben die Uhr zu stellen, diese regelmäßig synchronisieren sollten.
Es wäre schön, wenn andere dies auch mal probieren und bestätigen könnten. Wenn nicht, habe ich all das umsonst geschrieben^^
ZitatLangfristig wäre es sinnvoll, wenn das CUL_HM-Modul das synchroniseren der Uhrzeit übernimmt, damit es die selbe Funktionalität wie die CCU hat.
das geschieht doch schon jeden tag.
Zitat von: frank am 15 Januar 2016, 11:30:02
das geschieht doch schon jeden tag.
Okay. Ich kann nur sagen, das mein Thermostat nach einiger Zeit eine Abweichung von zwei Minuten hatte. Im Moment läuft immer noch alles fehlerfrei. Ich werde es weiter beobachten. Es war nur eine Vermutung, dass es an der Zeit liegt.
ZitatIch kann nur sagen, das mein Thermostat nach einiger Zeit eine Abweichung von zwei Minuten hatte.
du hast hmlan?
vergleiche seine zeit mit fhemzeit.
Der Fehler ist wieder aufgetaucht. :-(
Erst hat das Wohnzimmerthermostat gegen 16 Uhr wieder angefangen und etwas später auch andere. Mittlerweile kommen die Abweichungen wieder "öfter".
Wie kann ich die aktuelle Zeit vom HMLAN auslesen? In HMLAN1_TIME springt die Zeit immer (ca. alle 20-30 Sekunden. keepAlive?). Diese stimmt zwar ungefähr überein, aber ein überprüfen ist so recht schwierig.
ZitatMittlerweile kommen die Abweichungen wieder "öfter".
wenn du jetzt ein set sysTime machst, wird es dann wieder besser? eventuell braucht es etwas zeit dafür.
ZitatWie kann ich die aktuelle Zeit vom HMLAN auslesen?
am einfachsten eventuell, indem du die keepalive logst "attr hmlan logIDs sys". kann man wohl mittlerweile auch im eventmonitor sehen. wenn dann ein keepalive kommt, schaust du in den internals des hmlan nach. dann solltest du die differenz vom timestamp des logs und hmlan_time bekommen können.
Zitat von: frank am 15 Januar 2016, 11:30:02
das geschieht doch schon jeden tag.
Weißt du zufällig wann/wie oft?
ok, mir wurde zu kalt... hab jetzt auf einen hm- thermostat gewechselt, und gut ist....
Viel Glück euch....
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.
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 02041E186223etwas lektüre: http://forum.fhem.de/index.php/topic,28088.0.html (http://forum.fhem.de/index.php/topic,28088.0.html)
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?
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.
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.
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. >:(
Wenn die bat so schnell leer ist hat das device einen schaden oder es wird Staendig burst ausgelöst.
Hast du burst im griff?
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? ???
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.
Gibt es hier Neuigkeiten?
Ich habe aktuelle das gleiche Problem, der HM-CC-RT-DN übernimmt die Temperatur nicht mehr vom Virtual Device.
ich habe immer mal wieder Aussetzer. Mal für 1Messwert, mal für 2Stunden. Habe aber keine Lösung gefunden.
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.
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?
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
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.
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.
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.
Ob LaCrosse oder jedes andere beliebige Thermometer ist ja völlig egal. Das Problem scheinen ja die virtuellen Devices zu sein.
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.
ich verwendete Panstamp Boards als Sensoren. Egal ob per AT Notifiy oder sonstwas, die Werte vom virtuellen Sensor landen nie beim RT.
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?
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.
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?
Ich denke das haben alle die als externen Sensor kein HM Device nutzen.
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!
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.
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.
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
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.
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 :(
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.
Also eure Vermutung ist, dass die Temperatur vom virt.Sensor gesendet wird, aber der RT gerade nicht lauscht? Und eigentlich sollten die beiden beim ersten Kontakt ein (wiederkehrendes?) Zeitfenster in der Zukunft (paar Minuten) vereinbaren, in dem der RT sich empfangsbereit hält und der TC dann sendet?
Ist das soweit schon gesichertes Wissen oder erstmal eine Annahme?
Erste Frage: Warum wird die Temperatur nicht einfach als Burst gesendet?
Ich könnte bestimmt den grundlegenden Nachrichtenaustausch ausforschen und rausfinden, wer wann sendet. Aber ich fürchte, wenn da wirklich Synchronisationsmechanismen in FHEM fehlen, dann werde ich da nicht helfen können. Ist die Frage, ob das jemand außer Martin kann :/
So sieht das bei mir aus, wenn der virt.Sensor aufwacht und die Temperatur abschickt:
2017-01-24 17:05:56.588 CUL_HM bd_hmVirtualWeather temperature: -17.0
2017-01-24 17:05:56.591 CUL_HM bd_hmVirtualWeather set_virtTemp -17.0
...
2017-01-24 17:08:43.304 CUL_HM bd_hmVirtual CMDs_pending
2017.01.24 17:08:43.304 0 : HMLAN_Send: HMLAN0 S:+000000,00,00,002017.01.24 17:08:43.305 0 : HMLAN_Send: HMLAN0 S:SD13C8D81 stat: 00 t:00000000 d:01 r:D13C8D81 m:D1 8670 F16789 000000 7F562017-01-24 17:08:43.310 CUL_HM bd_hmVirtual CMDs_done
2017.01.24 17:08:43.436 0 : HMLAN_Parse: HMLAN0 R:RD13C8D81 stat:0002 t:00000000 d:FF r:7FFF m:D1 8670 F16789 000000 7F56
2017.01.24 17:08:52.585 0 : HMLAN_Send: HMLAN0 I:K
Sprich: Er schickt um 17:08:43.304 die Nachricht ab (ich denke mal die Temp-Nachricht), aber er bekommt dann daraufhin um 17:08:43.436, also ca. 100 ms später, auch eine Antwort. Wenn das die Antwort vom RT ist, dann würde das ja bedeuten, dass der RT doch empfangen hat.
Leider sagen mir die Nachrichten sehr wenig. "F16789" ist auf jeden Fall die HM-ID meines virt. Devices, ist auch in der ersten Nachricht zu sehen. In der Antwort kann ich leider keine ID finden, die auf den Absender hindeutet, nur wieder die "F16789".
Bedeutet für mich entweder:
- jemand anders als RT hat geantwortet (aber sollte nicht so sein, oder?)
- der RT hat zwar geantwortet (und daher auch empfangen), aber die Temperatur trotzdem nicht übernommen.
hier hat kein device geantwortet. das ist die bestätigung vom hmusb über das senden.
da es eine msg an broadcast (0x000000) ist, wird sie auch keiner bestätigen. das ist ja sicherlich auch die schwierigkeit bei dieser kommunikation. fhem kann nicht erkennen, dass der rt empfangen hat.
wie gesagt, ich habe weder rt noch tc.
ich nutze allerdings einen virtuellen tc, um damit ventile (hm-cc-vd) zu steuern. hierbei ist die berechnung des nächsten kommunikationsfenster identisch. aber der vd antwortet hierbei, wenn das fenster korrekt getroffen wurde. bei jedem nichttreffen vergrössert der vd das fenster etwas und synchronisiert sich entsprechend bei erneutem treffen. da fhem dadurch eine synchronisation des vd erkennen kann, kann sich fhem auch entsprechen darauf einstellen. nach 6 erfolglosen versuchen hintereinander schläft der vd für eine ganze stunde komplett ein. danach ist er ein paar minuten dauerwach, um auf jeden fall wieder eine kommunikation zu schaffen. fhem ist bei mir aber in der lage eigentlich dauerhaft die kommunikation zu ermöglichen. ein fhem ohne verzögerungen ist natürlich voraussetzung.
beim rt/tc muss das etwas anders ablaufen. da ich aber noch nie davon gehört habe, dass es bei dieser kombination fälle gab, wo der rt auf seine eigene temp umgeschaltet hat, müsste es hier eigentlich auch einen synchronisations mechanismus geben. ich kann mir nicht vorstellen, dass die "uhren" beider devices, so genau gehen, dass es über wochen oder monate keine aussetzer gibt. unterscheiden muss man sicherlich noch, welche channel gepeert sind. im unterschied zum vd, meldet sich der rt sogar zyklisch von selbst und wäre auch über burst erreichbar. daher denke ich, dass nur eine kleinigkeit fehlt, damit es auch dauerhaft funktionieren sollte.
Nur soviel dazu:
Mein RT funktioniert ohne Aussetzer mit einem TC, ein anderer mit einem eigenbau sensor (Dirk!).
Mit burst hat es in keinem Fall etwas zu tun .
Evtl bei Dirk nach der Berechnungsmethode fragen.
Ich gehe davon aus, dass sich der Empfänger bei jeder mesage neu synchronisiert. Ist aber unbewiesen.
Zitat von: vbs am 24 Januar 2017, 17:19:51
So sieht das bei mir aus, wenn der virt.Sensor aufwacht und die Temperatur abschickt:
2017.01.24 17:08:43.304 0 : HMLAN_Send: HMLAN0 S:+000000,00,00,002017.01.24 17:08:43.305 0 : HMLAN_Send: HMLAN0 S:SD13C8D81 stat: 00 t:00000000 d:01 r:D13C8D81 m:D1 8670 F16789 000000 7F562017-01-24 17:08:43.310 CUL_HM bd_hmVirtual CMDs_done
2017.01.24 17:08:43.436 0 : HMLAN_Parse: HMLAN0 R:RD13C8D81 stat:0002 t:00000000 d:FF r:7FFF m:D1 8670 F16789 000000 7F56
2017.01.24 17:08:52.585 0 : HMLAN_Send: HMLAN0 I:K
Sprich: Er schickt um 17:08:43.304 die Nachricht ab (ich denke mal die Temp-Nachricht), aber er bekommt dann daraufhin um 17:08:43.436, also ca. 100 ms später, auch eine Antwort. Wenn das die Antwort vom RT ist, dann würde das ja bedeuten, dass der RT doch empfangen hat.
Leider sagen mir die Nachrichten sehr wenig. "F16789" ist auf jeden Fall die HM-ID meines virt. Devices, ist auch in der ersten Nachricht zu sehen. In der Antwort kann ich leider keine ID finden, die auf den Absender hindeutet, nur wieder die "F16789".
Bedeutet für mich entweder:
- jemand anders als RT hat geantwortet (aber sollte nicht so sein, oder?)
- der RT hat zwar geantwortet (und daher auch empfangen), aber die Temperatur trotzdem nicht übernommen.
Für mich sieht's so aus als ob beides die selbe Message ist:
In beiden Zeilen beginnt die Message mit D1 (Messagenummer), dann gefolgt von 86 (Flags - die sagen aus, daß kein ACK auf diese Nachricht folgen soll), dann das Src-Device (F16789), dann Dest (000000, also Broadcast - kein spezielles Zieldevice), dann die Payload.
Sieht also nicht so aus, als ob jemand geantwortet hätte - eher zwei Verarbeitungssteps innerhalb fhem...
Martin
Zitat von: frank am 24 Januar 2017, 19:16:56
beim rt/tc muss das etwas anders ablaufen. da ich aber noch nie davon gehört habe, dass es bei dieser kombination fälle gab, wo der rt auf seine eigene temp umgeschaltet hat, müsste es hier eigentlich auch einen synchronisations mechanismus geben. ich kann mir nicht vorstellen, dass die "uhren" beider devices, so genau gehen, dass es über wochen oder monate keine aussetzer gibt. unterscheiden muss man sicherlich noch, welche channel gepeert sind. im unterschied zum vd, meldet sich der rt sogar zyklisch von selbst und wäre auch über burst erreichbar. daher denke ich, dass nur eine kleinigkeit fehlt, damit es auch dauerhaft funktionieren sollte.
Beim RT wird der Abstand zum nächsten Zeitfenster aufgrund der Messagenummer und der Device-ID des TC berechnet und liegt irgendwo zwischen 2 und 3 Minuten. Das Zeitfenster ist dann für ca. 10 Sek. "offen". Dieses muß der TC mit seinem Sendeversuch treffen. Der RT synchronisiert sich dann daran wieder.
Sind die beiden Devices "außer Tritt", dann geht der RT öfter mal auf Empfang (dann wohl auch mit einem längeren Zeitfenster), um wieder eine Meldung des TC einzufangen und sich damit aufzusynchronisieren.
Wenn der Sender exakt zu Beginn des Zeitfensters sendet, kann es kritisch werden, falls die Quarze der beiden Devices nicht exakt stimmen. Ist dann der vom TC schneller, so sendet er, noch bevor der RT auf Empfang ist. Das ist mir z.B. bei einem virtuellen Sensor in fhem so passiert - der RT schaltete immer wieder auf seinen internen Messfühler.
Ich sende deshalb bei meinen Sensoren (Abwandlung von Dirks Universalsensor) 1 Sek. später und treffe damit das Fenster.
Martin
Zitat von: Linef am 24 Januar 2017, 22:20:53
Ich sende deshalb bei meinen Sensoren (Abwandlung von Dirks Universalsensor) 1 Sek. später und treffe damit das Fenster.
Wie kann man das einstellen?
Grüße
Zitat von: fhainz am 24 Januar 2017, 22:26:30
Wie kann man das einstellen?
Im Falle Device: Firmware umprogrammieren (nur bei Eigenbauten möglich, aber wahrscheinlich auch nur da nötig),
im Falle fhem (virt. Sensor): entsprechende Stelle (die den Abstand zum nächsten Zeitfenster berechnet) im Code suchen und 1000ms dazu addieren (oder wie auch immer das dort realisiert ist - ich habe noch nicht danach gesucht...)
Martin
Ah, das ist ein HM-Eigenbau Sensor, das hatte ich erst nicht überrissen.
Danke, dann werde ich mal danach suchen.
Ich such das gerade... würde das erstmal plump auf alle 5 Sekunden senden stellen, um erstmal zu beweisen, dass das das Problem ist.
Zitat von: vbs am 24 Januar 2017, 23:05:13
Ich such das gerade... würde das erstmal plump auf alle 5 Sekunden senden stellen, um erstmal zu beweisen, dass das das Problem ist.
Dann geht Dein HMLAN (ö.ä.) aber vermutlich in Overload und sendet ein Weilchen gar nix mehr...
Martin
Echt meinst du? Alle 5 Sekunden sind ja 720 Nachrichten pro Stunde. Gemäß 1%-Regel hat man 36 Sekunden Sendezeit. D.h. jede Nachricht darf 50 ms lang sein wenn ich mich nicht verrechnet habe. Klingt erstmal viel.
Zur Not kann ich den HMCFG auch kurz abstecken. Sollte zu Testzwecken ok sein.
Zitat von: vbs am 24 Januar 2017, 23:40:55
Echt meinst du? Alle 5 Sekunden sind ja 720 Nachrichten pro Stunde. Gemäß 1%-Regel hat man 36 Sekunden Sendezeit. D.h. jede Nachricht darf 50 ms lang sein wenn ich mich nicht verrechnet habe. Klingt erstmal viel.
Zur Not kann ich den HMCFG auch kurz abstecken. Sollte zu Testzwecken ok sein.
ok, sollte reichen. Ich glaube eine Nachricht dauert so um die 5ms (je nach Länge)
Martin
Zitat von: Linef am 24 Januar 2017, 22:51:31
Im Falle Device: Firmware umprogrammieren (nur bei Eigenbauten möglich, aber wahrscheinlich auch nur da nötig),
im Falle fhem (virt. Sensor): entsprechende Stelle (die den Abstand zum nächsten Zeitfenster berechnet) im Code suchen und 1000ms dazu addieren (oder wie auch immer das dort realisiert ist - ich habe noch nicht danach gesucht...)
Hat sich jemand damit mal beschäftigt, gibt es Neuigkeiten?
Moin zusammen,
ich hab das jetzt an verschiedenen Tagen in verschiedenen Räumen mal getestet, kurz nach dem Aufwachen und Senden vom RT hab ich am virtuellen Device die Temperatur von Hand verstellt (und damit meinen LaCrosse Sensor Wert überschrieben) und immer hat sich der RT Weather Kanal 2,5 Minuten später diesen Wert quasi abgeholt. Ist das nun Zufall, das es bei mir so gut funktioniert? Läuft das wirklich so ab, das beide Synchron laufen müssen? Sollte nicht das Virtuelle Device erkennen, dass sich der RT eben gemeldet hat und dann die neue Temperatur schicken während der RT noch lauscht? Oder ist dazu das Zeitfenster zu knapp bzw schläft das virtuelle Device`und ist dann nicht wach und ich bin total auf dem Holzweg?
Grüße
Achim
So wie ich es verstanden habe, kennen sich die beiden ausschließlich über den gemeinsamen Algorithmus zur Berechnung des nächsten Sendezeitpunkts. Der TC sendet einfach nur plump zyklisch die Temperatur ab. Irgendwann (durch Zufall) ist der RT gerade mal auf Empfang und sieht die Nachricht und kann dann berechnen, wann die nächste Nachricht gesendet werden wird und geht zu dem Zeitpunkt wieder auf Empfang usw.
Der Punkt ist, dass beide Seiten die Berechnung des nächsten Sendezeitpunkts identisch durchführen.
hmm ok der TC ist ja auch mit Batterie, da kann ich das nachvollziehen, das Virtuelle Device muss ja nicht schlafen, könnte also abwarten bis der RT sich meldet und dann die Temperatur durchgeben.
Naja evtl meldet sich ja mal jemand zu Wort der mehr Einblick/Hintergrundwissen in das entsprechende Modul hat ;-)
Könnte bitte mal jemand (oder gern mehrere), der ein TC gepeert mit RT hat, die Nachrichten, die dieser zyklisch schickt für so 5-6 Stunden loggen und mir schicken? Ich würde gerne mal die Zeitintervalle nachrechnen gegen die Implementierung in FHEM und in Asksin.
Sollte ungefähr so aussehen:
2017.01.26 22:12:52.919 0: HMLAN_Parse: HMLAN0 R:E306FC5 stat:0000 t:6359CC19 d:FF r:FFC4 m:27 8470 306FC5 000000 00AD25
Ihr müsstet nur gucken, welche HMID euer TC hat (in meinem Fall "306FC5") und dann sollten das immer die Nachrichten sein, die hinten die "8470" (nach dem "m:") haben. Außerdem bitte das Attribut mseclog bei global setzen, damit ms-genau geloggt wird.
@CBSnake
Guck dir mal die Funktion CUL_HM_valvePosUpdt in 10_CUL_HM an.
Zitat von: vbs am 28 Januar 2017, 13:24:40
Könnte bitte mal jemand (oder gern mehrere), der ein TC gepeert mit RT hat, die Nachrichten, die dieser zyklisch schickt für so 5-6 Stunden loggen und mir schicken?
Wie erstelle ich ein Log von dem Virtual Device?
Im Prinzip wie hier beschrieben:
https://wiki.fhem.de/wiki/Homematic_Nachrichten_sniffen
Hallo,
Die Berechnung des Zeitfensters wurde hier beschrieben:
https://forum.fhem.de/index.php/topic,17485.msg130378.html#msg130378 (https://forum.fhem.de/index.php/topic,17485.msg130378.html#msg130378)
oder in 10_CUL_HM.pm nachschauen.
Hab noch eine Kleinigkeit gefunden: Die originalen TCs senden immer 0x84 als Control-Byte, CUL_HM sendet aber 0x86. Unterschied ist das gesetzte WAKEMEUP-Flag. Keine Ahnung, ob das was mit unserem Problem zu tun haben könnte, aber ich denke schlechter machts das nicht. Vielleicht mag das mal jemand testen (im Anhang) und berichten ob es was ändert. Ich lass es hier bei mir auch gerade laufen...
Achso: FHEM muss neu gestartet werden nach dem Einspielen des Files. Nur ein reload auf das File reicht zumindest nicht.
Hier mal eine Variante, bei der man über ein Attribut selbst einen zeitlichen Offset für den Versand der Nachricht einstellen kann. Damit kann man also mal versuchen, zB. 1 Sekunde drauf zu addieren wie von Linef vorgeschlagen.
Das Attribut heißt "cyclicMsgOffset" und wird in ms direkt im Channel gesetzt. Also zB "1000" für eine Sekunde. Können auch negative Werte sein.
Vielleicht mag jemand auch mal damit rumspielen.
Sorry, da ist was schief gelaufen. Hier nochmal im Anhang...
Zitat von: Linef am 24 Januar 2017, 22:20:53
Beim RT wird der Abstand zum nächsten Zeitfenster aufgrund der Messagenummer und der Device-ID des TC berechnet und liegt irgendwo zwischen 2 und 3 Minuten. Das Zeitfenster ist dann für ca. 10 Sek. "offen". Dieses muß der TC mit seinem Sendeversuch treffen. Der RT synchronisiert sich dann daran wieder.
Ist das Zeitfenster wirklich ca. 10 Sek offen? Ich hab hier eine Seite gefunden, wo das Verhalten beschrieben wird (unter "Timing"):
https://homegear.eu/index.php/BidCoS_Packet_-_General_Information
Da ist von einem 250ms-Fenster die Rede, welches vergrößert wird, wenn Nachrichten verpasst werden. Muss natürlich auch nicht stimmen. Wäre aber super, wenn man an der Stelle an gesicherte Informationen kommen würde.
Zitat von: Linef am 24 Januar 2017, 22:20:53
Wenn der Sender exakt zu Beginn des Zeitfensters sendet, kann es kritisch werden, falls die Quarze der beiden Devices nicht exakt stimmen. Ist dann der vom TC schneller, so sendet er, noch bevor der RT auf Empfang ist. Das ist mir z.B. bei einem virtuellen Sensor in fhem so passiert - der RT schaltete immer wieder auf seinen internen Messfühler.
Ich sende deshalb bei meinen Sensoren (Abwandlung von Dirks Universalsensor) 1 Sek. später und treffe damit das Fenster.
Ich hätte erwartet, dass der RT den erwarteten Sendezeitpunkt in die Mitte seines Empfangsfenster legt, so dass zu beiden Seiten ein Puffer besteht. D.h. bei einem 10 Sek. Fenster hätte man zu beiden Seiten 5 Sek Toleranz. Ist das wirklich denkbar, dass die beiden Quarze so dermaßen unterschiedlichen laufen, dass sich da innerhalb von 2,5 Minuten ein Versatz von >5 Sek zwischen den beiden ergibt?
ZitatIch hab hier eine Seite gefunden, wo das Verhalten beschrieben wird (unter "Timing"):
das ist das erwähnte timing vom cc-vd.
funktioniert es denn nun bei dir?
Bei mir läuft es seit 14:00 Uhr, mit cyclicMsgOffset auf 1000, ohne Aussetzer. Solange hat das schon lange nicht mehr funktioniert ;D
Sieht gut aus! :)
Also vorweg: Ich denke es geht. Zumindest wesentlich stabiler als vorher.
Es ist nicht so ganz einfach herauszufinden, wie stabil der RT die Temperatur empfängt. Wenn man nur beobachtet, ob er auf die interne Temp zurückfällt oder nicht, dann sieht man nur ob er ungefähr 5 Nachrichten am Stück nicht empfangen. Wenn man nun einen Zustand hat, dass er zB nur jede 4. Nachricht sieht, dann wirkt es zwar stabil, da er nicht auf die interne Temp zurückfällt, jedoch erhöht er sehr oft sein Empfangsfenster, was permanent zu erhöhtem Batterieverbrauch führt.
Anderer Ansatz: Ich hab CUL_HM so umgebaut, dass er immer eine "gefakte" Temperatur zwischen 30°C und 40°C sendet, die er nach jeder Nachricht um 0.5°C erhöht. Sprich: Jede verschickte Nachricht enthält eine andere Temperatur. Anhand der zyklisch gemeldeten measure-temp des RT kann man dann recht genau sehen, welche Nachrichten er empfangen hat und welche nicht. Wenn er eine Nachricht nicht empfangen hat, dann meldet er die gleiche Temperatur wie im vorherigen Zyklus.
Gute Ergebnisse habe ich im Moment mit cyclicMsgOffset von 250 (geloggten measured-temp Werte vom RT):
"timestamp" "value"
"2017-01-29 22:25:32" "36.5"
"2017-01-29 22:23:27" "36.0"
"2017-01-29 22:21:08" "35.5"
"2017-01-29 22:18:35" "35.0"
"2017-01-29 22:15:47" "34.5"
"2017-01-29 22:12:45" "34.0"
"2017-01-29 22:10:32" "33.5"
"2017-01-29 22:08:05" "33.0"
"2017-01-29 22:05:23" "32.5"
"2017-01-29 22:02:27" "32.0"
"2017-01-29 22:00:21" "31.5"
"2017-01-29 21:58:00" "31.0"
"2017-01-29 21:55:25" "30.5"
Mit 1000 ms hatte ich schon ein paar doppelte. (*ich seh gerade mit 250 ms hab ich jetzt auch doppelte)
Ohne Offset hatte ich permanent mehrfache Temperaturen, oft 3-4 Zyklen die gleiche (-> sehr instabil).
Ungefähr so (also in der Zeit hat der RT offenbar keine Temp-Nachrichten gesehen):
"timestamp" "value"
"2017-01-29 22:53:51" "30.0"
"2017-01-29 22:51:13" "30.0"
"2017-01-29 22:48:20" "30.0"
"2017-01-29 22:46:18" "30.0"
Also offenbar hilft es deutlich, die Intervalle künstlich zu erhöhen. In meinem Fall scheint der ideale Wert irgendwo zwischen 250 und 1000 ms liegen. Also so weit so gut, ich denke man bekommt damit einen stabilen Betrieb hin mit nur vereinzelt verpassten Nachrichten.
Jetzt bitte die Preisfrage: Bitte erkläre mir jemand, warum das mit Offset funktioniert!! Nach allem was ich in den letzten Tagen gelesen und dachte verstanden zu haben, macht das für mich keinen Sinn. Der originale TC sendet genau in den Intervallen, die FHEM auch ausrechnet (habs nachgerechnet :)). Wenn man selbst in diesen Intervallen sendet, dann ist es jedoch instabil (!?!?!?).
Wenn der RT wirklich nur für 250 ms auf Empfang geht, dann müsste man doch mit einem Offset von 1000 ms das Fenster völlig verfehlen. Ich hätte es verstanden, wenn man mit kleinen Werte von max. +/- 50 ms Laufzeiten im OS o.ä. ausgleichen würde, aber nach meinem Verständnis müsste man doch mit einem Wert von 1000 ms sämtliche Timings völlig versauen und es dürfte gar nix mehr gehen (bis der RT nach einigen Nachrichten sein Fenster dermaßen vergrößert bis er wieder eine fängt) :(
Wäre klasse, wenn mich jemand erleuchten könnte, ich würde es wirklich gerne verstehen :(
(Im Anhang nochmal die CUL_HM-Variante die immer durchrotierende Temperaturen zwischen 30 und 40 °C sendet. Falls das jemand nachturnen möchte...)
Zitat von: vbs am 29 Januar 2017, 20:09:09
Ist das Zeitfenster wirklich ca. 10 Sek offen? Ich hab hier eine Seite gefunden, wo das Verhalten beschrieben wird (unter "Timing"):
https://homegear.eu/index.php/BidCoS_Packet_-_General_Information
Die Information ist sehr interessant - widerspricht aber den von mir gemachten Beobachtungen.
Ich hatte von meinem Temperatursensor aus mal versehentlich das ACK-Flag bei den Temperaturmeldungen versendet. Der RT-DN hat daraufhin den Empfang eines Pakets bestätigt. So konnte ich recht gut beobachten, wann er ein Paket bestätigt und wann nicht.
Zudem habe ich in FHEM alles ms-genau mitprotokollieren lassen, und dann mithilfe der "Formel" die Sendeabstände nachgerechnet.
So bin ich eben darauf gekommen, daß das Empfangsfenster die 10 Sekunden offen ist, und daß das neue Zeitfenster basierend auf dem letzten Empfangszeitpunkt berechnet wird.
Testweise hatte ich dann auch mal mehrere Messages pro Sekunde verschickt und dabei noch gesehen, daß der RT-DN auch zwischen diesen Zeitfenstern immer mal wieder kurz auf Empfang ist (eine Regel dahinter konnte ich aber nicht erkennen). Diese zusätzlichen Fenster hatte er auch, obwohl er "in sync" mit dem Temperatursensor war...
Also wer da nochmals testen will - einfach ACK vom RT-DN anfordern...
Ich betreibe mein Peering schon seit vielen Monaten mit einem Offset von 1000ms - ich kann ja mal noch mit weniger testen...
Ich denke, je kürzer der RT-DN auf das Datenpaket warten muß, desto batterisparender wird das Ganze...
Aber selbst mit 1000ms habe ich gelegentliche Aussetzer (alle paar Tage mal).
Bei den Tests mit den ACKs ist mir aufgefallen, daß der RT-DN immer mal wieder eine oder mehrere Übertragungen einfach nicht bestätigt hat - obwohl ich hundertprozentig IM Zeitfenster war. Entweder kam das Datenpaket bei ihm nicht richtig an, oder Firmwarebug. Zerstörte Datenpakete sind ja möglich (wenn zwei Homematic-Devices gleichzeitig senden), aber FHEM hat in diesem Falle die Pakete empfangen, der RT-DN jedoch nicht...
Zitat von: vbs
Ich hätte erwartet, dass der RT den erwarteten Sendezeitpunkt in die Mitte seines Empfangsfenster legt, so dass zu beiden Seiten ein Puffer besteht. D.h. bei einem 10 Sek. Fenster hätte man zu beiden Seiten 5 Sek Toleranz.
Nein - kannst ja mal mit negativem Offset probieren - bereits bei 100 oder 200ms kürzer als die Formel vorgibt, klappt praktisch kein Übertragungsversuch mehr...
Zitat von: vbs
Ist das wirklich denkbar, dass die beiden Quarze so dermaßen unterschiedlichen laufen, dass sich da innerhalb von 2,5 Minuten ein Versatz von >5 Sek zwischen den beiden ergibt?
Nein, ich formuliere das Problem mal anders:
Wenn der Sensor (Sender) ohne den Offset sendet, und beide Quarze exakt sind, dann sendet der Sensor genau dann, wenn der RT-DN das Fenster gerade geöffnet hat. Wenn jedoch der Quarz im Sensor nur ein klein bisschen schneller taktet, dann sendet der Sensor ein klein bisschen früher - vielleicht 100ms, und das ganze Telegramm ist damit futsch...
Martin
Zitat von: vbs am 28 Januar 2017, 22:30:53
Hab noch eine Kleinigkeit gefunden: Die originalen TCs senden immer 0x84 als Control-Byte, CUL_HM sendet aber 0x86. Unterschied ist das gesetzte WAKEMEUP-Flag.
0x84 ? Was will der TC mit dem Flag "DEVICE_IN_CONFIG_MODE"? Das verstehe ich nicht.
Ich sende bei mir mit 0x82, also nur das WKMEUP-Flag gesetzt.
Martin
Zitat von: Linef am 29 Januar 2017, 23:37:33
Also wer da nochmals testen will - einfach ACK vom RT-DN anfordern...
Das ist ein super Tipp danke!
Zitat von: Linef am 29 Januar 2017, 23:37:33
Ich betreibe mein Peering schon seit vielen Monaten mit einem Offset von 1000ms - ich kann ja mal noch mit weniger testen...
Ich hab im Moment 500 ms laufen und bisher jede Nachricht angekommen. Waren aber auch erst ~20. Also noch nix belastbares.
Zitat von: Linef am 29 Januar 2017, 23:37:33
Nein - kannst ja mal mit negativem Offset probieren - bereits bei 100 oder 200ms kürzer als die Formel vorgibt, klappt praktisch kein Übertragungsversuch mehr...
Das heißt der RT legt sein Empfangsfenster so, dass der erwartete Sendezeitpunkt am Anfang des Fenster liegt? Bei einem Fenster von 10 Sek müsste man dann theoretisch mit einem Offset von 5 Sek die besten Chancen haben? Evtl. erhöhter Batterieverbrauch weil der RT immer 5 Sek warten muss bis die Nachricht kommt...
Erklärt für mich aber irgendwo immer noch nicht so recht, warum der originale TC ohne Offset funktioniert und wir ca. 1 Sek (eine Ewigkeit!!) brauchen, damits stabil ist.
Zitat von: vbs am 29 Januar 2017, 23:51:27
Das heißt der RT legt sein Empfangsfenster so, dass der erwartete Sendezeitpunkt am Anfang des Fenster liegt? Bei einem Fenster von 10 Sek müsste man dann theoretisch mit einem Offset von 5 Sek die besten Chancen haben? Evtl. erhöhter Batterieverbrauch weil der RT immer 5 Sek warten muss bis die Nachricht kommt...
Genau.
Zitat von: vbs
Erklärt für mich aber irgendwo immer noch nicht so recht, warum der originale TC ohne Offset funktioniert und wir ca. 1 Sek (eine Ewigkeit!!) brauchen, damits stabil ist.
Das stimmt.
Wissen wir aber, ob bei einem TC der RT-DN alles sauber empfängt und NIE auf seinen internen Sensor umspringt?
Hat das ein TC-Besitzer schon mal verifiziert?
Martin
Zitat von: Linef am 29 Januar 2017, 23:48:59
0x84 ? Was will der TC mit dem Flag "DEVICE_IN_CONFIG_MODE"? Das verstehe ich nicht.
Ich sende bei mir mit 0x82, also nur das WKMEUP-Flag gesetzt.
Ist vielleicht zu früh am morgen, aber der TC sendet 0x84, CUL_HM sendet 0x86. Das 0x84 ist korrekterweise (denk ich) _ohne_ das Flag.
Zitat von: Linef am 29 Januar 2017, 23:37:33
Also wer da nochmals testen will - einfach ACK vom RT-DN anfordern...
Hm, also einfach nur das Flag setzen (BIDI-Flag, richtig?) klappt bei mir so erstmal nicht. Sieht dann so aus:
2017.01.30 08:26:13.591 0: HMLAN_Send: HMLAN0 S:+000000,00,00,00
2017.01.30 08:26:13.592 0: HMLAN_Send: HMLAN0 S:SEE4459B0 stat: 00 t:00000000 d:01 r:EE4459B0 m:06 A470 F16789 000000 0145
2017.01.30 08:26:14.295 0: HMLAN_Parse: HMLAN0 R:REE4459B0 stat:0008 t:00000000 d:FF r:7FFF m:06 A470 F16789 000000 0145
2017.01.30 08:26:14.295 0: HMLAN_Parse: HMLAN0 no ACK from 000000
Also gibt offenbar keine Antwort. Es ist ja weiterhin noch das Broadcast-Flag gesetzt und die Broadcast Adresse "0000000" als Empfänger eingetragen. Müsste man das Flag noch löschen und den RT konkret als Empfänger eintragen? Kann ich sonst einfach mal probieren, aber dann erst heute abend.
Nächste Erkenntnis: Mit einem Offset von 4000 kommen praktisch keine Nachrichten mehr an. Diese Beobachtung passt natürlich auch wieder nicht zu bisherigen Annahmen... :-\ Bei einem 10 Sek Fenster mit Sendezeitpunkt am Anfang sollte man eigentlich mitten drin liegen.
Zitat von: vbs am 30 Januar 2017, 08:29:26
Also gibt offenbar keine Antwort. Es ist ja weiterhin noch das Broadcast-Flag gesetzt und die Broadcast Adresse "0000000" als Empfänger eingetragen. Müsste man das Flag noch löschen und den RT konkret als Empfänger eintragen?
Die Messages bei wir waren auf jeden Fall an den Peer (RT-DN) gerichtet, also kein Broadcast.
Als Control-Byte hatte ich dann 0xA0 oder 0xA2 ("Broadcast"-Flag nicht gesetzt)
Apropos Broadcast-Flag: in NewAskSin ist das mit CFG (Device in Config Mode) betitelt und ist meines Wissens nach wirklich nur während eines Configs gesetzt. Dem widerspricht jetzt wieder daß der TC ständig mit gesetztem Bit sendet... Eine weitere Unklarheit...
Martin
Zitat von: Linef am 30 Januar 2017, 16:28:52
Apropos Broadcast-Flag: in NewAskSin ist das mit CFG (Device in Config Mode) betitelt und ist meines Wissens nach wirklich nur während eines Configs gesetzt. Dem widerspricht jetzt wieder daß der TC ständig mit gesetztem Bit sendet... Eine weitere Unklarheit...
Wir haben hier irgendwie ein Missverständnis: mMn sendet CUL_HM (nicht der TC!) mit einem Flag mehr:
CULHM: 0x86 -> 10000110
TC: 0x84 -> 10000100
Ich denke aber, dass wir dasselbe Bit meinen. Wird im Homegear Wiki beschrieben mit "1 WAKEMEUP Makes the central send configuration parameters after receiving the packet.". Aber TC sendet das nicht, sonder CULHM.
Zitat von: vbs am 30 Januar 2017, 16:48:42
Ich denke aber, dass wir dasselbe Bit meinen. Wird im Homegear Wiki beschrieben mit "1 WAKEMEUP Makes the central send configuration parameters after receiving the packet.". Aber TC sendet das nicht, sonder CULHM.
Nein, ich sprach von Bit 2 (hex:0x04): Das ist in NewAskSin mit CFG betitelt, während hier (und in dem Dokument weiter oben) von "Broadcast"-Flag gesprochen wird.
Dieses Bit ist bei mir eigentlich nur beim Pairing gesetzt.
Und dann gibt es Bit 1 (hex: 0x02), das ist das WKMEUP-Flag.
D.h. CULHM sendet bei Dir mit WKMEUP-Flag, der TC ohne Flag.
Da stellt sich die Frage, wann denn der TC mal MIT WKMEUP sendet - oder muß man bei jeder Änderung an den TC an selbigem den Konfig-Taster drücken?
So, und dann noch Bit 5 (hex: 0x20): das ist das BIDI-Flag. Das fordert ein ACK an.
D.h. mein Sensor müsste damals ein 0xA0 (nur ACK-Request) und/oder 0xA2 (ACK-Request + WKMEUP-Flag) gesendet haben (ist schon ein Jahr her, und Protokolle dazu habe ich auch nicht mehr).
WKMEUP an den RT-DN zu senden scheint zunächst mal keinen Sinn zu machen, aber die Zentrale bekommt das Paket auch und die reagiert dann, falls sie was an den Sensor zu senden hat.
Martin
Ich bin schlichtweg begeistert. ;D
Das festlegen der Offsetzeit auf 500ms hat bei mir alle Probleme mit den virtuellen Sensoren und meinen 8 HM-CC-RT-DN gelöst. In den letzten 12 Stunden konnte ich keine Temperatursprünge zwischen einem LaCrosse Sensor und der measured-temp mehr feststellen.
Danke dafür!
Hallo zusammen,
Ich hab auch mit Zwave einen virtuellen Temperatussensor unter HM realisiert, und dies Mit meinen HH_CC_RT_DN verbunden.
Ich habe mich schon gewundert, dass meine Regler ab und zu eine abweichende measured temp anzeigen, und nun hab ich gesehen ich bin nicht alein !!
Ich sprecht hier von einem "Offset cyclicMsgOffset" ich kann dieses Attribut weder beim HM-Regelr noch Weather Canel oder beim Virtuellen Tempsensor finden.
Wo sollte er sein !??? dammit ich dies auch mal testen kann !!!
Danke
Gruß Ralf !!
Ist momentan nur in der Version hier:
https://forum.fhem.de/index.php/topic,45735.msg572220.html#msg572220
ich kann ebenfalls fehlerfreiheit seit 24h vermelden mit einem Offset von 500ms.
@martin876
Liest du hier eigentlich mit?
Ich würde gerne den Patch im Anhang vorschlagen. Ändert einerseits das Control-Byte für die Wetter-Nachrichten von 0x86 auf 0x84 (wie beim echten TC). Andererseits führt es ein Attribut cyclicMsgOffset ein, das als Zeit in ms zum Sendezeitpunkt addiert wird.
Ich gehe davon aus, dass das ideale Offset von System zu System variieren könnte und denke daher, dass der User das selbst verändern können sollte.
Ich hab noch ziemlich viel getestet und tatsächlich hatte ich bisher mit kleinen Offsets zwischen 50 und 100 ms die besten Ergebnisse. Als default würde ich 50 ms vorschlagen (wie im Patch). Ich poste nochmal die kompletten Ergebnisse wenn ich damit durch bin.
EDIT:
Mit 50 ms kamen bei meinem Test mit über 400 Nachrichten ca. 99,5% an (2 nicht). Also ich denke, das liegt schon recht nah am Optimum.
Hab in den letzten Tage mal verschiedene Offset-Werte durchprobiert und dann ausgewertet, wie viele Nachrichten gesendet und wie viele davon verloren gegangen sind. Das sieht dann so aus:
https://docs.google.com/spreadsheets/d/1IG1Db8jTECoCP36WL4X-2M7ioUa9sCqwKa4fI1vzquU/edit?usp=sharing
Also mit Werten zwischen 50 und 100 ms hatte ich die besten Ergebnisse. Bei höheren Offsets nahm dann die Erfolgsquote nach und nach ab. Ich bin unsicher, ob die Daten 1:1 auf andere Installationen übertragbar sind. Wäre auf jeden Fall mal interessant zu sehen, wie sowas bei einer anderen Installation aussieht.
Es fehlt leider immer noch eine gute Erklärung zu dem beobachteten Verhalten. Ich denke mittlerweile nicht mehr, dass der RT für 10 Sekunden durchgängig auf Empfang ist. Ich könnte jetzt etwas spekulieren, aber das wird wohl nicht viel bringen :)
Ich habe bei mir mal testweise auf 50ms & 100ms gestellt. Das funktionierte bei meinem "Problem-Thermostat" im Badezimmer überhaupt nicht. Zur Zeit bin ich auf 250ms, das läuft zur Zeit stabil. Ich werde in den nächsten Tagen mal weiter testen.
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.
Wie testet ihr das ?
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
Hab Martin heute morgen schon geschrieben. Ich benutze einen HM-CFG-USB mit hmland.
Zitat von: andi11 am 01 Februar 2017, 15:30:58
ich kann ebenfalls fehlerfreiheit seit 24h vermelden mit einem Offset von 500ms.
Wie stellst Du fest, das es fehlerfrei läuft?
Zitat von: Fredi69 am 05 Februar 2017, 23:13:21
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.
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.
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 :)
hab nur einen im Einsatz. Default 200ms 1 sichtbarer Ausfall im Chart. 300ms bisher fehlerfrei
Einen RT im Einsatz, mit 250ms 48h fehlerfrei.
Top Job, vielen Dank für den Einsatz!!!
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.
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
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 8)
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
Musst du in dem virtueller Sensor setzen.
Wo? Jetzt bin völlig verwirrt. Ich habe das im .Clima Channel des RT gesetzt!
Zitat von: vbs am 19 Februar 2017, 12:15:51
Musst du in dem virtueller Sensor setzen.
Nach einem FHEM-Neustart habe ich das Attribut dort jetzt gefunden. Vielen Dank! :)
Ich melde mich, sobald ich sagen kann, ob 50ms zu Verbesserungen bei mir geführt haben.
Zitat von: Fredi69 am 19 Februar 2017, 12:31:48
Wo? Jetzt bin völlig verwirrt. Ich habe das im .Clima Channel des RT gesetzt!
Das ist eine Eigenschaft des Senders und muss daher (eigentlich) dort gesetzt werden. Sprich: Im virtuellen Device, welches als Temperaturgeber für den RT dient. Das im Clima-Channel des RT zu setzen kann mMn nicht funktionieren.
Aber es ist jetzt wie gesagt ein Default-Wert von 200 ms eingecheckt in der aktuellen Version. Also wenns gut läuft, dann muss man das Attribut nirgends händisch setzen.
Also ich habe es bei dem einen RT wo es mit dem Detail nicht lief im Weather Channel gesetzt. Der ist ja mit dem virtuellen Sensor gepeert.
Also ich kann nur sagen, klappt bisher bestens. Mehr als 1 Tag ist rum und bisher noch keine Spikes...das hatte ich noch nicht. Also Daumen hoch! :)
Zitat von: vbs am 19 Februar 2017, 12:51:55
...Sprich: Im virtuellen Device, welches als Temperaturgeber für den RT dient.
Wenn ich das im VirtualDevice setzen will kommt die Meldung:
cyclicMsgOffset only valid for channels
Also dann: genau das tun, was die Fehlermeldung sagt: Die Option kann nur in den Channeln des virtuellen Sensors gesetzt werden.
Genau. Sorry mein Fehler, hab mich ungenau ausgedrückt.
Jetzt habe ich es auch verstanden, sorry. Danke.
ZitatKönnte bitte mal jemand (oder gern mehrere), der ein TC gepeert mit RT hat, die Nachrichten, die dieser zyklisch schickt für so 5-6 Stunden loggen und mir schicken? Ich würde gerne mal die Zeitintervalle nachrechnen gegen die Implementierung in FHEM und in Asksin.
Sollte ungefähr so aussehen:
Code: [Auswählen]
2017.01.26 22:12:52.919 0: HMLAN_Parse: HMLAN0 R:E306FC5 stat:0000 t:6359CC19 d:FF r:FFC4 m:27 8470 306FC5 000000 00AD25
Hallo zusammen, ich weiß nicht wie aktuell die Anfrage hier ist, aber ich habe heute ane meinem System ca. 6 Std. mitgelogt. Vielleicht kann jemand mit etwas Exel-Magie eine oder das andere herausfinden. Ich sehe leider nichts, ob es hier irgendwo ein Muster gibt.
HMID 515162 ist ein HM-Wandthermostat, der mit einem HMID 493722 HM-Heizkörperthermostat gepeert ist.
HMID 061279 ist die Zentralle bzw. ein LaCrosse Sensor der mit HMID 493708 HM-Heizkörperthermostat gepeert ist.
Mein Problem sieht eigentlich wie folgt aus:
Solange ich nur ein Paar Lacrosse -> Thermostat im Betrieb habe, funktioniert es die meiste Zeit, auch ohne den Offset. Aber sobald ich ein zweites Paar in Betrieb nehme, dann gibt es sofort Aussetzer egal wie ich an dem Offset Attribut schraube.
Gruß
Zitat von: Hollo am 19 Februar 2016, 20:09:40
...
- bei meinem "schlechtesten" Thermostat die Batterie so ca. 4 Wochen hält
...
Mal ein kleiner Nachtrag:
Nach dem "Timing-Tuning" halten auch die Batterien meiner beiden "Problem"-Thermostate nun schon monatelang durch.
Es gibt also doch/auch eine direkte Abhängigkeit zwischen externem Temp-Sensor und Batterie-Lebensdauer.
Klar, weil im Schlechtfall der Sensor nach einiger Zeit in den "Dauerempfangs"-Modus geht, um dann das Synchronisationsfenster wieder zu treffen.
Das "sporadische Blinken" des Antennen-Symbols hatte ich ja bemerkt; dass der Unterschied der Batterie-Lebensdauer aber so gravierend ist/war, hatte ich nicht gedacht.
Jetzt läuft es ja seit Monaten sehr zufriedenstellend. Vielen Dank für die Arbeit.
Hallo zusammen. Ich möchte mich noch einmal an dieses Thema anhängen.
Bei mir hat seit gestern der Lacrosse-Gespeiste virt-Sensor im Wohnzimmer auch die Synchronisation verloren. Also auf die Suche gemacht, diesen Thread gefunden, gelesen und abgearbeitet.
Folgendes Tritt bie mir seit gestern Abend auf:
1- virtueller Sensor hat die korrekte Temperatur vom Lacrosse
2- virtueller Sensor Channel_01 steht dauerhaft im Modus set_virtTemp 17.9 (wobei die Temperatur immer der echten, gemessenen entspricht)
3- Das HM-CC-RT-DN hat dauerhaft das blinkende Antennensymbol
4- channel_01 Attribut cyclicMsgOffset auf verschiedene Werte gesetzt: 100,200,500. Keine Auswirkung. Wartezeit dazwischen immer ca. 20 Minuten.
5- Peering ist OK: x-ref list
HM_WZVirt => HM_WZ_Weather
HM_WZ_Weather => HM_WZVirt
Ich habe keine Ideen mehr wo ich hier angreifen soll. Letzte Instanz wäre ein komplettes Neuaufbauen des Reglers & des virtTemp. Habe ich im Spätherbst schon einmal gemacht, weil ich dachte, dass hier ein Problem liegt (War aber auch nur eine Abweichung der Temperatur, also das gleiche Problem wie jetzt).
Für Hilfe: Danke im Voraus!
wie sieht der funk aus, rssi?
hat das io gewechselt?
vielleicht helfen neue batterien.
Zitat von: SonOfAbaddon am 28 Februar 2018, 12:41:35
...Ich habe keine Ideen mehr wo ich hier angreifen soll...
Warten!
Klingt komisch, ist aber so.
Es kommt (aus welchen Gründen auch immer) schon mal vor, dass irgendwann mal das Timing der verschiedenen Dinge nicht mehr zueinander passt.
Hast Du z.B. ein FHEM-Update mit anschliessendem shutdown+restart gemacht?
In der Regel fängt sich das nach einiger Zeit von selbst wieder.
Wildes suchen und ändern ist da meist kontraproduktiv und verlängert nur die Zeitspanne.
Zitat von: frank am 28 Februar 2018, 12:51:41
wie sieht der funk aus, rssi?
hat das io gewechselt?
vielleicht helfen neue batterien.
RSSI müsste ich prüfen. Heute morgen hat er sich wieder gefangen.
Was ist mit io gemeint?
Kann man die Batterien einfach wechseln oder muss danach der RT wieder neu mit dem FHEM device oder dem HM USB gekoppelt werden?
Zitat von: Hollo am 28 Februar 2018, 12:57:57
Hast Du z.B. ein FHEM-Update mit anschliessendem shutdown+restart gemacht?
In der Regel fängt sich das nach einiger Zeit von selbst wieder.
Wildes suchen und ändern ist da meist kontraproduktiv und verlängert nur die Zeitspanne.
Ja, ich halte mein FHEM recht regelmäßig auf dem neuesten Stand. Ein Reboot war gestern auch mit auf dem Programm.
Heute morgen läuft das Thermostat tatsächlich wieder im Gleichschritt mit dem VT channel01. Ich werde heute mal überprüfen oder das set-temp command auch im Normalzustand im Channel steht.
Hallo
Ich möchte hier noch eine Variante dokumentieren.
Ich hatte ewige Zeiten das gleiche Problem, daß meine Thermostate die Temperatur von einem virtuellen Fühler immer wieder verloren haben. Gefühlt habe ich alle
Werte für cyclicMsgOffset von 0 bis 1000 ausprobiert-ohne dauerhaften Erfolg.
Durch den Zubau von einem HM-Funk-LAN Gateway (es ging immer wieder offline) habe ich festgestellt, daß ich in FHEM immer wieder längere timeout´s habe.
Ich bin dann mit perfmon, apptime und freezemon auf die Suche gegangen.
Der Schuldige war bei mir DbLog. Ich benutze das device mit einer SQLite Datenbank.
Nachdem ich einige Daten nicht mehr logge und mit
attr logdb asyncMode 1
den Schreibmodus umgestellt habe gibt es kaum noch timeout´s und meine Thermostate und mein HM-Funk-LAN Gateway funktionieren bestens. :D
Das Attribut cyclicMsgOffset habe ich gelöscht. Mit der Standardeinstellung läuft´s prima.
Ich meine auch irgendwo gelesen zu haben, daß das Timing etwas kritisch ist und die Probleme durch ein überlastetes FHEM entstehen können.
Grüße Martin