Autor Thema: Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE  (Gelesen 21946 mal)

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 19409
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #135 am: 29 November 2022, 19:17:00 »
Gerne und Danke für die Rückmeldung, dass es jetzt wohl deutlich vorangeht (und mein Geschreibsel anscheinend nicht völlig unleserlich ist).

Wir können gerne das Wiki verbessern und/oder auch neue/ergänzte attrTemplate (für die "Zieldevices") für alle bereitstellen. Ich hatte nur zwischenzeitlich etwas an Lust an dem Thema verloren, weil es anscheinend niemanden interessiert hatte bzw. auch niemand beitragen wollte...
Server: HP-T620@Debian 11, 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
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline C0mmanda

  • Sr. Member
  • ****
  • Beiträge: 550
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #136 am: 29 November 2022, 23:36:10 »
Das "Geschreibsel" ist verständlich, man muss sich nur drauf einlassen ;)

Was ich damit meine, grundsätzlich ist das Grundkonstrukt mit den topics erst einmal recht einfach zu begreifen, was es für mich schwer gemacht hat
ist die "Mechanik" die dahinter steckt und vor allem auch die verschiedenen FHEM-Devices die man dafür benötigt.

Wenn man dem Wiki (habe jetzt nur das zur Generic_Bridge gelesen) folgt und erstmal alles einfach macht was du schreibst wird es einem schon klarer.
Wichtig zum verstehen ist vor allem das machen und beobachten wie du ja mehrfach auch geschrieben hast.
Einfach mal 2 Terminalfenster aufmachen und den Traffic beobachten. Dann wird einem schon vieles klarer.

Ich hatte bis vor 2 Tagen absolut 0 Plan von MQTT und kratze nur an der Oberfläche.
Die nächsten Tage werde ich weiter testen und sollte mir was auffallen melde ich mich.

Die einzige Kleinigkeit die mir aufgefallen ist ist die InfoBox beim Thema "Geräte steuern"

Kommt als MQTT-Server MQTT2_SERVER zum Einsatz, ist zwingend eine ClientID mit anzugeben, andernfalls werden die so generierten Messages eventuell nicht ausgewertet!
Ich habe erst nicht wirklich kapiert wo ich diese ClientID setzen muss, denke aber die gehört ins IO-Device (MQTT2_CLIENT). Das IO-Dev wird aber "Ewigkeiten" früher behandelt.
Nur eine Kleinigkeit...

Den Fortgeschrittenen-Teil muss ich noch durchgehen, dazu kann ich noch nichts sagen ;)

Also long-story short: Wer dem Wiki genau folgt und sich Zeit nimmt der schafft es das MQTT erstmal lauffähig zu bekommen.

Mit neue/ergänzte attrTemplates für die Zieldevices meinst du für MQTT2_DEVICEs?


Was mich jetzt aber noch interessiert:

Ich habe für meine Ahoy-DTU vor einiger Zeit stumpf einen MQTT-Server erstellt (einfach nur "define MQTT2_SERVER 1883 global" und "attr autocreate no", sonst nichts) und für die Ahoy ein MQTT_DEVICE  erstellt. Da (d)ein AttrTemplate drüber gejagt und seitdem läuft es einfach.

Ist das i.O. so oder kann/sollte man das "eleganter" lösen wenn die MQTT-Zoo wächst?

Danke & Gruß

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 19409
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #137 am: 30 November 2022, 18:03:59 »
Das "Geschreibsel" ist verständlich, man muss sich nur drauf einlassen ;)
THX!

Das Zusammenspiel der verschiedenen Ebenen ist in der Tat nicht ganz einfach, daher der Versuch, das etwas zu standardisieren und "auf einen Rutsch" was funktionierendes "verteilen" zu können.

Zitat
Die einzige Kleinigkeit die mir aufgefallen ist ist die InfoBox beim Thema "Geräte steuern"

Kommt als MQTT-Server MQTT2_SERVER zum Einsatz, ist zwingend eine ClientID mit anzugeben, andernfalls werden die so generierten Messages eventuell nicht ausgewertet!
Danke für den Hinweis, das Problem bezieht sich auf "mosquitto_pub" - damit funktioniert autocreate nur, wenn man (auf der Kommandozeile) bei der Verwendung des Tools diese Angabe explizit macht (und was anderes nimmt, als das, was das Tool sonst automatisch generiert!).

