mdzio / ccu-jack

CCU-Jack bietet einen einfachen und sicheren REST- und MQTT-basierten Zugriff auf die Datenpunkte der Zentrale (CCU) des Hausautomations-Systems HomeMatic. Zudem können einfach Fremdgeräte an die CCU angebunden werden.

CCU-Jack

CCU-Jack bietet einen einfachen und sicheren REST- und MQTT-basierten Zugriff auf die Datenpunkte der Zentrale (CCU) des Hausautomations-Systems HomeMatic der Firma eQ-3. Er implementiert dafür das Very Easy Automation Protocol, welches von vielen Programmiersprachen leicht verwendet werden kann, und das MQTT-Protokoll, welches im Internet-of-Things weit verbreitet ist. Zudem können mit den genannten Protokollen auch Fremdgeräte an die CCU angebungen werden.

Folgende Ziele verfolgt der CCU-Jack:

Der CCU-Jack soll anderen Applikationen einen einfachen Zugriff auf die Datenpunkte der CCU ermöglichen. Beispielsweise werden für den Zugriff auf eine CCU mit HM-, HM-Wired- und HM-IP-Geräten insgesamt 9 Netzwerkverbindung, teilweise als Rückkanal und mit unterschiedlichen Protokollen, benötigt. Zudem sind die Netzwerkschnittstellen der CCU unverschlüsselt, wodurch sie nicht in der Firewall der CCU freigeschaltet werden sollten. Der CCU-Jack standardisiert den Zugriff auf alle Geräte und Systemvariablen mit einem einheitlichen Protokoll und über eine verschlüsselte Verbindung.

Zudem sollen möglichst einfach Fremdgeräte (z.B. WLAN-Steckdosen) an die CCU angebunden und mit dieser automatisiert werden. Angebundenen Fremdgeräte werden auf der CCU wie originale HM-Geräte dargestellt. Sie können über die Web-UI der CCU genauso bedient und beobachtet werden. Zudem können sie ohne Einschränkungen in CCU-Programmen verwendet werden.

Mehrere CCUs und andere Automatisierungsgeräte mit MQTT-Server können über den CCU-Jack untereinander vernetzt werden und Wertänderungen austauschen. Dafür stellt der CCU-Jack eine MQTT-Bridge zur Verfügung. CCUs können auch mit einem MQTT-Server in der Cloud verbunden werden.

Funktional ist der CCU-Jack eine Alternative zum XML-API Add-On. Das XML-API Add-On wird seit längerer Zeit nicht mehr weiter entwickelt und enthält nicht behobene Fehler und Sicherheitslücken. Zudem kann der CCU-Jack die Kombination der zwei Add-Ons hm2mqtt und Mosquitto ersetzen. Das Add-On hm2mqtt wird ebenfalls seit längerer Zeit nicht mehr weiter entwickelt.

Bezügliche der Anbindung von Fremdgeräten ersetzt der CCU-Jack viele komplizierte und aufwändige Lösungen und bietet gleichzeitig mehr Funktionaliät.

Anwenderhandbuch

Alle Informationen für Anwender (z.B. Installation, Konfiguration) sind im Anwenderhandbuch zu finden. Dies sollte vor der Installation gelesen werden!

Umfeld vom CCU-Jack

Im Zusammenhang mit dem CCU-Jack sind weitere Projekt von anderen entstanden:

• CCU-Jack to HomeAssistant (Anbindung der HomeMatic CCU an HomeAssistant über den CCU-Jack)
• node-red-contrib-ccu-jack (Anbindung der HomeMatic CCU an Node-RED über den CCU-Jack)
• ngx-ccu-jack-client (Integration des CCU-Jacks in Angular-Anwendung)

Entwicklung

Bauen aus den Quellen

Der CCU-Jack ist in der Programmiersprache Go geschrieben. Alle Distributionen des CCU-Jacks können sehr einfach und schnell auf allen möglichen Plattformen (u.a. Windows, Linux, MacOS) gebaut werden. Dafür in einem beliebigen Verzeichnis das Git-Repository klonen, oder die Quellen hinein kopieren. Danach in diesem Verzeichnis eine Kommandozeile öffnen, und folgende Befehle eingeben:

