Hallo zusammen,
ich habe heute (gestern) festgestellt, dass meine virtuellen Temperatursensoren ihre Temperatur nicht mehr auf das gepeerte Weather-Device des entsprechenden HM-CC-RT-DN übertragen. Das set der entsprechenden Werte kommt am gepeerten Kanal an, wird jedoch nicht über das Haupt-Device an den Heizungsthermostat übertragen. Beim Prüfen der Readings ist mir aufgefallen, dass das "commState"-Reading des virtuellen Devices zuletzt am vergangenen Montag aktualisiert wurde. Seit dem Rückspielen der 10_CUL_HM.pm aus dem Backup vom Montag funktioniert der Sync zwischen gepeerten Kanal und dem Weather-Kanal des entsprechenden HM-CC-RT-DN wieder.
Noch jemand mit dieser Erfahrung?
Gruß Thorsten
Ich kann das Problem bestätigen.
Auch bei mir kommt im Weather nicht mehr die Temperatur vom virtuellen HM Device (Xiaomi Btle Sensor an).
Beste Grüße
Daniel
Habe mal eben noch ein peerXref gemacht. Die Kommunikation vom Virtuellen Device zum Aktor, also dem Weather device, scheint gestört zu sein. Tauchen bei mir unter undef auf.
Ebenso mein virtueller Teamleader für die Rauchmelder.
Hallo Daniel,
peerXref hatte ich nicht geprüft. Nach dem Rückspielen der 10_CUL_HM.pm haben sich die _WEATHER-Channel wieder mit den virtuellen Tmperatur-Sensoren synchronisiert, nachdem diese über meine DOIF das nächste mal gesetzt wurde. Sync-Zeiten waren dabei in den Grenzen, die ich auch sonst von unterbrochenen Syncs kenne, sprich: Nach einiger Zeit (xx Minuten) haben alle Werte wieder gepasst.
Anbei die bei mir funktionierende 10_CUL_HM.pm sowie ein diff zwischen funktionierender und nicht-funktionierender Version.
Gruß Thorsten
diff 10_CUL_HM.pm.working 10_CUL_HM.pm.broken
4c4
< # $Id: 10_CUL_HM.pm 23075 2020-11-02 18:13:51Z martinp876 $
---
> # $Id: 10_CUL_HM.pm 23117 2020-11-08 16:37:38Z martinp876 $
434,443c434,449
< my $d =ReadingsVal($name,"valvePosTC","");
< $d =~ s/ %//;
< CUL_HM_Set($hash,$name,"valvePos",$d);
< CUL_HM_Set($hash,$name,"virtTemp",ReadingsVal($name,"temperature",""));
< CUL_HM_Set($hash,$name,"virtHum" ,ReadingsVal($name,"humidity",""));
< CUL_HM_UpdtReadSingle($hash,"valveCtrl","restart",1) if (ReadingsVal($name,"valvePosTC",""));
< RemoveInternalTimer("valvePos:$vId");
< RemoveInternalTimer("valveTmr:$vId");
< InternalTimer($hash->{helper}{vd}{next}
< ,"CUL_HM_valvePosUpdt","valvePos:$vId",0);
---
> if ($hash->{helper}{fkt} eq "vdCtrl"){
> my $d = ReadingsVal($name,"valvePosTC","");
> $d =~ s/ %//;
> CUL_HM_Set($hash,$name,"valvePos",$d);
> CUL_HM_UpdtReadSingle($hash,"valveCtrl","restart",1) if ($d =~ m/^[-+]?[0-9]+\.?[0-9]*$/);
> RemoveInternalTimer("valvePos:$vId");
> RemoveInternalTimer("valveTmr:$vId");
> InternalTimer($hash->{helper}{vd}{next},"CUL_HM_valvePosUpdt","valvePos:$vId",0);
> }
> elsif($hash->{helper}{fkt} eq "virtThSens"){
> my $d = ReadingsVal($name,"temperature","");
> CUL_HM_Set($hash,$name,"virtTemp",$d) if($d =~ m/^[-+]?[0-9]+\.?[0-9]*$/);
> $d = ReadingsVal($name,"humidity","");
> CUL_HM_Set($hash,$name,"virtHum" ,$d) if($d =~ m/^[-+]?[0-9]+\.?[0-9]*$/);
> }
>
445,446c451
< delete $attr{$name}{$_}
< foreach ("autoReadReg","actCycle","actStatus","burstAccess","serialNr");
---
> delete $attr{$name}{$_} foreach ("autoReadReg","actCycle","actStatus","burstAccess","serialNr");
4602c4607
< $paraFail = "$parIn[$pCnt] not numeric";
---
> $paraFail = "\'$parIn[$pCnt]\' not numeric";
4605c4610
< $paraFail = "$parIn[$pCnt] out of range min:$min max:$max";
---
> $paraFail = "\'$parIn[$pCnt]\' out of range min:$min max:$max";
Hallo Martin,
Ursache, wie hier https://forum.fhem.de/index.php/topic,115367.msg1099513.html#msg1099513 (https://forum.fhem.de/index.php/topic,115367.msg1099513.html#msg1099513) schon beschrieben.
Gruß, Ansgar.
Habe das gleiche Problem, die hier angehangene Version funktioniert allerdings auch nicht.
Hat jemand eine funktionierende 10_CUL_HM.pm?
Danke
Ich habe jetzt folgende 10_CUL_HM eingespielt: 10_CUL_HM.pm 22973 2020-10-15 13:32:29Z martinp876 $
Leider funktioniert auch die nicht.
1. Kann mir jemand eine definitiv funktionierende nennen oder zur Verfügung stellen.
2. Warum gibt es eigentlich so viele Probleme in letzter Zeit mit der CUL_HM?
Vielen Dank
Fredi
Die letzte funktioniert grundsätzlich, WENN man die patcht wie von noansi vorgeschlagen (=eine einzige Zeile verschieben).
Ansonsten wäre es zielführend, nicht rumzuschimpfen, martinp876 hat an dem Modul ziemlich rumgeschraubt, und wir als user dürfen davon ausgehen, dass das nicht grundlos war.
Ergo: bekannte Verbesserungen ggf. selbst einbauen, testen und Rückmeldung geben, dann hat der MAINTAINER eine Chance, das gleich "sauber" zu korrigieren ;) .
Zitat von: Beta-User am 27 November 2020, 12:17:25
Die letzte funktioniert grundsätzlich, WENN man die patcht wie von noansi vorgeschlagen (=eine einzige Zeile verschieben).
Ansonsten wäre es zielführend, nicht rumzuschimpfen, martinp876 hat an dem Modul ziemlich rumgeschraubt, und wir als user dürfen davon ausgehen, dass das nicht grundlos war.
Vielen Dank für die Info.
Nicht mal im Ansatz habe ich geschimpft, ich bewundere die Arbeit von martinp876 und allen anderen hier.
Ich habe lediglich nach dem Hintergrund gefragt.
Ich frage mich, ob es etwas mit der Frequenz zu tun haben kann.
könnte ich um etwas info bitten
1) mit get hm showTimer kann man die laufenden Timer sehen. hier sollte je Virtuellen ThermoSensor einer laufen.
CUL_HM_valvePosUpdt valvePos:10000005
<100000> ist die ID des wirtuellen Devices und <05> der Kanal
=> laufen die Timer?
2) wann geht es nicht?
a) nach Reboot?
b) nach Setzen von set vb05 vrtTemp 22
c) nie?
3) bitte ein List des virtuellen Thermo-sensor
@martinp876:
Im Moment kann ich das nicht mehr nachstellen, weil ich die Änderung wie von noansi hier vorgeschlagen vorgenommen hatte, der aber bereits festgestellt hatte, dass die Timer nicht anlaufen:
Zitat von: noansi am 08 November 2020, 20:27:01
Hallo Martin,
mit der Änderung laufen die Timer für meine virtuellen Temperatursensoren nicht mehr an.
Ich denke, das liegt an Zeile 426:
$hash->{helper}{virtTC} = "00";
Das verhindert, dass mit CUL_HM_Set($hash,$name,"virtTemp",$d) oder Setzen durch notifies in Zeile 6168
CUL_HM_valvePosUpdt("valvePos:$dst$chn");
aufgerufen wird, womit der Timer anlaufen soll.
{virtTC} dient als Flag in Zeile 6156, um mehrfachen Timerstart zu verhindern.
D.h. Zeile 426 müßte auch noch in den vdCtrl Block ab Zeile 434 umziehen, wenn ich das richtig sehe.
Gruß, Ansgar.
In dem anderen Thread hatte ich auch bestätigt, dass die Thermostate dann auch wieder die virtuelle Temperatur erhalten, wenn man die Zeile verschiebt wie von Ansgar vorgeschlagen.
Sorry, es gibt noch zwei oder drei weitere Threads, in denen es auch immer um dieses Thema geht, das ist leider dadurch nicht übersichtlich zu erkennen, wer wann was warum geschrieben hatte...
Zitat von: Beta-User am 27 November 2020, 16:13:01
@martinp876:
Im Moment kann ich das nicht mehr nachstellen, weil ich die Änderung wie von noansi hier vorgeschlagen vorgenommen hatte, der aber bereits festgestellt hatte, dass die Timer nicht anlaufen: In dem anderen Thread hatte ich auch bestätigt, dass die Thermostate dann auch wieder die virtuelle Temperatur erhalten, wenn man die Zeile verschiebt wie von Ansgar vorgeschlagen.
Sorry, es gibt noch zwei oder drei weitere Threads, in denen es auch immer um dieses Thema geht, das ist leider dadurch nicht übersichtlich zu erkennen, wer wann was warum geschrieben hatte...
Habe ich auch so gemacht, ich habe den Code angepasst und jetzt scheint es wieder zu laufen.
Ist die Änderung im nächsten Update enthalten?
Hallo Martin,
Zitat=> laufen die Timer?
nein, nicht für die virtuellen Temp/Hum Sensoren.
Zitat2) wann geht es nicht?
a) nach Reboot?
b) nach Setzen von set vb05 vrtTemp 22
c) nie?
nie (sofern man FHEM nach Austausch der 10_CUL_HM.pm einmal neu gestartet hat und damit die Timer natürlich weg sind), da die letzte Änderung dazu in CUL_HM_updateConfig das leider unterbindet.
Hier mein erster Post dazu https://forum.fhem.de/index.php/topic,115367.msg1099513.html#msg1099513 (https://forum.fhem.de/index.php/topic,115367.msg1099513.html#msg1099513) mit Erklärung zur Ursache im Code, wie von Jörg schon zitiert.
Zitat3) bitte ein List des virtuellen Thermo-sensor
Kann ich nicht mehr mit dienen. Aber sicherlich jemand hier, der das Problem noch hat.
Gruß, Ansgar.
Hallo Ansgar,
an dieser Stelle wurde eigentlich nichts geändert. Wenn es nicht klappt hat es evtl etwas mit den Kommando-parametern zu tun.
Bei mi rläuft der Timer - also "nie" stimmt nicht! Ich habe einen aufgesetzt und gerage einen reboot gemacht.
Ich würde es gerne selbst prüfen und brauche dazu die geforderten Infos
Gruß Martin
Hallo Martin,
Zitatan dieser Stelle wurde eigentlich nichts geändert.
im älteren Stand wurde in CUL_HM_updateConfig der CUL_HM_valvePosUpdt Timer sowohl für vdCtrl, als auch für virtThSens gestartet.
Im letzten Stand nur noch für virtThSens.
Das macht einen Unterschied für das "Überleben" von $hash->{helper}{virtTC}, da der Timer es mit delete wieder löscht, wenn nichts zu tun ist.
Es ist nicht offensichtlich und ich hab auch etwas gebraucht, um das Problem im Code zu identifizieren.
ZitatWenn es nicht klappt hat es evtl etwas mit den Kommando-parametern zu tun.
Den Gedanken hatte ich auch zuerst, aber nachdem ich auch händisch eine Temperatur via set virtTemp vorgegeben hatte ohne eine Fehlermeldung zu bekommen, aber auch ohne Sendeerfolg, und auch möglichen Fehlern auf dem Kommando-Wege nachgegangen war, konnte ich das ausschließen.
ZitatBei mi rläuft der Timer - also "nie" stimmt nicht! Ich habe einen aufgesetzt und gerage einen reboot gemacht
Dann verstehe ich nicht, warum es hier https://forum.fhem.de/index.php/topic,115367.msg1103933.html#msg1103933 (https://forum.fhem.de/index.php/topic,115367.msg1103933.html#msg1103933) bei Jörg nach vorgeschlagener Änderung wieder funktioniert und vorher nach Stand aus dem Update nicht.
Es macht auf jeden Fall einen Unterschied, ob ein vdCtrl genutzt wird (bei dem läuft der Timer nach letztem Stand noch) oder ob ein virtThSens genutzt wird, der eben nicht mehr läuft.
Erklärbar wäre ein laufender virtThSens eventuell noch, wenn es Dir vor dem Durchlauf von CUL_HM_updateConfig gelungen ist, ein set virtTemp an den virtThSens abzusetzen. Das wäre eine Ausnahme von nie.
Vielleicht mag ja doch noch ein betroffener User, der noch nicht wieder auf einen älteren Stand zurück gegangen ist, das gewünschte List mit dem Stand aus dem Update liefern. Ich möchte nicht mit meinem Stand für TSCUL zusätzlich Verwirrung stiften.
Gruß, Ansgar.
Edit: Ich habe gerade gesehen, dass Du Zeile 426 gelöscht (virtThSens sollten damit wieder laufen) aber nicht nach if ($hash->{helper}{fkt} eq "vdCtrl"){ umgezogen hast. Eventuell erzeugt das mal ein Problem mit zwei laufenden Timern für einen vdCtrl. Das hängt davon ab, ob der erste set für den vdCtrl vor der ersten Ausführung von CUL_HM_valvePosUpdt ausgeführt wird oder werden kann.
Ist der Fehler in der Version 10_CUL_HM.pm 23252 2020-11-28 19:48:27Z martinp876 behoben?
Ich habe das Problem aktuell wieder.
set DG.Kz.vT.Temperatur_Sensor1 virtTemp 13.3 : Unknown argument virtTemp
Die Heizung ist aktuell verständlicherweise nicht unkritisch.
Hat jemand einen Tipp für mich?
Ja, ausnahmsweise mal aktuelle Threads mitlesen...
https://forum.fhem.de/index.php/topic,116838.0.html
(https://forum.fhem.de/index.php/topic,116838.0.html)(im svn scheint es ein update zu geben, ich habe aber nicht verifiziert, ob martinp876 genau diesen Fix eingecheckt hat). Du musst aber auf alle Fälle die config checken, weil evtl. Attributinhalte verloren gegangen sind!
Ehrlich gesagt verstehe ich im Moment nicht:
1. Wann ist das Problem entstanden, die 10_CUL_HM.pm ist bei mir vom 2020-11-28 19:48:27
2. was muss ich prüfen?
3. Wie wird das Problem behoben?
Danke
Auch nach dem heutigen Update funktionieren unsere Thermostate leide immer noch nicht.
set DG.Kz.vT.Temperatur_Sensor1 virtTemp 11.9 : Unknown argument virtTemp
Ich befürchte, ich muss die Heizkörperregelung aus fhem rausnehmen.
Leider gibt es, warum auch immer, seit einigen Monaten immer wieder Probleme mit den virtuellen Homematic Devices.
Kann mir jemand vielleicht sagen mit welcher CUL_HM Version es noch funktionieren sollte?
Ich würde dann CUL_HM vom Update ausschließen.
Die Attribut-Inhalte hast du repariert?!?
Hier läuft die Version aus dem heutigen update ohne Probleme.
Hilf mir bitte kurz, was konkret muss ich reparieren?
Bisher hat ein Update ausgereicht.
Die "peerIDs" der virtuellen Kanäle stehen vermutlich nicht mehr auf den zugehörigen Kanälen der RT's, sondern stehen auf dem Wert, der im Titel des verlinkten Threads genannt ist.
Die Peer-Nummern müssen da wieder rein (neu peeren muss man nicht).
Danke, die PeerIDs der virtuellen Temperatur Sensoren waren leer.
Die habe ich jetzt wieder gefüllt.
Bei 3 von 4 Thermostaten funktioniert es wieder, mal sehen wann der vierte läuft.
Ich verstehe nur die Ursache der Probleme nicht, es lief ja wochenlang, ohne das sich die CUL_HM Version geändert hat.
Außerdem, habe ich jetzt wieder einen anderen Fehler im Log:
2020.12.27 13:54:04 1: PERL WARNING: Use of uninitialized value $mI[5] in hex at ./FHEM/10_CUL_HM.pm line 1916.
ZitatIch verstehe nur die Ursache der Probleme nicht, es lief ja wochenlang, ohne das sich die CUL_HM Version geändert hat.
der auslöser war ein fhem restart.
Zitat von: frank am 27 Dezember 2020, 14:59:36
der auslöser war ein fhem restart.
Das würde ja bedeuten, das Problem kann nach einem restart wieder auftreten.
Es läuft halt aktuell in keinster Weise stabil.
Die RT's springen immer mal wieder auf die interne Temperatur um, das Thermostat macht zu, dann kommt wieder die korrekte Temperatur, das Thermostat macht wieder auf.
So geht das jetzt leider munter hin und her.
ZitatDas würde ja bedeuten, das Problem kann nach einem restart wieder auftreten.
nee, weil es deswegen ja extra ein update gab.
das war doch deutlich im verlinkten thread zu lesen, inklusive ursache!
demnach handelst du scheinbar nach dem motto: nichts lesen, nur rumnölen.
ZitatEs läuft halt aktuell in keinster Weise stabil.
Die RT's springen immer mal wieder auf die interne Temperatur um, das Thermostat macht zu, dann kommt wieder die korrekte Temperatur, das Thermostat macht wieder auf.
So geht das jetzt leider munter hin und her.
das hat dann eher mit einem instabilen system zu tun.
zb. freezes, und/oder cul ohne tsculfw.
schon mal mit attr cyclicMsgOffset gespielt?
Zitat von: frank am 27 Dezember 2020, 22:27:50
das hat dann eher mit einem instabilen system zu tun.
zb. freezes, und/oder cul ohne tsculfw.
schon mal mit attr cyclicMsgOffset gespielt?
Das lief aber Jahrelang stabil, jetzt gibt es seit einigen Monaten immer wieder Probleme.
Mit dem Attribut cyclicMsgOffset hatte ich schon ,,gespielt"
Zitat von: Fredi69 am 27 Dezember 2020, 20:58:19
Es läuft halt aktuell in keinster Weise stabil.
Die RT's springen immer mal wieder auf die interne Temperatur um, das Thermostat macht zu, dann kommt wieder die korrekte Temperatur, das Thermostat macht wieder auf.
So geht das jetzt leider munter hin und her.
Das kann ich nur bestätigen - ich habe bei mir deswegen alle vier HM-Thermostate resettet und neu gepeert. Im Ergebnis bekommen idR nur drei von vier RTs die externen Temperaturwerte - es ist immer ein anderer, der den internernen Temperaturwert zieht.
Zitat von: frank am 27 Dezember 2020, 22:27:50das hat dann eher mit einem instabilen system zu tun.
zb. freezes, und/oder cul ohne tsculfw.
Das sehe ich nicht so - es lief bis Ende Oktober ohne große Probleme (auch ohne tsculfw).
Den Wechsel auf die tsculfw würde ich ja mal gerne testen - leider habe ich nur einen "Monster"-Thread zur Entstehung und einen fast genauso großen zu den aktuellen Versionen gefunden. Für ein HowTo wäre ich äußerst dankbar!
Resetten und neu Pairen (!?) sind eigentlich nie eine gute Idee... Vermutlich ist da was schief gegangen.
Dass der Attributinhalt weg war, ist ärgerlich, aber "nur" eine Änderung in CUL_HM liegt vermutlich nicht vor. Ich würde wetten, dass du nur eben entweder seit Oktober am System rumgeschraubt hast oder davor nicht sensibilisiert warst, falls es Ausfälle gab.
So wie ich das in dem Monsterthread gelesen hatte, ist es zwischenzeitlich so, dass man den CUL umflasht und dann mit Hilfe des Moduls TSCUL als IO einbindet. Das muss man vorher halt ins Modulverzeichnis mit passenden Rechten verfrachten und dann optimalerweise auch in eine VCCU einbinden, das war es aber auch schon ;) .
Die Langform steht afaik im ersten Beitrag von einem der beiden Monster-Threads...
Es ist aber immer noch klug, ein natives IO zu besorgen :P .
Zitat von: Beta-User am 30 Dezember 2020, 17:50:36
Es ist aber immer noch klug, ein natives IO zu besorgen :P .
Ach neee, lieber nicht ;)
War nicht Ende Oktober, war Ende November (als es mir aufgefallen ist) und mit meiner Sicherung der cul_hm vom 02.11. war alles wieder schick ...
Ich schau mir mal die nächsten Tage tsculfw an!
Danke!
@Taslow
lass mal apptime eine stunde laufen und dann zeig mal die ausgabe von "apptime max".
@frank: Ausgabe von "apptime max" nach ± 75 Minuten
active-timers: 30; max-active timers: 34; max-timer-load: 3 min-tmrHandlingTm: 0.0ms; max-tmrHandlingTm: 1176.2ms; totAvgDly: 1.8ms
name function max count total average maxDly avgDly TS Max call param Max call
tmr-CUL_HM_cfgStateUpdate cfgStateUpdate 125 2 156.81 78.40 2.71 1.61 30.12. 22:48:08 cfgStateUpdate:Essen_Heizung
mohnCUL CUL_Read 118 165 5985.00 36.27 0.00 0.00 30.12. 22:49:59 HASH(mohnCUL)
tmr-CUL_HM_valvePosUpdt valvePos 17 116 1239.39 10.68 9.00 1.22 30.12. 23:38:02 valvePos:22ABCD01
tmr-at_Exec HASH(0x30feb70) 17 73 698.77 9.57 0.76 0.52 30.12. 23:37:15 HASH(at_wz_vT)
tmr-FW_closeInactiveClients 0 16 73 104.32 1.43 76.48 5.68 30.12. 23:56:14 0
myJeeLink JeeLink_Read 16 2627 10412.76 3.96 0.00 0.00 30.12. 23:32:28 HASH(myJeeLink)
tmr-at_Exec HASH(0x3073e40) 16 73 683.55 9.36 0.89 0.62 30.12. 23:11:15 HASH(at_ez_vT)
tmr-at_Exec HASH(0x30f2270) 15 73 694.12 9.51 2.57 1.94 30.12. 23:37:15 HASH(at_buero_vT)
FileLog_SensorImFreien FileLog_Log 13 276 210.91 0.76 0.00 0.00 30.12. 23:32:28 HASH(FileLog_SensorImFreien); HASH(SensorImFreien)
tmr-at_Exec HASH(0x32c1490) 12 15 139.91 9.33 0.85 0.50 30.12. 23:27:15 HASH(at_bad_vT)
ez_vT_Sensor1 CUL_HM_Set 8 73 365.50 5.01 0.00 0.00 30.12. 23:55:15 HASH(ez_vT_Sensor1); ez_vT_Sensor1; virtTemp; 21.5
wz_vT_Sensor1 CUL_HM_Set 8 73 372.22 5.10 0.00 0.00 30.12. 22:56:15 HASH(wz_vT_Sensor1); wz_vT_Sensor1; virtTemp; 21.2
buero_vT_Sensor1 CUL_HM_Set 8 73 368.52 5.05 0.00 0.00 30.12. 23:37:15 HASH(buero_vT_Sensor1); buero_vT_Sensor1; virtTemp; 20.1
FileLog_SensorBad FileLog_Log 7 232 152.18 0.66 0.00 0.00 30.12. 23:09:41 HASH(FileLog_SensorBad); HASH(SensorBad)
FileLog_SensorEssen FileLog_Log 7 265 205.30 0.77 0.00 0.00 30.12. 23:46:41 HASH(FileLog_SensorEssen); HASH(SensorEssen)
FileLog_SensorInfrarotKabine FileLog_Log 6 247 193.06 0.78 0.00 0.00 30.12. 23:32:38 HASH(FileLog_SensorInfrarotKabine); HASH(SensorInfrarotKabine)
bad_vT_Sensor1 CUL_HM_Set 6 15 75.03 5.00 0.00 0.00 30.12. 23:47:15 HASH(bad_vT_Sensor1); bad_vT_Sensor1; virtTemp; 21
FileLog_SensorEisfach FileLog_Log 6 293 233.53 0.80 0.00 0.00 30.12. 22:58:34 HASH(FileLog_SensorEisfach); HASH(SensorEisfach)
FileLog_SensorBuero FileLog_Log 6 285 200.64 0.70 0.00 0.00 30.12. 23:38:36 HASH(FileLog_SensorBuero); HASH(SensorBuero)
FileLog_SensorSchlafzimmer FileLog_Log 6 251 187.39 0.75 0.00 0.00 30.12. 23:09:29 HASH(FileLog_SensorSchlafzimmer); HASH(SensorSchlafzimmer)
FileLog_SensorWohnzimmer FileLog_Log 6 355 238.35 0.67 0.00 0.00 30.12. 23:26:45 HASH(FileLog_SensorWohnzimmer); HASH(SensorWohnzimmer)
Zentrale HUEBridge_Read 5 420 392.56 0.93 0.00 0.00 30.12. 23:45:00 HASH(Zentrale)
FileLog_Wohnzimmer_Heizung FileLog_Log 4 27 20.87 0.77 0.00 0.00 30.12. 23:29:40 HASH(FileLog_Wohnzimmer_Heizung); HASH(Wohnzimmer_Heizung)
allowed_WEB allowed_Authenticate 4 8 20.52 2.56 0.00 0.00 30.12. 23:55:02 HASH(allowed_WEB); HASH(WEB_xxx.xxx.xxx.xxx_62548); HASH(0xb6fbf0)
tmr-CUL_HM_respPendTout respPend 4 2 8.60 4.30 2.04 1.60 30.12. 22:50:06 respPend:5A8FB4
FileLog_Buero_Heizung FileLog_Log 4 28 26.81 0.96 0.00 0.00 30.12. 23:26:33 HASH(FileLog_Buero_Heizung); HASH(Buero_Heizung)
FileLog_SchalteinheitKeller FileLog_Log 3 3789 1311.15 0.35 0.00 0.00 30.12. 23:11:15 HASH(FileLog_SchalteinheitKeller); HASH(at_ez_vT)
tmr-HUEBridge_GetUpdate HASH(0x30a68f0) 3 73 171.17 2.34 2.01 1.38 30.12. 23:36:16 HASH(Zentrale)
Logfile FileLog_Log 3 3789 983.19 0.26 0.00 0.00 30.12. 23:39:25 HASH(Logfile); HASH(SensorWohnzimmer)
tmr-at_Exec HASH(0x33e0528) 3 1 3.25 3.25 1.90 1.90 30.12. 23:45:00 HASH(at_Lampe_WZ_Fenster_Aus)
tmr-at_Exec HASH(0x33e5630) 2 1 2.95 2.95 8.40 8.40 30.12. 23:45:00 HASH(at_Lampe_EZ_Fenster_Aus)
tmr-at_Exec HASH(0x33e1ff0) 2 1 2.95 2.95 5.30 5.30 30.12. 23:45:00 HASH(at_Lampe_WZ_Fernseher_Aus)
ALL.Batterie readingsGroup_Notify 2 3789 674.68 0.18 0.00 0.00 30.12. 23:10:15 HASH(ALL.Batterie); HASH(at_wz_vT)
FileLog_Essen_Heizung FileLog_Log 2 64 47.23 0.74 0.00 0.00 30.12. 23:04:31 HASH(FileLog_Essen_Heizung); HASH(Essen_Heizung)
eventTypes eventTypes_Notify 1 3789 1121.42 0.30 0.00 0.00 30.12. 23:33:24 HASH(eventTypes); HASH(Bad_Heizung_Clima)
tmr-CUL_HM_complConfigTO CUL_HM_complConfigTO 1 1 1.87 1.87 2.24 2.24 30.12. 23:02:15 CUL_HM_complConfigTO
Lampe_WZ_Fenster HUEDevice_Set 1 1 1.72 1.72 0.00 0.00 30.12. 23:45:00 HASH(Lampe_WZ_Fenster); Lampe_WZ_Fenster; off
Lampe_EZ_Fenster HUEDevice_Set 1 1 1.57 1.57 0.00 0.00 30.12. 23:45:00 HASH(Lampe_EZ_Fenster); Lampe_EZ_Fenster; off
Lampe_WZ_Fernseher HUEDevice_Set 1 1 1.56 1.56 0.00 0.00 30.12. 23:45:00 HASH(Lampe_WZ_Fernseher); Lampe_WZ_Fernseher; off
FileLog_Bad_Heizung FileLog_Log 1 27 22.75 0.84 0.00 0.00 30.12. 23:58:56 HASH(FileLog_Bad_Heizung); HASH(Bad_Heizung)
WEB FW_Read 1 8 7.15 0.89 0.00 0.00 30.12. 23:59:45 HASH(WEB)
das sieht ja eigentlich sehr gut aus.
gab es in der zeit einen rückfall auf die ht temperatur?
falls nicht, wäre eine apptime ausgabe sinnvoll, während das problem auftaucht.
zum löschen der apptime daten "apptime clear" nutzen.
du nutzt ja einen jeelink, der scheinbar viel zu empfangen hat. wahrscheinlich die externen tempsensoren.
sind jeelink und cul beide über usb am pi angebunden?
könnte der jeelink dadurch eventuell den cul "ausbremsen"?
Bei mir läuft es nach wie vor auch sehr instabil.
Hat jemand einen Tipp?
Ich habe leider auch immer noch das Problem das die virtuellen Temperatur Sensoren sich nicht synchronisieren.
Zitat von: Joker2002 am 02 Januar 2021, 06:36:23
Ich habe leider auch immer noch das Problem das die virtuellen Temperatur Sensoren sich nicht synchronisieren.
Infos?!?
- was steht in den Attributen?
- welche IOs?
Zur Info: soweit erkennbar läuft hier alles fein rund... (Haupt-IO ist ein via USB angebundenes Pi-PCB).
Zitat von: frank am 01 Januar 2021, 18:43:36
das sieht ja eigentlich sehr gut aus.
gab es in der zeit einen rückfall auf die ht temperatur?
falls nicht, wäre eine apptime ausgabe sinnvoll, während das problem auftaucht.
Ich habe ständig und ohne Muste einen Rückfall auf eine der RT-Temperaturen. Aktuell ist es bei einem von vier: Wohnzimmer.
Apptime-Ausgabe nach ±5 Minuten
active-timers: 33; max-active timers: 33; max-timer-load: 1 min-tmrHandlingTm: 0.0ms; max-tmrHandlingTm: 120.6ms; totAvgDly: 2.3ms
name function max count total average maxDly avgDly TS Max call param Max call
WEB_xxx.xxx.xxx.xxx_55098 FW_Read 244 4 262.20 65.55 0.00 0.00 02.01. 08:19:01 HASH(WEB_xxx.xxx.xxx.xxx_55098)
tmr-at_Exec HASH(0x29ff5a8) 120 4 148.73 37.18 0.67 0.55 02.01. 08:18:15 HASH(at_wz_vT)
wz_vT_Sensor1 CUL_HM_Set 112 10 277.85 27.79 0.00 0.00 02.01. 08:18:15 HASH(wz_vT_Sensor1); wz_vT_Sensor1; virtTemp; 21
mohnCUL CUL_Read 38 8 135.50 16.94 0.00 0.00 02.01. 08:18:29 HASH(mohnCUL)
tmr-at_Exec HASH(0x29cb370) 17 4 51.83 12.96 7.06 4.66 02.01. 08:18:15 HASH(at_buero_vT)
myJeeLink JeeLink_Read 13 157 650.00 4.14 0.00 0.00 02.01. 08:15:56 HASH(myJeeLink)
tmr-CUL_HM_valvePosUpdt valvePos 12 4 48.96 12.24 2.16 1.05 02.01. 08:16:27 valvePos:44ABCD01
tmr-at_Exec HASH(0x2a36980) 12 4 37.55 9.39 10.13 3.00 02.01. 08:17:15 HASH(at_ez_vT)
tmr-FW_closeInactiveClients 0 11 5 15.92 3.18 1.17 0.81 02.01. 08:16:09 0
buero_vT_Sensor1 CUL_HM_Set 10 4 28.25 7.06 0.00 0.00 02.01. 08:18:15 HASH(buero_vT_Sensor1); buero_vT_Sensor1; virtTemp; 20.8
FileLog_SensorInfrarotKabine FileLog_Log 10 20 27.23 1.36 0.00 0.00 02.01. 08:15:56 HASH(FileLog_SensorInfrarotKabine); HASH(SensorInfrarotKabine)
ez_vT_Sensor1 CUL_HM_Set 6 4 19.84 4.96 0.00 0.00 02.01. 08:17:15 HASH(ez_vT_Sensor1); ez_vT_Sensor1; virtTemp; 20.8
tmr-at_Exec HASH(0x2a0bae0) 6 1 6.33 6.33 0.55 0.55 02.01. 08:15:15 HASH(at_bad_vT)
FileLog_SensorBuero FileLog_Log 5 12 13.49 1.12 0.00 0.00 02.01. 08:19:01 HASH(FileLog_SensorBuero); HASH(SensorBuero)
allowed_WEB allowed_Authenticate 5 13 35.72 2.75 0.00 0.00 02.01. 08:17:24 HASH(allowed_WEB); HASH(WEB_xxx.xxx.xxx.xxx_54919); HASH(0x13b2c50)
FileLog_SensorSchlafzimmer FileLog_Log 4 17 14.50 0.85 0.00 0.00 02.01. 08:18:51 HASH(FileLog_SensorSchlafzimmer); HASH(SensorSchlafzimmer)
Wohnzimmer_Heizung_Clima CUL_HM_Set 4 5 11.85 2.37 0.00 0.00 02.01. 08:18:29 HASH(Wohnzimmer_Heizung_Clima); Wohnzimmer_Heizung_Clima; ?
bad_vT_Sensor1 CUL_HM_Set 3 1 3.40 3.40 0.00 0.00 02.01. 08:15:15 HASH(bad_vT_Sensor1); bad_vT_Sensor1; virtTemp; 21.9
tmr-HUEBridge_GetUpdate HASH(0x19fbe78) 2 4 9.05 2.26 11.64 4.28 02.01. 08:18:26 HASH(Zentrale)
WEB_xxx.xxx.xxx.xxx_55098 FW_Notify 1 10 1.75 0.17 0.00 0.00 02.01. 08:19:09 HASH(WEB_xxx.xxx.xxx.xxx_55098); HASH(SensorWohnzimmer)
Lampe_WZ_Fenster HUEDevice_Set 1 4 3.59 0.90 0.00 0.00 02.01. 08:17:24 HASH(Lampe_WZ_Fenster); Lampe_WZ_Fenster; ?
WEB FW_Read 1 13 14.13 1.09 0.00 0.00 02.01. 08:18:19 HASH(WEB)
Wohnzimmer_Heizung CUL_HM_Set 1 5 4.11 0.82 0.00 0.00 02.01. 08:18:29 HASH(Wohnzimmer_Heizung); Wohnzimmer_Heizung; ?
Wohnzimmer_Heizung_Weather CUL_HM_Set 1 5 3.91 0.78 0.00 0.00 02.01. 08:18:29 HASH(Wohnzimmer_Heizung_Weather); Wohnzimmer_Heizung_Weather; ?
SD_WZ_Sub_und_Bar HUEDevice_Set 1 4 3.03 0.76 0.00 0.00 02.01. 08:17:24 HASH(SD_WZ_Sub_und_Bar); SD_WZ_Sub_und_Bar; ?
VCCU CUL_HM_Set 1 4 4.82 1.20 0.00 0.00 02.01. 08:17:24 HASH(VCCU); VCCU; ?
Zentrale HUEBridge_Read 1 27 25.95 0.96 0.00 0.00 02.01. 08:19:06 HASH(Zentrale)
SD_WZ_Rear HUEDevice_Set 1 4 2.90 0.72 0.00 0.00 02.01. 08:17:24 HASH(SD_WZ_Rear); SD_WZ_Rear; ?
FileLog_SensorEisfach FileLog_Log 1 15 10.03 0.67 0.00 0.00 02.01. 08:16:53 HASH(FileLog_SensorEisfach); HASH(SensorEisfach)
FileLog_Buero_Heizung FileLog_Log 1 2 1.71 0.86 0.00 0.00 02.01. 08:15:40 HASH(FileLog_Buero_Heizung); HASH(Buero_Heizung)
eventTypes eventTypes_Notify 1 214 67.66 0.32 0.00 0.00 02.01. 08:15:40 HASH(eventTypes); HASH(Buero_Heizung_Clima)
FileLog_Wohnzimmer_Heizung FileLog_Log 1 2 1.92 0.96 0.00 0.00 02.01. 08:18:29 HASH(FileLog_Wohnzimmer_Heizung); HASH(Wohnzimmer_Heizung)
FensterkontaktHaustuere CUL_HM_Set 1 4 3.48 0.87 0.00 0.00 02.01. 08:17:24 HASH(FensterkontaktHaustuere); FensterkontaktHaustuere; ?
FileLog_SensorWohnzimmer FileLog_Log 0 15 10.22 0.68 0.00 0.00 02.01. 08:18:43 HASH(FileLog_SensorWohnzimmer); HASH(SensorWohnzimmer)
FileLog_Bad_Heizung FileLog_Log 0 2 1.54 0.77 0.00 0.00 02.01. 08:16:15 HASH(FileLog_Bad_Heizung); HASH(Bad_Heizung)
wz_vT CUL_HM_Set 0 4 3.41 0.85 0.00 0.00 02.01. 08:17:24 HASH(wz_vT); wz_vT; ?
FileLog_SensorImFreien FileLog_Log 0 20 12.23 0.61 0.00 0.00 02.01. 08:18:54 HASH(FileLog_SensorImFreien); HASH(SensorImFreien)
FileLog_SensorBad FileLog_Log 0 15 8.75 0.58 0.00 0.00 02.01. 08:19:07 HASH(FileLog_SensorBad); HASH(SensorBad)
FileLog_SensorEssen FileLog_Log 0 10 6.75 0.68 0.00 0.00 02.01. 08:17:56 HASH(FileLog_SensorEssen); HASH(SensorEssen)
Wohnzimmer_Heizung_WindowRec CUL_HM_Set 0 4 2.98 0.75 0.00 0.00 02.01. 08:17:24 HASH(Wohnzimmer_Heizung_WindowRec); Wohnzimmer_Heizung_WindowRec; ?
FileLog_SchalteinheitKeller FileLog_Log 0 214 76.26 0.36 0.00 0.00 02.01. 08:18:43 HASH(FileLog_SchalteinheitKeller); HASH(SensorWohnzimmer)Zitat von: frank am 01 Januar 2021, 18:43:36
du nutzt ja einen jeelink, der scheinbar viel zu empfangen hat. wahrscheinlich die externen tempsensoren.
sind jeelink und cul beide über usb am pi angebunden?
könnte der jeelink dadurch eventuell den cul "ausbremsen"?
Ja beide sind per USB am PI dran.
Ich muss meine Aussage revidieren. Bei mir lag es daran, dass ich ein Fehler in den Peers hatte und das deshalb die Temperatur nicht korrekt weitergegeben wurde. Jetzt läuft es bei mir :)
Zitat von: Taslow am 02 Januar 2021, 08:30:03
Ich habe ständig und ohne Muste einen Rückfall auf eine der RT-Temperaturen. Aktuell ist es bei einem von vier: Wohnzimmer.
Apptime-Ausgabe nach ±5 Minuten
hier ist kein problem zu sehen.
ich meinte, dass im apptime aufzeichnungs zeitraum die ursache für den rückfall auf interne temp vorhanden sein muss.
wenn man am rt den rückfall erkennt, dann war der erste auslöser eventuell schon 10-15min vor dem umswitchen.
der rt switcht erst, wenn mehrere messages in folge nicht empfangen werden können.
Zitat von: Beta-User am 30 Dezember 2020, 17:50:36
Resetten und neu Pairen (!?) sind eigentlich nie eine gute Idee...
Bei mir hat es geholfen. Die Probleme mit den HM-Thermostaten gehören seither der Vergangenheit an.Neben zahlreichen anderen Problemen durch das große Modul-Update hatte ich das Problem, dass ein HM-Thermostat (von insgesamt 6) seine CMDs nicht mehr richtig abgearbeitet hat. Insbesondere liess sich auch die measured_temp im Weather-Kanal durch virt-Sensor nicht mehr setzen. Also das hier im Thread geschilderte Problem.
Auch das manuelle Eintragen in der peerList half nicht weiter.
set hm peerXref zeigte dann zwar brav die korrekten Peerings in beide Richtungen an, der Weather-Kanal des
HM-CC-RT-DN weigerte sich aber weiterhin, das CMD
set_virtTemp des channel_01 meines "VIRTUAL" - HM-Geräts anzunehmen.
Ich hatte die Sache eigentlich aufgegeben. Nun hatte ich am Wochenende nochmal einen letzten Anlauf unternommen und meinen FHEM-Container auf die neueste Version des HM-Moduls geupdated. Dennoch nahm dieser eine HM-CC-RT-DN weiterhin das set_virtTemp CMD nicht an.
Schliesslich brachte mir genau das "Resetten und neu Pairen" des HM-CC-RT-DN die Lösung, und zwar der unten beschriebene "doppelte Reset":
Zitat
https://de.elv.com/forum/neue-firmware-1.5-an-fhem-uart-modul-hm-mod-rpi-pcb-mit-firmware-1.4.1-7481
Ich hatte erst das gleiche Problem. Dann habe ich jedoch eine Vorgehensweise gefunden, die mich insg. 18 Thermostate an FHEM anlernen gelassen hat.
1. Pairing wie angegeben 2. Get Config erst nachdem die Zeit von hmPairVorSecnds abgelaufen ist. 3. burstXmit 4. set <gerät> reset 5. set <gerät> unpair Jetzt blos nichts löschen!!! 6. harten HW Reset nach Handbuch am Gerät 7. erneut pairen et voilat Dieses Vorgehen hat bei mir immer funktioniert.
PS: Auf meinem HM-CC-RT-DN hatte ich zwar die Firmware nie von 1.4.1 auf 1.5 geändert, dennoch läuft es bei mir seit dem o.g. reset und neu pairen.
völliger quatsch.
wozu 1. bis 5. wenn du danach (schon wieder) einen reset machst?
a. wenn ein reset wirklicht hilft, dann diesen einmal direkt am device ausführen.
b. anschliessend natürlich auch wieder pairen.
c. und danach natürlich auch wieder peeren.
also ist deine liste auch schon wieder murks, da du c. nicht erwähnst.
Hallo "Hero"-Member frank :)
"Quatsch?" "Murks?" Weil ich eine Lösung zitiere, die funktioniert? Gerade als "Hero"-Member sollte man Vorbild in Netiquette sein, denke ich.
Weder ist das "meine Liste", noch ist mein Beitrag "Quatsch?" oder "murks".
Seit ich dem (von mir nur zitierten) Rat aus dem elv-Forum gefolgt bin, in der beschriebenen Weise zu resetten, arbeitet der HM-CC-RT-DN (bei mir und anderen Betroffenen, siehe elv-Forum) wieder korrekt mit dem FHEM-Modul zusammen.
Ich lade Dich gerne in mein Haus ein und zeige es Dir ;D
Und meine Kinder haben wieder ein warmes Zimmer :-)
Da kann ich (und vermutlich auch die meisten anderen Leser) auf "Quatsch?"- "Murks?"- Kommentare gerne verzichten :-)
(PS: und selbstverständlich muss das neu gepairte device anschliessend auch entsprechend gepeert werden, was denn sonst?)
Liebe Grüße
raspiano