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

Offline edy_80

  • New Member
  • *
  • Beiträge: 4
Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« am: 25 Oktober 2020, 19:06:36 »
Hallo,

Ich stehe vor Folgendem Problem und zwar möchte ich meine FHEM als Zentrale Steuerung weiterhin behalten und HomeAssistant als Frontend nutzen. Ich habe beim durchforsten ein paar Anleitungen gefunden wie Ich es in etwa machen soll aber bis jetzt habe ich es nicht geschafft eine Verbindung in beide Richtungen Herzustellen. Es ist ja mit MQTT_GENERIC_BRIDGE möglich nur klappt bei mir momentan nichts.

Ich Verwende schon den MQTT2_SERVER für die Anbindung meiner Tasmota Devices aber bekomme keine Verbindung zu dem Server mit HomeAssistant zustande.

Vielen Dank schonmal für eure Hilfe

Offline gadget

  • Full Member
  • ***
  • Beiträge: 275
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #1 am: 26 Oktober 2020, 10:41:19 »
Hallo,

bei mir schaut das so aus:

Ich habe bei hassio den MQTT-Server über Supervisor->Add-ONs installiert (Mosquitto broker). Zuvor unter Einstellungen->Benutzer einen User hamqtt angelegt (ohne Admin-Rechte). Details siehe https://github.com/home-assistant/hassio-addons/blob/master/mosquitto/DOCS.md

Bei HA muss man sich dann überlegen, welche Art von MQTT Device am besten zu dem fhem-Device passt, das man in HA sichtbar machen will.
Ich habe im Einsatz:


  • binary_sensor für Wasser- und Rauchmelder, Fensterkontakte (unidirektional, also von HA aus nicht veränderbar)
  • sensor für Temperatur, Luftdruck, Stromverbrauch, Betriebsdauer usw. (ebenfalls unidirektional), aber numerisch mit Einheit
  • device_tracker (für fhem PRESENCE, ebenfalls unidirektional)
  • switch für einfache Lichtschalter (ohne Dimmer) und fhem-Dummys die nur on/off brauchen, Schaltbar von HA
  • light für dimmbare Beleuchtung (HUEBridge ist allerdings sowohl an fhem als auch an HA direkt angebunden)
  • cover für Rollos und Markisen
  • climate für Klimageräte (Daikin), Heizkörperventile (MAX), Fussbodenheizung (fhem PWM-Modul)
Ich beschreibe hier mal die Vorgehensweise für einen switch, auf fhem-Seite als dummy realisiert.

in der configuration.yaml:

switch:
  - platform: mqtt
    name: demoswitch
    command_topic: "fhem/demoswitch/set"
    state_topic: "fhem/demoswitch/state"
    payload_on: "on"
    payload_off: "off"
    state_on: "on"
    state_off: "off"
    #availability_topic: "fhem/connection/status"
    #payload_available: "connected"
    #payload_not_available: "disconnected"

Ich habe in HA den Samba-Share installiert und editiere die config mit Visual Studio Code. Damit erkennt man Einrückungsfehler in yaml -Files recht schnell.

Dann Einstellungen -> Serversteuerung -> Config prüfen und Einstellungen -> Serversteuerung -> Server neu starten.

(Man kann in der aktuellen Version auch nur die MQTT Devices neu laden, bei mir fliegen dann aber immer die Autodiscovery-Devices raus)

Unter Entwicklerwerkzeuge -> Zustände sollte sich nun bei den Entitäten ein switch.demoswitch befinden.

Den kann man jetzt mit ein paar Mausklicks in einem Lovelace Dashboard hinzufügen.

Als nächstes folgt ein Test vom fhem Sever aus, noch unabhängig von fhem. Bei mir ist das ein Raspi. Ich habe mir dazu das Paket mosquitto-clients installiert mit
sudo apt-get install mosquitto-clients
Danach sollte es möglich sein, mit

mosquitto_pub -h <ip-adresse des HA Servers> -u hamqtt -P <Passwort des Users hamqtt> -t 'fhem/demoswitch/state' -m on
mosquitto_pub -h <ip-adresse des HA Servers> -u hamqtt -P <Passwort des Users hamqtt> -t 'fhem/demoswitch/state' -m off

den switch in HA ein- und auszuschalten.

Mit

mosquitto_sub -h <ip-adresse des HA Servers> -u hamqtt -P <Passwort des Users hamqtt> -t 'fhem/demoswitch/set'

kann man dann noch prüfen, ob das Umschalten des Switch in HA an den MQTT Broker übertragen wird. Da sollte dann ein "on" bzw. "off" erscheinen. Der Switch springt dann wieder zurück, das ist aber normal (weil der Switch nicht im optimistic mode arbeitet und noch keine Rückmeldung erhält). Das mosquitto_sub dann mit ctrl-C abbrechen.

Als grafische Alternative zu mosquitto_sub kann ich https://mqtt-explorer.com/ empfehlen, den kann man natürlich auch auf seinem "Arbeitsrechner" installieren und damit dann remote auf den MQTT Broker zugreifen.

Wenn das soweit geklappt hat, geht es in fhem weiter. Zunächst eine Verbindung zum MQTT Broker von HomeAssistant aufbauen, dazu ein MQTT2_CLIENT Device anlegen

defmod ha_MQTT2 MQTT2_CLIENT 192.168.1.2:1883
attr ha_MQTT2 clientId fhem
attr ha_MQTT2 keepaliveTimeout 60
attr ha_MQTT2 msgAfterConnect -r fhem/connection/status connected
attr ha_MQTT2 msgBeforeDisconnect -r fhem/connection/status disconnected
attr ha_MQTT2 qosMaxQueueLength 100
attr ha_MQTT2 room MQTT
attr ha_MQTT2 username hamqtt

Die IP-Adresse in der Definition  ist natürlich die IP-Adresse des HA-Servers, auf dem der MQTT Broker läuft.

Mit set ha_MQTT2 passwort <Passwort> das Passwort des Users hamqtt hinterlegen. Status sollte nun "opened" sein.

Auf der Kommandozeile oder per mqtt-explorer prüfen, was im Topic fhem/connection/status steht:

mosquitto_sub -h <ip-adresse des HA Servers> -u hamqtt -P <Passwort des Users hamqtt> -t 'fhem/connection/status'

-> Hier sollte nun "connected" stehen.

Die Definition des Switch in HA kann man passend ergänzen und die Kommentare vor availability_topic, payload_available, payload_not_available entfernen. HA Server Config-Check + Restart nicht vergessen.

Jetzt kommt die MQTT_GENERIC_BRIDGE zum Einsatz. Bei mir ist die so definiert:

defmod mqttGeneric MQTT_GENERIC_BRIDGE mqtt room=HASS
attr mqttGeneric IODev ha_MQTT2
attr mqttGeneric globalDefaults sub:qos=2 pub:qos=0 retain=1 base={"fhem/$device"}
attr mqttGeneric globalPublish *:topic={"fhem/$device/$reading"}
attr mqttGeneric icon mqtt_bridge_2
attr mqttGeneric room MQTT
attr mqttGeneric stateFormat in: incoming-count out: outgoing-count devices: device-count
attr mqttGeneric verbose 0

Mit dieser Definition sendet die Bridge alle Readings von allen fhem-Devices zum MQTT-Broker, die im fhem-Raum "HASS" sind. Bestehende fhem-Devices, die ich dann in HA sehen will, muss ich dann nur zusätzlich in diesen Raum packen.

Exemplarisch jetzt mal für einen fhem-dummy, der das Äquivalent zu dem HA-Switch werden soll:

defmod demoswitch dummy
attr demoswitch room HASS,Test
attr demoswitch webCmd on:off

Jetzt zur MQTT_GENERIC_BRIDGE gehen und ein get ... refreshUserAttr machen. Dann wieder zurück zum demoswitch dummy.
Dieser hat jetzt automagisch userattr verbraten bekommen und schaut jetzt so aus:

defmod demoswitch dummy
attr demoswitch userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
attr demoswitch room HASS,Test
attr demoswitch webCmd on:off

Als Besonderheit für dummy-Devices muss man nun noch das Attribut mqttForward setzten und zwar auf true.
Warum das so ist kann man in der CommandRef zur MQTT_GENERIC_BRIDGE (kurz: MGB) nachlesen.

attr demoswitch mqttForward all


Der fhem-Device-Name des dummy ("demoswitch") taucht nun genau so im MQTT-Topic ( fhem/demoswitch/... ) auf.

Mit

mosquitto_sub -h <ip-adresse des HA Servers> -u hamqtt -P <Passwort des Users hamqtt> -t 'fhem/demoswitch/state'

kann man prüfen, ob fhem jetzt den Schaltzustand (= Reading "state") an den MQTT-Server von HA sendet, wenn man den Dummy in fhem schaltet.

Sobald auf dem Topic 'fhem/demoswitch/state' die on/off ankommen, sollte auch der Schalter in HA den entsprechenden Zustand annehmen. Wenn das soweit klappt, ist die Kommunikation fhem -> HA soweit fertig. Bei einem sensor oder binary_sensor war das dann alles.
Beim Switch fehlt jetzt noch der Weg HA -> fhem. Dazu muss das fhem Device eine Subscription zum passenden Topic fhem/demoswitch/set bekommen:

attr demoswitch mqttSubscribe state:stopic={"$base/set"}


Jetzt sollte es auch möglich sein, den dummy von HA aus zu schalten.

Bei komplizierteren Devices (cover, climate,light), die nicht nur ein on/off kennen, muss man sich in der HA Dokumentation erst mal anschauen, welche attribute erwartet werden. Man kann dann auf HA Seite mit templates arbeiten. Ich mache das lieber auf fhem-Seite mit userReadings.

Wenn man in fhem bereits den eingebauten MQTT2_SERVER verwendet und da drüber MQTT_Devices angebunden hat (z.B. Tasmota), habe ich noch keine Möglichkeit gefunden, dass man die via MQTT_GENERIC_BRIDGE an den HA-Server weiterreichen kann. Ich habe nur eine handvoll solcher Devices und behelfe mir mit fhem-   
readingsProxy.
(Edit: Geht inzwischen). Man könnte die MQTT-Devices natürlich auch direkt an den HA-Server hängen, aber das will ich bei meiner Installation nicht machen, da  HA nur zur Visualisierung dient und auf einem nicht weiter abgesichterten Server läuft, während der fhem-Raspberry z.B. eine USV hat und täglich gesichert wird und ein Ersatz-Raspberry bereit liegt, den ich bei Ausfall innerhalb von 10 Minuten mit identischer Konfig in Betrieb nehmen kann. 

Grüße, gadget
« Letzte Änderung: 23 Februar 2021, 02:50:14 von gadget »
Gefällt mir Gefällt mir x 3 Informativ Informativ x 1 Liste anzeigen

Offline Jens_B

  • Full Member
  • ***
  • Beiträge: 399
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #2 am: 14 Dezember 2020, 12:50:04 »
Hallo gadget,
danke für diese Anleitung. Ich habe das mit einem Demoswitch genauso auch bei mir umsetzen können (zum testen). Allerdings springt im homeassistant der Schalter nach dem schalten immer auf off.
Da ich ausserdem eine Menge an devices habe ist das Ganze natürlich letztlich ein ziemlicher Aufwand, puh... Jedes Device quasi in homeassistant noch mal anzulegen... (in der Config)

Aber einige Sachen sind in fhem einfach bei mir schon so gestrickt, das man die Homematic devices oder auch meine Z-Wave (Z Wave USB ist per remote/ip an fhem angebunden, ebenso Homematic)  nicht einfach in homeassistant direkt einbinden kann. Die Remotanbindung der einzelnen Gateways ist bei homeassistant nicht so einfach (Ich habe hier auch einen jeelink für die Temperatursensoren per IP angebunden).

Ich überlege ob ich den Aufwand letzendlich betreiben nur für die schönere Oberfläche...


RaspberryPi 3 (Raspian Buster)FHEM+Homebridge
HMLAN für Homematic
Z-Wave USB Stick
Pilight
Fritz!Box 7590

Offline gadget

  • Full Member
  • ***
  • Beiträge: 275
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #3 am: 14 Dezember 2020, 15:42:01 »
Allerdings springt im homeassistant der Schalter nach dem schalten immer auf off.

Dann stimmt was auf dem Weg fhem -> HA noch nicht. Kommt der richtige Zustand in HA an, wenn Du in fhem schaltest ?

Da ich ausserdem eine Menge an devices habe ist das Ganze natürlich letztlich ein ziemlicher Aufwand, puh... Jedes Device quasi in homeassistant noch mal anzulegen... (in der Config)

Wenn Du viele gleichartige Devices hast, ist der Aufwand nach dem Anbinden des ersten Devices dann nur noch Cut&paste. Wenn Du natürlich einen gewaltigen Zoo hast schaut das anders aus.
Ich hab auch nicht 1:1 alle fhem Devices nach HA gebracht. Da ist viel dabei was ich nur für die Automatisierung brauche und gar nicht im GUI sehen will, beispielsweise die ganzen Stellaktoren bei der Fussbodenheizung.

Sehr schick ist natürlich auch die IOS und Android-App.

Ich überlege ob ich den Aufwand letzendlich betreiben nur für die schönere Oberfläche...

Ich war auch erst skeptisch, aber bin inzwischen überzeugt. Etwas vergleichbares gibt es in fhem einfach nicht. Aber das ist ja das schöne an offenen Systemen, dass man sich die jeweiligen Rosinen raus picken kann ohne alles von Null auf neu aufbauen zu müssen.

Offline hckoe

  • Full Member
  • ***
  • Beiträge: 124
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #4 am: 13 Januar 2021, 16:05:01 »
Hallo gadget,

auch ich habe das gemäss Deiner Anleitung gestestet und habe das gleiche Problem wie Jens_B.
Wenn ich den demoswitch von FHEM aus umschalte, ändert sich immer der Status in HA korrekt.
Wenn ich den demoswitch aus HA umschalte, ändert sich auch der Status in FHEM korrekt, danach springt der Schalter in HA aber wieder auf den jeweils vorigen Zustand zurück.

Irgendeine Idee, warum das passiert?

Viele Grüße
Helmut
# CT mit Debian Buster / FHEM aktuell / EnOcean TCM310 / Eltako FSA12, FUD12NPN, FSB12, FRW, FSRP-230V
# Permundo PCS234, Nodon NO-SIN-2-2-00, GTAGS

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15768
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #5 am: 13 Januar 2021, 17:43:20 »
Irgendeine Idee, warum das passiert?
Schau mal in die cref zu "
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline hckoe

  • Full Member
  • ***
  • Beiträge: 124
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #6 am: 13 Januar 2021, 18:11:43 »
Hallo Beta-User,

Der Post war irgendwie noch nicht ganz vollständig?

cref zu MQTT_GENERIC_BRIDGE, MQTT2_CLIENT?


Gruß Helmut
# CT mit Debian Buster / FHEM aktuell / EnOcean TCM310 / Eltako FSA12, FUD12NPN, FSB12, FRW, FSRP-230V
# Permundo PCS234, Nodon NO-SIN-2-2-00, GTAGS

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15768
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #7 am: 13 Januar 2021, 18:29:04 »
Mist, da hat die forensoftware was verschluckt...

MQTT_GENERIC_BRIDGE, dort mqttForward.
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline hckoe

  • Full Member
  • ***
  • Beiträge: 124
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #8 am: 13 Januar 2021, 21:17:45 »
Hallo Beta-User,

mit "attr mttqForward all" funktioniert es beim Dummy-Device. Jetzt werden die Stati auf beiden Seiten immer richtig aktualisiert.

Danke und Gruß
Helmut
# CT mit Debian Buster / FHEM aktuell / EnOcean TCM310 / Eltako FSA12, FUD12NPN, FSB12, FRW, FSRP-230V
# Permundo PCS234, Nodon NO-SIN-2-2-00, GTAGS

Offline OppiM

  • Jr. Member
  • **
  • Beiträge: 67
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #9 am: 19 Januar 2021, 11:49:12 »
Hi,

ich hab die Verbindung bei mir mal nachgebaut, klappt (mit dem Dummy) ganz gut.

Allerdings werden bei jedem Schaltvorgang (egal, ob in FHEM oder HA ausgelöst), jede Menge Warnungen ins Log geschrieben. FHEM ist der aktuelle Stand.