cd build
go run .

In dem Hauptverzeichnis werden dann alle Distributionen gebaut.

Für die Entwicklung bietet sich die Entwicklungsumgebug Visual Studio Code an. Einfach das Hauptverzeichnis öffnen. Die nötigen Extensions werden automatisch zur Installation angeboten.

Mitwirkung

Mitwirkende sind natürlich gerne gesehen. Sei es für die Dokumentation, das Testen, den Support im HomeMatic-Forum, die Fehlerbehebung oder die Implementierung neuer Funktionalität. Für Code-Beiträge ist die Lizenz (GPL v3) zu beachten. Code-Beiträge sollten immer auf einem neuen Branch separat vom master-Branch entwickelt werden.

Autoren

• Mathias Dz.
• martgras (Raspberry Pi 4, Zertifikatsbehandlung)
• twendt (BIN-RPC für CUxD)
• Theta Gamma (Docker-Image)

Lizenz und Haftungsausschluss

Lizenz und Haftungsausschluss sind in der Datei LICENSE.txt zu finden.

ccu-jack's Issues

Datenpunkte eines Raumes/Gewerkes finden

Zwar sind in den Datenpunkteigenschaften die Räume und Gewerke eines Datenpunktes zu finden, allerdings kann nicht direkt rückwärts gesucht werden: Von einem Raum zu den zugehörigen Datenpunkten.

Es sollten Raum- und Gewerk-Objekte angelegt werden, die ihre Datenpunkte per Link referenzieren.

VEAP-Client

Es sollte ein VEAP-Client eingebettet werden, um Datenpunkte direkt von anderen VEAP-Servern zu lesen oder zu schreiben.

Hinweis: Derzeit keine Installation der Version 2 des CCU-Jacks auf der CCU2 oder piVCCU2 möglich

Für zukünftige Features ab V2 des CCU-Jacks wurde das Hochfahren der Applikation auf der CCU3 angepasst. Er startet nun vor der ReGaHss und wartet dann bis die ReGaHss komplett gestartet ist.

Dieses ist zwar auch auf der CCU2 möglich, muss aber gesondert angepasst werden. Da der CCU-Jack nur von sehr wenigen auf einer CCU2 verwendet wird, wird der Entwicklungsaufwand erst einmal eingespart. Andere Entwickler können hierbei gerne helfen.

Die Version 1 des CCU-Jacks wird weiterhin für die CCU2 und piVCCU2 gepflegt. Diese Version erhält allerdings keine neuen Funktionen mehr.

Mehr Zeichen bei der MQTT Client-ID erlauben

Jeder MQTT-Client meldet sich mit einer Client-ID beim CCU-Jack an. Diese wird bisher nach Maßgabe der MQTT-Spezifikation geprüft. Diese Prüfung sollte toleranter sein.

Docker-Image

Docker-Image für eine einfache Installation auf unterschiedlichsten Plattformen.

Json object return type

Hi,

may be I missed it - I would like to use some variable as complex JSON object. That means in contrast to the measurements and status values, I'd like to save a config for my webui within a variable.
This together with MQTT websockets (currently I use twistd+autobahn on localhost for testing) would move on my own LCARS like GUI (attachment). I would use it for the configuration of the GUI on load.

BR
Plurax

Änderung des Log-Levels über das Web-Frontend

Lesen- und Schreiben von Geräte- und Kanalkonfigurationen über REST-API

HomeMatic Geräte und die zugehörigen Kanäle können Konfigurationoptionen besitzen. Sie befinden sich im sogenannten Parametersatz MASTER der XML-RPC-API. Über die REST-API des CCU-Jacks sollte dieser Parametersatz gelesen und gesetzt werden können.

Der Parametersatz MASTER soll über den Bezeichner $MASTER adressierbar sein, damit keine Namenskollisionen mit anderen Parametern entstehen.

