HM-CC-RT-DN Funk-Heizkörperthermostat - Virtuelle Peers

[Beta-User]

Hallo zusammen,

im Zusammenhang mit diversen Themen, die mit Heizungssteuerung zu tun haben (u.a. auch Grundlagen_der_Heizungssteuerung und WeekdayTimer mit weekprofile steuern) bin ich dabei, manches "bewährte" in der eigenen Installation zu checken und evtl. auf unsere sich ändernden Bedarfe (und den zwischenzeitlichen eigenen Kenntnisstand) anzupassen. Ein Teil dabei war/ist die Verwendung von virtuellen Sensoren für die Steuerung von (WT und) HM-CC-RT-DN wie unter Simulation von Fensterkontakten und externen Temperatursensoren beschrieben.

Dabei sind mir jetzt einige Lücken und Unklarheiten aufgefallen, die ich gerne bei der Gelegenheit "wegpflegen" würde, manches des Nachfolgenden ist teilgetestetes Halbwissen aus diversen Threads zu dem Thema in der Vergangenheit, die es aber teils aus eigener Erfahrung erst mal nicht ins Wiki geschafft hatten . Um Bestätigung/Aufklärung wird daher gebeten...
(In order of apperance)
1. In der Einleitung erstellt man ein virtuelles Device , dann heißt es "erstelle dazu einen virtuellen Kanal".
Unklar bleibt, ob ein Device mit zwei (bzw. drei, s.u. zum Thema WT) Kanälen pro "Raum" (im Sinne einer gemeinsam zu steuernden Gruppe) genügt.
Nach meinen bisherigen Erfahrungen geht das ohne weiteres, man braucht nur eben je ein virtuelles Device pro Gruppe von RT's bzw. WT's (=> bitte um Hinweise, wenn das falsch sein sollte). Ich finde es daher in der Gesamtdarstellung (ggf. auch zum Verlinken aus allg. "Virtueller Kanal"-Einträgen) "runder", das als einen logischen Gesamtablauf darzustellen, bei dem ein (virtuelles) Device als "Partnerdevice" für alle "Klima-Fragen" seine Kanaldevices bereitstellt... (Rückmeldungen, ausdrücklich auch Meinungen dazu, erbeten!)
autoReadReg funktioniert bei "VIRTUAL" nicht mehr, expert wäre heute auch ein anderes Level (benötigt?)... Langer Rede kurzer Sinn: Habe mal nur das reingenommen, was man zwangsläufig braucht, bitte melden, wenn es ggf. der alten Fassung (in neuem Gewand) zu wenig ist...

2. Die Erstellung der Kanal-Devices erfolgte bisher "händisch". Jetzt wird nur noch "set ... virtual x" dargestellt, und auch hier habe ich die weiteren bisher genannten Attribute (dummy 1, expert...) mal rausgelassen, das schien mir veraltet (der Forumsbeitrag, auf den sich die alte Fassung bezieht, stammt von Ende 2014, da gab es wesentliche Änderungen an dem Modul (VIRTUAL)) und nur webCmd angepaßt.
Evtl. wäre es nützlich, noch "Aufhübschungsattribute" zu nennen? (=>Meinungen?)

Code Auswählen Erweitern

attr FK devStateIcon set_offen:fts_window_1w_open@red:geschlossen set_geschlossen:fts_window_1w@green:offen
attr FK eventMap /postEvent open:offen/postEvent closed:geschlossen/
attr FK icon fts_window_1w_open
attr FK webCmd offen:geschlossen

Bei den virtuellen FK's ist (zumindest mir) auch einiges unklar, aber dazu schreibe ich später noch was... Insbesondere ist mir unklar, warum das mit einem at gemacht wird, und warum man das Reading nicht irgendwann löscht, wenn der Wert des echten Temperaturfühlers nicht mehr aktualisiert wird...

[Beta-User]

