[FHEMWEB Patch] exportdevice

[Loredo]

Hallo Rudi,


mit Hinweis auf diesen Beitrag findest du anbei einen Patch für FHEMWEB, um dort den exportdevice-Befehl mit einzubauen.




Gruß
Julian

[rudolfkoenig]

Ich finde dein Patch ist noch nicht reif:
- zu den export-Daten gehoert auch setreading.
- mit quote (bzw. der Abwesenheit von quote) sollte man gar nicht erst anfangen.
- Export ohne Import ist nicht viel Wert. Telnet zaehlt nicht: dann haette ich fuer exportdevice "Edit Files/fhem.cfg"
- eigentlich muesste man exportdevice in CommandSave einbauen bzw. dessen Code mitverwenden, damit man Code nicht doppelt.
- Bin noch unsicher, ob mich die Zusatzangeben in Kommentar stoeren oder nicht

[betateilchen]

- zu den export-Daten gehoert auch setreading.

Das sehe ich (und andere User offenbar auch) anders. Denn mit "configdb list <device>" gibt es diese "Exportfunktion" schon lange, und bisher hat noch niemand die readings vermisst.

Aber wieso man einen "export" irgendwo explizit im Frontend einbauen sollte, erschließt sich mir nicht wirklich.

[rudolfkoenig]

Aber wieso man einen "export" irgendwo explizit im Frontend einbauen sollte, erschließt sich mir nicht wirklich.

Damit man jemandem einfacher eine Beispielkonfiguration zeigen kann. Sei es zum Nachahmen, oder zum Fehler melden. Insb. im letzten Fall ist setreading wichtig.

[betateilchen]

setreading ist (zur Problemlösung) nie wichtig.

[Loredo]

Danke, Rudi, für die schnelle Antwort.

- zu den export-Daten gehoert auch setreading.

Ich bin da eher bei Betateilchen, allerdings mehr deshalb, weil ich die Ausgabe gerne schlank halten wollte und es mir nicht darum geht ein Device mit exakt seinem Zustand zu exportieren. Den Zustand möchte man(ich) eigentlich immer eher konsistent durch das Modul und seine Definition nebst Attribute selbst lokal erzeugen.

- mit quote (bzw. der Abwesenheit von quote) sollte man gar nicht erst anfangen.

Ja, ich hatte da auch geschwankt, dachte mir aber es wäre so vollständiger. Auch wenn wir viel unternommen haben, dass Leute die fhem.cfg nicht direkt editieren (wo es ohne configDb noch geht), so wollte ich den Unterschied schon deutlich herausstellen, weil er den meisten Nutzern wohl nicht direkt auffallen dürfte und die Verwunderung dann groß ist, wenn sie meinen so schlau zu sein so etwas einfach in die fhem.cfg hinein zu kopieren. Zumindest den Hinweis "Flat Export" am Anfang würde ich deshalb drin lassen wollen. Auch wenn mir da bisher kein treffenderer Begriff eingefallen ist wo man genau weiß, was gemeint ist... Klar, eine Variante mit Quotes kann sich der Kenner auch direkt aus der fhem.cfg ziehen. Aber eben doch nicht so komfortabel, vor allem auch weil die heute früh eingecheckte Version auch noch die Option für die dependent Objekte beinhaltet, damit man sich eine zusammenhängende Gruppe aller Devices einfach mal zusammen ausgeben lassen und weitergeben kann. Das ginge über manuelles kopieren aus der fhem.cfg nur sehr umständlich. Aber dafür brauchts trotzdem nicht undbedingt die Quotes - anders gesagt: Ich bin da leidenschaftslos.

- Export ohne Import ist nicht viel Wert. Telnet zaehlt nicht: dann haette ich fuer exportdevice "Edit Files/fhem.cfg"

Absolut, ja! Ich habe mich daran versucht, steige aber durch all die verschiedenen JavaScript Querverweise und Zusammenhänge einfach nicht durch... ich weiß, dass es alle Bausteine dazu gibt und man die nur zusammen puzzeln muss, ich bin aber gescheitert.
Daher sollte dieser Patch einfach mal ein Anfang für die Einbindung in FHEMWEB sein. Für Support-Zwecke ist er ja auch so schon brauchbar.