Beispielkonfiguration in der CCU:

Beispielansicht im Navigator:

Schnittstelle (z.B. HmIPRF, BidCosRF) eines Gerätes zu den Eigenschaften hinzufügen

Name der Eigenschaft: interfaceType

Idee aus #26.

Zugriffsberechtigungen

Es sollen beliebig viele Benutzer mit eigenen Anmeldedaten angelegt werden können. Je Benutzer soll festgelegt werden können, über welche Schnittstelle (REST, MQTT) welche Datenpunkt gelesen oder beschrieben werden können.

MQTT: Zusätzliche Auslöser für das Lesen von Systemvariablen

Es sollte zusätzliche Auslöser für das Lesen von Systemvariablen geben:

• Es könnte Gruppen mit verschiedenen Zykluszeiten geben.
• Das Auslesen kann durch einen Gerätedatenpunkt (z.B. der letzte virtuelle Taster BidCoS-RF:50) angestoßen werden. Dann müsste aber nach dem Setzen einer Systemvariable noch der Taster angestoßen werden. Es könnten auch mehrere Gruppen mit unterschiedlichen Gerätedatenpunkten verknüpft werden.

MQTT-Bridge Funktionalität

Es wäre schön, wenn man den MQTT Server auch als Bridge konfigurieren könnte. In vielen Systemen gibt es schon einen MQTT Server, and damit könnte man die CCU mit ccu-jack dann direkt an den existierenden MQTT Server hängen.
Ebenfalls könnte man damit dann auch einfach mehrere CCUs bestimmte Daten direkt an einen MQTT Server im Internet schicken lassen. Last but not least, wenn die Bridge Konfiguration auch mehrere Remote MQTT Server unterstützt, dann bekommt man auch noch Failover...

Unterstützung für CUxD

Hi,

first of all, thank you for this really great project.

I would like to use it to connect my Homey App to the CCU. Currently I use either a combination of xmlrpc/binrpc to connect directly to the CCU or by using a special Node Red Flow and the mosquitto Addon.
The Node Red version works great, but is too complicated to implement for the users.
The direct connection uses too much memory on the Homey and can cause the App to crash.

Therefore I would really like to switch to your CCU-Jack. But that requires support for CUxD which unfortunately only supports binrpc.

I created an implementation for binrpc based on the great work by hobbyquaker who created a Node package for it.

The code is not the greatest yet, but maybe you are able to have a look at it. There were a a lot of changes required to existing code, but most of it is just because I extracted the Value and Query code into a model package which can then be shared between the xmlrpc and binrpc code.

Unfortunately the CUxD does not send any messages for new devices or other device changes. Only events are being sent. Therefore I added a call to list the devices on startup.

There was also a hack required because the interfaceID that is included in the event calls does not include the ID prefix. Right now I add it hardcoded.

Binrpc does not seem to differentiate between Int and I4 and also FlatString and String.

I can also create a pull request already if you like then we could discuss required changes in the PR.

I have not tested it on he CCU/RaspberryMatic yet, but it works, when I run it on my notebook.

I configured Go modules. Right now It is expected that go-hmccu module in located at ../go-hmccu when compiling the ccu-jack. That can easily be changed in the replace statement in the go.mod file.

Here are the links to my forked repos:
https://github.com/twendt/go-hmccu
https://github.com/twendt/ccu-jack

Regards,
Timo

Ändern der Zugriffsberechtigungen über die Web-UI

Die Zugriffsberechtigungen sollten komfortabel über die Web-UI änderbar sein.

Open Source

Cooles Projekt, gefällt mir. Aber warum ist der Source nicht im Repo? :-)

[FEATUREREQUEST] Lesen aus MQTT-Broker in Systemvariable

Wenn man in der Logikverarbeitung der CCU einen Wert aus dem MQTT-Broker verwenden möchte, wäre es doch ganz nützlich (ähnlich, wie beim Publish) die Beschreibung der Variablen um das Schlüsselwort MQTT (oder MQTT_SUB) + das gewünschte Topic ergänzen zu können. Das würde dann ein subscribe "auslösen" und dann bei Änderung der Message die Systemvariable updaten.

