CCU-Jack: REST-API/MQTT-Server/MQTT-CCU-Adapter

Der CCU-Jack als REST- und MQTT-Schnittstelle für die CCU und virtuelle Geräte für das IoT

Moderator: Co-Administratoren

wiwo
Beiträge: 16
Registriert: 17.01.2020, 17:48
Hat sich bedankt: 6 Mal
Danksagung erhalten: 1 Mal

Re: CCU-Jack: REST-API/MQTT-Server/MQTT-CCU-Adapter

Beitrag von wiwo » 16.02.2020, 19:28

Mathias hat geschrieben:
15.02.2020, 21:26
So, das Paket für das virtualisierte RaspberryMatic (x86, 32 Bit) ist fertig: ccu-jack-vccu-x86-0.7.4.tar.gz
Testen konnte ich es aber noch nicht. Vielleicht kannst Du mir kurz eine Rückmeldung geben.

Hallo Mathias,
das Addon lässt sich problemlos installieren, das Web GUI funktioniert rasend schnell.

Ich hatte versucht den MQTT Server mit dem IObroker MQTT Client zu verbinden da war ich nicht erfolgreich. Konnte aber mit der Anwendung MQTT Explorer sofort auf den MQTT Server zugreifen.

Gruss und nochmals Dank
Wolfgang
Proxmox VE HA Cluster auf Shuttle DL20N6 + DL10J, RaspberryMatic 3.75.6.20240316, RPI-RF-MOD mit HB-RF-ETH, HM-LGW + HmIP-HAP als Gateway, 82 BidCos-RF, 45 HmIP Geräte, ioBroker

Mathias
Beiträge: 1767
Registriert: 03.11.2010, 10:25
System: CCU
Wohnort: Aachen
Hat sich bedankt: 58 Mal
Danksagung erhalten: 253 Mal
Kontaktdaten:

Re: CCU-Jack: REST-API/MQTT-Server/MQTT-CCU-Adapter

Beitrag von Mathias » 19.02.2020, 21:13

Sowohl der ioBroker-Adapter "MQTT" (Client-Modus) als auch der Adapter "MQTT Client" können die Wertänderunen vom CCU-Jack empfangen (s.a. Bildschirmfotos).

Beim Adapter "MQTT" musste ich aber die voreingestellte Client-ID abändern, da Punkte laut MQTT-Spezifikation nicht erlaubt sind. Der Adapter blieb auch durchgehend "gelb". Er erwartet anscheinend noch irgendetwas spezielles vom MQTT-Server.

Das Setzen von CCU-Datenpunkten wird allerdings problematisch, beide Adapter sind auf eine spezielle Topic-Struktur zugeschnitten: Lese- und Schreibpräfixe werden nur in der obersten Topic-Ebene unterstützt. Dadurch kann aber praktisch nur eine Zentrale/Gerät angebunden werden. Die Topic-Struktur vom CCU-Jack ist generischer und daher anders. Vielleicht habe ich aber auch nur eine Einstellung bei den Adaptern nicht gefunden.

mqtt-iobroker.png
mqtt-iobroker-2.png


Mathias
Beiträge: 1767
Registriert: 03.11.2010, 10:25
System: CCU
Wohnort: Aachen
Hat sich bedankt: 58 Mal
Danksagung erhalten: 253 Mal
Kontaktdaten:

Re: CCU-Jack: REST-API/MQTT-Server/MQTT-CCU-Adapter

Beitrag von Mathias » 10.03.2020, 21:53

Auf GitHub ist eine neue Version zu finden.

Fehlerbehebungen / Verbesserungen

SGubler
Beiträge: 74
Registriert: 24.09.2018, 17:49
Hat sich bedankt: 3 Mal

Re: CCU-Jack: REST-API/MQTT-Server/MQTT-CCU-Adapter

Beitrag von SGubler » 16.03.2020, 00:43

Hallo Mathias.
Besten Dank für das interessante Modul. Das sieht schon sehr vielversprechend aus*
ich habe heute einiges getestet, als Beta funktioniert einiges, aber noch nicht alles.
Die Anleitungen sind auch noch sehr knapp gehalten.
Das sich die Applikation als Zusatzmodul, aber auch als separate Applikation installieren lässt finde ich von Vorteil. Werden vermutlich nicht viel brauchen, aber wenn das Modul unabhängig von der Rasperrymatic läuft ist mir das auch recht.

Auf einem Windows Server installiert funktionierts. Ich hatte im Logfile nur immer einen Fehlermeldung, wenn ich als Startoption für die Interface List: System hinzugefügt habe, da wollte er immer auf Port 2002 der CCU zugreifen. Dabei habe ich gar keine Wired Geräte.

