CCU-Jack: REST-API/MQTT-Server/MQTT-CCU-Adapter
Moderator: Co-Administratoren
-
- Beiträge: 21
- Registriert: 16.12.2021, 12:19
- System: CCU und Access Point
- Wohnort: Harsum
- Hat sich bedankt: 4 Mal
Re: CCU-Jack: REST-API/MQTT-Server/MQTT-CCU-Adapter
Moin zusammen,
ich bin noch recht frisch in der CCU / HomeMatic Welt und hoffe ich stelle die Frage gerade an der richtigen Stelle...
Ich nutze eine CCU3 mit RasperryMatic und CCU-Jack. Da mir die Programmierung auf der CCU nicht wirklich gefällt leite ich alle meine Sensoren / Aktoren via MQTT an eine Beckhoff TC3 RT weiter und führe hier die komplette Logik aus. Die CCU dient für mich also "nur" als "Gateway".
Nun funktioniert bisher alles wirklich gut!
1. Aber, wie kann ich von meinen Geräten das $MASTER Topic subsciben? DAs bekomme ich einfach nicht auf die Reihe...
2. Ich benutze bisher nur CCU Jack, keinen weiteren Broker. In der Beckhoff RT ist auch ein JSON Interface integriert, mit diesem kann ich auf alle Variablen des ADS Servers via MQTT zugreifen. Gibt es eine Möglichkeit bei CCU Jack diese Topics zu subscriben bzw. auf diese Topics zu publishen?
Vielen Dank schon mal
Grüße Sascha
ich bin noch recht frisch in der CCU / HomeMatic Welt und hoffe ich stelle die Frage gerade an der richtigen Stelle...
Ich nutze eine CCU3 mit RasperryMatic und CCU-Jack. Da mir die Programmierung auf der CCU nicht wirklich gefällt leite ich alle meine Sensoren / Aktoren via MQTT an eine Beckhoff TC3 RT weiter und führe hier die komplette Logik aus. Die CCU dient für mich also "nur" als "Gateway".
Nun funktioniert bisher alles wirklich gut!
1. Aber, wie kann ich von meinen Geräten das $MASTER Topic subsciben? DAs bekomme ich einfach nicht auf die Reihe...
2. Ich benutze bisher nur CCU Jack, keinen weiteren Broker. In der Beckhoff RT ist auch ein JSON Interface integriert, mit diesem kann ich auf alle Variablen des ADS Servers via MQTT zugreifen. Gibt es eine Möglichkeit bei CCU Jack diese Topics zu subscriben bzw. auf diese Topics zu publishen?
Vielen Dank schon mal
Grüße Sascha
-
- Beiträge: 1783
- Registriert: 03.11.2010, 10:25
- System: CCU
- Wohnort: Aachen
- Hat sich bedankt: 58 Mal
- Danksagung erhalten: 259 Mal
- Kontaktdaten:
Re: CCU-Jack: REST-API/MQTT-Server/MQTT-CCU-Adapter
Hallo Sascha.
Gruß
Mathias
Die $MASTER-Variable, die die Geräteeinstellungen enthält, kann zurzeit nur über die REST-API gelesen und beschrieben werden. Im bisherigen Ansatz vom CCU-Jack werden über MQTT nur Online-Werte (Parametersatz VALUES von HM-Geräten) und keine Konfigurationswerte (Parametersatz MASTER) übertragen. Technisch ist ein Subscribe auf Konfigurationswerte auch nicht möglich.Conhulio1980 hat geschrieben: ↑16.12.2021, 12:381. Aber, wie kann ich von meinen Geräten das $MASTER Topic subsciben? DAs bekomme ich einfach nicht auf die Reihe...
Der CCU-Jack kann sich nicht mit anderen MQTT-Brokern/Servern verbinden. Dieses Feature ist aber von vielen schon angefragt worden und auch bereits für die nächste Version notiert.Conhulio1980 hat geschrieben: ↑16.12.2021, 12:382. Ich benutze bisher nur CCU Jack, keinen weiteren Broker. In der Beckhoff RT ist auch ein JSON Interface integriert, mit diesem kann ich auf alle Variablen des ADS Servers via MQTT zugreifen. Gibt es eine Möglichkeit bei CCU Jack diese Topics zu subscriben bzw. auf diese Topics zu publishen?
Gruß
Mathias
Re: CCU-Jack: REST-API/MQTT-Server/MQTT-CCU-Adapter
hallo allerseits,
ganz kurz
1) fröhliche weihnachten und nen guten rutsch
2) sorry, falls das folgende obstrus oder trivial bekannt ist. ich hab mich zwar grad registriert, lese hier aber schon seit jahren
3) ich hab seit jahren auf diesen ccu jack gewartet und habe gestern gemerkt, dass ihn endlich jemand erfunden und implementiert hat!! danke !!!! mein hauptproblem waren immer tasmota geräte und bis heute unschöne anbindungen im hand und fuss betrieb. dass nun ALLES der ccu per mqtt bedienbar ist, ist natürlich toll, aber das waren meine tasmotas bisher ja auch schon. der heilige gral sind für mich die virtuellen mqtt geräte, die eeendlich "normal" erscheinen. auch die statischen dummen geräte, die ich denke als ersatz für systemvariablen einsetzen zu können sind großartig.
so nun die eigentliche frage:
ich habe eine visualisierung mit redmatic am laufen und benutze die redmatic value nodes zum spiegeln der ccu devices. aber das scheint nicht für die tollen neuen virtuelle geräte des CCU-Jack interfaces zu gelten... ihr merkt woraus ich raus will: entweder checke ich irgendwas triviales nicht, oder irgendwas ist kaputt (die ccu config im node red erlaubt ja das interface "Virtual Devices", aber die liste ist immer leer), oder man ist schlicht noch nicht so weit, oder man sagt mir, ich soll doch gleich per mqtt aus der redmatic darauf zugreifen. ja klar, letzteres geht. aber so weit war ich ja vorher auch schon: pro datenpunkt mqtt in, mqtt out, dashboard switch und fertig. aber das viel einfachere spiegeln mit der value node, wäre für mich der finale gewinn, um die redundanz und das gestrüpp in node red gering zu halten. wie komme ich also nun noch dahin? ist die antwort ein feature request im redmatic projekt, dass das interface "CCU-Jack" ebenfalls verfügbar gemacht (und gelistet) werden kann? ich würde dort die frage stellen, ob die integration trivial ist und in der ccu-connection.js ab zeile 354 vorgenommen werden KÖNNTE. diese frage würde ggfs wiederum aber hier besser beantwortet werden können
ganz kurz
1) fröhliche weihnachten und nen guten rutsch
2) sorry, falls das folgende obstrus oder trivial bekannt ist. ich hab mich zwar grad registriert, lese hier aber schon seit jahren
3) ich hab seit jahren auf diesen ccu jack gewartet und habe gestern gemerkt, dass ihn endlich jemand erfunden und implementiert hat!! danke !!!! mein hauptproblem waren immer tasmota geräte und bis heute unschöne anbindungen im hand und fuss betrieb. dass nun ALLES der ccu per mqtt bedienbar ist, ist natürlich toll, aber das waren meine tasmotas bisher ja auch schon. der heilige gral sind für mich die virtuellen mqtt geräte, die eeendlich "normal" erscheinen. auch die statischen dummen geräte, die ich denke als ersatz für systemvariablen einsetzen zu können sind großartig.
so nun die eigentliche frage:
ich habe eine visualisierung mit redmatic am laufen und benutze die redmatic value nodes zum spiegeln der ccu devices. aber das scheint nicht für die tollen neuen virtuelle geräte des CCU-Jack interfaces zu gelten... ihr merkt woraus ich raus will: entweder checke ich irgendwas triviales nicht, oder irgendwas ist kaputt (die ccu config im node red erlaubt ja das interface "Virtual Devices", aber die liste ist immer leer), oder man ist schlicht noch nicht so weit, oder man sagt mir, ich soll doch gleich per mqtt aus der redmatic darauf zugreifen. ja klar, letzteres geht. aber so weit war ich ja vorher auch schon: pro datenpunkt mqtt in, mqtt out, dashboard switch und fertig. aber das viel einfachere spiegeln mit der value node, wäre für mich der finale gewinn, um die redundanz und das gestrüpp in node red gering zu halten. wie komme ich also nun noch dahin? ist die antwort ein feature request im redmatic projekt, dass das interface "CCU-Jack" ebenfalls verfügbar gemacht (und gelistet) werden kann? ich würde dort die frage stellen, ob die integration trivial ist und in der ccu-connection.js ab zeile 354 vorgenommen werden KÖNNTE. diese frage würde ggfs wiederum aber hier besser beantwortet werden können
-
- Beiträge: 1783
- Registriert: 03.11.2010, 10:25
- System: CCU
- Wohnort: Aachen
- Hat sich bedankt: 58 Mal
- Danksagung erhalten: 259 Mal
- Kontaktdaten:
Re: CCU-Jack: REST-API/MQTT-Server/MQTT-CCU-Adapter
Das stimmt. Die Value Nodes unterstützen nur die Standard-CCU-Schnittstellen (BidCos-RF, HmIP-RF, ...) und CUxD. Die virtuellen Geräte des CCU-Jacks stehen in keiner Beziehung zu der VirtualDevices-Schnittstelle der CCU.
Ja.
Ich habe mal in die ccu-connection.js hineingeschaut. Dort müsste eine neue Schnittstelle in Zeile 417 eingefügt werden:
Code: Alles auswählen
'CCU-Jack': {
conf: 'jack',
rpc: xmlrpc,
port: 2121,
path: 'RPC3',
protocol: 'http',
init: true,
ping: true
},
Gruß
Mathias
Re: CCU-Jack: REST-API/MQTT-Server/MQTT-CCU-Adapter
danke für die antwort
hab mich durchgebissen und (mit lokalen verbindungen / ports) getestet und nen pull request gemacht.
bin begeistert
hab mich durchgebissen und (mit lokalen verbindungen / ports) getestet und nen pull request gemacht.
bin begeistert
- Baxxy
- Beiträge: 10779
- Registriert: 18.12.2018, 15:45
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 604 Mal
- Danksagung erhalten: 2205 Mal
Re: CCU-Jack: REST-API/MQTT-Server/MQTT-CCU-Adapter
Hallo Mathias,
es gibt ja eine separate Pi4 Version vom Jack.
Die hatte ich aus Versehen auf einer RaspberryMatic mit Pi3B+ installiert und musste feststellen das das problemlos läuft.
Wo ist der Unterschied zwischen der Pi2/3/CCU3 - Version und der Pi4 - Version?
Hängt das mit der Systemarchitektur (32/64bit) zusammen?
Wobei ja RaspberryMatic auch auf 3er Pi's seit 3.53.34.20201121 in 64bit läuft.
Welche Version nimmt man beim TinkerS? Soweit ich weiß läuft das in 32bit mit RM.
Grüße, Baxxy
es gibt ja eine separate Pi4 Version vom Jack.
Die hatte ich aus Versehen auf einer RaspberryMatic mit Pi3B+ installiert und musste feststellen das das problemlos läuft.
Wo ist der Unterschied zwischen der Pi2/3/CCU3 - Version und der Pi4 - Version?
Hängt das mit der Systemarchitektur (32/64bit) zusammen?
Wobei ja RaspberryMatic auch auf 3er Pi's seit 3.53.34.20201121 in 64bit läuft.
Welche Version nimmt man beim TinkerS? Soweit ich weiß läuft das in 32bit mit RM.
Grüße, Baxxy
-
- Beiträge: 1783
- Registriert: 03.11.2010, 10:25
- System: CCU
- Wohnort: Aachen
- Hat sich bedankt: 58 Mal
- Danksagung erhalten: 259 Mal
- Kontaktdaten:
Re: CCU-Jack: REST-API/MQTT-Server/MQTT-CCU-Adapter
Das ist erklärbar, wenn RaspberryMatic auch auf 3er Pi's in 64bit läuft. Sowohl CPU (ARMv8) als auch Betriebsystem müssen 64 Bit unterstützen.Baxxy hat geschrieben: ↑01.01.2022, 16:09es gibt ja eine separate Pi4 Version vom Jack.
Die hatte ich aus Versehen auf einer RaspberryMatic mit Pi3B+ installiert und musste feststellen das das problemlos läuft.
Wo ist der Unterschied zwischen der Pi2/3/CCU3 - Version und der Pi4 - Version?
Hängt das mit der Systemarchitektur (32/64bit) zusammen?
Wobei ja RaspberryMatic auch auf 3er Pi's seit 3.53.34.20201121 in 64bit läuft.
Die 32 Bit-Version läuft ebenfalls, da sowohl die 64-Bit CPU als auch das 64-Bit Betriebssystem mit 32-Bit Software in diesem Fall klar kommen. Die 64 Bit-Version müsste aber etwas performanter laufen.
Bei den Downloads für den CCU-Jack lasse ich es aber bei der 32-Bit Version, da eventuell noch alte RM-Versionen im Einsatz sind. Die Download-Tabelle ist jetzt schon für manche zu komplex.
Die Zuordnung müsste folgermaßen sein:
Tinker Board/Tinker Board S: ccu3-rm-rp2+3
Tinker Edge T/Tinker Edge R/Tinker Board 2/Tinker board 2S: rm-rp4 (Wenn es denn eine RM-Version für diese Boards gibt.)
Gruß
Mathias
-
- Beiträge: 79
- Registriert: 04.01.2020, 08:43
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Baden bei Wien
- Hat sich bedankt: 6 Mal
- Danksagung erhalten: 4 Mal
Re: CCU-Jack: REST-API/MQTT-Server/MQTT-CCU-Adapter
Also vorab: mein Mädl hat heute ein Jubelmeldung gemacht - CCU Jack ist das Tool, das ihr das Leben erleichtert.
Zuerst auf zwei CCUs ausprobiert - toll!
Dann wollte sie es auf unserer debmatic in Betrieb nehmen. Da ich aber eine "Gewaltentrennung" bevorzuge und keine Installations-Side-Effects auf unserem Herzstück wollte habe ich hierfür eine eigene Debian VM installiert. Dann den CCU-Jack dort eingerichtet und letztendlich gestartet.
Ja, eigentlich ganz nett - nur: buffer size is too small: 1000
Also ein bisserl lesen gegangen - und siehe da, offensichtlich: je mehr Geräte desto größer der benötigte Buffer.
Dazu nun meine Frage: es gibt ja ein Config FIle. Sehe ich das richtig, dass die Buffer Size Hard-Coded ist - oder hab ich hier etwas übersehen?
Wir haben da eh nur so um die 400 HMiP Devices: was wäre denn hier der bessere Buffer-Size-Wert - und wie könnte man den ändern?
Liebe Grüße aus Baden bei Wien
Peter
Zuerst auf zwei CCUs ausprobiert - toll!
Dann wollte sie es auf unserer debmatic in Betrieb nehmen. Da ich aber eine "Gewaltentrennung" bevorzuge und keine Installations-Side-Effects auf unserem Herzstück wollte habe ich hierfür eine eigene Debian VM installiert. Dann den CCU-Jack dort eingerichtet und letztendlich gestartet.
Ja, eigentlich ganz nett - nur: buffer size is too small: 1000
Also ein bisserl lesen gegangen - und siehe da, offensichtlich: je mehr Geräte desto größer der benötigte Buffer.
Dazu nun meine Frage: es gibt ja ein Config FIle. Sehe ich das richtig, dass die Buffer Size Hard-Coded ist - oder hab ich hier etwas übersehen?
Wir haben da eh nur so um die 400 HMiP Devices: was wäre denn hier der bessere Buffer-Size-Wert - und wie könnte man den ändern?
Liebe Grüße aus Baden bei Wien
Peter
-
- Beiträge: 1783
- Registriert: 03.11.2010, 10:25
- System: CCU
- Wohnort: Aachen
- Hat sich bedankt: 58 Mal
- Danksagung erhalten: 259 Mal
- Kontaktdaten:
Re: CCU-Jack: REST-API/MQTT-Server/MQTT-CCU-Adapter
So ein Mädl hätte ich auch gerne.
Code: Alles auswählen
buffer size is too small: 1000
Wieviele Meldungen bekommst Du denn? Dann kann ich die Puffergröße erhöhen. Sie ist hart kodiert und nicht konfigurierbar.
Die Meldung sollte nur ein Hinweis sein. Ich werde die Dringlichkeit von ERROR auf DEBUG ändern.
"nur" ist lustig. Ich wusste gar nicht, dass die CCU mit so vielen Geräten klar kommt.
-
- Beiträge: 79
- Registriert: 04.01.2020, 08:43
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Baden bei Wien
- Hat sich bedankt: 6 Mal
- Danksagung erhalten: 4 Mal
Re: CCU-Jack: REST-API/MQTT-Server/MQTT-CCU-Adapter
Kann ich verstehen - geb sie aber nicht mehr her
Code: Alles auswählen
buffer size is too small: 1000
Die Meldung kommt 583 mal.Mathias hat geschrieben: ↑28.01.2022, 22:48Während der Startphase des CCU-Jacks, in der er noch mit anderen Sachen beschäftigt ist, werden bereits erste Wertänderungen von Datenpunkten von der CCU übermittelt. Für die Zwischenspeicherung dieser ist der Puffer. Die Meldungen sollten nur beim Start erscheinen.
Wieviele Meldungen bekommst Du denn? Dann kann ich die Puffergröße erhöhen. Sie ist hart kodiert und nicht konfigurierbar.
Die Meldung sollte nur ein Hinweis sein. Ich werde die Dringlichkeit von ERROR auf DEBUG ändern.
Nun, die CCU3 kommt damit auch nicht klar. Aber die Debmatic in einer sehr sauberen VM Umgebung nimmt das mit links.