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.