HMIP-eTRV (HMCCUDEV) -> 1.CONTROL_MODE ohne Wert

[tca]

Hallo,

ich verwende mehrere HM-IP Thermostate HMIP-eTRV (HMCCUDEV).
Mir ist aufgefallen, dass das Reading/Attribut ":1.CONTROL_MODE" keinen Wert liefert, also leer ist.

Frage ich die CCU2 direkt über XML-API ab, ist auch dies ohne Rückgabewert. Es schein also ein Problem auf Seite der CCU2 (oder XML-API) zu sein.

Hat jemand von euch die gleiche Beobachtung gemacht?
Lässt sich der Wert von CONTROL_MODE auch anders von der CCU2 abfragen?
Falls ja, kann man evtl. einen work-around in HMCCUDEV implementieren?

Danke!
Tom

[zap]

CONTROL_MODE scheint nur die Flags Write und Event zu haben. Das ist komplett anders als bei BidCos. Wenn Du also den RPC Server laufen hast, müsste das Reading aktualisiert werden. XMLAPI greift per Read auf den Datenpunkt zu. Da kommt nix weil Read nicht unterstützt wird. Deshalb funktioniert auch get datapoint oder get update bei hmccudev nicht.

Hier hat jemand ein Beispiel:

https://forum.fhem.de/index.php/topic,51339.msg477197.html#msg477197

[tca]

Ich habe 8 HMIP-eTRV Thermostate; bei allen fehlt der Wert für CONTROL-MODE; die Abfrage mit 'get deviceifno' sieht bei allen 8 Thermostaten mehr oder weniger gleich aus:

Code Auswählen Erweitern


CHN 000393C98D0B9C:0 Bad Fenster:0
  DPT {b} HmIP-RF.000393C98D0B9C:0.CONFIG_PENDING =  [E]
  DPT {b} HmIP-RF.000393C98D0B9C:0.DUTY_CYCLE = false [RE]
  DPT {b} HmIP-RF.000393C98D0B9C:0.LOW_BAT = false [RE]
  DPT {f} HmIP-RF.000393C98D0B9C:0.OPERATING_VOLTAGE = 2.800000 [RE]
  DPT {b} HmIP-RF.000393C98D0B9C:0.UNREACH = false [RE]
CHN 000393C98D0B9C:1 HMIP-eTRV 000393C98D0B9C:1
  DPT {i} HmIP-RF.000393C98D0B9C:1.ACTIVE_PROFILE = 1 [WE]
  DPT {f} HmIP-RF.000393C98D0B9C:1.ACTUAL_TEMPERATURE = 26.100000 [RE]
  DPT {b} HmIP-RF.000393C98D0B9C:1.BOOST_MODE = false [WE]
  DPT {f} HmIP-RF.000393C98D0B9C:1.CONTROL_DIFFERENTIAL_TEMP =  [WE]
  DPT {i} HmIP-RF.000393C98D0B9C:1.CONTROL_MODE =  [WE]
  DPT {i} HmIP-RF.000393C98D0B9C:1.DURATION_UNIT =  [W]
  DPT {i} HmIP-RF.000393C98D0B9C:1.DURATION_VALUE =  [W]
  DPT {b} HmIP-RF.000393C98D0B9C:1.FROST_PROTECTION = false [RE]
  DPT {f} HmIP-RF.000393C98D0B9C:1.LEVEL = 0.000000 [RWE]
  DPT {b} HmIP-RF.000393C98D0B9C:1.PARTY_MODE = false [RE]
  DPT {f} HmIP-RF.000393C98D0B9C:1.PARTY_SET_POINT_TEMPERATU = 0.000000 [RE]
  DPT {s} HmIP-RF.000393C98D0B9C:1.PARTY_TIME_END =  [RWE]
  DPT {s} HmIP-RF.000393C98D0B9C:1.PARTY_TIME_START =  [RWE]
  DPT {i} HmIP-RF.000393C98D0B9C:1.SET_POINT_MODE = 0 [RWE]
  DPT {f} HmIP-RF.000393C98D0B9C:1.SET_POINT_TEMPERATURE = 20.500000 [RWE]
  DPT {b} HmIP-RF.000393C98D0B9C:1.SWITCH_POINT_OCCURED = false [RE]
  DPT {b} HmIP-RF.000393C98D0B9C:1.VALVE_ADAPTION =  [WE]
  DPT {i} HmIP-RF.000393C98D0B9C:1.VALVE_STATE = 4 [RE]
  DPT {i} HmIP-RF.000393C98D0B9C:1.WINDOW_STATE = 0 [WE]


