FHEM Forum

FHEM - Entwicklung => FHEM Development => Thema gestartet von: justme1968 am 15 Januar 2019, 09:22:49

Titel: vorschlag: eindeutige id für jedes fhem device
Beitrag von: justme1968 am 15 Januar 2019, 09:22:49
für manche anwendungen ist es wichtig fhem device eindeutig zu identifizieren. auch nach einem neustart oder nach einem rename.

da nicht alle devices mit tatsächlich vorhandener hardware verknüpft sind kann man nicht auf eine eventuell vorhandene hardware id ausweichen.

ein typischer anwendungsfall: diverse sprach apis lassen sich über eine suche solche eindeutigen ids melden und verwenden diese dann in den events die erzeugt werden. diese ids müssen stabil bleiben auch wenn devices umbenannt werden und sollten keine konflikte erzeugen wenn man ein neues device mit gleichem namen anlegt.


mit dem angehängten patch wird jedem fhem device beim define eine stabile id zugewiesen.

die genauen eigenschaften sind:ein offener punkt:
das wiederherstellen der FUID nach einem neustart geschieht aktuell mit perl code im save file. das ist unschön. ich wollte aber auch keine globales setfuid kommando da die id nicht vom anwender verändert werden soll. hat jemand eine bessere idee?
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: rudolfkoenig am 15 Januar 2019, 10:38:48
Spricht was gegen:
- einem Reading?
- einen "richtigen" UUID (Format XXXXXXXX-XXXX-XXXX-XXXXXXXXXXXX)?
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: Thorsten Pferdekaemper am 15 Januar 2019, 10:46:07
Hi,
ich finde den Vorschlag prinzipiell gut.
Zitat von: rudolfkoenig am 15 Januar 2019, 10:38:48
Spricht was gegen:
- einem Reading?
Das müsste meiner Meinung nach dann aber vor "setreading" geschützt sein und vielleicht sogar unsichtbar in FHEMWEB.

Zitat
- einen "richtigen" UUID (Format XXXXXXXX-XXXX-XXXX-XXXXXXXXXXXX)?
Das fände ich auch besser als die vorgeschlagene Implementierung. UUIDs bringen ja alle Anforderungen schon mit.
Gruß,
   Thorsten
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: justme1968 am 15 Januar 2019, 10:53:08
ja. ein reading ist nicht vor setreading geschützt.

wenn man es mit . versteckt ist es bei jsonlist2 nicht sichtbar.

copy kopiert alle readings. man bräuchte eine ausnahme.

es gibt devices die ein clear readings kommando haben.

außerdem ist es konzeptionell eher etwas internes und nichts das dem device gehört.


das format ist mir im prinzip egal.
wenn man einfach nur eine zufällig uuid erzeugt fehlt der zusammenhang zwischen den devices.

wenn man das berücksichtigt ist es kein problem.
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: rudolfkoenig am 15 Januar 2019, 11:05:13
Alternative:
define/defmod kriegen eine Option --uuid <uuid>, und save erzeugt diese Option.
define mit --uuid uebernimmt es in einem Internal, ohne generiert eine Neue.
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: justme1968 am 15 Januar 2019, 11:12:46
ich glaube eine option ist nicht gut.

der user soll garnichts damit zu tun haben und er soll auch nicht aus versehen ,mist' machen.

Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: Thorsten Pferdekaemper am 15 Januar 2019, 11:20:08
Hi,
es sieht so aus, als ob das "reading"-Konzept einiges an Aufwand nach sich ziehen würde.

Zitat von: justme1968 am 15 Januar 2019, 10:53:08
wenn man einfach nur eine zufällig uuid erzeugt fehlt der zusammenhang zwischen den devices.
Meiner Meinung nach sollte man das trennen. Eine "eindeutige Id" sollte nichts weiter sein als eine eindeutige Id. Wenn man noch andere Eigenschaften oder Beziehungen braucht, dann sollte man die getrennt modellieren.
Oder verstehe ich da was falsch? Was genau meinst Du denn damit?