Geschaltet in HA:
2021.01.19 11:27:09.915 1: PERL WARNING: Use of uninitialized value in substitution iterator at fhem.pl line 4710.
2021.01.19 11:27:09.917 1: stacktrace:
2021.01.19 11:27:09.917 1:     main::__ANON__                      called by fhem.pl (4710)
2021.01.19 11:27:09.917 1:     main::evalStateFormat               called by fhem.pl (4802)
2021.01.19 11:27:09.918 1:     main::readingsEndUpdate             called by fhem.pl (4993)
2021.01.19 11:27:09.918 1:     main::readingsSingleUpdate          called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2821)
2021.01.19 11:27:09.918 1:     MQTT::GENERIC_BRIDGE::onmessage     called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2802)
2021.01.19 11:27:09.919 1:     MQTT::GENERIC_BRIDGE::Parse         called by fhem.pl (4014)
2021.01.19 11:27:09.919 1:     main::Dispatch                      called by ./FHEM/00_MQTT2_CLIENT.pm (499)
2021.01.19 11:27:09.919 1:     main::MQTT2_CLIENT_Read             called by fhem.pl (3818)
2021.01.19 11:27:09.919 1:     main::CallFn                        called by fhem.pl (759)
2021.01.19 11:27:09.920 1: PERL WARNING: Use of uninitialized value in substitution iterator at fhem.pl line 4710.
2021.01.19 11:27:09.921 1: stacktrace:
2021.01.19 11:27:09.921 1:     main::__ANON__                      called by fhem.pl (4710)
2021.01.19 11:27:09.921 1:     main::evalStateFormat               called by fhem.pl (4802)
2021.01.19 11:27:09.921 1:     main::readingsEndUpdate             called by fhem.pl (4993)
2021.01.19 11:27:09.922 1:     main::readingsSingleUpdate          called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2737)
2021.01.19 11:27:09.922 1:     MQTT::GENERIC_BRIDGE::doSetUpdate   called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2886)
2021.01.19 11:27:09.922 1:     MQTT::GENERIC_BRIDGE::onmessage     called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2802)
2021.01.19 11:27:09.923 1:     MQTT::GENERIC_BRIDGE::Parse         called by fhem.pl (4014)
2021.01.19 11:27:09.923 1:     main::Dispatch                      called by ./FHEM/00_MQTT2_CLIENT.pm (499)
2021.01.19 11:27:09.923 1:     main::MQTT2_CLIENT_Read             called by fhem.pl (3818)
2021.01.19 11:27:09.923 1:     main::CallFn                        called by fhem.pl (759)
2021.01.19 11:27:09.930 1: PERL WARNING: Use of uninitialized value $function in hash element at fhem.pl line 4960.
2021.01.19 11:27:09.931 1: stacktrace:
2021.01.19 11:27:09.931 1:     main::__ANON__                      called by fhem.pl (4960)
2021.01.19 11:27:09.931 1:     main::readingsBulkUpdate            called by fhem.pl (4992)
2021.01.19 11:27:09.932 1:     main::readingsSingleUpdate          called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2428)
2021.01.19 11:27:09.932 1:     MQTT::GENERIC_BRIDGE::doPublish     called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2560)
2021.01.19 11:27:09.932 1:     MQTT::GENERIC_BRIDGE::publishDeviceUpdate called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2180)
2021.01.19 11:27:09.932 1:     MQTT::GENERIC_BRIDGE::checkPublishDeviceReadingsUpdates called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2103)
2021.01.19 11:27:09.933 1:     MQTT::GENERIC_BRIDGE::Notify        called by fhem.pl (3818)
2021.01.19 11:27:09.933 1:     main::CallFn                        called by fhem.pl (3735)
2021.01.19 11:27:09.933 1:     main::DoTrigger                     called by fhem.pl (4105)
2021.01.19 11:27:09.933 1:     main::Dispatch                      called by ./FHEM/00_MQTT2_CLIENT.pm (499)
2021.01.19 11:27:09.934 1:     main::MQTT2_CLIENT_Read             called by fhem.pl (3818)
2021.01.19 11:27:09.934 1:     main::CallFn                        called by fhem.pl (759)
2021.01.19 11:27:09.934 1: PERL WARNING: Argument "outgoing publish sent" isn't numeric in division (/) at FHEM/TimeSeries.pm line 367.
2021.01.19 11:27:09.935 1: stacktrace:
2021.01.19 11:27:09.935 1:     main::__ANON__                      called by FHEM/TimeSeries.pm (367)
2021.01.19 11:27:09.935 1:     TimeSeries::add                     called by fhem.pl (4961)
2021.01.19 11:27:09.936 1:     main::readingsBulkUpdate            called by fhem.pl (4992)
2021.01.19 11:27:09.936 1:     main::readingsSingleUpdate          called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2428)
2021.01.19 11:27:09.936 1:     MQTT::GENERIC_BRIDGE::doPublish     called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2560)
2021.01.19 11:27:09.936 1:     MQTT::GENERIC_BRIDGE::publishDeviceUpdate called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2180)
2021.01.19 11:27:09.937 1:     MQTT::GENERIC_BRIDGE::checkPublishDeviceReadingsUpdates called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2103)
2021.01.19 11:27:09.937 1:     MQTT::GENERIC_BRIDGE::Notify        called by fhem.pl (3818)
2021.01.19 11:27:09.937 1:     main::CallFn                        called by fhem.pl (3735)
2021.01.19 11:27:09.938 1:     main::DoTrigger                     called by fhem.pl (4105)
2021.01.19 11:27:09.938 1:     main::Dispatch                      called by ./FHEM/00_MQTT2_CLIENT.pm (499)
2021.01.19 11:27:09.938 1:     main::MQTT2_CLIENT_Read             called by fhem.pl (3818)
2021.01.19 11:27:09.938 1:     main::CallFn                        called by fhem.pl (759)
2021.01.19 11:27:09.939 1: PERL WARNING: Use of uninitialized value $value in concatenation (.) or string at fhem.pl line 4973.
2021.01.19 11:27:09.939 1: stacktrace:
2021.01.19 11:27:09.939 1:     main::__ANON__                      called by fhem.pl (4973)
2021.01.19 11:27:09.940 1:     main::readingsBulkUpdate            called by fhem.pl (4992)
2021.01.19 11:27:09.940 1:     main::readingsSingleUpdate          called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2428)
2021.01.19 11:27:09.940 1:     MQTT::GENERIC_BRIDGE::doPublish     called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2560)
2021.01.19 11:27:09.940 1:     MQTT::GENERIC_BRIDGE::publishDeviceUpdate called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2180)
2021.01.19 11:27:09.941 1:     MQTT::GENERIC_BRIDGE::checkPublishDeviceReadingsUpdates called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2103)
2021.01.19 11:27:09.941 1:     MQTT::GENERIC_BRIDGE::Notify        called by fhem.pl (3818)
2021.01.19 11:27:09.941 1:     main::CallFn                        called by fhem.pl (3735)
2021.01.19 11:27:09.941 1:     main::DoTrigger                     called by fhem.pl (4105)
2021.01.19 11:27:09.942 1:     main::Dispatch                      called by ./FHEM/00_MQTT2_CLIENT.pm (499)
2021.01.19 11:27:09.942 1:     main::MQTT2_CLIENT_Read             called by fhem.pl (3818)
2021.01.19 11:27:09.942 1:     main::CallFn                        called by fhem.pl (759)
2021.01.19 11:27:09.942 1: PERL WARNING: Use of uninitialized value in substitution iterator at fhem.pl line 4710.
2021.01.19 11:27:09.943 1: stacktrace:
2021.01.19 11:27:09.943 1:     main::__ANON__                      called by fhem.pl (4710)
2021.01.19 11:27:09.943 1:     main::evalStateFormat               called by fhem.pl (4802)
2021.01.19 11:27:09.943 1:     main::readingsEndUpdate             called by fhem.pl (4993)
2021.01.19 11:27:09.944 1:     main::readingsSingleUpdate          called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2428)
2021.01.19 11:27:09.944 1:     MQTT::GENERIC_BRIDGE::doPublish     called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2560)
2021.01.19 11:27:09.944 1:     MQTT::GENERIC_BRIDGE::publishDeviceUpdate called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2180)
2021.01.19 11:27:09.944 1:     MQTT::GENERIC_BRIDGE::checkPublishDeviceReadingsUpdates called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2103)
2021.01.19 11:27:09.944 1:     MQTT::GENERIC_BRIDGE::Notify        called by fhem.pl (3818)
2021.01.19 11:27:09.945 1:     main::CallFn                        called by fhem.pl (3735)
2021.01.19 11:27:09.945 1:     main::DoTrigger                     called by fhem.pl (4105)
2021.01.19 11:27:09.945 1:     main::Dispatch                      called by ./FHEM/00_MQTT2_CLIENT.pm (499)
2021.01.19 11:27:09.946 1:     main::MQTT2_CLIENT_Read             called by fhem.pl (3818)
2021.01.19 11:27:09.946 1:     main::CallFn                        called by fhem.pl (759)
2021.01.19 11:27:09.949 1: PERL WARNING: Use of uninitialized value $function in hash element at fhem.pl line 4960.
2021.01.19 11:27:09.949 1: stacktrace:
2021.01.19 11:27:09.949 1:     main::__ANON__                      called by fhem.pl (4960)
2021.01.19 11:27:09.950 1:     main::readingsBulkUpdate            called by fhem.pl (4992)
2021.01.19 11:27:09.950 1:     main::readingsSingleUpdate          called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2430)
2021.01.19 11:27:09.950 1:     MQTT::GENERIC_BRIDGE::doPublish     called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2560)
2021.01.19 11:27:09.951 1:     MQTT::GENERIC_BRIDGE::publishDeviceUpdate called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2180)
2021.01.19 11:27:09.951 1:     MQTT::GENERIC_BRIDGE::checkPublishDeviceReadingsUpdates called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2103)
2021.01.19 11:27:09.952 1:     MQTT::GENERIC_BRIDGE::Notify        called by fhem.pl (3818)
2021.01.19 11:27:09.952 1:     main::CallFn                        called by fhem.pl (3735)
2021.01.19 11:27:09.952 1:     main::DoTrigger                     called by fhem.pl (4105)
2021.01.19 11:27:09.953 1:     main::Dispatch                      called by ./FHEM/00_MQTT2_CLIENT.pm (499)
2021.01.19 11:27:09.953 1:     main::MQTT2_CLIENT_Read             called by fhem.pl (3818)
2021.01.19 11:27:09.953 1:     main::CallFn                        called by fhem.pl (759)
2021.01.19 11:27:09.953 1: PERL WARNING: Use of uninitialized value $value in concatenation (.) or string at fhem.pl line 4973.
2021.01.19 11:27:09.954 1: stacktrace:
2021.01.19 11:27:09.954 1:     main::__ANON__                      called by fhem.pl (4973)
2021.01.19 11:27:09.954 1:     main::readingsBulkUpdate            called by fhem.pl (4992)
2021.01.19 11:27:09.954 1:     main::readingsSingleUpdate          called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2430)
2021.01.19 11:27:09.955 1:     MQTT::GENERIC_BRIDGE::doPublish     called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2560)
2021.01.19 11:27:09.955 1:     MQTT::GENERIC_BRIDGE::publishDeviceUpdate called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2180)
2021.01.19 11:27:09.955 1:     MQTT::GENERIC_BRIDGE::checkPublishDeviceReadingsUpdates called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2103)
2021.01.19 11:27:09.955 1:     MQTT::GENERIC_BRIDGE::Notify        called by fhem.pl (3818)
2021.01.19 11:27:09.956 1:     main::CallFn                        called by fhem.pl (3735)
2021.01.19 11:27:09.956 1:     main::DoTrigger                     called by fhem.pl (4105)
2021.01.19 11:27:09.956 1:     main::Dispatch                      called by ./FHEM/00_MQTT2_CLIENT.pm (499)
2021.01.19 11:27:09.956 1:     main::MQTT2_CLIENT_Read             called by fhem.pl (3818)
2021.01.19 11:27:09.957 1:     main::CallFn                        called by fhem.pl (759)
2021.01.19 11:27:09.957 1: PERL WARNING: Use of uninitialized value in substitution iterator at fhem.pl line 4710.
2021.01.19 11:27:09.957 1: stacktrace:
2021.01.19 11:27:09.957 1:     main::__ANON__                      called by fhem.pl (4710)
2021.01.19 11:27:09.958 1:     main::evalStateFormat               called by fhem.pl (4802)
2021.01.19 11:27:09.958 1:     main::readingsEndUpdate             called by fhem.pl (4993)
2021.01.19 11:27:09.958 1:     main::readingsSingleUpdate          called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2430)
2021.01.19 11:27:09.958 1:     MQTT::GENERIC_BRIDGE::doPublish     called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2560)
2021.01.19 11:27:09.958 1:     MQTT::GENERIC_BRIDGE::publishDeviceUpdate called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2180)
2021.01.19 11:27:09.959 1:     MQTT::GENERIC_BRIDGE::checkPublishDeviceReadingsUpdates called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2103)
2021.01.19 11:27:09.959 1:     MQTT::GENERIC_BRIDGE::Notify        called by fhem.pl (3818)
2021.01.19 11:27:09.959 1:     main::CallFn                        called by fhem.pl (3735)
2021.01.19 11:27:09.960 1:     main::DoTrigger                     called by fhem.pl (4105)
2021.01.19 11:27:09.960 1:     main::Dispatch                      called by ./FHEM/00_MQTT2_CLIENT.pm (499)
2021.01.19 11:27:09.960 1:     main::MQTT2_CLIENT_Read             called by fhem.pl (3818)
2021.01.19 11:27:09.961 1:     main::CallFn                        called by fhem.pl (759)
2021.01.19 11:27:09.969 1: PERL WARNING: Use of uninitialized value in substitution iterator at fhem.pl line 4710.
2021.01.19 11:27:09.969 1: stacktrace:
2021.01.19 11:27:09.970 1:     main::__ANON__                      called by fhem.pl (4710)
2021.01.19 11:27:09.970 1:     main::evalStateFormat               called by fhem.pl (4802)
2021.01.19 11:27:09.970 1:     main::readingsEndUpdate             called by fhem.pl (4993)
2021.01.19 11:27:09.970 1:     main::readingsSingleUpdate          called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2821)
2021.01.19 11:27:09.971 1:     MQTT::GENERIC_BRIDGE::onmessage     called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2802)
2021.01.19 11:27:09.971 1:     MQTT::GENERIC_BRIDGE::Parse         called by fhem.pl (4014)
2021.01.19 11:27:09.972 1:     main::Dispatch                      called by ./FHEM/00_MQTT2_CLIENT.pm (499)
2021.01.19 11:27:09.972 1:     main::MQTT2_CLIENT_Read             called by ./FHEM/00_MQTT2_CLIENT.pm (512)
2021.01.19 11:27:09.972 1:     main::__ANON__                      called by fhem.pl (3350)
2021.01.19 11:27:09.972 1:     main::HandleTimeout                 called by fhem.pl (681)

