Neues Modul HMCCU für Homematic CCU

[zap]

Ich habe ein Homematic Thermostat HM-CC-RT-DN als HMCCUDEV eingebunden, hier tauchen die beiden nachfolgenden Probleme bei mir auf:

1.

Code Auswählen Erweitern

ccureadingname 4.BATTERY_STATE:Batterygreift bei mir nicht. Das Reading 4.BATTERY_STATE wird nicht ersetzt. Leider weiß ich nicht, was ich falsch mache.

Der Datenpunkt BATTERY_STATE muss auch im Attribut ccureadingfilter drin sein. Nach Deinen Angaben unten ist er das nicht..

2.

Code Auswählen Erweitern

ccureadingfilter (^UNREACH|LOWBAT|TEMPERATURE|VALVE_STATE|CONTROL)trotz dieses defaults Attributs werden Readings wie z.B. R-ENDTIME_FRIDAY ausgegeben. Auch hier die gleiche Frage, wieso wird dies mit ausgegeben bzw. was mache ich falsch?

Der ccureadingfilter bezieht sich nur auf die Datenpunkte. Alle Readings, die mit "R-" beginnen, sind aber Config-Parameter, die mit dem Befehl "get config" ausgelesen wurden. Bei diesem Befehl kann man einen regulären Ausdruck angeben, der die gelesenen Parameter (und damit die "R-" Readings) einschränkt.

Daher löse ich das Problem indem ich

Code Auswählen Erweitern

touch /var/status/hasInternet auf der CCU2 ausführe. Und nun meine Fragen. Kann ich den vorgenannten Befehl auch über das HMCCU-Modul absetzen. Oder wisst ihr, wie ich die Datei eQ3StartNetwork so editieren kann, dass ich die überprüfte IP-Adresse ersetzen kann (hier gegen die IP-Adresse meines Routers).

Die Ausführung von Linux Befehlen auf der CCU wird von HMCCU nicht unterstützt. Du kannst es Dir aber selbst bauen, z.B. per SSH:

- Key ohne Passphrase generieren
- Key auf der CCU für den User root hinterlegen
- Auf FHEM Seite eine Shell-Script erzeugen, dass per SSH unter Verwendung des o.g. Keys auf der CCU den gewünschten Befehl ausführt.

Um das Shellscript aus FHEM anzustoßen, gibt es viele Möglichkeiten unter FHEM.

Oder Du versuchst, die eigentliche Fehlerursache zu eliminieren. Bei mir geht die LED aus, sobald die Inet-Verbindung steht.

[chris1284]

hi zap, hast du evtl hierfür schon was in planung oder einen workaround?
https://forum.fhem.de/index.php/topic,64064.0.html

[Mundus]

Hallo,

Der Datenpunkt BATTERY_STATE muss auch im Attribut ccureadingfilter drin sein. Nach Deinen Angaben unten ist er das nicht.

Das war der Ansatzpunkt der mir fehlte. Nachdem ich

Code Auswählen Erweitern

deleteReading KuecheThermostat .*ausgeführt habe, sind alle (wie auch immer von mir zugefügten Readings) verschwunden. Anschließend wurden noch die Readings angezeigt, die im ccureadingfilter genannt waren. Dort habe ich BATTERY angefügt und prompt griff meine Ersetzung im ccureadingname. Gibt es eigentlich eine schönere Variante als deleteReading um die Readings von HMCCUDEV's zurückzusetzen?

Außerdem wird hier eine Doku zu HMCCU erwähnt, die ich leider nicht finde. Existiert neben den WIKI Einträgen und der COMMANDREF noch eine weitere Dokumentation?

Das Problem bzw. der Fehler mit der CCU2 ist bei mir kein Fehler, da meine CCU2 nicht ins Internet soll (Diesen Zustand möchte ich auch gerne beibehalten). Daher habe ich ein Workaround gesucht, wie ich die blinkende LED (das nervt ziemlich) dauerhaft anschalte. Ich werde mir also den Hinweis   

Die Ausführung von Linux Befehlen auf der CCU wird von HMCCU nicht unterstützt. Du kannst es Dir aber selbst bauen, z.B. per SSH:

- Key ohne Passphrase generieren
- Key auf der CCU für den User root hinterlegen
- Auf FHEM Seite eine Shell-Script erzeugen, dass per SSH unter Verwendung des o.g. Keys auf der CCU den gewünschten Befehl ausführt.

Um das Shellscript aus FHEM anzustoßen, gibt es viele Möglichkeiten unter FHEM.

mal genauer ansehen bzw. mich einlesen.

Abschließend vielen Dank für eure Hilfe

[zap]

 Mit dem Befehl "Set clear" kann man Readings löschen. Der Unterschied zu deleterding ist allerdings marginal.

Als Doku gibt es "nur" die Commandref und die Wiki Artikel. Was fehlt Dir denn?

[Mundus]

Als Doku gibt es "nur" die Commandref und die Wiki Artikel. Was fehlt Dir denn?

