Virtuelle Temperatur-Sensoren - kein Sync mit HM_Weather seit (letztem) Update

thorte · 11 November 2020, 20:49:21

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

nanocosmos · 12 November 2020, 21:30:45

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

nanocosmos · 12 November 2020, 21:35:04

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.

thorte · 13 November 2020, 18:19:41

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

Code Auswählen


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";

noansi · 13 November 2020, 20:30:01

Hallo Martin,

Ursache, wie hier https://forum.fhem.de/index.php/topic,115367.msg1099513.html#msg1099513 schon beschrieben.

Gruß, Ansgar.

Fredi69 · 27 November 2020, 11:41:33

Habe das gleiche Problem, die hier angehangene Version funktioniert allerdings auch nicht.
Hat jemand eine funktionierende 10_CUL_HM.pm?

Danke

Fredi69 · 27 November 2020, 12:13:06

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

Beta-User · 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.
Ergo: bekannte Verbesserungen ggf. selbst einbauen, testen und Rückmeldung geben, dann hat der MAINTAINER eine Chance, das gleich "sauber" zu korrigieren

.

Fredi69 · 27 November 2020, 12:27:58

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.

katsmart · 27 November 2020, 13:18:43

Ich frage mich, ob es etwas mit der Frequenz zu tun haben kann.

martinp876 · 27 November 2020, 15:32:10

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

Beta-User · 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:

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:
Code Auswählen Erweitern
$hash->{helper}{virtTC} = "00";

Das verhindert, dass mit CUL_HM_Set($hash,$name,"virtTemp",$d) oder Setzen durch notifies in Zeile 6168
Code Auswählen Erweitern
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...

Fredi69 · 27 November 2020, 18:21:21

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?

noansi · 27 November 2020, 19:30:22

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 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.

martinp876 · 28 November 2020, 19:49:46

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