Geschaltet in FHEM:
2021.01.19 11:27:57.216 1: PERL WARNING: Argument "outgoing publish sent" isn't numeric in subtraction (-) at FHEM/TimeSeries.pm line 251.
2021.01.19 11:27:57.217 1: stacktrace:
2021.01.19 11:27:57.217 1:     main::__ANON__                      called by FHEM/TimeSeries.pm (251)
2021.01.19 11:27:57.218 1:     TimeSeries::_updatestat             called by FHEM/TimeSeries.pm (316)
2021.01.19 11:27:57.218 1:     TimeSeries::add                     called by fhem.pl (4961)
2021.01.19 11:27:57.219 1:     main::readingsBulkUpdate            called by fhem.pl (4992)
2021.01.19 11:27:57.219 1:     main::readingsSingleUpdate          called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2428)
2021.01.19 11:27:57.220 1:     MQTT::GENERIC_BRIDGE::doPublish     called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2560)
2021.01.19 11:27:57.220 1:     MQTT::GENERIC_BRIDGE::publishDeviceUpdate called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2180)
2021.01.19 11:27:57.221 1:     MQTT::GENERIC_BRIDGE::checkPublishDeviceReadingsUpdates called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2103)
2021.01.19 11:27:57.221 1:     MQTT::GENERIC_BRIDGE::Notify        called by fhem.pl (3818)
2021.01.19 11:27:57.221 1:     main::CallFn                        called by fhem.pl (3735)
2021.01.19 11:27:57.222 1:     main::DoTrigger                     called by fhem.pl (4810)
2021.01.19 11:27:57.222 1:     main::readingsEndUpdate             called by fhem.pl (4993)
2021.01.19 11:27:57.222 1:     main::readingsSingleUpdate          called by ./FHEM/98_dummy.pm (73)
2021.01.19 11:27:57.223 1:     main::dummy_Set                     called by fhem.pl (3813)
2021.01.19 11:27:57.223 1:     main::CallFn                        called by fhem.pl (1919)
2021.01.19 11:27:57.223 1:     main::DoSet                         called by fhem.pl (1951)
2021.01.19 11:27:57.224 1:     main::CommandSet                    called by fhem.pl (1251)
2021.01.19 11:27:57.224 1:     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2721)
2021.01.19 11:27:57.224 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (948)
2021.01.19 11:27:57.225 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (596)
2021.01.19 11:27:57.225 1:     main::FW_Read                       called by fhem.pl (3818)
2021.01.19 11:27:57.225 1:     main::CallFn                        called by fhem.pl (759)
2021.01.19 11:27:57.226 1: PERL WARNING: Argument "outgoing publish sent" isn't numeric in addition (+) at FHEM/TimeSeries.pm line 253.
2021.01.19 11:27:57.226 1: stacktrace:
2021.01.19 11:27:57.226 1:     main::__ANON__                      called by FHEM/TimeSeries.pm (253)
2021.01.19 11:27:57.226 1:     TimeSeries::_updatestat             called by FHEM/TimeSeries.pm (316)
2021.01.19 11:27:57.227 1:     TimeSeries::add                     called by fhem.pl (4961)
2021.01.19 11:27:57.227 1:     main::readingsBulkUpdate            called by fhem.pl (4992)
2021.01.19 11:27:57.227 1:     main::readingsSingleUpdate          called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2428)
2021.01.19 11:27:57.228 1:     MQTT::GENERIC_BRIDGE::doPublish     called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2560)
2021.01.19 11:27:57.228 1:     MQTT::GENERIC_BRIDGE::publishDeviceUpdate called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2180)
2021.01.19 11:27:57.228 1:     MQTT::GENERIC_BRIDGE::checkPublishDeviceReadingsUpdates called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2103)
2021.01.19 11:27:57.228 1:     MQTT::GENERIC_BRIDGE::Notify        called by fhem.pl (3818)
2021.01.19 11:27:57.229 1:     main::CallFn                        called by fhem.pl (3735)
2021.01.19 11:27:57.229 1:     main::DoTrigger                     called by fhem.pl (4810)
2021.01.19 11:27:57.229 1:     main::readingsEndUpdate             called by fhem.pl (4993)
2021.01.19 11:27:57.230 1:     main::readingsSingleUpdate          called by ./FHEM/98_dummy.pm (73)
2021.01.19 11:27:57.230 1:     main::dummy_Set                     called by fhem.pl (3813)
2021.01.19 11:27:57.230 1:     main::CallFn                        called by fhem.pl (1919)
2021.01.19 11:27:57.230 1:     main::DoSet                         called by fhem.pl (1951)
2021.01.19 11:27:57.231 1:     main::CommandSet                    called by fhem.pl (1251)
2021.01.19 11:27:57.231 1:     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2721)
2021.01.19 11:27:57.231 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (948)
2021.01.19 11:27:57.232 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (596)
2021.01.19 11:27:57.232 1:     main::FW_Read                       called by fhem.pl (3818)
2021.01.19 11:27:57.232 1:     main::CallFn                        called by fhem.pl (759)
2021.01.19 11:27:57.233 1: PERL WARNING: Argument "outgoing publish sent" isn't numeric in numeric lt (<) at FHEM/TimeSeries.pm line 358.
2021.01.19 11:27:57.233 1: stacktrace:
2021.01.19 11:27:57.233 1:     main::__ANON__                      called by FHEM/TimeSeries.pm (358)
2021.01.19 11:27:57.233 1:     TimeSeries::add                     called by fhem.pl (4961)
2021.01.19 11:27:57.234 1:     main::readingsBulkUpdate            called by fhem.pl (4992)
2021.01.19 11:27:57.234 1:     main::readingsSingleUpdate          called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2428)
2021.01.19 11:27:57.234 1:     MQTT::GENERIC_BRIDGE::doPublish     called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2560)
2021.01.19 11:27:57.235 1:     MQTT::GENERIC_BRIDGE::publishDeviceUpdate called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2180)
2021.01.19 11:27:57.235 1:     MQTT::GENERIC_BRIDGE::checkPublishDeviceReadingsUpdates called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2103)
2021.01.19 11:27:57.236 1:     MQTT::GENERIC_BRIDGE::Notify        called by fhem.pl (3818)
2021.01.19 11:27:57.236 1:     main::CallFn                        called by fhem.pl (3735)
2021.01.19 11:27:57.236 1:     main::DoTrigger                     called by fhem.pl (4810)
2021.01.19 11:27:57.236 1:     main::readingsEndUpdate             called by fhem.pl (4993)
2021.01.19 11:27:57.237 1:     main::readingsSingleUpdate          called by ./FHEM/98_dummy.pm (73)
2021.01.19 11:27:57.237 1:     main::dummy_Set                     called by fhem.pl (3813)
2021.01.19 11:27:57.237 1:     main::CallFn                        called by fhem.pl (1919)
2021.01.19 11:27:57.238 1:     main::DoSet                         called by fhem.pl (1951)
2021.01.19 11:27:57.238 1:     main::CommandSet                    called by fhem.pl (1251)
2021.01.19 11:27:57.238 1:     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2721)
2021.01.19 11:27:57.238 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (948)
2021.01.19 11:27:57.239 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (596)
2021.01.19 11:27:57.239 1:     main::FW_Read                       called by fhem.pl (3818)
2021.01.19 11:27:57.240 1:     main::CallFn                        called by fhem.pl (759)
2021.01.19 11:27:57.240 1: PERL WARNING: Argument "outgoing publish sent" isn't numeric in numeric lt (<) at FHEM/TimeSeries.pm line 358.
2021.01.19 11:27:57.240 1: stacktrace:
2021.01.19 11:27:57.240 1:     main::__ANON__                      called by FHEM/TimeSeries.pm (358)
2021.01.19 11:27:57.241 1:     TimeSeries::add                     called by fhem.pl (4961)
2021.01.19 11:27:57.241 1:     main::readingsBulkUpdate            called by fhem.pl (4992)
2021.01.19 11:27:57.241 1:     main::readingsSingleUpdate          called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2428)
2021.01.19 11:27:57.242 1:     MQTT::GENERIC_BRIDGE::doPublish     called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2560)
2021.01.19 11:27:57.242 1:     MQTT::GENERIC_BRIDGE::publishDeviceUpdate called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2180)
2021.01.19 11:27:57.242 1:     MQTT::GENERIC_BRIDGE::checkPublishDeviceReadingsUpdates called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2103)
2021.01.19 11:27:57.243 1:     MQTT::GENERIC_BRIDGE::Notify        called by fhem.pl (3818)
2021.01.19 11:27:57.243 1:     main::CallFn                        called by fhem.pl (3735)
2021.01.19 11:27:57.243 1:     main::DoTrigger                     called by fhem.pl (4810)
2021.01.19 11:27:57.243 1:     main::readingsEndUpdate             called by fhem.pl (4993)
2021.01.19 11:27:57.244 1:     main::readingsSingleUpdate          called by ./FHEM/98_dummy.pm (73)
2021.01.19 11:27:57.244 1:     main::dummy_Set                     called by fhem.pl (3813)
2021.01.19 11:27:57.244 1:     main::CallFn                        called by fhem.pl (1919)
2021.01.19 11:27:57.245 1:     main::DoSet                         called by fhem.pl (1951)
2021.01.19 11:27:57.245 1:     main::CommandSet                    called by fhem.pl (1251)
2021.01.19 11:27:57.245 1:     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2721)
2021.01.19 11:27:57.245 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (948)
2021.01.19 11:27:57.246 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (596)
2021.01.19 11:27:57.246 1:     main::FW_Read                       called by fhem.pl (3818)
2021.01.19 11:27:57.246 1:     main::CallFn                        called by fhem.pl (759)
2021.01.19 11:27:57.246 1: PERL WARNING: Argument "outgoing publish sent" isn't numeric in numeric gt (>) at FHEM/TimeSeries.pm line 359.
2021.01.19 11:27:57.247 1: stacktrace:
2021.01.19 11:27:57.247 1:     main::__ANON__                      called by FHEM/TimeSeries.pm (359)
2021.01.19 11:27:57.247 1:     TimeSeries::add                     called by fhem.pl (4961)
2021.01.19 11:27:57.247 1:     main::readingsBulkUpdate            called by fhem.pl (4992)
2021.01.19 11:27:57.247 1:     main::readingsSingleUpdate          called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2428)
2021.01.19 11:27:57.248 1:     MQTT::GENERIC_BRIDGE::doPublish     called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2560)
2021.01.19 11:27:57.248 1:     MQTT::GENERIC_BRIDGE::publishDeviceUpdate called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2180)
2021.01.19 11:27:57.248 1:     MQTT::GENERIC_BRIDGE::checkPublishDeviceReadingsUpdates called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2103)
2021.01.19 11:27:57.248 1:     MQTT::GENERIC_BRIDGE::Notify        called by fhem.pl (3818)
2021.01.19 11:27:57.249 1:     main::CallFn                        called by fhem.pl (3735)
2021.01.19 11:27:57.249 1:     main::DoTrigger                     called by fhem.pl (4810)
2021.01.19 11:27:57.249 1:     main::readingsEndUpdate             called by fhem.pl (4993)
2021.01.19 11:27:57.249 1:     main::readingsSingleUpdate          called by ./FHEM/98_dummy.pm (73)
2021.01.19 11:27:57.249 1:     main::dummy_Set                     called by fhem.pl (3813)
2021.01.19 11:27:57.250 1:     main::CallFn                        called by fhem.pl (1919)
2021.01.19 11:27:57.250 1:     main::DoSet                         called by fhem.pl (1951)
2021.01.19 11:27:57.250 1:     main::CommandSet                    called by fhem.pl (1251)
2021.01.19 11:27:57.250 1:     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2721)
2021.01.19 11:27:57.250 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (948)
2021.01.19 11:27:57.251 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (596)
2021.01.19 11:27:57.251 1:     main::FW_Read                       called by fhem.pl (3818)
2021.01.19 11:27:57.251 1:     main::CallFn                        called by fhem.pl (759)
2021.01.19 11:27:57.251 1: PERL WARNING: Use of uninitialized value in substitution iterator at fhem.pl line 4710.
2021.01.19 11:27:57.252 1: stacktrace:
2021.01.19 11:27:57.252 1:     main::__ANON__                      called by fhem.pl (4710)
2021.01.19 11:27:57.252 1:     main::evalStateFormat               called by fhem.pl (4802)
2021.01.19 11:27:57.252 1:     main::readingsEndUpdate             called by fhem.pl (4993)
2021.01.19 11:27:57.253 1:     main::readingsSingleUpdate          called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2428)
2021.01.19 11:27:57.253 1:     MQTT::GENERIC_BRIDGE::doPublish     called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2560)
2021.01.19 11:27:57.253 1:     MQTT::GENERIC_BRIDGE::publishDeviceUpdate called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2180)
2021.01.19 11:27:57.253 1:     MQTT::GENERIC_BRIDGE::checkPublishDeviceReadingsUpdates called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2103)
2021.01.19 11:27:57.253 1:     MQTT::GENERIC_BRIDGE::Notify        called by fhem.pl (3818)
2021.01.19 11:27:57.254 1:     main::CallFn                        called by fhem.pl (3735)
2021.01.19 11:27:57.254 1:     main::DoTrigger                     called by fhem.pl (4810)
2021.01.19 11:27:57.254 1:     main::readingsEndUpdate             called by fhem.pl (4993)
2021.01.19 11:27:57.254 1:     main::readingsSingleUpdate          called by ./FHEM/98_dummy.pm (73)
2021.01.19 11:27:57.255 1:     main::dummy_Set                     called by fhem.pl (3813)
2021.01.19 11:27:57.255 1:     main::CallFn                        called by fhem.pl (1919)
2021.01.19 11:27:57.255 1:     main::DoSet                         called by fhem.pl (1951)
2021.01.19 11:27:57.255 1:     main::CommandSet                    called by fhem.pl (1251)
2021.01.19 11:27:57.256 1:     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2721)
2021.01.19 11:27:57.256 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (948)
2021.01.19 11:27:57.256 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (596)
2021.01.19 11:27:57.256 1:     main::FW_Read                       called by fhem.pl (3818)
2021.01.19 11:27:57.256 1:     main::CallFn                        called by fhem.pl (759)

List demoswitch:
Internals:
   CFGFN     
   FUUID      6006b0a2-f33f-d16d-4323-22a8869bc13224ea
   LASTInputDev ha_MQTT2
   MSGCNT     8
   NAME       demoswitch
   NR         1031
   STATE      off
   TYPE       dummy
   ha_MQTT2_MSGCNT 8
   ha_MQTT2_TIME 2021-01-19 11:27:09
   READINGS:
     2021-01-19 11:27:57   state           off
Attributes:
   DbLogExclude .*
   mqttForward all
   mqttSubscribe state:stopic={"$base/set"}
   room       HASS,Test
   userattr   mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
   webCmd     on:off

ha_MQTT2:
Internals:
   BUF       
   DEF        192.168.18.90:1883
   DeviceName 192.168.18.90:1883
   FD         115
   FUUID      6006ad54-f33f-d16d-6568-9ffe6a919445092d
   NAME       ha_MQTT2
   NR         799
   PARTIAL   
   STATE      opened
   TYPE       MQTT2_CLIENT
   WBCallback
   clientId   fhem
   lastMsgTime 1611052815.13848
   nextOpenDelay 5
   qosCnt     32
   qosMaxQueueLength 100
   READINGS:
     2021-01-19 11:22:15   state           opened
   qosQueue:
Attributes:
   DbLogExclude .*
   clientId   fhem
   keepaliveTimeout 60
   msgAfterConnect -r fhem/connection/status connected
   msgBeforeDisconnect -r fhem/connection/status disconnected
   qosMaxQueueLength 100
   room       MQTT
   username   hamqtt

List mqttGeneric:
Internals:
   CFGFN     
   DEF        mqtt room=HASS
   FUUID      6006b062-f33f-d16d-fbac-4404a0ae5b1d1338
   IODev      ha_MQTT2
   NAME       mqttGeneric
   NR         949
   NTFY_ORDER 50-mqttGeneric
   STATE      in:  out: 14 devices: 1
   TYPE       MQTT_GENERIC_BRIDGE
   devspec    room=HASS
   prefix     mqtt
   CHANGED:
     incoming-count:
     incoming-count:
     incoming-count:
     incoming-count:
     incoming-count:
     incoming-count:
   READINGS:
     2021-01-19 11:22:15   device-count    1
     2021-01-19 11:27:57   outgoing-count  14
     2021-01-19 11:27:57   transmission-state outgoing publish sent
     2021-01-19 11:11:46   updated-reading-count 0
     2021-01-19 11:27:09   updated-set-count 8
     incoming-count:
       TIME       2021-01-19 11:41:07
       VAL       
   devices:
     :global:
       :defaults:
         pub:base   {"fhem/$device"}
         pub:qos    0
         pub:retain 1
         sub:base   {"fhem/$device"}
         sub:qos    2
         sub:retain 1
       :publish:
         *:
           mode       R
           topic      {"fhem/$device/$reading"}
     demoswitch:
       :publish:
       :subscribe:
         HASH(0x55c6516a8458)
   globalDeviceExcludes:
   globalReadingExcludes:
   globalTypeExcludes:
     pub:
       FHEMWEB    *
       Global     *
       MQTT       transmission-state
       MQTT_BRIDGE transmission-state
       MQTT_DEVICE transmission-state
       MQTT_GENERIC_BRIDGE *
       telnet     *
     sub:
       FHEMWEB    *
       Global     *
       MQTT       transmission-state
       MQTT_BRIDGE transmission-state
       MQTT_DEVICE transmission-state
       MQTT_GENERIC_BRIDGE *
       telnet     *
   subscribe:
Attributes:
   DbLogExclude .*
   IODev      ha_MQTT2
   event-aggregator incoming-count:120,outgoing-count:120,transmission-state:120
   globalDefaults sub:qos=2 pub:qos=0 retain=1 base={"fhem/$device"}
   globalPublish *:topic={"fhem/$device/$reading"}
   icon       mqtt_bridge_2
   room       MQTT
   stateFormat in: incoming-count out: outgoing-count devices: device-count
   verbose    3

Gruß,
Michael
« Letzte Änderung: 19 Januar 2021, 11:55:02 von OppiM »

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15768
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #10 am: 19 Januar 2021, 11:59:57 »
Also:
Mit den incoming-counts gibt es (für M2-IO'S, noch) ein Problem, siehe https://forum.fhem.de/index.php/topic,117737.msg1121399.html#msg1121399.

Das haut dir das stateFormat und ggf. den event-aggregator zusammen. Lösche diese beiden Attribute zur MGB mal, dann sollte der Fehler weg sein.

In dem obigen Thread findest du auch einen Link zu "meiner" Modulfassung. Ob/was hexenmeister ggf. davon übernimmt, kann ich nicht beurteilen, aber evtl. hilft ihm Rückmeldung, dass das so funktioniert; ich selbst habe das bisher nur unter M2_SERVER getestet...
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline OppiM

  • Jr. Member
  • **
  • Beiträge: 67
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #11 am: 19 Januar 2021, 12:32:38 »
Hi,

das stateFormat war es nicht, aber der event-aggregator. Sobald der raus ist, gibt es keine Meldungen mehr, auch wenn stateFormat noch drin ist.

Dann seh ich mir jetzt mal deine Version an, ist derzeit eh nur ein Test.

Gruß,
Michael

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15768
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #12 am: 19 Januar 2021, 13:20:59 »
Danke auch für den Mut zum Testen...

Falls du jetzt erst nach github gehst, findest du da gleich eine Version, die "attrTemplate" als set-Befehl kennt.

In MAX Thermostate und MQTT - Readings und Steuerung über FHEM verfügbar machen (speziell: https://forum.fhem.de/index.php/topic,117423.msg1122346.html#msg1122346) hatte ich das mal andiskutiert, ob das ggf. Sinn macht.

So ein richtiges Ergebnis dazu gibt's nicht, aber das feedback der User ist ja immer das, was dann ggf. dazu führt, ob Ideen dann umgesetzt werden oder nicht. Die Idee dahinter wäre, über die MGB dann das "Zieldevice" auszuwählen und darüber dann die Attribute zu setzen, gleich mit Umrechnungen oä, wo sinnvoll ;) .
Im Moment ist die Auswahl natürlich noch ziemlich gering, und das, was vorhanden ist, ist in der im git ebenfalls zu findenden general_use.template...
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}
Informativ Informativ x 1 Liste anzeigen

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15768
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #13 am: 21 Januar 2021, 16:48:27 »
Hallo zusammen,

kurzes update dazu: hexenmeister hat zwischenzeitlich die funktionalen Teile übernommen, ihr solltet also ggf. wieder die reguläre Version aus dem svn verwenden.

Weiter gibt es jetzt betr. der attrTemplate-Sache einen separaten Thread, wer mag, kann sich dort gerne konstruktiv einbringen, interessant sind v.a. auch die Rückmeldungen von den Usern, die die Anbindung via MQTT_GENERIC_BRIDGE bereits am laufen haben ;) .

Grüße,
Beta-User
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}
Informativ Informativ x 1 Liste anzeigen

Offline gadget

  • Full Member
  • ***
  • Beiträge: 275
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #14 am: 21 Januar 2021, 17:16:41 »
ich hab meinen Post #2 mal angepasst auf die zwischenzeitlichen Ändernungen an der MQTT_GENERIC_BRIDGE. Zum Erstellungszeitpunkt hatte das noch alles so wie ursprünglich beschrieben funktioniert gehabt.

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15768
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #15 am: 21 Januar 2021, 17:26:28 »
Kannst du kurz zusammenfassen, was sich geändert hat; nicht, dass wir versehentlich was kaputt gemacht haben...

Weiter würde mich interessieren, warum du denselben Topic für Senden und Empfangen nutzt (oder ist das eine Fehlinterpretation meinerseits?)?

