(FHEM) Internes
FUUID
Functional Universally Unique IDentifier
Die FUUID ist ein INTERNAL, also etwas, was FHEM intern (bzw. einige Module) benötigen um dem User bessere Funktionalität zur Verfügung zu stellen. Der User soll damit nichts zu tun haben (müssen)
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.
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) :D Gruß Otto
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
csrfToken
Cross Site Request Forgery[1]
csrfToken schützt dich davor, dass dir jemand anderes einen FHEM-Befehl unterjubelt, der das nicht können dürfen soll. Du hast es aber vermutlich nicht so verstanden, aber csrfToken hat eine große Sicherheitsschwachstelle (jemand könnte z.B. hier ein "Bild" einfügen, dessen automatischer Aufruf durch den Browser bei dir zu Hause irgendeine Aktion auslöst) in FHEMWEB behoben und wenn du diese mit none aushebelst, stellst du diesen unsicheren Zustand wieder her. (Informations-)Sicherheit ist meistens nicht so komfortabel wie Unsicherheit, aber - in Anlehnung an einen bedeutenden Denker des 18. Jahrhunderts: Wer Sicherheit für Komfort aufgibt, hat bald weder noch.
define/defmod
Sowohl mit define als auch defmod lassen sich devices anlegen.
Warum gibt es zwei Moeglichkeiten und welchen Befehl nimmt man besser?
Define ist der aeltere Befehl und wurde durch defmod (Dezember 2015) ergaenzt.
Die Notwendigkeit geht wohl darauf zurueck, dass man eine Fehlermeldung erhaelt sobald man ein Device mit define bereits angelegt hat und in bestimmten Faellen nochmal neu anlegen muss/will.
Daher hat Rudolf König mit FHEM 5.6 den neuen Befehel "defmod" eingeführt, der ein noch nicht existieredendes Device wie define neu anlegt, ein bereits vorhandenes Device aber direkt ändert. Die Fehlermeldung "<device> already exists, delete it first" dadurch umgeht, dass erst ein delete und dann ein define ausgefuehrt wird.
Also koennte man auch grundsaetzlich defmod, anstelle von define benutzen.
Ein Beispiel mit 'notify' ist auch auf der Seite "Trick der Woche" beschrieben.
(alt) Fehlermeldung:
define Heizung_an notify Bewegung set HZG_WZ desired-temp 22 ;; define reset_Heizung at +01:00:00 set HZG_WZ desired-temp 16
(neu) Keine Fehlemeldung
define Heizung_an notify Bewegung set HZG_WZ desired-temp 22 ;; defmod reset_Heizung at +01:00:00 set HZG_WZ desired-temp 16