- eigentlich muesste man exportdevice in CommandSave einbauen bzw. dessen Code mitverwenden, damit man Code nicht doppelt.

Eigentlich habe ich das auch gewollt, aber ich schreibe wirklich nicht gerne deinen Code um. Es dauert für mich sehr lange den zu lesen und die Zusammenhänge ohne z.B. Kommentare im Code einigermaßen zu begreifen. Ich glaube einfach nicht, dass ich alle Seiteneffekte überblicken kann und wollte mich deshalb lieber auf separate Bausteine konzentrieren, bei denen ich mich auskenne. Wenn es aber dein Wunsch ist, mache ich bei Gelegenheit einen Versuch (die Zeit schwindet nun leider grad) auf die Gefahr hin ausgelacht zu werden.

- Bin noch unsicher, ob mich die Zusatzangeben in Kommentar stoeren oder nicht

Du hast ja richtig erkannt, dass ich das auch für Forum Posts und Support gedacht hatte. Deshalb dachte ich es wäre auch sinnvoll die Versionsinfo des Moduls dem User gleich mit anzubieten. Dann besteht die Chance, dass man diese manchmal wertvolle Zusatzinfo gleich gratis dazubekommt. Womöglich fällt es einem User aber auch mal von selbst auf und er spart sich die peinliche Antwort auf "have you tried to update first" 


