vorschlag: eindeutige id für jedes fhem device

Begonnen von justme1968, 15 Januar 2019, 09:22:49

Vorheriges Thema - Nächstes Thema

rudolfkoenig

Ich stelle fest:
justme1968 will UUID nicht als Reading. Da sonst keiner ein UUID braucht, waere es sinnlos es als Reading zu implementieren.
Um es als Internal zu implementieren muss es in fhem.pl und in configdb implementiert werden.

Vorschlag:
- ich implementiere uuid & co, im CommandDefine wird aber zunaechst UUID bei configDB nicht gesetzt.
- die zum Speichern notwendigen Befehle werden in einem neuen GenerateStatefile() Funktion implementiert, was ein Array von FHEM-Befehlen zurueckliefert, und in WriteStatefile (falls nicht configDb) per FileWrite geschrieben wird.
- betateilchen stellt irgendwannmal cfgDB_SaveState so um, dass sie GenerateStatefile verwendet.
- danach aktiviere ich die UUID Generierung im CommandDefine auch fuer configDb.
- Falls justme1968 nicht auf betateilchen warten will, dann muss sein code damit klarkommen, dass System mit und ohne UUID gibt.

justme1968

hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Thorsten Pferdekaemper

Klingt auch für mich vernünftig. Das mit der fhem-Id ist für mich auch ok.
Gruß,
   Thorsten
FUIP

betateilchen

*** DAGEGEN! ***

In der configDB dürfen die uuid auf keinen Fall im Statefile gespeichert werden. Dagegen sprechen mehrere Gründe.


  • das Statefile ist für den Betrieb von FHEM derzeit komplett unwichtig und es wäre schön, wenn das so bleibt
  • es gibt durchaus sinnvolle Szenarien, in denen ein FHEM komplett ohne Statefile gestartet wird
  • der wichtigste Grund, der gegen das Statefile spricht: In der Konfigurationsdatenbank werden die Konfigurationen versioniert, aber nicht das Statefile. Es existiert immer nur das "letzte" Statefile. Wenn nun ein Nutzer eine vorherige Konfiguration aus der Konfigurationsdatenbank wiederherstellt (das ist ja der Hauptzweck der Datenbank) kommt es zu Inkonsistenzen, da in einer vorherigen Version mehr/andere devices existieren können als im letzten Statefile. Das heißt, es können durchaus uuid zwischenzeitlich verlorengegangen sein.

Die uuid zu devices gehören für mich definitiv zur Konfiguration und nicht zum Statefile.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

justme1968

#34
du wirst eine ganze reihe anwender finden die nicht der meinung, sind das state file währe unwichtig.

vermutlich sogar einige die dir sagen der aktuelle systemzustand ist das wichtigste an fhem. wenn werte nicht aktuell sind ist das ein defekt.

ohne darüber zu argumentieren wie sinnvoll eine db ohne komplette sicherung ist:

wenn state file nicht zur zurück gerollten konfiguration passt dann ist das im fall der uid wie das löschen und eventuell neu anlegen eines device. das hierbei automatisch eine neue id vergeben wird ist ok und sogar beabsichtigt. ich sehe kein problem.

zur verdeutlichung:
gerät ist jetzt da, war in der alten version da -> id bleibt erhalten.
gerät ist jetzt da, in der alten version nicht -> gerät verschwindet mitsamt id
gerät ist nicht da, in der alten version schon -> bekommt neue id. wie löschen und anlegen.
gerät ist nicht da, war nicht da -> alles ok
ein gerät mit gleichem namen aber unterschiedlichem TYPE ist zu beiden zeitpunkten da -> problem mit allen readings da sie dem falschen device zugeordnet werden.

also bezüglich der id kein echtes problem. selbst wenn ein alter zustand mit neuem state file kombiniert wird.


noch mal: readings gehören dem device (und dem anwender). das system sollte hier nichts zusätzlich erzeugen. es gibt devices und anwender die alle readings löschen. dann wäre auch die id mitten im betrieb weg und wird noch nicht mal wieder neu angelegt.

eine von system eindeutig vergebene id gehört zu den internals. genau so wie notify order, nr, port oder filedescriptoren. es ist nichts das der anwender konfiguriert oder beeinflussen sollte.


unabhängig vom speicher ort: mir geht es vor allem um den speicher ort im betrieb. und der sollte in den internals liegen. aus den weiter oben im thread aufgerührten gründen wenn es ein reading ist und aus rein logischen.