Virtuelle Geräte für MQTT für die direkte Verwendung in der CCU-Automatisierung

Damit ohne weitere Add-Ons oder Programmierung MQTT-Nachrichten direkt in der CCU-Automatisierung verwendet werden können, sollen virtuelle Geräte mit entsprechender Funktionalität zur Verfügung stehen. Diese können wie reale HM-Geräte über die Web-UI bedient, konfiguriert, in Programmen abgefragt und von Programmen gesteuert werden. Der Zustand der Geräte soll sich über beliebige MQTT-Nachrichten von außen ändern lassen können (z.B. Zustand eines Schalters). Und eine Änderung des Zustands durch die CCU-Automatisierung soll automatisch entsprechende MQTT-Nachrichten versenden.

Die Geräte stellen entsprechende Parameter zur Konfiguration auf der CCU unter Einstellungen → Geräte → Einstellen zu Verfügung. Beispielsweise:

• MQTT-Topic/Payload zum Versand
• MQTT-Topic/Payload-Filter für den Empfang

Folgende Gerätetypen sollen als erstes unterstützt werden:

• Taster für den Versand von MQTT-Nachrichten
• Taster um auf MQTT-Nachrichten zu reagieren
• Schalter, dessen Zustand über MQTT-Nachrichten geändert werden kann, und der bei Ein-/Aus-Befehlen MQTT-Nachrichten versendet.

Dadurch können Tasmota-, ESPurna-, ESPEasy-Geräte wie HM-Geräte in der CCU-Automatisierung verwendet werden.

Lesen von Gerätedatenpunkten aus der ReGaHss schlägt unter Umständen fehl

Wenn Gerätedatenpunkte über die REST-API gelesen werden, und der zugehörige Schnittstellenprozess der CCU bisher noch keinen Wert selbst übermittelt hat, wird als Fallback der Wert des Datenpunktes aus der ReGaHss gelesen. Dies funktioniert seit V1.0.0 nicht mehr.

Ansteuerung von Gruppen

Gruppen scheinen leider nicht unterstützt zu werden. Ich habe hier eine Gruppe aus Wand- und Heizungsthermostat. Dafür wird im Homematic-UI ein virtuelles Gerät angezeigt. In Openhab bzw. im Homematic-UI kann man das virtuelle Gerät direkt ansprechen, ccu-jack kennt allerdings offenbar nur reale Devices.

Ich könnte beide Geräte wahrscheinlich separat mit den gleichen Werten ansteuern, ist aber unschön.

Ansonsten vielen Dank für die Software, funktioniert soweit bestens.

Unterstützung für die Homeassistant MQTT-Konvention

Es wäre sehr schön, wenn ccu-jack auch Meta-Informationen für Homeassistant erstellen könnte. Die notwendigen Daten liegen vor und es ist recht aufwändig, das alles von Hand anzulegen. (Ich würde schon nen PR schicken, aber meine Kenntnisse in Go sind bislang "nicht vorhanden").

Use Case:

• Die direkte Kopplung von Homeassistant und Homematic ist gerne mal "schwergängig". Insbesondere neuere HM-IP-Geräte an einer CCU2 führen gerne zu Exceptions. Daher verwende ich ccu-jack und lasse meinen Mosquitto den Status von CCU-Jack replizieren. Das klappt 1A, ist aber im Homeassistant-Setup recht aufwändig bzw. teilweise manuell gar nicht möglich (Seriennummern, etc.)

Dokumentation:
https://www.home-assistant.io/docs/mqtt/discovery/

Puffer für Wertänderungen bei großen Installationen zu klein

Folgende Meldung wurde bei einer Installation mit 160 Geräten beobachtet: Notification lost, buffer size is too small: 250

Die Meldung ist soweit unkritisch. Der Puffer sollte aber auf 1000 erhöht werden.