Auf einem virtuellen Linux 64 Bit lief die Installation, die Daten wurden von der CCU ausgelesen, aber nicht die Devices.
Als Modul auf der virtuellen Linux x86 Rasperrymatic funktioniert die Applikation, alle Daten können ausgelesen werden (ausser cuxd Devices)

die Performance ist schnell wie der Blitz. Na gut, ich verwende auch schnelle PCs, wie schnell es auf einem Raspi ist, weiss ich nicht,
Das WebUI hilft bei der Navigation.

Nun zu den Fragen / Fehlern oder zu meiner Unwissenheit:
1. Was ist der Zweck der Interfaces "System" und "Virtual Devices" ? Hatte die am Windows Server gestartet, sah aber keinen Effekt.

2. Wie kann man virtuelle Geräte vom CuxD abfragen? wurde dies noch nicht implementiert ? Für mich wäre dies der Zweck der Übung.
die virtuellen Geräte über dieses Modul mit Daten zu füllen, als Alternative zu XMLAPI und CuxD.exe

3. Beim Testen mit Curl hatte ich Probleme mit der Übergabe der Json parameter, das ging nur über eine externe Datei. Nach etwas testen ging es dann. Die Übergabe von True ohne "" gefällt curl wohl nicht besonders.

4. über Python funktionieren die Aufrufe. System Variablen lesen und schreiben. Licht Schalter ein und ausschalten.Jalousien. Man muss die richtigen Kanäle bzw. Parameter testen, dazu hilft das UI.

5. was nicht funktionierte, war das Schreiben eines temp. oder Feuchtewertes in einen existierenden HM-WDS40-TH-I-2 obwohl der Response 200 ausgegeben wurde.

Gerne werde ich die Programmierer weiter unterstützen beim Testen.
Viele Grüsse

Stefan

SGubler
Beiträge: 74
Registriert: 24.09.2018, 17:49
Hat sich bedankt: 3 Mal

Re: CCU-Jack: REST-API/MQTT-Server/MQTT-CCU-Adapter

Beitrag von SGubler » 16.03.2020, 09:06

Mittlerweile klappen die CURL Aufrufe aus Windows, wenn man das passend "Escaped"

curl -d "{\"v\":\"100\"}" -H "Content-Type: application/json" -X PUT http://192.168.xx.xx:2121/sysvar/26246/~pv

oder bei true / false oder numerischen Werten
curl -d "{\"v\":false}" -H "Content-Type: application/json" -X PUT http://192.168.xx.xx:2121/device/000xxxxxxx/2/STATE/~pv

Mathias
Beiträge: 1767
Registriert: 03.11.2010, 10:25
System: CCU
Wohnort: Aachen
Hat sich bedankt: 58 Mal
Danksagung erhalten: 253 Mal
Kontaktdaten:

Re: CCU-Jack: REST-API/MQTT-Server/MQTT-CCU-Adapter

Beitrag von Mathias » 16.03.2020, 22:08

SGubler hat geschrieben:
16.03.2020, 00:43
Die Anleitungen sind auch noch sehr knapp gehalten.
Hast Du die Auflistung der Curl-Befehle gefunden? Was sollte noch besser dokumentiert werden?
SGubler hat geschrieben:
16.03.2020, 00:43
Ich hatte im Logfile nur immer einen Fehlermeldung, wenn ich als Startoption für die Interface List: System hinzugefügt habe, da wollte er immer auf Port 2002 der CCU zugreifen. Dabei habe ich gar keine Wired Geräte.
Das Interface System existiert nur auf einer CCU1. (Da fällt mir auf, dass ich den CCU-Jack noch nicht mit einer CCU1 getestet habe.)
SGubler hat geschrieben:
16.03.2020, 00:43
Auf einem virtuellen Linux 64 Bit lief die Installation, die Daten wurden von der CCU ausgelesen, aber nicht die Devices.
Da müsstest Du mir nochmal genau beschreiben, was nicht funktioniert und noch eine Log-Datei erstellen.
SGubler hat geschrieben:
16.03.2020, 00:43
1. Was ist der Zweck der Interfaces "System" und "Virtual Devices" ? Hatte die am Windows Server gestartet, sah aber keinen Effekt.
System: nur auf CCU1 vorhanden; VirtualDevices sind virtuelle Geräte z.B. für Heizgruppen (s.a. CCU → Einstellungen → Gruppen).
SGubler hat geschrieben:
16.03.2020, 00:43
2. Wie kann man virtuelle Geräte vom CuxD abfragen? wurde dies noch nicht implementiert ? Für mich wäre dies der Zweck der Übung.
die virtuellen Geräte über dieses Modul mit Daten zu füllen, als Alternative zu XMLAPI und CuxD.exe
CUxD unterstützt nur BIN-RPC, die binäre Form der XML-RPC-API. Weil Uwe angedeutet hatte XML-RPC in den CUxD einzubauen, und weil alle anderen Schnittstellenprozesse XML-RPC unterstützen, habe ich auf eine Implementierung von BIN-RPC im CCU-Jack verzichtet.
SGubler hat geschrieben:
16.03.2020, 00:43
5. was nicht funktionierte, war das Schreiben eines temp. oder Feuchtewertes in einen existierenden HM-WDS40-TH-I-2 obwohl der Response 200 ausgegeben wurde.
Auch hier kann eine Log-Ausgabe weiterhelfen (Kommandozeilenparameter -log trace).
SGubler hat geschrieben:
16.03.2020, 00:43
Gerne werde ich die Programmierer weiter unterstützen beim Testen.
Danke für die Unterstützung durch Tests.

