FHEMWEB: save config speichert angabegemäß deleteattr nicht

[Dr. Boris Neubert]

Hallo,

ein Anwender meldet, dass save config ein deleteattr aus der fhem.conf entfernt, dass von Hand dort hinein geschrieben wurde.

Bug oder Feature?

Warum braucht man dies? ECMD verwendet requestSeparator und replySeparator. Diese können als Attribute gesetzt werden. Wenn sie gesetzt werden, werden die gesetzten Werte als Separatoren verwendet. Wenn sie nicht gesetzt sind, werden keine Separatoren verwendet. Der Default ist \000 und kann folglich nicht über ein nicht gesetztes Attribut erkannt werden. Stattdessen werden die Attribute beim define angelegt und müssen mit deleteattr gelöscht werden. Wenn jemand eine gefälligere Lösung dafür hat, würde ich auch diese implementieren.

Der Workaround ist derzeit, Werte für die Separatoren zu verwenden, die bestimmt nie vorkommen.

Viele Grüße
Boris

[justme1968]

hallo boris,

warum kann man \000 nicht von einem nicht gesetzten attribut unterscheiden?

oder wird das zeichen 1:1 ins attribut geschrieben? ich glaube das wäre keine gute idee weil du ja auf diese art unkontrolliert alle möglichen steuerzeichen  ins config file und sonst wohin bekommst.

wie wäre es denn alles außer \w zeichen. nur octal oder json oder anders codiert zu erlauben?

gruss
  andre

[Dr. Boris Neubert]

Hallo Andre,

\000 ist ein Nullbyte und als solches gemeint. Wenn der Anwender foo\000bar an das ECMD-Gerät schickt und den requestSeparator auf \000 gesetzt hat, wird erst foo und dann bar gesendet. Wenn das Attribut requestSeparator nicht gesetzt ist und der Anwender foo\000bar an das ECMD-Gerät schickt, wird foo\000bar gesendet.

Ja, es kommen unkontrolliert alle möglichen Steuerzeichen vor. Mir ist nicht klar, an welchen Stellen FHEM Zeichen perl-kodiert und wann nicht. Ob z.B. in attr myDevice \000 das Attribut als Nullbyte oder als Literal BackslashNullNullNull erkannt wird.

Viele Grüße
Boris

[justme1968]

ein
  attr <name> xyz \000
wird als 4 einzelne zeichen im config file gespeichert und auch so wieder eingelesen.

gruss
   andre

[rudolfkoenig]

save config ein deleteattr aus der fhem.conf entfernt, dass von Hand dort hinein geschrieben wurde.

Klar. save schreibt die interne Struktur in die Datei. Genauso wird set/get/etc "entfernt". Wenn man sowas unbedingt haben will, dann bitte per "define lastinclude notify global:INITIALIZED include myFhem.cfg"

Wenn sie nicht gesetzt sind, werden keine Separatoren verwendet.
Der Default ist \000 und kann folglich nicht über ein nicht gesetztes Attribut erkannt werden.

Diese zwei Saetze sind mAn widerspruechlich, und ich verstehe den Sinn trotz wiederholtes Lesen nicht.

\ hat in FHEM (bis aufs Zeilenende) keine besondere Bedeutung: ich habe jetzt mit "attr dummy comment \000" herumexperimentiert, und ich sehe keine Probleme.

[Dr. Boris Neubert]

Danke für die Infos und Tests. Ich mache erstmal meine Hausaufgaben und analysiere, an welchen Stellen i.V.m. ECMD Steuerzeichen vorkommen können (Attribute, Logs, etc.) und inwiefern dort lediglich Dokumentationsbedarf oder auch Programmierbedarf besteht.

Ich muss die zu Grunde liegende Thematik verständlich beschreiben. Hier:

Wenn das Attribut requestSeparator auf einen Wert gesetzt ist, werden die als Requests gesendeten Zeichenketten vor Überstellung an das ECMD-Gerät zunächst an diesem gesetzten Wert aufgetrennt und dann werden die einzelnen Teilzeichenketten nacheinander an das als ECMD-Gerät definierte physikalische Gerät gesendet.
Der Default ist das Zeichen mit dem Zeichenwert 0 (\000).
Verwendung von AttrVal($name, "requestSeparator", "\000") ist ausgeschlossen, da ein nicht gesetztes Attribut eben nicht  bedeutet, dass der Defaultwert genommen wird.
Daher setze ich das Attribut beim Define.
Wenn der Anwender keinen requestSeparator benötigt, muss er das Attribut mit deleteattr löschen.

Der Grund für den Default ist Abwärtskompatibilität gewesen (\000 war in einer frühen Version der hardkodierte requestSeparator).

Ich sehe drei Möglichkeiten:
1. Es lassen wie es ist und den Anwendern von Save-Config-per-FHEMWEB die Lösung mit lastinclude vorschlagen.
2. Nach Ankündigung mit einigem Vorlauf den Default auf "kein requestSeparator" ändern.
3. Eine andere Lösung, für die ich eine Eingebung benötige.

Ich präferiere 2.

Viele Grüße
Boris

[Markus Bloch]

Würde ich ebenfalls bevorzugen.

