Autor Thema: Virtuelle Temperatur-Sensoren - kein Sync mit HM_Weather seit (letztem) Update  (Gelesen 3378 mal)

Offline noansi

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1163
Hallo Martin,

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

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

Zitat
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.
« Letzte Änderung: 30 November 2020, 20:17:13 von noansi »

Offline Fredi69

  • Sr. Member
  • ****
  • Beiträge: 699
Ist der Fehler in der Version 10_CUL_HM.pm 23252 2020-11-28 19:48:27Z martinp876 behoben?
fhem auf Raspberry Pi 2
FRITZ!Box7490, Fritz!Box 3270 AP, HMLAN, CUL868 V3.4 mit 5dBi Antenne für FS20, nanoCUL 433 für IT, JeeLink für LaCrosse, HUE Bridge 2.0, Samsung UE46C8790 (STV), mehrere FS20, Homematic, Intertechno und LaCrosse Komponenten

Offline Fredi69

  • Sr. Member
  • ****
  • Beiträge: 699
Ich habe das Problem aktuell wieder.
set DG.Kz.vT.Temperatur_Sensor1 virtTemp 13.3 : Unknown argument virtTemp
« Letzte Änderung: 26 Dezember 2020, 20:01:23 von Fredi69 »
fhem auf Raspberry Pi 2
FRITZ!Box7490, Fritz!Box 3270 AP, HMLAN, CUL868 V3.4 mit 5dBi Antenne für FS20, nanoCUL 433 für IT, JeeLink für LaCrosse, HUE Bridge 2.0, Samsung UE46C8790 (STV), mehrere FS20, Homematic, Intertechno und LaCrosse Komponenten

Offline Fredi69

  • Sr. Member
  • ****
  • Beiträge: 699
Die Heizung ist aktuell verständlicherweise nicht unkritisch.
Hat jemand einen Tipp für mich?
fhem auf Raspberry Pi 2
FRITZ!Box7490, Fritz!Box 3270 AP, HMLAN, CUL868 V3.4 mit 5dBi Antenne für FS20, nanoCUL 433 für IT, JeeLink für LaCrosse, HUE Bridge 2.0, Samsung UE46C8790 (STV), mehrere FS20, Homematic, Intertechno und LaCrosse Komponenten

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 14346
  • "Developer"?!? Meistens doch eher "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!
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline Fredi69

  • Sr. Member
  • ****
  • Beiträge: 699
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
fhem auf Raspberry Pi 2
FRITZ!Box7490, Fritz!Box 3270 AP, HMLAN, CUL868 V3.4 mit 5dBi Antenne für FS20, nanoCUL 433 für IT, JeeLink für LaCrosse, HUE Bridge 2.0, Samsung UE46C8790 (STV), mehrere FS20, Homematic, Intertechno und LaCrosse Komponenten

Offline Fredi69

  • Sr. Member
  • ****
  • Beiträge: 699
Auch nach dem heutigen Update funktionieren unsere Thermostate leide immer noch nicht.
set DG.Kz.vT.Temperatur_Sensor1 virtTemp 11.9 : Unknown argument virtTempIch 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.
fhem auf Raspberry Pi 2
FRITZ!Box7490, Fritz!Box 3270 AP, HMLAN, CUL868 V3.4 mit 5dBi Antenne für FS20, nanoCUL 433 für IT, JeeLink für LaCrosse, HUE Bridge 2.0, Samsung UE46C8790 (STV), mehrere FS20, Homematic, Intertechno und LaCrosse Komponenten

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 14346
  • "Developer"?!? Meistens doch eher "User"
Die Attribut-Inhalte hast du repariert?!?
Hier läuft die Version aus dem heutigen update ohne Probleme.
« Letzte Änderung: 27 Dezember 2020, 11:42:51 von Beta-User »
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline Fredi69

  • Sr. Member
  • ****
  • Beiträge: 699
Hilf mir bitte kurz, was konkret muss ich reparieren?
Bisher hat ein Update ausgereicht.
fhem auf Raspberry Pi 2
FRITZ!Box7490, Fritz!Box 3270 AP, HMLAN, CUL868 V3.4 mit 5dBi Antenne für FS20, nanoCUL 433 für IT, JeeLink für LaCrosse, HUE Bridge 2.0, Samsung UE46C8790 (STV), mehrere FS20, Homematic, Intertechno und LaCrosse Komponenten

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 14346
  • "Developer"?!? Meistens doch eher "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).
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline Fredi69

  • Sr. Member
  • ****
  • Beiträge: 699
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.
fhem auf Raspberry Pi 2
FRITZ!Box7490, Fritz!Box 3270 AP, HMLAN, CUL868 V3.4 mit 5dBi Antenne für FS20, nanoCUL 433 für IT, JeeLink für LaCrosse, HUE Bridge 2.0, Samsung UE46C8790 (STV), mehrere FS20, Homematic, Intertechno und LaCrosse Komponenten

Offline Fredi69

  • Sr. Member
  • ****
  • Beiträge: 699
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.
fhem auf Raspberry Pi 2
FRITZ!Box7490, Fritz!Box 3270 AP, HMLAN, CUL868 V3.4 mit 5dBi Antenne für FS20, nanoCUL 433 für IT, JeeLink für LaCrosse, HUE Bridge 2.0, Samsung UE46C8790 (STV), mehrere FS20, Homematic, Intertechno und LaCrosse Komponenten

Offline frank

  • Hero Member
  • *****
  • Beiträge: 9809
Zitat
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.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [hm.js]: https://forum.fhem.de/index.php/topic,106959.0.html

Offline Fredi69

  • Sr. Member
  • ****
  • Beiträge: 699
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.
fhem auf Raspberry Pi 2
FRITZ!Box7490, Fritz!Box 3270 AP, HMLAN, CUL868 V3.4 mit 5dBi Antenne für FS20, nanoCUL 433 für IT, JeeLink für LaCrosse, HUE Bridge 2.0, Samsung UE46C8790 (STV), mehrere FS20, Homematic, Intertechno und LaCrosse Komponenten

Offline frank

  • Hero Member
  • *****
  • Beiträge: 9809
Zitat
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.


Zitat
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?
« Letzte Änderung: 27 Dezember 2020, 22:51:37 von frank »
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [hm.js]: https://forum.fhem.de/index.php/topic,106959.0.html

 

decade-submarginal