Über die Web-Oberfläche der CCU2 kann man den Modus auswählen/umschalten zwischen Auto, Manu, Boost, Urlaub. Die Anzeige am Thermostat wechselt dann (es kommt also wirklich an).

Sollte ich noch etwas mit dem RPC-Server versuchen? (Bei mir ist das auf HMCCU:RPCRPC=internal eingestellt)

[zap]

Die Werte in eckigen Klammern bei get deviceinfo geben die Zugriffsart des jeweiligen Datenpunkts an. Bei CONTROL_MODE steht [WE]. Das steht für "Write" und "Event". Da "Read" fehlt, funktioniert mit diesem Datenpunkt kein 'get datapoint' und kein 'get update'.

Dafür kannst Du mit 'set datapoint 1.CONTROL_MODE den Modus einstellen. Das Ergebnis inkl. Aktualisierung des Readings kommt dann als Event bei FHEM an.

Und damit dieser Event empfangen werden kann, musst Du in HMCCU den RPC Server starten, ungefähr so:

Code Auswählen Erweitern


attr iodev rpcport 2010
set iodev rpcserver on


wobei 2010 der RPC-Port für HM-IP ist.

[tca]

Hm,

das verstehe ich nicht ganz: 1.WINDOW_STATE, 1.BOOST_MODE oder andere datapoint(s) sind auch im Modus [WE], trotzdem zeigen sie den Wert aus der CCU2 an.

Der RPC Server ist gestartet und läuft auf Port 2001 und 2010; deswegen bekomme ich auch Werte für 1.ACTUAL_TEMPERATURE, 0.OPERATING_VOLTAGE oder 1.WINDOW_STATE.

Ich habe gerade auch die Gegenprobe mit 1.BOOST_MODE [WE] gemacht, und das geht: schaltet man den BOOST Mode am Thermostat an, dann wird es in der CCU2 angezeigt und sofort auch in FHEM (HMCCUDEV).

Insofern müsste der Fehler woanders liegen: entweder heisst der CCU2 datapoint anders (mapping), oder es ist ein Bug in CCU2, weil der datapoint nicht aktualisiert wird.

[zap]

Schick mal bitte die Gerätedefinition mit Attributen für einen der Thermostaten

[tca]

Hier die Definition für eines der Thermostate (HMIP-eTRV):

Code Auswählen Erweitern


# Heizkörper Bad1 Thermostat HMIP-eTRV
# Geräte mit State-Channel = 1
define ccu2_HKT_B1 HMCCUDEV 000393C98D0B9C 1
attr ccu2_HKT_B1 IODev ccu2
attr ccu2_HKT_B1 alias Bad Fenster
attr ccu2_HKT_B1 ccureadingfilter (LOW_BAT|TEMPERATURE|VALVE|CONTROL)
attr ccu2_HKT_B1 controldatapoint 1.SET_POINT_TEMPERATURE
attr ccu2_HKT_B1 event-on-change-reading .*
attr ccu2_HKT_B1 genericDeviceType thermostat
attr ccu2_HKT_B1 group Heizung
attr ccu2_HKT_B1 homebridgeMapping TargetTemperature=control::HMIP-eTRV_000393C98D0B9C.1.SET_POINT_TEMPERATURE,minValue=18,maxValue=25,minStep=0.5 CurrentTemperature=HMIP-eTRV_000393C98D0B9C.1.ACTUAL_TEMPERATURE\
StatusLowBattery=Bad_Fenster.0.LOW_BAT
attr ccu2_HKT_B1 icon hm-cc-rt-dn
attr ccu2_HKT_B1 room Homekit,1OG
attr ccu2_HKT_B1 stateFormat T: HMIP-eTRV_000393C98D0B9C.1.ACTUAL_TEMPERATURE° D: HMIP-eTRV_000393C98D0B9C.1.SET_POINT_TEMPERATURE° V: HMIP-eTRV_000393C98D0B9C.1.VALVE_STATE%
attr ccu2_HKT_B1 statechannel 1
attr ccu2_HKT_B1 statedatapoint HMIP-eTRV_000393C98D0B9C.1.VALVE_STATE
attr ccu2_HKT_B1 stripnumber 1
attr ccu2_HKT_B1 substitute LOW_BAT!(0|false):0,(1|true):1;;CONTROL_MODE!0:AUTO,1:MANU,2:PARTY,3:BOOST
attr ccu2_HKT_B1 webCmd control
attr ccu2_HKT_B1 widgetOverride control:slider,10,1,28