Healthcheck Endpunkt und Programm bereitstellen

Hallo @mdzio,

für das Dockerfile hatte ich einen healthcheck vorgeschlagen. Dort wird schlicht innerhalb des Containers ein Aufruf mit curl auf http://localhost:2121 ausgeführt und auf die HTTP return codes 200 oder 401 geprüft. Diese Lösung ist nicht besonders schön und bricht natürlich, sobald der Benutzer den Port in der ccu-jack.cfg ändert.

Wäre es möglich einen entsprechenden Status direkt in ./ccu-jack vorzuhalten, diesen evtl. per Kommandozeile oder HTTP-Endpunkt (ggfs. auch nur intern für localhost:80/health) bereitzustellen und dann das ganze per separatem Programm ./healthcheck an den Benutzer/Container zu melden?

Referenzen:

• Beispiel-App: https://github.com/Soluto/golang-docker-healthcheck-example/blob/master/healthcheck/healthcheck.go
• k8s Konzept: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-liveness-http-request

Wertänderungen an einen externen MQTT-Server schicken

Der CCU-Jack könnte um eine MQTT-Bridge erweitert werden. Diese abonniert alle Topics des eingebetteten MQTT-Server und schickt die Wertänderungen an einen externen MQTT-Server.

Entsprechend ist auch die andere Richtung denkbar: Der CCU-Jack abonniert alle Wertänderungen von einem externen MQTT-Server und dupliziert sie auf den eingebetten Server.

MQTT client mode

Can ccu-jack run as a MQTT client?
I already run a Mosquitto server and want to integrate my CCU3.

Web-UI: Setzen von Datenpunkten

Für Testzwecke ist es hilfreich Datenpunkte über die Web-Benutzeroberfläche mit neuen Werten beschreiben zu können. Dies sollte im Navigator und in der Überwachungsliste möglich sein.

Warnmeldung in der hmserver.log auf der CCU bei einem Schnittstellen-Ping vom CCU-Jack

Fehlermeldung im hmserver.log:

Feb 9 23:19:20 de.eq3.cbcs.legacy.bidcos.rpc.internal.LegacyNotificationHandler WARN  [vert.x-worker-thread-4] No such device while filtering device parameters on event. 
de.eq3.cbcs.server.core.backend.DeviceNotFoundException
	at de.eq3.cbcs.legacy.bidcos.rpc.internal.DeviceUtil.getDeviceID(DeviceUtil.java:2956)

Dies wird zur selben Zeit vom CCU-Jack ausgeführt:

2021-02-09 23:19:20|DEBUG  |itf-client     |Calling method ping(CCU-Jack-HmIP-RF-Ping) on http://127.0.0.1:2010
...
2021-02-09 23:19:20|DEBUG  |itf-server     |Call of method event received: CCU-Jack-HmIP-RF, CENTRAL:0, PONG, CCU-Jack-HmIP-RF-Ping

Die Fehlermeldung im hmserver.log ist unkritisch.

Etwas Abhilfe könnte die Erhöhung des Schnittstellen-Timeouts auf 5 Minuten bringen. Oder, falls keine HM-IP Geräte an der CCU angelernt worden sind, die Schnittstelle für HM-IP in der Konfigurationsdatei zu deaktivieren.

Als Abhilfe könnte auch ein Programm auf der CCU angelegt werden, der einen virtuellen HM-IP Taster alle 50 Sekunden drückt.

Siehe auch Foren-Beitrag.

CCU2: Für die Zeitstempel der ReGaHss wird eine falsche Zeitzone verwendet

Wahrscheinlich kann der CCU-Jack auf einer CCU2 nicht die eingestellte Zeitzone erkennen. Die Zeitstempel werden als UTC angenommen.

Für die Übermittlung des Zeitstempels ist es vielleicht günstiger die Unix-Sekunde zu verwenden. Diese kann in HM-Skript mit ts.ToInteger() ermittelt werden. Diese hängt nicht von der Zeitzone ab.

Gerätetyp (z.B. HmIP-SWDO-I) als Eigenschaft zur Geräteliste hinzufügen