Zu guter Letzt: Du schreibst, dass du den Umweg über readingsProxy gehen müßtest, um MQTT2_DEVICE-Type Geräte an FHEM anzubinden. Ich bin nicht ganz sicher, glaube aber, dass das ohne weitere gehen sollte (v.a., wenn man für die 2. Anbindung dann wieder jeweils unterschiedliche topics in Sende- und Empfangsrichtung verwendet; zwischenzeitlich sollte es sogar klappen, so ein Device über mehrere MQTT_GENERIC_BRIDGEs (mit unterschiedlichen Prefixes, versteht sich) auch in verschiedene Richtungen publishen zu lassen, also z.B. auch - neben der HomeAssistant-Anbindung) direkt ein ESP-Display damit zu beschicken; (mit dem aktuellen Mechanismus sollte das sogar praktisch kaum mehr Systemlast erzeugen). Das aber nur am Rande).

Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline gadget

  • Full Member
  • ***
  • Beiträge: 275
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #16 am: 21 Januar 2021, 18:27:11 »
Ich hab attr mqttGeneric mttqForward all ergänzt und stateFormat / event-aggregator rausgenommen (aufgrund der nachfolgenden Posts) damit das Beispiel hoffentlich wieder schlüssig ist.

Senden und Empfangen laufen auf unterschiedlichen Topics: fhem/demoswitch/state bzw. fhem/demoswitch/set (siehe auch configuration.yaml).

Wegen readings_proxy: Als ich die Anbindung Mitte 2020 umgesetzt habe, ging das noch nicht. Ich habe in meiner fhem Installation ja zwei unterschiedliche MQTT-Server, einmal den fhem-eigenen    
MQTT2_SERVER m2s (zur Anbindung von tasmota- und Zigbee2MQTT-Devices) und dann remote den Mosquitto von HA. Wenn ich z.B. den Schaltzustand eines tasmota-Devices, das am m2s  angebunden ist, an den Mosquitto von HA senden wollte, hat das nicht funktioniert. Die haben als IODev m2s drin stehen und wurden dann offenbar  von der Bridge ignoriert. Drum habe ich denn halt jeweils einen Readingsproxy zwischengeschaltet, der ist dann ja eben kein MQTT-Device und konnte dann über die Bridge zum HA Broker funken.
Ich werde das bei Gelegenheit nochmal ausprobieren falls es da jetzt Änderungen gab, die das ohne Umweg ermöglichen.

Grüße,

gadget.
« Letzte Änderung: 21 Januar 2021, 18:29:26 von gadget »

Offline hexenmeister

  • Developer
  • Hero Member
  • ****
  • Beiträge: 4678
    • tech_LogBuch
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #17 am: 22 Januar 2021, 23:45:39 »
Ist das wirklich nötig, zwei MQTT-Server zu verwenden? Es gibt dafür Anwendungesföllen, sind aber schon eher speziell. Ansonten wird  Mosquitto auch alleine wunderbar alles bedienen können. Oder eben der MQTT2_SERVER. Ich würde eher die HA umbiegen und den 'entfernten' Mosquitto abschaffen.

Ansonsten werden MQTT-Server i.d.R. miteinander mit eigenen Mitteln verbunden (bridging). In Mosquitto kann man konfigurieren, welche Topics der an andere Server weiterleiten soll. Ob das MQTT2_SERVER auch unterstützt, weiß ich nicht, sollte aber klappen, der Mosquitto auf der Gegenseite wird sich um senden und abonieren kümmern.
« Letzte Änderung: 23 Januar 2021, 00:03:57 von hexenmeister »
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15768
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #18 am: 23 Januar 2021, 05:50:45 »
Würde auch dazu neigen, die Gesamtkonstruktion möglichst einfach zu halten, wobei sich die Wahl des Servers wohl danach ausrichten sollte, wie viel "externer Verkehr" stattfindet, den "das Haupt-FHEM" nicht mitzubekommen braucht. Ist das wenig, eher M2_SERVER, ist das viel oder sind lahme Clients mit großen Datenmengen, dabei, dürfte mosquitto (o.a.) die bessere Wahl sein.
(die Daten müssen halt irgendwie in FHEM).

Server-bridgeing beherrscht M2_SERVER afaik nicht.

Hier hatte gadget ja erläutert, dass die Zugriffsrechte für manche (menschliche) User auf den mosquitto andere sind als auf M2_SERVER/FHEM, von daher hat es hier vermutlich seine Berechtigung. (Ob mosquitto es ermöglicht, unterschiedliche "Berechtigungen" zu verwalten, wäre ggf. noch eine Frage, aber das ist dann ggf. auch nicht "einfacher" im Sinne obiger Grund-Tendenz).


Was aber (zumindest in meinem Test eben) geht (hat aber mit Server-bridgeing nichts zu tun):

MQTT2_SERVER+2 MGB+Weiterleiten von Readings aus einem MQTT2_DEVICE.

Würde daher annehmen, dass es prinzipiell kein Problem darstellt, die Daten von einem (wirklich hinsichtlich des TYPE (fast) beliebigen) Device auf diesem Weg auch an verschiedene Server zu verteilen. Das sollte auch unabhängig vom IO-TYPE gehen.
Zur Klarstellung noch: es ist mAn. effizienter, für _dasselbe IO_ nur eine MGB zu verwenden und eher den !other_subscriber-Weg zu gehen, wenn man Daten aus einem Device "vervielfältigen" will.
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline hckoe

  • Full Member
  • ***
  • Beiträge: 124
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #19 am: 26 Januar 2021, 21:33:01 »
Hallo,

nachdem das mit dem Demoswitch alles geklappt hat, habe ich dann auch problemlos einen EnOcean Lichtschalter (Eltako FSB12) eingebunden. Kommunikation HA und FHEM funktioniert in beide Richtungen. Dagegen habe ich jetzt mit einem EnOcean Dimmer (Eltako FUD12) schon Probleme bei der Richtung FHEM -> HA. Wenn ich den Dimmer in FHEM ein-/auschalte sehe ich den passenden Zustand in HA. Wenn ich den Slider verwende, funktioniert das nur, wenn ich vorher den Dimmer einschalte.

Hier die Definition des Dimmers:
defmod demodimmer EnOcean FFCC6822
attr demodimmer userattr DIMMER DIMMER_map mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long structexclude
attr demodimmer IODev TCM310_0
attr demodimmer devStateIcon 0:FS20.off 100:FS20.on
attr demodimmer gwCmd dimming
attr demodimmer icon light_control
attr demodimmer manufID 00D
attr demodimmer mqttPublish state:topic={"$base/state"} dim:topic={"$base/dim"}
attr demodimmer mqttSubscribe state:stopic={"$base/set"}
attr demodimmer room HASS
attr demodimmer stateFormat dim
attr demodimmer subType gateway
attr demodimmer webCmd on:off:dim

setstate demodimmer 0
setstate demodimmer 2021-01-26 21:13:00 block unlock
setstate demodimmer 2021-01-26 21:13:00 dim 0
setstate demodimmer 2021-01-26 21:12:45 dimValueStored 50
setstate demodimmer 2021-01-26 21:13:00 state off

Hier noch die Ausgaben vom mosquitt_sub auf fhem/demodimmer/set .../state .../dim
Dimmer aus, dann Slider auf 50% -> HA: Dimmer aus, Slider 0%

fhem/demodimmer/state off
fhem/demodimmer/dim 50
fhem/demodimmer/state dim

Dimmer an, dann Slider auf 50% -> HA: Slider auf 50%

fhem/demodimmer/state on
fhem/demodimmer/dim 50
fhem/demodimmer/state dim

Hier noch die Konfig aus HA:
light:
  - platform: mqtt
    unique_id: "demodimmer"
    name: "Demo Dimmer"
    optimistic: false
    retain: true
    brightness_scale: 100
    on_command_type: brightness
    command_topic: "fhem/demodimmer/set"
    brightness_command_topic: "fhem/demodimmer/dim"
    brightness_state_topic: "fhem/demodimmer/dim"
    state_topic: "fhem/demodimmer/state"
    payload_on: "on"
    payload_off: "off"

Hat jemand eine Idee, warum das nur im Zustand "on" funktioniert. In FHEM schaltet auch ein "set dim 50" die Lampe ein und dimmt sie auf 50%.

Gruß
Helmut

# CT mit Debian Buster / FHEM aktuell / EnOcean TCM310 / Eltako FSA12, FUD12NPN, FSB12, FRW, FSRP-230V
# Permundo PCS234, Nodon NO-SIN-2-2-00, GTAGS

Offline gadget

  • Full Member
  • ***
  • Beiträge: 275
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #20 am: 27 Januar 2021, 02:19:17 »
Hallo Helmut,

Ich habe einen Eltako FUD71 Dimmaktor mit folgender Konfig problemlos laufen:

Home Assistant configuration.yaml:

light:
  - platform: mqtt
      name: "WZ Decke"
      optimistic: false
      retain: false
      brightness_scale: 100
      on_command_type: first
      command_topic: "fhem/Eltako_Aktor_FUD71_19888CA/set"
      brightness_command_topic: "fhem/Eltako_Aktor_FUD71_19888CA/setdim"
      brightness_state_topic: "fhem/Eltako_Aktor_FUD71_19888CA/dim"
      state_topic: "fhem/Eltako_Aktor_FUD71_19888CA/state"
      payload_on: "on"
      payload_off: "off"
      availability_topic: "fhem/connection/status"
      payload_available: "connected"
      payload_not_available: "disconnected"

fhem:

defmod Eltako_Aktor_FUD71_19888CA EnOcean 019888CA
attr Eltako_Aktor_FUD71_19888CA userattr  mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
attr Eltako_Aktor_FUD71_19888CA IODev TCM_ESP3_0
attr Eltako_Aktor_FUD71_19888CA alias Deckenleuchte WZ
attr Eltako_Aktor_FUD71_19888CA comMode confirm
attr Eltako_Aktor_FUD71_19888CA eep A5-38-08
attr Eltako_Aktor_FUD71_19888CA group Licht
attr Eltako_Aktor_FUD71_19888CA gwCmd dimming
attr Eltako_Aktor_FUD71_19888CA icon light_ceiling
attr Eltako_Aktor_FUD71_19888CA manufID 00D
attr Eltako_Aktor_FUD71_19888CA mqttSubscribe state:stopic={"$base/set"} dim:stopic={"$base/setdim"}
attr Eltako_Aktor_FUD71_19888CA room EnOcean,HASS,Wohnzimmer
attr Eltako_Aktor_FUD71_19888CA subDef FFBD8A34
attr Eltako_Aktor_FUD71_19888CA subType gateway
attr Eltako_Aktor_FUD71_19888CA webCmd dim
attr Eltako_Aktor_FUD71_19888CA widgetOverride dim:knob,min:40,max:100,step:1,linecap:round,angleOffset:-125,angleArc:250


In Lovelace verwende ich die Custom Card https://github.com/thomasloven/lovelace-slider-entity-row (via  HACS installiert), damit kann ich normale Ein/Aus Lichter und dimmbare Lichter kompakt in einer Card zusammenfassen.

entities:
  - entity: light.wz_decke
    hide_when_off: true
    min: 25
    toggle: true
    type: 'custom:slider-entity-row'


Grüße, gadget
« Letzte Änderung: 27 Januar 2021, 02:29:57 von gadget »

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15768
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #21 am: 27 Januar 2021, 12:59:33 »
@hckoe:
Na ja, du hast auch auf dim kein subscribe...
Zitat
attr demodimmer mqttSubscribe state:stopic={"$base/set"}
Vielleicht noch eine Anmerkung:
Wenn du das jetzt angehst, können wir das auch zusammen versuchen, allerdings sollten dann machen "Standards" beachtet werden (bzw. das, was dazu werden könnte:

- $base (aus den globalen Vorgaben) sollte jetzt doch ohne den $device-Anteil auskommen
- alle Setter gehen nach subscribe-$base ("xyz"/set) (festgelegt über ein globales Attribut an der MGB, wobei "xyz" das ist, was in publish-Richtung $base heißt)
- alles, was state betrifft, geht dann über $base/$device direkt, alles andere über $base/$device/$name

- dann sollte man für alles, was irgendwie "Standard" ist, auch standardisierte Benennungen verwenden. Vorschlag:
-- pct für (fast) alles, was 0-100 ist (bzw. bei ZWave: 0-99) (das würde hier bedeuten, einen mqttAlias zu verwenden "dim=pct")
    (Ausnahme: actuator/valve (?) bei Thermostaten etc., slatLevel (?) für Lamellendrehung)
-- brightness für alles, was in 0-255 einzustellen ist

-- desired-temp für die Soll-Temperatur,
-- temperature für gemessene Temperatur.

Falls da Interesse besteht, bitte ich um Rückmeldung, dann kann ich nämlich gleich versuchen, das in attrTemplate-Form zu gießen.

Falls jemand sich die Frage stelle, was das ggf. bringt: So kann man
- im Bedarfsfall einfach das Gerät (gegen ein völlig anderes) tauschen, paßt die (standardisierten!) Attribute an (ggf. über attrTemplate), und alles funktioniert von MQTT aus weiter wie bisher;
- in der yaml für alle Device-Typen denselben "Grundtypus" verwenden, man muss nur den Namen anpassen, und man kann sich auch hier zwischen den Usern einfacher austauschen...

(Ist nur ein Vorschlag...)

EDIT: Rückmeldungen zu Benennungsfragen bitte im Hauptthread ab hier: https://forum.fhem.de/index.php/topic,117987.msg1126418.html#msg1126418
« Letzte Änderung: 27 Januar 2021, 13:08:06 von Beta-User »
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline gadget

  • Full Member
  • ***
  • Beiträge: 275
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #22 am: 27 Januar 2021, 13:29:55 »
Ich glaube, der Zug für die Standardisierung ist bei fhem bereits abgefahren. Das wäre fast überall ein breaking change. Beispiel:

Fritz Dect Heizungsaktor (FBDECT):

desired-temp  17.0  C

fhem PWMR Modul:

desired-temp 21.5

Max Heizkörper Stellaktor:

desiredTemperature 17.0

Da kommt man um Handarbeit nicht rum, um das HomeAssistant-konform aufzubereiten.




Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15768
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #23 am: 27 Januar 2021, 13:43:33 »
Ich glaube, der Zug für die Standardisierung ist bei fhem bereits abgefahren. Das wäre fast überall ein breaking change. Beispiel:
Jein, Missverständnis, und herzlichen Dank für genau diese Frage :) !

Es geht _nicht_ darum, das IN FHEM zu standardisieren (jedenfalls nicht, für den Ist-Zustand), sondern für die MQTT-Schnittstelle; siehe dazu auch DevelopmentGuidelinesReadings - weitere Vorschläge für künftige Module. Optimalerweise wird sowas dann auch beachtet bei der Entwicklung künftiger Module, aber soweit sind wir noch lange nicht...

Für MAX gibt es bereits ein attrTemplate, das die Namen ummappt, und für den DECT könnte man im Prinzip den ZWave-Code des ebenfalls bereits vorliegenden attrTemplate ausschlachten: Da ist für temperature ein "mach das Celsius weg"-code drin. Die Frage ist da nur, ob der einen rein nummerischen Wert als Anweisung versteht...

Hoffe, jetzt wird auch etwas klarer, wohin meine Überlegungen/Vorschläge gehen 8) ?
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline hckoe

  • Full Member
  • ***
  • Beiträge: 124
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #24 am: 27 Januar 2021, 15:01:08 »
Hallo Beta-User,

ich bin da offen für alles. Ich werde mal schauen, daß ich es auf die "Standards" anpasse. Kann ich aber erst am WE in Ruhe machen.
Den Subscribe auf dim hatte ich schon drin, aber dann hat irgendwie das Publish dim und Subscribe dim einen Loop gebildet.

Melde mich demnächst.

Viele Grüße
Helmut
# CT mit Debian Buster / FHEM aktuell / EnOcean TCM310 / Eltako FSA12, FUD12NPN, FSB12, FRW, FSRP-230V
# Permundo PCS234, Nodon NO-SIN-2-2-00, GTAGS

Offline hckoe

  • Full Member
  • ***
  • Beiträge: 124
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #25 am: 31 Januar 2021, 17:54:56 »
Hallo Beta-User,

ich habe jetzt die MGB und den Dimmer noch einmal "sauber" nach Deinen Vorschlägen und mit attrTemplate aufgesetzt, d.h. Subscribe- und Publish-base sind jetzt gesplittet, pct ist jetzt ein mqttAlias für dim. Es funktioniert jetzt auch von HA nach FHEM alles, von FHEM nach HA gibt es aber noch immer das Problem, daß HA die Position des dim-Sliders nur aktualisert, wenn der Dimmer im on-Zustand ist. Das Problem ist vermutlich, daß der Dimmer die 3 Stati on,off und dim kennt und  HA nur on,off. FHEM published nämlich immer folgende Topics, egal ob aus dem on- oder off-Zustand:

MGB/demodimmer/pct 50
MGB/demodimmer dim

Wenn ich jetzt manuell mit mosquitto_pub folgende Topics schicke funktioniert es:

MGB/demodimmer/pct 50
MGB/demodimmer on

D.h. ich muss schauen, ob ich den dim-Status in HA irgendwie auf on gemappt bekomme.
Hat jemand so etwas schon einmal gemacht? Oder sieht jemand eine andere Möglichkeit?

Viele Grüße
Helmut
# CT mit Debian Buster / FHEM aktuell / EnOcean TCM310 / Eltako FSA12, FUD12NPN, FSB12, FRW, FSRP-230V
# Permundo PCS234, Nodon NO-SIN-2-2-00, GTAGS

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15768
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #26 am: 02 Februar 2021, 15:06:20 »
Sorry, dass es etwas gedauert hat mit der Rückmeldung...

Vorab mal: Schön, dass du vorankommst!

Bin etwas aus der Spur geraten, weil ich das Wiki bzw. die cref überarbeitete habe und da noch auf die (wohl wirklich überholte) Info gestoßen bin, Alias ginge nicht bei subscribe...