Zitat von: rudolfkoenig am 15 Januar 2019, 11:05:13
define/defmod kriegen eine Option --uuid <uuid>, und save erzeugt diese Option.
define mit --uuid uebernimmt es in einem Internal, ohne generiert eine Neue.
Theoretisch ist das gut, aber praktisch sehe ich jetzt schon 10 neue Threads pro "fhem.cfg-Editierer". Außerdem wird es bestimmt einige geben, die meinen, sie könnten das für irgendwas benutzen und dann prinzipell beim define direkt diese Option benutzen.
Anders gesagt: Meiner Meinung nach ist es zu einfach, damit Blödsinn zu machen.

Das Ding als Internal in die fhem.save zu packen finde ich gar nicht so schlecht. Was spricht denn dagegen?
Gruß,
   Thorsten
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: rudolfkoenig am 15 Januar 2019, 11:25:04
Die Loesung mit {} in fhem.cfg passt mir nicht, die Argumente von Thorsten bei der Option gelten damit nur verstaerkt.

Ich biete an:
- define mit Option
- reading (mit Ausnahmeregelungen fuer copy  und deletereading)
- neu: extra Datei, nur mit UUID.
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: justme1968 am 15 Januar 2019, 11:30:10
@thorsten: eindeutige ids können (und sollen unter umständen) auch teile enthalten die für zusammengehörige devices (z.b. aus der gleichen FHEM installation) identische teile enthalten. z.b uuids die auf einem bestimmen namensraum basieren. d.h. alle uuids aus einer fhem installation haben z.b. den gleichen prefix. oder innen einen gleichen teil.

@ruid: dass {} war nur ein workaround um zu schauen ob alles geht.

wie wäre es einfach mit einem setuid kommando das analog zu setreading im save file verwendet wird.

kann man das bei help ausblenden?

reading ist glaube ich wirklich nicht gut.
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: justme1968 am 15 Januar 2019, 11:55:12
als format könnte man z.b. so etwas verwenden:

tttttttt-ffff-iiii-ddddddddddddddddd

t -> zeitstempel wir rfc
ffff -> egal aber immer und bei alle fhem installationen gleich -> dies ist eine fhem device id
iiii -> egal aber in jeder installation für alle device ids identisch
dddd -> für jedes device zufällig
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: Thorsten Pferdekaemper am 15 Januar 2019, 12:38:12
Zitat von: justme1968 am 15 Januar 2019, 11:55:12ffff -> egal aber immer und bei alle fhem installationen gleich -> dies ist eine fhem device id
Was soll dann passieren, wenn man eine fhem-Installation auf einen anderen Rechner umzieht? Neue fhem-Id oder die alte belassen? Was soll passieren, wenn man zwei Installationen zusammenfasst oder eine in zwei aufteilt?
...solche Sachen meine ich, wenn ich sage, dass eine eindeutige Id nicht noch anderen Kram haben sollte.
Gruß,
   Thorsten
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: justme1968 am 15 Januar 2019, 12:40:56
wenn man beim umziehen das save file mit nimmt behalten alle devices ihre id

wenn man es nicht mit nimmt werden neue ids erzeugt.

das ist nicht anders wie das mit ebnen der unique id

ich sehe kein problem.
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: zap am 15 Januar 2019, 12:46:04
Ich könnte mir folgende Attribute in einer UUID vorstellen:

- Zeitstempel UTC der ersten Erstellung eines Device
- Eindeutige ID für das verwendete Modul
- Zusätzliche Attribute aus einem Device, z.B. eine Serial oder Adresse, sofern vorhanden.

Leider sind wir noch sehr weit davon entfernt, dass jedes Gerät eine IPv6 Adresse hat. Sonst wäre die für mich ein heißer Kandidat, zumindest für einen Teil der UUID.
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: justme1968 am 15 Januar 2019, 12:52:36
den aktuellen device zustand sollte man nicht mit rein packen.


wir haben je gerade keine hardware bei dummys und co. deshalb brauchen wir etwas das nicht hardware basiert ist.

