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

[wolwin]

Jedoch kommt es dann zu einem (CCUJack ?) Fehler, den man im hmserver.log sehen kann.

Auch hier hilft eine detaillierte Log-Datei weiter. Dann können die Zeitstempel miteinander verglichen werden.

Abgesehen von den Meldungen gibt es denn Probleme mit der Funktionalität vom CCU-Jack? Web-Seiten, REST-API, MQTT?

Hallo Mathias,
Danke für die schnelle Antwort - klar: die Warnmeldung von CCU-Jack ist unkritisch ... sie korrespondiert jedoch eindeutig mit der Exception-Meldung aus der hmserver.log - Datei - deinstalliere ich CCU-Jack ist auch die Exception nicht mehr vorhanden ...
Ich habe bisher lediglich die MQTT-Server Funktionalität getestet - das funktioniert.
Für mich sieht es so aus, als ob von CCU-Jack regelmäßig die Geräte 'gescant' werden, wobei es bei 'nicht ansprechbaren' Geräten zu dieser Exception kommt ...

[Mathias]

Danke für die schnelle Antwort - klar: die Warnmeldung von CCU-Jack ist unkritisch ... sie korrespondiert jedoch eindeutig mit der Exception-Meldung aus der hmserver.log - Datei - deinstalliere ich CCU-Jack ist auch die Exception nicht mehr vorhanden ...

Die Exception im hmserver.log kommt zeitgleich mit einem sogenannten Ping-Aufruf (Dies ist kein Netzwerk-Ping!) vom CCU-Jack. Diese dient dazu, die Verbindung zu den Schnittstellenprozessen auf der CCU zu testen. Diese Funktion ist dokumentiert und wird auch richtig vom CCU-Jack aufgerufen. Warum sich der HM-Server selber darüber wundert, ist unklar. Die Log-Meldung ist unkritisch.

Der Ping wird aber nur ausgeführt, wenn von einem Schnittstellenprozess seit einer Minute nichts mehr an den CCU-Jack gemeldet worden ist. Ich nehme an, dass Du keine oder nur wenige HM-IP Geräte an der CCU hast. Ich werde mal das Timeout auf 5 Minuten vergrößern. Falls Du keine HM-IP Geräte angelernt hast, kann die HM-IP-Schnittstelle aus der Konfiguration entfernt werden. Dann verschwinden die Meldungen auch.

[cebulon]

Hallo Mathias,

Dein Hinweis zum Trace-Log hat die Blockade gelöst. Die Anwendung lief demnach auch bereits vorher, ich habe das nur nicht bemerkt. Demnach läuft nicht nur der MQTT-Broker einwandfrei.

Ich bin auf diesem Gebiet eher Anfänger und nicht sehr „trittsicher“. Mein erster Versuch, zwischen einem ESP8266 und meiner CCU via Mosquitto und NODE-RED bidirektional zu kommunizieren, hat unter Zuhilfenahme diverser Literatur zwar nach längerer Zeit geklappt – aber auch gezeigt, daß auf beiden Seiten fehlerträchtig sehr viel manuell programmiert werden muß und die Ressourcen erheblich in Anspruch genommen werden.

Nun habe ich es mit „ccu-jack“ versucht. Auch dieser Anfang war für mich ziemlich holprig, aber nachdem ich den Navigator verstanden habe, war das Lesen von Datenpunkten der CCU vom ESP aus kein Hexenwerk mehr:

mqttClient.subscribe("device/status/1/0010D8A990A289/1/ACTUAL_TEMPERATURE");

liefert das Ergebnis: {"ts":1613147752751,"v":-4.2,"s":0}

Ich kann den numerischen Meßwert natürlich aus der Antwort isolieren, aber gibt es auch einen Weg, diesen Wert direkt zu erhalten?

Ansonsten hat mich das Schlüsselwort „MQTT“ in der Beschreibung von CCU-Systemvariablen begeistert. Diese Funktionalität ist genau das, was ich brauche.

Herzlichen Dank für Deine Arbeit.

mfg Gerd

[wolwin]

Hallo Mathias,

Diese Funktion ist dokumentiert und wird auch richtig vom CCU-Jack aufgerufen. Warum sich der HM-Server selber darüber wundert, ist unklar. Die Log-Meldung ist unkritisch.

Der Ping wird aber nur ausgeführt, wenn von einem Schnittstellenprozess seit einer Minute nichts mehr an den CCU-Jack gemeldet worden ist. Ich nehme an, dass Du keine oder nur wenige HM-IP Geräte an der CCU hast. Ich werde mal das Timeout auf 5 Minuten vergrößern. Falls Du keine HM-IP Geräte angelernt hast, kann die HM-IP-Schnittstelle aus der Konfiguration entfernt werden. Dann verschwinden die Meldungen auch.

Stimmt - habe keine HM-IP Geräte angelernt. Werde also die Konfigurationsdatei anpassen und testen ...
Bleibt nur noch, warum der HM-Server so reagiert und das Log-File mit Exception-Meldungen vollmüllt - vielleicht kannst Du ja einen Workaround finden

[Mathias]

