mqtt2.template: bugs, Fragen, Anregungen

Begonnen von Beta-User, 15 Dezember 2018, 11:44:43

Vorheriges Thema - Nächstes Thema

rudolfkoenig

ZitatIch verstehe noch nicht warum die Bindestriche in der CID beim autocreate des MQTT2_DEVICE in Unterstriche umgewandelt werden (müssen?)
Weil Bindestriche keine gueltigen Zeichen im FHEM-Namen sind, das ist nur a-z0-9._
Siehe auch makeDeviceName() in fhem.pl
Weiss nicht mehr, woher die Aversion gegen dieses Zeichen herkommt, vermutlich hat das was mit Rechnen zu tun.

Otto123

#451
Ja, das habe ich mir auch gedacht. Aber es geht ja nicht um den Namen sondern um eine ClientID von MQTT die malträtiert wird damit sie in den Namen passt (klar) aber diese verunstaltete ClientID wandert anschließend in die DEF und damit in das Internal CID!?

Ok, ich kann das "heilen" in dem ich die DEF nicht leer lassen sondern die echte CID einlese und reinschreibe, damit wird auch das Internal überschrieben. Eine leere DEF löscht das Internal CID nicht.

Und ich habe nicht verstanden, warum die Umwandlung nicht nur Zeichen ersetzt sondern auch noch Eines anfügt - das ist doch ein Bug Edit : in meinem Template, siehe unten?
android-da1a23fb-12bf-1234-a1d2-123c4567b89b
android_da1a23fb_12bf_1234_a1d2_123c4567b89b_
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

rudolfkoenig

Ich wuerde jetzt eine Wette anbieten, dass da hinten ein unsichtbares Zeichen herumlungert.

Otto123

#453
Ich wollte spontan dagegen halten :) aber ich habe das herumlungernde Zeichen gefunden  ;D :-[
Mit dieser Programmzeile steht am Ende des Strings $uuid ein Zeilenumbruch: :o
{my $uuid=qx(cat /proc/sys/kernel/random/uuid);;fhem("attr MQTT_Worx clientId android-$uuid")}
Es ist also ein bug in meinem Template!

Ist es legitim wenn ich es so umschreibe? Ich brauche eigentlich eine UUID mit 32/36 Stellen, die sub genUUID in fhem.pl erzeugt eine UUID mit 36/40 Stellen (da erhebt sich die Frage: Wieso eigentlich? Laut Definition ist das zuviel? https://de.wikipedia.org/wiki/Globally_Unique_Identifier ;)

{my $uuid=substr(genUUID(),0,36);;fhem("attr MQTT_Worx clientId android-$uuid")}


Im Template dann:Das war ein Gedankenfehler, es gibt dafür ja kein Template. Kommt wir oben ins setup.
par:UUID; UUID generate from fhem subroutine; substr(genUUID(),0,36)
...
attr DEVICE clientId android-UUID
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

rudolfkoenig

Mit der Laenge scheinst Du recht zu haben, komisch, dass bisher das keinem aufgefallen ist.
Bin unsicher, ob ich das jetzt fixen soll, da ich die Nebeneffekte nicht blicke. Meinungen?

Otto123

1. Wer verwendet bisher wirklich die FUUID? Es gab Leute die haben ne Routine geschrieben um die regelmäßig aus der Config zu löschen weil sie "schlimmes" vermuteten.
2. Ich habe im Kopf: Du hast die mal eingeführt weil man das in Zukunft brauchen könnte. Wenn sie bis jetzt nicht Kriegsentscheidend war würde ich es jetzt fixen.
3. die Bestehenden bleiben, die Neuen werden GUID konform. Eine unique ID ist es in jedem Fall. Man könnte auch drübergehen und alle einkürzen - würde ich nur "anbieten" und nicht ungefragt ausführen.

Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

rudolfkoenig

FUUID wurde auf die Anfrage der Alexa/etc Sprachsteuerungs-Fraktion eingefuehrt, damit Geraete eindeutig uebers Umbennen identifiziert werden koennen. Loeschen muss man es nicht, das Speichern kann man mit dem (undokumentierten) "attr global disableFeatures saveuuid" untersagen. Theoretisch kann man ohne Bedenken kuerzen, weil ja keiner bitte die Laenge pruefen soll, andererseits bin ich in letzter Zeit vorsichtiger, und selbst das hilft nicht immer, siehe die aktuelle IODev Diskussion.

Otto123

Ich weiß, in Jurassic Park hieß es: Die Natur findet einen Weg ... - Bei FHEM heißt es: der Anwender findet einen Weg ... (etwas so zu benutzen wie es nie vorgesehen war)
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Beta-User

Zitat von: rudolfkoenig am 03 Juni 2021, 15:24:10
Meinungen?
Keine zur Sache, aber eine zum Ort der Diskussion:

a) Falls es Probleme gibt, wäre es besser, es gäbe dazu einen separaten Thread (in Development?)
b) Falls jemand (ein Developer) im vorhinein Probleme erwartet, wäre es auch gut, wenigstens die Chance zu haben, eine Art Vorwarnung zu erhalten (da, wo man sie vermuten würde, nicht hier irgendwo versteckt in einem Mammutthread für was ganz anderes)... (Oder dann eben einen eindeutigen Ort zu haben, im Nachhinein unerwartete "Fernwirkungen" zu diskutieren).