Die anderen Thermostate sind mehr oder weniger auch so definiert.

Hier die Definition der CCU2:

Code Auswählen Erweitern


define ccu2 HMCCU ccu2
attr ccu2 alias HomeMatic Zentrale CCU2
attr ccu2 group Steuerung
attr ccu2 icon hm_ccu
attr ccu2 room 1OG
attr ccu2 rpcinterval 3
attr ccu2 rpcport 2001,2010
attr ccu2 rpcserver on


[zap]

Das sieht gut aus. Ich muss mal schauen welche Tracing Möglichkeit es gibt. Du könntest mal die Datei /var/log/messages auf der CCU prüfen, ob da Fehlermeldungen drin stehen, die CONTROL_MODE enthalten.

Noch ein Tipp: wenn Du das Attribut ccureadingformat auf datapoint setzt, sparst Du Dir den Devicenamen in den Readings. Seit Version 3.4 geht das Attribut auch mit HMCCUDEV, voher war es nur bei HMCCUCHN möglich.

Update: setzte mal in einem der Thermostat Devices das Attribut ccuflags auf trace. Loglevel sollte >1 sein. Dann ändere den Controlmode und schau mal, ob im Logfile von fhem entsprechende Einträge für CONTROL_MODE auftauchen.

Nicht vergessen, das trace Flag spätre wieder zu löschen

[tca]

ok, ich hab das 'ccuflags' auf 'trace' gestellt; das 'Loglevel' steht auf '2';
dann den Controlmode am Thermostat geändert, im Web-UI der CCU2 überprüft (->OK), aber im Logfile von FHEM ist kein Hinweis auf CONTROL_MODE (Trace-Log im Anhang);

Die Datei /var/log/messages habe ich mit

Code Auswählen Erweitern

cat /var/log/messages | grep CONTROL_MODE
überprüft, aber da steht nichts drinnen. Habe auch einen grep auf CCU2, CCU oder CONTROL gemacht, aber auch da kommt nichts.

Sieht für mich so aus, als ob die CCU2 das nicht weitergibt (? ? ?)

... Danke für den Tip mit dem ccureadingformat ...

Nachtrag:

Habe mir gerade mit "http://ccu2/addons/xmlapi/state.cgi?device_id=1838" alle Werte für ein Thermostat angesehen (XML Antwort der CCU2). Ich bekomme u.a.

Code Auswählen Erweitern

<datapoint name="HmIP-RF.000393C98D0B9C:1.CONTROL_MODE" type="CONTROL_MODE" ise_id="1859" value="" valuetype="16" valueunit="" timestamp="0"/> also 'value="" '; spricht für ein Fehler der CCU2 ? ?

[zap]

Nein, das leere Value bei XML-API ist kein Fehler der CCU. Der Datenpunkt CONTROL_MODE kann nicht aktiv gelesen werden. Works as designed. Bei BidCos Thermostaten ist das genau umgekehrt. Da kann man in CONTROL_MODE nicht schreiben und muss die Modi über dedizierte Datenpunkte setzen.

Bei HM-IP ist man darauf angewiesen, dass die CCU aktiv die Info schickt (per RPC Event). Es scheint hier wirklich ein Fehler CCU seitig vorzuliegen, d.h. die CCU schickt die Info nicht. Das ist umso ärgerlicher, als es anscheinend keinen Datenpunkt mit "Read"-Flag gibt, über den man den Control-Mode aktiv abfragen könnte.

Liest hier ggf. jemand mit, der ein HM-IP Thermostat nutzt und bei dem die Aktualisierung von CONTROL_MODE funktioniert?

[zap]

Es gibt einen Workaround, der zwar nicht schön ist, aber vielleicht hilft es, bis EQ-3 das gefixt hat:

