Neues Modul HMCCU für Homematic CCU

[zap]

Der Befehl GLOBAL_BUTTON_LOCK ist BOOL und RW. Also müsste er anpassbar sein. Alles merkwürdig.

Sehe ich auch so, zumal folgender Befehl bei einem nicht-IP Thermostaten funktioniert:

set mydev config GLOBAL_BUTTON_LOCK=true

Da ist der Parameter dem Device zugeordnet, nicht dem Kanal 0. Scheint beim IP-Thermostaten anders zu sein.

Prüfe bitte mal, ob in der Datei /var/log/messages auf der CCU irgendwelche Fehler auftauchen, wenn Du den set Befehl ausführst. Oder hattest Du das schon geprüft? Dann sorry, versuche den Überblick zu behalten

[fini]

Auf dem Pi:

vi /etc/systemd/system/fhem.service

Falls Du nicht root bist, vornedran ein "sudo" stellen.

Folgendes eintragen:

Code Auswählen Erweitern


[Unit]
Description=FHEM service
After=network.target
Wants=network.target

[Service]
Type=forking
User=fhem
Group=dialout
WorkingDirectory=/opt/fhem
ExecStart=/usr/bin/perl fhem.pl fhem.cfg

[Install]
WantedBy=multi-user.target


Abspeichern. Dann folgende Befehle ausführen (wieder mit sudo davor, wenn Du kein root bist:

systemctl daemon-reload
systemctl enable fhem.service

Fertig.

also nach den reboot sind jetzt alle Geräte da ... rpc läuft.
Supi ... danke zap!!!
Kannst Du noch mal schaun ins Logfiles ob wiklich alles ok ist?

[Mundus]

Hier mal meine bisher ermittelten verschiedenen LOGS.
1. GLOBAL_BUTTON_LOCK über UI der CCU2 zu setzen

Code Auswählen Erweitern

LOG aus /var/log/messages

Feb 24 20:39:13 homematic-ccu2 local0.err ReGaHss: Error: IseESP::ExecError= Execution failed: [-1] 0 0x00 [0] 144 0x90 [1] 0 0x00 [2] 9 0x09 [3] 0 0x00 [4] 28 0x1c  [../Platform/DOM/iseESPexec.cpp (11622)]
Feb 24 20:39:13 homematic-ccu2 local0.err ReGaHss: Error: IseESP::ExecError= Execution failed: [-1] 0 0x00 [0] 144 0x90 [1] 0 0x00 [2] 9 0x09 [3] 0 0x00 [4] 28 0x1c  [../Platform/DOM/iseESPexec.cpp (11622)]

2. GLOBAL_BUTTON_LOCK über FHEM setzen

Code Auswählen Erweitern

LOG aus /var/log/messages

ailed: [-1] 0 0x00 [0] 97 0x61 [1] 0 0x00 [2] 99 0x63 [3] 0 0x00 [4] 100 0x64  [../Platform/DOM/iseESPexec.cpp (11622)
Feb 24 20:45:55 homematic-ccu2 local0.err ReGaHss: Error: IseESP::ExecError= Execution failed: [-1] 0 0x00 [0] 144 0x90 [1] 0 0x00 [2] 9 0x09 [3] 0 0x00 [4] 28 0x1c  [../Platform/DOM/iseESPexec.cpp (11622)]
Feb 24 20:45:55 homematic-ccu2 local0.err ReGaHss: Error: IseESP::ExecError= Execution failed: [-1] 0 0x00 [0] 144 0x90 [1] 0 0x00 [2] 9 0x09 [3] 0 0x00 [4] 28 0x1c  [../Platform/DOM/iseESPexec.cpp (11622)]

Einen Unterschied in den LOGs erkenne ich nicht wirklich. Insgesamt scheint der Befehl seltsam verarbeitet zu werden (egal ob CCU2 oder FHEM).

Die Antwort von eQ-3 auf meine Anfrage war auch nicht zielführend:

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

Bitte haben Sie Verständnis, dass der technische Support der eQ-3 AG in erster Linie auf die Beantwortung von technischen Detailfragen im Aftersales-Service zu unseren Produkten ausgerichtet ist.

Folgende Serviceleistungen und Themenbereiche bearbeiten wir daher nicht selbst.

- individuelle Programmerstellung
- Skriptprogrammierung
- Zusatzsoftware
- Expertenparameter
- Open Source Projekte
- OEM Bausätze
- Support auf Bauteilebene
- XML-RPC Schnittstelle
- Vorort-Service
- Fernwartung
- etc.

Viele dieser Leistungen können jedoch weitgehend über unsere geschulten Fachpartner und Fachhandwerker abgedeckt werden.

Das Netzwerk an qualifizierten Fachpartnern wird stetig erweitert.
Eine Übersicht der Bezugsquellen finden Sie hier:
http://www.eq-3.de/partner/bezugsquellen.html

Mit freundlichen Grüßen aus Leer

Ihr eQ-3 Support-Team

Daher versuche ich mal einen Fachpartner... Zur Zeit vermute ich, dass die Befehlssyntax bei dem HM-IP Gerät anders lautet, nur wie, da habe ich keine Ahnung... [0/1|false/true] sind es scheinbar nicht. Kann ich ermitteln, was die CCU2 an das HMIP Thermostat sendet?

Gruß

Mundus

[fini]

also nach den reboot sind jetzt alle Geräte da ... rpc läuft.
Supi ... danke zap!!!
Kannst Du noch mal schaun ins Logfiles ob wiklich alles ok ist?

ich habe doch ein neues Problem ...
Wenn ich Fhem neu starte

Code Auswählen Erweitern


shutdown restart

dann will er all 5 sek. neu starten, also immer wieder neu

Wenn ich den PI neu starte ist alles ok

[klaso]

Machst du beim browser einen refresh? Falls ja, dann nach shutdown restart nicht refresh sondern "page zurück" drücken. Oder tab schliessen und im neuen tab auf fhem wieder zugreifen

[fini]

Machst du beim browser einen refresh? Falls ja, dann nach shutdown restart nicht refresh sondern "page zurück" drücken. Oder tab schliessen und im neuen tab auf fhem wieder zugreifen

nein ... mach kein browser refresh
gebe nur  shutdown restart ein und oben steht dann immer wieder das er neu starte 5 sek

[zap]

Stelle die Frage bitte mal im allgemeinen Forum. Das hat nichts mit HMCCU zu tun.

[zap]

Einen Unterschied in den LOGs erkenne ich nicht wirklich. Insgesamt scheint der Befehl seltsam verarbeitet zu werden (egal ob CCU2 oder FHEM).

Die Antwort von eQ-3 auf meine Anfrage war auch nicht zielführend:
Daher versuche ich mal einen Fachpartner... Zur Zeit vermute ich, dass die Befehlssyntax bei dem HM-IP Gerät anders lautet, nur wie, da habe ich keine Ahnung... [0/1|false/true] sind es scheinbar nicht. Kann ich ermitteln, was die CCU2 an das HMIP Thermostat sendet?

Gruß

Mundus

Leider ist mir keine Möglichkeit bekannt, wie man da etwas tracen kann. Bei HM-IP schon gar nicht, da das verschlüsselt ist. Hier ist übrigens die Doku zu den IP-Devices:

http://www.eq-3.com/Downloads/eq3/download%20bereich/hm_web_ui_doku/HmIP_DeviceDocumentation.pdf

Da sind sogar die Config-Parameter (u.a. GLOBAL_BUTTON_LOCK) beschrieben. Liegt bei Deinem Thermostat in Kanal 0, ist RW und vom Typ BOOL. Also nichts neues.

Ein Unterschied zum alten Protokoll ist natürlich theoretisch denkbar. Ich schau mir mal die RPC Doku nochmal an. Ein Zitat aus dieser Doku:

"* die Parameterwerte entsprechen nicht komplett der alten Spezifikation (z.B. Flags werden nicht unterstützt oder bestimmte Werteausprägungen sind geändert worden)"

Was konkret geändert wurde, steht da natürlich nicht. 

(!) Aber mal ne blöde Frage: wenn Du ein "get deviceinfo" ausführst, enthält die Ausgabe dann vielleicht einen Datenpunkt "GLOBAL_BUTTON_LOCK"?

UPDATE: Ich habe gerade die Version 3.9.005 von HMCCU eingecheckt. Sollte morgen per update verteilt werden.
Wenn Du die morgen installiert hast, setze bitte bei dem Thermostatdevice das Attribut ccuflags auf trace. Danach den set config Befehl nochmal ausführen und sehen, was im Logfile ausgegeben wird. Verbose muss mindestens 2 sein.

[kjmEjfu]

Blöde Frage vielleicht, aber kann ich auch zwei neue Readings erstellen lassen?

Sprich HMCCU erzeugt mir derzeit im ccudef-readingname der CCU2 u.a.

Code Auswählen Erweitern

^(.+\.)?ACTUAL_TEMPERATURE$:measured-temp;

Nun bräuchte ich den Wert aus ACTUAL_TEMPERATURE aber auch noch im Reading temperature (wegen Homekit).
Geht das oder habe ich einen Denkfehler? (ja, ich kann im Homebridge-Mapping natürlich measured-temp auf temperature mappen)

[zap]

Blöde Frage vielleicht, aber kann ich auch zwei neue Readings erstellen lassen?

Sprich HMCCU erzeugt mir derzeit im ccudef-readingname der CCU2 u.a.

Code Auswählen Erweitern

^(.+\.)?ACTUAL_TEMPERATURE$:measured-temp;

Nun bräuchte ich den Wert aus ACTUAL_TEMPERATURE aber auch noch im Reading temperature (wegen Homekit).
Geht das oder habe ich einen Denkfehler? (ja, ich kann im Homebridge-Mapping natürlich measured-temp auf temperature mappen)

Das geht:

Code Auswählen Erweitern

^(.+\.)?ACTUAL_TEMPERATURE$:+measured-temp;^(.+\.)?ACTUAL_TEMPERATURE$:temperature;

Das '+' ist hier entscheidend und bedeutet: ersetze ACTUAL_TEMPERATURE nicht durch measured-temp, sondern füge ein neues Reading hinzu. Bei der 2. Regel wird dann ACTUAL_TEMPERATURE tatsächlich durch temperature ersetzt, weil hier das '+' fehlt. Wenn Du hier auch ein '+' einsetzt, hast Du am Ende sogar 3 Readings: ACTUAL_TEMPERATURE, measured-temp und temperature.

[fini]

Stelle die Frage bitte mal im allgemeinen Forum. Das hat nichts mit HMCCU zu tun.

hab es ja hier nur hier rein geschrieben, weill es erst nach der Einbindung von
/etc/systemd/system/fhem.service
der Fehler kommt.

Beim PI start weden die HM Geräte jetzt erkannt.
Nur wenn ich Fhem neu starte ... sartet Fhem jede 5 sec neu

Also das Problem mit rpc server ist vorbei ... das mit Fhem ist neu

[Wernieman]

hab es ja hier nur hier rein geschrieben, weill es erst nach der Einbindung von
/etc/systemd/system/fhem.service
der Fehler kommt.

Ich würde denken, das der systremd dafür verantwortlich ist ... aber das möchte ich nicht in diesem Thread diskutieren

[zap]

Ich würde denken, das der systremd dafür verantwortlich ist ... aber das möchte ich nicht in diesem Thread diskutieren

Ja ich auch (bezieht sich auf beide Teile Deiner Aussage).

Nur soviel: Der Effekt tritt bei mir auch auf. Habe es nur nicht bemerkt, da ich nach einem Update sowieso nie "shutdown restart" benutze sondern unter Linux:

1. systemctl stop fhem

Dann prüfen ob noch was läuft (geforkte Prozesse, z.B. SONOS oder HMCCU):
2. ps -ef | grep fhem.pl

3. systemctl start fhem

[Mundus]

(!) Aber mal ne blöde Frage: wenn Du ein "get deviceinfo" ausführst, enthält die Ausgabe dann vielleicht einen Datenpunkt "GLOBAL_BUTTON_LOCK"?

Code Auswählen Erweitern

get FlurThermostat deviceinfo
gibt nachfolgende Ausgabe

Code Auswählen Erweitern

CHN 000397098A3254:0 HMIP-FlurThermostat:0
  DPT {b} HmIP-RF.000397098A3254:0.CONFIG_PENDING = true [RE]
  DPT {b} HmIP-RF.000397098A3254:0.DUTY_CYCLE = false [RE]
  DPT {b} HmIP-RF.000397098A3254:0.LOW_BAT = false [RE]
  DPT {f} HmIP-RF.000397098A3254:0.OPERATING_VOLTAGE = 2.900000 [RE]
  DPT {n} HmIP-RF.000397098A3254:0.RSSI_DEVICE = 221 [RE]
  DPT {n} HmIP-RF.000397098A3254:0.RSSI_PEER = 220 [RE]
  DPT {b} HmIP-RF.000397098A3254:0.UNREACH = false [RE]
  DPT {b} HmIP-RF.000397098A3254:0.UPDATE_PENDING = false [RE]
CHN 000397098A3254:1 HMIP-FlurThermostat:1
  DPT {i} HmIP-RF.000397098A3254:1.ACTIVE_PROFILE = 1 [WE]
  DPT {f} HmIP-RF.000397098A3254:1.ACTUAL_TEMPERATURE = 20.600000 [RE]
  DPT {b} HmIP-RF.000397098A3254:1.BOOST_MODE = false [WE]
  DPT {f} HmIP-RF.000397098A3254:1.CONTROL_DIFFERENTIAL_TEMP =  [WE]
  DPT {i} HmIP-RF.000397098A3254:1.CONTROL_MODE =  [WE]
  DPT {i} HmIP-RF.000397098A3254:1.DURATION_UNIT =  [W]
  DPT {i} HmIP-RF.000397098A3254:1.DURATION_VALUE =  [W]
  DPT {b} HmIP-RF.000397098A3254:1.FROST_PROTECTION = false [RE]
  DPT {f} HmIP-RF.000397098A3254:1.LEVEL = 1.000000 [RWE]
  DPT {b} HmIP-RF.000397098A3254:1.PARTY_MODE = false [RE]
  DPT {f} HmIP-RF.000397098A3254:1.PARTY_SET_POINT_TEMPERATU = 0.000000 [RE]
  DPT {s} HmIP-RF.000397098A3254:1.PARTY_TIME_END =  [RWE]
  DPT {s} HmIP-RF.000397098A3254:1.PARTY_TIME_START =  [RWE]
  DPT {i} HmIP-RF.000397098A3254:1.SET_POINT_MODE = 0 [RWE]
  DPT {f} HmIP-RF.000397098A3254:1.SET_POINT_TEMPERATURE = 21.000000 [RWE]
  DPT {b} HmIP-RF.000397098A3254:1.SWITCH_POINT_OCCURED = false [RE]
  DPT {b} HmIP-RF.000397098A3254:1.VALVE_ADAPTION =  [WE]
  DPT {i} HmIP-RF.000397098A3254:1.VALVE_STATE = 4 [RE]
  DPT {i} HmIP-RF.000397098A3254:1.WINDOW_STATE = 0 [WE]
Ein Datenpunkt GLOBAL_BUTTON_LOCK ist nicht dabei... Ich habe den Befehl auch für das alte Thermostat ausprobiert und auch dort taucht GLOBAL_BUTTON_LOCK nicht auf.

UPDATE: Ich habe gerade die Version 3.9.005 von HMCCU eingecheckt. Sollte morgen per update verteilt werden.
Wenn Du die morgen installiert hast, setze bitte bei dem Thermostatdevice das Attribut ccuflags auf trace. Danach den set config Befehl nochmal ausführen und sehen, was im Logfile ausgegeben wird. Verbose muss mindestens 2 sein.

Grundsätzlich ist global verbose =5, sodass ich verbose für das Thermostat nicht angepasst habe.  Das LOG hat sich nicht geändert

Code Auswählen Erweitern


2017.03.03 22:52:37 4 : WEB_192.168.130.8_52078 POST /fhem&detail=FlurThermostat&fwcsrf=fhem_222963384671245&dev.setFlurThermostat=FlurThermostat&cmd.setFlurThermostat=set&arg.setFlurThermostat=config&val.setFlurThermostat=0+GLOBAL_BUTTON_LOCK%3D1; BUFLEN:0
2017.03.03 22:52:37 5 : Cmd: >set FlurThermostat config 0 GLOBAL_BUTTON_LOCK=1<
2017.03.03 22:52:37 1 : HMCCU: Invalid parameter or value
2017.03.03 22:52:37 1 : HMCCUDEV: FlurThermostat Execution of CCU script or command failed
2017.03.03 22:52:37 4 : name: /fhem&detail=FlurThermostat&fwcsrf=fhem_222963384671245&dev.setFlurThermostat=FlurThermostat&cmd.setFlurThermostat=set&arg.setFlurThermostat=config&val.setFlurThermostat=0+GLOBAL_BUTTON_LOCK%3D1 / RL:1474 / text/html; charset=UTF-8 / Content-Encoding: gzip /
2017.03.03 22:52:37 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.03 22:52:37 2 : HMCCU: UpdateClientReading device=FlurThermostat, devadd=000397098A3254, chnadd=000397098A3254:0, dpt=CONFIG_PENDING, value=1
2017.03.03 22:52:37 2 : HMCCU: rm=0, r=(PARTY), dpt=CONFIG_PENDING
2017.03.03 22:52:37 2 : HMCCU: Check 0 = 1 AND CONFIG_PENDING = (PARTY) OR 0 = 0 AND CONFIG_PENDING = (PARTY)
2017.03.03 22:52:37 2 : HMCCU: Check negative
2017.03.03 22:52:37 2 : HMCCU: rm = 0 ? 0 : 1
2017.03.03 22:52:37 2 : HMCCU: UpdateClientReading device=FlurThermostat, readings=0.CONFIG_PENDING, orgvalue=1 value=1
2017.03.03 22:52:37 5 : Cmd: >get FlurThermostat configlist 0 LOCK<
2017.03.03 22:52:37 2 : HMCCU: GetAttrSubstitute: subst = SET_POINT_TEMPERATURE!#0-4.5:off,#30.5-40:on;WINDOW_STATE!(0|false):closed,(1|true):open;SET_POINT_MODE!(0):Auto,(1):Manual
2017.03.03 22:52:37 3 : get FlurThermostat configlist 0 LOCK : GLOBAL_BUTTON_LOCK=1
2017.03.03 22:52:37 5 : Starting notify loop for FlurThermostat, 3 event(s), first is 0.CONFIG_PENDING: 1
2017.03.03 22:52:37 5 : createNotifyHash
2017.03.03 22:52:38 5 : testBattStatus: not on any display, ignoring notify
2017-03-03 22:52:38 HMCCUDEV FlurThermostat 0.CONFIG_PENDING: 1
2017-03-03 22:52:38 HMCCUDEV FlurThermostat hmstate: 17.0
2017-03-03 22:52:38 HMCCUDEV FlurThermostat Gesperrt: GLOBAL_BUTTON_LOCK=1
2017.03.03 22:52:38 5 : End notify loop for FlurThermostat Im übrigen bleibt auch alles andere identisch

Code Auswählen Erweitern

LOG aus messages:
Mar  3 22:53:50 homematic-ccu2 local0.err ReGaHss: Error: IseESP::ExecError= Execution failed: [-1] 0 0x00 [0] 144 0x90 [1] 0 0x00 [2] 9 0x09 [3] 0 0x00 [4] 28 0x1c  [../Platform/DOM/iseESPexec.cpp (11622)]
Mar  3 22:53:50 homematic-ccu2 local0.err ReGaHss: Error: IseESP::ExecError= Execution failed: [-1] 0 0x00 [0] 144 0x90 [1] 0 0x00 [2] 9 0x09 [3] 0 0x00 [4] 28 0x1c  [../Platform/DOM/iseESPexec.cpp (11622)]

Für mich die Verständnisfrage, das Attribut ccuflags=trace sollte doch lediglich das LOG verändern, oder?

[zap]

Das Tracing ist aktiv (sehe ich an den Details bei der Log Ausgabe). Allerdings ist das nicht die korrekte Version von 88_HMCCU.pm. Sonst müsste die Ausgabe etwas anders aussehen. Kannst Du bitte nochmal updaten und FHEM neu starten?

Du könntest auch mal versuchen, irgendeinen anderen Config Parameter zu setzen. Möglichst einen, der einen nummerischen Wert erfordert. Bei Bool Werten weiß man nie so genau, ob jetzt false/true oder 0/1 erforderloch ist.
Dann kann man das Problem ggf. auf GLOBAL_LOCK eingrenzen.