Neues Modul HMCCU für Homematic CCU

[zap]

RPCState ist ein Internal. Du musst stateFormat wie folgt setzen:

{ $defs{$name}{RPCState} }

[cho]

Danke!

[ToM_ToM]

Hallo Zusammen,

irgendwie geht nachdem ich meinen Pi heute neugestartet habe, auch der RPC-Server nicht wenn beide Ports angegeben sind.
Das muss doch irgendein anderes Problem sein. Werde die CCU wohl später wieder neu starten müssen.

Aber mal eine andere Frage. Ist es möglich dass die Config die ganzen mühevoll angelegten Devices auch nach einem Neustart behält und ich die nicht alle wieder neu hinzufügen muss?
Zum Glück habe ich gestern ein Backup meiner alten Config gemacht.

Viele Grüße und schon Mal ein frohes Osterfest vorab, Thomas

[zap]

Mein Problem ist, dass ich dieses Verhalten überhaupt nicht nachvollziehen kann. Egal, ob ich einen oder zwei Ports angebe, es wird immer alles korrekt gestartet, auch bei einem Reboot. Von anderen Usern weiß ich, dass es bei ihnen auch läuft.

Und was meinst Du mit Speichern? Man legt die Devices in FHEM an und speichert mit Save. Allerdings: wenn beim Starten von FHEM das HMCCU IO-Device nicht angelegt werden kann, werden auch die Client Devices nicht angelegt. In dem Fall sollten aber einige Fehlermeldungen im FheM Log stehen. In der Oberfläche fehlen dann die Devices.

Die Definitionen sind aber trotzdem noch in fhem.cfg vorhanden. Du darfst nur nicht den Fehler machen, Save zu drücken. Dann wird der fehlerhafte Zustand in fhem.cfg gespeichert und alles ist weg.

Wenn Du die CCU neu startest geht alles wieder? Seltsam.

Du hast nicht noch eines der anderen HM RPC Module gleichzeitig aktiv? Das geht auf keinen Fall.

Verwendest Du auch die aktuelle Version von ccurpcd.pl? Einige Funktionen sind von dort in 88_HMCCU.pm gewandert.

[cho]

Hallo zap,

ich versuche gerade, Gruppen einzurichten. Aber ich blicke es leider nicht.

Auf der CCU2 habe ich z.B. eine Gruppe INT0000001 eingerichtet, zu der ein Wandthermostat (HM-TC-IT-WM-W-EU_aaa), zwei Heizkörperthermostate (HM-CC-RT-DN_bbb und HM-CC-RT-DN_ccc) und ein Fensterkontakt (HM-Sec-SCo_ddd) gehören.

Auf der CCU2 habe ich auf diese Gruppen datumsabhängig Wochenprogramme per TCL Skript so eingespielt

> xmlrpc http://127.0.0.1:9292/groups putParamset [list string INT0000001] [list string "MASTER"] [list struct {P1_ENDTIME_SATURDAY_1} {int 1440}} {P1_TEMPERATURE_SATURDAY_1 {string 18.0}}]

(vereinfachtes Beispiel für einen Wochentag)
Diese würde ich jetzt gerne auf Fhem und HMCCU übertragen.

Die Gruppe lege ich dann in Fhem so an

> define GR_INT0000001 HMCCUDEV INT0000001 group=HM-TC-IT-WM-W-EU_aaa,HM-CC-RT-DN_bbb,HM-CC-RT-DN_ccc,HM-Sec-SCo_ddd

Wenn ich danach dann

> set GR_INT0000001 config P1_ENDTIME_SATURDAY_1=1440 P1_TEMPERATURE_SATURDAY_1=18.0

ausführe, bekomme ich aber diese Fehlermeldung im WebUI

> HMCCUDEV: GR_INT0000001 Execution of CCU script or command failed

und diese Einträge im fhem log

> 2016.03.26 23:11:46 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/88_HMCCU.pm line 2939.
> 2016.03.26 23:11:46 1: HMCCUDEV: GR_INT0000001 Execution of CCU script or command failed

Ich denke mal, ich mache nur einen Anfängerfehler.
Aber wie geht es richtig?

Viele Grüße
Christian
[/list][/list][/list]

[zap]

Es gibt nur wenige MASTER Parameter, die direkt im Device liegen. Bei den meisten muss man nach "config" im set Befehl noch eine Kanalnummer angeben.