In der Geräteliste (/device) soll bei den Verweisen die Eigenschaft type (Gerätetyp) hinzugefügt werden.

Idee aus #26.

Programme der CCU über REST-API und MQTT

Es sollte die Möglichkeit bestehen, die Programme der CCU aufzulisten und anzustoßen.

Kommandozeilenoption für den Pfad zur Konfigurationsdatei

Zusätzlich sollte noch in der Konfigurationsdatei der Dateipfad für die Web-Applikation konfigurierbar sein.

Optimierte Raspberry Pi 4 Version (ARM64)

s.a. #33

Docker: build-nightly.sh schlägt fehlt

build-nightly.sh funktioniert nicht wie geplant

Step 5/18 : RUN cd ccu-jack-master/build && go run .
 ---> Running in 9fbc292c9585
go: downloading github.com/mdzio/go-logging v1.0.0
go: downloading github.com/mdzio/go-lib v0.1.5
INFO   |Building application: ccu-jack
INFO   |Version: 2.0.1
[...]
Step 13/18 : COPY --from=builder /app/ccu-jack-master/ccu-jack-linux-${BUILD_VERSION}.tar.gz .
COPY failed: stat app/ccu-jack-master/ccu-jack-linux-1.1.1.tar.gz: file does not exist

ich kümmere mich darum :-)

Dockerfile und build-release.sh passen nicht für einen Raspberry

Zwei Probleme:

• hart codiertes *tar.gz für linux/amd64: ccu-jack-linux-${BUILD_VERSION}.tar.gz
• wget bricht bei der Erstellung des Images ab (tar.gz wurde vorab an einen Raspberry angepasst):

Step 6/11 : RUN wget -q -O - "https://github.com/mdzio/ccu-jack/releases/download/v1.1.1/ccu-jack-ccu3-rm-rp2+3-1.1.1.tar.gz" | tar -xvzC . &&     mkdir -p /app/conf /app/cert /data &&     adduser -h /app -D -H ccu-jack -u 1000 -s /sbin/nologin &&     chown -R ccu-jack:ccu-jack /data && chmod -R g+rwX /data &&     chown -R ccu-jack:ccu-jack /app && chmod -R g+rwX /app
 ---> Running in 627488d713af
wget: bad address 'github.com'
tar: invalid magic
tar: short read
The command '/bin/sh -c wget -q -O - "https://github.com/mdzio/ccu-jack/releases/download/v1.1.1/ccu-jack-ccu3-rm-rp2+3-1.1.1.tar.gz" | tar -xvzC . &&     mkdir -p /app/conf /app/cert /data &&     adduser -h /app -D -H ccu-jack -u 1000 -s /sbin/nologin &&     chown -R ccu-jack:ccu-jack /data && chmod -R g+rwX /data &&     chown -R ccu-jack:ccu-jack /app && chmod -R g+rwX /app' returned a non-zero code: 1

CCU Add-On: Download-Link in der CCU-Systemsteuerung falsch

MQTT: Auslösen des Lesens einer Systemvariable auch bei interner Aktualisierung durch CCU

Schon jetzt werden Änderungen an Systemvariablen bereits nach 300/400 ms gelesen und an Subscriber publiziert, wenn sie von einem (externen) MQTT-Client geändert wurden.
Bei internen Änderungen durch die CCU-Logikschicht erfolgt das erst nach dem zyklischen Lesen (1/s) der mit "MQTT" gekennzeichneter Systemvariablen. Bei einer größeren Anzahl kann es daher lange dauern, z.B. 60 Sekunden bei 60 MQTT-Variablen, bis die Änderung am MQTT-Subscriber ankommt.
Im Gegensatz dazu kommen Status-Änderungen von Geräten nahezu "sofort" an. Wenn nun die Zustände mehrerer Geräte in einer Systemvariable aggregiert werden ("Eine Tür ist offen"), führt das vorübergehend zu irritierenden Inkonsistenzen auf der Anzeige (alle Türen werden einzeln als "Geschlossen" angezeigt, die Systemvariable zeigt aber "offen" an), solange bis CCU-Jack die Liste abgearbeitet hat.

