HMCCU Version 4.0 mit CUxD Unterstützung released

[zap]

Ich habe gerade neue Versionen aller Module eingecheckt.

Wichtigste Neuerung: Der externe RPC Server (Modul HMCCURPC) unterstützt nun vollumfänglich CUxD Devices der CCU2, d.h. auch die automatische Aktualisierung der Readings.

Zur Aktivierung muss im I/O Device das Attribut rpcinterface um CUxD ergänzt werden. Zusätzlich muss im I/O Device das Attribut ccuflags auf extrpc gesetzt werden, damit HMCCURPC verwendet wird. Vorher den RPC Server stoppen und danach wieder starten.

Eine weitere Neuerung: HMCCU aktiviert nur die RPC-Schnittstellen, für die auch Devices in der CCU vorhanden sind.

Ich empfehle wenn möglich den externen RPC Server zu verwenden, da die Reaktionszeit wesentlich kürzer ist (bei ca. 50 ms).

Nachteil des externen RPC-Servers: Leider wird der Speicher beim Stoppen des Servers nicht komplett frei gegeben. Wenn man also häufig den RPC-Server stoppt und wieder startet ohne FHEM neu zu starten, läuft irgendwann der Speicher voll.

Natürlich kann man nun auch das System.exec Device von CUxD nutzen, um z.B. Linux Befehle bzw Shell-Scripts auf der CCU auszuführen. Beispiel:

Code Auswählen Erweitern


define myccuexec HMCCUCHN 1234567:1

Set myccuexec datapoint CMD_EXEC ""pfad_zu_meinem_script""


Die 2 doppelten " am Anfang und Ende müssen so angegeben werden. Damit kann man zB auch die CCU neu starten.

[Chris8888]

Hallo Zap,

danke! Eben installiert. Mein Problem mit dem Disconnect bei Ext. Server bleibt leider.
Bei dem int. Server läuft alles wie gewohnt.

Beim Start kommt allerdings im Log folgende Fehlermeldung "HMCCU: HMCCU_QueueDeq seperator not found" so knapp 30x.
Aber es läuft wie gewohnt, der Fehlereintrag kommt danach auch nicht mehr.

Danke für deine unermüdliche Arbeit an der "Brücke"!

Viele Grüße
Christian

[Patrick131184]

Danke Zap.
Darauf habe ich schon gewartet.

Leider bekomme ich den RPC Server nicht gestartet wenn ich das Attribute ccuflags auf "extrpc" stelle.


Config:

Code Auswählen Erweitern

define d_ccu HMCCU 192.168.0.24
attr d_ccu ccuflags extrpc
attr d_ccu room hidden
attr d_ccu rpcinterfaces BidCos-RF,CUxD,HmIP-RF,VirtualDevices
attr d_ccu rpcinterval 5
attr d_ccu rpcport 2001,8701,2010,9292
attr d_ccu rpcserver on
attr d_ccu stateFormat rpcstate/state

Hier ein Auszug aus den Logs:

Code Auswählen Erweitern

