Die FHEM-config-XMLs nutzen das Datenformat von Openzwave und basieren teilweise auch auf deren Datenbestand.
Openzwave 1.6 (https://groups.google.com/d/msg/openzwave/a26mAKMam58/KZnH6wQ0AgAJ) 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
Zitat von: krikan am 06 Mai 2019, 11:51:41
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
rein aus interesse: hat fhem eine eigene ZWave Protokoll Implementierung oder nutzt es openzwave als basis?
Zitat von: adnan am 02 Juli 2019, 21:19:30
rein aus interesse: hat fhem eine eigene ZWave Protokoll Implementierung oder nutzt es openzwave als basis?
FHEM hat eine eigene Implementierung.
@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
@Christian: kannst du bitte ein konkretes Beispiel zeigen?
aus https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/openzwave_manufacturer_specific.xml:
<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:
<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".
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.
Zitat von: rudolfkoenig am 19 Juli 2019, 19:22:42
Weisst Du, warum fheminfo openzwave_manufacturer_specific.xml liest?
Weil das hier...
Zitat von: rudolfkoenig am 19 Juli 2019, 19:22:42
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.
Mit den bereits genannten ca. 2 Jahren lag ich ziemlich richtig :)
Zitat von: rudolfkoenig am 19 Juli 2019, 19:22:42
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.
Zitat von: krikan am 18 Juli 2019, 17:11:42
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.
ZitatSchau mal in diesen Thread: https://forum.fhem.de/index.php/topic,73980.msg657158.html#msg657158 (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.
Zitat von: rudolfkoenig am 20 Juli 2019, 13:01:54
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...
Zitat von: rudolfkoenig am 07 Juli 2017, 09:45:56
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.
Zitat-> 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.
Zitat von: rudolfkoenig am 20 Juli 2019, 14:03:27
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...
Zitat von: betateilchen am 08 Juli 2017, 10:15:34
- 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...
Zitat von: rudolfkoenig am 08 Juli 2017, 14:09:37
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.
Nicht falsch verstehen: das ist meine Meinung, und das heisst nicht, dass ich boese bin, wenn jemand eine Andere hat.
Keine Sorge, ich habe Dich schon richtig verstanden. Inzwischen "kennen" wir uns ja schon eine Weile :)
Kannst Du bitte trotzdem mal das hier testen:
Zitat von: betateilchen am 20 Juli 2019, 12:31:42
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.
Zitat von: betateilchen am 20 Juli 2019, 16:58:24
Kannst Du bitte trotzdem mal das hier testen:
fheminfo send debug-Auszug zu ZWave mit dem derzeiigen svn-Stand:
"ZWave":{"0086-0002-0064":1,"0086-0003-0062":1,"0086-0004-0050":1,"0108-0002-000e":3,"0109-2021-2101":1,"010f-0203-1000":1,"010f-0301-1001":4,"010f-0402-1002":1,"010f-0403-1000":2,"010f-0600-1000":1,"010f-0701-1001":1,"010f-0800-1001":2,"010f-0b01-1002":1,"010f-1d01-1000":1,"0115-0100-0102":1,"013c-0001-0012":1,"013c-0002-000c":1,"013c-0009-0022":1,"0148-0003-0001":1,"0154-0004-0002":2,"0154-0004-0004":2,"0159-0002-0052":1,"019a-0003-0003":2}Funktioniert mit dem derzeitigen Stand des svn noch nicht, da ich die openzwave_manufacturer_specific.xml noch nicht auf das neue Format umgestellt habe. Schaffe es heute auch nicht mehr mit dem Check-In.
Nach Format-Umstellung würde es aber wohl funktionieren:
fheminfo send debug-Auszug zu ZWave mit einer openzwave_manufacturer_specific.xml im neuen Format (meine Testversion)
"ZWave":{"AEON Labs ZW080 Siren Gen5":1,"AEON Labs ZW098 LED Bulb":1,"AEON Labs ZW100 MultiSensor 6":1,"D-Link Corporation DCH-Z110 Door/Window 3 in 1 sensor":3,"EUROtronic EUR_SPIRITZ Wall Radiator Thermostat":1,"FIBARO System FGFS101 Zwave+ Flood Sensor":1,"FIBARO System FGK10x Door Opening Sensor":1,"FIBARO System FGMS001 Motion Sensor":2,"FIBARO System FGRM222 Roller Shutter Controller 2":4,"FIBARO System FGS212 Switch 3kW":1,"FIBARO System FGS213 Switch":2,"FIBARO System FGS223 Double Relay":1,"FIBARO System FGWPE/F Wall Plug":1,"FIBARO System FGWR111 Walli Roller Shutter":1,"Philio Technology Corp PAN04-1 Double Relay Switch 2x1.5kW with Power Measurement":1,"Philio Technology Corp PSR04 Smart Color Button":1,"Philio Technology Corp PST02-A 4 in 1 Multi-Sensor":1,"Popp & Co 009402 10-Year Smoke Detector":2,"Popp & Co Solar Powered Outdoor Siren":2,"Qubino (Goap) ZMNHADx Flush 1 Relay":1,"Sensative Strips":2,"Vision Security ZP3111 Multisensor 4in1":1,"Z-Wave.Me ZME_KFOB-S 4 Button Key Fob":1}Rudi hat es in 10_ZWave.pm eine Variante gewählt die sowohl altes als auch neues Format unterstützt.
Danke fürs Testen.
Falls Du Zeit & Lust hast, kannst Du mit der eben eingecheckten Variante von 98_fheminfo.pm nochmal das alte und neue Format testen, darin habe ich nun die Variante umgesetzt, die Rudi auch verwendet.
Beim alten Format gibt es in 10_ZWave.pm und 98_fheminfo.pm noch Probleme. Es wird nur der Herstellername statt "Herstellername+Modellbezeichnung" genutzt:
"ZWave":{"Aeotec ":3,"D-Link Corporation ":3,"EUROtronic ":1,"FIBARO System ":14,"Philio Technology Corporation ":3,"Popp ":4,"Qubino ":1,"Sensative ":2,"Vision ":1,"Z-Wave.Me ":1}
Könnt ihr das bitte noch mal gegenchecken. Bin unterwegs und habe keine optimalen Testbedingungen....
Danke fuer den Hinweis, habs gefixt und eingecheckt.
Ich habe wohl nicht alle 3 moeglichen Aufrufversionen der Funktion durchgetestet, das habe ich jetzt nachgeholt.
Die Änderung habe ich auch in fheminfo nachgezogen.
Zitat von: betateilchen am 21 Juli 2019, 15:13:34
Die Änderung habe ich auch in fheminfo nachgezogen.
Danke.
Konvertierte openzwave_manufacturer_specific.xml im neuen Format habe ich gestern abend eingecheckt und funktioniert problemlos mit fheminfo. Alle weiteren Themen im Zusammenhang mit dem neuen XML-Format betreffen nicht openzwave_manufacturer_specific.xml, sondern die anderen XML-Dateien und haben damit mMn keine Auswirkungen auf fheminfo mehr.
@Rudi:
Auf den aktuellen Stand gebrachte openzwave_deviceconfig.xml.gz habe ich nun bereit zum Einchecken, ABER habe gerade mit Erschrecken die Dateigröße bemerkt: 525 kb. Für FHEM brauchen wir aus den XMLs derzeit nur einen geringen Teil. Verzichten könnten wir mMn aus den akuellen XMLs auf alles was zwischen <MetaData> </MetaData> an Text steht (siehe bspw. https://github.com/OpenZWave/open-zwave/blob/master/config/fibaro/fgwr111.xml ); es sei denn Du hast vor das irgendwie als Hilfe einzubinden. So einchecken oder optimieren/kürzen?
Edit: Nach Löschen der Texte von <MetaData> ist die Datei noch ca. 300kb groß.
Ich schlage vor die kompletten Daten einzuchecken: Du hast weniger Aufwand, und ich habe einen Anreiz, die Daten anzuzeigen.
Doku zu haben ist gut, wir sollten es nicht unnoetig wegwerfen.
Sind eingecheckt.
Musste "zwave_configconvert.pl" ein wenig anpassen, damit das Ergebnis (halbwegs) passt. Die Zeilenumbrüche insbesondere innerhalb von Kommentaren sind bei ozw momentan noch (?) etwas unglücklich. Mit der Codeänderung hatte ich nur noch 2 manuelle Anpassungen vorzunehmen und das war für mich einfacher als einen komplexeren Parser zu erstellen, der alles abdeckt. Keine Ahnung, ob Du den Patch einchecken willst.
Index: zwave_configconvert.pl
===================================================================
--- zwave_configconvert.pl (Revision 19964)
+++ zwave_configconvert.pl (Arbeitskopie)
@@ -43,7 +43,8 @@
while(my $l = <FH>) {
next if($l =~ m/^<\?xml/);
chomp($l);
- $l =~ s/^<Product.*xmlns.*/<Product sourceFile="$name">/;
+ $l =~ s/<!--.*-->//g;
+ $l =~ s/^(.*)<Product.*xmlns.*/$1<Product sourceFile="$name">/;
$l =~ s/\r//g;
$l =~ s/\t/ /g;
#$l =~ s/^ *//g;
@@ -52,6 +53,14 @@
if($l !~ m/>$/ || $l =~ m/^\s*<Help>\s*$/) { $buffer .= " ".$l; next; }
if($buffer && $l =~ m/>$/) { $l = "$buffer $l"; $buffer=""; }
$l =~ s/<!--.*-->//g;
+ # $l =~ s/<MetaData.*<\/MetaData>//g;
+ # $l =~ s/<MetaDataItem.*<\/MetaDataItem>//g;
+ # $l =~ s/<Entry.author.*<\/Entry>//g;
+ # $l =~ s/<ChangeLog.*<\/ChangeLog>//g;
+ # $l =~ s/<MetaData>//g;
+ # $l =~ s/<\/MetaData>//g;
+ # $l =~ s/<ChangeLog>//g;
+ # $l =~ s/<\/ChangeLog>//g;
$l =~ s/ *$//g;
print $l,"\n" if($l);
}
Danke fuer die Arbeit!
Habe dein Patch (ohne Nachdenken) eingecheckt, und ZWave.pm erweitert, um die MetaDataItems anzuzeigen.
Falls(!) fuer die aktuelle modelConfig <MetaDataItem> Eintraege gibt, dann wird unten rechts ein "Details:OZW" Link generiert, und beim Click der gesammelte Text eingeblendet, siehe Anhang.