UUID wird gekuerzt

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