Problem transfer VCCU => HM-CCRTDN "measured-temp" per peering

[jhs]

Hallo zusammen,

es ist Sommer und dabei ergibt sich die gute Gelegenheit, stressfrei an der Optimierung der Heizungssteuerung zu werkeln, mit dem Ziel:
Werte von beliebigen Raum-Thermometern via peering VCCU=>HM-CCRTDN  als "measured-temp" im HM-Thermostat zu nutzen

Bisher war diese Art Kopplung in meiner Fhem-Konfiguration von Raum-Thermometer (HHM-WDS-10-TH-O, soweit vorhanden) und dem zugehörigen Heizungsregler (HM-CCRTDN) per  direktem peering im wesentlichen ohne Probleme nutzbar. Aber bei der "Zwischenschaltung" der VCCU in der Übertragung der "measured-temp" bin ich auf folgendes Problem gestoßen:

die Kommunikation funktioniert zwischen Temperatur-Sensoren und VCCU problemlos, aber die Kommunikation funktioniert NICHT zwischen VCCU und den HM-Heizkörper-Ventilen,
genauer gesagt, nur sporadisch in seltenen Fällen wird der Wert von der VCCU vom HM-CCRTDN als "measuered-temp" übernommen, ansonsten meistens der interne Wert vom Thermostaten.

# das peering wurde für alle Thermostatet nach folgendem Beispiel konfiguriert:

set VCCU_HM_06_EG_Arbeitszimmer_jhs_Sensor5 peerChan 0 EG.AZ.jhs.Heizung.05_Weather single set

nach längerere Wartezeit

getkonfig auf EG.AZ.jhs.Heizung.05_Weather

Ich muss nicht extra erwähnen, dass ich jede Menge zu dem Thema im Forum recherchiert habe, und viele der entsprechenden Tipps nachvollzogen habe, leider mit o.g. unbefriedigendem Ergebnis, d.h. mit folgendem Zwischenstand:
lt. Doku müsste das funktionieren, aber die Realität sieht anders aus.

Irgendwelche Ideen, zur Fehlereinkreisung oder Lösung ?

Danke im voraus

JHS

Noch als Hinweis: Fhem läuft in aktueller Version (Latest Revision: 29046) auf einem NUC mit 32GB und SSD.

Code Auswählen Erweitern

peerXref done:
 x-ref list
...
  virtual
       VCCU_HM_01_EG_Flur_Sensor1  =>  EG.Flur.Heizung.10_Weather
       VCCU_HM_03_EG_Wohnzimmer_Sensor2  =>  EG.Wohnzimmer.Heizung.04_Weather
       VCCU_HM_04_EG_Esszimmer_Sensor3  =>  EG.Esszimmer.Heizung.03_Weather
       VCCU_HM_05_EG_Kueche_Sensor4  =>  EG.Kueche.Heizung.17_Weather
       VCCU_HM_06_EG_Arbeitszimmer_jhs_Sensor5  =>  EG.AZ.jhs.Heizung.05_Weather
       VCCU_HM_07_EG_Arbeitszimmer_ih_Sensor6  =>  EG.AZ.ih.Heizung.06_Weather
       VCCU_HM_08_EG_Bad_hinten_Sensor7  =>  EG.Bad.hinten.Heizung.01_Weather
       VCCU_HM_09_EG_Schlafzimmer_Sensor8  =>  EG.Schlafzimmer.Heizung.15_Weather
       VCCU_HM_10_EG_Gartenzimmer_Sensor9  =>  EG.Gartenzimmer.Heizung.07_Weather
       VCCU_HM_12_EG_Bad_vorn_Sensor10  =>  EG.Bad.vorn.Heizung.02_Weather
       VCCU_HM_13_EG_Veranda_Sensor11  =>  EG.Veranda.Heizung.09_Weather
       VCCU_HM_14_EG_Garage_Sensor12  =>  EG.Garage.Heizung.16_Weather
       VCCU_HM_22_OG_Gaestezimmer_Sensor13  =>  OG.Gaestezimmer.Heizung.08_Weather
       VCCU_HM_23_OG_Durchgang_Sensor14  =>  OG.Durchgangsraum.Heizung.13_Weather
       VCCU_HM_25_OG_Technikraum_Sensor15  =>  OG.Technikraum.Heizung.12_Weather
       VCCU_HM_32_KG_Werkkeller_Sensor16  =>  KG.Werkkeller.Heizung.14_Weather
       VCCU_HM_35_KG_Waeschekeller_Sensor17  =>  KG.Waeschekeller.Heizung.11_Weather
Demnach müsste alles funktionieren, tut es aber nicht

[frank]

lt. Doku müsste das funktionieren, aber die Realität sieht anders aus.