aber das format ist mit eigentlich ganz egal. so lange es kein reading wird :)
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: herrmannj am 15 Januar 2019, 12:54:52
viele device sind doch überhaupt keine Netzwerk-device -> sowieso keine ip.

Für uuid gibt es doch genügend Standards. Ansonsten schlage ich einen Hash (sha) , gebildet über fhem unique ID + (ursprünglicher) device Name vor. Das ist immer einzigartig. Wenn das device "umzieht" zieht der Hash halt mit um. Gespeichert werden kann der in der fhem cfg, analog der def.
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: justme1968 am 15 Januar 2019, 12:57:01
achso: automatische daten aus dem device wenn möglich.

ja. im prinzip schon.

aber: das was ich oben vorgeschlagen habe ist erst mal komplett unabhängig und geht führ jedes device.

im prinzip steht es einem device frei die von fhem vergebene id nachträglich teilweise zu ändern wenn es tatsächlich eine hardware id gibt.

man darf diese aber nicht 1:1 übernehmen. dann hätten zwei devices in zwei fhem installationen die die gleiche hardware steuern die gleiche fhem id. das soll nicht passieren.
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: justme1968 am 15 Januar 2019, 13:18:50
ich mache einen neuen patch vorschlag mit uuid format und setfuid.

ps: die if sollte im save file stehen. nicht im config file.  sonst ist das risiko sie aus versehen zu kopieren zu groß.
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: rudolfkoenig am 15 Januar 2019, 13:23:10
Zitatich mache einen neuen patch vorschlag mit uuid format und setfuid.
Nicht noetig, so kompliziert ist die Sache nicht. Wird aber bis morgen dauern.
Wir bleiben bei UUID nach dem vorgeschlagenen Muster (t,f,i,d), und setuuid Befehl, was explizit in fhem.cfg gespeichert wird.
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: justme1968 am 15 Januar 2019, 13:24:35
und ablage in internal :)
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: justme1968 am 15 Januar 2019, 14:16:51
bitte ins save file. nicht cfc. grund siehe oben
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: Loredo am 15 Januar 2019, 15:43:35
Bei der Anbindung von 3rd Party Bridges (also z.B. Homematic), die ihre Geräte selbst eindeutig identifizieren, wäre es vielleicht doch auch ganz gut diese ID zu übernehmen statt eine neue UUID zu generieren?
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: justme1968 am 15 Januar 2019, 15:46:19
nein. weil du damit unter umständen zwei fhem devices mit der gleichen id bekommst. die fhem devices sollen aber eindeutig sein.

außerdem soll der code in fhem generell arbeiten und keine änderung an modulen erfordern.
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: Loredo am 15 Januar 2019, 15:56:38
Hm, vielleicht geht dann eine Alias-Funktion o.ä.?
Es wäre ja schon sexy, wenn man auch über mehrere Gateways hinweg zumindest irgendeine einmalige ID hätte.
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: betateilchen am 15 Januar 2019, 18:20:28
Denkt bitte daran, dass es neben fhem.cfg auch noch die configDB gibt.
Und das meiste, was bisher hier im Thread an Ideen geäußert wurde, würde mit der configDB nicht funktionieren.
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: betateilchen am 15 Januar 2019, 18:24:07
Zitat von: herrmannj am 15 Januar 2019, 12:54:52
Für uuid gibt es doch genügend Standards. Ansonsten schlage ich einen Hash (sha) ,

FHEM selbst ist schon lange in der Lage, uuid zu erzeugen.

sub createUniqueId()
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: justme1968 am 15 Januar 2019, 18:29:08
der ansatz mit setfuid im state file sollte mit configDB problemlos gehen. du musst nur die eine zeile aus WriteStatefile entsprechend übernehmen cfgDB_SaveState. oder übersehe ich etwas ?

createUniqueId() erzeugt keine uuid im rfc format. das wollten die herren aber :)
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: betateilchen am 15 Januar 2019, 18:35:48
Eigentlich will ich nur vermeiden, dass Rudi mit einem spontan Schnellschuss einmal mehr Inkompatibilitäten und Probleme verursacht.

Wenn ich sowas lese