wenn die db ein problem mit dem statefile hat steck es in eine eigene  tabelle oder ins config file. es muss noch nicht mal der gleiche ort wie im filesystem fall sein. es sollte völlig transparent sein. configdb benutz ja jetzt schon eine eigene routine.

im ,normalfall' kann es trozdem das statefile sein.

wichtig ist es aus den internals zu holen und mit setfuid wider herzustellen.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

dev0

Gedanklich hatte ich schon öfters den Wunsch Internals über einen FHEM Neustart hinweg, wie Readings auch, wiederverwenden zu können.
Bei mir ging/geht es um Device-Einstellungen, die von Devices geliefert werden, die sich sehr selten bei FHEM melden. Ein Reading wollte ich nicht verwenden, da der User es löschen könnte oder ggf. das Device auch auch einen gleichnamigen Wert liefert (sleep, model, ...), der als Reading gespeichert wird.

Vielleicht könnte man den Ansatz Internals persistent zu halten noch etwas verallgemeinern und eine Möglichkeit schaffen bestimmte Internals im Modul zu benennen, die einen FHEM Neustart überleben. Einen Patch habe ich nicht parat und habe mich mit einer globalen Lösung auch noch nicht auseinandergesetzt.

mMn wäre das statefile ideal für die Speicherung geeignet, auch wenn configdb ggf. angepasst werden müßte.

betateilchen

Zitat von: justme1968 am 17 Januar 2019, 09:22:13
wenn state file nicht zur zurück gerollten konfiguration passt dann ist das im fall der uid wie das löschen und eventuell neu anlegen eines device. das hierbei automatisch eine neue id vergeben wird ist ok und sogar beabsichtigt. ich sehe kein problem.

Ich sehe da durchaus ein Problem. Wenn ich mich als Anwender dazu entschließe, eine vorherige Version mit allen darin enthaltenen devices wiederherzustellen, dann will auch wieder genau diese IDs haben, die zum Zeitpunkt des Speicherns der gesamten Konfiguration definiert waren. Und keine neuen. Es ist nämlich durchaus denkbar, dass z.B. in 99_myUtils auch mit den uuid gearbeitet wird.

Zitat von: justme1968 am 17 Januar 2019, 09:22:13
du wirst eine ganze reihe anwender finden die nicht der meinung, sind das state file währe unwichtig.

Die Anwender dürfen diese Meinung gerne haben. Aber trotzdem ist es so, dass das statefile aus technischer Sicht bisher nicht notwendig ist, um aus den gespeicherten Konfigurationen ein lauffähiges System mit allen in der Konfiguration vorhandenen devices zu erzeugen. Deshalb muss für mich auch die uuid eines devices aus der config kommen und nicht aus dem statefile.

Zitat von: dev0 am 17 Januar 2019, 10:57:12
Gedanklich hatte ich schon öfters den Wunsch Internals über einen FHEM Neustart hinweg, wie Readings auch, wiederverwenden zu können.

auweia...
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

Zitat von: dev0 am 17 Januar 2019, 10:57:12
mMn wäre das statefile ideal für die Speicherung geeignet, auch wenn configdb ggf. angepasst werden müßte.

Es geht nicht darum, configdb anzupassen oder nicht. Es geht darum, was logisch wäre und Sinn macht.

Das was Du willst, sind readings, die vom User nicht geändert werden können. Das ist ein nachvollziehbarer Wunsch. Aber deshalb muss aus einem reading noch lange kein Internal werden. Man könnte sich auch eine Art "schreibgeschützter" readings vorstellen, die vom Benutzer nicht verändert oder gelöscht werden können. Damit würden die Werte in ihrer Funktion als reading erhalten bleiben, es stehen m.E. ohenhin schon viel zuviele Dinge in den Internals, die da eigentlich nicht hingehören.

Zitat von: dev0 am 17 Januar 2019, 10:57:12
Bei mir ging/geht es um Device-Einstellungen, die von Devices geliefert werden, die sich sehr selten bei FHEM melden.

Das ist der klassische Fall eines readings, genau dadurch sind readings definiert: Werte, die vom device geliefert werden.




Übrigens: der User kann auch Internals löschen und verändern, wenn er das möchte. Und es ist im Forum und im Wiki auch schon oft genug dokumentiert, wie man das macht.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

justme1968