Zitat
Den Fortgeschrittenen-Teil muss ich noch durchgehen, dazu kann ich noch nichts sagen ;)
Das ist der eigentliche "stub" und da findet sich auch nur zusammenkopiert, was Hexenmeister mal an Beispielen in seinem Thread zusammengeschrieben hat. Müßte mal formatiert und redigiert werden...

Zitat
Mit neue/ergänzte attrTemplates für die Zieldevices meinst du für MQTT2_DEVICEs?
Nope. attrTemplate funktioniert auch für MQTT_GENERIC_BRIDGE, und dort ist der Mechanismus so umgesetzt, dass man über den Umweg der MGB-Instanz auch beliebige andere Geräte "durchkonfigurieren" kann, so dass z.B. ein CUL_HM-Rollladen am Ende genauso gesteuert werden kann wie ein ZWave-Modell, also z.B. dann von HomeAssistant aus genau identisch aussieht!
Zitat
Was mich jetzt aber noch interessiert:

Ich habe für meine Ahoy-DTU vor einiger Zeit stumpf einen MQTT-Server erstellt (einfach nur "define MQTT2_SERVER 1883 global" und "attr autocreate no", sonst nichts) und für die Ahoy ein MQTT_DEVICE  erstellt. Da (d)ein AttrTemplate drüber gejagt und seitdem läuft es einfach.

Ist das i.O. so oder kann/sollte man das "eleganter" lösen wenn die MQTT-Zoo wächst?
So sollte es sein: attrTemplate drüberbügeln und freuen, dass die Dinge funktional sind und sich jemand Gedanken dazu gemacht hat, wie es sinnvoll sein könnte. Klappt leider nicht immer, und offenbar gehe ich gelegentlich auch dem einen oder anderen Nutzer etwas auf den Keks, wenn ich was noch nicht optimal finde und dann weiter nachbohre oder auf "gewisse Standards" poche. Meistens findet sich dann aber früher oder später jemand, der dann doch ein Einsehen hat...

Grade bei den früh entstandenen attrTemplate (für M2D) kann es aber schon sein, dass das heute etwas anders aussehen würde, also einfach mal kritisch beobachten, ob das alles "gut" ist, ist auf keinen Fall verboten ;) .
Server: HP-T620@Debian 11, 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

Offline C0mmanda

  • Sr. Member
  • ****
  • Beiträge: 550
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #138 am: 01 Dezember 2022, 20:26:51 »
Zitat
Was mich jetzt aber noch interessiert:

Ich habe für meine Ahoy-DTU vor einiger Zeit stumpf einen MQTT-Server erstellt (einfach nur "define MQTT2_SERVER 1883 global" und "attr autocreate no", sonst nichts) und für die Ahoy ein MQTT_DEVICE  erstellt. Da (d)ein AttrTemplate drüber gejagt und seitdem läuft es einfach.

Ist das i.O. so oder kann/sollte man das "eleganter" lösen wenn die MQTT-Zoo wächst?