sicherlich nicht.
zeige die doku.

[jhs]

Hallo,
Sorry, den höheren Sinn der Pointe habe ich nicht so ganz verstanden.
Ich bin vieles  der Links gem ...

Google: fhem  vccu hm-ccrtdn  external sensor

durchgegangen und entsprechend konfigriert (17 Ventile, mühselig).
Wenn mich meine Beobachtung nicht täuscht, bekomme ich kein statisches Verhalten:
wechselt nach kurzer Anzeige das

Code Auswählen Erweitern

attr EG.AZ.jhs.Heizung.05_Weather peerIDs 00000000,F120342Ein

Code Auswählen Erweitern

attr EG.AZ.jhs.Heizung.05_Weather peerList VCCU_HM_06_EG_Arbeitszimmer_jhs_Sensor5in

Code Auswählen Erweitern

attr EG.AZ.jhs.Heizung.05_Weather peerList peerUnreadund zwischenzeitlich stimmen kurzzeitlich die Werte von "measured-temp" und "set_virtTemp" überein.

Kann das ein timing Problem sein ?

Danke für jeden brauchbaren Tipp.
Gruß
JHS

[frank]

Sorry, den höheren Sinn der Pointe habe ich nicht so ganz verstanden.

es gab gar keine pointe, sondern:

1. die doku
https://wiki.fhem.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat#Simulation_von_Fensterkontakten_und_externen_Temperatursensoren

2. sagt explizit im grossen roten "kasten"

Insbesondere die virtuellen Kanäle der VCCU eignen sich nicht dazu, mehrere HM-CC-RT-DN unabhängig voneinander anzusteuern!

Kann das ein timing Problem sein ?

genau.
daher würde ich zunächst mit nur 2 virtuellen tempfühlern beginnen, bis diese zuverlässig funktionieren.

[jhs]

Hallo,
zunächst erst einmal vielen Dank für die schnelle und hilfreiche Antwort mit Hinweisen.
Sorry, den "roten Kasten" hatte ich gelesen, aber im ersten Durchgang nicht in der genügenden Tiefe beachtet. Nun habe ich mich nochmals an das Thema neu rangewagt, mit dem Ziel beliebige externe Temp.sensoren als Datenquelle "measured-temp" für die Regelung in den HM-CCRTDN zu nutzen.
(Code-Schnipsel und screenshots habe ich unten als Info meiner Tests beigefügt.)

Mein persönliches Fazit aus dieser Aktion:
vermutlich Timing-Probleme führen in meinem Fhem-System zu einem recht instabilen Betrieb bei der Übergabe der "measured-temp" Werte, sodass ich dieses Konstrukt mittels VCCU-Technik für so etwas kritisches wie die Heizungssteuerung nicht einsetzen möchte.
- mein System werde ich zunächst auf die direkte peering-Kommunikation zwischen HM-Technik (HM-CCRTDN || HM-WDS10-TH-O bzw. WDS30-T-O) zurückrüsten und baldmöglichst die Schiene HM verlassen.
- zur Info: als Hardware-Ersatz ist AVM/DECT und Shelly vorgesehen. Da steht dann demnächst 'ne ganze Menge an HM-Hardware zur Verfügung

Ich bewundere die Leistung der Entwickler, dies möglich zu machen, vermute aber, hier werden Grenzen der HM-CCRTDN erreicht oder überschritten, für die es keinen workaround gibt.

Nochmals vielen Dank für Deine Unterstützung,
Gruß
jhs

Code Auswählen Erweitern

# HM-CCRTDN (extract)
define EG.AZ.jhs.Heizung.05_Weather CUL_HM 22B63F01
attr EG.AZ.jhs.Heizung.05_Weather alias EG.AZ.jhs.Heizung.05_Weather
attr EG.AZ.jhs.Heizung.05_Weather model HM-CC-RT-DN
attr EG.AZ.jhs.Heizung.05_Weather peerIDs 00000000,F1200501

define VCCU_HM_06_EG_Arbeitszimmer_jhs_Sensor5 CUL_HM F12005
attr VCCU_HM_06_EG_Arbeitszimmer_jhs_Sensor5 .mId FFF1
attr VCCU_HM_06_EG_Arbeitszimmer_jhs_Sensor5 IOgrp VCCU_HM_06_EG_Arbeitszimmer_jhs_Sensor5
attr VCCU_HM_06_EG_Arbeitszimmer_jhs_Sensor5 event-on-change-reading state.*
attr VCCU_HM_06_EG_Arbeitszimmer_jhs_Sensor5 group VCCU
attr VCCU_HM_06_EG_Arbeitszimmer_jhs_Sensor5 model VIRTUAL
attr VCCU_HM_06_EG_Arbeitszimmer_jhs_Sensor5 msgRepeat 0
attr VCCU_HM_06_EG_Arbeitszimmer_jhs_Sensor5 room MQTT
attr VCCU_HM_06_EG_Arbeitszimmer_jhs_Sensor5 subType virtual
attr VCCU_HM_06_EG_Arbeitszimmer_jhs_Sensor5 webCmd virtual