Zitat von: rudolfkoenig am 15 Januar 2019, 13:23:10
Nicht noetig, so kompliziert ist die Sache nicht. Wird aber bis morgen dauern.

gehen hier schon die roten Alarmleuchten an. Wir können sowas gerne gemeinsam so implementieren, dass es in beiden "Konfigurationswelten" funktioniert. Aber wir sollten das dann auch in Abstimmung und möglichst zeitgleich tun. Diese Woche komme ich definitiv nicht mehr dazu.

Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: betateilchen am 15 Januar 2019, 18:41:37
Zitat von: justme1968 am 15 Januar 2019, 18:29:08
oder übersehe ich etwas ?

Du übersiehst zumindest, dass es durchaus FHEM Installationen gibt, in denen kein statefile verwendet wird.
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: betateilchen am 15 Januar 2019, 18:56:03
Zitat von: justme1968 am 15 Januar 2019, 10:53:08
ja. ein reading ist nicht vor setreading geschützt.

Wenn ein reading einen festgelegten Namen hat, wäre es überhaupt kein Problem, dieses reading vor einem Überschreiben/Ändern durch setreading zu schützen.
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: justme1968 am 15 Januar 2019, 19:08:22
das wäre aber eine sonderlocke. wenn die id in einem reading steckt sind an allen möglichen stellen sonderbehandlungen nötig (setreading, copy, clear readings...), man muss bei kopieren aufpassen und das prinzip das die readings dem device gehören wird verletzt.

in einem internal ist nirgends sonderbehandlung nötig sogar copy geht komplett automatisch inklusive einer neuen id. die internals gehören auch mindestens zum teil zum system.

ein fhem system ohne state speicher (egal ob file oder db) hält auch keine readings über den start hinweg. d.h. da gehen auch einige andere dinge nicht.
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: rudolfkoenig am 15 Januar 2019, 19:40:38
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.
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: justme1968 am 16 Januar 2019, 09:15:36
einverstanden
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: Thorsten Pferdekaemper am 16 Januar 2019, 09:25:46
Klingt auch für mich vernünftig. Das mit der fhem-Id ist für mich auch ok.
Gruß,
   Thorsten
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: betateilchen am 17 Januar 2019, 08:57:23
*** DAGEGEN! ***

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


Die uuid zu devices gehören für mich definitiv zur Konfiguration und nicht zum Statefile.
Titel: vorschlag: eindeutige id für jedes fhem device
Beitrag 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.

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.
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag 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.
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.
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: betateilchen am 17 Januar 2019, 11:23:44
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...
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: betateilchen am 17 Januar 2019, 11:41:38
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.
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: justme1968 am 17 Januar 2019, 11:43:42
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 :)
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: justme1968 am 17 Januar 2019, 11:54:58
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
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: rudolfkoenig am 17 Januar 2019, 12:25:27
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.
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: justme1968 am 17 Januar 2019, 12:54:13
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.
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: rudolfkoenig am 17 Januar 2019, 13:04:46
Ok, dann setuuid, in fhem.cfg, nur beim Initialisieren, nicht Teil von "list -r".
@betateilchen?
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: betateilchen am 17 Januar 2019, 14:36:49
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.


Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: betateilchen am 17 Januar 2019, 14:40:31
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*
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: betateilchen am 17 Januar 2019, 14:45:23
Zitat von: rudolfkoenig am 17 Januar 2019, 13:04:46
Ok, dann setuuid, in fhem.cfg,

Syntax?


setuuid $name $uuid


und uuid in den Internals kleingeschrieben uuid oder großgeschrieben UUID ?
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: justme1968 am 17 Januar 2019, 15:40:00
syntax: ja.

name: vielleicht fuid oder FUID für fhem unique id. oder FDID für fhem device id. und um konflikte mit einer eventuell anderweitigen uuid zu vermeiden
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: betateilchen am 17 Januar 2019, 15:49:29
Zitat von: justme1968 am 17 Januar 2019, 15:40:00
name: vielleicht fuid oder FUID für fhem unique id.

