vorschlag: eindeutige id für jedes fhem device

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

Vorheriges Thema - Nächstes Thema

betateilchen

#45
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 ?
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

justme1968

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
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

betateilchen

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

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

justme1968

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

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

betateilchen

ok, wenn Rudi mit dem vorgeschlagenen Namen auch einverstanden ist, baue ich das heute in die configDB ein.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

justme1968

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.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

betateilchen

... und irgendwann brauchen devices dann gar keinen Namen mehr  8)
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

nils_

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??
viele Wege in FHEM es gibt!

justme1968

wer trotz verbot rumfummelt ist selber schuld.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

DS_Starter

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
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

herrmannj

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


justme1968

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
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

rudolfkoenig

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...




herrmannj

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 ;)