save zerstört kommands und include structure

[martinp876]

Hi,

nach einigen versuchen habe ich jetzt doch einmal versucht zu analysieren, warum meine Include-struktur nicht funktioniert.

Ich wollte files nach attribute aufteilen sowie kommandos abarbeiten lassen. Die Dokumentation habe ich so nicht gefunden oder nicht verstanden. Der Mechanismus ist nach meinen erkenntnissen

- Attribute werden immer in das File gespeichert, in dem die Entity definiert ist
=> eine Aufteilung anderer Art scheint nicht möglich
- Zeilen anders als attr, define oder comment (#") werden gelöscht.

Die reoganisation in files  - kann man wahrscheinlich nur schwer umgehen.

Wie wäre es, wenn "save" alle zeilen drin lässt, die es nicht kennt, anstatt sie zu löschen? Kommandos würden so erhalten bleiben.
Nach dem save wird sonst das Verhalten geändert, da kommandos gelöscht werden - das ist eher nicht gewünscht, oder?

Könnte man files als no-touch kennzeichnen? ok, ich konnte die Schreibrechte ändern. Aber man könnte evtl einen hearder einbauen #dontChangeMe ... dann schreibt FHEM nichts in dieses File. Zu komplex für den User?

Gruss Martin

[rudolfkoenig]

Deine Vermutungen sind korrekt, diese kann man in CommandSave einfach nachlesen.

Ich werde nicht weiter an der Save-Logik schrauben, da meiner Ansicht nach man fhem.cfg nicht manuell aendern sollte. Wenn die Daten in einer Datenbank stehen wuerden, wuerde auch keiner die Reihenfolge der Zeilen umdrehen wollen. Kommentieren kann man Eintraege mit dem comment Attribut, fuer strukturieren, gruppieren, etc gibt es auch Moeglichkeiten.

Wenn irgendwer die fhem.cfg trotzdem selbst editieren/strukturieren/kommentieren will, der soll sein Finger von save und automatisch generierten Eintraegen lassen. Um sicherzugehen, kann man mit cmdalias save "neutralisieren".

Ich habe schon ueberlegt, das Editieren der fhem.cfg in FHEMWEB + rereadcfg komplett zu entfernen, habe aber noch etwas Respekt vom Aufschrei. Aber nicht mehr viel ...

[martinp876]

hallo Rudi,

ok - verstehe. Kann ich akzeptieren und halte es für gut, wenn es der User nicht editieren soll.
Das kommt aber in er Beschreibung m.E. nicht heraus - da werden includes u.ä. angebote. Die implizieren (zumindest mit) dass ich eine configfile struktur aufbauen konnte.

Ich befürworte ausdrücklich deinen Vorschlagn, dass diesen File von User nicht editiert werden sollte (ähnlich wie das Statefile). Wie immer in FHEM muss man es nicht verrammlen - aber dem User eine möglichkeit schaffen, ein eigenes File anzuhängen. "User.cfg"

Meine Anregungen
- verschieben das file in ein Unterverzeichnis "setup" oder ähnlich. Das top-verzeichnis gefällt mir nicht besonders - zu ungeordnet.
- der User könnte dort weitere Konfig files ablegen - für HM kann man die device-einstellungen speichern und ggf. nachladen - da gibt es ein paar sinnvolle Ausnahmen.
- erlaube dem User ein UserConfig anzuhängen, das nach dem Config ausgeführt wird. Dort könnte ich meine startup kommandos einstellen - beispielsweise das Nachladen unzugänglicher Device-configs.

Gruss Martin

[rudolfkoenig]

- erlaube dem User ein UserConfig anzuhängen, das nach dem Config ausgeführt wird.

Dafuer gibt es zwei Moeglichkeiten:
- lastinclude
- define nLast notify global:INITIALIZED include myConfig.cfg

[Rince]

Weiß nicht.
Ein eigenes cfg für HM, FS20, ARC, at, Notify, Watchdog etc. schiene mir schlauer.

[Joachim]

Ich schliesse mich Rince an.
Gerade wenn man am testen/basteln ist, kann man so schnell mal einen Adapter/Konfiguration aus dem Spiel nehmen/tauschen.
Außerdem bevorzuge ich es, den Inhalt meiner Configs selbst zu bestimmen (Autocreate ist aus und save tabu).
Bei mir sind z.B. zurzeit 4 verschiedene 1-Wire Varianten auf 4 unterschiedlichen 1-Wire Adaptern am laufen.

Gruß Joachim

[justme1968]

auf dem entwicklungssystem ist es wichtig das konfig file auch von hand ändern zu können. da möchte ich aber nichts anderes als einen vi und ein shutdown restart. da möchte ich nicht das mir irgendjemand in die quere kommt. auch nicht fhem mit rereadcfg und irgendwelchen seiteneffekten.

auf dem produktiv system denke ich gar nicht daran irgendetwas von hand machen zu wollen. fhem soll sich bitte selber drum kümmern das die configuration richtig gelesen und gespeichert wird. wenn irgend wie möglich soll autocreate auch einfach funktionieren. falls nicht lege ich von hand etwas an und konfiguriere im web fontend. auch hier möchte ich keine seiteneffekte durch rereadcfg, irgendwelchen maskierten oder nicht maskierten zeichen oder was auch immer. das system sollte einfach nur funktionieren.

ich sehe also auf keinem der systeme den bedarf das konifig file 'aufzuräumen' oder kommentare darin zu haben oder rereadcfg zu nutzen.

gruss
  andre

[martinp876]

nun - lastinclude sollte also nicht mehr genommen werden.

If this attribute is set, then the last command of the generated configfile (see the save command) will be
include <lastinclude-value>

Die Beschreibung ist etwas nichts-sagend. lastinclude-value - ist der filename? Wird der dann von save auch platt gemacht? Alles nicht beschrieben... aber eh outdated (sollte man einmal wegräumen)

ein notify ist natürlich eine Möglichkeit - kann man machen. Das notify darf ich aber nicht löschen - es wird immer abgeprüft werden - halte ich für eine einmal-ereignis für übertrieben. Wenn ich es lösche ist es beim nächsten Save verschwunden.

So gesehen bleibt aktuell keine empfohlene Lösung.

Vom Handling schließe ich mich meinen Vorrednern an:
- fhem.cfg  sollte editierbar bleiben (wenns sein muss mit vi) - das ist eigentlich unabdingbar. Aber - wie viele der Configfiles - ist es unter SYS-hoheit. wenn man ein Save macht speichert Rudi die defines und Attribute. Somit können entwickler darin herumhantieren - und jeder, der glaubt es zu verstehen. Das ist der aktuelle Stand

- Wenn es jetzt noch ein User.cfg (name ist mir egal) gibt, das Save einfach nicht antastet und dann nach fhem.cfg ausgeführt wird wäre ich zufrieden.

Absolut unbefriedigend ist die zerstörende Implementierung aktuell. Ich schreiben mir ein configfile und editiere kommandos hinein (warum auch immer). Alles funktioniert - dann ein save und alle ist ungefragt einfach gelöscht. Konsequent ist, wenn fhem.cfg entweder Kommandos im file nicht ausführt oder sie rettet.

Im Prinzip sollte FHEM für User, nicht für entwickler gebaut sein - oder?
Entwickler müssen ein save machen können - und sollten ein paar dinge (insbesondere startup kommandos) definieren dürfen.

Ich hoffe mein Standpunkt kommt rüber - vielleicht gibt es noch eine andere Lösung (99_MyUtils.pm ist möglich, aber nicht der User-level den ich suche)

Gruss Martin

[rudolfkoenig]

lastinclude-value - ist der filename?

Ja, include und lastinclude nimmt einen Dateinamen als Argument.

Das notify darf ich aber nicht löschen

Man sollte generell wissen, was die Konsequenzen beim Loeschen sind.
Ich weiss aber von keinem Konstrukt, was dieses Problem nicht hat.

es wird immer abgeprüft werden

Seit dieser Aenderung wird so ein Notfiy nur fuer global Events aufgerufen, stoert also mAn nicht merkbar.
Das notify IST die empfohlene Loesung.

[rudolfkoenig]

Ein eigenes cfg für HM, FS20, ARC, at, Notify, Watchdog etc. schiene mir schlauer.

Das kann man doch alles machen. Man sollte sich nur entscheiden:
- ENTWEDER vi/notepad, include, kommentare/einrueckung/etc und shutdown restart
- ODER autocreate, "online" rename/attribute setzen/etc und save

[Rince]

Ich will auf das Autocreate nicht verzichten. Gerade wenn man ein neues System anfängt, ist schon interessant was da eigentlich wie angelegt wird.
Dann gehöre ich aber zu der Spezies Mensch, die zumindest die Illusion haben will, zu verstehen was da eigentlich passiert. Dazu muss ich aber die Files lesen können.

Da ich jedoch nicht völlig ignorant rumlaufe (jedenfalls nicht dauernd), versuche ich mehr und mehr ohne das Editieren der fhem.cfg zu machen, da du Rudolf, das ja als potentiell gefährlich betrachtest.

Deshalb komme ich mit dem entweder/oder schlicht nicht klar.
(Was habt ihr gegen vi? Benutzt mal Edlin. Dagegen ist vi schon ziemlicher Luxus)

Was noch?
Ja.
Eine alternative Möglichkeit Makros anzulegen und zu speichern. Die 99myUtils sind schon nicht schlecht, aber das wird auch irgendwie unübersichtlich auf Dauer. Eine Art Autoload von selbst geschriebene Makros, Routinen etc. wäre fein.

[rudolfkoenig]

Was habt ihr gegen vi?

Nichts (siehe $VIMRUNTIME/macros/urm/README.txt), ich will nur nicht, dass man erwartet, dass FHEM die eigenen Kommentare/Einrueckung/etc behaelt, und GLEICHZEITIG die automatisch generierten Eintraege an der "richtigen" Stelle einfuegt. Die ganze Diskussion wuerde hier nicht stattfinden, wenn fhem.cfg in einem Datenbank (oder Registry/etc) gespeichert waere.

Eine alternative Möglichkeit Makros anzulegen und zu speichern.

Das sehe ich nicht:
-  ein FHEM-Macro ist nichts anderes als ein notify, den man per trigger aufruft. Sogar Parameter kann man uebergeben. Wenn man den Regexp einfach waehlt (notifyName selbst), dann belastet es das System bei der Event-Verarbeitung gar nicht.
- Wem das zu beschraenkt ist, kann beliebig viele 99*.pm Dateien mit Perl-Funktionen bauen, da hat man "reines" perl zur Verfuegung, die Funktionen ruft man dann aus Notify/etc heraus mir Parameter auf.
- Wem das zu primitiv ist, der kann ordentliche Module schreiben.
- Wem Perl zu doof ist, der kann seine Lieblingsprogrammiersprache verwenden, und etwas ausfuehrbares per notify ("shell-command") aufrufen.
- Oder man baut einen Standalone-Server, und man bindet den per TCP/IP ein (inform/FHEM Befehle).
Ich finde von leicht bis vollstaendig ist alles dabei.

[justme1968]

der 99myUtils mechanismus ist doch nicht auf ein file beschränkt. du kannst ein 99myHeizung, 99myWasAuchImmer, ... und so viele wie dir namen einfallen haben.

jede davon hat auch ein Initiize über das du beim Laden etwas automatisch machen kannst.

gruss
  andre

[Rince]

Danke Andre, ich hatte das verdrängt. Völlig richtig.

Die ganze Diskussion wuerde hier nicht stattfinden, wenn fhem.cfg in einem Datenbank (oder Registry/etc) gespeichert waere.

Das ist ein nicht unspannender Einwand.

Was dagegen spricht:
Abwärtskompatibilität => man müsste wirklich ziemlich viele verschiedene fhem.cfg konvertieren
Viele Codebeispiele im Wiki und im Forum wären vermutlich so nicht mehr umsetzbar
In eine Textdatei kann ich reinschauen und sehe was sich da tut. Das ist bei einer Datenbank schwieriger. Da braucht es mehr als vi.

Wenn man sowas wirklich macht, sollte man zeitgleich eine Dokumentationsoffensive starten. Sonst springen die Leute ab. Ich hab da die ein oder andere Idee, die muss ich mal mit Uli bereden. 

[martinp876]

Hallo Rudi,

mit dem notify kann ich leben - insbesondere wenn "dieser" eingebaut ist. 

Eine Art Autoload von selbst geschriebene Makros, Routinen etc. wäre fein.

nun, das hatte ich ja auch gesucht  - mit dem notify ist es möglich, und so werde ich es nutzen (und für ein paar details in HM empfehlen)
ich erstelle mir ein directory "setup" und dort ein file fhemUsr.cfg, dazu das
define usrCfg notify global:INITIALIZED include setup/fhemUsr.cfg

da kann man dann starten was man will.

Rudis Ansatz, dass fhem.cfg primär ein systemfile ist finde ich immer noch gut. Normal/einfach user sollten garnicht oder nur sehr selten hier editieren (mit der ohne vi ). Entwickler, fortgeschrittene User und Freaks können wie immer tun und lassen was sie wollen. FHEM sollte daher klarstellen, dass beim Ändern des Files "die Garantie erlischt" (im Übertragenen Sinn, klar).

Schön wäre es, das entsprechende Notify, ein userconfig file und ein setup directory zu vereinheitlichen. Das ist keine Code-Änderung sonder nur eine Konvention und sollte in eine Doku.

Gruss Martin