2017.04.12 09:18:01 1: HMCCURPC: Received SL event. RPC server DATA enters server loop
2017.04.12 09:18:01 1: HMCCURPC: Received SL event. RPC server CB2001 enters server loop
2017.04.12 09:18:01 1: HMCCURPC: Received SL event. RPC server CB8701 enters server loop
2017.04.12 09:18:01 1: HMCCURPC: Received SL event. RPC server CB9292 enters server loop
2017.04.12 09:18:01 1: HMCCURPC: All threads working
2017.04.12 09:18:01 1: HMCCURPC: Registering callback http://192.168.0.12:7411/fh2001 with ID CB2001 at http://192.168.0.24:2001/
2017.04.12 09:18:01 1: CCURPC: CB2001 ListDevices. Sending init to HMCCU
2017.04.12 09:18:01 1: HMCCURPC: RPC callback with URL http://192.168.0.12:7411/fh2001 registered
2017.04.12 09:18:01 1: HMCCURPC: Registering callback xmlrpc_bin://192.168.0.12:14111 with ID CB8701 at http://192.168.0.24:8701/
2017.04.12 09:18:02 2: CCURPC: CB2001 NewDevice received 165 device specifications
2017.04.12 09:18:03 1: HMCCURPC: RPC callback with URL xmlrpc_bin://192.168.0.12:14111 registered
2017.04.12 09:18:03 1: HMCCURPC: Registering callback http://192.168.0.12:14702/fh9292 with ID CB9292 at http://192.168.0.24:9292/groups
2017.04.12 09:18:03 1: CCURPC: CB9292 ListDevices. Sending init to HMCCU
2017.04.12 09:18:03 2: CCURPC: CB9292 NewDevice received 4 device specifications
2017.04.12 09:18:13 1: HMCCURPC: RPC callback with URL http://192.168.0.12:14702/fh9292 registered
2017.04.12 09:18:13 1: HMCCURPC: Received IN event. RPC server CB2001 running.
2017.04.12 09:18:14 1: HMCCURPC: Received IN event. RPC server CB9292 running.
2017.04.12 09:19:15 2: HMCCURPC: Checking if all threads are running
2017.04.12 09:19:15 1: HMCCURPC: Only 3 of 4 threads are running. Cleaning up
2017.04.12 09:19:15 1: HMCCURPC: Housekeeping called. Cleaning up RPC environment
2017.04.12 09:19:15 2: HMCCURPC: Stop I/O handling
2017.04.12 09:19:15 2: HMCCURPC: Close child socket
2017.04.12 09:19:15 2: HMCCURPC: Close parent socket
2017.04.12 09:19:15 2: HMCCURPC: Sending signal INT to thread CB9292 TID=4
2017.04.12 09:19:15 2: HMCCURPC: Sending signal INT to thread CB2001 TID=2
2017.04.12 09:19:15 2: HMCCURPC: Sending signal INT to thread DATA TID=1
2017.04.12 09:19:15 2: HMCCURPC: Sending signal INT to thread CB8701 TID=3
2017.04.12 09:19:15 2: CCURPC: DATA stopped event processing. TID=1
2017.04.12 09:19:16 2: CCURPC: RPC server CB8701 stopped handling connections. TID=3
2017.04.12 09:19:17 1: HMCCURPC: Thread CB9292 with TID=4 still running. Can't delete it
2017.04.12 09:19:17 1: HMCCURPC: Thread CB2001 with TID=2 still running. Can't delete it
2017.04.12 09:19:17 2: HMCCURPC: Thread DATA with TID=1 has been stopped. Deleting it
2017.04.12 09:19:17 2: HMCCURPC: Thread CB8701 with TID=3 has been stopped. Deleting it
2017.04.12 09:19:17 1: HMCCURPC: Clean up failed for 2 threads
2017.04.12 09:19:24 2: CCURPC: RPC server CB2001 stopped handling connections. TID=2
2017.04.12 09:19:25 2: CCURPC: RPC server CB9292 stopped handling connections. TID=4

[zap]

Ich denke, das Problem ist HMIP. Vermutlich hast Du keine HMIP-Devices in der CCU. Beim Start der RPC-Server Threads prüft HMCCURPC, für welche Schnittstellen auch Geräte vorhanden sind. Nur für diese Schnittstellen werden RPC-Server Threads gestartet. Leider scheint aber bei der Prüfung der erfolgreich gestarteten Threads grundsätzlich auf alle Schnittstellen geprüft zu werden. Das muss ich noch korrigieren.

Als Workaround nimm einfach mal HMIP aus dem Attribut rpcinterfaces raus.

Solltest Du allerdings doch HMIP Geräte haben, liegt das Problem woanders ...

Falsch gedacht. Problem ist, dass innerhalb einer Minute nach dem Start des RPC-Servers kein Update von einem CUxD Device kommt. Die Initialisierung der Verbindung läuft bei CUxD etwas anders ab. Das muss ich nochmal überarbeiten ...

Der CUxD schickt nämlich kein "offizielles" Init an HMCCURPC. Daher wartet HMCCURPC einfach, bis die ersten Events von CUxD reinkommen und wertet das dann als erfolgreichen Verbindungsaufbau. Allerdings sind einige CUxD Devices geschwätziger als andere. Wenn sich die zu viel Zeit lassen, tritt der Fehler auf.

[Patrick131184]

Ah wollte grad schreiben, dass die Änderung keine Besserung gebracht hat....

Danke schon mal

[zap]

Habe ein Update eingecheckt, das das Problem beheben sollte. Bitte morgen mal aktualisieren und testen.

[Patrick131184]