Zitat von: betateilchen am 17 Januar 2019, 11:41:38
Das ist der klassische Fall eines readings, genau dadurch sind readings definiert: Werte, die vom device geliefert werden.
ja!


die id wird aber nicht vom device geliefert und fehört genau deshalb nicht in ein reading :)
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

justme1968

noch mal konstruktiv:

könne wir uns darauf einigen:

- die id in die internals zu stecken
   als reading gibt es wirklich probleme. s.o.

- den zustand mit einem setfuid kommando wieder herzustellen

- das setfuid zum wiederherstellen ins config file zu schreiben wenn das notwendig ist wie bei config db

- das setfuid zum wiederherstellen ist state file zu schreiben wenn das möglich ist wie bei fhem installationen ohne configdb
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

rudolfkoenig

#40
Vielleicht hilft es aufzufrischen, wie es eigentlich gedacht war:
- Internals sind Werte, die fhem.pl oder ein Modul im Betrieb braucht, aber nicht persistiert werden muessen, oder beim Persistieren impliziert in anderem Form vorliegen (wie Name/Typ/Nr).
- Readings sind die Werte, die ein Modul persisitieren will. Gehoeren dem Modul (und nicht dem Benutzer), und sind nicht vom Benutzer zu aendern. Werden mindestens so haeufig gespeichert, wie fhem.cfg, und fhem.cfg ohne die dazugehoerigen Readings zu restaurieren schreit nach Problemen.

Da manche Module Readings falsch geliefert oder umbenannt haben, ist irgendwannmal userReadings/setreading/deletereading dazugekommen, und die klare Trennung verlorengegangen. Ich werde keinen neuen Mechanismus zum persistieren der Internals anlegen, da es frueher oder spaeter den Weg des Readings nimmt, eher koennen wir manche Readings von setreading/deletereading schuetzen.

Nach etwas Nachdenken sollte ein UUID meiner Ansicht nach:
- in fhem.cfg gespeichert werden, da es kein aenderbarer Modul-Wert ist.
- als Internal dargestellt werden
- dem Benutzer "unmoeglich" gemacht werden, es zu aendern.

Ich preferiere immer noch die "define -uuid" Methode (das Modul hat im DefineFn den "richtigen" Wert, und muss nicht explizit benachrichtigt werden), lasse mich bei passenden Argumenten aber auch auf den setuuid Befehl ein.
Beiden ist es gemeinsam, dass:
- nur bei der FHEM Initialisierung verwendet werden koennen
- im "list -r" nicht angezeigt werden
=> Ein Benutzer sollte damit UUID weder weitergeben, noch nachtraeglich aendern koennen.

Wer per fhem.cfg Editieren die UUID aendert, kopiert oder weitergibt, der braucht sich nicht zu beschweren.
Waere noch ein Argument gegen direktes Editieren.

justme1968

bis auf das define mit allem einverstanden.

ein problem am define: man muss bei der implementierung aufpassen. es gibt module die DEF ändern. oder so prüfen das es probleme geben könnte.

es wäre eine vermischung von user und system dingen bei den define parametern.

wenn man sich die mühe macht es vor dem speicher ins define zu stecken und nach dem lesen erst mal wieder dort rauszuholen fühlt es sich irgendwie unständlich und unsauber an.

readings und attribute sind in der DefineFn auch noch nicht da. von daher macht es nichts wenn sich die id später kommt.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

rudolfkoenig

Ok, dann setuuid, in fhem.cfg, nur beim Initialisieren, nicht Teil von "list -r".
@betateilchen?

betateilchen

setuuid als Befehl in der Konfiguration zu speichern, passt für mich perfekt.
An dem Vorschlag saß ich auch gerade auf meiner aktuellen Bahnfahrt.

Und über eines sind wir uns doch im Klaren: User editieren nicht nur die fhem.cfg sondern auch die fhem.save wenn sie das wollen. Insofern bietet der Speicherort selbst überhaupt keine "Sicherheit" für irgendeinen Wert, den man irgendwo speichert.


-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

#44
grundsätzlicher Hinweis:

"define --irgendeinParameter <name> <type> <bla>"

passt aufgrund der Datenstruktur der configDB generell nicht.




Zitat von: rudolfkoenig am 17 Januar 2019, 12:25:27
Ich werde keinen neuen Mechanismus zum persistieren der Internals anlegen, da es frueher oder spaeter den Weg des Readings nimmt, eher koennen wir manche Readings von setreading/deletereading schuetzen.

*gefällt mir*
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!