GOVEE2MQTT - Client mit wechselnder ClientID verursacht Autocreate Kopfschmerz

Begonnen von Dek, 27 Januar 2025, 16:30:47

Vorheriges Thema - Nächstes Thema

Dek

Hallo zusammen,

ich habe erfolgreich die GOVEE2MQTT (https://github.com/wez/govee2mqtt) Integration in einem Docker-container ans laufen bekommen und sehe auch in der Konsole, wie er meine LEDs über das LAN-Control Interface erkennt.

Als MQTT Server habe ich meine fhem Instanz des MQTT2_FHEM_Server angegeben (incl. user/passwort). Diese Instanz nutze ich schon geraume Zeit erfolgreich für diverse Shelly Geräte.

Somit war ich auch nicht überrascht, als per autocreate ein neues MQTT2_DEVICE angelegt wurde. Verbindung funktioniert.

Da ich allerdings im Rahmen der Versuche den Docker-Container öfter neu gestartet habe, habe ich beobachtet, dass der Client govee2mqtt jedesmal ein neues autocreate triggert. Das ist auch nicht weiter verwunderlich, da er offenbar die client-ID jedesmal neu würfelt:
/// govee2mqtt source; geschreiben in RUST
    let client = Client::with_id(
        &format!("govee2mqtt/{}", uuid::Uuid::new_v4().simple()),
        true,
    )?;

Die Frage ist: wie gehe ich als best-practice in fhem damit um? Ich würde ungern das autocreate abschalten, gleichzeitig aber nicht bei jedem Docker-Neustart, oder Systemneustart erstmal die ids in fhem neu zu sortieren.


Gruß
Dek

TomLee

Zitat von: Dek am 27 Januar 2025, 16:30:47Die Frage ist: wie gehe ich als best-practice in fhem damit um?


Hallo,

die ClientId aus den ReadingList-Einträgen (den Teil vorne, mit dem Doppelpunkt) des bereits vorhandenen Device entfernen, ist eine.

Womit ich mich noch nie beschäftigt habe, eine feste in der MQTT2_SERVER-Definition fest anzugeben:


Zitat von: commandrefclientId <name>
set the MQTT clientId for all connections, for setups with clients creating a different MQTT-ID for each connection. The autocreate capabilities are greatly reduced in this case, and setting it requires to remove the clientId from all existing MQTT2_DEVICE readingList attributes.

Gruß Thomas

Dek

Zitat von: TomLee am 27 Januar 2025, 17:11:57die ClientId aus den ReadingList-Einträgen (den Teil vorne, mit dem Doppelpunkt) des bereits vorhandenen Device entfernen, ist eine.

Servus,

D.h. die existierende Definition funktioniert auch nach client Neustart mit neuer ID. Soweit so gut.
 
Es würde doch aber auch genauso wieder ein neues Device per autocreate angelegt werden, oder nicht? Kann man das autocreate per Regex auf die client ID ausschalten?


Dek

TomLee

ZitatEs würde doch aber auch genauso wieder ein neues Device per autocreate angelegt werden, oder nicht?

Das passiert eben nicht wenn Du "vorne" die ClientId entfernst, zumindest meine Erfahrung/Verständnis.
Was spricht denn gegen ausprobieren, indem Du den Docker-Container einfach mal neu startest?


Dek

Hallo Thomas,

Das ich das nicht direkt ausprobiert habe, lag an dem einfachen Grund, dass ich die Nachricht auf dem Sofa gelesen habe 8) .

Ich war dann aber tatsächlich neugierig, und habe
  • den docker Container gestoppt
  • alle govee2mqtt devices in fhem gelöscht
  • den docker Container gestartet
  • den docker Container gestoppt
  • den docker Container gestartet

Das hat wie erwartet 2 MQTT2_DEVICE angelegt.

Daraufhin habe ich
  • den docker Container gestoppt
  • eines der beiden govee2mqtt in fhem devices gelöscht
  • beim anderen aus der Readinglist nach Deinem Hinweis den ersten Teil mit ":" entfernt [A*]
  • den docker Container gestartet

Und es wurde kein neues Device angelegt: success.

dann wurde ich mutig und habe ein eigenes Device (ohne autocreate und ohne client id im define angelegt)
define  Govee2MQTT MQTT2_DEVICEDem habe ich dann die Readinglist aus [A*] gegeben und das alte autocreate Device gelöscht.

Nach einem restart des docker containers hat jetzt mein neues Device die Readings erhalten: BIG SUCCESS.

Damit ist meine Frage vollständig beantwortet, jetzt muss ich nur noch die LEDs über MQTT geschaltet bekommen, den Status sehe ich schon mal.

Großen Dank!
Dek

Beta-User

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

Dek

In der Tat, das will ich. Muss ich mich dann noch einlesen. Bislang war der Ansatz mit den Shelly über MQTT straight-forward. Das ist jetzt Level 2.  8)
Da ich fhem jetzt schon >10Jahre produktiv (incl. WAF*) einsetze, habe ich davor aber auch keine Angst.

Ich habe allerdings abends das Problem, dass die LED Panels bei meinem Sohn im Zimmer montiert sind, und ich nicht nach Belieben blinken lassen kann :). Muss also noch warten...


Dek


*)WAF