fuid klingt genau so komisch wie fdid - egal ob klein- oder großgeschrieben, zumal FD schon in den Internals verwendet wird.

FUUID

Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: justme1968 am 17 Januar 2019, 15:51:19
einverstanden
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: betateilchen am 17 Januar 2019, 15:54:45
ok, wenn Rudi mit dem vorgeschlagenen Namen auch einverstanden ist, baue ich das heute in die configDB ein.
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: betateilchen am 17 Januar 2019, 21:07:48
configDB unterstützt ab sofort das Speichern eines Internal FUUID, wenn dieses in einem device vorhanden ist.
Beim FHEM Start wird FUUID - wenn vorhanden - direkt nach dem define gesetzt, die Reihenfolge sieht so aus:


define <name> <type> [<def>]
setuuid <name> <uuid>
attr <name> <attrName> <attrValue>
attr ...


Bei einem "configdb list <deviceName>" wird eine vorhandene FUUID nicht mit ausgegeben, um das gleiche Verhalten wie bei "list -r" zu erhalten.




Was ich noch nicht ganz verstanden habe:

Soll künftig wirklich jedes FHEM device eine UUID erhalten oder wird das im Define des jeweiligen Moduls festgelegt?
Den Sinn einer UUID z.B. bei einem at oder notify kann ich mir nicht herleiten.
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: justme1968 am 17 Januar 2019, 21:14:37
danke!

ja. jedes device. automatisch. ohne das ein modul autor oder ein anwender etwas tun muss.

ja. es gibt devices bei denen es eventuell (noch) überflüssig ist. es ist aber konsistent und vermeidet fehler durch irgendwelche ausnahmen.

auch ein notify oder at lässt sich z.b. in alexa oder siri einbinden um es per sprache zu aktivieren/deaktivieren. dazu muss es eindeutig identifizierbar sein.

module die andere devices referenzieren können das intern jetzt über die uuid tun und können so rename unabhängig sein. LightScene und structure z.b.
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: betateilchen am 17 Januar 2019, 21:22:13
... und irgendwann brauchen devices dann gar keinen Namen mehr  8)
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: nils_ am 18 Januar 2019, 08:46:11
Zitat von: justme1968 am 17 Januar 2019, 21:14:37
module die andere devices referenzieren können das intern jetzt über die uuid tun und können so rename unabhängig sein.
guter plan....
so lange da keiner händisch rumfummelt :)


brauchen wir ne prüfung auf gleiche uuids??
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: justme1968 am 18 Januar 2019, 08:48:32
wer trotz verbot rumfummelt ist selber schuld.
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: DS_Starter am 18 Januar 2019, 10:11:02
Ich finde die UUID Vergabe eine interessante Entwicklung und könnte mir perspektivisch auch  eine hilfreiche Nutzung bei der Eventspeicherung in einer Datenbank vorstellen. D.h. bei einer Auswertung der Tabelleneinträge kõnnte man auf eine gespeicherte FUUID Bezug nehmen.
Ein bisschen Zukunftsmusik, aber sicherlich eine gute Sache.

Grüße,
Heiko
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: herrmannj am 18 Januar 2019, 10:28:51
Zitat von: justme1968 am 18 Januar 2019, 08:48:32
wer trotz verbot rumfummelt ist selber schuld.
Zumindest aus Sicht des Supports kann das ein sehr unangenehmes Problem sein.

Wenn jemand als "support-Geber" nicht erkennen kann warum "sein" modul bei user "x" fehlerhaft funktioniert und man dann erstmal einige post benötigt um rauszubekommen dass "unsachgemäßer Gebrauch" ;) die Ursache ist - dann nervt das. Mindestens

Entsprechende Prüfungen sollten also unbedingt eingebaut werden und log fehler (1) werfen.

* Doppelte UUID
* Der Versuch auf nicht existierende UUID zuzugreifen

Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: justme1968 am 18 Januar 2019, 10:34:35
Zitat von: herrmannj am 18 Januar 2019, 10:28:51
* Doppelte UUID
ja das sollte man später tun wenn die id breitere nutzung findet. dann sollte man auch überlegen eine routinen für name -> uuid und uuid -> name einzubauen. letzteres mit einem globalen hash. und nicht einen in jedem device.

