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

[noansi]

Hallo Martin,

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

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

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

[Fredi69]

Ist der Fehler in der Version

Code Auswählen Erweitern

10_CUL_HM.pm 23252 2020-11-28 19:48:27Z martinp876 behoben?

[Fredi69]

Ich habe das Problem aktuell wieder.

Code Auswählen Erweitern

set DG.Kz.vT.Temperatur_Sensor1 virtTemp 13.3 : Unknown argument virtTemp

[Fredi69]

Die Heizung ist aktuell verständlicherweise nicht unkritisch.
Hat jemand einen Tipp für mich?

[Beta-User]

Ja, ausnahmsweise mal aktuelle Threads mitlesen...

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!

[Fredi69]

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

[Fredi69]

Auch nach dem heutigen Update funktionieren unsere Thermostate leide immer noch nicht.

Code Auswählen Erweitern

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.

[Beta-User]

Die Attribut-Inhalte hast du repariert?!?
Hier läuft die Version aus dem heutigen update ohne Probleme.

[Fredi69]

Hilf mir bitte kurz, was konkret muss ich reparieren?
Bisher hat ein Update ausgereicht.

[Beta-User]

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

[Fredi69]

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.

[Fredi69]

Außerdem, habe ich jetzt wieder einen anderen Fehler im Log:

Code Auswählen Erweitern

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.

[frank]

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

[Fredi69]

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.

[frank]

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

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 hat dann eher mit einem instabilen system zu tun.
zb. freezes, und/oder cul ohne tsculfw.

schon mal mit attr cyclicMsgOffset gespielt?