set VCCU_HM_06_EG_Arbeitszimmer_jhs_Sensor5 virtual 1

define VCCU_HM_06_EG_Arbeitszimmer_jhs_Sensor5_Btn1 CUL_HM F1200501
attr VCCU_HM_06_EG_Arbeitszimmer_jhs_Sensor5_Btn1 group VCCU_HM_ext_temp_sensor_Btn1
attr VCCU_HM_06_EG_Arbeitszimmer_jhs_Sensor5_Btn1 model VIRTUAL
attr VCCU_HM_06_EG_Arbeitszimmer_jhs_Sensor5_Btn1 peerIDs 22B63F01
attr VCCU_HM_06_EG_Arbeitszimmer_jhs_Sensor5_Btn1 room MQTT
attr VCCU_HM_06_EG_Arbeitszimmer_jhs_Sensor5_Btn1 webCmd virtTemp

set VCCU_HM_06_EG_Arbeitszimmer_jhs_Sensor5_Btn1 peerChan 0 EG.AZ.jhs.Heizung.05_Weather single set

[Otto123]

Hi,
ich halte das hier für Unfug

attr VCCU_HM_06_EG_Arbeitszimmer_jhs_Sensor5 IOgrp VCCU_HM_06_EG_Arbeitszimmer_jhs_Sensor5

Du vermischts die definition EINER VCCU mit der definition von virtuellen Temperaturfühlern. Das sind auf alle Fälle zwei völlig getrennte Dinge!

Eine VCCU gruppiert und koordiniert die IOs, ein virtueller Aktor / Fühler ist ein separates Device.
Eine VCCU hat auch virtuelle Kanäle, die sind nur speziell, und nicht als peering Partner für einen Thermostaten, nutzbar.

Gruß Otto

[jhs]

Hi,

danke für den Hinweis, dass meine Konfig. mit VCCU&Co falsch ist.
OT: über Jahre hinweg mit _einer_ VCCU (seit 2014..."wie ich VCCU verstanden hatte") hat meine Fhem-Konfig mit allen devices auch gut funktioniert, insbesondere die störungsfreie Funk-Abdeckung ("VCCU_HM CUL_0:ok,LAN_1:ok,LAN_4:ok,LAN_5:ok")

Erst mit dem neuen Vorhaben, beliebige externe Temp.sensoren als Datenquelle "measured-temp" für die Regelung in den HM-CCRTDN zu nutzen und meinem Vorgehen gemäß
Google: fhem  vccu hm-ccrtdn  external sensor und https://wiki.fhem.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat#Simulation_von_Fensterkontakten_und_externen_Temperatursensoren
traten die .o.g. Probleme auf..
Unabhängig davon, wie falsch ich von eine rrichtigen Konfiguration entfernt bin, das genannte Ziel mit den ext. Temp.sensoren zu erreichen, habe ich aus den Forenbeiträgen entnommen, dass man keinen stabilen Betrieb erwarten kann bei 17x HM-CCRTDN mit der Übertragung der "measured-temp" (u.a. timing Problematik). Und mit so einem System möchte ich nicht in die nächste Heizperiode schlittern.

Wie geht es für mich da weiter ?
Für mich macht es daher wenig Sinn, noch weiter auf diesem Weg mit den HM-Komponenten zu experimentieren.
Wie o.g., ich werde meine Fhem-/HM-Konfig zurückstellen auf direktes peering der HM-devices HM-CCRTDN und HM-WDS.* und danach möglichst bald auf Nicht-HM-Hardware umsatteln, bei der eine Einspeisung von "measured-temp" durch ein offenes Protokoll ohne Umwege unterstützt wird.
Wer jetzt noch Interesse an den dann für mich obsoleten HM-Komonenten hat, mag sich vormerken lassen

Vielen Dank an alle Beteiligten für die Tipps und Unterstützung.
Gruß jhs

[Otto123]

Hi jhs,

ich habe nicht gesagt, dass die Konfig Deiner VCCU falsch ist, ich kenne die nicht. Die Statusmeldung "VCCU_HM CUL_0:ok,LAN_1:ok,LAN_4:ok,LAN_5:ok" klingt gut.
Nur das, was Du mit den anderen virtuellen Definitionen gemacht hast sieht eigentümlich aus. Du hast das alles VCCU..... genannt, aber es hat scheinbar mit der VCCU gar nichts zu tun.