Gruß
Mathias

SGubler
Beiträge: 74
Registriert: 24.09.2018, 17:49
Hat sich bedankt: 3 Mal

Re: CCU-Jack: REST-API/MQTT-Server/MQTT-CCU-Adapter

Beitrag von SGubler » 21.03.2020, 23:33

Danke für die Antworten.

Beim Linux System hängt es vermutlich am Parameter -addr dass dieser korrekt angegeben wird, wenn die CCU auf einem anderen Server liegt, ansonsten nimmt er localhost als addresse. Danach funktionierts.

Die virtuellen Gruppen funktionieren auch (aber nicht die virtuellen Geräte auf cuxd Basis, aber das ist ja bekannt).


Das Setzen eines Datenpunktes eines HM-WDS40-TH-I-2 der Temperatur:
Get http://192.168.25.61:2121/device/NEQxxx ... RATURE/~pv
ergiebt {"ts":1584827039465,"v":24.3,"s":0}

der Put erzeugt Code 200 = OK aber in der CCU ändert sich nichts.

Der ausschnitt des Tracefiles des CCU-Jack:

2020-03-21 22:27:12|DEBUG |veap-handler |Request from 192.168.25.61:41078, method PUT, URL /device/NEQxxxxxxx/1/TEMPERATURE/~pv
2020-03-21 22:27:12|TRACE |veap-handler |Request body: {"v": 10.3}
2020-03-21 22:27:12|DEBUG |itf-client |Calling method setValue(NEQ0680500:1, TEMPERATURE, 10.3) on http://192.168.25.75:2001
2020-03-21 22:27:12|TRACE |xmlrpc-client |Calling method setValue on http://192.168.25.75:2001
2020-03-21 22:27:12|TRACE |xmlrpc-client |Request XML: <?xml version="1.0" encoding="ISO-8859-1"?>\n<methodCall><methodName>setValue</methodName><params><param><value>NEQ0680500:1</value></param><param><value>TEMPERATURE</value></param><param><value><double>10.3</double></value></param></params></methodCall>
2020-03-21 22:27:12|TRACE |xmlrpc-client |Response XML: <?xml version="1.0" encoding="iso-8859-1"?>\n<methodResponse><params><param>\n <value></value>\n</param></params></methodResponse>\n
2020-03-21 22:27:12|TRACE |veap-handler |Response code: 200




die Curl Befehle müssen escaped werden, sonst funktionieren sie nicht:
curl -d "{\"v\":true}" -H "Content-Type: application/json" -X PUT http://ccuadrresse:2121/device/000serie ... /STATE/~pv

Mathias
Beiträge: 1767
Registriert: 03.11.2010, 10:25
System: CCU
Wohnort: Aachen
Hat sich bedankt: 58 Mal
Danksagung erhalten: 253 Mal
Kontaktdaten:

Re: CCU-Jack: REST-API/MQTT-Server/MQTT-CCU-Adapter

Beitrag von Mathias » 22.03.2020, 22:36

Das Setzen der Temperatur wird erfolgreich an die CCU weitergeleitet, und die CCU meldet auch keinen Fehler. Soweit ist alles in Ordnung.

Allerdings kann die Temperatur eines Sensors nicht gesetzt werden. Bei einem nicht beschreibbaren Datrenpunkt gibt es normalerweise einen HTTP-Status-Code von 500 mit der Meldung "XML-RPC fault (code: -5, message: Invalid parameter or value)" von der CCU. Bei den Datenpunkteigenschaften müsste dies auch die Eigeschaft operations anzeigen: Das Bit 1 (mit Wert 2) müsste 0 sein. Welchen Wert besitzt den operations von dem Datenpunkt?


Antworten

Zurück zu „CCU-Jack“