UUID wird gekuerzt

[rudolfkoenig]

Otto123 ist hier: https://forum.fhem.de/index.php/topic,94494.msg1160727.html#msg1160727 aufgefallen, dass die von FHEM generierte UUID zu lang ist. Ich will es jetzt korrigieren, und um 4 Stellen (2 Bytes) verkuerzen. Es geht nur um das Generieren, alte UUIDs werden nicht angefasst.

Falls jemand meint, das wuerde trotzdem bestimmte Module stoeren, und scharen von Benutzer in Unglueck stuerzen, der moege sich hier melden.

[herrmannj]

Ich verwende UUID, bspw bei den Schellenberg Handles um den Rolling Code aktuell zu halten oder in JsonMod um die Secrets zu speichern (und weitere)

Ich habe keine Bauchschmerzen. Die Idee das zu kürzen, macht aber überhaupt keinen Sinn. Für eine UUID gilt dass sie eine geringe Kollisions-Wahrscheinlichkeit haben muss, sprich hohe Entropie. Ein Verkürzen mindert die Entropie, erhöht zwangsläufig die Kollisions-Wahrscheinlichkeit. Dadurch wird es also schlechter. Merksatz: ein "zu-lang" bei UUIDs gibts überhaupt nicht. Das wäre jetzt höchstens ein Argument wenn man die UUIDs zu irgendwas kompatible halten _muss_, was meiner Meinung nach nicht der Fall ist. Dazu kommen dann die Risiken, dass es eben doch zu Fehlern in bestehenden Installationen kommt.

Wenn's also nur Nachteile hat, Frage: wozu das Ganze?

[betateilchen]

Klar, je länger desto "sicherer", aber bisher wollte nach meinem Kenntnisstand noch niemand eine Atomrakete per FHEM steuern.

Gemäß RFC4122 besteht eine UUID aus 32 Zeichen. Was spricht dagegen, dass auch FHEM sich daran orientiert?

In configDB verwende ich auch UUID, eine Verkürzung auf die standardkonformen 32 Zeichen hätte keine negativen Auswirkungen.

[herrmannj]

selten so einen unqualifizierten Kommentar gelesen. Atomraketen standen nie zur Diskussion. RFC4122 referenziert klar die Versionen 1-5. Je nach Version der UUID wird Einzigartigkeit in "Space und Time" angestrebt. Das involviert (je nach Version) die MAC Adresse sowie Clock im 100ns Slots. Damit Clock auch bei Zeit- Anpassungen (NTP / Sommer- Winterzeit) funktioniert gibt es eine Clock Sequence. Daher ist der Verweis auf RFC4122 in etwa genauso qualifiziert wie ein möglicher Verweis auf die 16bit Bluetooth UUID. Da steht auch UUID dran, das kann man nicht leugnen und das ist ebenfalls ein Standard. Lass uns doch den nehmen

[betateilchen]

Hast Du schlecht geschlafen letzte Nacht?

[herrmannj]

ich habe volles Verständnis für die Aufgabenstellung von Otto. Die lässt sich aber ganz leicht lösen indem getUUID() mit anschließendem substr() verwendet wird. Ich wiederhole: bei der vorgeschlagenen Änderung überwiegen die Risiken das Ergebnis.