Was das Verhalten bei "gedimmtem on" angeht, würde ich vermuten, dass man das mit einer expression in den Griff bekommen könnte: "einfach" "dim" durch "on" ersetzen. Ungetestet:
state:expression={$value=~m,dim,?"on":$value}
Wenn das so klappt, wäre das m.E. die zu bevorzugende Variante, weil man dann wieder in der externen Anwendung nichts ändern muss, sondern einen mAn. konsistenten Datensatz bekommt. Und das war ja der eigentliche Gedanke hinter der attrTemplate-Idee...
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline hckoe

  • Full Member
  • ***
  • Beiträge: 124
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #27 am: 02 Februar 2021, 15:11:56 »
Danke für die Info. Werde ich heute abend gleich ausprobieren.
# CT mit Debian Buster / FHEM aktuell / EnOcean TCM310 / Eltako FSA12, FUD12NPN, FSB12, FRW, FSRP-230V
# Permundo PCS234, Nodon NO-SIN-2-2-00, GTAGS

Offline hckoe

  • Full Member
  • ***
  • Beiträge: 124
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #28 am: 02 Februar 2021, 19:02:22 »
Also mit dem Hinweis auf state:expression funktioniert es jetzt.
Danke! Jetzt kommen noch Rollos und Jalousien dran.

@gadget: Kann der von Dir erwähnte Slider aus dem HACS Werte von 0–100 oder nur wie der Standard 1–100?
# CT mit Debian Buster / FHEM aktuell / EnOcean TCM310 / Eltako FSA12, FUD12NPN, FSB12, FRW, FSRP-230V
# Permundo PCS234, Nodon NO-SIN-2-2-00, GTAGS

Offline gadget

  • Full Member
  • ***
  • Beiträge: 275
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #29 am: 02 Februar 2021, 19:40:51 »
Hab ich nicht ausprobiert
 Mein eltako Dimmer schaltet unter 15% eh ab.

Offline hckoe

  • Full Member
  • ***
  • Beiträge: 124
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #30 am: 09 Februar 2021, 11:48:44 »
So, habe jetzt die Kommunikation zwischen HA/MosquittoMQTT und FHEM/MQTT2_CLIENT/MGB soweit am Laufen. Stecke aber jetzt noch in einem Verständnis-Problem mit "retain".
Ich versuch's mal zu beschreiben:

FHEM und HA haben bei einem Demoswitch jeweils folgende Topics (mit retain=0) abonniert:
mqttPublish     -> MGB/demoswitch      -> state_topic
mqttSubscribe <- MGB/set/demoswitch <- command_topic

Wenn ich jetzt bei eingeschaltenem Switch am MQTT2_CLIENT disconnect/connect ausführe (oder FHEM neu starte) schaltet sich der Switch aus. Mosquitto_sub liefert:
MGB/connection disconnected
MGB/connection connected
MGB/demoswitch off
Vermutlich ist bei MQTT der Default "off" bei retain=0.

Das gleiche Verhalten habe ich, wenn ich in FHEM retain=1 eingebe.
Erst wenn ich in HA retain=true setze, bleibt der Status des Switches über Neustarts von FHEM bzw. disconnect/connect-Aufrufe des MQTT2_CLIENTS erhalten. Das FHEM Retain-Flag ist hier egal.
MGB/connection disconnected
MGB/connection connected
MGB/demoswitch on

Warum hat "retain" hier in FHEM keine Auswirkung, sondern nur in HA?
Kann hier jemand Licht in mein Dunkel bringen?


# CT mit Debian Buster / FHEM aktuell / EnOcean TCM310 / Eltako FSA12, FUD12NPN, FSB12, FRW, FSRP-230V
# Permundo PCS234, Nodon NO-SIN-2-2-00, GTAGS

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 24511
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #31 am: 09 Februar 2021, 12:28:10 »
Zitat
Vermutlich ist bei MQTT der Default "off" bei retain=0.
Es gibt kein Default bei retain=0.

Retain bedeutet, dass diese Nachricht gespeichert wird, und wenn jemand nach diesem Topic fragt, die Nachricht erhaelt.
Um die Nachricht zu entfernen, muss man das gleiche Topic mit einem leeren Message schicken.

Vor kurzem wurden Fehler bei der Kombination MGB/MQTT2_CLIENT/retain gemeldet, weiss aber nicht den aktuellen Status dazu.
Auf dem ersten Blick schaut der MGB Code richtig aus.

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15768
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #32 am: 09 Februar 2021, 14:18:20 »
Könnte auch was mit "resendOnConnect" zu tun haben.

Hast du da irgendeine Einstellung in diese Richtung vorgenommen?
(Im Code gibt es dazu einen auskommentierten Zweig in isConnected(), der für M2C "always online" signalisiert, was aber dieses Phänomen eigentlich auch nicht erklären würde...)
Ansonsten: kannst du sicherheitshalber mal in global "showInternalValues" auf 1 setzen und dann mal schauen, ob an der MGB irgendwas in richtung .helper -> .pub_queue zu erkennen ist?
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline hckoe

  • Full Member
  • ***
  • Beiträge: 124
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #33 am: 09 Februar 2021, 14:35:04 »
Nein, resendOnConnect verwende ich nicht. Werde das mit "showInternalValues" heute abend mal testen.
# CT mit Debian Buster / FHEM aktuell / EnOcean TCM310 / Eltako FSA12, FUD12NPN, FSB12, FRW, FSRP-230V
# Permundo PCS234, Nodon NO-SIN-2-2-00, GTAGS

