Implementierungsfrage ....

Begonnen von tux75at, 07 August 2018, 14:10:29

Vorheriges Thema - Nächstes Thema

tux75at

Ich spiele mich schon ein wenig mit FHEM und stoße dabei immer wieder auf das gleiche Problem.

Bei meinem Fibaro Dimmer 2 bekomme ich Probleme beim Konfigurieren.
Ich lese immer zuerst das Datenblatt und versuche dann alles umzusetzen. Aller Anfang ist schwer und bei umfangreichen Settings kann man nicht alles auf Anhieb finden.
Ich habe erst spät gefunden dass es ein configForcedSwitchOnBrightnessLevel gibt und versucht dies anders umzusetzen, was dazu geführt hat, dass sich das licht durch Geisterhand  ??? einschaltete, bin dann aber rasch draufgekommen was es war  ;D

Nach Neuaufsetzen und möglichst alle Settings für mich zu Dokumentieren stoße ich wieder auf die Selben Probleme.

Fibaro Dimmer 20 - GROUP 20 - Dimmer 2 operation - Switches
20. Switch type (Einstellen von Taster, Schalter und Roller Blind Switch)

Lange gesucht, soeben wieder, auch wieder die Doku geöffnet damit ich irgendwie vielleicht doch fündig werde.
configInputsButtonSwitchConfiguration  >:( Switch type  :o das ist nicht ganz das gleiche und das bei einem doch Wichtigen Setting.
Wenistens kommt nach Auswal darunter der Hinweis mit (numeric code 20). Ansonsten würde ich mir nie sicher sein, dass es das richtige ist.
Können Numerische Werte eingegeben werden? z.B: set Dimmer 20 0 oder vielleicht auch set Dimmer 0x14 0?
Beim get geht es nicht.

configForcedSwitchOnBrightnessLevel -> Forced switch on brightness level  .... hier passt es
configTheValueSentToAssociatedDevices21 -> The value sent to associeated devices on single click .... lass ich mal gelten, hie rist aber auch noch die 21 dran (numeric code 21)

Da stellt sich schon die Frage nach einem Einheitlichen System.

Ich will damit nicht sagen, dass es falsch ist. Ich vermute eher, dass Fibaro den namen geändert hat und diese Änderung nicht nachgezogen wurde. Warum auch, wenn es funktioniert und niemand etwas sagt. Irgendwann findet es schließlich jeder.

Da hier sowieso immer ein Präfix dran ist, könnte dieser erweitert werden um auch eine bessere Reihenfolge zu haben
zB:
config_20_InputsButtonSwitchConfiguration oder
config20InputsButtonSwitchConfiguration

Damit wäre man rasch fündig, auch bei Namensänderungen in der Spezifikation.
Weiters wären alle configs in der Reihenfolge des Numerischen Wertes.

Eines sollte klar, sein. Ich will hier keinen Krieg anzetteln, sondern nur kurz darauf aufmerksam machen.
Wenn es zuviel Arbeit ist für bestehende Devices dies zu ändern, dann sollte man hier vielleicht bei der Implementierung für neue Devices darauf achten.
Wobei ich auch hier nicht weiß wie stark alles zusammenhäng.
Also bitte als konstruktive Kritik auffassen.

Gruß
   Tux

krikan

#1
Als "MAINTAINER" der ZWave-XML-Dateien meine Anmerkungen zur Aktualität/Qualität der XMLs:

Die eingespielten XML-Dateien sind nur so aktuell, wie sie mir zur Verfügung gestellt werden (und ich Zeit finde sowie entsprechende EDV im Zugriff habe, um sie einzuchecken [derzeit nicht]). Also ist die Aktualität nicht garantiert und sie werden fehleranfällig per Hand erstellt. Es sind eben "nur" Hilfen.

Zusätzlich zur Aktualität/Qualität der bei FHEM vorhandenen XML-Dateien gibt es noch ein derzeit ungelöstes Problem:
Es gibt in den XML-Dateien (derzeit) keine Unterscheidung der verschiedenen Firmwareversionen der Geräte. Da Gerätehersteller teilweise inkompatible Änderungen in neuere Firmwareupdates einbauen, "verliert" immer eine Firmwareversion. Die XML passt nur zu einer Firmwareversion. Eine Änderung des zugrundeliegenden openzwave-XML-Formates ist seit längerem (Jahren) in Arbeit; also Geduld ;-).

