Devicename ohne MQTT2_...

Begonnen von Pauline, 29 November 2024, 10:24:29

Vorheriges Thema - Nächstes Thema

Pauline

Hi all,

Wenn MQTT2_Device ein neues Device erstellt, beginnt der neue Device-Name immer mit "MQTT2_xxxxxxx". Kann das irgendwie unterdrückt werden? Bei den Attributen kann ich nichts finden, und auch sonst nichts.
Es soll genau der Device-Name, den ich in der bridgeRegexp am Ende (in Anführungszeichen) angebe, also z,B. "My_ESP8_OG" und eben nicht "MQTT2_My_ESP8_OG"
Oder wo könnte ich es (notfalls) im Modul ändern?

Mit Alias oder Umbenennen ist mir nicht geholfen, da ich eine Menge Quellcode an vielen Stellen aus einer anderen FHEM Instanz übernommen habe und diesen Code möglichst nicht ändern möchte.
Zur Info: Ist ein Umzug von MQTT_Device zu MQTT2_Device. Die Forenbeiträte dazu habe ich weitgehend gelesen.

marvin78

Du kannst doch einfach das Device umbenennen (rename).

Pauline

Bin mir nicht sicher, ob durch (einfaches) Umbenennen mit rename der neue Name konsequent an allen Stellen in FHEM erfolgt.
Was ich z.B. direkt sehe ist, dass das automatisch mit angelegte "FileLog_MQTT_2_My_ESP8_OK" eben NICHT mit umbenannt wird!
Und wass passiert, wenn ich neue Sensoren im ESP einbinde. (Das werde ich am WE testen.)

Schöner und sauberer wäre, wenn es gleich mit dem gewünschten Device-Namen angelegt würde.
Da ich inzwischen doch so einige Geräte und Sensoren eingebunden habe (hatte), wäre autocreate für mich schon sehr wünschenswert. 

Beta-User

#3
Zitat von: Pauline am 29 November 2024, 10:42:17Bin mir nicht sicher, ob durch (einfaches) Umbenennen mit rename der neue Name konsequent an allen Stellen in FHEM erfolgt.
Dass andere Module ein rename (oder delete etc.) nachverfolgen, ist eher die (m.E. ehrenwerte, aber unangenehme!) Ausnahme, weil das den "einfachen Tausch" von Geräten eher erschwert...

Ich würde das Anlegen des FileLog bei autocreate abschalten, in dem Zug überlegen, ob nicht ein Wechsel auf DbLog angesagt ist. Ansonsten halt manuell anlegen (und ggf. überlegen, was man zusammenfassen könnte)...

Wenn das rename direkt nach dem Anlegen erfolgen soll, könnte eventuell "archetype" helfen.

Nachtrag noch: Bis zu einem gewissen Grad sieht man unten auf der Detailseite der Geräte, was ggf. "probably associated with" ist, und es gibt mit "weblink" (Type associatedWith) auch ein Tool, um das grafisch und mit mehr Tiefe anzuzeigen.
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

rudolfkoenig

ZitatEs soll genau der Device-Name, den ich in der bridgeRegexp am Ende (in Anführungszeichen) angebe, also z,B. "My_ESP8_OG" und eben nicht "MQTT2_My_ESP8_OG"
Wenn das mehrfach gewuenscht wird, kann ich dafuer ein Attribut einbauen.


Das Attribut koennte auch in Autocreate eingebaut werden, damit waere es generischer.

Beta-User

Zitat von: rudolfkoenig am 29 November 2024, 12:31:14Wenn das mehrfach gewuenscht wird, kann ich dafuer ein Attribut einbauen.
...wenn schon, denn schon...

Meint: "Eigentlich" braucht kein Mensch diesen "MQTT2_"-Prefix am Device-Namen, und man könnte es genauso gut so gestalten, dass den der bekommen kann, der das unbedingt will ;) . "Wo" die Devices herkommen, sieht man ja am TYPE und (default) auch am room, in den die sortiert werden.
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

betateilchen

Ich hasse das autocreate in den allermeisten Fällen.

Mit "selbst anlegen" bin ich in der Regel bei MQTT2 schneller fertig.
Dann passen auch der Name und andere Attribute.

Der einzige Fall, in dem ich in meinem FHEM wirklich ein autocreate device anlege, ist beim Anlernen von klassischen Homematic Komponenten.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

frober

Ich schließe mich Beta-User an.
Per Default ohne Präfix und wer möchte kann es "einschalten".
Raspi 3b mit Raspbian Bullseye und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

Pauline

Rudi, das finde ich ein tolles Angebot. Wenn es wählbar ist, dann sind doch alle zufrieden, auch die, die es weiterin manuell bevorzugen.