Was man wohl eher in devspec2array einbauen müsste wäre noch, dass ich eine Sortierung nach Modulname haben wollte, damit alle Devices mit dem selben Modul zusammen stehen und sich der Modulheader dann nicht mehrfach in der Ausgabe wiederholen muss (ausgenommen dependent Objects, für die zwar das selbe Device nicht mehrfach aufgeführt wird, jedoch andere Devices vom selben TYPE womöglich als eigenständiges/nicht-dependent Device und da würde ich dann wieder einen Header sehen wollen.

[rudolfkoenig]

Hier mischen wir zwei Sachen (export fuer Wiki bzw. Code-Weitergabe und Debugging). Fuer Wiki braucht man weder eine Modulversionsangabe, noch setreading, bei debugging schon. Vermutlich braucht man dafuer zwei Links oder eine Umschaltmoeglichkeit nach dem ersten Link.

Ich bin immer noch auf dem Stand: Ohne Quotes ist ein Export sinnlos. Da man mehrere Befehle auf einmal einlesen muss, muss man wissen, wo man die Befehle trennen soll.  "Zeile fuer Zeile reinkopieren" ist fuer mich keine Alternative zu einem import..

die heute früh eingecheckte Version auch noch die Option für die dependent Objekte beinhaltet

Das ist aber geraten, und wenn man das konsequent weiterverfolgt, dann musste man manche Definitionen abwaehlen, und welche dazuwaehlen koennen, was mir den Aufwand in die Hoehe treibt.

Ich setzte das auf meine TODO Liste, es sei denn es kommt vorher eine Loesung, wo ich kein Meckerbedarf habe .

[betateilchen]

es sei denn es kommt vorher eine Loesung, wo ich kein Meckerbedarf habe

Hast Du mal versucht, eine Drehtür zuzuschlagen?

[Loredo]

betadingens, wenn du was zu sagen hast, dann sag es doch bitte nach vorne heraus.


Gruß
Julian

[betateilchen]

Ich habe doch schon eindeutig geschrieben, dass ich in diesem Zusammenhang die setreadings für entbehrlich halte.
Genauso entbehrlich übrigens wie eine explizite Import-Funktion, denn Importieren lässt sich eine mehrzeilige (def + attr) Gerätedefinition bereits jetzt problemlos per telnet.

Man muss doch nicht immer jede einfache Idee auf die kompliziertest mögliche Art und Weise umsetzen, wenn man sich einfach mal auf das Wesentliche besinnen würde und darum, worum es eigentlich bei der Idee geht.

[rudolfkoenig]

Ich meine ich habe eine vergleichbare Funktionalitaet jetzt implementiert, jedenfalls teilweise.
- list hat die Option "-r" bekommen, was Definition+Attribute+Readings im "fhem.cfg" Format anzeigt.
- in der Detailansicht kann man ganz unten mit "Raw definition" die Ausgabe von "list -r" einblenden.
- Falls man in diesem Fenster was aendert, kann man es mit "Apply changes" anwenden.

Ich gehe davon aus, dass es noch nicht perfekt ist, hat aber ein paar Tests bei mir aber schon ueberstanden.
Fehlt noch: Versionsangabe fuer debugging. Bin noch unsicher, ob man sowas braucht.

[Loredo]

Klasse, finde ich gut! Vielen Dank.


Mir fehlt noch die Möglichkeit -r mitzugeben, dass ich "mal eben schnell" alle mutmaßlich zusammenhängenden Objekte gesammelt ausgeben lassen möchte. Danach wäre es ein sehr guter Ersatz für exportdevice.

Kann man vielleicht per Parameter auch die setstate Befehle weglassen? Wenn man die reine Device-Definition weitergeben wollen würde und dabei vielleicht auch mehrere Devices auf einmal ausgeben lässt, dann ist es je nach Anzahl der Readings sehr mühsam die dann überflüssigen setstate Befehle wieder zu löschen. Ein einfaches Copy&Paste "mal eben schnell" fürs Forum ist damit nicht so einfach. Ich erkenne schon den Charme das gleich dabei zu haben, aber vielleicht kann man das irgendwie optional machen?


Die Quotes standardmäßig mit auszugeben sehe ich wohl ein, insbesondere bei mehrzeiligen Values. Über Telnet lassen sich die so erzeugten Exporte bisher noch nicht wieder per copy&paste einlesen?
Den Raw-Edit in FHEMWEB finde ich eine gute Idee. Was mir dazu noch einfällt:


1. Codemirror Support
2. Könnte man das Raw Edit Fenster auch mit leerem Inhalt nach einem Doppelklick auf die normale Befehlszeile als modales Fenster anzeigen, um dort per Copy&Paste eben diese Befehle, die man z.B. irgendwo im Forum vorfindet, mehrzeilig dort hinein zu kopieren und dann auszuführen? Das scheint nun in greifbarer Nähe als "low hanging fruit"
3. "Apply changes" sollte (zumindest unter der Device Detaildarstellung) nur die Befehlszeile(n) ausführen, in der wirklich etwas geändert wurde. Dabei müssen natürlich die mehrzeiligen Befehle berücksichtigt werden... (kniffelig, ich weiß). Ansonsten kommt es ja einem selektiven reload der fhem.cfg gleich und ich bin nicht sicher, ob man das immer will? Vielleicht will man auch beides können.


Die Versionsangabe als Kommentar finde ich halt immer nett. Ggf. kann man das ja gesammelt für alle beteiligten Module und fhem.pl ganz am Ende als Kommentar anzeigen? Tut doch eigentlich nicht weh. Bei der Raw-Ausgabe für ein einzelnes Device in FHEMWEB könnte man es ggf. auch weglassen, obwohl es auch hier sicherlich nett wäre etwas versteckt mal schnell zu erfahren, welche Version das Modul hat.

[rudolfkoenig]

Mir fehlt noch die Möglichkeit -r mitzugeben, dass ich "mal eben schnell" alle mutmaßlich zusammenhängenden Objekte gesammelt ausgeben lassen möchte.

"Zusammenhaengend" ist subjektiv, und selbst das wird in FHEMWEB(!) nicht fehlerfrei realisiert. Jemanden sinnlose Definitionen weiterzugeben, nur weil das schnell geht, verwirrt nur den Empfaenger. Da sollte der Lieferant lieber ein bisschen mehr Zeit investieren, da es hoffentlich mehr Empfaenger als Lieferanten gibt.

Kann man vielleicht per Parameter auch die setstate Befehle weglassen?

Im Moment nicht, und wuesste auch nicht warum man das sollte. Beim Debuggen ist das sinnvoll, und bei der Weitergabe der Definition tut nicht weh, eher hilft es. Als Kompromiss habe ich list -r so umgebaut, das erst alle defines/attr (also das was in fhem.cfg landet) und dann die setstates (das was in fhem.state landet) gezeigt werden.

1. CodeMirror: Habs versucht, leider hebelt das die beobachtung der Textarea aus, um den Knopf ein- bw. auszublenden. Wenn jemand das fixen kann, bitte melden.
2. Doppelklick auf die normale Befehlszeile: Kann man bestimmt irgendwie, bin noch nicht ueberzeugt ob das a) intuitiv und b) an dieser Stelle sinnvoll ist. Andere Meinungen?
3. Bin auch hier nicht so recht ueberzeugt. Ich will diesen Fenster nicht als Alternative/Konkurrenz zu den bisherigen Methoden pushen. Um Missverstaendnisse zu vermeiden habe ich den Knopf in "Execute commands" umbenannt.