aber bitte lasst die suche nach der 100% perfekten lösung nicht dazu führen das (mal wieder) nichts passiert. ein system das sich (langsam) weiterentwickelt (selbst wenn es machmal einen schritt zurück auf zwei voran geht) ist besser als eines das versucht perfekt zu sein, es nicht schafft und deshalb still steht.

Zitat von: herrmannj am 18 Januar 2019, 10:28:51
* Der Versuch auf nicht existierende UUID zuzugreifen
das ist kein fehler sondern einfach ein gelöschtes device
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: rudolfkoenig am 18 Januar 2019, 10:41:48
Habe setuuid implementiert und eingecheckt.

Bemerkungen:
- Format ist 8-4-4-4-12 (nicht 8-4-4-16), da das eher RFC konform ist.
- Inhalt: alles lowercase hex: Sekunden, Konstante:f33f, letzten 4 Stellen von getUniqueId (was fuer die fhem.de Statistiken verwendet wird), 4 Stellen Zufallszahl, 12 Stellen Zufallszahl.
- Beispiel: 5c419349-f33f-c296-73b5-2d94dbfa5b9da6b4
- gespeichert wird im Internal FUUID
- global kriegt kein FUUID (wg. Henne-Ei-Problem nicht einfach einzubauen).
- setuuid prueft auf Duplikate.
- commandref dokumentiert setuuid als Systembefehl.

ZitatconfigDB unterstützt ab sofort das Speichern eines Internal FUUID, wenn dieses in einem device vorhanden ist.
Das war nach meinem Geschmack etwas zu schnell, ich wollte dich noch ueberreden die GetDefAndAttr() Funktion zu verwenden.
Aber vielleicht ist es nicht zu spaet...



Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: herrmannj am 18 Januar 2019, 10:54:46
Zitat von: justme1968 am 18 Januar 2019, 10:34:35
ja das sollte man später tun wenn die id breitere nutzung findet. dann sollte man auch überlegen eine routinen für name -> uuid und uuid -> name einzubauen. letzteres mit einem globalen hash. und nicht einen in jedem device.

aber bitte lasst die suche nach der 100% perfekten lösung nicht dazu führen das (mal wieder) nichts passiert. ein system das sich (langsam) weiterentwickelt (selbst wenn es machmal einen schritt zurück auf zwei voran geht) ist besser als eines das versucht perfekt zu sein, es nicht schafft und deshalb still steht.
das ist kein fehler sondern einfach ein gelöschtes device
Ich stimme Dir schon zu ("...100% perfekt..."), das darf aber keine Entschuldigung sein nachzudenken und Dinge gleich richtig zu machen. Geht am Ende schneller ;)
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: betateilchen am 18 Januar 2019, 12:14:30
Zitat von: rudolfkoenig am 18 Januar 2019, 10:41:48
Das war nach meinem Geschmack etwas zu schnell, ich wollte dich noch ueberreden die GetDefAndAttr() Funktion zu verwenden.
Aber vielleicht ist es nicht zu spaet...

Es ist nie zu spät. Aber bevor ich GetDefAndAttr() in configDB verwenden kann, müsste die Behandlung von Attributen, die NICHT gespeichert werden dürfen, noch angepasst werden. Patch folgt.
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: betateilchen am 18 Januar 2019, 12:31:04

Index: fhem.pl
===================================================================
--- fhem.pl     (revision 18313)
+++ fhem.pl     (working copy)
@@ -1619,13 +1619,15 @@
   push @ret, "setuuid $d $defs{$d}{FUUID}"
         if($dumpFUUID && defined($defs{$d}{FUUID}) && $defs{$d}{FUUID});