Zitat von: Otto123 am 03 Juni 2021, 19:57:07
Ich weiß, in Jurassic Park hieß es: Die Natur findet einen Weg ... - Bei FHEM heißt es: der Anwender findet einen Weg ... (etwas so zu benutzen wie es nie vorgesehen war)
Wie wahr...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

TomLee

Wegen dem Thread und der Zeilen
{ AttrVal('DEVICE','IODev',InternalVal('DEVICE','IODev',undef)) }
in mqtt2.template .

Mir gibt aus der Kommandozeile ausgeführt:
{InternalVal('<Devicneame>','IODev',undef) }

HASH(0xXXXXXX) zurück, warum ist das so ?

Wenn ich auf LASTInputDev zugreife:
{InternalVal('MQTT2_DVES_561C8B','LASTInputDev',undef) }

wird der korrekte Name des IODev zurückgegeben.

Ergo, ersetze ich die Abfragen
InternalVal('DEVICE','IODev',undef)
in mqtt2.template durch eine LASTInputDev-Abfrage gibts auch keine Probleme beim anwenden der Tasmota-Templates.

rudolfkoenig

$hash->{IODev} enthaelt den "Zeiger", damit es schneller geht.
Versuchs mal mit { InternalVal('DEVICE', 'IODev', '')->{NAME} }

TomLee

#461
Eine Suche nach

{ AttrVal('DEVICE','IODev',InternalVal('DEVICE','IODev',undef)) }

ergibt 11 Treffer, die hab ich, zum Test und weil ich nicht weiß ob die Abfrage des Attributs noch benötigt (weil ich die Änderungen zu IODev nicht genau verfolgt habe) durch

{ InternalVal('DEVICE', 'IODev', '')->{NAME} }

ersetzt . Damit kann man die Templates wieder anwenden.

Es gibt noch weitere 11 Treffer die das Attribut abfragen und als Ersatz InternalVal nutzen ( u.a. die ignoreRegexp-Templates und weitere ?) damit hab ich mich nicht weiter beschäftigt.




Wenn ich einen Wert mit InternalVal abrufen möchte würd ich den Wert erwarten der auch drin steht und keinen Zeiger.

rudolfkoenig

ZitatWenn ich einen Wert mit InternalVal abrufen möchte würd ich den Wert erwarten der auch drin steht und keinen Zeiger.
Ich frag mich gerade, wozu man diesen Wert als Anwender ueberhaupt abrufen will.

TomLee

Hab das nur in Erinnerung dass das in dem fhem2mqttfhem-Faden (oder ähnlicher Name) mal der Fall war, also nicht als Anwender.

TomLee

Ich vermute jetzt schon das mir die Antwort zu weit, hoch ist, frag aber trotzdem, für mich und auch andere (zum Verständnis), warum steht dann in LASTInputDev kein Zeiger ?