Die Versionsangabe als Kommentar finde ich halt immer nett. [...] Tut doch eigentlich nicht weh.

Doch. Sinnloses Code/Daten/etc tun weh, weil man Energie aufwenden muss, um das Sinnvolle rauszufischen.

[Loredo]

Da sollte der Lieferant lieber ein bisschen mehr Zeit investieren, da es hoffentlich mehr Empfaenger als Lieferanten gibt.

Nicht unbedingt. Wenn ich mehrere Häuser verwalte bin ich oft selbst der Empfänger solcher Schnipsel. Da wäre es eine Erleichterung alles zusammen ausgeben lassen zu können. Das war für mich der Hauptgrund exportdevice zu schreiben.

Im Moment nicht, und wuesste auch nicht warum man das sollte. Beim Debuggen ist das sinnvoll, und bei der Weitergabe der Definition tut nicht weh, eher hilft es. Als Kompromiss habe ich list -r so umgebaut, das erst alle defines/attr (also das was in fhem.cfg landet) und dann die setstates (das was in fhem.state landet) gezeigt werden.

Ok, ist ein Kompromiss.

Doch. Sinnloses Code/Daten/etc tun weh, weil man Energie aufwenden muss, um das Sinnvolle rauszufischen.

Hm. Genau so argumentiere ich für die Option setstate wegzulassen. Zum debuggen ist IMHO list ohne -r nach wie vor am sinnvollsten, weil dort auch die INTERNALS dabei sind und man somit nur dort ein wirklich vollständiges Bild bekommt.
Die -r Option kann (und soll auch in meinen Augen) eher der Weitergabe von Konfigurationen dienen. Diese dann auf der anderen Seite wieder einzuspielen fehlt halt nur noch, dann wäre der Workflow komplett. Einige wollen auch einfach Devices komplett klonen können. Ist auch ok, dass man dafür dann setstate haben kann. Für mich ist es eben nur optional...


Nun steht setstate am Ende, darunter noch Zeilen für die Modulversionen einzubinden wäre jetzt auch nicht weiter schlimm. Ich sehe aber ein, dass ich hier gerade (ähnlich wie du auch) gegen mich selbst argumentiere und die Debug-Infos somit eigentlich zum normalen list dazugehören würden.
Aber ok.


Edit:
Was trotzdem dafür spricht: Module entwickeln sich weiter und wenn man ein Schnipsel irgendwo findet möchte man ggf. einschätzen können zu welcher Modulversion es einmal gepasst hat. Es kann immer sein, dass eine direkte Übernahme alter Schnipsel mit einer neueren Modulversion nicht mehr funktioniert und die Version fest zu einem Schnipsel mitzugeben könnte dabei helfen, dass User schneller einschätzen können, dass eine Fehlermeldung beim Re-Import vielleicht deshalb auftritt, weil ein alter Schnipsel nicht mehr kompatibel ist.

[rudolfkoenig]

Diese dann auf der anderen Seite wieder einzuspielen fehlt halt nur noch, dann wäre der Workflow komplett.

Das kann man im telnet, oder in der "Raw definition" Fenster tun.