Aber: das scheint nicht das einzige Problem zu sein. Der Fehler im Log bedeutet, dass die grundlegende URL für die Verbindung zur CCU nicht richtig zusammen gebaut wird. In dem Fall wird der Befehl nie funktionieren. Hast Du im HMCCU Device ein Internal "host" mit dem Namen der CCU?

Aber bevor Du jetzt hier ne Menge Zeit investierst, lass mich das heute abend mal testen. Ich habe das Thema Config Parameter (v.a. die Temperaturen und Zeiten bei Themostaten) bisher etwas vernachlässigt, da ich das immer direkt in der CCU einstelle und dann maximal noch das Wochenprogramm per FHEM auswähle.

[cho]

Ja, hab ich:

Internals
Clients :HMCCUDEV:HMCCUCHN:
DEF homematic.fritz.box
DelDevices 0
DevCount 134
NAME CCU2
NR 33
NewDevices 0
RPCPID 714,719
RPCPRC ./FHEM/ccurpcd.pl
RPCState running
STATE running
TYPE HMCCU
host homematic.fritz.box

Attributes
ccureadings 0 
group Zentrale
room 1 HomeMatic
rpcport 2010,2001
rpcqueue /opt/fhem/tmp/ccuqueue
rpcserver on
stateFormat { $defs{$name}{RPCState} }
updatemode both

[zap]

Gerade nochmal kurz  remote getestet und dabei mein FHEM abgeschossen. Da ist wohl ein größerer Bug drin. Erst mal bitte nicht mehr testen. Muss das heute Abend mal analysieren ...

Grundsätzlich: Es ist denkbar, dass das Setzen und Lesen von Config Parametern bei Gruppen gar nicht geht, da die RPC-Schicht der CCU gar keine Gruppen kennt. Die gibt es nur in der Logik-Schicht. In dem Fall müsste man die Parameter über das Wand-Thermostat (sofern vorhanden) oder das Heizkörper-Thermostat setzen. Wenn es ein Wand-Thermostat in einer Gruppe gibt, ist das der Master, d.h. gibt die Werte für die Gruppe vor.

UPDATE: Morgen gibt es eine neue Version mit funktionierendem set/get config.

[zap]

Ich habe die Version 3.1 der Module eingecheckt (Link siehe 1. Beitrag). Bitte unbedingt alle Dateien 88_HMCCU* sowie ccurpcd.pl updaten!

Änderungen:

Queue-Files

Die Queue-Files werden nun mit der Berechtigung 0666 (-rw-rw-rw-) angelegt.

Statusanzeige RPC-Server

Im HMCCU-Device wird der Status des RPC-Servers nun auch im Reading "rpcstate" angezeigt. Um diesen Status in STATE zu übernehmen, kann das Attribut "stateFormat" auf "rpcstate" gesetzt werden.

Start RPC Server:

Der RPC Server wird nicht mehr über "attr rpcserver" gestartet. Dazu gibt es nun in HMCCU den Befehl "set rpcserver on/off". Das Attribut rpcserver dient nur noch dazu festzulegen, ob der RPC Server beim Starten von FHEM automatisch gestartet wird.
Beim Starten von FHEM wird der RPC Server erst gestartet, wenn FHEM den globalen Event "INITIALIZED" triggert. Das könnte dazu beitragen, dass die Startprobleme bei einigen Benutzern behoben werden.

Setzen von Config-Parametern:

Das Setzen von Config-Parametern sollte nun funktionieren. Folgendes Beispiel setzt 3 Zeitintervalle für ein Wandthermostat. Das Thermostat ist als HMCCUDEV Device mit dem Namen HM_KL_SZ angelegt:

set HM_KL_SZ P1_ENDTIME_SATURDAY_1=420 P1_ENDTIME_SATURDAY_2=1260 P1_ENDTIME_SATURDAY_3=1440

Beim Setzen der Zeiten für ein Thermostat sollte immer ein kompletter Tag definiert werden.

Wichtig zu wissen für das Setzen und Lesen von Config-Parametern:

