Änderungen an Config-XMLs mit Openzwave 1.6 -> Grundlage für FHEM XMLs

[krikan]

Die FHEM-config-XMLs nutzen das Datenformat von Openzwave und basieren teilweise auch auf deren Datenbestand.

Openzwave 1.6 wurde vor einigen Tagen freigegeben. Mit 1.6 wurde einige Änderungen an der Gerätedatenbank eingeführt:
https://github.com/OpenZWave/open-zwave/wiki/OpenZWave-1.6-Release-Notes#device-metadata-information
https://github.com/OpenZWave/open-zwave/wiki/OpenZWave-1.6-Release-Notes#config-file-revision-management

Nach erster Durchsicht der Infos erkenne ich keinen Handlungsbedarf von unserer Seite; habe aber noch keine Tests mit dem angepassten Datenformat vorgenommen.

Der neu in den XMLs aufgenommene Block "Metadata-Information" wird in FHEM bereits seit Jahren über die Verlinkung zum (mittlerweile ungepflegten) pepper1-Datenbestand und https://products.z-wavealliance.org/ eingebunden.

Vorteil von "config-file-revision-management" für FHEM erkenne ich nicht. Ob es Änderungen an den Configs gab, sieht man auch per "svn diff ." . Es erleichtert vielleicht die Kommunikation im Forum, wenn man die Revision erkennt.

Die ursprünglich, vor Jahren einmal geplante Unterscheidungsmöglichkeit für verschiedene Firmeware-Versionen finde ich nicht in den Änderungen. Die Beschreibung des Formats liegt derzeit auch erst als DRAFT vor: https://github.com/OpenZWave/open-zwave/wiki/Adding-Devices

Ansonsten finde ich nur Reihenfolgeumstellungen von Feldern in den XMLs; sollte unkritisch sein.

Gruß, Christian

[krikan]

Die Beschreibung des Formats liegt derzeit auch erst als DRAFT vor: https://github.com/OpenZWave/open-zwave/wiki/Adding-Devices

Endgültige Beschreibung des neuen Formats liegt vor. Infos zu den Änderungen:
Neue Metadata-Information: https://github.com/OpenZWave/open-zwave/wiki/Adding-Devices#creating-the-metadata-block
Neue Changelogs: https://github.com/OpenZWave/open-zwave/wiki/Adding-Devices#changelog-entries (Sinn?)
Neue Verlinkung zu Produktbildern: https://github.com/OpenZWave/open-zwave/wiki/Adding-Devices#product-pictures
Erweiterung der types um bitset: https://github.com/OpenZWave/open-zwave/wiki/Adding-Devices#bitset-value-types

[adnan]

rein aus interesse: hat fhem eine eigene ZWave Protokoll Implementierung oder nutzt es openzwave als basis?

[krikan]

rein aus interesse: hat fhem eine eigene ZWave Protokoll Implementierung oder nutzt es openzwave als basis?

FHEM hat eine eigene Implementierung.

[krikan]

@Rudi:

Die Reihenfolgeumstellung in https://github.com/OpenZWave/open-zwave/blob/master/config/manufacturer_specific.xml innerhalb der "<Product .*/>" -Zeilen im Vergleich zu früher/unserem https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/openzwave_manufacturer_specific.xml bereitet mir hinsichtlich https://fhem.de/stats/statistics.html / fheminfo ein wenig Kopfschmerzen:

Wollte unsere openzwave_manufacturer_specific.xml einfach an die Reihenfolge-Änderung anpassen und in 10_ZWave.pm in ZWave_mfsParse($$$$$) entsprechend Regex anpassen. Das ist auch insoweit kein Problem und funktioniert im Test. Aber die Auswirkungen auf fheminfo/statistics überblicke ich nicht vollständig. In fheminfo müsste nach meinem Verständnis ebenfalls zeitgleich regex angepasst werden und zudem müsste wohl sichergestellt werden, dass Klartext-Name unverändert bleibt, da Klartextname und nicht modelId der Statistik zugrundeliegt. Gerade letzteres bereitet mir Schwierigkeiten und mir graut vor Überwachung der zukünftigen Anpassungen/Ergänzungen. Hast Du eine Idee/Vorschlag?

Gruß, Christian

[rudolfkoenig]

@Christian: kannst du bitte ein konkretes Beispiel zeigen?

[krikan]

aus https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/openzwave_manufacturer_specific.xml:

Code Auswählen Erweitern

<Product type="0007" id="0052" name="ZMNHTDx Smart meter" config="qubino/ZMNHTDx.xml"/>

aus https://github.com/OpenZWave/open-zwave/blob/master/config/manufacturer_specific.xml:

Code Auswählen Erweitern

<Product config="qubino/ZMNHTDx.xml" id="0052" name="ZMNHTDx Smart meter S4 S5 S6" type="0007"/>

Reihenfolge der Elemente ist vertauscht und "name" weicht ab. "name" bestimmt afaik https://fhem.de/stats/statistics.html und müsste stabil bleiben damit statistics "stimmt".

[rudolfkoenig]

Ich habe ZWave.pm angepasst, damit die Attributreihenfolge keine Rolle spielt.

Weisst Du, warum fheminfo openzwave_manufacturer_specific.xml liest? ZWave setzt doch model.
Ich habe betateilchen angepingt.

Wg. Namensaenderung: mAn ist das Pech, ich finde wir sollten nichts unternehmen.

[betateilchen]

Weisst Du, warum fheminfo openzwave_manufacturer_specific.xml liest?

