Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE

Begonnen von edy_80, 25 Oktober 2020, 19:06:36

Vorheriges Thema - Nächstes Thema

Beta-User

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-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

C0mmanda

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ß

Beta-User

Zitat von: C0mmanda am 29 November 2022, 23:36:10
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.

ZitatDie 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!).

ZitatDen 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...

ZitatMit 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-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

C0mmanda

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... :(

Beta-User

Das ist hier OT, aber mache mal ein update (es sollte was zu M2S und M2C geben, wenn du update check abfragst).
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


kmidt

#141
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

Beta-User

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-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

kmidt

Zitat von: Beta-User 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...?

- 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

Beta-User

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-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

kmidt

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.

Beta-User

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-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

Spartacus

Hallo zusammen,

auch ich spiele mit dem Gedanken aus HA meine fhem Devices zu steuern. Vor Allem wird die 1-wire und Enocean Integration in HA ziemlich schlecht unterstützt. Welche Erfahrungen gibt es mit der mqtt-Lösung. Funktioniert die Anbindung zuverlässig in beide Richtungen, d.h. meldet fhem den neuen Status des Devices auch korrekt an HA zurück?

Zigbee Devices werde ich alle nach HA schieben und fhem soll als 1-wire und Enocean GW dienen.

Wäre super, wenn Ihr Eure Erfahrungen mit dieser Lösung teilen könntet und was man an Aufwand rechnen muss, bei je 20 Sensoren und Aktoren (Hauptsächlich FTS14)

Danke Spartacus.
Fhem-System: 1 x raspberry PI Typ B, 1 x enOcean PI Typ B | Enocean: PTM210, FMS61NP, FAM14, 2 x FSR14-4x, FTS14-EM | LaCrosse: 2 x TX29D über Jeelink V3 | 1-Wire: 2 x DS18B20 über DS9490R

C0mmanda

Zitat von: Spartacus am 19 Januar 2023, 16:53:21
Hallo zusammen,

auch ich spiele mit dem Gedanken aus HA meine fhem Devices zu steuern. Vor Allem wird die 1-wire und Enocean Integration in HA ziemlich schlecht unterstützt. Welche Erfahrungen gibt es mit der mqtt-Lösung. Funktioniert die Anbindung zuverlässig in beide Richtungen, d.h. meldet fhem den neuen Status des Devices auch korrekt an HA zurück?

Zigbee Devices werde ich alle nach HA schieben und fhem soll als 1-wire und Enocean GW dienen.

Wäre super, wenn Ihr Eure Erfahrungen mit dieser Lösung teilen könntet und was man an Aufwand rechnen muss, bei je 20 Sensoren und Aktoren (Hauptsächlich FTS14)

Danke Spartacus.

Die Kommunikation und Rückmeldung HA<->FHEM klappt absolut problemlos wenn man es einmal korrekt eingestellt und verstanden hat.
Die 20 Sensoren/Aktoren sind dann vermutlich in 1 Stunde angelegt.

Der große Zeitaufwand bei mir war es MQTT soweit zu verstehen dass ich es korrekt einstellen kann ;) Denke das waren ein paar Stündchen.

Muss aber auch sagen: Ich habe keine Langzeiterfahrung. Ich habe Home Assistant bereits wieder aufgegeben. Ohne zu coden
geht da meiner Meinung nach nix und mir fehlt einfach die Zeit sich da komplett neu einzuarbeiten. Dachte ich kann alles über das UI machen.

Habe aktuell lediglich meinen iCloud.Account von HA in FHEM per MQTT eingebunden da FHEM dies nunmal nicht kann.
(zum tracken falls GeoFancy mal wieder klemmt)

Spartacus

Hallo C0mmanda,

vielen Dank für Dein Feedback. Ich werde mir das mal MQTT-Thema mal ansehen. Ich muss auch sagen, HA ist schon ganz nett, wenn man mal flux was zusammenschrauben will. Struktur ist allerdings schwierig und dann versagt auch der visuelle Editor. Das finde ich etwas schade! Es gibt allerdings viele Community addons und man findet fast alles, was man schon immer gerne in fhem gehabt hätte. (z.B. WE-Connect von VW war in 5min installiert und die Standheizung vom Golf 7 wird über den Viessmann Außenfühler angesteuert.)

Ich gucke mal, wie sich enocean, 1-wire und duofern per mqtt anbinden lassen. Das wird, wie gesagt, von HA nicht wirklich gut unterstützt.

Enocean plane ich sowieso über kurz oder lang rauszuschmeißen, da es funktechnisch einfach Mist ist und viel zu teuer. Mein Zigbee Netzwerk läuft jetzt seit 3 Jahren und das absolut störungsfrei. Meine 1-wire laufen aktuell parallel zu den aqara Multisensoren und liefern ziemlich genau die selben Werte, von daher ist das auch ersetzbar....nochmals Danke für Dein Feedback!

Spartacus
Fhem-System: 1 x raspberry PI Typ B, 1 x enOcean PI Typ B | Enocean: PTM210, FMS61NP, FAM14, 2 x FSR14-4x, FTS14-EM | LaCrosse: 2 x TX29D über Jeelink V3 | 1-Wire: 2 x DS18B20 über DS9490R