Bei den virtuellen FK's ist (zumindest mir) auch einiges unklar, aber dazu schreibe ich später noch was... Insbesondere ist mir unklar, warum das mit einem at gemacht wird, und warum man das Reading nicht irgendwann löscht, wenn der Wert des echten Temperaturfühlers nicht mehr aktualisiert wird...

Also anknüpfend:
3. at statt notify?
a) Im Wiki steht noch, man solle den aktuellen Wert alle 2 Min aus dem Reading des echten Thermostaten holen und in den virtuellen schreiben.
Leuchtet mir nicht ein: Es wird nirgends geprüft, ob der Wert auch aktuell ist, es wird dann immer weiter derselbe völlig veraltete Wert weitergeschrieben?
Habe das daher auch mit einem notify gelöst.

b) Jetzt habe ich aber zwei gedankliche Hänger dazu, teilweise ausgehend von meinem setup, das zwei recht unterschiedliche Sensortypen angeht. Beide sind von Xiaomi, aber das eine ist ein Aqara (ZigBee als HUEDevice@deCONZ), das andere ein Mija (?), so ein rundes Bluetooth-Ding mit Display (eingebunden über OpenMQTTGateway). Der Aqara sendet nur ca. alle Stunde was, es sei denn, es gäbe signifikante Änderungen, der Mija ist ziemlich gesprächig, aktuell gebändigt mit event-on-change-reading (0.2 Hysterese) und einem min-interval von 300).
Das läuft jetzt noch nicht lange so, aber die Messdaten (von dem Mija nur ca. 1/2 Tag vor dem Peeren, läuft jetzt seit gestern früher Nachmittag) bestätigt eigentlich, dass eQ-3 mit der 1.5-er firmware einen ganz ordentlichen Job gemacht hat: Ungepeert war der interne Meßwert zu hoch, aber das Ergebnis innerhalb einer kleinen Toleranz.
Nach den jeweiligen Peerings (den Aqara habe ich erst später gepeert) sind die Daten fast synchron, gelegentlich laufen die "gemessenen" Werte am RT dem externen Temp-Fühler kurz nach - je nachdem, wann der RT die Daten eben abholt...
Obwohl die Daten vom Aqara recht konstant waren, ist der RT nie auf den internen zurück, jedenfalls, soweit ich das aus den Plots sehen kann.