Weil das hier...

ZWave setzt doch model.

... nicht zuverlässig genug funktioniert.

Über die Vorgehensweise, die Daten direkt aus der XML Datei zu lesen, haben wir vor ca. 2 Jahren (ohne den Zeitpunkt jetzt genau geprüft zu haben) im Rahmen einer Sonderbehandlung von zwave diskutiert.

Das Thema werde ich mir nach meinem derzeitigen Urlaub näher anschauen.

[betateilchen]

Mit den bereits genannten ca. 2 Jahren lag ich ziemlich richtig

Weisst Du, warum fheminfo openzwave_manufacturer_specific.xml liest? ZWave setzt doch model.

Schau mal in diesen Thread: https://forum.fhem.de/index.php/topic,73980.msg657158.html#msg657158

Dort haben wir das Thema diskutiert, wie man bei zwave auf sinnvolle Informationen für die Modellbezeichnungen kommen kann.

[betateilchen]

In fheminfo müsste nach meinem Verständnis ebenfalls zeitgleich regex angepasst werden

Das habe ich eben eingecheckt. Kann bitte jemand von Euch mit der aktualisierten 98_fheminfo.pm und den aktuellen xml-Daten testen, ob da nun immer noch sinnvolle Ergebnisse entstehen?

Bitte testen mit "fheminfo send debug" und die JSON Ausgabe zu zwave hier posten. Da ich selbst keine zwave Komponenten habe, kann ich nicht selbst testen.

[rudolfkoenig]

Schau mal in diesen Thread: https://forum.fhem.de/index.php/topic,73980.msg657158.html#msg657158

Ich habe geschaut, und nicht verstanden, warum fheminfo die Daten selbst aus der Datei extrahieren muss.
ZWave.pm macht das doch auch, und speichert es in model ab.
Vermutlich uebersehe ich etwas.

[betateilchen]

Ich habe geschaut, und nicht verstanden, warum fheminfo die Daten selbst aus der Datei extrahieren muss.
ZWave.pm macht das doch auch, und speichert es in model ab.
Vermutlich uebersehe ich etwas.

Ich zitiere mal Dich selbst...

Ja:

1. wenn etwas nicht nach Plan laeuft. Modellabfrage ist ein extra "get model" an das Geraet bei der Inklusion (aka peering). Wenn die Antwort ausbleibt, wird das Geraet von FHEM trotzdem nicht entfernt, sondern existiert ohne model und modelId. Das stoert in manchen Faellen die Benutzer auch, weil sie die config Befehle vom Beipackzettel ablesen und numerisch eingeben muessen, es gibt kein dropdown mit Klartext und Hilfe im Frontend dazu. Ich gehe davon aus, dass sie das kurz oder lang fixen, indem sie die Abfrage manuell wiederholen.

2. Die Kanaele eines Geraetes (wie Fernbedienung) sind auch ZWave-Instanzen, sind erkennbar an dem Internal endpointParent oder ZWaveSubDevice=yes und haben keine eigene modelId.

-> Man kann sich bei TYPE=ZWave nicht darauf verlassen, dass model oder modelId gibt.

[rudolfkoenig]

-> Man kann sich bei TYPE=ZWave nicht darauf verlassen, dass model oder modelId gibt.

Stimmt, aber meiner Ansicht nach soll fheminfo das nicht selbst fixen, das ist die Aufgabe des abgefragten Moduls.
Der Code in fheminfo hilft nur dann, falls bei der ZWave-Inklusion noch keine Modellinformation in der Datei vorlag, beim fheminfo absetzen aber schon, und in der Zwischenzeit der Benutzer sich nicht um eine manuelle Aktualisierung gekuemmert hat. Der Benutzer hat ein Interesse daran es selbst zu fixen, damit er die config-Werte sprechend setzen bzw. abfragen kann. Ich meine dieser Sonderfall ist es nicht Wert, dafuer Code in fheminfo zu duplizieren.

[betateilchen]

Stimmt, aber meiner Ansicht nach soll fheminfo das nicht selbst fixen, das ist die Aufgabe des abgefragten Moduls.

Ach Rudi, vor zwei Jahren habe ich die Änderung mit Deinem Segen eingebaut, weil zwave devices den größten (und meisten) Müll in die Statistik brachten...

• ZWAVE devices ohne modelId werden ab sofort für die Statistik ignoriert
• wird eine modelId gefunden, wird versucht, aus dem XML die Modellbezeichnung zu finden
• wird eine Bezeichnung gefunden, wird diese zum Zählen verwendet, ansonsten wird die Hex-ID verwendet

Dadurch sollte die Statistik für ZWAVE aussagekräftiger werden, ausserdem erkennt man an den Hex-IDs in der Statistik künftig die Modelle, die noch nicht im XML definiert sind. (wobei das natürlich abhängig ist vom Versionsstand der FHEM-Installation beim Anwender, denn es wird im XML auf Anwenderseite gesucht, nicht serverseitig)

und Du warst damals recht zufrieden...

Danke, klingt nach perfekten Service.

Warum soll ich einen "perfekten Service", der funktioniert und niemandem wehtut, jetzt wieder ausbauen?
Immerhin wurde dadurch der Datenschrott aus zwave-devices weitgehend aus der Statistik entfernt.

Solange nicht sichergestellt ist, dass es keine "Sonderfälle" bei zwave mehr gibt, die die Statistik verhunzen, werde ich die Verarbeitung aus fheminfo nicht ausbauen.