• Wenn beim Setzen ein nicht existierender Parameter angegeben wird, ignoriert die CCU diesen und gibt keine Fehlermeldung zurück
• Die RPC-Schnittstelle unterstützt keine Homematic Gruppen-Geräte (Adresse INT...), da diese in der Logikschicht der CCU abgebildet werden. Wenn z.B. Zeiten oder Temperaturen einer Heizungsgruppe gesetzt werden sollen, muss das Wandthermostat verwendet werden (oder das Heizkörperthermostat, falls kein Wandthermostat vorhanden ist).
• Nicht alle Geräte unterstützen das Auslesen der Parameter-Beschreibung mit "get configdesc" (z.B. die Wandthermostate bieten diesen Funktion nicht an).

Sonstiges

Die Warnung "experimental::smartmatch" sollte nun nicht mehr im Log auftauchen.

[cho]

Hallo zap,

vielen Dank für das Update!
Der RPC Server startet bei mir jetzt - auch wenn ich nur Port 2001 angebe.
Und das setzen der Statusanzeige ist so auch viel einfacher.

Ich bekomme beim Booten allerdings immernoch diese Warnungen im fhem log:

Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1176, <$fh> line 52.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1176, <$fh> line 52.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2758, <$fh> line 52.
Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 2758, <$fh> line 52.

Das Setzen der Config Parameter funktioniert bei mir jetzt auch.
Schade, dass das nur für die Geräte selber funktioniert, nicht aber für Gruppen.
Wie gesagt, auf der CCU2 funktioniert es via TCL Skript auch bei Gruppen:

load tclrpc.so
xmlrpc http://127.0.0.1:9292/groups putParamset [list string INT0000001] [list string "MASTER"] [list struct {P1_ENDTIME_SATURDAY_1} {int 1440}} {P1_TEMPERATURE_SATURDAY_1 {string 18.0}}]

Aber das scheint dann ja leider über eine andere RPC Schnittstelle zu laufen?

Ich habe die Wochenprogramme bisher immer auf Gruppenebene gesetzt. Die Gruppe hat die Einstellungen dann vererbt: Gruppe -> Wandthermostat, Wandthermostat -> Heizkörper Thermostat bzw. Gruppe -> Heizkörper Thermostat.
Ich frage mich gerade, was passiert, wenn ich die Wochenprogramme nur noch an die Wandthermostat und Heizkörper Thermostate übertrage. Die Gruppen (mit dann abweichenden Wochenprogrammen) bleiben ja bestehen. Nicht, daß die Gruppen dann meine neu übertragenen Wochenprogramme auf den Geräten wieder überschreiben. Das muss ich jetzt erst einmal testen und beobachten.

Viele Grüße
Christian

[/list][/list][/list]

[zap]

Schön, dass es nun läuft. Möglicherweise hattest Du beim letzten Mal den RPC-Server ccurpcd.pl nicht mit aktualisiert(?). Aber egal. Würde mich interessieren, ob auch bei ToM_ToM das jetzt rund läuft.

Ich bekomme beim Booten allerdings immernoch diese Warnungen im fhem log:

Smartmatch is experimental at ./FHEM/88_HMCCU.pm line 1176, <$fh> line 52.

Ich hatte gestern Abend nochmal ein Update von 88_HMCCU.pm nachgeschoben. Kannst Du bitte prüfen, ob am Anfang der Datei (nach dem Kommentar-Header) folgende Zeile vorhanden ist:

Code Auswählen Erweitern


no if $] >= 5.017011, warnings => 'experimental::smartmatch';


Schade, dass das nur für die Geräte selber funktioniert, nicht aber für Gruppen.
Wie gesagt, auf der CCU2 funktioniert es via TCL Skript auch bei Gruppen:

load tclrpc.so
xmlrpc http://127.0.0.1:9292/groups putParamset [list string INT0000001] [list string "MASTER"] [list struct {P1_ENDTIME_SATURDAY_1} {int 1440}} {P1_TEMPERATURE_SATURDAY_1 {string 18.0}}]

Aber das scheint dann ja leider über eine andere RPC Schnittstelle zu laufen?

Definitiv, die CCU schickt auch keine Aktualisierungen für Gruppen an den RPC-Server. Ist die Datei "xmlrpc" standardmäßig auf der CCU vorhanden? Dann schaue ich mir das mal an.

Ich frage mich gerade, was passiert, wenn ich die Wochenprogramme nur noch an die Wandthermostat und Heizkörper Thermostate übertrage. Die Gruppen (mit dann abweichenden Wochenprogrammen) bleiben ja bestehen. Nicht, daß die Gruppen dann meine neu übertragenen Wochenprogramme auf den Geräten wieder überschreiben. Das muss ich jetzt erst einmal testen und beobachten.