(btw: Hat mich bei ESPEasy_... auch schon immer maßlos genervt.)

rudolfkoenig

Ich habe keine elegante Loesung fuer ein autocreate Attribut gefunden => Aenderung nur in MQTT2_DEVICE

Das Praefix erst nach Setzen eines Attributes hinzuzufuegen finde ich albern, deswegen habe ich "MQTT2_" im Namen beim autocreate jetzt einfach entfernt.

Pauline

Hallo Rudi, super, bezaubernd!
Erstellung der Devices funktiniert problemlos ohne "MQTT2_......" im Namen.
Habe eine schöne neue Liste aller MQTT-Devices, und die gefällt mir richtig gut. Und der bestehende Quellcode funktioniert auch.
Vielen Dank für Deine super schnelle Hilfe!

Werde noch1-2 Tage warten und dann als gelöst schließen.

VG, Pauline

cryptik

#11
Hallo zusammen,

ich habe heute ein FHEM Update (update all) durchgeführt.
Anschließend funktioniert eins meiner MQTT Devices nicht korrekt. Die readings, welche über die readinglist definiert werden, erhalten keine Aktualisierung.
Da die hier beschriebene Änderung am MQTT2 Device die letzte seit Anfang November ist (mein letztes FHEM Update), vermute ich einen Zusammenhang.

Vor dem Update ist mein Device wie folgt definiert:

defmod MQTT2_FLU_BLE MQTT2_DEVICE FLU_BLE
attr MQTT2_FLU_BLE autocreate 0
attr MQTT2_FLU_BLE event-on-change-reading .*
attr MQTT2_FLU_BLE readingList FLU_BLE:hallo:.* hallo\
FLU_BLE:FLU_BLE:.* { json2nameValue($EVENT,'',$JSONMAP,'ee_ee_ee_ee_ee_e0|ee_ee_ee_ee_ee_e1') }
attr MQTT2_FLU_BLE room MQTT
attr MQTT2_FLU_BLE stateFormat {\
        "Online seit: ".(ReadingsTimestamp('MQTT2_FLU_BLE','hallo',''))\
}

setstate MQTT2_FLU_BLE Online seit: 2024-09-09 19:39:50
setstate MQTT2_FLU_BLE 2024-12-04 05:31:44 IODev m2server
setstate MQTT2_FLU_BLE 2024-12-04 05:40:45 ee_ee_ee_ee_ee_e0 -47
setstate MQTT2_FLU_BLE 2024-12-04 05:40:45 ee_ee_ee_ee_ee_e1 -63
setstate MQTT2_FLU_BLE 2024-09-09 19:39:50 hallo FLU_BLE

Vor dem Update sehen Events genau so aus, wie nach dem Update:
Vorher:
2024-12-04 05:36:52 MQTT2_DEVICE MQTT2_FLU_BLE ee_ee_ee_ee_ee_e1: -59Nachher:
2024-12-04 05:51:11 MQTT2_DEVICE MQTT2_FLU_BLE ee_ee_ee_ee_ee_e1: -85
Nach dem Update muss ich die readingList löschen und autocreate wieder auf 1 stellen, damit readings und events erzeugt werden.

Die readinglist wird dann automatisch wie folgt gesetzt
FLU_BLE:FLU_BLE:.* { json2nameValue($EVENT) }Die readings sind anschließend wie gewohnt vorhanden, nur ohne den Filter wird die Liste natürlich unendlich lang.

Seht ihr hier einen kausalen Zusammenhang und evtl. auch eine Lösung?

(Hardware-ID's habe ich bewusst geändert.)

rudolfkoenig

Das Entfernen der MQTT2_ Praefixes sollte nur neu angelegte MQTT2_DEVICE Instanzen betreffen.

Ich tippe auf die Unicode String-Dekodierng fuer Schluessel: https://forum.fhem.de/index.php?topic=139807.msg1326592#msg1326592

Kannst Du mir eine MQTT-Nachricht zeigen?
Entweder hier angehaengt, oder per EMail, siehe Impressum.

juergen012

Hallo,
ich finde die Änderung auf Wunsch einer Person schon für bedenklich. Falls fhem neu angelegt wird und die Konfiguration übernommen wird, stimmt hinterher nichts mehr, da die Devices jetzt mit neuem Namen angelegt werden. Somit ist ein händisches ändern erforderlich. Nicht schön.

Gruß
Jürgen K.
Fhem unter Proxmox

marvin78

@juergen012: Wenn du die Konfiguration übernimmst, übernimmst du auch die "alten" Namen. Das Problem existiert also, aus meiner Sicht, nicht.