Wäre es möglich, geänderte Systemvariablen auch dann zu lesen bzw. publizieren, wenn sie von innerhalb der CCU geändert wurden?

Virtuelle Geräte für eine bessere Integration in die CCU-Automatisierung

Bisher lag das Augenmerk darauf, dass externe Applikationen leicht über die MQTT- oder REST-API auf CCU-Datenpunkte zugreifen können. In der Version 2 des CCU-Jacks wird der Schwerpunkt auf eine leichtere Integration in die CCU-Automatisierung (z.B. in die CCU-Programme) gelegt.

Dafür soll der CCU-Jack virtuelle Geräte auf der CCU anlegen können. Diese können wie reale HM-Geräte über die Web-UI bedient, konfiguriert, in Programmen abgefragt und von Programmen gesteuert werden. Das Innenleben der Geräte wird je nach Anwendungszweck entworfen.

Die erste Typ von virtuellen Geräten realisiert rein statische Geräte ohne interne Logik. Dies dient dazu neue Datenpunkte zu generieren, die mit CCU-Programmen direkt verknüpft werden können. Dadurch ist der funktional eingeschränkte Umweg über Systemvariablen nicht mehr nötig.

Fortschritt:

• Implementierung fehlender XML-RPC-Methoden für Geräteschnittstellenprozesse
• Basisfunktionalität eines Geräteschnittstellenprozesses
• Hülle für ein Gerät
• Hülle für den Wartungskanal
• Hülle für ein Taster-Kanal
• Hülle für ein Schalter-Kanal
• Anpassung des Start-Skripts, damit der CCU-Jack vor der ReGaHss gestartet wird.

Meilenstein: Erste auf der CCU funktionierende virtuelle Geräte.

• Laden der bisher erstellten virtuellen Geräte aus der Konfigurationsdatei.
• Erweiterung CCU-Jack Web-UI zur Verwaltung der virtuellen Geräte.
• Anbindung der virtuellen Geräte an die REST-API
• Anbindung der virtuellen Geräte an die MQTT-API

Meilenstein: Veröffentlichung CCU-Jack mit virtuellen Geräten.

Erweiterungen:

• Hülle für einen analogen Messwert (z.B. wie bei HmIP-MIO16-PCB)
• Hülle für einen analogen Stellwert (z.B. wie bei HmIP-FROLL)

REST: Mehrere CORS-Origins sollten konfigurierbar sein

Dies wird intern im CCU-Jack bereits unterstützt. Es ist aber noch nicht über Kommandozeilenparameter konfigurierbar.

CORS Error bei API Zugriff aus Angular App

Moderne Webanwendungen erwarten den Response-Header Access-Control-Allow-Origin in der Antwort von Server. Andernfalls wird die Antwort abgeblockt und nicht weiter verarbeitet.

Aktueller Workaround: Proxy zwischen CCU und WebApp, welcher den Header setzt.

Das Setzen des folgenden Headers in jeder Response würde das Problem beheben:
Access-Control-Allow-Origin: *

Option um das CCU-Zertifikat zu nutzen

Falls auf der CCU schon ein TLS Zertifikat existiert, könnte dieses verwendet werden anstatt ein neues Zertifikat zu erstellen.
Die CCU verwendet ein kombiniertes PEM Zertifikat das CA und auch den Key enthält : /etc/config/server.pem

Eine Möglichkeit ist /etc/config/server.pem in das CCU-Jack Verzeichnis als svrcert.pem und svrcert.key zu kopieren .

cd <ccujackdir>
cp /etc/config/server.pem svrcert.pem
cp /etc/config/server.pem svrcert.key

Oder CCU-Jack überprüft beim start ob /etc/config/server.pem vorhanden ist und benutzt dann dieses Zertifikat

