Hm-rpc: Wie Device/Channel erweitern

[klassisch]

Hallo,

habe eine HM-Installation mit ioBroker gekoppelt. Läuft.

Mittlerweile kommen viele der Daten von einem ESP8266 über ein CUxD device zur HM und dann zum ioBroker. Läuft.

Jetzt möchte ich aber zusätzliche Datenspuren anlegen, die

• vom ESP8266 direkt an ioBroker übertragen werden

• direkt in der Hierarchie des bereits angelegten HM-Devices landen

Dazu habe ich einen bereits vohandenen channel eines CUxD Wrapper devices erweitert. Also z.B. in dem vorhandenen Channel

"hm-rpc.1.CUX9000056.0" einen zustätzlichen state

"hm-rpc.1.CUX9000056.0.zusatzdatum"

eingefügt.

Das Einfügen funktioniert. Der Wert läßt sich auch auch vom Browser her beschreiben.

Aber all das wird jedesmal mit einer Fehlermeldung des hm-rpc bestraft:

hm-rpc.1	2017-12-17 09:15:01.607	error	binrpc -> setValue: no dpType for hm-rpc.1.CUX9000056.0.zusatzdatum!

Kann man das irgendwie vermeiden? Kann man dem hm-rpc-Adapter klar machen, daß diese Datenspur valide ist, auch wenn sie auf der HM-Seite keinen direkten Partner hat?

Die Fehlermeldungen sind nicht nur störend, es könnte ja auch sein, daß der Adapter beim nächsten "Neu laden" oder Hochfahren, die aus seiner Sicht unauthorisierten Datenspuren einfach wegputzt.

[Homoran]

Hallo klassisch,
@klassisch:

Aber all das wird jedesmal mit einer Fehlermeldung des hm-rpc bestraft `
Klar, weil der Adapter bidirektional arbeitet und den Wert auch auf der ccu schreiben will.

@klassisch:

Kann man das irgendwie vermeiden? `
Ich fürchte nicht - Begründung oben.

@klassisch:

es könnte ja auch sein, daß der Adapter beim nächsten "Neu laden" oder Hochfahren, die aus seiner Sicht unauthorisierten Datenspuren einfach wegputzt. `
Nicht ganz unberechtigt!

Gruß Rainer

[klassisch]

Vielen Dank, lieber Rainer! Ich habs befürchtet. Es gibt CUxD Termostat-Devices, dieauch für Funk-Geräte eingesetzt werden können. Die haben dann zusätzliche, in meinem Fall ungenutzte Datenpunkte wie RSSI_PEER, z.B. "hm-rpc.1.CUX9002008.0.RSSI_PEER". Die kann ich bedingt vereinnahmen. Bedingt, weil der Wertebereich bereits definiert ist. Dann gibt es keine Beschwerden. Und ob die Daten dann wieder zurück auf die CCU geschrieben werden, kann ich nicht so einfach prüfen, weil diese Werte mit der WebUi nicht sichtbar sind.

Und die "einfacheren "CuxD Wrapper- Transform-devices", die ja kein reales Funk-Pendant besitzen, haben diese zusätzlichen, ungenutzten Datenpunkte nicht.

Die Fehlermeldung kommt auch, wenn ich den Datenpunkt auf "Read" stelle und "Write" abwähle. Also wohl keine Rückmeldung von der CCU, sondern eine Art Eingangskontrolle. Da kann man erahnen, wie komplex diese Adapter sind.

Edit: wobei ich gerade sehe, daß es bei einigen Transform devices solche zusätzlichen Datenpunkte gibt und bei anderen nicht. Da muß ich mal die Konfiguration in der CCU untersuchen.

[Homoran]

Ich habe für solche Datenpunkte einen eigenen Baum aufgemacht: Messwerte.0

Leider sind da nicht alle drin. Mqtt Daten landen im mqtt-client.0.

Inzwischen schicke ich viele Daten über mqtt zu meinen Installationen um überall die gleiche Strukturen zu haben.

Gruß Rainer

[klassisch]

Ja, dann leiden wir an dem gleichen Problem : fast jeder Adapter legt seine Daten unter seiner eigenen Struktur ab und lässt sich nicht dazu überreden, die Daten woanders abzulegen. Mein letztes Beispiel war der Sonoff Adapter

Meine Lösung ist deiner sehr ähnlich, aber kürzer: data.0

Gesendet von meinem ZTE A2016 mit Tapatalk