+# exclude attributes, format <deviceName>:<attrName>, space separated list
+  my @dontSave = qw(configdb:rescue configdb:nostate configdb:loadversion
+                    global:configfile global:version);
   foreach my $a (sort {
                    return -1 if($a eq "userattr"); # userattr must be first
                    return  1 if($b eq "userattr");
                    return $a cmp $b;
                  } keys %{$attr{$d}}) {
-    next if($d eq "global" &&
-            ($a eq "configfile" || $a eq "version"));
+    next if (grep { $_ eq "$d:$a" } @dontSave);
     my $val = $attr{$d}{$a};
     $val =~ s/;/;;/g;
     $val =~ s/\n/\\\n/g;


Auf meinem Testsystem habe ich gerade eine so gepatchte fhem.pl und eine configDB, die GetDefAndAttr() verwendet, erfolgreich getestet. Die FUUID werden alle angelegt und nach einem Neustart wiederhergestellt.

Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: betateilchen am 18 Januar 2019, 12:41:58
Mir ist gerade aufgefallen, dass GetDefAndAttr() in den Forward-Deklarationen der fhem.pl noch fehlt.
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: betateilchen am 18 Januar 2019, 17:39:42
Zitat von: justme1968 am 18 Januar 2019, 10:34:35
dann sollte man auch überlegen eine routinen für name -> uuid und uuid -> name einzubauen.

das geht grundsätzlich auch jetzt schon...

{(defInfo('FUUID=5c41b807-f33f-01d2-8853-63bca4a2bcd43a69','NAME'))[0]}

liefert bei mir korrekt den deviceName oc_test

und umgekehrt liefert

{(defInfo('NAME=oc_test','FUUID'))[0]}

5c41b807-f33f-01d2-8853-63bca4a2bcd43a69
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: rudolfkoenig am 18 Januar 2019, 18:09:41
@betateilchen: hab dein Patch + Forward-Deklaration eingecheckt.

Ich frage mich, wieso wir beide fuer nicht zu speichernde Internal Values Attribute verwenden.
Leider wird global version und global configfile auch von anderen Modulen geprueft, sonst haette ich es jetzt ausgebaut.
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: betateilchen am 18 Januar 2019, 19:04:34
Zumindest für das globale Attribut "configfile" kann ich Dir Deine Frage beantworten.

Es ist die einzige Chance für einen configDB Nutzer, aus seiner Konfiguration wieder eine lauffähige fhem.cfg zu erzeugen.


Auch wenn es m.E. keinen Grund gibt  8) 8) 8) von der configDB wieder zurück zu den altertümlichen Textdateien zu wechseln, sollte man den Usern diesen Weg nicht versperren, indem man dieses Attribut ausbaut. Man könnte den Rückweg natürlich auch anders bauen, aber diese Möglichkeit ist zumindest die logischste und sie ist bereits vorhanden, dokumentiert und bewährt.

Den Sinn des "version" Attributes habe ich allerdings noch nie verstanden.
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: betateilchen am 18 Januar 2019, 19:08:36
Zitat von: rudolfkoenig am 18 Januar 2019, 18:09:41
@betateilchen: hab dein Patch + Forward-Deklaration eingecheckt.

Danke, ich habe eben die dazu passende configDB.pm eingecheckt.
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: herrmannj am 19 Januar 2019, 23:11:40
Da klemmt es noch irgendwo: https://forum.fhem.de/index.php/topic,96172.0.html
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: betateilchen am 20 Januar 2019, 11:15:03
noch ein Grund mehr, rereadcfg zu entsorgen :)
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: betateilchen am 20 Januar 2019, 20:13:28
Macht es eigentlich in jedem Fall Sinn, dass ein device seine FUUID behält, wenn man die DEF (ggf. komplett) ändert?

Meiner Meinung nach: eher nicht.
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: justme1968 am 20 Januar 2019, 20:17:42
ich denke in den meisten fällen schon.

das lässt sich nicht wirklich automatisch entscheiden.

wenn es tatsächlich mal probleme gibt: löschen und neu anlegen.
Titel: Antw:vorschlag: eindeutige id für jedes fhem device
Beitrag von: CoolTux am 20 Januar 2019, 20:18:10
Warum nicht? Das Device an sich bleibt ja existent. Es ändern sich nur Eigenschaften.
Ähnlich wie bei einem Objekt.