Alternativvorschlag:

In der Define-Funktion jetzt wird folgende Zeile aufgenommen:

Code Auswählen Erweitern

$attr{$name}{requestSeparator} ='\000';

Während der Initialisierung wird es durch das usereigene Attribut aus der Konfiguration überschrieben, sofern der Nutzer einen eigenen Wert gesetzt hat. Andernfalls bleibt es so als "Defaultwert" gesetzt und wird in der Konfiguration bei der nächsten Save-Gelegenheit gespeichert. Dann wartest du ein paar Wochen ab und änderst dann in ECMD den Default-Wert auf [kein separator] ab.

Damit hast du dann einen Großteil der aktiven Update-Nutzer direkt abgefrühstückt und dein Supportaufwand minimiert sich.

Gruß
Markus

[justme1968]

zu 3: schön ist anders, aber ein 'spezialwert' wie no-requestSeparator im attribut als kennzeichen das kein separator verwendet werden soll wäre eine möglichkeit. oder ein zusätzliches attribut noSeparator.

2. ist glaube ich am saubersten.

gruss
  andre

[Dr. Boris Neubert]

In der Define-Funktion jetzt wird folgende Zeile aufgenommen:

Code Auswählen Erweitern

$attr{$name}{requestSeparator} ='\000';

Während der Initialisierung wird es durch das usereigene Attribut aus der Konfiguration überschrieben, sofern der Nutzer einen eigenen Wert gesetzt hat. Andernfalls bleibt es so als "Defaultwert" gesetzt und wird in der Konfiguration bei der nächsten Save-Gelegenheit gespeichert. Dann wartest du ein paar Wochen ab und änderst dann in ECMD den Default-Wert auf [kein separator] ab.

Damit hast du dann einen Großteil der aktiven Update-Nutzer direkt abgefrühstückt und dein Supportaufwand minimiert sich.

Danke Markus für den Alternativvorschlag. Die oben erwähnte Zeile ist ja jetzt schon drin. Möglicherweise sind damit alle Anwender von Save-Config-per-FHEMWEB bereits abgefrühstückt. ECMD/ECMDDevice ist allerdings ein Hackerdevice. Ich nehme an, dass die meisten Anwender lieber die fhem.conf per Hand bearbeiten.

Viele Grüße
Boris

[Dr. Boris Neubert]

Danke an Euch beide für die Bestätigung, dass Nummer 2 der Weg der Wahl ist.

[betateilchen]

1. Es lassen wie es ist und den Anwendern von Save-Config-per-FHEMWEB die Lösung mit lastinclude vorschlagen.
2. Nach Ankündigung mit einigem Vorlauf den Default auf "kein requestSeparator" ändern.
3. Eine andere Lösung, für die ich eine Eingebung benötige.

4. Endlich akzeptieren, dass Attribute dem Benutzer gehören und nicht dem Entwickler oder dem xx_Define()

Lösung 1 ist keine schöne/gute Lösung, denn Anwender der configDB müssten somit mit der Datenbank UND einer zusätzlichen Konfigurationsdatei arbeiten oder für jedes benötigte deleteattr ein eigenes notify definieren. Eventuell wäre noch eine Funktion in der 99_myUtils.pm denkbar, die bei mehreren deleteattr nur einmal (per notify) aufgerufen werden müsste.

Irgendwo steht m.W. geschrieben, dass in Konfigurationsdaten (egal ob Datei oder Datenbank) nur vier Zeilentypen vorkommen sollen:

• define...
• attr...
• # Kommentar
• <Leerzeile>

Wobei die configDB bereits die Typen 3+4 komplett ignoriert.

In diesem Sinne könnte man vielleicht überlegen, ein attr <device> <attrName> ohne einen angegebenen Attributwert zukünftig so zu interpretieren, dass das Attribut gelöscht werden soll. Bei den configDB-eigenen Attributen zur Parametrierung der Datenbank funktioniert das schon sehr lange so.

[justme1968]

ja. attribute gehören dem benutzer.

aber trotzdem ist es sinnvoll das ein modul die intern verwendeten defaults sichtbar macht in dem es attribute auf diese defaults initialisiert.

wenn man dies richtig macht ist das eine hilfe für den anwender ohne ihn beim setzen, ändern oder löschen der attribute eintuschränken.

[rudolfkoenig]

attr <device> <attrName> ohne einen angegebenen Attributwert zukünftig so zu interpretieren, dass das Attribut gelöscht werden soll.

Aktuell wird bei so einem Attribut das Wert 1 gesetzt.
Bei einer Aenderung haette ich das Bedenken, dass relativ viel Doku und Code ueberprueft werden muss.

[betateilchen]

Aktuell wird bei so einem Attribut das Wert 1 gesetzt.

Und diese Logik habe ich bis heute nicht verstanden. Eigentlich ist ein fehlender Attributwert beim Setzen eines Attributes für mich (bisher) ein Syntaxfehler, der als solcher gemeldet werden müsste.

[rudolfkoenig]

Fuer ja/nein Werte ist es bequem, und mAn auch verstaendlich:
attr global mseclog
attr global stacktrace
attr global updateInBackground
usw.