c) Bringt mich (noch ungetestet und ohne größere Recherche hier im Forum zur Frage, ob man den Wert aus dem virtuellen Device löschen muss, wenn er (zu) veraltet ist? Sonst wird er "forever" verwendet (beim aqara kann das eine Stunde sein, jedenfalls war das in etwa ein mehrfacher Stichprobenwert auch @zigbee2mqtt). Ergo muß man zwischen (noch) "akzeptabel veraltet" (Aqara) oder "inakzeptabel veraltet" unterscheiden und (ggf.) aktiv werden, oder übersehe ich was? (Insbesondere: eine Stunde reicht nicht, um den RT wieder seiner eigenen Sensorik zu überlassen?)

4. (teilweise OT, zu verwerten dann im WT-Artikel):
Da wir grade bei virtuellen Peers sind und HM da einen guten Job macht:
Ich habe auch einen Bodenkonvektor (einen im Fußboden sitzenden Heizkörper mit Luft drumrum). Der wird von einem WT (https://wiki.fhem.de/wiki/HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP) geschalten (mit kleiner Hysterese, also immer zuerst), das ist toll (wir hatten es neulich ja von dem unschönen Effekt, den fallende kalte Luft an Wänden oder anderen kalten Außenflächen (Fensterfront....) hat).
Im Moment ist das ein einkanaliger CUL_HM, aber falls mal Ersatz zu suchen sein müßte, würde ich vermutlich was anderes (ZWave) nehmen. Der trigger aus dem WT müßte nur die andere Richtung via FHEM nehme... Hat diese Art (virtuelle) Peering schon mal jemand in diese Richtung ausgenutzt? Sollte doch gehen, oder?

Rückmeldungen wären hilfreich, sonst muß ich im HM-Bereich nochmal posten oder selber testen, aber das ist mühsam und fehleranfällig...

Danke vorab,

Beta-User

[LuckyDay]

 

Code Auswählen Erweitern

gelegentlich laufen die "gemessenen" Werte am RT dem externen Temp-Fühler kurz nach - je nachdem, wann der RT die Daten eben abholt...
dein Virtueller Wandthermostat, sendet ca alle 2,5 Min, nach dem komischen HM Logaritmus eine Broadcastmeldung in den Raum mit akt Temperatur die du per at oder notify in den virtuellen Peer setzen tust. UND der Zeitschlitz vom wachen RT muss getroffen werden von CUL-HM. Hier holt niemand etwas "ab". Wenn der Zeitschlitz verfehlt wird, verzeiht dir das der RT ein/zweimal ansonsten schaltet er seinen internen Tempfühler wieder an. und regelt nach dem wieder.

zu 4.

peere deinen WT mit einem virtuellen Device und du hast einen virtuellen Switch , danach wertest du das aus und sendest on oder off an dein Zwave Switch.
Ps. Ein WT kann mehrere Peers am tr.

[Beta-User]

Thx, so um die 10 Minuten hatte ich auch im Hinterkopf, bis der "interne" wieder greift.

Das mit dem periodischen Broadcast (und dem burst beim virtuellen Fensterkontakt) werde ich als technische Hintergrundinfo noch mit verarbeiten.

Kurz zusammengefaßt ist zu 3. also zu sagen, dass das "at" zwar seine Wirkung tut, aber definitiv nicht "best practice" darstellt. Wie beim FK sollte man da
a) ein notify oä. nehmen, dann wird der Wert direkt bei jeder Aktualisierung auch im Kanal abgelegt unt tut dort ab/mit dem nächsten broadcast seine Wirkung UND
b) dafür sorgen, dass der Wert rausfliegt, wenn er nicht mehr aktuell ist.
Zu b) werde ich mir dann mal testweise ein "one-for-all"-at basteln, dass alle 15 Min. alle virtuellen Temperaturwerte löscht, die älter als eine Stunde sind...
Oder hat jemand da bessere Ideen, um das zu lösen (readingsWatcher werde ich erwähnen, habe das aber nicht im Einsatz und will sowieso auch eine einfach zu kopierende Alternative anbieten)?
Die andere Variante wäre, mit einem zyklischen at die Werte zu übertragen bzw. den Wert zu löschen, wenn das Ausgangsreading zu alt ist; aber da hat man tendenziell einen (m.E. unnötigen) weiteren Zeitversatz zwischen der wirklichen Aktualisierung und der Auswirkung auf den RT.

ad 4.: Also haben wir dazu dieselbe Theorie (die praktisch erprobt werden will), oder nutzt du das irgendwie schon heute praktisch?


Dann ist mir noch ein 5. begegnet, nämlich wie sich das verhält, wenn eine CCU ins Spiel kommt, also HMCCU&Co verwendet wird.
Hier mal eine kurze Linkliste (ich werde die bestenfalls mit einpflegen mit dem Hinweis, dass "sowas" sich zumindest teilweise auch auf diesem Weg umsetzen läßt; vielleicht findet sich jemand, der das dann - wo auch immer - in weitere praxistaugliche Lösungen überführt, die technischen Probleme sind ja im wesentlichen dieselben...):

* RaspberryMatic (HMCCU) und LaCrosse Temperature als "Wandthermostat"
* HMCCU mit Thermostat HM-CC-RT-DN und ZWave Türsensor
* Heizungssteuerung mit CCU3 und HM-TC-IT-WM-W-EU,HM-SEC-SCo und HM-LC-SW4-DR

