HmIP Geräte-XMLs auslesen

Nutzung von XML RPC, Remote Script, JSON RPC, XMLAPI

Moderator: Co-Administratoren

Antworten
danielperna84
Beiträge: 150
Registriert: 04.12.2019, 22:10
Hat sich bedankt: 4 Mal
Danksagung erhalten: 38 Mal

HmIP Geräte-XMLs auslesen

Beitrag von danielperna84 » 06.12.2019, 22:08

Hi,

erster Thread hier, daher erst noch eine kurze Begrüßung: ich bin Daniel. Der Daniel, der pyhomematic gemacht hat. Wem das noch nichts sagt: das ist die Basis für die HomeMatic Integration in Home Assistant. Ggf. hab ich also dem ein oder anderen hier schon mal im Home Assistant Forum diesbezüglich geholfen. :)

Nun brauche ich Hilfe: gibt es für HmIP etwas analoges zu den XML-Dateien in /firmware/*types? Dort sind ja nur die für RF und Wired.

Hintergrund der Frage: ich plane eine neue Variante von pyhomematic spezifisch für Home Assistant zu machen. Und anstatt manuell für alle möglichen Geräte Support einbauen zu müssen würde ich das lieber automatisiert passieren lassen. Wir Programmierer sind halt faul. :D

Idealfall wäre, dass ich anhand dessen was in den Paramset Descriptions steht automatisch die richtigen Home Assistant entities erzeuge. Mit der Option nur noch für komplexere Geräte (Thermostate/Gruppen) etwas Logik auszuliefern. Wenn ich das hinkriege werden also idealerweise auch neue Geräte direkt unterstützt, und zusätzlich dann vielleicht auch die, die mit AskSin gemacht wurden.

Plan ist, das was als CONTROL im Paramset steht als Indikator dafür zu nehmen, welcher HA-entity-Typ am ehesten zum Gerät passt.

Um das machen zu können muss ich aber erst mal wissen, welche Controls es bei HmIP gibt. In der Device-Doku (mittlerweile über 20MB groß) stehen die ganzen Parameter der Geräte drin. Aber eben auch nur die. Ich brauche also eine Quelle für diese Info. Weiß da jemand was drüber?

Gruß

jp112sdl
Beiträge: 12085
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 847 Mal
Danksagung erhalten: 2139 Mal
Kontaktdaten:

Re: HmIP Geräte-XMLs auslesen

Beitrag von jp112sdl » 07.12.2019, 07:26

Hi,
schaust du in der
- HMIPServer.jar
- de/eq3/cbcs/devicedescription/channelspecification/ (allgemeine Kanaldefinitionen)
- de/eq3/cbcs/devicedescription/devicespecification/eQ-3/ (Gerätebeschreibungen)

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

danielperna84
Beiträge: 150
Registriert: 04.12.2019, 22:10
Hat sich bedankt: 4 Mal
Danksagung erhalten: 38 Mal

Re: HmIP Geräte-XMLs auslesen

Beitrag von danielperna84 » 07.12.2019, 21:36

Vielen Dank, das ist schon mal sehr aussagekräftig. Was fehlt sind die controls und welche Operationen darauf angewandt werden können. Aber vielleicht ist das gar nicht so schlimm. Anstelle der controls kann ich vermutlich auch einfach die Kanalspezifikationen (z.B. SWITCH_TRANSMITTER, SWITCH_VIRTUAL_RECEIVER usw.) als Basis benutzen. Andererseits fehlen dann Infos wie die Einheit des Parameters (Watt, Grad usw.), und ich weiß auch nicht welcher Typ (bool, int, ...) der richtige ist. Aber zumindest für den Anfang sollte es reichen um fake Device Descriptions für alle Gerätetypen zu erstellen mit denen ich testen kann. Die Paramset Descriptions werde ich in der Praxis sowieso von den Geräten selbst ziehen müssen um die tatsächliche Config zu bekommen.

EDIT:
Mittlerweile habe ich ein Script, das mir aus den RF- (und Wired) XMLs die einfacheren device descriptions baut. Mit Ausnahme von 2 Details:
1. Ich weiß nicht, wie ich aus count_from_sysinfo="23.0:1.0" die tatsächliche Anzahl von Kanälen herleiten kann (ist aber auch nicht so wichtig, ein Demo-Kanal reicht ja für's testen)
2. Die Flags (visible, internal) im XML entsprechen nicht dem, was ich in einer echten device description stehen habe. Auf den ersten Blick scheinen die nur für die Paramsets angegeben zu sein. Für die Kanäle sind sie unvollständig, und für das Gerät selbst (ohne Kanalangabe) fehlt das gänzlich.

Sind jetzt beides nicht unbedingt die wichtigsten Sachen, aber gerade die Flags könnten nützlich sein um zu entscheiden was mit dem Kanal passieren soll.

jp112sdl
Beiträge: 12085
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 847 Mal
Danksagung erhalten: 2139 Mal
Kontaktdaten:

Re: HmIP Geräte-XMLs auslesen

Beitrag von jp112sdl » 08.12.2019, 09:49

danielperna84 hat geschrieben:
07.12.2019, 21:36
Ich weiß nicht, wie ich aus count_from_sysinfo="23.0:1.0" die tatsächliche Anzahl von Kanälen herleiten kann
Gar nicht. Wie viele Kanäle das Gerät tatsächlich hat, überträgt es einmalig beim Anlernen - an Index 23 (mit 1 Byte Größe)
So brauchts für eine Geräteklasse, die es in unterschiedlichen Kanalzahlausführungen gibt, nur eine XML.
danielperna84 hat geschrieben:
07.12.2019, 21:36
Flags (visible, internal)
Ist m.W. hauptsächlich für die Darstellung von Steuerelementen in der WebUI notwendig und hat keine technische Auswirkungen auf die Kommunikation mit dem Gerät

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

danielperna84
Beiträge: 150
Registriert: 04.12.2019, 22:10
Hat sich bedankt: 4 Mal
Danksagung erhalten: 38 Mal

Re: HmIP Geräte-XMLs auslesen

Beitrag von danielperna84 » 08.12.2019, 11:47

jp112sdl hat geschrieben:
08.12.2019, 09:49
Gar nicht. Wie viele Kanäle das Gerät tatsächlich hat, überträgt es einmalig beim Anlernen - an Index 23 (mit 1 Byte Größe)
So brauchts für eine Geräteklasse, die es in unterschiedlichen Kanalzahlausführungen gibt, nur eine XML.
Verstehe. Ergibt Sinn.
jp112sdl hat geschrieben:
08.12.2019, 09:49
Ist m.W. hauptsächlich für die Darstellung von Steuerelementen in der WebUI notwendig und hat keine technische Auswirkungen auf die Kommunikation mit dem Gerät
Das denke ich mir auch. Meine Idee war deshalb nur Kanäle zu verarbeiten die das visible-bit gesetzt haben, denn nur was der User im CCU-UI sieht würde er auch im Home Assistant UI erwarten. Aber nachdem ich mir das noch mal genauer angeschaut habe sehe ich, dass z.B. beim HM-CC-RT-DN eigentlich nur der Kanal 4 relevant ist, andere Kanäle aber auch das visible-Flag haben.

Ich muss dann also doch die Paramsets durchlaufen (was ich aus Performance- und DutyCycle-Gründen so gut es geht vermeiden wollte), oder statisch definieren, dass z.B. ein WEATHER_RECEIVER immer uninteressant ist, ein CLIMATECONTROL_RT_TRANSCEIVER hingegen relevant.

jp112sdl
Beiträge: 12085
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 847 Mal
Danksagung erhalten: 2139 Mal
Kontaktdaten:

Re: HmIP Geräte-XMLs auslesen

Beitrag von jp112sdl » 08.12.2019, 11:59

danielperna84 hat geschrieben:
08.12.2019, 11:47
Kanäle zu verarbeiten die das visible-bit gesetzt haben
Kann ein ganzer Kanal diese Eigenschaft besitzen? Wäre mir neu.
danielperna84 hat geschrieben:
08.12.2019, 11:47
Aber nachdem ich mir das noch mal genauer angeschaut habe sehe ich, dass z.B. beim HM-CC-RT-DN eigentlich nur der Kanal 4 relevant ist,
Du meinst relevant nur für die Steuerung?
Die anderen Kanäle sind ja nicht umsonst da, sondern z.B. für Peerings mit einem Wandthermostat oder Temperatursensor.

Wenn es dir nur darum geht, die Kanäle zu finden, um das Gerät zu steuern, solltest du in den <frames> nach direction="to_device" schauen und in welchem Channel dann die id="..." des Frames auftaucht.

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

danielperna84
Beiträge: 150
Registriert: 04.12.2019, 22:10
Hat sich bedankt: 4 Mal
Danksagung erhalten: 38 Mal

Re: HmIP Geräte-XMLs auslesen

Beitrag von danielperna84 » 09.12.2019, 02:24

jp112sdl hat geschrieben:
08.12.2019, 11:59
Kann ein ganzer Kanal diese Eigenschaft besitzen? Wäre mir neu.
Ähm, vielleicht verstehe ich da ja was falsch. Also grundsätzlich kann er Flags haben. In der XML-RPC Doku Punkt 3.4, Seite 8. Was bestätigt wird durch beispielsweise rf_central.xml, in welcher folgendes steht:

Code: Alles auswählen

<channel index="0" type="MAINTENANCE" ui_flags="internal" class="maintenance" count="1">
Wobei es dort als internal steht.
Aber in der Device Description einer CCU:

Code: Alles auswählen

{
...
    "LINK_TARGET_ROLES": "",
    "PARENT": "abc",
    "FLAGS": 3,
    "LINK_SOURCE_ROLES": "",
    "ADDRESS": "abc:0",
    "AES_ACTIVE": 0,
    "PARENT_TYPE": "HM-RCV-50",
    "VERSION": 6,
    "INDEX": 0,
    "TYPE": "MAINTENANCE",
    "DIRECTION": 0
}
3 ist für mich 1 || 2. 1 ist laut oben genannter Doku visible, 2 ist internal. Wobei mir gerade auffällt, dass AES_ACTIVE das flag invisible hat, was es laut Doku gar nicht gibt. Das lässt vermuten, dass Kanäle eigentlich immer visible sind, und das Bit durch invisible deaktiviert wird.
jp112sdl hat geschrieben:
08.12.2019, 11:59
Du meinst relevant nur für die Steuerung?
Die anderen Kanäle sind ja nicht umsonst da, sondern z.B. für Peerings mit einem Wandthermostat oder Temperatursensor.
Nein, relevant im Sinne dessen, dass daraus ein Gerät im Home Assistant Kontext erzeugt wird. Wenn man ein Thermostat hat, dann will man im UI nur die (eingestellte) Temperatur und die Betriebsmodi (und was man halt sonst noch so zum bedienen braucht). Was in dem Beispiel alles auf Kanal 4 ist. Die anderen Kanäle sind für das UI irrelevant.
Aber da führt glaube ich nix an den Paramsets vorbei. Ein HM-Sen-MDIR-WM55 hat z.B. auf Kanal 3 sowohl die Helligkeit als auch den Bewegungsmelder. Deshalb müssen daraus auch zwei separate Entities werden. In pyhomematic habe ich das für haufenweise Geräte schon alles manuell definiert. Der Punkt ist, dass ich das nicht tun will, denn immer wenn ein neues Gerät raus kommt muss ich den Support in pyhomematic einbauen. Und da ich die Geräte selbst nie habe ist das immer eher blöd. Deshalb versuche ich das programmatisch auf Basis der Daten zu machen, die das Gerät selbst liefert.
jp112sdl hat geschrieben:
08.12.2019, 11:59
Wenn es dir nur darum geht, die Kanäle zu finden, um das Gerät zu steuern, solltest du in den <frames> nach direction="to_device" schauen und in welchem Channel dann die id="..." des Frames auftaucht.
Ja, das mit dem Frames habe ich schon gesehen. Wobei es in den XMLs mal mit denen ist, mal direkt im Kanal. Der Ordnung halber nehme ich an. Aber das ist ja kein Problem. Meinem Parser-Skript bringe ich das schon bei. An das mit der Direction habe ich auch schon gedacht. Daran kann ich vermutlich unterscheiden ob es sich um einen Aktor oder Sensor handelt. Je nach Richtung ist es dann also entweder (im Home Assistant Kontext) ein switch (kann ein- und ausgeschaltet werden) oder binary_sensor (zeigt nur an ob ein- oder ausgeschaltet ist) wenn der Datentyp ein bool ist.

EDIT:
Meine Theorie war richtig. Flags ist per Default 1, und wenn im XML invisible steht ziehe ich das Bit ab und habe am Ende den richtigen Wert. Jetzt passen alle erzeugten Flags. :D
Und die Paramsets für den das Gerät selbst habe ich auch gefunden. Ist in der root-XML-Node, sehr leicht zu übersehen.

danielperna84
Beiträge: 150
Registriert: 04.12.2019, 22:10
Hat sich bedankt: 4 Mal
Danksagung erhalten: 38 Mal

Re: HmIP Geräte-XMLs auslesen

Beitrag von danielperna84 » 12.12.2019, 01:36

Falls jemand daran interessiert ist:
Den aktuellen Stand sieht man in meinem pydevccu Repository. Mein Parser macht fast alles. Nur DIRECTION klappt noch nicht sauber, und bisher funktioniert das noch nicht für HmIP. Ein paar Details bei den Paramsets stimmen auch nicht, aber das ist für meinen Anwendungsfall erst mal irrelevant. Was auch noch Probleme macht ist die Anzahl der Kanäle in den Fällen in denen es nicht im XML steht. In manchen Fällen kann ich es herleiten, aber in einigen auch nicht. Da ist es dann nur ein Kanal / Paramset.

Die virtuelle CCU (also nur der XML-RPC Server) geht grundsätzlich auch. Die Methoden listDevices, getDeviceDescription und getParamsetDescription tun was sie sollen. Der Rest sind noch Dummy-Methoden, und vieles fehlt ganz. Wird noch dran gearbeitet.
Aktuell hat man hiermit also eine CCU mit 257 (verschiedene Namen für die gleichen Geräte sind separat) virtuellen Geräten (die bisher nix können außer eben da zu sein).

Edit:
setValue und getValue sind eingebaut. Sie liefern entweder den Default Wert, oder einen, den man selbst per setValue gesetzt hat. Das wird auch in einer kleinen JSON Datenbank gespeichert und ist somit auch nach einem Neustart noch gültig.

Antworten

Zurück zu „Softwareentwicklung von externen Applikationen“