Mir fehlt nichts, ich wollte nur wissen, ob es weitere Beschreibungen gibt, die ich übersehen habe.

[zentis666]

Hallo!
Ich habe ein Problem mit dem HMCCU Modul und einem CCU Gruppendevice.
Ich hab mich an die Config in  https://forum.fhem.de/index.php/topic,51339.msg499371.html#msg499371 angelehnt.
Wenn ich die Temperatur per Slider setze friert fhem komplett ein, per Weboberfläche und per telnet nicht mehr erreichbar.
Auch ein service fhem restart führt nicht zum Erfolg.
Ich muss meinen NUC neu booten damit ich überhaupt wieder auf fhem komme.

Im Log steht nach dem Einfrieren:
Undefined subroutine &main::usleep called at ./FHEM/88_HMCCU.pm line 3833.

Definition des Device:

Code Auswählen Erweitern

IODev hm_ccu
ccureadingfilter (^SET_TEMPERATURE|^TEMPERATURE|^HUMIDITY|LOWBAT|^VALVE|^CONTROL|^WINDOW_OPEN)
ccureadingformat name
ccuverify 1
cmdIcon Auto:sani_heating_automatic Manu:sani_heating_manual Boost:sani_heating_boost on:general_an off:general_aus
controldatapoint 1.SET_TEMPERATURE
event-on-change-reading .*
eventMap /datapoint 1.MANU_MODE 20.0:Manu/datapoint 1.AUTO_MODE 1:Auto/datapoint 1.BOOST_MODE 1:Boost/datapoint 1.MANU_MODE 4.5:off/datapoint 1.MANU_MODE 30.5:on/
room 2.10:Arbeitszimmer,Homematic
stateFormat
T: HM-TC-IT-2OG_AZ.1.TEMPERATURE° H: HM-TC-IT-2OG_AZ.1.HUMIDITY% D: HM-TC-IT-2OG_AZ.2.SET_TEMPERATURE° P: DEWPOINT° V: HM-CC-RT-2OG_AZ.4.VALVE_STATE% HM-TC-IT-2OG_AZ.2.CONTROL_MODE
statechannel 1
statedatapoint 1.SET_TEMPERATURE
stripnumber 1
substitute LOWBAT!(0|false):no,(1|true):yes;CONTROL_MODE!0:AUTO,1:MANU,2:PARTY,3:BOOST;WINDOW_OPEN_REPORTING!(true|1):open,(false|0):closed
userReadings DEWPOINT {HMCCU_Dewpoint($name,"HM-TC-IT-2OG_AZ.1.TEMPERATURE", "HM-TC-IT-2OG_AZ.1.HUMIDITY","n/a")}, LOWBAT_STATE:(HM-TC-IT-2OG_AZ.0.LOWBAT|HM-CC-RT-2OG_AZ.0.LOWBAT) {HMCCU_AggReadings($name, "HM-CC.*LOWBAT","and","no","yes")}, LOWBAT_COUNT:(HM-TC-IT-2OG_AZ.0.LOWBAT|HM-CC-RT-2OG_AZ.0.LOWBAT) {HMCCU_AggReadings($name, "HM-CC.*LOWBAT","cnt","yes","")}
webCmd control:Auto:Manu:Boost:on:off
widgetOverride control:slider,10,1,25

Readings:

Code Auswählen Erweitern

DEWPOINT 7.3
G_HZ_2OG_AZ.0.LOWBAT no
G_HZ_2OG_AZ_INT0000001.1.CONTROL_MODE AUTO
G_HZ_2OG_AZ_INT0000001.1.SET_TEMPERATURE 21.0
HM-CC-RT-2OG_AZ.0.LOWBAT no
HM-CC-RT-2OG_AZ.4.CONTROL_MODE AUTO
HM-CC-RT-2OG_AZ.4.SET_TEMPERATURE 21.0
HM-CC-RT-2OG_AZ.4.VALVE_STATE 6
HM-TC-IT-2OG_AZ.0.LOWBAT no
HM-TC-IT-2OG_AZ.1.HUMIDITY 41
HM-TC-IT-2OG_AZ.1.TEMPERATURE 21.1
HM-TC-IT-2OG_AZ.2.CONTROL_MODE AUTO
HM-TC-IT-2OG_AZ.2.LOWBAT_REPORTING false
HM-TC-IT-2OG_AZ.2.SET_TEMPERATURE 21.0
HM-TC-IT-2OG_AZ.2.WINDOW_OPEN_REPORTING closed
control 21.0
state 21.0

Fehler im Modul oder bei mir?

Gruß
Sven

[zap]

In Deiner Perl Installation fehlt usleep() aus dem Modul Timer::Hires. Bei vielen Installationen ist das dabei.

Abhilfe ist einfach: Lösche das Attribut "ccuverify". Dann wird usleep() nicht mehr aufgerufen. Alternativ kannst Du Timer::HiRes per CPAN oder als Paket installieren. ccuverify ist aber in den wenigsten Fällen notwendig.

[zentis666]

Hi zap,