Wenn ein Wandthermostat in der Gruppe ist und man ändert Parameter des Wandthermostats, ändern sich auch die Gruppen-Parameter. Ich verstehe das so, dass eine Gruppe keine eigenen Parameter hat sondern die des Wandthermostats bzw. des Heizkörperthermostats verwendet und darstellt. Für diese Theorie spricht auch, dass die Meldung kommt "Daten werden an das Gerät übertragen" sobald man im CCU WebUI einen Gruppenparameter ändert.

P.S. wo kommt eigentlich dieses "list, list, list" am Ende des Beotrags her. Ich bekomme das nicht weg.
[/list][/list][/list]

[ToM_ToM]

Hallo Zusammen,

bei mir läuft es jetzt seit einigen Tagen wunderbar, weshalb ich mich kaum traue, zu aktualisieren.
Da ich das Ganze bei meinen Eltern eingerichtet habe, morgen wieder abreise und nur ca. alle 5 Monate dazu komme daran weiterzubasteln, bin ich gerade froh dass es so gut läuft.
Ich kann die Heizungsthermostate schalten, Klimasensoren abfragen... - alles wunderbar.

Hier übrigens ein Beispiel für nen Klimasensor:

Code Auswählen Erweitern

define HM_DB_Klimasensor HMCCUDEV LEQXXXXXXXX 1
attr HM_DB_Klimasensor IODev CCU2
attr HM_DB_Klimasensor ccureadingfilter (LOWBAT|HUMIDITY|TEMPERATURE|CONTROL)
attr HM_DB_Klimasensor ccureadingformat name
attr HM_DB_Klimasensor event-on-change-reading .*
attr HM_DB_Klimasensor statechannel 1
attr HM_DB_Klimasensor stripnumber 1
attr HM_DB_Klimasensor substitute LOWBAT!(0|false):no,(1|true):yes

VG, Thomas

[zap]

In dem Fall würde ich vielleicht auch nach dem Prinzip "never touch a running system" verfahren. Das Setzen von Config-Parametern (z.B. Heizzeiten) wird mit der alten Version aber nicht funktionieren. Da ist ein Bug drin.

P.S. Schon mal über einen VPN-Tunnel zwecks Remote-Zugriff nachgedacht?

[ToM_ToM]

Hallo zap,

VPN ist an sich kein Thema, allerdings müsste ich das Tablet dann auch über VPN konfigurieren. Und soweit ich weiß, geht das per TeamViewer nur mit der kommerziellen Version.
Naja ich habe auch mit meinem System daheim schon genug Arbeit.
Heizdaten an sich setze ich aktuell nicht. von daher passt es.

Kennst du diese Lautsprecher von Homematic die man in die Steckdose steckt und die dann mp3-files von einer darin enthaltenen SD-Karte abspielen?
Mich würde noch interessieren wie man so ein Gerät anspricht.
Aber das mache ich dann beim nächsten Mal.

Habe es übrigens jetzt doch mal gewagt das Update durchzuführen und bisher läuft es super.
Kann nur sagen, super Arbeit von dir.

VG, Thomas

[cho]

Hallo zap,

ob ich beim letzten mal vergessen hatte, die ccurpcd.pl zu aktualisieren, kann ich nicht mehr überprüfen. Ich glaube es aber eigentlich nicht. Wie auch immer, jetzt funktioniert es ja.

Ich habe gerade auch noch einmal nachgesehen. Ich habe Dein letztes Update 3.1 mit der 88_HMCCU.pm mit der Zeile "no if..." laufen. Sind die Warnungen eigentlich problematisch?

Die Datei "xmlrpc" ist standardmäßig auf der CCU vorhanden. Ich weiß dazu auch nur, dass auf der CCU2 für Gruppen ein eigener XML-RPC-Server mit der Adresse http://127.0.0.1:9292/groups läuft. Die Info findet man in verschieden Foren Beiträgen, z.B. hier:

http://homematic-forum.de/forum/viewtopic.php?f=26&t=20875#p189304

P.S. Wo das "list, list, list" herkommt, kann ich Dir leider auch nicht sagen. Es war nach dem Speichern ("Schreiben") einfach da und ließ sich über "Ändern" auch nicht wieder löschen?

Viele Grüße
Christian