Habe ein Update eingecheckt, das das Problem beheben sollte. Bitte morgen mal aktualisieren und testen.

Läuft.Danke vielmals!

[Chris8888]

Hallo Zap,

ich war ein paar Tage im Urlaub.
Im Log tauchen sporadisch folgende Meldungen auf:

Code Auswählen Erweitern

2017.04.16 14:47:51 2: HMCCU: HMCCU_QueueDeq seperator not found
2017.04.16 14:47:51 2: HMCCU: Received unknown event from CCU: 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x45 0x56

Zu verschiedenen Uhrzeiten und sicherlich ohne Interaktion

Hast du eine Idee was das ist?

Viele Grüße
Christian

[zap]

Kannst Du ignorieren. Liegt daran, dass so eine Filequeues gelegentlich Probleme bekommt, wenn gleichzeitig gelesen und geschrieben wird.
Dabei kann ein Event der CCU verloren gehen. Abhilfe dagegen wäre aufwändig. Eigentlich möchte ich die Filequeues so bald wie möglich abmanagen. Aber du hast ja Probleme mit HMCCURPC. Sonst hätte ich dir empfohlenen, das zu verwenden.

[Chris8888]

Alles klar. Danke. Obwohl ich diese Meldungen vor der 4er-Version nie hatte.

Ich werde jetzt nach dem Urlaub den externen Server mal ein paar Tage laufen lassen.
Vielleicht komme ich da noch etwas weiter.

Danke nochmals für deinen Support!

By the way: Siehst du eine Möglichkeit das Homematic-Update-Check-Tool auch für die Komponenten über deine Bridge anzubinden?
Das hier: https://wiki.fhem.de/wiki/HomeMatic_Firmware_Update
Wäre klasse!

[zap]

Meinst Du nur das Überprüfen, ob für irgendein Gerät eine neue Firmware vorhanden ist oder auch das eigentliche Firmware Update?

BTW: Die von Dir festgestellten Meldungen im Log hatte ich auch schon mit früheren Versionen. Insofern nicht mit der 4.0 entstanden.

[Chris8888]

Hi,
nur das Überprüfen ob eine neue Version da ist.
Mehr macht das Tool ja derzeit auch nicht. Reicht mir aber so auch völlig.

VG
Christian

[zap]

Die Version 4.0.001 ist im SVN. Lediglich 3 Ergänzungen im Modul HMCCU (I/O Device):

- get dutycycle: Erzeugt ein Reading je Interface mit dem aktuellen Duty Cycle
- get firmware: Listet die aktuelle Firmware der in FHEM definierten Devices sowie die bei EQ-3 verfügbare Version (funktioniert erst, wenn der RPC-Server gestartet wurde).
- set hmscript: Kann nun auch direkt HomeMatic Script Code ausführen. Der Code muss in eckigen Klammern angegeben werden.

Siehe auch Online Doku der Befehle.

Hinweis: Sollte jemand beim Stoppen des externen RPC-Servers (Modul HMCCURPC) Probleme bekommen (FHEM reagiert komisch oder stürzt ab), sollte man im RPC-Device das Attribut ccuflags auf keepThreads setzen.

[Chris8888]

Hallo Zap,

das Update habe ich eben eingespielt. Die Erweiterung mit der Firmwareabfrage ist spitze! Vielen Dank für die schnelle Implementierung!
Verstehe ich das richtig, dass in der Updateliste nur Devices auftauchen für die auch eine Firmwareupdatedatei auf dem Server liegt (egal welche Version)?

Bisher läuft alles wie gewohnt! (Ich nutze auch seit ein paar Tagen den externen Server, bisher ohne weitere Probleme. Nur der Disconnect bei Veränderung über die WebGui bleibt, aber damit muss und kann ich leben).

Viele Grüße
Christian

[zap]

Verstehe ich das richtig, dass in der Updateliste nur Devices auftauchen für die auch eine Firmwareupdatedatei auf dem Server liegt (egal welche Version)?

Ja, genau. HMCCU holt sich alle verfügbaren Updates vom EQ-3 Server. Es werden aber nur die gelistet, für die auch Devices in FHEM existieren.

Das Ganze funktioniert nur so lange, wie EQ-3 die Struktur der Download Seite nicht ändert. Was allerdings seltsam ist: Für eines meiner Devices ist die Firmware auf dem Device neuer als die auf dem EQ-3 Server.