danke für die Erklärung, funktioniert bei mir leider noch nicht wie beschrieben

In Deiner Perl Installation fehlt usleep() aus dem Modul Timer::Hires. Bei vielen Installationen ist das dabei.

Abhilfe ist einfach: Lösche das Attribut "ccuverify". Dann wird usleep() nicht mehr aufgerufen. Alternativ kannst Du Timer::HiRes per CPAN oder als Paket installieren. ccuverify ist aber in den wenigsten Fällen notwendig.

Ich hab HiRes per CPAN installiert:

Code Auswählen Erweitern

cpan
cpan> install Bundle::CPAN
cpan> reload cpan
cpan> install Time::HiRes
cpan> exit

Habe dann sicherheitshalber fhem mal neu gestartet.
Der Fehler ist immer noch da.

Das Paket libdatetime-perl war übrigens vorher schon installiert.
Mein System ist ein NUC mit Debian (8.6).

Ich hab ccuverify erstmal abgeschaltet was das Problem ja erstmal nur umgeht.
Was kann ich tun um das Perl Problem zu lösen?

Danke und Gruß
Sven

[zap]

Komischerweise ist aus dem Modul 88_HMCCU.pm das Statement verschwunden, mit dem Timer::HiRes eingebunden wird. Deine Installation hat daher keinen Effekt. Ich habe das vermutlich irgendwann mal entfernt, warum auch immer.

In der nächsten Version ist es wieder drin und Du kannst dann das Attribut wieder benutzen.

Die 3.7 ist gerade im Test bei mir. Wenn keine größeren Bugs mehr auftreten, werde ich es in den nächsten Tagen einchecken.

[zentis666]

Ok dann liegt es nicht an meiner Installation.
Danke fürs nachschauen dann freu ich mich aufs Update 

Gruß
Sven

[zap]

Hat jemand schon mal Sirenen (HM-Sec-Sir-WM) mit diesem Modul angebunden und gesteuert?

Hier mal einige Attribute, die hilfreich sein könnten. Da ich keine Sirene habe, kann ich das alles nicht testen.

ccureadingfilter = (STATE|ERROR)
ccureadingname = 1.STATE:STATE_SENSOR1,2.STATE:STATE_SENSOR2,3.STATE:STATE_PANIC
eventMap = /datapoint 3.STATE true:panic/
statedatapoint = 4.ARMSTATE
statevals = disarmed:0,extsens-armed:1,allsens-armed:2,alarm-blocked:3
substitute = ERROR_SABOTAGE!(0|false):no,(1|true):yes;ARMSTATE!0:disarmed,1:extsens_armed,2:allsens_armed,3:alarm_blocked

Damit bekommst Du zusätzliche Set-Befehle:

set panic
set disarmed
set extsens-armed
set allsend-armed
set alarm-blocked

Wenn Du on-for-timer oder on-till nutzen möchtest, solltest Du statevals wie folgt setzen:

statevals = off:0,extsens-armed:1,on:2,alarm-blocked:3

Hintergrund: die Timerbefehle funktionieren nur, wenn "on" existiert.

[rubinho]

@ZAP

Ich hab ne Frage zu den Thermostaten (HM-CC-RT-DN, HM-TC-IT-WM-W-EU).
Gibt es eine Möglichkeit über Fhem die Modis btnLock, globalBtnLock und modusBtnLock über HMCCU zu senden ?
Ich hab da so zwei Stinker, nennen wir sie mal Kinder und die drehen gerne mal Nachts zur Schlafenszeit die Temperatur hoch.
Das will ich verhindern und ihnen Nachts das Thermostat sperren. Momentan klappt das über HMLAN, jedoch will ich irgendwann komplett auf HMCCU umsteigen.

Gruß
Rubinho

[chris1284]

in der konfig gibts zumindest MODUS_BUTTON_LOCK=0 , in der deviceinfo taucht aber kein writeable datapoint auf.
per cul_hm gehts

EDIT: Antowrt aus HM -Forum

das geht mit dem setParam.tcl-Script, min. BUTTON_LOCK boolean 0 MODUS_BUTTON_LOCK boolean 0 kann man damit setzen und aufheben...

[rubinho]

@chris1284

Ja, das der datapoint fehlt ist mir auch aufgefallen (deswegen die Frage) vielleicht wurde das auf Modulseite (HMCCU) nur nicht implementiert.
Blöd wäre es, wenn das rpc die Modis einfach nicht hat.

[rubinho]

So ich hab mittlerweile herausgefunden, dass man zumindest mit dem Befehl

Code Auswählen Erweitern

get <device> config GLOBAL_BUTTON_LOCK den Wert angezeigt bekommt.
Eigendlich bin ich davon ausgegangen, dass mit dem Befehl

Code Auswählen Erweitern

set <device> config GLOBAL_BUTTON_LOCK=1 den Modus auch auf dem Gerät setzen kann, doch dass will nicht gehen.
Der Befehl wird zwar ohne murren abgesetzt, jedoch wird das HM Device nicht geändert :/

Hat noch jemand eine Idee ?