Btw, natürlich gibt es fertige Module (zb https://metacpan.org/pod/Data::UUID) die das alles schon können. Würden wir die verwenden, dann würden wir die Diskussion hier nicht führen. Machen wir aber nicht, weil dann der Anwender die Abhängigkeiten installieren müsste. Was der Anwender nicht müsste wenn wir eine anständige Toolchain hätten und per Docker Container liefern würden. Was, btw, allen Anwender die gleiche perl Versionen garantieren könnte. Haben wir aber nicht und deshalb diskutieren wir stattdessen über ein kosmetisches Rand-Detail unter Ausschluss aller Logik.

[Christoph Morrison]

ich habe volles Verständnis für die Aufgabenstellung von Otto. Die lässt sich aber ganz leicht lösen indem getUUID() mit anschließendem substr() verwendet wird. Ich wiederhole: bei der vorgeschlagenen Änderung überwiegen die Risiken das Ergebnis.

Wo siehst du denn konkrete Risiken?

Btw, natürlich gibt es fertige Module (zb https://metacpan.org/pod/Data::UUID) die das alles schon können. Würden wir die verwenden, dann würden wir die Diskussion hier nicht führen. Machen wir aber nicht, weil dann der Anwender die Abhängigkeiten installieren müsste. Was der Anwender nicht müsste wenn wir eine anständige Toolchain hätten und per Docker Container liefern würden. Was, btw, allen Anwender die gleiche perl Versionen garantieren könnte. Haben wir aber nicht und deshalb diskutieren wir stattdessen über ein kosmetisches Rand-Detail unter Ausschluss aller Logik.

Ja, da bin ich absolut bei dir.

[herrmannj]

Wo siehst du denn konkrete Risiken?

geringere Entropie + mögliche (!=sichere) Nebenwirkungen in modulen welche FUUID verwenden - vs - "kosmetische Änderung"

Wo siehst Du einen Gewinn?

[Christoph Morrison]

Wo siehst Du einen Gewinn?

Ich hab mir noch keine Meinung gebildet. Im Zweifel würde ich jetzt einen Wechsel auf Data::UUID vorschlagen. Davon hätten wir nämlich wirklich was: weniger duplizierten Code, der UUID auch nicht besser macht als das CPAN-Modul.

Man (also Rudi, als head honcho) könnte ja einen Major-Version-7-Thread starten, in dem er alle fundamentalen Änderungen ankündigt und darin auch die Nutzung von Data::UUID. Otto könnte bis dahin die UUID manuell kürzen (prüfen ob länger als x, dann kürzen).

(halb ot:
Ein Kandidat für diesen Thread wäre dann auch gleich DevIo so zu ändern, dass es nicht mehr direkt auf $hash->{STATE} schreibt und den Nutzern die Hoheit darüber wieder zurück gibt (dazu gibt es schon irgendwo einen Thread).)

[Otto123]

Hallo Jungs,

ich habe eigentlich gar kein Problem mit der Länge der UUID. Ich hatte mir (mangels Kenntnis) eine UUID einfach im System geholt (cat /proc/sys/kernel/random/uuid).
Gestern dachte ich, ich kann doch auch einfach die von FHEM nehmen und hab mir die Frage gestellt: Ist eine UUID immer eine UUID ? (also mit gewissem Aufbau) oder ist das einfach eine große (je größer je besser) Zufallszahl?
Die Dinger untereinander kopiert und da fiel es auf 
Kurz gesucht und gefunden: es gibt eine Festlegung für die UUID / GUID : 128 bit, Algorithmus, 32 Zeichen in definierten Gruppen plus 4 Bindestriche = 36 Zeichen gesamte Länge usw.
Ich dachte: hier ist in der FHEM Implementierung ev. ein Fehler passiert.

Es ist immer gut sich an Standards zu halten.  und an Fehlern muss man nicht zwingend festhalten. Ich will damit nicht sagen es ist ein Fehler passiert - aber die FUUID entspricht nicht dem gängigen Standard.
Jetzt wäre noch zu klären: Nimmt FHEM Typ 3 oder Typ 4 ? (ich duck mich) 

Gruß Otto

[justme1968]

ich sehe nicht warum wir in fhem etwas kürzen müßten/sollten. falls wir zu irgendetwas kompatibel sein wollen müßen: ja. das sehe ich aber nicht.

die dinger heißen ja nicht umsonst fuuid und nicht uuid. wer eine uuid braucht die irgendwelchen standards entsprich kann ausgehen von der fuuid ja eine erzeugen.

eine änderung die einfluß auf alte fuuids hat wäre problematisch und würde unter anderem alle homekit und alexa anwender betreffen die alles was mit den geräten dort zu tun hat neu einrichten müssten. das sind mindestens 2000-3000 installationen.

da die alten also gleich bleiben sollten finde ich es wichtiger das fhem zu sich selber kompatibel bleibt und erst mal nichts geändert wird.

wenn es irgendwann mal tatsächlichen bedarf für eine 'standard' uuid gibt kann man die zusätzlich einführen oder aus der fuuid ableiten.

[Christoph Morrison]

Das kodifiziert halt mal wieder einen FHEM-Sonderweg, der nur entstanden ist, weil man sich weigert, Standardmodule für Standardfunktionalität zu nutzen.

eine änderung die einfluß auf alte fuuids hat wäre problematisch und würde unter anderem alle homekit und alexa anwender betreffen die alles was mit den geräten dort zu tun hat neu einrichten müssten. das sind mindestens 2000-3000 installationen.

Dann könnte man zumindest neue UUID (ob mit oder ohne f ist mir wumpe) nach dem RfC generieren lassen, alte aber weiterhin akzeptieren. Und bitte einfach das Modul dafür benutzen.

[justme1968]

warum sonder weg? es ist doch nirgendwo festgelegt das es etwas mit uuid zu tun hat.

böse könnte man jetzt sagen: wenn wir damals direkt meinen vorschlag umgesetzt hätten und das ding dann fid genannt hätten gäbe es keine assoziationen zu irgendetwas uuid mäßigem und die diskussion wäre garnicht erst entstanden

im übrigen: die fuuid ist sowieso nicht in einem sinne eindeutig das das gleiche hardware device immer die gleiche fuuid bekommt sondern nur ein ein mal per define erzeugtes fhem devise behält seine id. wenn das device gelöscht und neu angelegt wird ändert sich die fuuid. auch wenn fhem neu aufgesetzt wird bekommt das gleiche hardware ding eine neue fuuid. mac oder andere adressen der endgeräte fliesen also sowieso nicht ein.

[Christoph Morrison]

warum sonder weg? es ist doch nirgendwo festgelegt das es etwas mit uuid zu tun hat.

Weil es auch für die Erzeugung anderer IDs fertige Module gibt, die nicht nur in FHEM eingesetzt werden, besser/überhaupt getestet sind und für andere Entwickler dann halt kein neues Konzept zu lernen ist.
Von mir aus kann auch Zing::Id, Data::ID::Exim oder was auch immer verwendet werden, nur halt kein neues Konzept mit neuem Code. Ich finde es immer so entnervend, für Standard zu argumentieren. Argumentiert ihr doch mal, was an einer eigenen Implementierung so viel besser ist, dass ich CPAN dafür links liegen lassen soll. Ich hab ja ne Idee, aber ich bin gespannt.

böse könnte man jetzt sagen: wenn wir damals direkt meinen vorschlag umgesetzt hätten und das ding dann fid genannt hätten gäbe es keine assoziationen zu irgendetwas uuid mäßigem und die diskussion wäre garnicht erst entstanden

Hätte der Hund ...

im übrigen: die fuuid ist sowieso nicht in einem sinne eindeutig das das gleiche hardware device immer die gleiche fuuid bekommt sondern nur ein ein mal per define erzeugtes fhem devise behält seine id. wenn das device gelöscht und neu angelegt wird ändert sich die fuuid. auch wenn fhem neu aufgesetzt wird bekommt das gleiche hardware ding eine neue fuuid. mac oder andere adressen der endgeräte fliesen also sowieso nicht ein.

Spricht das dagegen, alte "legacy" UUID neben neuen, standardkonformen zu verwenden? Neue Geräte bekämen dann halt eine richtige, standardkonforme UUID, alte Geräte behalten ihre alte. Und in ein paar Jahren/im übernächsten major release können wir die dann auch nicht mehr akzeptieren.

[justme1968]

nein. das verhalten ist so gewünscht. die id soll ja genau für ein them device eindeutig sein. wenn mehrere fhem devices die gleiche fuuid verwenden würden wenn es das gleiche endgerät ist gäbe es alle möglichen konflikte. zumindest in meinem anwendungsfall.

ich habe kein problem mit standards. ganz im gegenteil. es muss aber passend sein.

die diskussion ob es sinnvoll ist existierende module in fhem einzubinden hat mit dem thema hier nur am rande zu tun und es wurden schon einige argumente dafür und auch dagegen vorgebracht. ich glaube es bringt an dieser stelle nichts die diskussion eines einfachen konkreten problems  darauf auszuweiten.

[Christoph Morrison]

nein. das verhalten ist so gewünscht. die id soll ja genau für ein them device eindeutig sein. wenn mehrere fhem devices die gleiche fuuid verwenden würden wenn es das gleiche endgerät ist gäbe es alle möglichen konflikte. zumindest in meinem anwendungsfall.

Worauf antwortest du mit "nein"?

Ich halte das ansonsten auch für eine sehr kurzfristige Denke. Mein "FHEM" ist ein HAB und besteht aus vielen FHEM, Datenbankservern, Bridges, etc. und da hätte ich auch gerne lokalglobal oder globallokal eindeutige UUID. Und ich weiß, dass ich nicht der einzige mit einem etwas umfangreicheren Setup bin.

ich habe kein problem mit standards. ganz im gegenteil. es muss aber passend sein.

Was ist an UUIDs nach RfC im konkreten Fall denn unpassend? Oder ist es unpassend, weil man es halt irgendwann mal nicht nach RfC gemacht hat und jetzt nicht mehr weg davon will, also eher unbequem als unpassend?

die diskussion ob es sinnvoll ist existierende module in fhem einzubinden hat mit dem thema hier nur am rande zu tun und es wurden schon einige argumente dafür und auch dagegen vorgebracht. ich glaube es bringt an dieser stelle nichts die diskussion eines einfachen konkreten problems  darauf auszuweiten.

In beiden Fällen nutzt man keine bewährten, standardisierten Dinge, sondern jeweils Sonderlösungen. Die haben in beiden Fällen auch keine Vorteile gegenüber den Standardlösungen. Ich sehe hier ein gewisses Muster. Ist ja nix neues, reinventing the square wheel (ein Anti-Pattern der Softwareentwicklung) sieht man ja überall, aber warum wird das so vehement verteidigt, zumal ich eine Lösung vorgeschlagen habe, die das Problem löst ohne Probleme im Bestandscode der Anwender auszulösen?

[herrmannj]

vorsicht: zuerst mal hat Microsoft ja genauso eigene UUIDs erfunden (die GUUID), und die sind jetzt da der "Standard". Dann ist globale (Zeit und Raum) Einzigartigkeit nur bei V1 und V2 garantiert (sehr schwer zu implementieren), alle anderen Versionen haben eine Kollisionswahrscheinlichkeit >0, aber eben praktisch vernachlässigbar. Die FHEM FUUID ist ironischerweise aufgrund der größeren Länge (und vmtl Nichtbeachtung der Normkennung) sogar besser aufgestellt als V3,4,5 - technisch halt V4 mit verringerter Kollisionswarscheinlichkeit (also besser!).

Ich halte es daher für wenig klug das jetzt, im Nachhinein, ändern zu wollen Wohingegen ich es ausdrücklich befürworte, zukünftig einfach existierende Bibliotheken für alle Routine Aufgaben zu verwenden.

[justme1968]

Worauf antwortest du mit "nein"?

Ich halte das ansonsten auch für eine sehr kurzfristige Denke. Mein "FHEM" ist ein HAB und besteht aus vielen FHEM, Datenbankservern, Bridges, etc. und da hätte ich auch gerne lokalglobal oder globallokal eindeutige UUID. Und ich weiß, dass ich nicht der einzige mit einem etwas umfangreicheren Setup bin.

das nein bezog sich auf das (irgendwann) ändern für alte bestehende installationen/geräte. das wird ein paar tausend anwender gegen dich aufbringen ohne das unterm strich auch nur der aller kleinste vorteil vorhanden wäre.


der fall einer endgeräte eindeutigen id die auch zwischen mehreren fhem instanzen gleich wäre ist ein komplett anderer anwendung fall und unterscheidet sich vom jetzigen anwendunsfall. ich habe kein problem damit dafür eine eigene zusätzliche id in fhem zu haben. behaupte aber das es garnicht allgemein möglich ist da es endgeräte ohne id gibt die sich schlicht und einfach nicht eindeutig identifizieren lassen. d.h. der node part aus dem rfc ist nicht eindeutig bzw. kann nur die fhem instanz selber statt dem endgerät sein.

abgesehen davon finde ich es lustig das es inzwischen tatächlich eine ganze reihe befürworter einer id gibt. bei der diskussion damals gab es einige gegenstimmen.


ich hatte in den letzten jahren eine ganze menge mit standards zu tun. und bin ganz sicher nicht dagegen. etwas als standard anzusehen von dem es entweder x versionen gibt oder das versucht x hersteller varianten unter einen hut zu bekommen in dem alles (optional) möglich ist bzw. bleibt ist oft nur dem namen nach ein standard und gehört sehr genau beobachtet.

ich bin auch nicht gegen das wiederverwenden. aber fertige module als allheilmittel zu sehen ist gefährlich. sobald diese sich unkontrolliert schneller als der eigene code verändern oder auf uraltem stand stehen bleiben mach mehr unnötige arbeit als gewisse module mit einer hand voll code zeilen selber zu schreiben und unter kontrolle zu haben. so schön es mit npm sein kann mal schnell etwas einzubinden so übel werden die dependencies im laufe der zeit. das gleiche gilt für node versionen sobald man über die installierten systeme unterschiedliche versionen supporten muss.

ps: von osf oder dce (wie sie im rfc erwähnt werden) über asn.1, xml, json (wie sie nacheinander 'der letzte schrei' waren/sind) oder isdn und atm gibt und gab es viele andere standards die nach einer weile dann doch nicht mehr so relevant waren.

aber wird driften immer weiter vom eigentlichen thema ab.


die fuuid bestehender devices sollte sich auf keinen fall ändern. jede änderung die die kollisionswarsheinlichkeit relevant erhöht sollte unterbleiben und mehrere installationen dürfen nicht die gleiche id vergeben auch wenn es das gleiche en endgerät ist. alles andere ist mir erst mal egal

[rudolfkoenig]

Ich will die aufregende (oder aufgeregte?) Diskussion nicht stoeren, wollte nur leise vermerken, dass ich meinen urspruenglichen Vorhaben (die erzeugte UID zu kuerzen) hiermit offiziell zurueckziehe. Ich wundere mich, was ich dabei ueberhaupt gedacht habe .

Nur fuers Protokoll: ich hatte nie vor alte FUUIDs zu aendern, ganz so wahnsinnig bin ich dann doch nicht.

Mein "FHEM" ist ein HAB

Fuer nicht Eingeweihte: was ist ein HAB? Die Vorschlaege aus dem Internet (https://acronyms.thefreedictionary.com/HAB) erscheinen mir nicht gerade plausibel, obwohl manche fantasieanregend sind.

[CoolTux]

Ich will die aufregende (oder aufgeregte?) Diskussion nicht stoeren, wollte nur leise vermerken, dass ich meinen urspruenglichen Vorhaben (die erzeugte UID zu kuerzen) hiermit offiziell zurueckziehe. Ich wundere mich, was ich dabei ueberhaupt gedacht habe .

Nur fuers Protokoll: ich hatte nie vor alte FUUIDs zu aendern, ganz so wahnsinnig bin ich dann doch nicht.
Fuer nicht Eingeweihte: was ist ein HAB? Die Vorschlaege aus dem Internet (https://acronyms.thefreedictionary.com/HAB) erscheinen mir nicht gerade plausibel, obwohl manche fantasieanregend sind.

HAB = Home Automation Bus
Zu mindest würde ich es so verstehen.