Eigenes Device in CCU

[leknilk0815]

Danke, wieder was gelernt...
(obwohl ich das eigentlich noch wissen müsste... na ja, Alz... - warum piept jetzt meine Schreibmaschine.. )

[Schrauber]

Das Thema würde mich auch interessieren.

Ich bin dabei einen OW-Server-Enet (1-Wire) in HM einzubinden. Der liefert ein XML mit sämtlichen Messwerten der angeschlossenen 1-Wire-Geräte. Die Idee war dieses XML mit TCL zu parsen und so die Werte zu extrahieren. Soweit, so einfach.
Es stellt sich nun die Frage, wie man die extrahierten Messwerte in der CCU nutzbar macht. Natürlich kann man einfach entsprechend viele Systemvariablen anlegen und die aus dem TCL-Code setzen.
Schöner wäre, wenn man für die 1-Wire-Sensoren "neue virtuelle Geräte" in der CCU definieren könnte, die dann auch funktionieren wie echte Geräte. Das wäre der Idealzustand.

Ein Mapping der ermittelten Werte auf bestehende HM-Geräte wäre aber auch schonmal was.
Ich habe aber noch nicht einmal eine Idee, wie ich der HM aus TCL heraus (oder wie auch immer) ein Geräte unterjuble, das physisch gar nicht vorhanden ist.

Für Tips wäre ich dankbar. Wie macht CUxD das?

[TinkyWinky]

Nun ist schon etwas Zeit ins Lang gegangen. Was kam denn raus?

Ist der Weg über CUxD sinnvoll oder wäre CCU-Jack besser geeignet?

Ich habe eine Tüte DS18B20 und DHT11/22 Sensoren, die derzeit noch von einem Raspi ausgelesen werden, der ihre Werte per XMLRPC in die CCU einspeist. Nicht so schön und oversized. Ein Raspi Pico W reicht eigentlich. Einspeisung der Daten als eigenes virtuelles Gerät wäre schöner.

[Mathias]

Der CCU-Jack stellt statische virtuelle Geräte, also ohne irgendeine interne Logik, für diesen Zweck zur Verfügung. Diese können dann über eine REST-API oder MQTT von außen angesteuert oder abgefragt werden. In der CCU sehen sie dann aus, wie normale HM-Geräte.

[TinkyWinky]

Danke, das klingt brauchbar. Dann fräse ich mich mal rein.