Ob das Timing bei solchen virtuellen Konstrukten ein Problem in Abhängigkeit der Anzahl ein Problem ist, kann ich nicht sagen. Ich habe damit null Erfahrung.

Nachdem was ich hier rauslese, müsste in Deiner Umgebung das attr IOgrp immer so aussehen

Code Auswählen Erweitern

attr xxx IOgrp VCCU_HMda muss die VCCU drinstehen und nichts anderes!

Gruß Otto

[frank]

Sorry, den "roten Kasten" hatte ich gelesen, aber im ersten Durchgang nicht in der genügenden Tiefe beachtet. Nun habe ich mich nochmals an das Thema neu rangewagt, mit dem Ziel beliebige externe Temp.sensoren als Datenquelle "measured-temp" für die Regelung in den HM-CCRTDN zu nutzen.

wohl eher ein grundsätzliches vorgehen?
ich vermisse auch noch das attribut cyclicMsgOffset.

Ich bewundere die Leistung der Entwickler, dies möglich zu machen, vermute aber, hier werden Grenzen der HM-CCRTDN erreicht oder überschritten, für die es keinen workaround gibt.

zur zeit sehe ich erst einmal ein "grenze" bei der umsetzung des wiki artikels.

Unabhängig davon, wie falsch ich von eine rrichtigen Konfiguration entfernt bin, das genannte Ziel mit den ext. Temp.sensoren zu erreichen, habe ich aus den Forenbeiträgen entnommen, dass man keinen stabilen Betrieb erwarten kann bei 17x HM-CCRTDN mit der Übertragung der "measured-temp" (u.a. timing Problematik).

das hört sich eher nach einer ausrede an, wenn man es nicht einmal mit nur einem virtuellen tempsensor schafft. 

Wie o.g., ich werde meine Fhem-/HM-Konfig zurückstellen auf direktes peering der HM-devices HM-CCRTDN und HM-WDS.*

dezentralisierung ist immer besser.

sodass ich dieses Konstrukt mittels VCCU-Technik für so etwas kritisches wie die Heizungssteuerung nicht einsetzen möchte.

ein umstieg auf avm/dect und shelly/wlan soll dann sicherer sein?

[jhs]

Hi,

noch eine AW mit ein paar Anmerkungen und dann mein Fazit.

Es fehlt mir sicher noch vieles an Kenntnis an Fhem-KnowHow, mein o.g. Vorhaben umzusetzen (... beliebige externe Temp.sensoren als Datenquelle "measured-temp" für die Regelung in den HM-CCRTDN zu nutzen).
Nach den gescheiterten Experimenten kann ich wenigstens den Rollback zum direkten peering der HM-nativen Komponenten HM-CCRTDN und HM-WDS.*  erfolgreich abhaken.
(Nebenbei, Murphy's Law war auch beteiligt: einige Temp.sensoren schwankten im Status "end-of-battery-life" und kommunizierten mal und mal nicht! Das war evtl. auch schon in der Experimentierpahse so )

Inzwischen habe ich für die gleiche Problematik eine Lösung auf andere Weise ausprobiert:
Die wichtigen Parameter "Soll-Temperatur" und (extern gemessene) "Raum-Temeperatur" in meinem Fhem-Umgebung wurden per MQTT zwischen drei Shelly Heizkörper-Thermostaten und den vorhandenen HM-WDS.* Sensoren ausgetauscht. (Das war auch mein erster Kontakt mit shellies).
Innerhalb weniger Stunden lief das ganze Konstrukt perfekt und stabil, so wie ich mir das vorgestellt hatte.
Durch Verwendung von MQTT konnte ich das ganze in einem weiteren Test auch noch auf mehrere unabhängige Fhem-Instanzen  verteilen (Danke an @Otto123 für die tollen Hilfstexte zum Thema mehrere Fhem-Instanzen)

Mein Fazit:
die MQTT-Schnittstelle der Shelly-Hardware, das war die Lösung: einfach und übersichtlich, robust, und von jedermann nachvollziehbar, von der Möglichkeit, mit anderen Systemen zu interagieren mal ganz abgesehen.

Für mich ergibt sich daraus die Erkenntnis,
HM ist wohl inzwischen eher ein "Ritt auf einem toten Gaul"! (sorry, die Diskussion darüber passt nicht in diesen Thread.)
Ob man eine Implementierung von MQTT-Schnittstellen in den HM &Co  device Modulen realisieren kann kann ich nicht beurteilen. Ich würde es auf jeden Fall als signifikante Verbesserung empfinden.

Nochmals vielen Dank
jhs