Offline gadget

  • Full Member
  • ***
  • Beiträge: 275
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #34 am: 09 Februar 2021, 14:35:31 »
Im Beispiel (Post#2)  ist auch aufgezeigt, wie man in HA das  availability_topic verwendet. Wenn fhem (oder die Verbindung zum MQTT Server) down ist bekomme ich in HA bei den abhängigen Geräten schlicht ein "unavailable" angezeigt und kann dann bei denen auch nix schalten.
Bei Schaltern würde ich auch kein retain verwenden. Das kann unschön werden, wenn nach einer längeren Störung dann auf einmal alte Schaltzustände "nachgeschickt" werden, die aktuell wahrscheinlich eher unerwünscht sind.

Offline hckoe

  • Full Member
  • ***
  • Beiträge: 124
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #35 am: 09 Februar 2021, 15:37:41 »
Das availability_topic habe ich schon eingestellt. Die connected/disconnected-Meldungen kommen auch davon. Und da beim Switch retain=false eingestellt ist, kann ich den auch nicht mehr von HA aus schalten, wenn fhem down ist. Ich stelle jetzt noch einmal alles auf retain=false und lösche alle alten Stati in MQTT und dann teste ich noch einmal, um sicher zu gehen.
# CT mit Debian Buster / FHEM aktuell / EnOcean TCM310 / Eltako FSA12, FUD12NPN, FSB12, FRW, FSRP-230V
# Permundo PCS234, Nodon NO-SIN-2-2-00, GTAGS

Offline hckoe

  • Full Member
  • ***
  • Beiträge: 124
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #36 am: 09 Februar 2021, 16:35:31 »
So, da haben doch noch irgendwelche alten retained-Stati beim Mosquitto reingefunkt. Habe mal alle gespeicherten retained Topics gelöscht. Und siehe da, es klappt - auch mit disconnect/connect.
Habe alles wieder auf retained=false gestellt.

Sorry für die Verwirrung, die ich gestiftet habe.
# CT mit Debian Buster / FHEM aktuell / EnOcean TCM310 / Eltako FSA12, FUD12NPN, FSB12, FRW, FSRP-230V
# Permundo PCS234, Nodon NO-SIN-2-2-00, GTAGS

Offline jensorium

  • New Member
  • *
  • Beiträge: 10
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #37 am: 21 Februar 2021, 01:44:49 »
Hey

ich hab Jahrlang zufrieden pilight genutzt, das lief dann nicht mehr und ich bekam es auch einfach nicht mehr ans laufen, dann auf Fhem gewechselt, aber irgendwie warm geworden bin ich damit nie ;/. Jetzt meine Idee HomeAssistant zu nutzen, optisch erstmal besser aber keine Verbindung zu meinem Nanocul möglich. Ok Plan B Fhem mit MQTT auf dem alten Raspi, HA auf dem neuen.
Erstmal so gar nichts geklappt und dann diese super Anleitung gefunden. Danke erstmal!
attr mqttGeneric mttqForward all lies sich nicht einrichten. "mqttGeneric: unknown attribute mttqForward. Type 'attr mqttGeneric ?' for a detailed list."

Mit dem Demoschalter schien auch alles zu laufen.
Dann habe ich einen wirklichen Schalter aus Fhem eingefügt. Dies ging auch nach anfänglichen Problemen in HA (weiß immer noch nicht wo nun mein Typo war), lässt sich aus HA auch schalten, aber der Status springt dann immer wieder auf den vorherigen Status den HA hatte :( Also der Schrank ist an, ich schalte ihn aus über HA aber der Schalter springt wieder zurück auf an.

Hat hier wer eine Idee? Es scheint für mich an HA zu liegen, daher hier der Code:

switch:
  - platform: mqtt
    name: "demoswitch"
    command_topic: "fhem/demoswitch/set"
    state_topic: "fhem/demoswitch/state"
    payload_on: "on"
    payload_off: "off"
    state_on: "on"
    state_off: "off"
  - platform: mqtt
    name: "schrank"
    command_topic: "fhem/schrank/set"
    state_topic: "fhem/schrank/state"
    payload_on: "on"
    payload_off: "off"
    state_on: "on"
    state_off: "off"

Wenn ich sonst was an Code senden soll sagt bescheid
Danke und Gruß
Jens

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15768
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #38 am: 21 Februar 2021, 08:50:12 »
Dann mal willkommen im Forum hier!

Das Attribut gehört mAn. zum jeweiligen "wirklichen Schalter" und kann je nach prefix-Einstellung in der MGB auch anders heißen; ein list von der MGB und dem "wirklichen Schalter" wären ggf. aufschlussreich...
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline jensorium

  • New Member
  • *
  • Beiträge: 10
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #39 am: 21 Februar 2021, 14:35:56 »
Hey

Danke fürs Willkommen und die Gedanken

der wirkliche schalter ist auch ein Dummy. Der schaltet dann über RPi_utils per notify.

mgttGeneric devinfo:
demoswitch
  publish:
  subscribe:
    state            <= fhem/demoswitch/set (mode: S)

schrank
  publish:
  subscribe:
    state            <= fhem/schrank/set (mode: S)

ist es das was du meintest?


HA schaltet ja auch in Fhem, aber er geht dann zurück auf den alten Zustand.

Gruß

Offline gadget

  • Full Member
  • ***
  • Beiträge: 275
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #40 am: 21 Februar 2021, 17:34:13 »
Mach mal ein list schrank und poste das Ergebnis hier. Wenn die MQTT-Kommunikation z.B. mit mosquitto_sub  abhörst: Was passiert auf dem topic  fhem/schrank/state   wenn Du von fhem oder von HA aus schaltest ?

(mosquitto_sub - Beispiele sind im Post #2 dieses Threads, es gibt mit https://mqtt-explorer.com/ auch ein sehr gutes grafisches Tool)

Wenn der Schalter hin HA wieder zurück springt, liegt das i.d.R. daran, dass du auf dem .../state keine Rückmeldung über den Schaltvorgang bekommst, der über .../set ausgelöst wurde.
Das kann je nachdem was du da tatsächlich an Hardware schaltest auch normal sein, z.B. bei einfachen Funksteckdosen mit einem oder mehreren Handsendern. Da bekommen die Handsender keine Rückmeldung ob der Schaltbefehl ausgeführt wurde und wie der momentane Schaltzustand gerade ist. Dann kann man nur hoffen dass der Schaltbefehl ausgeführt wurde. Für diesen Fall gibt es in HA den optimistic mode. in der configuration.yaml ergänzt Du dann entweder ein
optimistic: true
oder Du lässt state_topic, state_on, state_off ganz weg, dann ist der Schalter sowieso im optimistic mode. Evtl. solltest du aus dem Schalter dann aber einen Taster machen ("Umschalten").



Offline jensorium

  • New Member
  • *
  • Beiträge: 10
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #41 am: 21 Februar 2021, 21:26:16 »
Hey

Danke für die Antwort

list schrank:
Internals:
   FUUID      5cb511dd-f33f-6e90-c8b3-12a1d7e089e26541
   LASTInputDev ha_MQTT2
   MSGCNT     7
   NAME       schrank
   NR         50
   STATE      on
   TYPE       dummy
   ha_MQTT2_MSGCNT 7
   ha_MQTT2_TIME 2021-02-21 14:27:25
   READINGS:
     2021-02-21 14:27:25   state           on
Attributes:
   alias      schrank
   mqttSubscribe state:stopic={"$base/set"}
   room       HASS,licht,wz
   setList    on off
   userattr   lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0 mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long room_map structexclude

Der Schaltet ja einen Dummy und dieser dummy ist ja auch an oder aus, sollte der dann nicht seinen status zurück geben? Und es sind 433er Steckdosen ohne Rückkanal, aber der Schaltzustand sollte doch in HA und Fhem gleich angezeigt werden?

Wenn ich in fhem schalte sagt der Explorer mir state on und off,
wenn ich in HA schalte sagt er mir set on und off und der Status bleibt, schaltet aber
Dies bleibt auch wen ich den optimistic rein gemacht habe oder alles gelöscht.

Ich glaub ich besorg mir besser par zigbee Dosen und gut, dann hab ich die Fehlerquelle MQTT hin und her weniger :(

Offline gadget

  • Full Member
  • ***
  • Beiträge: 275
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #42 am: 22 Februar 2021, 02:58:55 »
Ich glaube das liegt am fehlenden mqttforward all bei deinem schrank-dummy.

Aus der Doku:

mqttForward
Dieses Attribut definiert was passiert, wenn eine und dasselbe Reading sowohl aboniert als auch gepublisht wird. Mögliche Werte: 'all' und 'none'.
Bei 'none' werden per MQTT angekommene Nachrichten nicht aus dem selben Gerät per MQTT weiter gesendet.
Die Einstellung 'all' bewirkt das Gegenteil, also damit wird das Weiterleiten ermöglicht.
Fehlt dieser Attribut, dann wird standardmäßig für alle Gerätetypen außer 'Dummy' die Einstellung 'all' angenommen (damit können Aktoren Befehle empfangen und ihre Änderungen im gleichem Zug weiter senden) und für Dummies wird 'none' verwendet. Das wurde so gewählt, da dummy von vielen Usern als eine Art GUI-Schalterelement verwendet werden. 'none' verhindert hier unter Umständen das Entstehen einer Endlosschleife der Nachrichten.


Wenn du das  Attribut nicht setzen kannst musst Du evtl. mal dein fhem updaten.

Grüße, gadget


Offline jensorium

  • New Member
  • *
  • Beiträge: 10
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #43 am: 22 Februar 2021, 06:33:35 »
Hey

Über update sagt der mir es sei nichts zu tun...

Gruß

Offline jensorium

  • New Member
  • *
  • Beiträge: 10
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #44 am: 22 Februar 2021, 06:52:52 »
Hey. Unter userattribute on Schrank ist er auch drin. Wie auch bei anderen Usern so gesehen grade.


attr mqttGeneric mttqForward all

Hier steht mttq und nicht mqtt aber so oder so nimmt er das nicht.
Gruß

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15768
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #45 am: 22 Februar 2021, 07:36:09 »
Hey. Unter userattribute on Schrank ist er auch drin. Wie auch bei anderen Usern so gesehen grade.


attr mqttGeneric mttqForward all

Hier steht mttq und nicht mqtt aber so oder so nimmt er das nicht.
Gruß
Warum gehst du mit den Attributen so frei um, versuchst aber nicht das, was in der commandref steht, nämlich das Attribut da zu setzen, wo es vorhanden ist: Am zu überwachenden/steuernden Gerät... Wurde doch hier schon geschrieben (ohne Hervorhebung)
Ich glaube das liegt am fehlenden mqttforward all bei deinem schrank-dummy.

Ich glaub ich besorg mir besser par zigbee Dosen und gut, dann hab ich die Fehlerquelle MQTT hin und her weniger :(
Funk ohne Rückkanal ist nicht mehr zeitgemäß, und ein Teil der Probleme kommt auch daher, dass du irgendeine PI-GPIO-Lösung zu nutzen scheinst, die für sich genommen schon schwierig ist. Frage mich, warum du eingangs  einen NanoCUL erwähnt hattest. Wären das "normale IT-Geräte" (InterTechno-Protokoll via CUL) gewesen, wäre der Hackel vermutlich gar nicht erst entstanden.
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline hckoe

  • Full Member
  • ***
  • Beiträge: 124
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #46 am: 22 Februar 2021, 11:05:04 »
Hast Du ein globales mqttPublish in der MGB definiert, denn im Device selbst ist ja keines? Der mqttPublish wird benötigt, daß der Status an HA gesendet wird.
# CT mit Debian Buster / FHEM aktuell / EnOcean TCM310 / Eltako FSA12, FUD12NPN, FSB12, FRW, FSRP-230V
# Permundo PCS234, Nodon NO-SIN-2-2-00, GTAGS

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15768
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #47 am: 22 Februar 2021, 11:10:56 »
Hast Du ein globales mqttPublish in der MGB definiert, denn im Device selbst ist ja keines? Der mqttPublish wird benötigt, daß der Status an HA gesendet wird.
Guter Hinweis!

@jensorium: Bitte aber KEIN globales publish angeben, (auch) das sollte mAn. immer am Device (=> "schrank") konfiguriert werden...
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline jensorium

  • New Member
  • *
  • Beiträge: 10
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #48 am: 22 Februar 2021, 11:39:45 »
Hey Beta User,

erstmal Danke.
Da du vollkommen recht hast mit nicht mehr Zeitgemäß hab ich mir nun Zigbee sachen bestellt.

Dennoch versuche ich zu verstehen:

Besagte Zeile habe ich aus dem 2. Beitrag, hier war mir gestern der vermeintliche Typo aufgefallen, der aber keine Besserung brachte, auch mit ? und google finde ich leider nichts zu mqttForward oder mttqForward.

Ich habe geschaut und es ist im dummy schrank vorhanden, wie in der Liste zu sehen von gestern abend. Da ist es also drin, weiß nicht wo ich dann frei damit umgehe? Habe nun unter userattr und auch unter Attribute mgttForward drin. Bei Schrank.

Ja ich hab da eine GPIO lösung genutzt, das war so gewachsen, da ich dann das Intertechno System bekam und nen Nanocul bin ich mit dem Intertechno darüber gegegangen.

Jetzt versteh ich grad noch weniger:
Schrank und demoswitch machen state und set nun richtig (ON OFF), hier hab ich das GPIO Modul aber abgeklemmt, denke aber die würden schalten.

Mein WZ IT macht wenn ich es aus FHEM schalte state on off, wenn ich aus HA schalte set ON OFF aber es ändert sich nicht :(
Hier habe ich aber keinen Dummy genutzt

defmod wz IT 00111100010000111101111110 0 0000
attr wz userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0 mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long room_map structexclude
attr wz IODev traxCUL
attr wz mqttForward all
attr wz mqttSubscribe state:stopic={"$base/set"}
attr wz room GoogleAssistant,HASS,IT,wz
attr wz webCmd on:off

setstate wz off
setstate wz 2019-04-15 00:26:11 group 0
setstate wz 2019-04-15 00:26:11 protocol V3
setstate wz 2021-02-22 11:18:54 state off
setstate wz 2019-04-15 00:26:11 unit 0000


Wieso kann ich das WZ nicht so steuern?


Gruß
Jens




Offline jensorium

  • New Member
  • *
  • Beiträge: 10
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #49 am: 22 Februar 2021, 11:41:14 »
Guter Hinweis!

@jensorium: Bitte aber KEIN globales publish angeben, (auch) das sollte mAn. immer am Device (=> "schrank") konfiguriert werden...

Danke ihr zwei,

doch ich hatte ein Globales publisch in der mqttGeneric, hab das aus dem Beitrag oben so genommen:

globalPublish *:topic={"fhem/$device/$reading"}

Gruß

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15768
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #50 am: 22 Februar 2021, 12:04:25 »
Danke ihr zwei,

doch ich hatte ein Globales publisch in der mqttGeneric, hab das aus dem Beitrag oben so genommen:

globalPublish *:topic={"fhem/$device/$reading"}

Gruß
Dann wirf es raus und mach die (eingeschränkten!) Publishes nur an die Devices, die du auch extern brauchst. Wie oft muss man denn schreiben, dass es Unsinn ist, ALLES in die Welt zu pusten...?
Meine Empfehlung ist, an der Bridge nur globalDefaults zu setzen, siehe dazu das attrTemplate "base_settings_to_MQTT_GENERIC_BRIDGE"
Vermutlich brauchst du für state@wz auch ein passendes publish, damit das an den richtigen Topic geht. Leider ist es bei diesen ganzen Bruchstücken, die du lieferst überhaupt nicht nachvollziehbar, was du wie gesetzt hast...
Jedenfalls ist "all" für alles, was nicht dummy ist der default für "mqttForward" (=> man braucht es nur da!).
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline jensorium

  • New Member
  • *
  • Beiträge: 10
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #51 am: 22 Februar 2021, 12:14:23 »
Hey Beta User,

ich versuche mal überblick zu schaffen, was brauchst du sonst noch?

Meine wz:
last Input device ist angeblich mgtt, aber ohne funktion
defmod wz IT 00111100010000111101111110 0 0000
attr wz userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0 mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long room_map structexclude
attr wz IODev traxCUL
attr wz mqttForward all
attr wz mqttSubscribe state:stopic={"$base/set"}
attr wz room GoogleAssistant,HASS,IT,wz
attr wz webCmd on:off

setstate wz off
setstate wz 2019-04-15 00:26:11 group 0
setstate wz 2019-04-15 00:26:11 protocol V3
setstate wz 2021-02-22 11:57:16 state off
setstate wz 2019-04-15 00:26:11 unit 0000


mein Client:
defmod ha_MQTT2 MQTT2_CLIENT 192.168.178.57:1883
attr ha_MQTT2 alias ha_MQTT2
attr ha_MQTT2 clientId fhem
attr ha_MQTT2 keepaliveTimeout 60
attr ha_MQTT2 msgAfterConnect -r fhem/connection/status connected
attr ha_MQTT2 msgBeforeDisconnect -r fhem/connection/status disconnected
attr ha_MQTT2 qosMaxQueueLength 100
attr ha_MQTT2 room MQTT
attr ha_MQTT2 username hamqtt

setstate ha_MQTT2 opened
setstate ha_MQTT2 2021-02-22 11:48:33 state opened

meine bridge:
defmod mqttGeneric MQTT_GENERIC_BRIDGE mqtt room=HASS
attr mqttGeneric IODev ha_MQTT2
attr mqttGeneric alias mqttGeneric
attr mqttGeneric globalDefaults sub:qos=2 pub:qos=0 retain=1 base={"fhem/$device"}
attr mqttGeneric globalPublish *:topic={"fhem/$device/$reading"}
attr mqttGeneric icon mqtt_bridge_2
attr mqttGeneric room MQTT
attr mqttGeneric stateFormat in: incoming-count out: outgoing-count devices: device-count
attr mqttGeneric verbose 0

setstate mqttGeneric in: 103 out: 93 devices: 3
setstate mqttGeneric 2021-02-22 11:48:33 device-count 3
setstate mqttGeneric 2021-02-22 11:59:04 incoming-count 103
setstate mqttGeneric 2021-02-22 11:57:16 outgoing-count 93
setstate mqttGeneric 2021-02-22 11:57:16 transmission-state outgoing publish sent
setstate mqttGeneric 2021-02-22 11:16:59 updated-reading-count 0
setstate mqttGeneric 2021-02-22 11:49:48 updated-set-count 81



Ich hab das Global publish jetzt ertsmal drin gelassen, werde das dann raus nehmen wenn ich es verstanden habe ;(

DANKE

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15768
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #52 am: 22 Februar 2021, 12:41:49 »
Also:
"globalPublish" und "mqttPublish" am einzelnen Device bewirken dasselbe, nur eben für einen anderen "Wirkungskreis". Hier hast du das zwar schon durch die devspec begrenzt (ausdrückliches Lob!) , aber trotzdem: Wenn du erst anfängst, kannst du es gefahrlos löschen und dann durch gezielte publishes ersetzen! Sonst läufst du ständig Gefahr, eine "Kleinigkeit" an der falschen Stelle zu ändern mit entsprechenden Auswirkungen...

Erst mal das, was an sinnvollen Änderungen am Client wäre:
attr ha_MQTT2 clientOrder MQTT_GENERIC_BRIDGE
attr ha_MQTT2 subscriptions setByTheProgram
Das erste spart den Durchlauf durch MQTT2_DEVICE (das solltest du ggf. (hinten) ergänzen, falls (!) du "normale" MQTT-Geräte in FHEM haben willst/musst);
das zweite bewirkt, dass M2_CLIENT nur auf das hört, auf was den abbonierten Topics passiert (@all: das war bisher auch unter meinem Radar geflogen, kommt ins attrTemplate noch rein...).

Dann würde ich MGB so konfigurieren:
attr mqttGeneric globalDefaults pub:base={"fhem/$device"} sub:base={"fhem/set/$device"}
deleteattr mqttGeneric globalPublish
"retain" bewirkt teils seltsame Effekte, wenn FHEM oder der mosquitto neu gestartet werden (=> sollte nur aktivieren, wer weiß, was er tut!), und QOS ist bei "normalen TCP/IP-Verbindungen" sowieso durch features dieses Layers überlagert, wenn ich Rudi da richtig verstanden habe.
Damit hast du in Sende- und Empfangsrichtungen bei allen Geräten unterschiedliche Topics, und kannst dann dein eigentliches Gerät so konfigurieren:
attr wz mqttSubscribe state:stopic=$base
attr wz mqttPublish state:topic=$base
deleteattr wz mqttForward

Du musst dann halt noch checken, ob die subscription auf der Gegenseite dann noch dazu paßt.
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline hckoe

  • Full Member
  • ***
  • Beiträge: 124
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #53 am: 22 Februar 2021, 13:27:43 »
@Beta-User: Ist "$device" in den "globalDefaults xxx:base=" aktuell die Empfehlung. Im Thread über attrTemplate wurde das unterschiedlich diskutiert.   
# CT mit Debian Buster / FHEM aktuell / EnOcean TCM310 / Eltako FSA12, FUD12NPN, FSB12, FRW, FSRP-230V
# Permundo PCS234, Nodon NO-SIN-2-2-00, GTAGS

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15768
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #54 am: 22 Februar 2021, 13:41:56 »
Danke für den Hinweis, nein, ist es nicht (mehr) :o ...

Müßte dann also so aussehen
attr mqttGeneric globalDefaults pub:base=fhem sub:base=fhem/set
deleteattr mqttGeneric globalPublish

attr wz mqttSubscribe state:stopic={"$base/$device"}
attr wz mqttPublish state:topic={"$base/$device"}
« Letzte Änderung: 22 Februar 2021, 14:00:26 von Beta-User »
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline jensorium

  • New Member
  • *
  • Beiträge: 10
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #55 am: 22 Februar 2021, 13:57:09 »
Hey

danke für die Inputs.

hier ist beides mal topic oder?
attr wz mqttSubscribe state:stopic=$base
attr wz mqttPublish state:topic=$base
deleteattr wz mqttForward
ändert aber nichts auch ohne S

ich fhem gibt keinen Output mehr und reagiert auch nicht auf die set befehle

probiert: hab in HA  geändert:
    command_topic: "fhem/set/wz"


daher hatte ich in deinem "sub:base={"fhem/set/$device"}"  das set nach hinten verschoben, ohne erfolg

Danke

Gruß

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15768
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #56 am: 22 Februar 2021, 14:01:38 »
Da war mir beim editieren noch eine Klammer durchgerutscht, hoffe, das hattest du bemerkt:
attr mqttGeneric globalDefaults pub:base=fhem sub:base=fhem/set
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline jensorium

  • New Member
  • *
  • Beiträge: 10
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #57 am: 22 Februar 2021, 14:20:32 »
Hey

gesehen ja, gewundert, dachte aber es gehört so, Änderung brachte aber keinen Erfolg

Offline hckoe

  • Full Member
  • ***
  • Beiträge: 124
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #58 am: 22 Februar 2021, 14:55:42 »
stopic für Subscribe-Topic ist schon richtig!
Wenn Du es nach Anleitung von Beta-User gemacht hast, müssest Du jetzt auf HA ein command-Topic: fhem/set/wz und ein state-Topic: fhem/wz definiert haben.
Auf FHEM-Seite ein Publish auf fhem/wz und ein Subscribe auf fhem/set/wz. Dann könntest Du mit mosquitto_sub ein subscribe auf diese beiden Topics machen und schauen, wie die Kommunikation jetzt verläuft, wenn Du auf beiden Seiten schaltest.
# CT mit Debian Buster / FHEM aktuell / EnOcean TCM310 / Eltako FSA12, FUD12NPN, FSB12, FRW, FSRP-230V
# Permundo PCS234, Nodon NO-SIN-2-2-00, GTAGS

Offline gadget

  • Full Member
  • ***
  • Beiträge: 275
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #59 am: 23 Februar 2021, 02:32:17 »
Mea culpa, ich sehe gerade, dass ich im Januar beim überarbeiten von Post #2 in diesem Thread einen sinn-entstellenden Fehler reingebaut habe bzgl. mqttForward. Hab es gerade nochmal überarbeitet. Das gehört natürlich zum dummy-device und nicht zur MGB. Das dürfte die Verwirrung in den letzten Posts erklären.
« Letzte Änderung: 23 Februar 2021, 02:36:30 von gadget »

Offline daim21

  • New Member
  • *
  • Beiträge: 12
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #60 am: 06 April 2021, 14:30:26 »
Hallo zusammen,

erst einmal vielen für die sehr ausführliche und gut strukturierte Anleitung bestehende Fhem Switche über MQTT mit Home Assistant verbinden.
Das hat wunderbar funktioniert.

Nun wollte ich noch meine Temperatur und Luftfeuchtigkeits Sensonsoren verbinden, jedoch bisher ohne Erfolg.
Die Sensoren zeigen 0°C bzw. 0% an.  :-[


Sensor in FHEM:
IODev
deCONZ

event-min-interval
30

group
Temperaturen

icon
temp_temperature

model
TS0201

mqttForward
all

mqttPublish
*:topic={"$base/$device/temperature"}

mqttSubscribe
state:stopic={"fhem/Balkon.Sensor.temp/temperature"} 

room
Balkon,HASS,Sensoren

stateFormat
temperature C°

userattr
mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long structexclude

Habe unter "mqttSubscribe" und "mqttPublish" verschiedene Varianten probiert (z.B. $base/$device). Alles ohne Erfolg. Ich vermute das hier mein Fehler liegt. :(

Sensor in HA:
- platform: mqtt
  name: "BalkonTemperature"
  state_topic: "fhem/Balkon.Sensor.temp/temperature"
  device_class: "temperature"
  unit_of_measurement: "°C"
  value_template: "{{ value_json.temperature }}"
  force_update: "true"

Hat vielleicht jemand einen wertvollen Tipp für mich?  :)


Vielen Dank und Grüße
Daim21

Offline gadget

  • Full Member
  • ***
  • Beiträge: 275
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #61 am: 06 April 2021, 14:39:32 »
Hi,

verwende bitte code Tags (der "Gartenzaun" im Editor)  sonst ist das nicht leserlich und dann bitte bei deinem Sensor auf Raw definition gehen und alles von defmod bis zum Ende der attr Zeilen einfügen.

Was mir auffällt: Wieso state:stopic={"fhem/Balkon.Sensor.temp/temperature"} ? Du willst die Temperatur doch vermutlich nicht von Home Assistant aus senden ?

Wenn Du dem Beispiel gefolgt bist, müsstest Du den Sensor zudem noch in den HASS - Raum aufnehmen.

Kommt auf dem mqtt-Broker überhaupt was von dem Sensor an ? Bitte auf Kommandozeilenebene prüfen mit mosquitto_sub  oder bequem mit MQTT Explorer.

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15768
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #62 am: 06 April 2021, 14:41:34 »
zusätzlich:
a) FHEM / MQTT_GENERIC_BRIDGE ist aktuell?
b) mqttForward und mqttSubscribe sind hier m.E. unnötig, du willst ja nur was publishen (das sieht mir nach einer Schleife aus!)
c) mqttPublish sollte entweder vollständig auf "wildcard" sein, oder nur auf Temperatur. Würde letzteres empfehlen:
temperature:topic={"$base/$device/temperature"}
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline gadget

  • Full Member
  • ***
  • Beiträge: 275
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #63 am: 06 April 2021, 14:46:03 »
... und das value_template sieht auch komisch aus. Du sendest ja vermutlich nur einen numerischen Wert und kein json.

bei mir sieht ein von fhem versorgter Temperatur-Sensor in der configuration.yaml so aus:

sensor:
  - platform: mqtt
    name: "Temp Carport"
    state_topic: "fhem/LaCrosse_22/temperature"
    unit_of_measurement: "°C"
    icon: mdi:thermometer
    value_template: '{{ value | round(1) }}'
    expire_after: 4000
    availability_topic: "fhem/connection/status"
    payload_available: "connected"
    payload_not_available: "disconnected"

Und das event-min-interval passt auch nicht. Da muss das reading mit rein, also z.b. so:

attr Balkon.Sensor.temp event-min-interval temperature:30
« Letzte Änderung: 06 April 2021, 14:52:57 von gadget »

Offline daim21

  • New Member
  • *
  • Beiträge: 12
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #64 am: 06 April 2021, 16:00:42 »
Ok vielen Dank für euren input.

Habe jetzt in Fhem und HA entsprechend angepasst, jedoch erhalte ich nun zwar 0°C mehr sondern einen weiteren Fehlerhaften Wert. In diesem Fall wird mir angezeigt das 23°C auf dem Balkon sind. Was ja heute leider nicht stimmt. :)

Attributes
IODev
deCONZ

alexaName
Temperatur Balkon

event-min-interval
temperature:10

group
Temperaturen

icon
temp_temperature

model
TS0201

mqttPublish
temperature:topic={"$base/$device/temperature"}

room
Balkon,HASS,Sensoren,alexa

stateFormat
temperature C°

userattr
mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long structexclude

IN HA
- platform: mqtt
  name: "BalkonTemperature"
  state_topic: "fhem/Balkon.Sensor.temp/temperature"
  unit_of_measurement: "°C"
  icon: mdi:thermometer
  value_template: '{{ value | round(1) }}'
  expire_after: 4000
  availability_topic: "fhem/connection/status"
  payload_available: "connected"
  payload_not_available: "disconnected"

Zu der Frage "a) FHEM / MQTT_GENERIC_BRIDGE ist aktuell?"
Was meinst du damit genau?

Soll ich mal die Config von der Bridge und dem mqtt device hier posten?

Danke Euch

Offline gadget

  • Full Member
  • ***
  • Beiträge: 275
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #65 am: 06 April 2021, 16:12:52 »

Zu der Frage "a) FHEM / MQTT_GENERIC_BRIDGE ist aktuell?"
Was meinst du damit genau?

Geh bitte zu deiner Bridge und mach da ein get version

Da sollte dann z.B. so was rauskommen:

version 1.3.3 by hexenmeister
$Id: 10_MQTT_GENERIC_BRIDGE.pm 23753 2021-02-16 22:03:34Z hexenmeister $

Ansonsten bitte bei deinem Temperatur Device in fhem ganz unten auf "raw definition" klicken. Da geht dann eine Box auf mit der Definition wie sie in der fhem.cfg steht. Und davon dann bitte alles bis zu den setstate-Zeilen kopieren und hier in einem code-Block einfügen.

Und schau bitte nach was auf dem mqtt Broker ankommt.


Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15768
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #66 am: 06 April 2021, 16:15:00 »
Es sollte was deutlich aktuelleres bei der Versionsanfrage rauskommen, es gab ein Problem, wenn man keine Attribute in der MGB selbst gesetzt hatte (dann sollte aber gar nichts ankommen).
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline daim21

  • New Member
  • *
  • Beiträge: 12
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #67 am: 06 April 2021, 16:19:50 »
Das ist der Output.

version 1.4.0 by hexenmeister
$Id: 10_MQTT_GENERIC_BRIDGE.pm 24029 2021-03-21 01:43:41Z hexenmeister $


Das sind die Attribute
Attributes
IODev
ha_MQTT2
deleteattr
event-aggregator
state
deleteattr
globalDefaults
sub:qos=2 pub:qos=0 retain=1 base={"fhem/$device"}
deleteattr
globalPublish
*:topic={"fhem/$device/$reading"}
deleteattr
icon
mqtt_bridge_2
deleteattr
room
MQTT
deleteattr
stateFormat
in: incoming-count out: outgoing-count devices: device-count
deleteattr
verbose
0
deleteattr



Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15768
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #68 am: 06 April 2021, 16:23:17 »
Bitte updaten.

Und möglichst gleich direkt in der MGB "$base" in Sende- und Empfangsrichtigung unterschiedlich setzen.

Dass globalPublish in der Kategorie "not recommended" ist, ist dir auch entgangen, nehme ich an? (Das ist dann auch doppelt zu den Einstellungen am Gerät! Würde empfehlen, es an der Bridge zu löschen.)
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline daim21

  • New Member
  • *
  • Beiträge: 12
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #69 am: 06 April 2021, 16:38:50 »
Zitat
Bitte updaten.
Habe ich

Das ist nun der output
version 1.4.1 by hexenmeister
$Id: 10_MQTT_GENERIC_BRIDGE.pm 24088 2021-03-25 20:53:02Z hexenmeister $



Zitat
Und möglichst gleich direkt in der MGB "$base" in Sende- und Empfangsrichtigung unterschiedlich setzen.
Hier bin ich nicht sicher was du genau meinst

[quoteDass globalPublish in der Kategorie "not recommended" ist, ist dir auch entgangen, nehme ich an? (Das ist dann auch doppelt zu den Einstellungen am Gerät! Würde empfehlen, es an der Bridge zu löschen.)][/quote]
Habe ich entfernt.


Das sind nun die MGB Attr bzw readings
Readings
device-count
26
2021-04-06 16:23:29
incoming-count
1
2021-04-06 16:23:44
outgoing-count
9
2021-04-06 16:35:18
transmission-state
outgoing publish sent
2021-04-06 16:35:18
updated-reading-count
0
2021-04-06 16:23:18
updated-set-count
1
2021-04-06 16:23:44
 mqttGeneric
room
MQTT

IODev
ha_MQTT2

event-aggregator
state

globalDefaults
sub:qos=2 pub:qos=0 retain=1 base={"fhem/$device"}

icon
mqtt_bridge_2

room
MQTT

stateFormat
in: incoming-count out: outgoing-count devices: device-count

verbose
0

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15768
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #70 am: 06 April 2021, 16:47:41 »
Hier bin ich nicht sicher was du genau meinst
Bei mir sieht das z.B. so aus:globalDefaults sub:base=MGB1/set pub:base=MGB1Damit ist "$base" in Sende- und Empfangsrichtung unterschiedlich vorbelegt.

"retain=1" ist auch zweischneidig, fällt nach meiner persönlichen Meinung auch in "not recommended", kommt aber darauf an, wie das Gesamtsystem aufgebaut ist.
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline daim21

  • New Member
  • *
  • Beiträge: 12
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #71 am: 06 April 2021, 16:59:23 »
globalDefaults sub:base=fhem/set pub:base=fhem
Habe das jetzt so bei mir eingegeben.

Erhalte weiterhin seltsame Werte.  :-\

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15768
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #72 am: 06 April 2021, 17:13:24 »
Das glaube ich gerne. Du musst dann die Einstellungen an den zu versendenden Geräten auch entsprechend anpassen, da in $base dann $device nicht mehr enthalten ist. Das muss dann überall so sein wie an dem Sensor:
mqttPublish temperature:topic={"$base/$device/temperature"}oder (falls aliasing im Spiel ist)
mqttPublish temperature:topic={"$base/$device/$name"}
Ansonsten ist "seltsame Werte" eine schwierig zu interpretierende Aussage. Würde empfehlen, einen "seltsamen Wert" rauszupicken und dann mal dessen "Pfaden" zu folgen.
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline gadget

  • Full Member
  • ***
  • Beiträge: 275
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #73 am: 06 April 2021, 18:07:29 »
Erhalte weiterhin seltsame Werte.  :-\

Ich bin raus, so lange Du nicht mal nachschaust was auf dem Broker ankommt und per "Raw Definition" die Definition deines Temperatur-Sensors mitteilst.

Offline daim21

  • New Member
  • *
  • Beiträge: 12
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #74 am: 06 April 2021, 21:36:59 »
Du hast recht. Ich werde morgen mal "mosquitto_pub" und "mosquitto_sub" output von dem Balkon Temp Sensor posten. Ich hatte zwischenzeitlich sogar die korrekten Werte in HA stehen.  :)
Für heute reichts mir auch.

Offline daim21

  • New Member
  • *
  • Beiträge: 12
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #75 am: 07 April 2021, 11:28:13 »
So ich habe nun über msquitto zwei Sensoren und ein Switch aufgenommen.

pi@fhem:~ $ mosquitto_sub -h 192.168.178.72 -u hamqtt -P <password> -t 'fhem/Balkon.Sensor.temp/temperature'
23.1
Temperatur auf dem Display und Fhem ist 3.7

pi@fhem:~ $ mosquitto_sub -h 192.168.178.72 -u hamqtt -P <password> -t 'fhem/KZ.Sensor.temp/temperature'
100
Temperatur auf dem Sensor Display und Fhem ist 20.8

Und wenn ich nun ein Switch schalten will passiert folgendes.
pi@fhem:~ $ mosquitto_sub -h 192.168.178.72 -u hamqtt -P <password> -t 'fhem/PCLicht/state'
on
off

Schalte ich das Switch "PCLicht" aus Fhem heraus erhalte ich on off schalte ich jedoch aus HA das Switch dann sehe ich kein "on off" über mosquitto und das Switch geht nicht an und aus.

So sehen die Devices nun bei mir aus
MQTT Bridge
define mqttGeneric MQTT_GENERIC_BRIDGE mqtt room=HASS
attr mqttGeneric IODev ha_MQTT2
attr mqttGeneric event-aggregator state,temperature,humidity
attr mqttGeneric globalDefaults sub:base=fhem/set pub:base=fhem
attr mqttGeneric icon mqtt_bridge_2
attr mqttGeneric room MQTT
attr mqttGeneric stateFormat in: incoming-count out: outgoing-count devices: device-count
attr mqttGeneric verbose 0

Sensor in Fhem
define Balkon.Sensor.temp HUEDevice sensor 6  IODev=deCONZ
attr Balkon.Sensor.temp userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long structexclude
attr Balkon.Sensor.temp IODev deCONZ
attr Balkon.Sensor.temp alexaName Temperatur Balkon
attr Balkon.Sensor.temp event-min-interval temperature:30
attr Balkon.Sensor.temp group Temperaturen
attr Balkon.Sensor.temp icon temp_temperature
attr Balkon.Sensor.temp model TS0201
attr Balkon.Sensor.temp mqttPublish temperature:topic={"$base/$device/temperature"}
attr Balkon.Sensor.temp room Balkon,HASS,Sensoren,alexa
attr Balkon.Sensor.temp stateFormat temperature C°

Sensor in HA
- platform: mqtt
  name: "BalkonTemperature"
  state_topic: "fhem/Balkon.Sensor.temp/temperature"
  unit_of_measurement: "°C"
  icon: mdi:thermometer
  value_template: '{{ value | round(1) }}'
  expire_after: 4000
  availability_topic: "fhem/connection/status"
  payload_available: "connected"
  payload_not_available: "disconnected"

Switch in Fhem
define PCLicht dummy
attr PCLicht userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long structexclude
attr PCLicht alexaName Pc Licht
attr PCLicht alexaRoom alexa
attr PCLicht devStateIcon an:li_wht_on aus:li_wht_off
attr PCLicht eventMap on:an off:aus
attr PCLicht genericDeviceType switch
attr PCLicht group Beleuchtung
attr PCLicht icon light_office_desk
attr PCLicht mqttForward all
attr PCLicht mqttPublish *:topic={"$base/$device/$name"}
attr PCLicht mqttSubscribe state:stopic={"$base/set"}
attr PCLicht room Arbeitszimmer,HASS,alexa
attr PCLicht setList on off
attr PCLicht webCmd on:off

Switch in HA
- platform: mqtt
  name: PCLicht
  command_topic: "fhem/PCLicht/set"
  payload_on: "on"
  payload_off: "off"
  availability_topic: "fhem/connection/status"
  payload_available: "connected"
  payload_not_available: "disconnected"

Habt ihr eine Idee was ich ändern muss am sub bzw am pub?

Vielen Dank im Vorraus

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15768
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #76 am: 07 April 2021, 11:42:01 »
Die Pfade sollten in FHEM und HASS zusammenpassen, tun sie aber nicht:
attr PCLicht mqttSubscribe state:stopic={"$base/set"}
command_topic: "fhem/PCLicht/set"

Versuch's mal so:
attr PCLicht mqttSubscribe state:stopic={"$base/$device"}
command_topic: "fhem/set/PCLicht"
Außerdem würde ich erst mal ohne eventMap testen, (falls es nicht funktioniert).


Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline daim21

  • New Member
  • *
  • Beiträge: 12
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #77 am: 07 April 2021, 12:35:23 »
Also nach der Anpassung:
in Fhem
attr PCLicht mqttSubscribe state:stopic={"$base/$device"}in HA
command_topic: "fhem/set/PCLicht"Ich Kann ddas Switch über HA schalten und state ändert sich in Fhem und HA.
Schalte ich über Fhem ändert sich state nur in Fhem.
Beim schalten über HA wird folgendes aufgelistet.
pi@fhem:~ $  mosquitto_sub -h 192.168.178.72 -u hamqtt -P <password> -t 'fhem/PCLicht/state'
on
off
on
off
on
Das entfernen von:
attr eventMap on:an off:aushat keine Auswirkungen.

Was die Sensoren angeht bin ich ratlos, vorallem da mir der Sensor Balkon gestern kurzzeitig die korrekte Temperatur angezeigt hat.

Hast du eine Idee?

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15768
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #78 am: 07 April 2021, 12:56:50 »
Hmm,

da scheint mir auf der HASS-Seite noch was zu fehlen:
state_topic: "fhem/PCLicht"
Was den Sensor angeht, bin ich erst mal ratlos, ich würde empfehlen, den MQTT-Verkehr mal etwas detaillierter mitzulesen. Sollte so gehen:
mosquitto_sub -h 192.168.178.72 -u hamqtt -P <password> -t 'fhem/#' -v(Wegen -v für verbose = zeige auch den Topic an müßte ich in die manpage schauen; => bitte selbst verifizieren)

Vermute, dass da schlicht zu selten was gesendet wird oder sonst ein Problem in FHEM/HUEBridge vorliegt.
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline daim21

  • New Member
  • *
  • Beiträge: 12
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #79 am: 07 April 2021, 14:31:28 »
Nachdem ich nun in HA
state_topic: "fhem/PCLicht"gesetzt habe.
Und über HA das Switch schalte, spring state sofort wieder auf "off".

Hier hat nur das geholfen. Wie früher beschrieben.
Zitat
Wenn der Schalter hin HA wieder zurück springt, liegt das i.d.R. daran, dass du auf dem .../state keine Rückmeldung über den Schaltvorgang bekommst, der über .../set ausgelöst wurde.
Das kann je nachdem was du da tatsächlich an Hardware schaltest auch normal sein, z.B. bei einfachen Funksteckdosen mit einem oder mehreren Handsendern. Da bekommen die Handsender keine Rückmeldung ob der Schaltbefehl ausgeführt wurde und wie der momentane Schaltzustand gerade ist. Dann kann man nur hoffen dass der Schaltbefehl ausgeführt wurde. Für diesen Fall gibt es in HA den optimistic mode. in der configuration.yaml ergänzt Du dann entweder ein
optimistic: true

Was die Sensoren angeht habe ich langsam auch die Vermutung das die Sensoren zu selten Daten übermitteln.

Das habe ich mitgelesen
pi@fhem:~ $ mosquitto_sub -h 192.168.178.72 -u hamqtt -P <password> -t 'fhem/#' -v
fhem/connection/status connected
fhem/Balkon.Sensor.temp/temperature 23.1
fhem/Balkon.Sensor.temp/battery 10
fhem/Balkon.Sensor.temp/reachable 1
fhem/Balkon.Sensor.temp/batteryPercent 10
fhem/Balkon.Sensor.temp/Balkon.Sensor.temp/reachable 1
fhem/Balkon.Sensor.temp/Balkon.Sensor.temp/battery 30
fhem/Balkon.Sensor.temp/Balkon.Sensor.temp/batteryPercent 30
fhem/Balkon.Sensor.temp/Balkon.Sensor.temp/temperature 6.2
fhem/Balkon.Sensor.hum/humidity 59.4
fhem/Balkon.Sensor.hum/batteryPercent 30
fhem/Balkon.Sensor.hum/reachable 1
fhem/Balkon.Sensor.hum/battery 30
fhem/Balkon.Sensor.hum/Balkon.Sensor.hum/state 10
fhem/Balkon.Sensor.hum/Balkon.Sensor.hum/humidity 67.6
fhem/PCLicht/PCLicht/state on
fhem/PCLicht/set on
fhem/KZ.Sensor.hum/humidity 41.2
fhem/KZ.Sensor.hum/KZ.Sensor.hum 41.2
fhem/KZ.Sensor.hum/KZ.Sensor.hum/humidity 100
fhem/KZ.Sensor.temp/KZ.Sensor.temp/temperature 100
fhem/KZ.Sensor.temp/KZ.Sensor.temp/reachable 1
fhem/KZ.Sensor.temp/KZ.Sensor.temp/batteryPercent 100
fhem/KZ.Sensor.temp/KZ.Sensor.temp/battery 100
fhem/KZ.Sensor.temp/temperature 100
fhem/SZ.Sensor.hum/SZ.Sensor.hum/reachable 1
fhem/SZ.Sensor.hum/SZ.Sensor.hum/battery 100
fhem/SZ.Sensor.hum/SZ.Sensor.hum/batteryPercent 100
fhem/SZ.Sensor.temp/SZ.Sensor.temp/battery 100
fhem/SZ.Sensor.temp/SZ.Sensor.temp/reachable 1
fhem/SZ.Sensor.temp/SZ.Sensor.temp/batteryPercent 100

Mich wundert auch das der z.B. der Batterie Status da auftaucht. Sollte eigentlich nicht oder?

Werde im nächsten Schritt mal den Phoscon Stick updaten.

Vielleicht fällt dir noch etwas auf was ich nicht bedenke bzw. nicht sehe.

Danke nochmal. :)


Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15768
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #80 am: 07 April 2021, 14:47:20 »
Bei dem dummy war aber doch weiter
attr PCLicht mqttForward allgesetzt, oder? Dann sollte eigentlich auch die Schaltung zurückgemeldet werden...

Der Batteriestatus ist vermutlich "alt" und eine Folge von früheren "retain"- und "globalPublish"-Werten (jetzt wird hoffentlich auch klarer, warum ich es nicht empfehlenwert finde, das zu setzen ;) ).
Und m.E. sollte man auch von HASS aus nicht mit retain senden, allenfalls mit QoS "once" (aber m.E. in einem TCP/IP-Umfeld nicht mal das).
Irgendwo gab es die Option, alle "retain"-Einträge von mosquitto zu löschen, das solltest du mal tun.

Und dann ggf. einfach etwas mehr Geduld haben, die Dinger senden eigentlich schon so etwa alle Stunde, wenn es keine signifikante Änderung gab... Zum Testen kannst du auch "setreading" verwenden und einfach den alten Wert nochmal setzen, dann sollte auch auf der MQTT-Seite was zu sehen sein.

Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline gadget

  • Full Member
  • ***
  • Beiträge: 275
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #81 am: 07 April 2021, 22:51:23 »
Zu Deinem Temperatur Sensor: Installier Dir mal  auf deinem Arbeitsrechner den MQTT Explorer http://mqtt-explorer.com/ und verbinde Dich mit dem MQTT-Broker. Mit dem kann man per Mausklick alte Messages, die retain gesetzt haben, ganz einfach löschen. Echt ein geniales Tool für die Experimentierphase. Du kannst mit dem Tool auch vorhergehende Nachrichten kopieren und nochmal per publish verschicken (und ggf. auch vorher editieren). Das ist beim Rumprobieren ungemein nützlich.

Bei einem Temperatursensor spricht aber meiner Meinung nach nichts dagegen, retain zu verwenden, damit man nach einem Neustart sofort den letzten übermittelten Wert bekommt. Ist ja bei fhem auch nicht anders, da bleibt ein reading ja auch stehen bis was Neues kommt.


Bezüglich Switch in HA:

Wenn im MQTT-Dump die Nachricht so auschaut:

fhem/PCLicht/PCLicht/state on

Dann müsste in der HA-Config doch stehen:

state_topic: "fhem/PCLicht/state"
oder ?

Probier ggf. auch mal ein

attr PCLicht event-on-change-reading .*
Sollte eigentilch nicht notwendig sein, Ich hab da was im Hinterkopf, dass sich dummys bezüglich Event-Generieung etwas konterinutitiv verhalten und dass das dagegen hilft.

Grüße, gadget
« Letzte Änderung: 07 April 2021, 22:59:36 von gadget »

Offline daim21

  • New Member
  • *
  • Beiträge: 12
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #82 am: 07 April 2021, 23:35:09 »
Ok danke dir.

Hiermit klappt es nun
state_topic: "fhem/PCLicht/state"Wenn ich aus Fhem schalte wird nun auch in HA der richtige state gesetzt.  8)