mqttClient.subscribe("device/status/1/0010D8A990A289/1/ACTUAL_TEMPERATURE");
liefert das Ergebnis: {"ts":1613147752751,"v":-4.2,"s":0}
Ich kann den numerischen Meßwert natürlich aus der Antwort isolieren, aber gibt es auch einen Weg, diesen Wert direkt zu erhalten?

Nein, der CCU-Jack versendet immer in diesem Format mit Zeitstempel (ts) und Status (s).

[Mathias]

Auf GitHub ist eine neue Version zu finden.

In dieser Version ist die Anbindung vom CUxD hervor zu heben. Also auch CUxD-Datenpunkte können nun über die REST- und MQTT-API gelesen und gesetzt werden. Dazu hat twendt einiges an Vorarbeit geleistet. Vielen Dank dafür!

Die komplette Dokumentation vom CCU-Jack ist in der README zu finden.

Fehlerbehebungen / Verbesserungen

• Kommandozeilenoption für den Pfad zur Konfigurationsdatei (v1.1.0)
• Warnmeldung in der hmserver.log auf der CCU bei einem Schnittstellen-Ping vom CCU-Jack (v1.1.0)
• Option um das CCU-Zertifikat zu nutzen (v1.1.0)
• Unterstützung für CUxD (v1.1.0)

[Turnierkrokodil]

Ich hab aus dem 1.1.0 er Release ein (bei mir funktionierdes) Dockerimage für Linux gebaut und auf docker hub hochgeladen (thetagamma/ccu-jack). Dort sind auch ich ein paar (hoffentlich hilfreiche) Hinweise, wie das Image zu nutzen ist.

Sobald ich die Kontrolle über git wiedererlange, werde ich die Änderungen noch ins Repository einfliessen lassen. Vielleicht mag der eine oder andere schonmal mit dem fertigen Image experimentieren

[djangp]

Hallo, wo genau finde ich die "ccu-jack.cfg"
Denn habe ich aktuell noch das Problem, dass per MQTT kein Adapter angesprochen werden kann.

CCU-Jack ist als Addon auf meinem Raspberrymatic, welcher unter einer Proxomox LXC läuft.
Ich möchte per node-red (weitere VM auf Proxmox) direkt Devices von der CCU/Raspberrymatic schalten.

Direkt über das CCU-Jack Addon kann ich den Adapter schalten.
Das der Topic Eintrag auf node-red "/device/set/LEQ0093550/1/STATE"
Die MQTT Node zeigt verbunden an - wobei sie das irgendwie immer tut.


Edit:
Habe in der neuen Version jetzt die ".conf" gesehen, was ja passen sollte.

Code: Alles auswählen

(CCU=(Address=127.0.0.1, Interfaces=(BidCosRF, HmIPRF, VirtualDevices), InitID=CCU-Jack), Host=(Name=raspberrymatic, Address=127.0.0.1), Logging=(Level=INFO, FilePath=/var/log/ccu-jack.log), HTTP=(Port=2.121, PortTLS=2.122, CORSOrigins=(*), WebUIDir=webui), MQTT=(Port=1.883, PortTLS=8.883, WebSocketPath=/ws-mqtt), BINRPC=(Port=2.123), Certificates=(AutoGenerate=1, CACertFile=cacert.pem, CAKeyFile=cacert.key, ServerCertFile=svrcert.pem, ServerKeyFile=svrcert.key), Users=())	

Allerdings kann ich de Datenpunkte nicht ansprechen. Wie soll ich vorgehen, damit ich das Problem entdecke?

[Mathias]

Das der Topic Eintrag auf node-red "/device/set/LEQ0093550/1/STATE"

Topics dürfen nicht mit / beginnen (s.a. Anleitung). Die Topics können auch leicht mit einem MQTT-Client wie MQTT Explorer überprüft werden.

[wolwin]

Hallo Mathias,

Der Ping wird aber nur ausgeführt, wenn von einem Schnittstellenprozess seit einer Minute nichts mehr an den CCU-Jack gemeldet worden ist. Ich nehme an, dass Du keine oder nur wenige HM-IP Geräte an der CCU hast. Ich werde mal das Timeout auf 5 Minuten vergrößern. Falls Du keine HM-IP Geräte angelernt hast, kann die HM-IP-Schnittstelle aus der Konfiguration entfernt werden. Dann verschwinden die Meldungen auch.

habe jetzt die aktuelle Version 1.1.0.0 getestet ... in der Tat kommt die Execption immer noch, da ich keine IP-Geräte besitze ... sobald der Eintrag "HmIPRF" aus der config genommen ist, verschwindet auch die Exception. Vielleicht kannst Du mal über einen GUI -Switch, wie für CuxD nachdenken ...

Ich habe ein wenig mit den MQTT CCU und Server Möglichkeiten rumgespielt, z.B. indem ich meine Node-Red MQTT Verknüpfungen auf die CCU-Jack Adresse gesetzt habe: es funktioniert bei mir (lesend) alles - SUPER

Mit Deinem Tool ergeben sich tolle, neue Möglichkeiten - ich kann nur eins sagen: Hut ab vor Deiner Entwicklung !!

VG
Wolfram