[etwas OT]
Habe eben mal ein paar von den BT-Dingern bestellt, das mit dem Display gefällt mir besser als die ZigBee-Geräte, die ich sonst in Betracht gezogen hätte; zwei Varianten...
https://www.ebay.de/itm/XIAOMI-Mijia-Bluetooth-Thermometer-Electronic-Temperatur-Monitor-Feuchtesensor/283716992847?hash=item420ed9bf4f:g:0VEAAOSwk8Jd~Jh1 bzw. https://www.ebay.de/itm/Xiaomi-Mijia-BT-Temperatur-Feuchtigkeitssensor-Digital-Hygrometer-Thermometer/114030099568?_trkparms=aid%3D555018%26algo%3DPL.SIM%26ao%3D1%26asc%3D57925%26meid%3Dccdbe73f205a478e968c94c031ef08d7%26pid%3D100005%26rk%3D2%26rkt%3D12%26mehot%3Dco%26sd%3D383205118301%26itm%3D114030099568%26pmt%3D1%26noa%3D0%26pg%3D2047675&_trksid=p2047675.c100005.m1851 (das Modell habe ich schon, leider zu spät gemerkt, dass der Doppelpack für 17,- Euro zu haben war).

Kurz - verzichtet man auf die Steuerung am Raumthermostat und die Einbindung ins Schalterprogramm, kann man ca. 5 Räume ausrüsten zum Preis von einem WT-Bausatz (Classic, von IP rede ich gar nicht)...

Es gibt ja ein Modul für die Teile (https://fhem.de/commandref_modular_DE.html#XiaomiBTLESens), aber dazu müßte man irgendwelche PC-Frickeleien mit einem passenden BT-Adapter vornehmen. Ich habe den einen aber ganz schlicht mit OpenMQTTGateway@MQTT2_DEVICE eingebunden, dazu braucht man im einfachsten Fall einen ESP32 und die firmware, wobei die Reichweite "na ja" ist (durch eine Decke ging bei mir nicht, ich "brauchte" ein 2. GW, aber so kann ich "wenigstens" meine attrTemplate-Struktur dazu austesten ). Zumindest bis dahin ist das ok, (Batterie steht nach ca. 5 Wochen auf 100%) daher habe ich jetzt vor, diese Komfortfunktion mal auszurollen. Aber so ganz traue ich der ganzen (WLAN+BT-) Konstruktion noch nicht, daher auch der kritische Blick auf das, was bisher im Wiki stand .

Werde berichten...

[Beta-User]

werde ich mir dann mal testweise ein "one-for-all"-at basteln, dass alle 15 Min. alle virtuellen Temperaturwerte löscht, die älter als eine Stunde sind...

Jedenfalls mit kürzeren Intervallen hat das hier funktioniert :

Code Auswählen Erweitern

defmod a_delete_outdated_virtTemps at +*00:15 {\
my @vTemps = devspec2array("TYPE=CUL_HM:FILTER=model=VIRTUAL:FILTER=temperature~.+");;\
  foreach my $vTemp (@vTemps) {\
    CommandDeleteReading(undef,"$vTemp temperature" ) if ReadingsAge($vTemp,"temperature",0) > HOURSECONDS ;;\
  }\
}
Werde das mal ins Wiki packen, wenn mir nicht rechtzeitig was besseres liefert oder erklärt, warum es nicht gut ist .


Das mit den "leicht nachlaufenden Werten" dürfte sich auch geklärt haben: die Sensoren sind einfach "genauer" als die 0.1°C, die die HM-Geräte liefern (dass das messtechnischer Unsinn sein dürfte, ist schon klar, aber jedenfalls bringt es das System nicht durcheinander, wenn man "eigentlich (mathematisch) zu" genaue Werte weitergibt...).
Wie dem auch sei, in den Graphen sieht man die kleine Abweichung eben "irgendwann", bis dann die Schwelle erreicht ist, bis das wieder "genau" übereinstimmt .