Setzen kann man die Parameter mit set configByte/configWord/configLog/configDefault auch ohne XMLs (siehe auch https://fhem.de/commandref.html#ZWave unter Class Configuration)

In https://wiki.fhem.de/wiki/Z-Wave#Konfiguration und den dortigen FAQs gibt es zum Themenkomplex auch einige Infos.

Für das Thema Umstellung der config-Klartext-Befehle und Bildung der Befehle ist Rudi Dein Ansprechpartner.

Gruß, Christian

tux75at

Da sind ein paar super Entwickler unterwegs .... Inkompatible config Addressen bei Firmwareupdates  :o

Daran hätte ich garnicht gedacht.

set configByte/configWord/configLong/configDefault ist zum Setzen gut und wichtig für diese Problematik.
Aber ein get für selbiges wäre dann auch noch nett (überprüfen eines inkompatiblen Settings wird dann schwierig.

Eben ein get config 20 beim Fibaro Dimmer getestet: configInputsButtonSwitchConfiguration:BiStableInputSwitch
es findet eine Klartext Umsetzung statt, wird schwierig, wenn man inkompatibilitäten hat und eventuell nicht vorhandene Werte ausgelesen werden.

Können diese XML-Datein nur von dir (krikan) erstellt und eingecheckt werden? oder könnten das auch andere machen? bzw selbiges für die Klartext Befehle?

Gruß
   Tux

krikan

ZitatAber ein get für selbiges wäre dann auch noch nett (überprüfen eines inkompatiblen Settings wird dann schwierig.
Kann Dir nicht folgen:
get <device> config cfgAddress
geht bei allen Parametern, egal welche Parametergröße.
Es gibt wenige Geräte die bestimmte Parameter zwar setzen aber nicht auslesen lassen.

ZitatEben ein get config 20 beim Fibaro Dimmer getestet: configInputsButtonSwitchConfiguration:BiStableInputSwitch
es findet eine Klartext Umsetzung statt, wird schwierig, wenn man inkompatibilitäten hat und eventuell nicht vorhandene Werte ausgelesen werden.
Lösche das Reading modelConfig (https://fhem.de/commandref.html#deletereading) oder setze es auf unknown, dann wird keine XML mehr genutzt und es findet keine "Zwangsumsetzung" mehr statt.

ZitatKönnen diese XML-Datein nur von dir (krikan) erstellt und eingecheckt werden? oder könnten das auch andere machen? bzw selbiges für die Klartext Befehle?
Könnten theoretisch auch andere, dürfen aber grundsätzlich nicht (https://forum.fhem.de/index.php/topic,18962.0.html). Es gibt einen Verantwortlichen, damit man bei Murks in den XMLs direkt den Schuldigen findet und einer den Überblick/Hoheit hat. Ansonsten droht Chaos.

Brennt es irgendwo bei den XMLs?

Gruß, Christian

krikan

Zitat von: tux75at am 07 August 2018, 15:32:50
Können diese XML-Datein nur von dir (krikan) erstellt und eingecheckt werden? oder könnten das auch andere machen? bzw selbiges für die Klartext Befehle?
Erstellen kann sie natürlich jeder und mir zum Einchecken hier zur Verfügung stellen (siehe https://wiki.fhem.de/wiki/Z-Wave#Wie_k.C3.B6nnen_fehlende_XML-Config-Informationen_f.C3.BCr_mein_ZWave-Ger.C3.A4t_in_FHEM_eingebunden_werden.3F). Die Einschränkung ("nur ich") betrifft ausschließlich das Einchecken.

tux75at

Zitat von: krikan am 07 August 2018, 16:01:06
Brennt es irgendwo bei den XMLs?
Nein, ich bin zur Zeit etwas damit beschäftigt mein Testsystem richtig zum laufen zu bekommen und eigentlich geht es um die Klartext Umsetzung, die ich gerne verbessern würde.

Wobei ich jetzt erst gesehen habe, dass es kein xml für den Popp Z-Weather 005206 gibt. Wäre mir jetzt garnicht aufgefallen, wenn ich die "modelConfig" dort nicht gesucht hätte.
Funktionierten tut er, es wird halt kein Bildchen angezeigt. Das ist mir aber auch nicht wichtig, die Readings gehen.
Das Problem mit den Updates wird wohl nicht an der fehlenden XML Datei liegen?

Gruß
   Tux

tomspatz

ZitatWobei ich jetzt erst gesehen habe, dass es kein xml für den Popp Z-Weather 005206 gibt.

get <deinsensor> model

LG
Tom

krikan

Zitat von: tux75at am 07 August 2018, 18:57:27
Das Problem mit den Updates wird wohl nicht an der fehlenden XML Datei liegen?
Nein, das kann nicht daran liegen.
Die XMLs bieten nur die in https://wiki.fhem.de/wiki/Z-Wave#Welche_Funktion_haben_die_XML-Config-Dateien_in_FHEM.3F aufgelisteten Erleichterungen. Nicht mehr.