Das einzige was mich optisch bei den HA Switchen noch stört ist, dass das Switch seit dem "State topic" keinen Schieberegler mehr hat sondern diese zwei Blitze für "an" "aus".  ???

Zu den Sensoren:

Das mit dem MQTT Explorer war echt ein guter Tipp.
Habe blitz schnell alle "retain" Einträge löschen können.  ;D

Ich bezweifel aber langsam das ich über MQTT meine Sensoren in HA sauber eingebunden kriege.

Ich warte jetzt mal nach dem löschen der "retains" ab...  :P

Sollte dies wieder nichts bringen werde ich mal probieren, den ConBee Stick an den HA-Rpi anzuschließen und nicht mehr über den Fhem-Rpi.
In Fhem muss ich theoretisch nur die IP des deCONZ Devices anpassen und die Sensoren sollten wieder in Fhem verbunden sein.

Ich werde weiter berichten.

Danke für die ganzen Tipps!


« Letzte Änderung: 07 April 2021, 23:38:16 von daim21 »

Offline gadget

  • Full Member
  • ***
  • Beiträge: 275
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #83 am: 08 April 2021, 10:56:24 »
Das einzige was mich optisch bei den HA Switchen noch stört ist, dass das Switch seit dem "State topic" keinen Schieberegler mehr hat sondern diese zwei Blitze für "an" "aus".  ???

