Hier können wir zum Thema Imker-IDs diskutieren.
Aus Usability-Sicht finde ich die langen und nicht human-readable Imker-IDs unpraktisch. Sie tauchen doch dann auch in der URL bei Grafana auf, oder? Die kann man dann nicht mehr “aus dem Kopf” und mal schnell, z.B. auf “fremden” Rechner, Tablets, Handys eingeben. Und gab es nicht auch Probleme mit einer MQTT-Lib bei (zu) langen topics?
Nicht zwangsläufig, sondern
-
nur, wenn die Leute ihr (automatic-)dashboard nicht umbenennen, bzw. kopieren, umbenennen und das alte löschen
-
nur bei der ‘alten’ (?) Grafana-API vor 4.2(?) , mit welcher zu dieser Zeit unserer automatic-Dashboards angelegt wurden
Ein nach der alten API angelegtes dashboard heißt dann z.B.
“hiveeyes 21f6c33d-0056-4b54-a916-15462d470bb5 automatic” , die URL davon weist genau das aus:
https://swarm.hiveeyes.org/grafana/d/000000169/hiveeyes-21f6c33d-0056-4b54-a916-15462d470bb5-automatic
Sobald ein jedes dashboard umbenannt wird, heißt auch die URL so, wie man sie sich merken möchte. ;) Dazu sollten wir die Leute einfach anhalten, dies zu tun.
Die dashboards, die mit der http-API zum Einrichten seitdem gebaut werden, lassen sich auch an jenem Teil erkennen, welcher hintern dem “grafana/d/” steht: es sind dort keine Ziffern mer, sondern alphanumerische Zeichen zu sehen, z.B.
https://swarm.hiveeyes.org/grafana/d/OnAfiIkiz/hiveeyes-open-hive-christian-automatic
mqtt-topic-Länge: in vielen Fällen mußte einfach die MAXBUFFERSIZE oder MAX_PACKET_SIZE vom default höher gesetzt werden, und dann ging das.
Außerdem ist es ja gerade moll’s Ansatz mit der ULID, daß sie trotz timestamp und entropy kürzer ist als eine (128bit-)UUID.
Es finde es ein absolut wünschenswertes feature, daß spätestens die influxdb-Datenbanken, aber auch schon die einzelne mqtt-transmission diesen Namensbestandteil haben - aus naheliegenden Gründen; und diese Namen baucht man sich nun nicht wie eine URL merken können.
Was den mqtt-Bus angeht, benötigen wir hier auch einfach eine automatische Diversifizierung; wir können ja mal wetten, wie lange es dauert, bis was kollidiert, weil es so viele sind, daß die Leute z.B. hiveeyes/matthias/Beute1/… oder hiveeyes/christian/hive1/… zweimal haben.
Zumal wir hier irgendwann auch mal eine dynamische Verwaltung der Zugriffrechte brauchen werden. Im Moment nutzen wir die ACLs file basiert, das kann aber irgendwann auch in eine Datenbank liegen.
Danke an @weef und @einsiedlerkrebs für die Ausführungen!
I hear you, see Alternatives to UUIDs as network identifiers - #3 by Andreas. Ausblick: Let’s use snowflake / sonyflake, e.g. 20f8707d6000108. Mehr ist an dieser Stelle kaum möglich - außer selbermachen - aber das würde ich ungern tun.
Ja, da können wir durchaus entgegenkommen. Allerdings ist zu berücksichtigen, dass ¹
Das bleibt vermutlich teilweise immer noch wahr, trotz der nun maximal komprimierten technischen Identifizierer. Wir werden jedoch auch human-readable identifier “on top” einführen, vgl. Vanity-Domain – Wikipedia bzw. https://en.wikipedia.org/wiki/Vanity_number. So wird ein Schuh draus, weil man dadurch das Beste aus beiden Welten bekommt. Hier wird dann das “first come, first serve” Prinzip gelten, analog zum Handling von Wunschnamen wie auf anderen Plattformen auch.
¹ hier - wie von @weef beschrieben - die komplette MAX_PACKET_SIZE relevant ist. Das heißt in die Rechnung geht sowohl die Länge des Topic Strings, als auch die des Payloads und obendrein der Platzbedarf für die mqtt auth credentials ein. Wir reißen also u.U. mit unseren durchaus längeren JSON Payloads - je nach Anzahl der Sensoren - ohnehin die Latte ggü. dem default Wert. Es ist aber kein Problem, in unserem Stack eine angepasste Lib zur Verfügung zu stellen bzw. lässt sich die #define Konstante vermutlich auch auf unserer Seite anpassen, ohne irgendeine invasive Änderung machen zu müssen. Darüber hinaus hat man ja immer die Möglichkeit, die Meßwerte auch diskret zu versenden.
Das mit dem “Aus-dem-Kopf-Eingeben” finde ich kein Problem, denn man muß das ja nicht tun:
- das Umbenennen eines dashboards auf einen Namen, der diesen initialen ‘human unerwünschten’ Namensbestandteil nicht hat, ist kein Problem, damit ändert sich nach Abspeichern auch dessen URL (Dann ist da zwar noch jener Teil …/grafana/d/NnZi6Pmmk/hiveeyes-open-hive-…, den man aber AFAIK nicht ändern kann …? @moll?)
aber viel wichtiger:
- solange man sich an swarm.hiveeyes.org erinnern kann, wird auf /grafana weitegeleitet, und dort kann man oben, wo sonst der dashboard-Name steht, sofort suchen, - und wer dort sein dashboard nicht findet…
Im Falle von Grafana ist das wohl wahr, ich schiele aber auch auf besseres Handling bei der Adressierung des (lowlevel) Datenkanals an sich, z.B. hinsichtlich Exportfunktionalität oder anderweitiger Ansteuerung an Grafana vorbei - etwa, wenn wir irgendwann einmal verschlüsselten und authentifizierten (Lese-)Zugriff direkt auf InfluxDB erlauben sollten oder ähnliche Späße. Auch auf dem MQTT Bus kommt das ganze dann kompakter rüber.
Ja, nach meiner Erfahrung ist das die Grafana-interne eineindeutige ID der Dashboard Instanz, die über ihren Lebenszyklus hinweg nicht mehr verändert werden kann, zumindest nicht durch die UI/API/Shell. Macht für mich Sinn, weil sich dadurch das Label ändern kann, das ist ganz ähnlich gestaltet wie bei Discourse und anderen modernen Deep-Linking Contentsystemen, bei denen man sowohl eindeutige Adressierung als auch den “sprechenden Namen” (Titel/Slug) des Artikels irgendwie in der URL untergebracht haben will und sich letzteres auch ändern können darf.
Im Gegensatz zu Discourse, wo der stabile Identifizierer ruhig aufsteigend und damit enumerierbar sein darf, will man das bei Systemen wie Grafana oder anderen oft anders, gerade wenn die adressierbaren Ressourcen nicht von vornherein in einem Index verzeichnet sind und anonymen sowie voneinander isolierten Charakter haben. Dort will man solche Identifizierer dann oftmals bewusst nicht enumerierbar haben.
Eben so etwas wie die Grafana Dashboard UIDs:
Das brauche ich grade anderswo, deshalb hab ich mir hier was zusammengesucht:
def unique_id(salt):
"""
Generate unique ids based on Hashids.
Hashids are short, unique, non-sequential ids generated from numbers
and suitable to be used as unguessable and unpredictable short UIDs.
Here, we are generating Hashids of the current timestamp in milliseconds.
To keep the footprint low, a custom epoch is used which starts on Jan 1, 2019.
Examples::
1Zk5zBoQ
Y4Mvj5Zx
2b4NBvYe
XaMvl962
yzgOlvap
"""
now = int(round((datetime.utcnow() - datetime(2019, 1, 1)).total_seconds() * 1000))
return hashify(salt, now)
if __name__ == '__main__':
print(unique_id('Hotzenplotz'))
Utility functions
from datetime import datetime
from binascii import hexlify
from hashids import Hashids
def hashify(salt, *data):
"""
Hashids are short, unique, non-sequential ids generated from numbers
and suitable to be used as short UIDs.
If you want to decode the Hashids later, you should keep your salt stable.
Remark: Hashids are not limited to encode a single number, you can actually
pack a list of numbers into a single Hashid.
- https://hashids.org/
- https://github.com/davidaurelio/hashids-python
"""
hashids = Hashids(salt=salt)
return hashids.encode(*data)
def gensalt():
"""
This generates a salt from 24 random bytes from an OS-specific randomness source.
The returned data should be unpredictable enough for cryptographic applications,
though its exact quality depends on the OS implementation.
https://docs.python.org/3/library/os.html#os.urandom
Examples::
b5f95cead701f2488d5668decb0d63a30e7ddb4c21f26574
b4157e5459c88a6c454186492ee629ca097f8a60cbfb1a36
de1ba437524e540e3b0d55617afcad5677b982d9e1f45f9d
"""
return hexlify(os.urandom(24))
Damit wirds gemacht.
By the way, Grafana uses this guy:
See also: grafana/pkg/util/shortid_generator.go at v6.1.6 · grafana/grafana · GitHub
Gerade entdeckt. Nice!
six-nibble-name
About
A minimal, light-weight Python module for converting six nibbles (three bytes) into a 4-character name.
Description
The idea behind the design of this module is to convert somewhat unique, ugly names into something not only readable, but memorable. We are using this for giving real names to devices yielding unique identifiers such as those retrieved through the unique_id() call from ESP8266 MicroPython.
Code example
>>> import sixnibblename
>>> sixnibblename.get(0x123456)
'Mori'