Es ist zum Mäuse melken.
Jetzt war ich froh mit oben genannter Config gut zu fahren und das sie funktioniert (sogar Auto-Discovery bei HA hat mit der Ahoy-DTU funktioniert) und nun geht nix mehr nachdem ich
die Verbindung FHEM <-> HA "korrekt" am laufen habe...
Es wird von FHEM nichts mehr an HA weitergeleitet von der Ahoy, keine topics und dementsprechend geht auch kein Auto-Discover mehr.
Gibt es da eine Erklärung?  Wie kann ich FHEM beibringen alles von der Ahoy 1:1 an HA weiterzuleiten?
Finde seit gestern keine Lösung... :(

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 19409
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #139 am: 02 Dezember 2022, 07:51:52 »
Das ist hier OT, aber mache mal ein update (es sollte was zu M2S und M2C geben, wenn du update check abfragst).
Server: HP-T620@Debian 11, 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

Offline juergen012

  • Full Member
  • ***
  • Beiträge: 419
Fhem unter Proxmox

Offline kmidt

  • Jr. Member
  • **
  • Beiträge: 67
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #141 am: 02 Dezember 2022, 15:50:22 »
Hallo zusammen,

ich habe seit einem Jahr Erfogreich eine MQQT Verbindung zwischen FHEM und HASS so wie hier beschrieben laufen.
Ich kann auch alles sehen und Schalten. Aber Inzwischen mehr Errors als sonst was.

habe aber extrem viele :

022.12.02 15:48:40 1 : 192.168.178.151:1883 disconnected, waiting to reappear (mqtt)
2022.12.02 15:48:40 1 : 192.168.178.151:1883 reappeared (mqtt)
2022.12.02 15:48:40 1 : 192.168.178.151:1883 disconnected, waiting to reappear (mqtt)
2022.12.02 15:48:41 1 : 192.168.178.151:1883 reappeared (mqtt)
2022.12.02 15:48:41 1 : 192.168.178.151:1883 disconnected, waiting to reappear (mqtt)
2022.12.02 15:48:41 1 : 192.168.178.151:1883 reappeared (mqtt)
2022.12.02 15:48:41 1 : 192.168.178.151:1883 disconnected, waiting to reappear (mqtt)
2022.12.02 15:48:41 1 : 192.168.178.151:1883 reappeared (mqtt)
2022.12.02 15:48:41 1 : 192.168.178.151:1883 disconnected, waiting to reappear (mqtt)
2022.12.02 15:48:41 1 : 192.168.178.151:1883 reappeared (mqtt)
2022.12.02 15:48:41 1 : 192.168.178.151:1883 disconnected, waiting to reappear (mqtt)
2022.12.02 15:48:41 1 : 192.168.178.151:1883 reappeared (mqtt)
2022.12.02 15:48:41 1 : 192.168.178.151:1883 disconnected, waiting to reappear (mqtt)
2022.12.02 15:48:41 1 : 192.168.178.151:1883 reappeared (mqtt)
2022.12.02 15:48:41 1 : 192.168.178.151:1883 disconnected, waiting to reappear (mqtt)
2022.12.02 15:48:41 1 : 192.168.178.151:1883 reappeared (mqtt)
2022.12.02 15:48:41 1 : 192.168.178.151:1883 disconnected, waiting to reappear (mqtt)
2022.12.02 15:48:41 1 : 192.168.178.151:1883 reappeared (mqtt)
2022.12.02 15:48:41 1 : 192.168.178.151:1883 disconnected, waiting to reappear (mqtt)
2022.12.02 15:48:41 1 : 192.168.178.151:1883 reappeared (mqtt)
2022.12.02 15:48:41 1 : 192.168.178.151:1883 disconnected, waiting to reappear (mqtt)
2022.12.02 15:48:41 1 : 192.168.178.151:1883 reappeared (mqtt)
2022.12.02 15:48:41 1 : 192.168.178.151:1883 disconnected, waiting to reappear (mqtt)

Fehlermeldungen. So dass das inzwischen echt nicht mehr Rund läuft. die 151 ist der Broker von Hass.
Einer eien Idee was ich tun kann ?

Hier das Gegenlog von Hass :

error: received null username or password for unpwd check
2022-12-02 15:59:52: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:52: New connection from 192.168.178.118:45402 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:52: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:52: New connection from 192.168.178.118:45404 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:52: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:52: New connection from 192.168.178.118:45414 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:52: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:53: New connection from 192.168.178.118:45424 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:53: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:53: New connection from 192.168.178.118:45436 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:53: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:53: New connection from 192.168.178.118:45448 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:53: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:53: New connection from 192.168.178.118:45464 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:53: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:53: New connection from 192.168.178.118:45466 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:53: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:53: New connection from 192.168.178.118:45478 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:53: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:53: New connection from 192.168.178.118:45494 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:53: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:53: New connection from 192.168.178.118:45502 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:53: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:53: New connection from 192.168.178.118:45512 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:53: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:53: New connection from 192.168.178.118:45528 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:53: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:53: New connection from 192.168.178.118:45530 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:53: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:53: New connection from 192.168.178.118:45544 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:53: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:53: New connection from 192.168.178.118:45560 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:53: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:53: New connection from 192.168.178.118:45568 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:53: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:53: New connection from 192.168.178.118:45576 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:53: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:53: New connection from 192.168.178.118:45578 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:53: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:53: New connection from 192.168.178.118:45584 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:53: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:53: New connection from 192.168.178.118:45590 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:53: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:53: New connection from 192.168.178.118:45602 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:53: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:53: New connection from 192.168.178.118:45614 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:53: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:54: New connection from 192.168.178.118:45628 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:54: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:54: New connection from 192.168.178.118:45632 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:54: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:54: New connection from 192.168.178.118:45648 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:54: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:54: New connection from 192.168.178.118:45664 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:54: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:54: New connection from 192.168.178.118:45668 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:54: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:54: New connection from 192.168.178.118:45678 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:54: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:54: New connection from 192.168.178.118:45682 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:54: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:54: New connection from 192.168.178.118:45694 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:54: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:54: New connection from 192.168.178.118:45696 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:54: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:54: New connection from 192.168.178.118:45710 on port 1883.
error: received null username or password for unpwd check

Ich habe Benutzer und Passwort 100 mal gecheckt.



Danke und Gruß,
Andi
« Letzte Änderung: 02 Dezember 2022, 16:02:14 von kmidt »

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 19409
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #142 am: 02 Dezember 2022, 16:04:39 »
Vermutlich solltest du zu dem Thema einen gesonderten Thread aufmachen.

Allgemeine Hinweise und Anmerkungen:
- FHEM ist aktuell?
- Das scheint MQTT2_CLIENT zu sein? Mit welcher Art Gegenstelle (mosquitto? welche Version?)? (Evtl. braucht man nach einem update credentials?)
- Wie ist die ClientID gesetzt von der MQTT2_CLIENT-Instanz?
- Gibt es weitere Clients, die ggf. dieselbe ClientId nutzen?
- Verbindung? WLAN, LAN, PowerLAN...?
Server: HP-T620@Debian 11, 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

Offline kmidt

  • Jr. Member
  • **
  • Beiträge: 67
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #143 am: 02 Dezember 2022, 17:01:28 »
Vermutlich solltest du zu dem Thema einen gesonderten Thread aufmachen.

Allgemeine Hinweise und Anmerkungen:
- FHEM ist aktuell?
- Das scheint MQTT2_CLIENT zu sein? Mit welcher Art Gegenstelle (mosquitto? welche Version?)? (Evtl. braucht man nach einem update credentials?)
- Wie ist die ClientID gesetzt von der MQTT2_CLIENT-Instanz?
- Gibt es weitere Clients, die ggf. dieselbe ClientId nutzen?
- Verbindung? WLAN, LAN, PowerLAN...?

- Fhem ist aktuell
- Das ist ein MQTT2 Client, ja
- Gegenstelle ist mosquitto in Homeassistant, neuste Version
- Verbindung ist LAN Gbit auf beiden Seiten
- Client ID : fhem   Ich habe nur FHem als Sender und Homeassistantals Empfänger. Ich kenne mich mit der Funktion der Client ID aber auch nicht wirklich aus

AUf jeden Fall schon einmal Danke für Deine ANtwort

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 19409
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #144 am: 02 Dezember 2022, 17:08:43 »
mosquitto will (per default) in/ab V. 2.0, dass man sich mit Usernamen und Passwort anmeldet. Kann sein, dass das der Fehler ist (keine Ahnung, was dazu wann wie im Log zu finden ist).

Wenn es wirklich nur zwei Clients sind, darf halt deren ClientId nicht identisch sein, sonst wird die Verbindung typischerweise immer abgewiesen bzw. geschlossen. Ob das der Fall ist, kannst nur du sagen, im Zweifel würde ich in der Konstellation halt mal die ClientID am M2C einfach "anders" setzen als bisher. Wenn nur MGB was mit den Daten anfängt, sollte das komplett unkritisch sein; wenn MQTT2_DEVICE-Instanzen da sind, die die ClientID in die readingList übernommen haben, werden die halt nicht mehr beliefert (was einer der Gründe ist, warum ich immer empfehle, diese Angabe aus der readingList zu entfernen).
Server: HP-T620@Debian 11, 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

Offline kmidt

  • Jr. Member
  • **
  • Beiträge: 67
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #145 am: 02 Dezember 2022, 17:23:47 »
CLient ID´s sind Unterschiedlich.

Ich kann ja auch alle Topics Empfangen und senden. Halt nur diese Sekündlichen Fehlermeldungen spamen das Log zu und
dann irgendwann geht mal ein Topic durch, weil zu viele Fehlermeldungen.

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 19409
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #146 am: 02 Dezember 2022, 17:33:56 »
OK, dann mach bitte einen neuen Thread dazu auf, damit Rudi das ggf. gesondert mal ansieht. Bitte dazu die notwendigen Infos sauber zusammenfassen (udn vielleicht verbose am MQTT2_CLEINT mal hochsetzen, damit vielleicht mehr zu sehen ist).
Server: HP-T620@Debian 11, 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

 

decade-submarginal