Wenn Du - wie im Beispiel in Post #2 - auch noch

    state_on: "on"
    state_off: "off"

verwendest, sollte das nicht mehr auftreten.


Wenn Du einen fhem-Sensor in HA sauber darstellen kannst, ist der Rest dann eigentlich nur noch Copy & Paste. Ich habe um die 40 Stück (Temperatur, Tür&Fenster, Wasser, Bewegung, Presence). Wo ich länger kämpfen musste waren Heizung & Klima und die Rollos sowie der Staubsauger-Roboter (valetudo).

Für Zigbee verwende ich Zigbee2mqtt - das funktioniert sowohl mit HA als auch mit fhem sehr ordentlich, wenn man einen guten Stick hat. In einer reinen HA Umgebung würde ich aber ZHA mit einer sonoff bridge bevorzugen. Dann musst Du aber auch Deine Automationen von fhem nach HA oder NodeRed verlagern. Ich mach das weiterhin lieber in fhem mit DOIF usw.

Offline daim21

  • New Member
  • *
  • Beiträge: 12
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #84 am: 08 April 2021, 22:16:31 »
Das Switch sieht nun so aus
- platform: mqtt
  name: PCLicht
  command_topic: "fhem/set/PCLicht"
  payload_on: "on"
  payload_off: "off"
  state_topic: "fhem/PCLicht/state"
  state_on: "on"
  state_off: "off"
  availability_topic: "fhem/connection/status"
  payload_available: "connected"
  payload_not_available: "disconnected"
  optimistic: "true"

Habe trotz der state on off s lediglich die zwei Blitze zum ein und aus schalten.  :(

Was die Sensoren angeht.

Hat das löschen der retains geholfen, zumindest kurzfristig.

Ich habe nun über den Tag verteilt über den MQTT Explorer "retains" gelöscht und hatte jeweils kurzfristig korrekte Werte für Temperatur und Luftfeuchte.

Kann man das irgendwie automatisieren? Ich bin mir aber nicht sicher ob das sinnvoll ist.  ???

Offline gadget

  • Full Member
  • ***
  • Beiträge: 275
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #85 am: 09 April 2021, 11:34:15 »

  command_topic: "fhem/set/PCLicht"
  state_topic: "fhem/PCLicht/state"

Würde ich so machen:

 
  command_topic: "fhem/PCLicht/set"
  state_topic: "fhem/PCLicht/state"

(natürlich auch entsprechend auf fhem-Seite) - sonst wird das schnell unübersichtlich wenn du mehrere Devices hast.

 
  optimistic: "true"

Wenn die Rückmeldung fhem -> HA sauber funktioniert stell den optimistic mode auf false (oder lass die Zeile weg, die ist per Default auf false wenn ein state_topic gesetzt ist.


Habe trotz der state on off s lediglich die zwei Blitze zum ein und aus schalten.  :(


Das gehört zwar jetzt eigentlich in ein HA Forum, aber wenn Dir das Blitz Symbol nicht gefällt such Dir auf https://materialdesignicons.com/ ein anderes aus.

switch:
- platform: mqtt
  name: PCLicht
  command_topic: "fhem/PCLicht/set"
  payload_on: "on"
  payload_off: "off"
  state_topic: "fhem/PCLicht/state"
  state_on: "on"
  state_off: "off"
  availability_topic: "fhem/connection/status"
  payload_available: "connected"
  payload_not_available: "disconnected"
  optimistic: "false"
  icon: mdi:desk-lamp

Im Anhang ist ein Screenshot wie das dann im Lovelace-Editor aussieht wenn man den auf einer Lovelace-Card (Elemente) verwendet.


Was die Sensoren angeht.

Hat das löschen der retains geholfen, zumindest kurzfristig.

Ich habe nun über den Tag verteilt über den MQTT Explorer "retains" gelöscht und hatte jeweils kurzfristig korrekte Werte für Temperatur und Luftfeuchte.

Kann man das irgendwie automatisieren? Ich bin mir aber nicht sicher ob das sinnvoll ist.  ???

Nein, das ist nicht sinnvoll. Das ist nur hilfreich wenn von früheren Experimenten alte Werte rumschwirren und man Tabula Rasa machen will. Schau dir in HA den Verlauf an (Menüpunkt auf der linken Seite, Du kannst da dann filtern). Da siehst Du, was HA bisher empfangen hat und man erkennt auch, ob die Daten regelmäßig ankommen. Ich hab mal einen Screenshot vom Verlauf einem meiner Temperatursensoren angehängt. Das ist ein LaCrosse Sensor, der in fhem an einem https://wiki.fhem.de/wiki/LaCrosseGateway_V1.x hängt und die Messwerte per MQTT an HA sendet.

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15768
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #86 am: 09 April 2021, 11:41:42 »
Das mit "würde ich so machen" ist eine Geschmacksfrage. Wenn man $base entsprechend setzt, ergibt sich das halt automatisch anders.

Ich würde "state" tendenziell direkt auf den Haupttopic umbiegen wollen:
state_topic: "fhem/PCLichtVielleicht eine Anmerkung dazu warum ich das anders machen würde: Die bisher existierenden attrTemplate folgen genau diesem Muster.... Soweit das also schon funktiniert, ist es auf der FHEM-Seite schnell und einfach fertig konfiguriert. (Wer mag, kann gerne Vorschläge für Erweiterungen liefern!)
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline gadget

  • Full Member
  • ***
  • Beiträge: 275
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #87 am: 09 April 2021, 11:45:50 »
Das mit "würde ich so machen" ist eine Geschmacksfrage. Wenn man $base entsprechend setzt, ergibt sich das halt automatisch anders.


Definitiv Geschacksfrage. Ich hab gern alles was zu einem Device gehört, in einem Leaf, gerade wenn es dann einen ganzen Sack voll Topics zu einem Device gibt wie z.B. bei HVAC.

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15768
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #88 am: 09 April 2021, 11:56:28 »
...das schließt sich aber nicht aus, oder?
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline daim21

  • New Member
  • *
  • Beiträge: 12
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #89 am: 09 April 2021, 15:32:08 »
So habe ich das Switch nun auf beiden Seiten laufen.
HA
- platform: mqtt
  name: PCLicht
  command_topic: "fhem/set/PCLicht"
  payload_on: "on"
  payload_off: "off"
  state_topic: "fhem/PCLicht/state"
  state_on: "on"
  state_off: "off"
  availability_topic: "fhem/connection/status"
  payload_available: "connected"
  payload_not_available: "disconnected"
  icon: "mdi:desk-lamp"

FHEM
define PCLicht dummy
attr PCLicht userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long structexclude
attr PCLicht alexaName Pc Licht
attr PCLicht alexaRoom alexa
attr PCLicht devStateIcon an:li_wht_on aus:li_wht_off
attr PCLicht eventMap on:an off:aus
attr PCLicht genericDeviceType switch
attr PCLicht group Beleuchtung
attr PCLicht icon light_office_desk
attr PCLicht mqttForward all
attr PCLicht mqttPublish *:topic={"$base/$device/$name"}
attr PCLicht mqttSubscribe state:stopic={"$base/$device"}
attr PCLicht room Arbeitszimmer,HASS,alexa
attr PCLicht setList on off
attr PCLicht webCmd on:off

Zitat
Das gehört zwar jetzt eigentlich in ein HA Forum, aber wenn Dir das Blitz Symbol nicht gefällt such Dir auf https://materialdesignicons.com/ ein anderes aus.

Ich habe nicht das Entity Icon gemeint sondern die "An Aus" Schaltfläche. Und die zwei Blitze verschwinden sobald der "optimistic mode" entfernt wird.  :D
Somit ist das Thema "Switches" für meine Umgebung erfolgreich umgesetzt.

Vielen Dank an @Beta-User und @gadget !!!!!

Die Sensoren werde ich nun beobachten und wie schon erwähnt den DeCONZ Stick an HA anschließen und umgekehrt an FHEM und HA anbinden.

Grüße
Daim



« Letzte Änderung: 10 April 2021, 01:19:17 von daim21 »

Offline SebastianStorb

  • Jr. Member
  • **
  • Beiträge: 62
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #90 am: 15 September 2021, 20:00:49 »
Ich wüsste gerne wie es genau umgekehrt funktioniert. Ich nutze FHEM und Tablet UI. Meine Klimaanlagen habe ich über HACS in Home Assistant eingebunden und kann diese dort auch von der Oberfläche steuern.
Entitäts-ID: climate.midea_ac_18691697794845Über den MQTT-Explorer sehe ich, was ich aus FHEM sende. Jetzt verstehe ich nur nicht, was ich senden muss?

Versucht hatte ich:
fhem/climate/midea_ac_18691697794845/preset_mode 2und vieles Andere in dieser Art.

In der configuration.yaml hatte ich ohne Erfolg folgendes versucht:

select:
    - platform: mqtt
      command_topic: fhem/climate/midea_ac_18691697794845
      name: dimstal
      #climate.midea_ac_18691697794845
      options:
        - preset_mode 1
        - preset_mode 2
        - preset_mode 3

in FHEM bekomme ich u.a. folgende Infos über die Anlage im MQTT-Client
2021-09-15 19:51:27   fan_modes_1     Auto
     2021-09-15 19:51:27   fan_modes_2     Full
     2021-09-15 19:51:27   fan_modes_3     High
     2021-09-15 19:51:27   fan_modes_4     Medium
     2021-09-15 19:51:27   fan_modes_5     Low
     2021-09-15 19:51:27   fan_modes_6     Silent
 
    2021-09-15 19:44:26   midea_ac_18691697794845-current_temperature 21.0
     2021-09-15 19:44:26   midea_ac_18691697794845-fan_mode "Auto"
     2021-09-15 19:44:26   midea_ac_18691697794845-friendly_name "KlimaanlageSebastian"
     2021-09-15 19:44:26   midea_ac_18691697794845-last_changed 2021-09-15T17:38:52.203079+00:00
     2021-09-15 19:44:26   midea_ac_18691697794845-last_updated 2021-09-15T17:44:26.568485+00:00
     2021-09-15 19:44:26   midea_ac_18691697794845-max_temp 30
     2021-09-15 19:44:26   midea_ac_18691697794845-min_temp 17
     2021-09-15 19:44:26   midea_ac_18691697794845-outdoor_temperature 19.0
     2021-09-15 19:44:26   midea_ac_18691697794845-preset_mode "none"
     2021-09-15 15:48:19   midea_ac_18691697794845-restored true
     2021-09-15 19:44:26   midea_ac_18691697794845-state off
     2021-09-15 19:44:26   midea_ac_18691697794845-supported_features 57
     2021-09-15 19:44:26   midea_ac_18691697794845-swing_mode "Both"
     2021-09-15 19:44:26   midea_ac_18691697794845-target_temp_step 1.0
     2021-09-15 19:44:26   midea_ac_18691697794845-temperature 18.0
     2021-09-14 20:58:49   midea_ac_18691697794845_preset_mode 2
   
     2021-09-15 19:51:27   hvac_modes_1    auto
     2021-09-15 19:51:27   hvac_modes_2    cool
     2021-09-15 19:51:27   hvac_modes_3    dry
     2021-09-15 19:51:27   hvac_modes_4    heat
     2021-09-15 19:51:27   hvac_modes_5    fan_only
     2021-09-15 19:51:27   hvac_modes_6    off

Ich habe gestern Abend so vieles versucht, dass HASS heute morgen nicht mehr lief und ich den ganzen Nachmittag nochmal neu aufgesetzt habe. Jetzt traue ich mich nicht mehr so viel zu probieren.

Im Log vom HASS ist scheinbar nie etwas angekommen - nur wie gesagt einfach nicht mehr gelaufen.

Könnte mir jemand helfen?
« Letzte Änderung: 15 September 2021, 20:06:04 von SebastianStorb »

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15768
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #91 am: 15 September 2021, 20:21:03 »
Du solltest zu dem Thema einen neuen Thread aufmachen, und dann VOLLSTÄNDIGE Informationen liefern - Auszüge sind mehr oder weniger unnütz, weil nicht klar ist, wo was herkommt und wie es ggf. durch json2nameValue() ausgepackt wurde; wir werden vermutlich MQTT-Rohdaten brauchen, wie sie z.B. über mosquitto_sub zu bekommen sind.
Das sieht mir nach komplexeren JSON-Strukturen aus, die da versendet werden müssen.
Server: HP-T620@Debian 10, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline SebastianStorb

  • Jr. Member
  • **
  • Beiträge: 62
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #92 am: 15 September 2021, 21:31:23 »
Ok, ich werde einen neuen Beitrag schreiben. Tut mir Leid, wenn es nicht verständlich geschrieben ist. Ich verstehe nur viel zu wenig über Home Assistant, MQTT und vor allem die Bridge in FHEM bzw.auch Mosquitto. Das ist mehr oder weniger ein Wunder, dass ich das überhaupt irgendwie zum Laufen bekommen habe. Als ich die Wiki-Artikel gelesen habe, die darüber geschrieben wurden komme ich schon nach den ersten Absätzen schon ins Stocken (weil ich keine Ahnung habe was dort beschrieben wird) und verstehe gar nichts mehr. Die Schnipsel, die ich hier zusammengetragen habe sind hilflose Versuche gewesen irgendetwas von Fhem nach HASS zu schicken. Es wird also noch dauern, bis ich so weit bin überhaupt die Frage richtig zu formulieren und die erforderlichen Informationen dazuzuschreiben.

Danke für die Unterstützung,

(Meine Posts zu diesem Thema können gerne einfach von einem Admin gelöscht weden)

Offline gadget

  • Full Member
  • ***
  • Beiträge: 275
Antw:Verbindung zu HomeAssistant mit MQTT_GENERIC_BRIDGE
« Antwort #93 am: 16 September 2021, 14:59:56 »
Poste hier bitte einen Link auf den neuen Thread wenn der fertig ist, dann schaue ich mir das gerne an. Vielleicht ist so etwas komplexes wie die Steuerung einer Klimaanlage auch nicht unbedingt die beste Wahl für den Einstieg, probier es doch erst mal mit einfacheren Dingen (Temperatursensoren, Schalter, Dimmer).

Ich nehme an, dass es für deine Klimaanlage eine fertige Integration in HA gibt und Du diese (evtl. sogar per Autodiscovery) verwendet hast ? Dann ist das per se erst mal ein climate-Device, aber nicht vom Typ platform: mqtt, sondern irgendwas Herstellerspezifisches (Übersicht der Integrationen siehe https://www.home-assistant.io/integrations/#climate)

Du kannst aber per MQTT Statestream https://www.home-assistant.io/integrations/mqtt_statestream/ dafür sorgen, dass alle Informationen von beliebigen Integrationen, die Du in fhem brauchen kannst, per MQTT in Richtung fhem gesendet werden. Allerdings ist es dann bei komplexen Devices nicht trivial, ein passendes MQTT2_DEVICE in fhem zu basteln, dass die MQTT Nachrichten dann korrekt in Readings umsetzt.

Die Klimaanlage dann von fhem aus zu steuern ist dann noch mal eine ganz andere Sache, hier wirst Du vermutlich am ehesten Erfolg haben, wenn Du Dir zusätzlich ein (Pseudo-) climate-Device vom Typ MQTT anlegst, dies von fhem aus schaltest und dann schließlich mit  HA-Automatisierungen dafür sorgst, dass das "echte" climate-Device das gleiche macht.

Wenn es in fhem eine gutes Modul für deine Klimaanlage gibt würde ich überlegen dieses parallel zu HA zu nutzen. So mache ich das bei meiner Daikin auch. Die kommt gut damit zurecht gleichzeitig von fhem und von HA angesprochen zu werden.