Setze für das FHEM Device das Attribut ccuverify auf 2.Das bewirkt, dass HMCCUDEV/HMCCUCHN das Reading nach dem Setzen des Datenpunkts eigenständig aktualisiert. Blöd ist nur, wenn der Set Befehl beim Thermostaten nicht ankommt. Dann wird das Reading auf den falschen Wert gesetzt. Dürfte aber eher selten vorkommen.

[tca]

Danke für den Workaround. Ich glaube aber, dass ich in meinem Fall warten muss, bis es EQ-3 das repariert hat: mir gehts in erster Linie darum, schnell erkennen zu können, ob jemand versehentlich am Thermostat auf z.B. 'Manu' gestellt hat (also weniger, dass man es von FHEM aus einstellt).

Was meinst Du: ich kann mich am Montag kurz an EQ-3 wenden, und den Fehler/Beschreibung weitergeben (dann ist alles auf den Weg gebracht)?

[zap]

Habe noch nie bei EQ-3 einen Fehler gemeldet. Ich kenne auch die Reaktionszeiten nicht. Ich denke, die sammeln einige Fehler und geben dann ein Update raus.

Fehlerbeschreibung wäre: Datenpunkt CONTROL_MODE wird nicht per XML-RPC Schnittstelle (Event) aktualisiert.

[tca]

Habe gestern (SO, 18.9.16) eine Email (Kontaktformular) an eQ-3 geschrieben:

Sehr geehrter EQ-3 Support,

ich verwende mehrere HM-IP Thermostate (HMIP-eTRV) und eine CCU2 (Firmware 2.21.10), wobei auf die CCU2, neben dem Web-UI, auch über Skripte (XML-RPC Schnittstelle) zugegriffen wird.

Es scheint so, als ob bei einer Änderung des Betriebsmodus eines Thermostats ('Auto', 'Manu') der zugehörige Datenpunkt ,,1.CONTROL_MODE" nicht per XML-RPC (Event) aktualisiert/signalisiert wird. Die Aktualisierung im Web-Interface funktioniert allerdings.
Die Gegenprobe mit z.B. den Datenpunkten ,,1.WINDOW_STATE" oder ,,1.BOOST_MODE" funktioniert: hier wird die Änderung als XML-RPC Event von der CCU2 signalisiert.

Gibt es evtl. eine andere Möglichkeit den Datenpunkt ,,1.CONTROL_MODE" zu empfangen bzw. per Skript auszulesen?

Vielen Dank und freundliche Grüße,

heute (19.9.16) kanm die Antwort

Sehr geehrter Herr ...,

hiermit möchten wir uns für das von Ihnen entgegengebrachte Interesse an unseren Produkten bedanken.

Der Support von eQ-3 ist jedoch auf die Beantwortung von technischen Detailfragen zu unseren angebotenen Produkten ausgelegt.

Folgende Serviceleistungen und Anfragen bearbeiten wir daher nicht selbst,
können jedoch bei unseren Vertriebspartnern angefragt werden:

- Erstellung von individuellen Programmierungen in der CCU
- Fragen zur Skriptprogrammierung
- Fragen zu Zusatzsoftware
- Fragen zum Expertenmodus
- Fragen zu Open Source Projekten
- Fragen zu Bausätzen und einzelnen Bauteilen
- Fragen zur XML-RPC Schnittstelle (Anbindung an externe Systeme)
- Vorort-Service und Fernwartung
Bitte beachten Sie, dass obige Leistungen je Vertriebspartner unterschiedlich und nicht immer vollumfänglich angeboten werden können.
Das Netzwerk an Fachpartnern wird stetig erweitert, eine Übersicht der Bezugsquellen finden Sie hier: http://www.eq-3.de/partner/bezugsquellen.html

Weitere nützliche Informationen zu unserem HomeMatic System finden Sie im HomeMatic Blog
http://www.homematic-inside.de/
http://www.smarthelpers.de/

Mit freundlichen Grüßen aus Leer
...

Hm, ich hätte zwar gedacht, dass dies eine technische Detailfrage ist, offenbar werden aber Fragen zur XML-RPC Schnittstelle von den Vertriebspartnern beantwortet. Ich habe die Frage jetzt an ELV gesendet, die sitzen scheinbar im selben Haus.

[zap]

Da bin ich mal gespannt. Eine solche Fragen müsste eigentlich ein Entwickler beantworten und nicht der Vertrieb. Aber wer bei ELV/EQ-3 was macht, hab ich noch nie kapiert.