Unterstützung für CUxD

[twendt]

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

[mdzio]

Ich wechsle einfach mal ins Deutsche:

Erst einmal freue ich mich natürlich über jeden Mitstreiter im Projekt.

Über die Unterstützung vom CUxD habe ich auch lange nachgedacht, und dann auf unbestimmte Zeit verschoben. Ich nutze ihn selber nicht und wollte daher erst einmal auf Anwender warten, die die Unterstützung benötigen. Jetzt gibt es den ersten Anwendungsfall.

Ich selber habe auch bereits einmal das komplette BIN-RPC-Protokoll für den CCU-Historian in Groovy implementiert. Für die Validierung konnte ich auf die C++ Originalquellen der Implementierung in der ReGaHss zurückgreifen. Diese ist Open-Source und (hoffentlich noch) im OCCU-Repo zu finden. Für Go hatte ich Encoder und Decoder fertig, bis ich die Implementierung gestoppt habe.

Ein kurzer Blick auf Deine Implementierung sieht vielversprechend aus, und ich würde sie auch langfristig mit in den CCU-Jack aufnehmen wollen. Vorher müsste ich mir Deine Erweiterungen und Änderungen nochmal genau anschauen (Code-Review) und selbst ein paar Tests durchführen. Vielleicht könntest Du noch die Installation als Add-On testen. Ein Pull-Request brauchst Du noch nicht machen, ich kann erst einmal mit Deinem Repo arbeiten. Bitte nicht ungeduldig werden, wenn der Code-Review etwas länger dauert. Aber wenn Du den CCU-Jack für deine Homey-Anbindung einsetzen möchtest, dann wird er auch eine CUxD-Unterstützung bekommen.

Viele Grüße
Mathias

[twendt]

Hallo Mathias,

vielen Dank für deine schnelle Antwort.

Das klingt ja sehr vielversprechend. Ich habe den CCU Jack nun bei mir inklusive CUxD support auf meiner CCU laufen. Es funktioniert bisher ohne Probleme.
Ich werde die Tage schauen, dass ich meine Homey App zum Testen anpasse und eine Anbindung über den CCU Jack als Alternative einbaue. Dann kann ich das bei mir damit laufen lassen und besser sehen, wie zuverlässig die Implementierung ist.

Da ich bisher direkt mit der CCU kommuniziert habe, verwendet meine Implementierung intern auch den InterfaceTyp, also HmIP-RF, BidCos-RF oder CUxD. Diese Info bekomme ich aktuell beim CCU Jack nicht geliefert. Könnte man das in den Attributen der Devices eventuell noch mit aufnehmen? Ansonsten könnte ich es mit vermutlich aus einer Kombination aus dem Type und der Adresse herleiten.

Beim Anlernen der Geräte im Homey muss zunächst ein Gerätetyp ausgewählt werden. In der App werden dann alle Geräte dieses Typs aufgelistet. Um das über die API vom CCU Jack zu machen, muss ich dafür die Device Description von allen Geräten abfragen. Gäbe es eine Möglichkeit, dass man den Typ als Filter mitgeben kann, oder dass der Type als Attribut in der Device Liste ausgegeben wird?

Gruß,
Timo

[twendt]

Ich habe eine erste Version meiner App gebaut, die den CCU Jack verwendet. Die Implementierung läuft bei mir seit einigen Tagen ohne Probleme.

[mdzio]

Ich habe mir den Code nochmal genauer angeschaut, und er sieht gut aus. Ich plane ihn dann suksessive zu prüfen und in den CCU-Jack einzubauen. Aber das dauert etwas.

[mdzio]

Du kannst gerne einen Pull-Request stellen.

[twendt]

Super, werde ich machen.

[mdzio]

Die Anpassungen erfolgen zurzeit im Repo mdzio/go-hmccu. Das dortige Issue ist mdzio/go-hmccu#2.

[mdzio]

Hallo Timo,
konntest Du Deine Homey App schon weiter entwickeln. Oder fehlt noch etwas im CCU-Jack?

[twendt]

Hallo Mathias,

meine App läuft schon seit einiger Zeit mit dem CCU Jack bei mir und auch bei ersten Test-Usern. Die Test-User haben allerdings keinen CUxD. Ich selber habe den CUxD im Einsatz, hatte aber bisher den CCU Jack in der Version aus meinem PR eingesetzt. Ich habe nun heute auf die 1.1.0 umgestellt und bisher läuft es ohne Probleme.

Vielen Dank für die Implementierung..