Begündung:
Ich erstelle meine Zertifikate über meine eigene CA der bereits in allen Browsern vertraut wird und möchte gerne darauf verzichten immer wieder neuen Zerts vertauen zu müssen

MQTT: Unterstützung für WebSocket-Protokoll

Damit Web-Applikationen im Browser sich über MQTT mit dem CCU-Jack verbinden können, muss eine Unterstützung für WebSockets eingebaut werden.

CCU3 Add-On: Bei Update Konfigurationsdatei beibehalten

Setzen von Werten in SysVars möglich ?

Hallo

Wie der Titel schon beschreibt, können damit auch Werte in SysVars gesetzt werden ?

lg Richard

Startparameter beim Start aus Textdatei lesen

Enhancement Request:
Es wäre von Vorteil, wenn die Startparameter nicht in die Kommandozeile eingegeben werden müsste sondern aus einer Datei gelesen werden könnte, welche im gleichen Verzeichnis liegt wie die ccu-jack exe Datei.
Dies würde eine Plattformübergreifende gleiche Konfiguration ermöglichen
und man müsste bei linux oder ccu dann nicht in die shell scripts für die Startkonfiguration eingreifen, oder bei Windows als Service wären keine Registry oder Batch Datei Änderungen notwendig.

Unterstützung für die Homie MQTT-Konvention

Diese Konvention wird auf https://homieiot.github.io/ beschrieben.

Anzeige von Log-Meldungen auf dem Web-Fronend

Für eine einfachere und schneller Fehlerdiagnose sollten auf dem Web-Frontend Diagnosedaten angezeigt werden können. Als erstes sollten die Log-Meldungen abrufbar sein.

Installation auf piVCCU auf Raspberry Pi 4 funktioniert nicht

Aus der Zuordnung der Distributionen zum Zielsystem geht nicht hervor, welche für die Installation von ccu-jack auf pivCCU3 korrekt ist.
Bei der Installation von pivCCu3 auf einem Raspberry4 funktioniert die Version für "RaspberryMatic auf Raspberry Pi 4" nicht.
Es muss die Version " CCU3 oder RaspberryMatic auf Raspberry Pi 2, 3" installiert werden.
Eine entsprechende Anmerkung würde dem ein oder anderen sicher einiges an Fehlersuche ersparen.

Fehlende Datenpunkteigenschaften (SPECIAL, VALUE_LIST)

Für die Datentypen FLOAT und INTEGER fehlt die Eigenschaft SPECIAL. In dieser werden Werte mit einer besonderen Bedeutung aufgelistet.

Für den Datentyp ENUM fehlt die Eigenschaft VALUE_LIST. Mit dieser können die Zahlenwerte auf Texte abgebildet werden.

Dies sind die letzten fehlenden Eigenschaften aus den Schnittstellenprozessen der CCU.

Navigator sollte die MQTT-Topics je Datenpunkt auflisten

Bei den Eigenschaften der Datenpunkte sollten auch die MQTT-Topics im Navigator angezeigt werden. Dadurch können sie schneller durch Kopieren und Einfügen in andere Anwendungen übernommen werden.

Über die REST-API sollen die Topics ebenfalls erkundet werden können.

MQTT: Setzen einer Systemvariable löst ein Lesen kurz danach aus

400 Millisekunden nach dem Setzen einer Systemvariablen über MQTT wird diese aus der CCU wieder ausgelesen und der Wert über MQTT veröffentlicht.

Dies ist besonders hilfreich, wenn über eine Visualisierung Systemvariablen verändert werden. Dadurch erhält die Visualisierung sofort eine Rückmeldung über den geänderten Wert.

MQTT: Gemeinsames zyklisches Lesen aller markierten Systemvariablen

Die für MQTT markierten Systemvariablen (mit MQTT in der CCU-Variablenbeschreibung) werden nun alle gemeinsam alle 3 Sekunden auf Änderungen überprüft. Bei Änderung/Aktualisierung wird der Wert dann per MQTT versendet. Die Zykluszeit ist so nicht mehr von der Anzahl der Systemvariablen abhängig.