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
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 (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-clientsDanach 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/ (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
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...
Zitat von: Jens_B am 14 Dezember 2020, 12:50:04
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 ?
Zitat von: Jens_B am 14 Dezember 2020, 12:50:04
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.
Zitat von: Jens_B am 14 Dezember 2020, 12:50:04
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.
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
Zitat von: hckoe am 13 Januar 2021, 16:05:01
Irgendeine Idee, warum das passiert?
Schau mal in die cref zu "
Hallo Beta-User,
Der Post war irgendwie noch nicht ganz vollständig?
cref zu MQTT_GENERIC_BRIDGE, MQTT2_CLIENT?
Gruß Helmut
Mist, da hat die forensoftware was verschluckt...
MQTT_GENERIC_BRIDGE, dort mqttForward.
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
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
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 (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...
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
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 (https://forum.fhem.de/index.php/topic,117423.msg1122346.html#msg1122346) (speziell: https://forum.fhem.de/index.php/topic,117423.msg1122346.html#msg1122346 (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...
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 (https://forum.fhem.de/index.php/topic,117987.0.html), 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
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.
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).
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.
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.
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.
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
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 (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
@hckoe:
Na ja, du hast auch auf dim kein subscribe...
Zitatattr 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
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.
Zitat von: gadget 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:
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 (https://forum.fhem.de/index.php/topic,117933.0.html). 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) ?
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
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
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...
Danke für die Info. Werde ich heute abend gleich ausprobieren.
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?
Hab ich nicht ausprobiert
Mein eltako Dimmer schaltet unter 15% eh ab.
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?
ZitatVermutlich 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.
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?
Nein, resendOnConnect verwende ich nicht. Werde das mit "showInternalValues" heute abend mal testen.
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.
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.
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.
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
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...
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ß
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").
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 :(
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
Hey
Über update sagt der mir es sei nichts zu tun...
Gruß
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ß
Zitat von: jensorium 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ß
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)
Zitat von: gadget am 22 Februar 2021, 02:58:55
Ich glaube das liegt am fehlenden mqttforward all bei deinem schrank-dummy.
Zitat von: jensorium am 21 Februar 2021, 21:26:16
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.
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.
Zitat von: hckoe 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.
Guter Hinweis!
@jensorium: Bitte aber KEIN globales publish angeben, (auch) das sollte mAn. immer am Device (=> "schrank") konfiguriert werden...
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
Zitat von: Beta-User am 22 Februar 2021, 11:10:56
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ß
Zitat von: jensorium am 22 Februar 2021, 11:41:14
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!).
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
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.
@Beta-User: Ist "$device" in den "globalDefaults xxx:base=" aktuell die Empfehlung. Im Thread über attrTemplate wurde das unterschiedlich diskutiert.
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"}
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ß
Da war mir beim editieren noch eine Klammer durchgerutscht, hoffe, das hattest du bemerkt:
attr mqttGeneric globalDefaults pub:base=fhem sub:base=fhem/set
Hey
gesehen ja, gewundert, dachte aber es gehört so, Änderung brachte aber keinen Erfolg
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.
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.
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
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.
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"}
... 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
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
Zitat von: daim21 am 06 April 2021, 16:00:42
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.
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).
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
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.)
ZitatBitte 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 $ZitatUnd 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
Zitat von: daim21 am 06 April 2021, 16:38:50
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.
globalDefaults sub:base=fhem/set pub:base=fhem
Habe das jetzt so bei mir eingegeben.
Erhalte weiterhin seltsame Werte. :-\
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.
Zitat von: daim21 am 06 April 2021, 16:59:23
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.
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.
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
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).
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:aus
hat 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?
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.
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.
ZitatWenn 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 100Mich 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. :)
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.
Zu Deinem Temperatur Sensor: Installier Dir mal auf deinem Arbeitsrechner den MQTT Explorer http://mqtt-explorer.com/ (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
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!
Zitat von: daim21 am 07 April 2021, 23:35:09
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.
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. ???
Zitat von: daim21 am 08 April 2021, 22:16:31
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.
Zitat von: daim21 am 08 April 2021, 22:16:31
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.
Zitat von: daim21 am 08 April 2021, 22:16:31
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/ (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.
Zitat von: daim21 am 08 April 2021, 22:16:31
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 (https://wiki.fhem.de/wiki/LaCrosseGateway_V1.x) hängt und die Messwerte per MQTT an HA sendet.
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/PCLicht
Vielleicht 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!)
Zitat von: Beta-User 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.
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.
...das schließt sich aber nicht aus, oder?
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:offZitatDas 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
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 2
und 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?
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.
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)
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 (https://www.home-assistant.io/integrations/#climate))
Du kannst aber per MQTT Statestream https://www.home-assistant.io/integrations/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.
Erst einmal Danke für die vielen wertvollen Informationen. Damit habe ich bereits erfolgreich die Verbindung über MQTT hinbekommen.
Was ich nun gerne noch erreichen möchte ist das autodiscovery von HA für MQTT zu nutzen, da man nur so ein Gerät in HA für MQTT Geräte anlegen kann und auch das automatische setzen des Raums funktioniert nur über Discovery. Dafür wird eine config Nachricht benötigt. Die Idee ist das diese von den einzelnen Geräten in fhem mit retain gesendet werden. Über mosquitto_pub habe ich dasganze auch schon erfolgreich hinbekommen.
Allerdings habe ich noch keine Möglichkeit gefunden diese aus fhem zu senden.
fhem könnte diese beim erstellen/ändern oder sobald fhem die Verbindung zum Broker aufbaut senden, dank retain sollten sie ja auf dem mqtt Broker erhalten bleiben und damit auch nach einem HA neustart weiterhin für das discovery zur Verfügung stehen.
Zitat von: Shortie am 08 November 2021, 20:13:45
Was ich nun gerne noch erreichen möchte ist das autodiscovery von HA für MQTT zu nutzen, da man nur so ein Gerät in HA für MQTT Geräte anlegen kann und auch das automatische setzen des Raums funktioniert nur über Discovery. Dafür wird eine config Nachricht benötigt. Die Idee ist das diese von den einzelnen Geräten in fhem mit retain gesendet werden. Über mosquitto_pub habe ich dasganze auch schon erfolgreich hinbekommen.
Vermutlich wäre es auch hierfür sinnvoll, einen neuen Thread zu starten, und dazu v.a. auch für die, die HA nicht kennen zu zeigen, wie sowas aussehen muss...
Zitat
Allerdings habe ich noch keine Möglichkeit gefunden diese aus fhem zu senden.
Prinzipiell unterstützen alle MQTT-Interface-Module in FHEM z.B. auch das direkte publishen von Infos.
Zitat
fhem könnte diese beim erstellen/ändern oder sobald fhem die Verbindung zum Broker aufbaut senden, dank retain sollten sie ja auf dem mqtt Broker erhalten bleiben und damit auch nach einem HA neustart weiterhin für das discovery zur Verfügung stehen.
Dazu müßte aber v.a. klar sein, was wohin unter welchem Namen gesendet wird. V.a. für wildcard-Readings ist das uU. einem gewissen Wandel unterworfen, und es ist nicht immer klar, welcher Datentyp sich hinter welchem Reading verbirgt, usw., usf..
Sehr vielleicht könnte man ein stark erweitertes "get <mgb> devinfo" basteln, aber dazu müßte sich jemand mal hinsetzen und erst mal exemplarisch ein, zwei Geräte "darstellen".
Ich habe hier https://forum.fhem.de/index.php/topic,124018.0.html dazu einen neuen Thread gestartet und ein Beispiel geliefert.
In den MQTT-Interface Modulen hatte ich noch nicht geschaut, da war ich vermutlich zu sehr auf MQTT_GENERIC_BRIDGE innerhalb des Device fokussiert bisher. Generell ergibt es meiner Meinung nach aber Sinn sowas an den Geräten selbst zu haben, siehe auch den neuen Thread.
Hallo zusammen,
auch wenn ich hier gerade den Grabräuber spiele, bitte ich um Vergebung, da meine Frage in dieses Thema einfach am Besten passt:
Ich versuche gerade meine Rolladen, welche in Fhem stecken, in HomeAssistant sinnvoll zu nutzen.
Die grundsätzliche Funktionalität (auf/stop/zu) bekomme ich hin.
Lediglich mit den Positionen habe ich Probleme und hoffe, dass mir einer der Gelehrten hier weiterhelfen kann:
Dies ist die Definition eines meiner Rollos in Fhem:
defmod Rollo_Nr_14 ROLLO
attr Rollo_Nr_14 userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
attr Rollo_Nr_14 autoStop 1
attr Rollo_Nr_14 commandDown {RolloIo("14","down")}
attr Rollo_Nr_14 commandStop {RolloIo("14","stop")}
attr Rollo_Nr_14 commandUp {RolloIo("14","up")}
attr Rollo_Nr_14 devStateIcon open:fts_shutter_10:closed closed:fts_shutter_100:open half:fts_shutter_50:closed drive-up:fts_shutter_up@red:stop drive-down:fts_shutter_down@red:stop position-100:fts_shutter_100:open position-90:fts_shutter_80:closed position-80:fts_shutter_80:closed position-70:fts_shutter_70:closed position-60:fts_shutter_60:closed position-50:fts_shutter_50:closed position-40:fts_shutter_40:open position-30:fts_shutter_30:open position-20:fts_shutter_20:open position-10:fts_shutter_10:open position-0:fts_shutter_10:closed
attr Rollo_Nr_14 excessBottom 4.4
attr Rollo_Nr_14 excessTop 0
attr Rollo_Nr_14 genericDeviceType blind
attr Rollo_Nr_14 group Rollos
attr Rollo_Nr_14 homebridgeMapping clear\
CurrentPosition=homekit_pos,minValue=0,maxValue=100\
TargetPosition=homekit_pos,minValue=0,maxValue=100,minStep=10,delay=400,cmd=position_homekit,\
PositionState=state,values=/^drive-up/:INCREASING;;/^drive-down/:DECREASING;;/.*/:STOPPED
attr Rollo_Nr_14 mqttForward all
attr Rollo_Nr_14 mqttSubscribe state:stopic={"$base/set"}
attr Rollo_Nr_14 resetTime 0
attr Rollo_Nr_14 room HASS,Interfaces->homekit,Obergeschoss->Schlafzimmer,fhem->Alexa
attr Rollo_Nr_14 secondsDown 22.0
attr Rollo_Nr_14 secondsUp 26.8
attr Rollo_Nr_14 switchTime 1
attr Rollo_Nr_14 type normal
attr Rollo_Nr_14 webCmd open:closed:half:stop:position
setstate Rollo_Nr_14 position-60
setstate Rollo_Nr_14 2022-03-14 17:03:35 command position-60
setstate Rollo_Nr_14 2022-03-14 17:03:35 desired_position 60
setstate Rollo_Nr_14 2022-03-14 17:03:35 drive-type modul
setstate Rollo_Nr_14 2022-03-14 17:03:41 homekit_pos 40
setstate Rollo_Nr_14 2022-03-14 17:03:35 last_drive drive-down
setstate Rollo_Nr_14 2022-03-14 17:03:41 position 60
setstate Rollo_Nr_14 2022-03-14 17:03:41 state position-60
Ich nutze (bewusst) eine alte, leicht modifizierte Rollo-Version, weil ich meine Rolladen seit Ewigkeiten über eine gehackte Fernbedienung steuere. Damals war die Definition von auf und zu noch anders, als sie in Homekit war, weshalb homekit_pos die korrekte Position des Rollos ist.
Auf der Homeassistant-Seite sieht das Ganze so aus:
cover:
- platform: mqtt
name: Fhem_Rollo_14
unique_id: "fhemRollo14"
command_topic: "fhem/Rollo_Nr_14/set"
state_topic: "fhem/Rollo_Nr_14/state"
position_topic: "fhem/Rollo_Nr_14/homekit_pos"
set_position_topic: "fhem/Rollo_Nr_14/set"
set_position_template: "{{'position_homekit '}}{{ position }}"
#availability_topic: "fhem/connection/status"
payload_available: "true"
payload_not_available: "false"
payload_open: "open"
payload_close: "closed"
payload_stop: "stop"
state_opening: "drive-up"
state_closing: "drive-down"
position_open: 100
position_closed: 0
optimistic: false
qos: 1
Mit dieser Konfiguration kann ich in der Richtung HA->Fhem die Position exakt einstellen.
1. Problem: Ich will die Position in 10% Schritten einstellen.
2. Problem: Ich bekomme zwar auf dem Topic fhem/Rollo_Nr_14/homekit_pos die Position zurück, aber in HA wird diese nicht korrekt grafisch angezeigt. Hier steht immer noch "Schließt " als state. Wie kann ich das einstellen?
Danke für die Hilfe!
Hallo Zusammen,
ich habe seit Jahren FHEM laufen und probiere mich zur Zeit mal mit Home Assistant. Da ich meine DOOYA Rolläden wohl nicht so einfach direkt mit HA verheiratet bekomme wird FHEM wohl weiterhin nicht zu ersetzen sein. Eventuell gibt mit die MQTT Bridge aber die Möglichkeit beides zu kombinieren.
Ich habe jetzt mal den "demoswitch" von Gadget und das "PC Licht" von Daim21 nachgebaut. Bei beiden Devices kommt mein schalten aus FHEM in HA an.
Wenn ich aber in HA schalte springt der Schalter nach einer Sekunde wieder zurück und in FHEM passiert nichts - das gleiche verhalten was hier schon ein paar mal beschrieben wurde.
Meine Generic Bridge sieht so aus:
Internals:
DEF mqtt room=HASS
FUUID 62659733-f33f-96ca-bbd7-622bbcbf44eeba1c
IODev ha_MQTT2
NAME mqttGeneric
NR 24
NTFY_ORDER 50-mqttGeneric
STATE in: 75 out: 9 devices: 0
TYPE MQTT_GENERIC_BRIDGE
devspec room=HASS
prefix mqtt
CHANGED:
incoming-count: 44
incoming-count: 45
incoming-count: 46
incoming-count: 47
incoming-count: 48
incoming-count: 49
incoming-count: 50
incoming-count: 51
incoming-count: 52
incoming-count: 53
incoming-count: 54
incoming-count: 55
incoming-count: 56
incoming-count: 57
incoming-count: 58
incoming-count: 59
incoming-count: 60
incoming-count: 61
incoming-count: 62
incoming-count: 63
incoming-count: 64
incoming-count: 65
incoming-count: 66
incoming-count: 67
incoming-count: 68
incoming-count: 69
incoming-count: 70
incoming-count: 71
incoming-count: 72
incoming-count: 73
incoming-count: 74
incoming-count: 75
READINGS:
2022-04-24 22:59:50 device-count 0
2022-04-24 23:10:25 incoming-count 75
2022-04-24 23:03:13 outgoing-count 9
2022-04-24 23:03:13 transmission-state outgoing publish sent
2022-04-24 22:59:50 updated-reading-count 0
2022-04-24 22:59:50 updated-set-count 0
devices:
:global:
:publish:
*:
mode R
topic {"fhem/$device/$reading"}
globalDeviceExcludes:
globalReadingExcludes:
globalTypeExcludes:
Attributes:
IODev ha_MQTT2
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 5
MQTT2_Client so:
Internals:
BUF
DEF 192.168.178.231:1883
DeviceName 192.168.178.231:1883
FD 9
FUUID 6265959e-f33f-96ca-973e-c0c9eebd9e85ca29
NAME ha_MQTT2
NR 21
PARTIAL
STATE opened
TYPE MQTT2_CLIENT
WBCallback
clientId fhemdev
lastMsgTime 1650834710.16311
nextOpenDelay 5
qosCnt 11
qosMaxQueueLength 100
READINGS:
2022-04-24 22:59:50 state opened
qosQueue:
Attributes:
clientId fhemdev
keepaliveTimeout 60
msgAfterConnect -r fhem/connection/status connected
msgBeforeDisconnect -r fhem/connection/status disconnected
qosMaxQueueLength 100
room MQTT
username openmqtt
verbose 5
Der demoswitch:
Internals:
FUUID 62659733-f33f-96ca-e55b-c377d267c3c4b9a5
NAME demoswitch
NR 27
STATE off
TYPE dummy
READINGS:
2022-04-24 22:53:00 state off
Attributes:
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
verbose 5
webCmd on:off
und mein PCLICHT so:
Internals:
FUUID 6265ba46-f33f-96ca-36d0-7fa81ad5515726cf
NAME PCLicht
NR 30
STATE an
TYPE dummy
READINGS:
2022-04-24 23:03:13 state on
Attributes:
devStateIcon an:li_wht_on aus:li_wht_off
eventMap on:an off:aus
group Beleuchtung
icon light_office_desk
mqttForward all
mqttPublish *:topic={"$base/$device/$name"}
mqttSubscribe state:stopic={"$base/$device"}
room Arbeitszimmer,HASS,alexa
setList on off
userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long structexclude
webCmd on:off
In der HA Conf steht folgendes:
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"
optimistic: true
- 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"
icon: "mdi:desk-lamp"
Fällt jemandem hier ein Fehler auf?
Vielen Dank vorweg
Dominik
Zitat von: Dominik83 am 24 April 2022, 23:18:30
Fällt jemandem hier ein Fehler auf?
MAn. sind hier gleich mehrere Dinge "verbogen":
- prinzipiell ist "globalPublish" nicht zu empfehlen!
- "device-count" mit 0 ist komisch, das CHANGED-Array sollte leer sein. Das deutet auf irgendwas sehr Seltsames in deiner Konfiguration hin. Ist alles aktuell?
- Dann sind die "subscribe"-Angaben für beide dummy unterschiedlich, "richtig" dürfte
mqttSubscribe state:stopic={"$base/set"} sein (iVm. dieser unglücklichen nicht nach sub und pub geteilten Einstellung für $base in der MGB selbst).
Hi Beta,
danke für deine Unterstützung. Es tut nun: Update war das Stichwort! Verrückt, zum testen habe ich gestern einen neuen Container mit dem neusten Image von Dockerhub gemacht da dachte ich ein Update sei nicht nötig.
Wieder was dazu gelernt!
Danke!
Nun ja,
ein "update" ist mAn. immer Pflicht nach einer Neuinstallation (wenn man nicht grad das nightly-deb genutzt hat), aber erst mal ist ja schön, dass es nun eher läuft wie erwartet.
Bedeutet aber nicht, dass meine anderen Hinweise nicht auch ernst gemeint gewesen waren, insbesondere zu "globalPublish"...
Hi,
ich habe das Global Publish entfernt und das publish auf dem Device "Demoswitch" angepasst ---> klappt.
Als nächstes möchte ich meine Rollos ins HA bringen. Meine MGB zeigt auch:
D_Rollo6D
publish:
* => fhem/D_Rollo6D/* (mode: R; qos: 0; retain)
subscribe:
state <= fhem/D_Rollo6D/set (mode: S)
Interessanterweise kommt vom Rollo aber nichts bei meinem MQTT Broker an. Also das Topic "D_Rollo6D" erscheint da gar nicht.
Habe alles durchgestartet - geupdated habe ich ja gestern:-)
Das Rollo ist so definiert:
Internals:
CHANNEL
DEF 0001100000000111100000101011
FUUID 5c9e6500-f33f-9eb1-3523-c14aff76b2f30d5b
ID 0001100000000111100000101011
IODev SIGNALESP1
NAME D_Rollo6D
NR 196
STATE open
TYPE Dooya
exact open
move off
position 0
CODE:
1 0001100000000111100000101011
READINGS:
2022-04-26 22:11:54 IODev SIGNALESP1
2022-04-26 22:18:18 exact open
2022-04-26 22:18:18 position 0
2022-04-26 22:18:18 state open
Attributes:
IODev SIGNALESP1
SignalRepeats 10
channel 6
devStateIcon .*closed:fts_shutter_100 .*open:fts_window_2w
event-on-change-reading state
eventMap on:Runter off:Hoch stop:Stop
mqttForward all
mqttPublish *:topic={"$base/$name"}
mqttSubscribe state:stopic={"$base/set"}
room hass,Dominik,alexa
userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
webCmd Runter:Hoch:Stop:pos
Hast Du da noch einen guten Tip?
Danke Dir!
Dominik
Zitat von: Dominik83 am 26 April 2022, 22:27:39
ich habe das Global Publish entfernt und das publish auf dem Device "Demoswitch" angepasst ---> klappt.
Soweit so gut.
Zwei Anmerkungen dazu:
- das dann durch "pauschale publishes" in den einzelnen Devices zu ersetzen, ist nicht unbedingt Ziel der Übung, ich würde auch immer die publishes beschränken auf die Readings, die es "wirklich braucht". Was das bei deinem Rollladen wäre, musst du selbst wissen; wenn der "state" auf der Gegenseite mit numerischen Werten ausreichend beschrieben ist, würde ich nur das senden, und ggf. dann auch ein anderes Reading dahin umbiegen. Könnte sein, dass "position" dafür geeignet wäre...
- Meine Empfehlung wäre, "$base" global in Sende- und Empfangsrichtung unterschiedlich zu belegen, also in sub: gleich das "/set" mir reinzubasteln. (Deine anderen Angaben da sind auch überdenkenswert; es gibt dazu irgendwo auch eine separate Diskussion, vermutlich im "attrTemplate für MGB"-Thread).
Zitat
Als nächstes möchte ich meine Rollos ins HA bringen. Meine MGB zeigt auch:
Das sieht "eigentlich" (s.u.) ok aus, kann keinen Grund zur Annahme erkennen, dass es ein prinzipielles Problem gäbe.
Zitat
Das Rollo ist so definiert:
Internals:
TYPE Dooya
event-on-change-reading state
eventMap on:Runter off:Hoch stop:Stop
mqttForward all
Hast Du da noch einen guten Tip?
Ob gut, sei mal dahingestellt...
a) help Doyaa liefert für "state" als Setter on+off. Ich würde dazu neigen, (nur) den "pos"-Setter zu nutzen, und notfalls ein "richtiges" eventMap zu basteln, das die Sonderfälle "on/off" via MQTT mit abbildet - oder eben eine Verarbeitungsroutine (expression) für numerische set-state-Eingänge festlegen. Solche "Spezialitäten" waren/sind der Grund, warum ich mal vorgeschlagen hatte, attrTemplate für MGB einzubauen. Damit könnte man sowas wie einen "Standard" für Gegenstellen etablieren, bei denen praktisch alle FHEM-Rollladen-Devices "von außen" gleich zu bedienen wären. Es hat sich nur keiner die Mühe gemacht, den Faden für "seine" TYPE aufzugreifen...
b) Das eventMap ist vermutlich eher hinderlich - ich habe das aber nicht im Detail untersucht, Bauchgefühl sagt: es wird die "komplexe Form" benötigt, commandref zu diesem Attribut sollte weiterhelfen.
c) Das "event-on-.*"-Attribut kommt mir auch vom Baufgefühl her unpassend vor. (Entweder unnötig oder unvollständig.)
d) mqttForward all ist afaik der default für alles, was nicht dummy ist => unnötig (mAn. sollte man immer alles weglassen, was unnötig ist).
Hi Beta,
das pauschale publish aller readings nehme ich mir nochmal zu herzen.
Irgendwie publishen die Dooya Devices aber gar nichts.
Ich habe nochmal ein neues Device in der minimal Konfiguration angelegt um mögliche event-map Probleme auszuschließen:
Internals:
CFGFN
CHANNEL 6
DEF 0001100000000111100000101011_6
FUUID 6269ad62-f33f-9eb1-005b-e235f75667ebdfd4
ID 0001100000000111100000101011
IODev SIGNALESP1
NAME D_Rollotest
NR 61194
STATE open
TYPE Dooya
exact open
move off
position 0
CODE:
1 0001100000000111100000101011_6
READINGS:
2022-04-27 22:53:54 IODev SIGNALESP1
2022-04-27 22:56:11 exact open
2022-04-27 22:56:11 position 0
2022-04-27 22:56:11 state open
Attributes:
mqttPublish *:topic={"fhem/$device/$reading"}
mqttSubscribe state:stopic={"$base/set"}
room hass
In der MGB erscheint es auch:
D_Rollotest
publish:
* => fhem/D_Rollotest/* (mode: R; qos: 0; retain)
subscribe:
state <= fhem/D_Rollotest/set (mode: S)
Ich kann die Rollos per publish aus dem Broker heraus steuern, das subscribe funktioniert also.
Die Rollos Publishen aber nichts einfach gar nichts.
Da ich testweise auch nochmal andere Devices ins MQTT aufgenommen habe und alle sich beim Broker "melden" scheint es irgendwie an dem Dooya Modul zu liegen. Ich forsche nochmal weiter...
Grüße
Noch eine Ergänzung,
ich habe nochmal meine Screenshots durchforstet. Auch als ich noch das global publish auf der MGB definiert hatte gab es von den Rollos nicht einen einzigen publish. Alle anderen Devices waren da.
Zitat von: Dominik83 am 27 April 2022, 23:01:23
Irgendwie publishen die Dooya Devices aber gar nichts.
Das kommt mir komisch vor, jedenfalls auf die Schnelle ist im Dooya-Code kein Anhaltspunkt zu erkennen, warum das nicht klappen sollte.
Gibt es denn Events (im Event-Monitor), wenn du schaltest? Wenn nein, ist es "relativ klar": MGB ist bzgl. publish von Aktualisierungen einfach nur ein Event-Handler - keine Events, kein publish... Das wäre dann im dazu passenden Forenbereich zu klären.
Hi,
das ist das Problem - keine Events der Devices im Event Monitor.
Ich suche ...
Hi,
noch ein Update: Habe es nun mit einem DOIF und Dummies gelöst. Nicht die schönste Lösung aber funktioniert!
Danke nochmal für die Unterstützung.
...das klingt gruselig...
Hallo zusammen,
ich versuche die Daten von einem Strommesser (Revolt_71a6) per MQTT an Homeassitant zu senden.
Einen zusätzlichen MQTT Server, wie in diesem Thread beschrieben, möchte ich nicht verwenden,
sondern einfach den in fehm enthaltenen MQTT2_SERVER.
Sende ich einen Test mit Topic (123) über den MQTT2_FHEM_Server an Homeassistant kommt dieser bei Homeassitant an.
Nachrichten von Homeassitant werden am FHEM Server ebenfalls empfangen.
Die Daten vom Strommesser (Revolt_71a6) sehe ich im MQTT traffic als sent, diese kommen aber nicht bei Homeassitant an.
Hat jemand vielleicht einen einen Tip für mich.
Danke
Gruß Mark
FHEM Version:
fhem.pl 25997 2022-04-25 18:39:55Z rudolfkoenig
MQTT_GENERIC_BRIDGE Version:
version 1.4.4 by hexenmeister
$Id: 10_MQTT_GENERIC_BRIDGE.pm 25117 2021-10-25 11:05:19Z hexenmeister $
MQTT traffic:
RCVD: 123 Hallo von Homeassistant
SENT: /Revolt_71a6/voltage/voltage 231
SENT: /Revolt_71a6/current/current 0.56
SENT: /Revolt_71a6/power/power 87.9
SENT: /Revolt_71a6/pf/pf 0.67
SENT: /Revolt_71a6/current/current 0.57
SENT: /Revolt_71a6/power/power 89.1
SENT: /Revolt_71a6/pf/pf 0.68
RCVD: shellies/shellyplug-s-0CDAD9/relay/0/power 0.00
list MQTT2_FHEM_Server:
Internals:
CONNECTS 7
Clients :MQTT2_DEVICE:MQTT_GENERIC_BRIDGE:
ClientsKeepOrder 1
DEF 1883 global
FD 86
FUUID 5e45b3c2-f33f-a0b3-d691-a162068318b09ed0
NAME MQTT2_FHEM_Server
NR 779
PORT 1883
STATE Initialized
TYPE MQTT2_SERVER
MatchList:
1:MQTT2_DEVICE ^.
2:MQTT_GENERIC_BRIDGE ^.
READINGS:
2022-05-06 06:00:06 RETAIN {"fhem/Revolt_71a6/.lastenergy/.lastenergy":"467.79","fhem/Revolt_71a6/current/current":"0.58","fhem/Revolt_71a6/energy/energy":"467.79","fhem/Revolt_71a6/power/power":"89.8","fhem/Revolt_71a6/statEnergy/statEnergy":"Hour: 0.07 Day: 1.90 Month: 8.27 Year: 268.23","fhem/Revolt_71a6/statEnergyDay/statEnergyDay":"1.90","fhem/Revolt_71a6/statEnergyHour/statEnergyHour":"0.07","fhem/Revolt_71a6/statEnergyMonth/statEnergyMonth":"8.27","fhem/Revolt_71a6/statEnergyYear/statEnergyYear":"268.23","tele/Steckdose_2/LWT":"Online","tele/tasmota102/LWT":"Online"}
2022-05-06 06:02:58 lastPublish 123:Test fhem
2022-05-06 06:00:51 nrclients 7
2022-05-06 05:59:39 state Initialized
clients:
MQTT2_FHEM_Server_192.168.11.166_43411 1
MQTT2_FHEM_Server_192.168.110.102_60653 1
MQTT2_FHEM_Server_192.168.110.112_53521 1
MQTT2_FHEM_Server_192.168.110.130_6493 1
MQTT2_FHEM_Server_192.168.110.131_22239 1
MQTT2_FHEM_Server_192.168.110.132_4515 1
MQTT2_FHEM_Server_192.168.110.160_51925 1
retain:
fhem/Revolt_71a6/.lastenergy/.lastenergy:
ts 1651809580.54848
val 467.79
fhem/Revolt_71a6/current/current:
ts 1651809580.54848
val 0.58
fhem/Revolt_71a6/energy/energy:
ts 1651809580.54848
val 467.79
fhem/Revolt_71a6/power/power:
ts 1651809580.54848
val 89.8
fhem/Revolt_71a6/statEnergy/statEnergy:
ts 1651809580.54848
val Hour: 0.07 Day: 1.90 Month: 8.27 Year: 268.23
fhem/Revolt_71a6/statEnergyDay/statEnergyDay:
ts 1651809580.54848
val 1.90
fhem/Revolt_71a6/statEnergyHour/statEnergyHour:
ts 1651809580.54848
val 0.07
fhem/Revolt_71a6/statEnergyMonth/statEnergyMonth:
ts 1651809580.54848
val 8.27
fhem/Revolt_71a6/statEnergyYear/statEnergyYear:
ts 1651809580.54848
val 268.23
tele/Steckdose_2/LWT:
ts 1651809606.81993
val Online
tele/tasmota102/LWT:
ts 1651809606.77573
val Online
Attributes:
autocreate simple
clientOrder MQTT2_DEVICE MQTT_GENERIC_BRIDGE
rePublish 0
room 00_devices,02_MQTT2_Devices
verbose 1
list mqttGeneric:
Internals:
DEF fhem_ Revolt_71a6
FUUID 62703058-f33f-a0b3-1143-560988d95b2b52f7
IODev MQTT2_FHEM_Server
NAME mqttGeneric
NR 979
NTFY_ORDER 70-mqttGeneric
STATE ???
TYPE MQTT_GENERIC_BRIDGE
devspec Revolt_71a6
prefix fhem_
READINGS:
2022-05-06 05:59:41 IODev MQTT2_FHEM_Server
2022-05-05 15:54:15 attrTemplateVersion 20211208_MQTT
2022-05-06 05:59:41 device-count 1
2022-05-06 05:59:40 incoming-count 0
2022-05-06 06:48:12 outgoing-count 342
2022-05-06 06:48:12 transmission-state outgoing publish sent
2022-05-06 05:59:40 updated-reading-count 0
2022-05-06 05:59:40 updated-set-count 0
devices:
Revolt_71a6:
:alias:
:publish:
*:
mode R
topic {"$base/$device/$name/$reading"}
:subscribe:
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 *
Attributes:
IODev MQTT2_FHEM_Server
room 00_devices,02_MQTT2_Devices
list Revolt_71a6:
Internals:
CUL433_MSGCNT 134
CUL433_RAWMSG r71a6e5003732034d42b7e0
CUL433_RSSI -24
CUL433_TIME 2022-05-06 06:48:12
DEF 71a6
FUUID 5c46f961-f33f-a0b3-e790-e061c2eae95d109d
ID 71a6
IODev CUL433
LASTInputDev CUL433
MSGCNT 134
NAME Revolt_71a6
NR 507
STATE P: 84.5 E: 470.72 V: 229 C: 0.55 Pf: 0.66
TYPE Revolt
READINGS:
2022-05-06 05:59:40 IODev CUL433
2018-10-22 08:45:07 avgpower 66.25
2022-05-06 06:48:12 current 0.55
2022-05-06 06:48:12 energy 470.72
2022-05-06 06:41:15 energy_avg_day 470.4
2022-05-06 06:41:15 energy_avg_month 464.2
2022-05-06 06:41:15 energy_cum_day 11325411.67
2022-05-06 06:41:15 energy_cum_month 251838921.07
2022-05-06 06:41:15 energy_max_day 470.7
2022-05-06 06:41:15 energy_max_month 470.7
2022-05-06 00:05:10 energy_min_day 470.1
2022-05-01 00:00:28 energy_min_month 459.5
2022-05-06 06:48:12 frequency 50
2022-05-06 06:48:12 pf 0.66
2022-05-06 06:48:12 power 84.5
2022-05-06 06:48:12 statEnergy Hour: 0.07 Day: 0.61 Month: 11.20 Year: 271.16
2022-05-06 06:48:12 statEnergyDay 0.61
2022-05-05 23:59:55 statEnergyDayLast 2.11
2022-05-06 06:48:12 statEnergyHour 0.07
2022-05-06 05:59:55 statEnergyHourLast 0.09
2022-05-06 05:59:55 statEnergyLast Hour: 0.09 Day: 2.11 Month: 63.17 Year: 136.39
2022-05-06 06:48:12 statEnergyMonth 11.20
2022-04-30 23:59:57 statEnergyMonthLast 63.17
2022-05-06 06:48:12 statEnergyYear 271.16
2021-12-31 23:59:55 statEnergyYearLast 136.39
2022-05-06 06:48:12 state active
2022-05-06 06:48:12 voltage 229
helper:
_98_statistics myStatDevice
Attributes:
IODev CUL433
comment power:1,avgpower
dblog exclude
current,energy,pf,state,.lastenergy,voltage,frequency
event-aggregator power:180:linear:mean
event-on-change-reading .*
fhem_Publish *:topic={"$base/$device/$name/$reading"}
room 1.Verbrauch,Revolt
stateFormat P: power E: energy V: voltage C: current Pf: pf
userattr fhem_Alias:textField-long fhem_Defaults:textField-long fhem_Disable:both,incoming,outgoing fhem_Forward:all,none fhem_Publish:textField-long fhem_Subscribe:textField-long
Zeigst du bitte auch noch die Einstellungen auf der HomeAssistant-Seite? Wenn ich das richtig verstanden habe, muss man dort erst angeben, was man abonnieren will (yaml editieren).
Falls du da was erstellen mußt, solltest du m.E. vorab noch die Vaiable $base belegen (unterschiedlich in Sende- und Empfangsrichtung):
attr mqttGeneric globalDefaults sub:base=fhem/set pub:base=fhem
Und für den Fall, dass du irgendwann mal was aus HomeAssistant heraus schalten willst, musst du auch die clientOrder ändern:
attr MQTT2_FHEM_Server clientOrder MQTT_GENERIC_BRIDGE MQTT2_DEVICE
Hallo und danke für den Hilfeversuch. Auf der HomeAssistant-Seite gibt es nur die MQTT-Optionen, siehe Screenshot. In der yaml habe ich nichts editiert und dort steht auch nichts zum Thema mqtt.
Die Variable $base zu belegen klingt gut. Wenn ich es richtig verstehe, handelt es sich dabei um einen Prefix und nicht um ein Topic?
Laut Doku hört HomeAssitant per Default auf das Topic "homeassistant".
Kann man vielleicht das sent topic bei FHEM angeben, so wie beim testen des MQTT2_SERVER?
Zitat von: Mark am 06 Mai 2022, 16:30:03
Hallo und danke für den Hilfeversuch. Auf der HomeAssistant-Seite gibt es nur die MQTT-Optionen, siehe Screenshot. In der yaml habe ich nichts editiert und dort steht auch nichts zum Thema mqtt.
Also:
- FHEM übermittelt keine "auto-Konfigurationsdaten" (nennt sich glaube ich autodiscovery)
- Kann sein, dass HomeAssistant den "homeassistant"-Topic automatisch abonniert, aber wenn, dann solltest du das so lassen, und ggf. überlegen, ob du in FHEM diesen "prefix" (als "$base") vergibst. Ich _glaube_ aber, das ist nicht der richtige Weg, denn das ist mAn. für autodiscovery gedacht, nicht für die eigentlichen Nutzdaten.
Ich kenne nur das, was die User hier posten, und das sieht dann z.B. so aus:
Zitat von: Dominik83 am 24 April 2022, 23:18:30
In der HA Conf steht folgendes:
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"
optimistic: true
- 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"
icon: "mdi:desk-lamp"
Ergo meine ich, dass dir da was vergleichbares fehlt und du das händisch konfigurieren musst (wie auch immer die Datei heißt...).
Zitat
Die Variable $base zu belegen klingt gut. Wenn ich es richtig verstehe, handelt es sich dabei um einen Prefix und nicht um ein Topic?
Laut Doku hört HomeAssitant per Default auf das Topic "homeassistant".
Es handelt sich um eine Variable, die man dann bei den "untergeordneten Devices" in FHEM nutzen kann, und zwar u.A. eben als Teil des Topics. Würd das in diesem Fall auch als "Prefix" bezeichnen, der Mechanismus an sich ist aber universeller, und dein mqttPublish-Attribut enthält die Variable ja auch schon...
(Ergo: just do it, ich hatte mir schon was dabei gedacht ::) ).
Zitat(Ergo: just do it, ich hatte mir schon was dabei gedacht ::) ).
Hatte ich doch direkt gemacht :D
Zitat- FHEM übermittelt keine "auto-Konfigurationsdaten" (nennt sich glaube ich autodiscovery)
Ahh, okay. Dann kann ich ja lange warten...
Habe jetzt im Homassistant yaml manuell einen Sensor angelegt.
sensor:
- platform: mqtt
state_topic: "fhem/Revolt_71a6/power/power"
name: revolt
unit_of_measurement: "W"
device_class: "power"
state_class: "measurement"Und siehe da, die Werte kommen heile an.
Klasse, das ist ein Anfang.
Vielen Dank für die Hilfe.
Hallo zusammen,
ich habe mithilfe dieses Forums es geschafft, meine 15 Rollos von Fhem aus nach Homeassistant durchzuschleifen und auch zu steuern.
Allerdings stelle ich nun fest, dass fhem bei aktiviertem MQTT2_CLIENT sehr träge reagiert. Bspw. wirft alexa nun Fehlermeldungen wie lexa: read: end of file reached while sysread.
Vorher konnte ich diese Verhalten nicht beobachten. Hier einmal die Definitionen meiner MQTT2 Geräte:
defmod ha_MQTT2 MQTT2_CLIENT 192.168.0.20:1883
attr ha_MQTT2 clientId mqtt_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 mqtt_fhem
setstate ha_MQTT2 opened
setstate ha_MQTT2 2022-05-28 23:02:00 state opened
defmod mqttGeneric MQTT_GENERIC_BRIDGE mqtt room=HASS
attr mqttGeneric IODev ha_MQTT2
attr mqttGeneric globalDefaults sub:qos=0 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: 4238421 out: 22445 devices: 17
setstate mqttGeneric 2022-05-28 23:02:00 device-count 17
setstate mqttGeneric 2022-05-29 10:41:30 incoming-count 4238421
setstate mqttGeneric 2022-05-29 08:43:05 outgoing-count 22445
setstate mqttGeneric 2022-05-29 08:43:05 transmission-state outgoing publish sent
setstate mqttGeneric 2022-03-12 21:17:15 updated-reading-count 0
setstate mqttGeneric 2022-05-28 23:59:18 updated-set-count 103
Fällt euch hier auf den ersten Blick etwas auf? Ich stehe ein bisschen auf dem Schlauch. Würde mich über Hilfe freuen :)
ZitatAllerdings stelle ich nun fest, dass fhem bei aktiviertem MQTT2_CLIENT sehr träge reagiert.
Woher stammt die Vermutung, dass die Ursache MQTT2_CLIENT ist?
Existiert das Problem auch:
- wenn qosMaxQueueLength nicht gesetzt ist?
- wenn MQTT2_CLIENT mit einem nicht vorhandenen MQTT Server konfiguriert ist?
Wieviele Events pro Minute muss das System verarbeiten, wieviele FHEM-Definitionen gibt es und auf welchem Hardware laeuft FHEM?
Sieht man zeitliche Aussetzer im "attr global verbose 5" FHEM-log?
Kling nach einer Schleife...?!? sub und pub sollten unterschiedlich sein, globalPublish ist nur zu empfehlen, wenn man weiß, was es bewirkt...
Zitat von: rudolfkoenig am 29 Mai 2022, 11:22:07
Woher stammt die Vermutung, dass die Ursache MQTT2_CLIENT ist?
Existiert das Problem auch:
- wenn qosMaxQueueLength nicht gesetzt ist?
- wenn MQTT2_CLIENT mit einem nicht vorhandenen MQTT Server konfiguriert ist?
Wieviele Events pro Minute muss das System verarbeiten, wieviele FHEM-Definitionen gibt es und auf welchem Hardware laeuft FHEM?
Sieht man zeitliche Aussetzer im "attr global verbose 5" FHEM-log?
Sofern mein MQTT2_CLIENT nicht verbunden ist, reagiert das system flott.
Die beiden anderen Punkte konnte ich gerade mangels Zeit nicht ausreichend testen. Wie bekomme ich denn raus, wieviele Events pro Minute hier ankommen? Fhem läuft auf einem Pi3B, bisher völlig ohne Probleme.
Zitat von: Beta-User am 29 Mai 2022, 12:00:09
Kling nach einer Schleife...?!? sub und pub sollten unterschiedlich sein, globalPublish ist nur zu empfehlen, wenn man weiß, was es bewirkt...
Was ist denn die alternative zu global publish? Habe nur 15 Rollos und ein Thermostatdummy, die gepusht bzw. auf die Befehle gehorcht werden soll. Horche ich vielleicht auf alles? Im Log tauchen nämlichnauch Sachen auf, die eigentlich nur an Homeassistant gehen sollen (Shellyklingel bspw.)
Hier jedenfalls mal das log mit verbose 5:
Edit: Nun im Anhang.
Zitat von: jazzor am 29 Mai 2022, 12:43:27
Was ist denn die alternative zu global publish?
mqttPublish an den Geräten _konkret_ und _so_ zu setzen, dass _nur_ das raus geht, was auch interessiert. Bei 22k publishes (dein list) stellt sich die Frage, über welchen Zeitraum das zusammengekommen ist...
Zitat
Habe nur 15 Rollos und ein Thermostatdummy, die gepusht bzw. auf die Befehle gehorcht werden soll. Horche ich vielleicht auf alles? Im Log tauchen nämlichnauch Sachen auf, die eigentlich nur an Homeassistant gehen sollen (Shellyklingel bspw.)
Das ist ein (etwas) anderes Problem: Du hast (@MQTT2_CLIENT)
a) keine Einschränkung der subscriptions, und
b) keine geänderte clientOrder
=> es gibt ein MQTT2_DEVICE, das "alles" bekommt und auch entsprechend viele Events erzeugt (dein list: 4,2Mio Events...). Stellt sich wieder die Frage, in welchem Zeitraum...
(Thermostatdummy klingt auch gruselig, und das log wäre in einem Anhang besser aufgehoben gewesen).
Zitat von: Beta-User am 30 Mai 2022, 10:57:43
mqttPublish an den Geräten _konkret_ und _so_ zu setzen, dass _nur_ das raus geht, was auch interessiert. Bei 22k publishes (dein list) stellt sich die Frage, über welchen Zeitraum das zusammengekommen ist...
Ha Fehlannnahme dann meinerseits, ich dachte, nur die Readingsänderungen würden gepusht. Wie würde ich denn bspw den Status und das Reading "homekit_pos" publishen? Mit mqttPublish einfach status,homekit_pos eingeben bei dem Gerät?
Zitat von: Beta-User am 30 Mai 2022, 10:57:43
Das ist ein (etwas) anderes Problem: Du hast (@MQTT2_CLIENT)
a) keine Einschränkung der subscriptions, und
Verstehe ich, kümmere ich mich drum.
Zitat von: Beta-User am 30 Mai 2022, 10:57:43
b) keine geänderte clientOrder
Hier kann ich dir nicht folgen. Finde bei keinem meiner Geräte das Attribut clientOrder. Kannst du mir sagen, wo ich suchen muss?
Zitat von: Beta-User am 30 Mai 2022, 10:57:43
(Thermostatdummy klingt auch gruselig, und das log wäre in einem Anhang besser aufgehoben gewesen).
Das Log hat sich erfolgreich mehrmals den code-Tags widersetzt. Thermostatdummy ist leider eine Notwendigkeit, und der Name leider historisch gewachsen :P
Zitat von: jazzor am 30 Mai 2022, 20:34:25
Ha Fehlannnahme dann meinerseits, ich dachte, nur die Readingsänderungen würden gepusht. Wie würde ich denn bspw den Status und das Reading "homekit_pos" publishen? Mit mqttPublish einfach status,homekit_pos eingeben bei dem Gerät?
MQTT_GENERIC_BRIDGE reagiert auf "Events". Jedes "erfasste" Event wird auch gepublisht...
...jetzt habe ich die commandref schon so umgestellt, dass man die Beispiele direkt sieht, wenn man das Attribut auswählt, da steht nichts von einem Komma als Trenner...
"Status" bzw. "status" ist vermutlich "state"? Dann würde ich das auch direkt auf den "Haupttopic" publishen => unterschiedliche Topic-Angaben...
Zitat
Hier kann ich dir nicht folgen. Finde bei keinem meiner Geräte das Attribut clientOrder.
Bei meinem MQTT2_CLIENT-Device ist es da... Dein FHEM ist aktuell?
ZitatDas Log hat sich erfolgreich mehrmals den code-Tags widersetzt.
Ärgerliches, aber bekanntes Problem mit der Foren-Software. Daher der Hinweis, dass es in solchen "länglichen" Fällen besser als Anhang gepostet werden sollte.
Zitat
Thermostatdummy ist leider eine Notwendigkeit, und der Name leider historisch gewachsen :P
Wir können gerne wetten, aber nicht in diesem Thread...
Meine Erfahrung ist die: 95% aller irgendwo zu findenden TYPE=dummy sind überflüssig wie ein Kropf und machen das Gesamtsystem nicht einfacher zu durchschauen. (just my2ct).
Weitere Anmerkungen:
- Um das Einrichten zu vereinfachen, unterstützt MQTT_GENERIC_BRIDGE attrTemplate. Damit muss man sich als User eigentlich gar nicht mit den ganzen Details rumschlagen, sondern hat die Option, direkt einen "Satz" zusammenpassender Attribute zu erhalten (base_settings_to_MQTT_GENERIC_BRIDGE)...
Das macht aber z.B. aus guten Gründen keine retain-publishes, die dann dazu führen, dass man sowas im Log hat ;D :
2022.05.29 12:31:28 5: Starting notify loop for mqttGeneric, 23556 event(s),
- Es gibt auch für den einen oder anderen konkreten Anwendungsfall attrTemplate, um die "Klienten" der Bridge zu konfigurieren, allerdings bisher nicht für ROLLO (bei dem sich eh' die Frage stellt, warum es nicht invertiert wird, statt irgendeine Logik für das "homekit_pos"-Handling drumrum zu basteln... Mit gesetztem rl_type/HomeKit verhält sich ROLLO halt wie andere Kauf-Rollladenaktoren auch (soweit mir bekannt) bzw. wie Tasmota oder Shelly im Shutter-Modus... )
(Das mit den attrTemplate für MGB ist sicher nicht perfekt, das kann man vermutlich durchaus noch verbessern, keine Frage).
So, als aller-allererstes ein dickes DANKESCHÖN! :-)
Deine Hinweise waren genau die richtigen: Angefangen mit einer alten Version, über die Subscriptions bis zur clientOrder.
Nach ersten Tests scheint es jetzt vernünftig zu funktionieren, trotzdem würde ich mich freuen, wenn du mir sagen könntest, ob ich in dieser Konfiguration jetzt 'sauber' bin:
MQTT2_CLIENT:
defmod ha_MQTT2 MQTT2_CLIENT 192.168.0.20:1883
attr ha_MQTT2 clientId fhem
attr ha_MQTT2 clientOrder MQTT_GENERIC_BRIDGE MQTT2_DEVICE
attr ha_MQTT2 icon mqtt
attr ha_MQTT2 ignoreRegexp cmnd/[^:"]+:|homeassistant/[^:"]+/config:|shellies/[^:"]+/command:|zigbee2mqtt/[^/]+/set:|milight/0x[0-9a-fA-F]{1,4}/.*/[0-8]:|tasmota/discovery/
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 subscriptions fhem/set/#
attr ha_MQTT2 username mqtt_fhem
MQTT_GENERIC_BRIDGE :
defmod mqttGeneric MQTT_GENERIC_BRIDGE mqtt room=MQTT_HA
attr mqttGeneric IODev ha_MQTT2
attr mqttGeneric icon mqtt_bridge_1
attr mqttGeneric room MQTT
attr mqttGeneric stateFormat in: incoming-count out: outgoing-count devices: device-count
attr mqttGeneric verbose 0
Und bei den Rollos habe ich exemplarisch:
attr Rollo_Nr_01 mqttPublish state|homekit_pos:topic={"fhem/$device/$name"}
attr Rollo_Nr_01 mqttSubscribe state:stopic={"fhem/set/Rollo_Nr_01/state"} position_homekit:stopic={"fhem/set/Rollo_Nr_01/homekit_pos"}
attr Rollo_Nr_01
Mir ist allerdings noch aufgefallen, dass beim Horchen auf "fhem/#" mit Mosquito/Homeassistant als erstes die Ganze Litanei eines Rollos kommt. Und zwar nicht nur state und homekit_pos sondern alle folgenden:
fhem/Rollo_Nr_01/homekit_pos
fhem/Rollo_Nr_01/position
fhem/Rollo_Nr_01/drive-type
fhem/Rollo_Nr_01/last_drive
fhem/Rollo_Nr_01/desired_position
fhem/Rollo_Nr_01/command
fhem/Rollo_Nr_01/state
Kann das sein, dass die aus Homeassistant selbst republished werden? Danke für die Hilfe! :)
Zitat von: jazzor am 02 Juni 2022, 19:37:10
So, als aller-allererstes ein dickes DANKESCHÖN! :-)
:) Danke für die Rückmeldung!
Zitat
Nach ersten Tests scheint es jetzt vernünftig zu funktionieren, trotzdem würde ich mich freuen, wenn du mir sagen könntest, ob ich in dieser Konfiguration jetzt 'sauber' bin:
Mir gefällt manches noch nicht, Kernpunkte: zu viel "Handarbeit", und "von außen" ist das Device nicht "standardkonform". Einen Rollladen will ich im Topic mit "pct" sehen, nicht mit "irgendwas, was grade da ist"...
Schnelle Stichworte: globalDefaults, $alias
Zitat
Mir ist allerdings noch aufgefallen, dass beim Horchen auf "fhem/#" mit Mosquito/Homeassistant als erstes die Ganze Litanei eines Rollos kommt. [...]
Kann das sein, dass die aus Homeassistant selbst republished werden? Danke für die Hilfe! :)
Das ist eine Folge der ehemaligen pauschalen Publisherei mit "retain"-Flag, würde ich behaupten. Habe leider keine Ahnung, wie die aus dem von dir verwendeten MQTT-Server zu löschen wären, vielleicht, indem eine leere Info ohne Flag auf den Topic gesendet wird (ist aber mühsam, schon klar). Bei Mosquitto gäbe es da einen Schalter in der config; ist der nicht gesetzt, sind die retain-Messages nach einem Neustart des Mosquitto (afaik) weg...
Nochmal ein dickes Dankeschön und kurz, falls zukünftig mal jemand ähnliche Problemchen haben sollte meine Lösung:
Zitat von: Beta-User am 03 Juni 2022, 09:10:50
zu viel "Handarbeit", und "von außen" ist das Device nicht "standardkonform". [...]
Schnelle Stichworte: globalDefaults, $alias
Habe deine Anmerkungen bzgl. Standardisierung umgesetzt.
Zitat von: Beta-User am 03 Juni 2022, 09:10:50
Das ist eine Folge der ehemaligen pauschalen Publisherei mit "retain"-Flag,
Absolut richtige Annahme. Ich habe die Software "MQTT-Explorer" genutzt, um alle alten retained-topics zu löschen. Das war jedenfalls die Lösung mit der schnellsten usability ;)
Vielen Dank nochmal!
Zitat von: gadget 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.
Kleiner Fehler: "password" anstatt "passwort"
Und inzwischen ist der Switch in HA als:
mqtt:
switch:
[..]einzubinden...
Moin moin,
der Thread hier hat mich schon recht weit gebracht, aber ich habe gerade ein Problem was mit etwas Kopfschmerzen bereitet... :(
Ich habe 2 Schalter angelegt,
Die Kommunikation FHEM -> HA funktioniert einwandfrei, aber bei der Kommunikation HA --> FHEM scheint es ein Problem zu geben.
In FHEM kann ich beide Schalter einzeln schalten und die werden auch korrekt in HA angezeigt.
Wenn ich aber in HA einen Schalter schalte, wird das (von HA?) an alle (beide) Topics gesendet, also es werden beide Schalter
gleich geschaltet.
Hier habe ich z.B. in HA nur den demoswitch "on" geschaltet:
SENT fhem/OG.gz.LI.TVLampe/state on
SENT fhem/demoswitch/state on
RCVD fhem/demoswitch/set on
RCVD fhem/OG.gz.LI.TVLampe/state on
RCVD fhem/demoswitch/state on
Wo liegt mein Fehler?
Mein MQTT-Client Device:
Internals:
BUF
CFGFN
Clients :MQTT2_DEVICE:MQTT_GENERIC_BRIDGE:
ClientsKeepOrder 1
DEF 192.168.1.221:1883
DeviceName 192.168.1.221:1883
FD 27
FUUID 6384e931-f33f-dd8f-3500-360ec9207d56c8e8
NAME ha_MQTT2
NR 264469
PARTIAL
STATE opened
TYPE MQTT2_CLIENT
WBCallback
clientId fhem
eventCount 26
lastMsgTime 1669663915.40313
nextOpenDelay 5
qosCnt 117
qosMaxQueueLength 100
MatchList:
1:MQTT2_DEVICE ^.
2:MQTT_GENERIC_BRIDGE ^.
READINGS:
2022-11-28 18:26:43 state opened
qosQueue:
Attributes:
DbLogExclude .*
clientId fhem
keepaliveTimeout 60
msgAfterConnect -r fhem/connection/status connected
msgBeforeDisconnect -r fhem/connection/status disconnected
qosMaxQueueLength 100
room Server
username hamqtt
Mein Bridge-Device:
Internals:
BUF
CFGFN
Clients :MQTT2_DEVICE:MQTT_GENERIC_BRIDGE:
ClientsKeepOrder 1
DEF 192.168.1.221:1883
DeviceName 192.168.1.221:1883
FD 27
FUUID 6384e931-f33f-dd8f-3500-360ec9207d56c8e8
NAME ha_MQTT2
NR 264469
PARTIAL
STATE opened
TYPE MQTT2_CLIENT
WBCallback
clientId fhem
eventCount 26
lastMsgTime 1669664156.19664
nextOpenDelay 5
qosCnt 117
qosMaxQueueLength 100
MatchList:
1:MQTT2_DEVICE ^.
2:MQTT_GENERIC_BRIDGE ^.
READINGS:
2022-11-28 18:26:43 state opened
qosQueue:
Attributes:
DbLogExclude .*
clientId fhem
keepaliveTimeout 60
msgAfterConnect -r fhem/connection/status connected
msgBeforeDisconnect -r fhem/connection/status disconnected
qosMaxQueueLength 100
room Server
username hamqtt
Schalter 1:
Internals:
CFGFN
FUUID 63844f3b-f33f-dd8f-a83f-828d26612b3735ed
LASTInputDev ha_MQTT2
MSGCNT 40
NAME demoswitch
NR 230561
STATE off
TYPE dummy
eventCount 93
ha_MQTT2_MSGCNT 40
ha_MQTT2_TIME 2022-11-28 20:29:23
READINGS:
2022-11-28 20:29:23 state off
Attributes:
DbLogExclude .*
mqttForward all
mqttSubscribe state:stopic={"$base/set"}
room HASS
setList on off
userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
webCmd on:off
Mein zweiter Schalter:
Internals:
DEF 0000F0FFFF FF F0
FUUID 5c443666-f33f-02b0-cd30-019682e96cc09e0f
IODev CUL_Stick
LASTInputDev ha_MQTT2
MSGCNT 28
NAME OG.gz.LI.TVLampe
NR 323
STATE off
TYPE IT
XMIT 0000f0ffff
XMITdimdown 00
XMITdimup 00
XMIToff f0
XMITon ff
eventCount 46
ha_MQTT2_MSGCNT 28
ha_MQTT2_TIME 2022-11-28 20:29:23
CODE:
1 0000f0ffff
READINGS:
2022-11-25 08:58:20 IODev CUL_Stick
2022-09-01 19:52:49 protocol V1
2022-11-28 20:29:23 state off
Attributes:
DbLogExclude .*
IODev CUL_Stick
genericDeviceType light
model itswitch
mqttSubscribe state:stopic={"$base/set"}
room HASS,Homekit,Licht
userattr OG.xx.LI.structType OG.xx.LI.structType_map mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long structexclude
Meine Config aus HA:
mqtt:
switch:
- unique_id: testswitch
name: "Test Switch"
state_topic: "fhem/demoswitch/state"
command_topic: "fhem/demoswitch/set"
payload_on: "on"
payload_off: "off"
state_on: "on"
state_off: "off"
qos: 0
retain: true
optimistic: false
- unique_id: GaestezimmerLicht
name: "GZ Lampe"
state_topic: "fhem/OG.gz.LI.TVLampe/state"
command_topic: "fhem/OG.gz.LI.TVLampe/set"
payload_on: "on"
payload_off: "off"
state_on: "on"
state_off: "off"
qos: 0
retain: true
optimistic: false
Für meine Ahoy-DTU hatte ich mal ein MQTT_Server Device erstellt, kann das ein Problem sein?
Wäre echt dankbar wenn jemand eine Idee hat, ich komme einfach keinen Schritt weiter :(
Danke!
a) warum zeigst du 2 mal denselben MQTT2_CLIENT? Dort wäre aber bitte die clientOrder passend zu setzen, sonst kann es mittelfristig komische Effekte geben....
b) An der MQTT_GENERIC_BRIDGE kann man sich anzeigen lassen, was sie kennt (get-Befehl). Da sollten beide Switches an sich korrekt auftauchen.
c) Die Event-Abfolge dürfte umgedreht sein. Bitte checke mal, ob das auf der Homeassistant-Seite korrekt konfiguriert ist. Es kommen nämlich scheinbar zwei messages rein, was bedeutet, dass FHEM alles korrekt macht.
Zitat von: Beta-User am 28 November 2022, 21:16:56
a) warum zeigst du 2 mal denselben MQTT2_CLIENT?
Fehler beim kopieren. Da sollte einmal ja list von der Matt-Bridge rein und nicht 2x der Client-Device...
Internals:
CFGFN
DEF mqtt room=HASS
FUUID 6384ea99-f33f-dd8f-ab18-8a5983514813fa1e
IODev ha_MQTT2
NAME mqttGeneric
NR 264699
NTFY_ORDER 70-mqttGeneric
STATE in: 48 out: 113 devices: 2
TYPE MQTT_GENERIC_BRIDGE
devspec room=HASS
eventCount 118
prefix mqtt
READINGS:
2022-11-28 18:06:34 IODev ha_MQTT2
2022-11-28 18:26:43 device-count 2
2022-11-28 21:31:28 incoming-count 48
2022-11-28 21:31:28 outgoing-count 113
2022-11-28 21:31:28 transmission-state outgoing publish sent
2022-11-28 18:06:33 updated-reading-count 0
2022-11-28 21:31:28 updated-set-count 84
devices:
:global:
:alias:
: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"}
OG.gz.LI.TVLampe:
:alias:
:publish:
:subscribe:
HASH(0x55e08ad6f5d0)
demoswitch:
:alias:
:publish:
:subscribe:
HASH(0x55e08aa134f8)
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 .*
globalDefaults sub:qos=2 pub:qos=0 retain=1 base={"fhem/$device"}
globalPublish *:topic={"fhem/$device/$reading"}
icon mqtt_bridge_1
room Server
stateFormat in: incoming-count out: outgoing-count devices: device-count
verbose 0
ZitatDort wäre aber bitte die clientOrder passend zu setzen, sonst kann es mittelfristig komische Effekte geben....
Danke für den Hinweis.Was wäre aber dann der richtige Eintrag?
Syntax ist ja
clientOrder [MQTT2_DEVICE] [MQTT_GENERIC_BRIDGE]Ich habe kein MQTT2_DEVICE angelegt. Gehört dann nur die Bridge da rein?
Zitatb) An der MQTT_GENERIC_BRIDGE kann man sich anzeigen lassen, was sie kennt (get-Befehl). Da sollten beide Switches an sich korrekt auftauchen.
Stimmt, das tun sie, alles korrekt. (get devlist)
Zitatc) Die Event-Abfolge dürfte umgedreht sein. Bitte checke mal, ob das auf der Homeassistant-Seite korrekt konfiguriert ist. Es kommen nämlich scheinbar zwei messages rein, was bedeutet, dass FHEM alles korrekt macht.
Ja das stimmt, die Event-Abfolge ist von unten nach oben zu lesen.
Wenn ich im HomeAssistant Broker auf alle Topics lausche (#) zeigt er mit diese Abfolge (ebenfalls von unten nach oben zu lesen)
Nachricht 7 empfangen auf fhem/OG.gz.LI.TVLampe/state um 21:47:
on
QoS: 0 - Retain: false
Nachricht 6 empfangen auf fhem/demoswitch/state um 21:47:
on
QoS: 0 - Retain: false
Nachricht 5 empfangen auf fhem/demoswitch/set um 21:47:
onAlles was ich nach meinem Wissensstand auf HA-Seite konfigurieren kann ist dies:
mqtt:
switch:
- unique_id: testswitch
name: "Test Switch"
state_topic: "fhem/demoswitch/state"
command_topic: "fhem/demoswitch/set"
payload_on: "on"
payload_off: "off"
state_on: "on"
state_off: "off"
qos: 0
retain: true
optimistic: false
- unique_id: GaestezimmerLicht
name: "GZ Lampe"
state_topic: "fhem/OG.gz.LI.TVLampe/state"
command_topic: "fhem/OG.gz.LI.TVLampe/set"
payload_on: "on"
payload_off: "off"
state_on: "on"
state_off: "off"
qos: 0
retain: true
optimistic: falseIn den Broker-Einstellungen kann ich sonst nur Ports, User sowie Birth/Last Will einstellen....
Zitat von: C0mmanda am 28 November 2022, 21:58:33
globalDefaults sub:qos=2 pub:qos=0 retain=1 base={"fhem/$device"}
globalPublish *:topic={"fhem/$device/$reading"}
[/code]
[...]
Danke für den Hinweis.Was wäre aber dann der richtige Eintrag?
Syntax ist ja clientOrder [MQTT2_DEVICE] [MQTT_GENERIC_BRIDGE]
Ich habe kein MQTT2_DEVICE angelegt. Gehört dann nur die Bridge da rein?
Brrr, ich habe da zum einen andere Vorstellungen zu fast allen Details und zum anderen als attrTemplate vercoded, was ich meine, was gut ist. Irgendwie sehe ich nicht so richtig ein, warum ich mir immer wieder die Finger wund schreibe (ist nicht persönlich gemeint). Im Wiki gibt es einen stub eines Artikels zu MQTT_GENERIC_BRIDGE, da ist erklärt, wie es (mAn.) funktioniert.
ZitatNachricht 7 empfangen auf fhem/OG.gz.LI.TVLampe/state um 21:47:
Ich habe keine Ahnung, wo #7 herkommt, und es paßt nicht zu dem, was du gezeigt hast (oder ich habe es übersehen)
Das müßte von dem anderen Switch in HASS kommen...
Zitat von: Beta-User am 28 November 2022, 22:06:36
Brrr, ich habe da zum einen andere Vorstellungen zu fast allen Details und zum anderen als attrTemplate vercoded, was ich meine, was gut ist. Irgendwie sehe ich nicht so richtig ein, warum ich mir immer wieder die Finger wund schreibe (ist nicht persönlich gemeint). Im Wiki gibt es einen stub eines Artikels zu MQTT_GENERIC_BRIDGE, da ist erklärt, wie es (mAn.) funktioniert.
Hm, ok, kann ich sogar verstehen...Habe aus Unwissenheit auch nur als funktionierend "bestätigte" configs kopiert weil überhaupt keine Ahnung von MQTT.
Ich werde mir das wiki nochmal vornehmen.
Aber zu den attrTemplates muss ich leider sagen: funktioniert bei mir nicht.
Der "OK" Button im zweiten Schritt erscheint bei mir nicht und ich kann die Konfiguration nicht abschliessen. (Getestet in Safari + Firefox am Rechner sowie auf Safari am Handy)
Siehe dazu den Screenshot.
Zitat
Ich habe keine Ahnung, wo #7 herkommt, und es paßt nicht zu dem, was du gezeigt hast (oder ich habe es übersehen)
Das müßte von dem anderen Switch in HASS kommen...
Den Verdacht hatte ich auch schon, konnte aber auch nix finden. Werde weiter forschen und mich ggf. melden.
Danke für die Unterstützung bis hierher.
Gruß
Danke für den Versuch, ich schau's mir die Tage an, warum das nicht mehr funktioniert...
Es sollte trotzdem vor dem "set" angezeigt werden, was alles passieren kann (allerdings ist es wegen der Optionen etwas unübersichtich). Vielleicht hilft es auch so schon mal weiter.
Zitat von: Beta-User am 28 November 2022, 22:38:03
Danke für den Versuch, ich schau's mir die Tage an, warum das nicht mehr funktioniert...
Hmm, habe das mit aktuellem FHEM auf dem Testsystem grade nachzustellen versucht, es ist mir aber nicht gelungen... Zuerst hat sich meine neu erstellte MGB den bereits vorhandenen MQTT2_CLIENT geschnappt - da war aber u.a. clientOrder schon gesetzt => keine Rückfrage. Danach habe ich einen weiteren MQTT2_CLIENT erstellt, und die MGB nochmal angelegt => das Dialogfeld wird ordnungsgemäß angezeigt, (u.a.) OK ist vorhanden.
Ist dein FHEM halbwegs aktuell und ggf. der Browsercache mal gelöscht (es gab einige updates zum FHEMWEB-js-script)?
Danke für's nachschauen.
Mein FHEM war -relativ- aktuell, hatte ich zuletzt vor ein oder zwei Wochen ge-updated.
Wie dem auch sei, heute nochmal ein Update gemacht, der attrTemplate setter hat funktioniert (lag aber vielleicht auch daran dass ich die Attribute mittlerweile manuell gesetzt hatte)
Dann bin ich noch einmal Schritt für Schritt das Wiki durchgegangen und habe alle Einstellungen gemacht und was soll ich sagen, aktuell funktioniert es scheinbar einwandfrei.
Werde jetzt mal in Ruhe Weitertesten und mich dann Schritt für Schritt an die eigentlichen devices machen.
Vielen Dank für den Schubs in die richtige Richtung!
Wenn ich wieder Probleme bekomme melde ich mich ;)
Danke & Gruß
Gerne und Danke für die Rückmeldung, dass es jetzt wohl deutlich vorangeht (und mein Geschreibsel anscheinend nicht völlig unleserlich ist).
Wir können gerne das Wiki verbessern und/oder auch neue/ergänzte attrTemplate (für die "Zieldevices") für alle bereitstellen. Ich hatte nur zwischenzeitlich etwas an Lust an dem Thema verloren, weil es anscheinend niemanden interessiert hatte bzw. auch niemand beitragen wollte...
Das "Geschreibsel" ist verständlich, man muss sich nur drauf einlassen ;)
Was ich damit meine, grundsätzlich ist das Grundkonstrukt mit den topics erst einmal recht einfach zu begreifen, was es für mich schwer gemacht hat
ist die "Mechanik" die dahinter steckt und vor allem auch die verschiedenen FHEM-Devices die man dafür benötigt.
Wenn man dem Wiki (habe jetzt nur das zur Generic_Bridge gelesen) folgt und erstmal alles einfach macht was du schreibst wird es einem schon klarer.
Wichtig zum verstehen ist vor allem das machen und beobachten wie du ja mehrfach auch geschrieben hast.
Einfach mal 2 Terminalfenster aufmachen und den Traffic beobachten. Dann wird einem schon vieles klarer.
Ich hatte bis vor 2 Tagen absolut 0 Plan von MQTT und kratze nur an der Oberfläche.
Die nächsten Tage werde ich weiter testen und sollte mir was auffallen melde ich mich.
Die einzige Kleinigkeit die mir aufgefallen ist ist die InfoBox beim Thema "Geräte steuern"
Kommt als MQTT-Server MQTT2_SERVER zum Einsatz, ist zwingend eine ClientID mit anzugeben, andernfalls werden die so generierten Messages eventuell nicht ausgewertet!
Ich habe erst nicht wirklich kapiert wo ich diese ClientID setzen muss, denke aber die gehört ins IO-Device (MQTT2_CLIENT). Das IO-Dev wird aber "Ewigkeiten" früher behandelt.
Nur eine Kleinigkeit...
Den Fortgeschrittenen-Teil muss ich noch durchgehen, dazu kann ich noch nichts sagen ;)
Also long-story short: Wer dem Wiki genau folgt und sich Zeit nimmt der schafft es das MQTT erstmal lauffähig zu bekommen.
Mit neue/ergänzte attrTemplates für die Zieldevices meinst du für MQTT2_DEVICEs?
Was mich jetzt aber noch interessiert:
Ich habe für meine Ahoy-DTU vor einiger Zeit stumpf einen MQTT-Server erstellt (einfach nur "define MQTT2_SERVER 1883 global" und "attr autocreate no", sonst nichts) und für die Ahoy ein MQTT_DEVICE erstellt. Da (d)ein AttrTemplate drüber gejagt und seitdem läuft es einfach.
Ist das i.O. so oder kann/sollte man das "eleganter" lösen wenn die MQTT-Zoo wächst?
Danke & Gruß
Zitat von: C0mmanda am 29 November 2022, 23:36:10
Das "Geschreibsel" ist verständlich, man muss sich nur drauf einlassen ;)
THX!
Das Zusammenspiel der verschiedenen Ebenen ist in der Tat nicht ganz einfach, daher der Versuch, das etwas zu standardisieren und "auf einen Rutsch" was funktionierendes "verteilen" zu können.
ZitatDie einzige Kleinigkeit die mir aufgefallen ist ist die InfoBox beim Thema "Geräte steuern"
Kommt als MQTT-Server MQTT2_SERVER zum Einsatz, ist zwingend eine ClientID mit anzugeben, andernfalls werden die so generierten Messages eventuell nicht ausgewertet!
Danke für den Hinweis, das Problem bezieht sich auf "mosquitto_pub" - damit funktioniert autocreate nur, wenn man (auf der Kommandozeile) bei der Verwendung des Tools diese Angabe explizit macht (und was anderes nimmt, als das, was das Tool sonst automatisch generiert!).
ZitatDen Fortgeschrittenen-Teil muss ich noch durchgehen, dazu kann ich noch nichts sagen ;)
Das ist der eigentliche "stub" und da findet sich auch nur zusammenkopiert, was Hexenmeister mal an Beispielen in seinem Thread zusammengeschrieben hat. Müßte mal formatiert und redigiert werden...
ZitatMit neue/ergänzte attrTemplates für die Zieldevices meinst du für MQTT2_DEVICEs?
Nope. attrTemplate funktioniert auch für MQTT_GENERIC_BRIDGE, und dort ist der Mechanismus so umgesetzt, dass man über den Umweg der MGB-Instanz auch beliebige andere Geräte "durchkonfigurieren" kann, so dass z.B. ein CUL_HM-Rollladen am Ende genauso gesteuert werden kann wie ein ZWave-Modell, also z.B. dann von HomeAssistant aus genau identisch aussieht!
Zitat
Was mich jetzt aber noch interessiert:
Ich habe für meine Ahoy-DTU vor einiger Zeit stumpf einen MQTT-Server erstellt (einfach nur "define MQTT2_SERVER 1883 global" und "attr autocreate no", sonst nichts) und für die Ahoy ein MQTT_DEVICE erstellt. Da (d)ein AttrTemplate drüber gejagt und seitdem läuft es einfach.
Ist das i.O. so oder kann/sollte man das "eleganter" lösen wenn die MQTT-Zoo wächst?
So sollte es sein: attrTemplate drüberbügeln und freuen, dass die Dinge funktional sind und sich jemand Gedanken dazu gemacht hat, wie es sinnvoll sein könnte. Klappt leider nicht immer, und offenbar gehe ich gelegentlich auch dem einen oder anderen Nutzer etwas auf den Keks, wenn ich was noch nicht optimal finde und dann weiter nachbohre oder auf "gewisse Standards" poche. Meistens findet sich dann aber früher oder später jemand, der dann doch ein Einsehen hat...
Grade bei den früh entstandenen attrTemplate (für M2D) kann es aber schon sein, dass das heute etwas anders aussehen würde, also einfach mal kritisch beobachten, ob das alles "gut" ist, ist auf keinen Fall verboten ;) .
Zitat
Was mich jetzt aber noch interessiert:
Ich habe für meine Ahoy-DTU vor einiger Zeit stumpf einen MQTT-Server erstellt (einfach nur "define MQTT2_SERVER 1883 global" und "attr autocreate no", sonst nichts) und für die Ahoy ein MQTT_DEVICE erstellt. Da (d)ein AttrTemplate drüber gejagt und seitdem läuft es einfach.
Ist das i.O. so oder kann/sollte man das "eleganter" lösen wenn die MQTT-Zoo wächst?
Es ist zum Mäuse melken.
Jetzt war ich froh mit oben genannter Config gut zu fahren und das sie funktioniert (sogar Auto-Discovery bei HA hat mit der Ahoy-DTU funktioniert) und nun geht nix mehr nachdem ich
die Verbindung FHEM <-> HA "korrekt" am laufen habe...
Es wird von FHEM nichts mehr an HA weitergeleitet von der Ahoy, keine topics und dementsprechend geht auch kein Auto-Discover mehr.
Gibt es da eine Erklärung? Wie kann ich FHEM beibringen alles von der Ahoy 1:1 an HA weiterzuleiten?
Finde seit gestern keine Lösung... :(
Das ist hier OT, aber mache mal ein update (es sollte was zu M2S und M2C geben, wenn du update check abfragst).
https://github.com/oznu/homebridge-config-ui-x (https://github.com/oznu/homebridge-config-ui-x)
Hallo zusammen,
ich habe seit einem Jahr Erfogreich eine MQQT Verbindung zwischen FHEM und HASS so wie hier beschrieben laufen.
Ich kann auch alles sehen und Schalten. Aber Inzwischen mehr Errors als sonst was.
habe aber extrem viele :
022.12.02 15:48:40 1 : 192.168.178.151:1883 disconnected, waiting to reappear (mqtt)
2022.12.02 15:48:40 1 : 192.168.178.151:1883 reappeared (mqtt)
2022.12.02 15:48:40 1 : 192.168.178.151:1883 disconnected, waiting to reappear (mqtt)
2022.12.02 15:48:41 1 : 192.168.178.151:1883 reappeared (mqtt)
2022.12.02 15:48:41 1 : 192.168.178.151:1883 disconnected, waiting to reappear (mqtt)
2022.12.02 15:48:41 1 : 192.168.178.151:1883 reappeared (mqtt)
2022.12.02 15:48:41 1 : 192.168.178.151:1883 disconnected, waiting to reappear (mqtt)
2022.12.02 15:48:41 1 : 192.168.178.151:1883 reappeared (mqtt)
2022.12.02 15:48:41 1 : 192.168.178.151:1883 disconnected, waiting to reappear (mqtt)
2022.12.02 15:48:41 1 : 192.168.178.151:1883 reappeared (mqtt)
2022.12.02 15:48:41 1 : 192.168.178.151:1883 disconnected, waiting to reappear (mqtt)
2022.12.02 15:48:41 1 : 192.168.178.151:1883 reappeared (mqtt)
2022.12.02 15:48:41 1 : 192.168.178.151:1883 disconnected, waiting to reappear (mqtt)
2022.12.02 15:48:41 1 : 192.168.178.151:1883 reappeared (mqtt)
2022.12.02 15:48:41 1 : 192.168.178.151:1883 disconnected, waiting to reappear (mqtt)
2022.12.02 15:48:41 1 : 192.168.178.151:1883 reappeared (mqtt)
2022.12.02 15:48:41 1 : 192.168.178.151:1883 disconnected, waiting to reappear (mqtt)
2022.12.02 15:48:41 1 : 192.168.178.151:1883 reappeared (mqtt)
2022.12.02 15:48:41 1 : 192.168.178.151:1883 disconnected, waiting to reappear (mqtt)
2022.12.02 15:48:41 1 : 192.168.178.151:1883 reappeared (mqtt)
2022.12.02 15:48:41 1 : 192.168.178.151:1883 disconnected, waiting to reappear (mqtt)
2022.12.02 15:48:41 1 : 192.168.178.151:1883 reappeared (mqtt)
2022.12.02 15:48:41 1 : 192.168.178.151:1883 disconnected, waiting to reappear (mqtt)
Fehlermeldungen. So dass das inzwischen echt nicht mehr Rund läuft. die 151 ist der Broker von Hass.
Einer eien Idee was ich tun kann ?
Hier das Gegenlog von Hass :
error: received null username or password for unpwd check
2022-12-02 15:59:52: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:52: New connection from 192.168.178.118:45402 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:52: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:52: New connection from 192.168.178.118:45404 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:52: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:52: New connection from 192.168.178.118:45414 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:52: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:53: New connection from 192.168.178.118:45424 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:53: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:53: New connection from 192.168.178.118:45436 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:53: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:53: New connection from 192.168.178.118:45448 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:53: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:53: New connection from 192.168.178.118:45464 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:53: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:53: New connection from 192.168.178.118:45466 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:53: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:53: New connection from 192.168.178.118:45478 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:53: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:53: New connection from 192.168.178.118:45494 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:53: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:53: New connection from 192.168.178.118:45502 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:53: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:53: New connection from 192.168.178.118:45512 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:53: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:53: New connection from 192.168.178.118:45528 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:53: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:53: New connection from 192.168.178.118:45530 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:53: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:53: New connection from 192.168.178.118:45544 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:53: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:53: New connection from 192.168.178.118:45560 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:53: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:53: New connection from 192.168.178.118:45568 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:53: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:53: New connection from 192.168.178.118:45576 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:53: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:53: New connection from 192.168.178.118:45578 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:53: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:53: New connection from 192.168.178.118:45584 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:53: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:53: New connection from 192.168.178.118:45590 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:53: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:53: New connection from 192.168.178.118:45602 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:53: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:53: New connection from 192.168.178.118:45614 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:53: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:54: New connection from 192.168.178.118:45628 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:54: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:54: New connection from 192.168.178.118:45632 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:54: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:54: New connection from 192.168.178.118:45648 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:54: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:54: New connection from 192.168.178.118:45664 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:54: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:54: New connection from 192.168.178.118:45668 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:54: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:54: New connection from 192.168.178.118:45678 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:54: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:54: New connection from 192.168.178.118:45682 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:54: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:54: New connection from 192.168.178.118:45694 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:54: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:54: New connection from 192.168.178.118:45696 on port 1883.
error: received null username or password for unpwd check
2022-12-02 15:59:54: Client <unknown> disconnected, not authorised.
2022-12-02 15:59:54: New connection from 192.168.178.118:45710 on port 1883.
error: received null username or password for unpwd check
Ich habe Benutzer und Passwort 100 mal gecheckt.
Danke und Gruß,
Andi
Vermutlich solltest du zu dem Thema einen gesonderten Thread aufmachen.
Allgemeine Hinweise und Anmerkungen:
- FHEM ist aktuell?
- Das scheint MQTT2_CLIENT zu sein? Mit welcher Art Gegenstelle (mosquitto? welche Version?)? (Evtl. braucht man nach einem update credentials?)
- Wie ist die ClientID gesetzt von der MQTT2_CLIENT-Instanz?
- Gibt es weitere Clients, die ggf. dieselbe ClientId nutzen?
- Verbindung? WLAN, LAN, PowerLAN...?
Zitat von: Beta-User am 02 Dezember 2022, 16:04:39
Vermutlich solltest du zu dem Thema einen gesonderten Thread aufmachen.
Allgemeine Hinweise und Anmerkungen:
- FHEM ist aktuell?
- Das scheint MQTT2_CLIENT zu sein? Mit welcher Art Gegenstelle (mosquitto? welche Version?)? (Evtl. braucht man nach einem update credentials?)
- Wie ist die ClientID gesetzt von der MQTT2_CLIENT-Instanz?
- Gibt es weitere Clients, die ggf. dieselbe ClientId nutzen?
- Verbindung? WLAN, LAN, PowerLAN...?
- Fhem ist aktuell
- Das ist ein MQTT2 Client, ja
- Gegenstelle ist mosquitto in Homeassistant, neuste Version
- Verbindung ist LAN Gbit auf beiden Seiten
- Client ID : fhem Ich habe nur FHem als Sender und Homeassistantals Empfänger. Ich kenne mich mit der Funktion der Client ID aber auch nicht wirklich aus
AUf jeden Fall schon einmal Danke für Deine ANtwort
mosquitto will (per default) in/ab V. 2.0, dass man sich mit Usernamen und Passwort anmeldet. Kann sein, dass das der Fehler ist (keine Ahnung, was dazu wann wie im Log zu finden ist).
Wenn es wirklich nur zwei Clients sind, darf halt deren ClientId nicht identisch sein, sonst wird die Verbindung typischerweise immer abgewiesen bzw. geschlossen. Ob das der Fall ist, kannst nur du sagen, im Zweifel würde ich in der Konstellation halt mal die ClientID am M2C einfach "anders" setzen als bisher. Wenn nur MGB was mit den Daten anfängt, sollte das komplett unkritisch sein; wenn MQTT2_DEVICE-Instanzen da sind, die die ClientID in die readingList übernommen haben, werden die halt nicht mehr beliefert (was einer der Gründe ist, warum ich immer empfehle, diese Angabe aus der readingList zu entfernen).
CLient ID´s sind Unterschiedlich.
Ich kann ja auch alle Topics Empfangen und senden. Halt nur diese Sekündlichen Fehlermeldungen spamen das Log zu und
dann irgendwann geht mal ein Topic durch, weil zu viele Fehlermeldungen.
OK, dann mach bitte einen neuen Thread dazu auf, damit Rudi das ggf. gesondert mal ansieht. Bitte dazu die notwendigen Infos sauber zusammenfassen (udn vielleicht verbose am MQTT2_CLEINT mal hochsetzen, damit vielleicht mehr zu sehen ist).
Hallo zusammen,
auch ich spiele mit dem Gedanken aus HA meine fhem Devices zu steuern. Vor Allem wird die 1-wire und Enocean Integration in HA ziemlich schlecht unterstützt. Welche Erfahrungen gibt es mit der mqtt-Lösung. Funktioniert die Anbindung zuverlässig in beide Richtungen, d.h. meldet fhem den neuen Status des Devices auch korrekt an HA zurück?
Zigbee Devices werde ich alle nach HA schieben und fhem soll als 1-wire und Enocean GW dienen.
Wäre super, wenn Ihr Eure Erfahrungen mit dieser Lösung teilen könntet und was man an Aufwand rechnen muss, bei je 20 Sensoren und Aktoren (Hauptsächlich FTS14)
Danke Spartacus.
Zitat von: Spartacus am 19 Januar 2023, 16:53:21
Hallo zusammen,
auch ich spiele mit dem Gedanken aus HA meine fhem Devices zu steuern. Vor Allem wird die 1-wire und Enocean Integration in HA ziemlich schlecht unterstützt. Welche Erfahrungen gibt es mit der mqtt-Lösung. Funktioniert die Anbindung zuverlässig in beide Richtungen, d.h. meldet fhem den neuen Status des Devices auch korrekt an HA zurück?
Zigbee Devices werde ich alle nach HA schieben und fhem soll als 1-wire und Enocean GW dienen.
Wäre super, wenn Ihr Eure Erfahrungen mit dieser Lösung teilen könntet und was man an Aufwand rechnen muss, bei je 20 Sensoren und Aktoren (Hauptsächlich FTS14)
Danke Spartacus.
Die Kommunikation und Rückmeldung HA<->FHEM klappt absolut problemlos wenn man es einmal korrekt eingestellt und verstanden hat.
Die 20 Sensoren/Aktoren sind dann vermutlich in 1 Stunde angelegt.
Der große Zeitaufwand bei mir war es MQTT soweit zu verstehen dass ich es korrekt einstellen kann ;) Denke das waren ein paar Stündchen.
Muss aber auch sagen: Ich habe keine Langzeiterfahrung. Ich habe Home Assistant bereits wieder aufgegeben. Ohne zu coden
geht da meiner Meinung nach nix und mir fehlt einfach die Zeit sich da komplett neu einzuarbeiten. Dachte ich kann alles über das UI machen.
Habe aktuell lediglich meinen iCloud.Account von HA in FHEM per MQTT eingebunden da FHEM dies nunmal nicht kann.
(zum tracken falls GeoFancy mal wieder klemmt)
Hallo C0mmanda,
vielen Dank für Dein Feedback. Ich werde mir das mal MQTT-Thema mal ansehen. Ich muss auch sagen, HA ist schon ganz nett, wenn man mal flux was zusammenschrauben will. Struktur ist allerdings schwierig und dann versagt auch der visuelle Editor. Das finde ich etwas schade! Es gibt allerdings viele Community addons und man findet fast alles, was man schon immer gerne in fhem gehabt hätte. (z.B. WE-Connect von VW war in 5min installiert und die Standheizung vom Golf 7 wird über den Viessmann Außenfühler angesteuert.)
Ich gucke mal, wie sich enocean, 1-wire und duofern per mqtt anbinden lassen. Das wird, wie gesagt, von HA nicht wirklich gut unterstützt.
Enocean plane ich sowieso über kurz oder lang rauszuschmeißen, da es funktechnisch einfach Mist ist und viel zu teuer. Mein Zigbee Netzwerk läuft jetzt seit 3 Jahren und das absolut störungsfrei. Meine 1-wire laufen aktuell parallel zu den aqara Multisensoren und liefern ziemlich genau die selben Werte, von daher ist das auch ersetzbar....nochmals Danke für Dein Feedback!
Spartacus
Hallo zusammen,
ich habe mich heute mit der MGB beschäftigt und habe es auch dank der tollen Anleitung auf Seite 1 hibekommen, einen enocean Switch in HA zu integrieren.
Allerdings scheitere ich an meinen 1-wire Sensoren. Das kommt in HA einfach nicht an. Zunächst wollte dich das Reading "temperature" verarbeiten.
Config in HA:
sensor:
- name: 1-wire
state_topic: "fhem/GH.in.1W.DS2438/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"
Der Sensor in fhem:
Internals:
CFGFN Config/98-1-Wire.cfg
DEF DS2438 09DB84000003
ERRCOUNT 0
ERRSTATE 0
FUUID 5df503ed-f33f-788a-2661-f28484a8c00af383
INTERVAL 300
IODev 1Wire
NAME GH.in.1W.DS2438
NEXTSEND 1674767588.22131
NOTIFYDEV global
NR 881
NTFY_ORDER 50-GH.in.1W.DS2438
OW_FAMILY 26
OW_ID 09DB84000003
PRESENT 1
ROM_ID 26.09DB84000003.EC
STATE T: 2.50°C, H: 85.47 %
TYPE OWMULTI
eventCount 27
offset 0
Helper:
DBLOG:
Feuchte:
logdb:
TIME 1674767288.47532
VALUE 85.47
Taupunkt:
logdb:
TIME 1674767288.47532
VALUE 0.3
absFeuchte:
logdb:
TIME 1674767288.47532
VALUE 4.9
temperature:
logdb:
TIME 1674767288.47532
VALUE 2.5
READINGS:
2023-01-26 22:13:08 Feuchte 85.47
2023-01-26 16:37:42 IODev 1Wire
2023-01-26 22:08:08 Taupunkt 0.3
2023-01-26 22:13:08 VDD 5.00
2023-01-26 22:08:08 absFeuchte 4.9
2023-01-26 22:13:08 state Feuchte: 85.47 % (T: 2.5 °C vs: 0.00 V vs.t: 0.00 Vs)
2023-01-26 22:13:08 temperature 2.5
2023-01-26 22:13:08 time 0
2023-01-26 22:13:08 vsense 0
2023-01-26 22:13:08 vsense.t 0
owg_val:
2.48828125
5
3.58
0
0
0
0
tempf:
factor 1
offset 0
Attributes:
DbLogInclude temperature,Feuchte,Taupunkt,absFeuchte
IODev 1Wire
VFunction (161.29 * V / VDD - 25.8065)/(1.0546 - 0.00216 * T)
VName Feuchte
VUnit %
alias DS2438
comment Sensor: SHT35
event-min-interval .*:600
group Sensoren
icon temperature_humidity
model DS2438
mqttForward all
mqttPublish temperature:topic={"$base/$device/temperature"}
room 98-Geräte -> 1-Wire,HASS
stateFormat {sprintf("T: %.2f°C, H: %.2f %%",ReadingsVal("$name","temperature",0),ReadingsVal("$name","Feuchte",0) )}
userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
Config MGB:
Internals:
CFGFN
DEF mqtt room=HASS
FUUID 63d2c1b7-f33f-788a-0fc8-6b698a23e5d3d07d
IODev ha_MQTT2
NAME mqttGeneric
NR 1395
NTFY_ORDER 70-mqttGeneric
STATE in: 22 out: 72 devices: 3
TYPE MQTT_GENERIC_BRIDGE
devspec room=HASS
eventCount 86
prefix mqtt
READINGS:
2023-01-26 19:08:55 IODev ha_MQTT2
2023-01-26 21:45:49 device-count 3
2023-01-26 21:25:38 incoming-count 22
2023-01-26 22:18:08 outgoing-count 72
2023-01-26 22:18:08 transmission-state outgoing publish sent
2023-01-26 19:08:55 updated-reading-count 0
2023-01-26 21:25:38 updated-set-count 22
devices:
:global:
:alias:
:defaults:
pub:base MGB1
sub:base MGB1/set
:publish:
*:
mode R
topic {"fhem/$device/$reading"}
GA.ss.SA.Licht:
:alias:
:publish:
:subscribe:
HASH(0x59aad98)
GH.in.1W.DS2438:
:alias:
:publish:
temperature:
last 1674767888.59118
mode R
topic {"$base/$device/temperature"}
demoswitch:
:alias:
:publish:
:subscribe:
HASH(0x5f5b440)
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:
IODev ha_MQTT2
globalDefaults sub:base=MGB1/set pub:base=MGB1
globalPublish *:topic={"fhem/$device/$reading"}
icon mqtt_bridge_2
room MQTT
stateFormat in: incoming-count out: outgoing-count devices: device-count
verbose 0
Wenn ich auf der fhem Konsole mitlese, sieht das so aus und irgendwie vermisse ich das Reading temperature:
fhem/GH.in.1W.DS2438/absFeuchte 4.9
fhem/GH.in.1W.DS2438/Taupunkt 0.3
fhem/GH.in.1W.DS2438/Feuchte 85.47
fhem/GH.in.1W.DS2438/vsense 0
fhem/GH.in.1W.DS2438/vsense.t 0
fhem/GH.in.1W.DS2438/time 0
fhem/GH.in.1W.DS2438/VDD 5.00
fhem/GH.in.1W.DS2438/state Feuchte: 85.47 % (T: 2.5 °C vs: 0.00 V vs.t: 0.00 Vs)
fhem/GH.in.1W.DS2438/absFeuchte 4.9
fhem/GH.in.1W.DS2438/Taupunkt 0.3
Müsste ich in den Attributen des Sensors etwas ändern, wenn ich die Readings absFeuchte, Feuchte Taupunkt und temperature in einem Rutsch nach HA übertrage?
Kann mir jemand ggf. helfen warum die Temperatur nicht in HA ankommt?
Danke und Gruß,
Spartacus
...du mischst die Anleitungen aber bunt durcheinander...
globalPublish finde ich immer noch (denk dir was) - hier bewirkt es, dass (auch) alles andere versendet wird...
Und das eine Reading, das du eigentlich haben willst, wird dann an einen ANDEREN Topic geschrieben ;) .
Soviel mal auf die Schnelle, vielleicht kommst du ja selbst drauf, wo der Wert landet...
Guten Morgen,
ja, ich bin vorne angefangen zu lesen und habe dann die verschiedenen Einstellungen durchgetestet. :-)
Das mit dem "global publish" habe ich m.E. verstanden und jetzt aus der MGB entfernt, weil es auf "Device"-Ebene eingebaut wird.
mqttPublish temperature:topic={"$base/$device/temperature"}
Wo es allerdings landet, kappiet ich noch nicht!. Auch nach dem Entfernen aus der MGB hat sich am Verhalten des Sensors nichts geändert.
Moin nochmal,
ich habe jetzt so lange rumgefummelt, bist das mit der Temperatur geht!. Leider geht aber der Switch nicht mehr. In HA kommt nichts mehr an und setzten kann ich ihn auch nicht mehr!
Wo ist jetzt der Wurm drin?
Danke und Gruß,
Spartacus
MGB:
defmod mqttGeneric MQTT_GENERIC_BRIDGE mqtt room=HASS
attr mqttGeneric IODev ha_MQTT2
attr mqttGeneric globalDefaults pub:base=fhem sub:base=fhem/set
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
Switch:
defmod GA.ss.SA.Licht EnOcean FFE88602
attr GA.ss.SA.Licht userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
attr GA.ss.SA.Licht IODev TCM310
attr GA.ss.SA.Licht alias Gartenlicht
attr GA.ss.SA.Licht comMode confirm
attr GA.ss.SA.Licht comment Eltako FSR14-4 Kanal 2
attr GA.ss.SA.Licht devStateIcon .*on:light_light_dim_100@lightgreen .*off:light_light_dim_00@grey
attr GA.ss.SA.Licht event-on-change-reading state,buttons,channelA,channelB
attr GA.ss.SA.Licht group FSR14-4x Keller
attr GA.ss.SA.Licht gwCmd switching
attr GA.ss.SA.Licht manufID 00D
attr GA.ss.SA.Licht mqttPublish state:topic={"$base/$device"}
attr GA.ss.SA.Licht mqttSubscribe state:stopic={"$base/$device"}
attr GA.ss.SA.Licht room 98-Geräte -> EnOcean,HASS
attr GA.ss.SA.Licht subDef FF94C0E2
attr GA.ss.SA.Licht subType gateway
attr GA.ss.SA.Licht verbose 3
HA:
unique_id: gartenlicht
name: gartenlicht
command_topic: "fhem/GA.ss.SA.Licht/set"
state_topic: "fhem/GA.ss.SA.Licht/state"
payload_on: "on"
payload_off: "off"
state_on: "on"
state_off: "off"
optimistic: false
qos: 0
retain: true
NACHTRAG:
wenn ich das
attr GA.ss.SA.Licht mqttPublish state:topic={"$base/$device"}
herausnehme, wird der Status von fhem nach HA übernommen, wenn ich in fhem schalte, Aber ich möchte auch in HA den switch betätigen können?
$base in FHEM ist "fhem/set"
Da wird das mit
command_topic: "fhem/GA.ss.SA.Licht/set"
wohl eher nicht funktionieren...
sorry, kapiere nicht, wie die Pfade jetzt sein müssen, damit der Befehl richtig übermittelt und von fhem richtig zusammengebaut wird.
was muss denn dort ankommen, wenn ich mit mosquitto_sub mitlausche?
aktuell ist es:
fhem/set/GA.ss.SA.Licht on
ich verstehe noch nicht, wie fhem dann den Befehl zusammenbaut, damit auch geschaltet wird!
Spartacus
Zitat von: Spartacus am 27 Januar 2023, 10:46:36
sorry, kapiere nicht, wie die Pfade jetzt sein müssen, damit der Befehl richtig übermittelt und von fhem richtig zusammengebaut wird.
was muss denn dort ankommen, wenn ich mit mosquitto_sub mitlausche?
aktuell ist es:
fhem/set/GA.ss.SA.Licht on
Das sollte passen. Bitte mal am IO nachschauen, ob das da auch ankommt (oder ob auch dort die subscriptions geändert werden müssen).
Hi beta-user,
sorry, was soll ich jetzt wo nachsehen? Jetzt bin ich irgendwie lost. Wo kann man denn noch was nachsehen?
meinst Du den hier?
defmod ha_MQTT2 MQTT2_CLIENT homeassistant: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 fhem
Sorry für die doofen Fragen, aber vor 3 Wochen wusste ich nicht, dass es HA und mqtt überhaupt gibt!
...da bist du richtig, aber da fehtl was entscheidendes: clientOrder muss anders gesetzt werden! Vermutlich gibt es irgendwo ein MQTT2_DEVICE, in dem die Infos landen, die du eigentlich durch die MGB ausgewertet haben willst (wenn man die Einrichtung per attrTemplate@MGB macht, wird das automatisch gesetzt...).
Und im Wiki zu MGB hatte ich das auch deutlichst erwähnt, oder?
Hm,
jetzt noch mal ganz von vorne:
ich setzte in der MGB das Template base_settings_to_MQTT_GENERIC_BRIDGE.
danach funktioniert dann gar nichts mehr!
ICh denke, dann muss ich die Sunscription und as publishing wieder anpassen.
muss ich dann die global_defaults wieder auf meine alten Werte setzte?
sub:base=mqttGeneric/set pub:base=mqttGeneric gegen pub:base=fhem sub:base=fhem/set tauschen?
Danke und Gruß,
Spartacus
Na ja, wenn du das mit dem attrTemplate nachträglich machst, ist das nicht hilfreich, weil dann eben wieder die "üblichen" defaults gesetzt werden.
Zumindest sollte jetzt clientOrder richtig gesetzt sein, ob die subscriptions passen, kann ich von hier aus nicht sagen...
OT: ich würde aus HA heraus NICHT mit retain senden. Kann dazu führen, dass das Licht zum falschen Zeitpunkt angeht usw. ::) .
Moin,
so, jetzt bin ich völlig lost! Welche Stellschrauben gibt es denn:
1. IO Device:
2. Bridge
3. Device
4. configuration .yaml
Ich habe verstanden, dass man unterschiedliche Pfade für publish und subscription setzten muss und diese mit HA übereinstimmen.
Ich habe dann jetzt das Basic-Template ausgeführt um wieder die Grundeinstellungen zu haben. Subscription und publish Pfade in der Bridge habe ich dann wieder angepasst, sodass es mit den Attributen im Device und den Phaden in der configuration.yaml übereinstimmt.
- Die Temperatur des 1-Wire Sensors kommt in HA an.
- Wenn ich in fhem den Enocean Aktor schalte, kommt der Status in HA an.
- Wenn ich aus HA schalte den Aktor schalte, dann passiert in fhem nichts
mosquitto_sub auf dem fhem-Server zeigt Folgendes an:
fhem/set/GA.ss.SA.Licht onDas heisst, es kommt grundsätzlich was an.
So sieht es jetzt meine Konfig aus.
IO:defmod ha_MQTT2 MQTT2_CLIENT homeassistant:1883
attr ha_MQTT2 clientId fhemwird im
attr ha_MQTT2 clientOrder MQTT_GENERIC_BRIDGE MQTT2_DEVICE
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 subscriptions setByTheProgram
attr ha_MQTT2 username fhemBridge:defmod mqttGeneric MQTT_GENERIC_BRIDGE mqtt room=HASS
attr mqttGeneric IODev ha_MQTT2
attr mqttGeneric globalDefaults pub:base=fhem sub:base=fhem/set
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 0Device Enocean:defmod GA.ss.SA.Licht EnOcean FFE88602
attr GA.ss.SA.Licht userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
attr GA.ss.SA.Licht IODev TCM310
attr GA.ss.SA.Licht alias Gartenlicht
attr GA.ss.SA.Licht comMode confirm
attr GA.ss.SA.Licht comment Eltako FSR14-4 Kanal 2
attr GA.ss.SA.Licht devStateIcon .*on:light_light_dim_100@lightgreen .*off:light_light_dim_00@grey
attr GA.ss.SA.Licht event-on-change-reading state,buttons,channelA,channelB
attr GA.ss.SA.Licht group FSR14-4x Keller
attr GA.ss.SA.Licht gwCmd switching
attr GA.ss.SA.Licht manufID 00D
attr GA.ss.SA.Licht mqttPublish state:topic={"$base/$device/state"}
attr GA.ss.SA.Licht mqttSubscribe state:stopic={"$base/$device/set"}
attr GA.ss.SA.Licht room 98-Geräte -> EnOcean,HASS
attr GA.ss.SA.Licht subDef FF94C0E2
attr GA.ss.SA.Licht subType gateway
attr GA.ss.SA.Licht verbose 3Device DS2438:defmod GH.in.1W.DS2438 OWMULTI DS2438 09DB84000003
attr GH.in.1W.DS2438 userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
attr GH.in.1W.DS2438 DbLogInclude temperature,Feuchte,Taupunkt,absFeuchte
attr GH.in.1W.DS2438 IODev 1Wire
attr GH.in.1W.DS2438 VFunction (161.29 * V / VDD - 25.8065)/(1.0546 - 0.00216 * T)
attr GH.in.1W.DS2438 VName Feuchte
attr GH.in.1W.DS2438 VUnit %
attr GH.in.1W.DS2438 alias DS2438
attr GH.in.1W.DS2438 comment Sensor: SHT35
attr GH.in.1W.DS2438 event-min-interval .*:600
attr GH.in.1W.DS2438 group Sensoren
attr GH.in.1W.DS2438 icon temperature_humidity
attr GH.in.1W.DS2438 model DS2438
attr GH.in.1W.DS2438 mqttForward all
attr GH.in.1W.DS2438 mqttPublish temperature:topic={"$base/$device/temperature"}
attr GH.in.1W.DS2438 room 98-Geräte -> 1-Wire,HASS
attr GH.in.1W.DS2438 stateFormat {sprintf("T: %.2f°C, H: %.2f %%",ReadingsVal("$name","temperature",0),ReadingsVal("$name","Feuchte",0) )}
HA:
switch:
- unique_id: gartenlicht
name: gartenlicht
command_topic: "fhem/set/GA.ss.SA.Licht"
state_topic: "fhem/GA.ss.SA.Licht/state"
payload_on: "on"
payload_off: "off"
state_on: "on"
state_off: "off"
optimistic: false
qos: 0
retain: true
sensor:
- name: 1-wire
state_topic: "fhem/GH.in.1W.DS2438/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"
Mindestens das hier paßt nicht (zum Rest):attr GA.ss.SA.Licht mqttSubscribe state:stopic={"$base/$device/set"}
das "/set" steckt in (per globalDefault gesetzter) $base (an anderer Stelle).
H E U R E K A !
das war es! Du hast es gefunden!
Komischerweise taucht das doppelte set beim Lauschen nicht auf!
Was muss ich jetzt am Attribut ändern, wenn ich nicht nur die Temperatur des DS2438, sondern auch absFeuchte, Feuchte und Taupunkt zu HA rüber-shiften will. Durch das Attribut
attr GH.in.1W.DS2438 mqttPublish temperature:topic={"$base/$device/temperature"}
wird die Kommunikation über die MQTT-Bridge m.E. auf "temperature" begrenzt, oder?
Spartacus
:)
Ich habe (leider*) schon eine Menge Leute auf dem Weg begleitet...
*wegen der Frustrationen, die Betreffenden leider durchmachen mussten, bis der Groschen gefallen war
Daher habe ich den Prozess auch versucht zu vercoden, damit alles (im Ergebnis) einigermaßen konsistent zueinander paßt (per attrTemplate) - das gibt es auch für diverse "klassische" Probleme wie z.B. Rollladenaktoren. Leider ist es prinzipbedingt bei MGB etwas komlizierter wie anderswo, weil man Attribute an "anderen" Geräten setzen muss. "Vollständig" ist das auch bei weitem nicht, k.A., wieso das keiner weiter aktiv treiben will (ich brauche das nicht selbst).
ABER: Man kann sich vorher anzeigen lassen, was in welchem Fall gesetzt wird, und die commandref erklärt auch, was bei bestimmten Attributen möglich ist ;) , und zwar auch an "fremden" Devices (falls FHEM halbwegs aktuell ist).
Von daher verstehe ich nicht ganz, was z.B. an den in der commandref genannten Beispielen unklar ist (es ist zu viel "drumrum", aber das ist ein anderes Thema):
Zitatattr <dev> mqttPublish temperature:topic={"$base/$name"} temperature:qos=1 temperature:retain=0 *:topic={"$base/$name"} humidity:topic=/TEST/Feuchte
attr <dev> mqttPublish temperature|humidity:topic={"$base/$name"} temperature|humidity:qos=1 temperature|humidity:retain=0
Hinweis: Vermutlich enhält globalDefaults-$base für diese Beispiele auch "/$device"...
Moin,
jetzt habe ich doch noch mal eine Frage:
Ich plane u.a. auch die enocean und DUOFERN Rollo-Aktoren über HA verfügbar zu machen. Du schreibst, dafür gäbe es Templates. Wenn ich jetzt aber in der Bridge das Template "shutter" auswähle, dann überbügelt der mir doch sicherlich meine funktionierende Switches und Sensor Konfiguration, oder?
Wie wendet man das dann an?
Spartacus
Zitat von: Spartacus am 27 Januar 2023, 13:28:10
Ich plane u.a. auch die enocean und DUOFERN Rollo-Aktoren über HA verfügbar zu machen. Du schreibst, dafür gäbe es Templates. Wenn ich jetzt aber in der Bridge das Template "shutter" auswähle, dann überbügelt der mir doch sicherlich meine funktionierende Switches und Sensor Konfiguration, oder?
Geändert wird immer nur das "Zieldevice", und zwar einmalig, updates etc. muss man ggf. dann wieder händisch nachziehen. Bei den meisten attrTemplate wirkt das Anwenden auf das gerade ausgewählte Device.
Zitat
Wie wendet man das dann an?
Bei den meisten (außer den "Grundlagen"-templates für die MGB selbst) ist das etwas anders: Das ist eine Art "sidekick" auf ein anderes Device, das man zusätzlich angeben kann bzw. muss. Dann wird auch nur wieder genau das eine Device angefasst.
Vermutlich funktioniert die Homematic-Variante von dem Rollladen-attrTemplate auch für EnOcean => Testen, Rückmeldung geben und ggf. freuen, dass es eingepflegt wird...
Hallo,
das mit dem Testen und dem Feedback geben, mache ich natürlich sehr gerne! Wird aber heute leider nix mehr, da ich jetzt andere Dinge tun muss... Ich bleibe am Ball!
Nochmals vielen Dank für die Unterstützung!
Spartacus
Kein Ding, Rom wurde auch nicht an einem Tag erbaut...
PS: Ich glaube ja immer noch, dass du "eigentlich" von HA aus nicht mit retain-Flag senden willst ;) .
...besser ?
....
- unique_id: gartenlicht
name: gartenlicht
command_topic: "fhem/set/GA.ss.SA.Licht"
state_topic: "fhem/GA.ss.SA.Licht/state"
payload_on: "on"
payload_off: "off"
state_on: "on"
state_off: "off"
optimistic: false
qos: 0
retain: false
Zitat von: Spartacus am 27 Januar 2023, 14:26:58
...besser ?
MAn ja, aber am Ende musst du das selbst wissen...
Es gibt halt immer mal wieder einen, der sich wundert, warum mitten in der Nacht Rollläden aufgehen uä ;D . Ursache nicht eben selten: ein aus "Sicherheitsdenken" gesetztes retain-flag...
Hallo,
ja, das mit dem retain: false ist schon richtig!
In meiner Testumgebung läuft das dann ja jetzt. Ich überlege gerade nur, ob ich den Broker als Addon auf den produktivem HA schraube, oder ob ich dem eine eigene VM auf der QNAP spendiere. Ich habe im Moment keine Vorstellung davon, was langfristig die bessere Wahl ist und ob ich das konfigurationstechnisch mit meinen DAU-Kenntnissen hinkriege.
Hintergrund der Überlegung:
Fhem läuft produktiv auch in einer VM auf der QNAP und auch die MariaDB 10 für HA ist dort gehostet. Die Docker Unterstützung auf dem NAS hat aktuell noch keine VLAN Unterstützung und von daher nehme ich VMs. Container Station V3 wird dann VLANs unterstützen und die VMs werden dann migriert.
Kann jemand einen Tipp geben, was lang-, bzw. mittelfristig die bessere Lösung ist?
Gruß,
Spartacus
Moin zusammen,
ich habe heute versucht das shutter_Template zu testen, aber leider kommt bei der Auswahl meines enocean Rolladenaktors die Fehlermeldung: "Empty parameters are not allowed"
Mehr passiert dann nicht.
Hier mal mein Device-List:
Internals:
CFGFN Config/98-EnOcean.cfg
DEF FFD02B00
FUUID 5df9e57f-f33f-788a-79a1-10bacfc74c3c8e6f
IODev TCM310
LASTInputDev TCM310
MSGCNT 151
NAME EG.wz.RO.links
NR 634
NTFY_ORDER 50-EG.wz.RO.links
STATE 0
TCM310_DestinationID FFFFFFFF
TCM310_MSGCNT 151
TCM310_PacketType 1
TCM310_RSSI -83
TCM310_ReceivingQuality good
TCM310_RepeatingCounter 0
TCM310_SubTelNum 3
TCM310_TIME 2023-01-29 15:20:28
TYPE EnOcean
eventCount 47
READINGS:
2023-01-28 13:08:35 IODev TCM310
2023-01-29 15:20:28 alarm off
2023-01-29 15:20:28 endPosition open
2023-01-29 15:20:28 position 0
2023-01-29 15:20:28 positionMode normal
2023-01-29 15:20:28 serviceOn no
2023-01-29 15:20:28 shutterState stopped
2023-01-29 15:20:28 state open
helper:
Attributes:
IODev TCM310
alias Wohnzimmer Rollade links
angleMax 0
angleMin 0
comMode confirm
comment PEHA 452 FU-EBIM JR o.T.
devStateIcon 100:fts_shutter_100 0:fts_window_2w 9\d.*:fts_shutter_90 8\d.*:fts_shutter_80 7\d.*:fts_shutter_70 6\d.*:fts_shutter_60 5\d.*:fts_shutter_50 4\d.*:fts_shutter_40 3\d.*:fts_shutter_30 2\d.*:fts_shutter_20 1\d.*:fts_shutter_10 \d.*:fts_window_2w
eep A5-38-08
event-on-change-reading .*
eventMap opens:auf closes:ab
group 452 FU-EBIM
gwCmd blindCmd
manufID 001
room 98-Geräte -> EnOcean
stateFormat position
subDef FF94C082
subType shutterCtrlState.01
subTypeSet gateway
webCmd auf:ab:stop
Spartacus
Werde erst mal nicht dazu kommen, mir das näher anzusehen.
Im Zweifel kannst du an den anderen Shutter-attrTemplates in etwa ablesen, wie das zu konfigurieren ist - wenn man im dropdown was auswählt, kommt dann darunter die Beschreibung bzw. auch die Befehlsliste, die abgearbeitet würde, wie du vermutlich schon gesehen hast.
Hallo,
ja, ist alles gut! Nur weil ich halt Feedback geben sollte... Ich spiele mal etwas damit herum...
Bis bald!
Spartacus
Hallo zusammen,
ich benötige für die einbinden der enocean Aktoren für die Rollos doch etwas Unterstützung. Ich kann die Rollos auf- und abfahren, positionieren und während der Fahrt stoppen. Leider klappt das mit der Rückmeldung nicht ganz, weil ich die Zuordnung er Zustände nicht. Die Rückmeldung der Position scheint allerdings zu funzen.
Hier mal die Konfiguration:
- unique_id: wz_rollo_li
name: Wohnzimmer Rollo links
command_topic: "fhem/set/EG.wz.RO.links"
state_topic: "fhem/EG.wz.RO.links/State"
position_topic: "fhem/EG.wz.RO.links/position"
set_position_topic: "fhem/set/EG.wz.RO.links/position"
payload_open: "auf"
payload_close: "ab"
payload_stop: "stop"
position_open: 100
position_closed: 0
state_open: "open"
state_opening: "opening"
state_closed: "closed"
state_closing: "closing"
state_stopped: "stopped"
optimistic: false
qos: 0
retain: false
fhem:
Internals:
CFGFN Config/98-EnOcean.cfg
DEF FFD02B00
FUUID 5df9e57f-f33f-788a-79a1-10bacfc74c3c8e6f
IODev TCM310
LASTInputDev TCM310
MQTTClient_MSGCNT 24
MQTTClient_TIME 2023-01-29 22:26:01
MSGCNT 299
NAME EG.wz.RO.links
NR 634
NTFY_ORDER 50-EG.wz.RO.links
STATE 0
TCM310_DestinationID FFFFFFFF
TCM310_MSGCNT 275
TCM310_PacketType 1
TCM310_RSSI -85
TCM310_ReceivingQuality good
TCM310_RepeatingCounter 0
TCM310_SubTelNum 6
TCM310_TIME 2023-01-30 07:34:59
TYPE EnOcean
eventCount 209
READINGS:
2023-01-29 16:40:21 IODev TCM310
2023-01-30 07:34:59 alarm off
2023-01-30 07:34:59 endPosition open
2023-01-30 07:34:59 position 0
2023-01-30 07:34:59 positionMode normal
2023-01-30 07:34:59 serviceOn no
2023-01-30 07:34:59 shutterState stopped
2023-01-30 07:34:59 state open
helper:
Attributes:
IODev TCM310
alias Wohnzimmer Rollade links
angleMax 0
angleMin 0
comMode confirm
comment PEHA 452 FU-EBIM JR o.T.
devStateIcon 100:fts_shutter_100 0:fts_window_2w 9\d.*:fts_shutter_90 8\d.*:fts_shutter_80 7\d.*:fts_shutter_70 6\d.*:fts_shutter_60 5\d.*:fts_shutter_50 4\d.*:fts_shutter_40 3\d.*:fts_shutter_30 2\d.*:fts_shutter_20 1\d.*:fts_shutter_10 \d.*:fts_window_2w
eep A5-38-08
event-on-change-reading .*
eventMap opens:auf closes:ab
group 452 FU-EBIM
gwCmd blindCmd
manufID 001
mqttPublish position|endPosition|shutterState|state:topic={"$base/$device/$name"}
mqttSubscribe state:stopic={"$base/$device"} auf|ab|stop|position:stopic={"$base/$device/$name"}
room 98-Geräte -> EnOcean,HASS
stateFormat position
subDef FF94C082
subType shutterCtrlState.01
subTypeSet gateway
userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
webCmd auf:ab:stop
Ausgabe auf der Konsole -> shutter down, teilweise:
fhem/EG.wz.RO.links/state ab
fhem/EG.wz.RO.links/shutterState ab
fhem/EG.wz.RO.links/position 1
fhem/EG.wz.RO.links/endPosition not_reached
fhem/EG.wz.RO.links/state not_reached
fhem/EG.wz.RO.links/position 5
fhem/EG.wz.RO.links/position 10
fhem/EG.wz.RO.links/state stop
fhem/EG.wz.RO.links/position 11
fhem/EG.wz.RO.links/shutterState stopped
Ausgabe auf der Konsole -> shutter up bis Endposition, open:
fhem/EG.wz.RO.links/state auf
fhem/EG.wz.RO.links/shutterState auf
fhem/EG.wz.RO.links/position 5
fhem/EG.wz.RO.links/position 0
fhem/EG.wz.RO.links/endPosition open
fhem/EG.wz.RO.links/state open
fhem/EG.wz.RO.links/shutterState stopped
Mein Problem sind die Enpositionen. Da habe ich keine Idee, wie ich die zuordnen kann, da die Endposition im Reading endPosition (open/closed) steckt
Vielleicht kann jemand hier helfen.
Spartacus
Moin,
irgendwie bin ich etwas lost! Ich überwache jetzt in HA die Zustände von dem Device zu tracken.
Ich kann auch schön sehen, dass state die Zustände: open, opening, closing, closed annimmt, wenn ich den Shutter fahre. Stoppe ich den Shutter, dann kriegt er offenbar die Zustand nicht richtig mit, das heißt, Zeile 6 wird ignoriert und er zeigt "open" an.
fhem/EG.wz.RO.links/state ab
fhem/EG.wz.RO.links/shutterState ab
fhem/EG.wz.RO.links/position 55
fhem/EG.wz.RO.links/position 60
fhem/EG.wz.RO.links/position 65
fhem/EG.wz.RO.links/state stop
fhem/EG.wz.RO.links/position 67
fhem/EG.wz.RO.links/shutterState stopped
Sonst passt jetzt eigentlich alles:
attr EG.wz.RO.links mqttPublish position|endPosition|shutterState|state:topic={"$base/$device/$name"}
attr EG.wz.RO.links mqttSubscribe state:stopic={"$base/$device"}
- unique_id: wz_rollo_li
name: Wohnzimmer Rollo links
command_topic: "fhem/set/EG.wz.RO.links"
state_topic: "fhem/EG.wz.RO.links/state"
position_topic: "fhem/EG.wz.RO.links/position"
set_position_topic: "fhem/set/EG.wz.RO.links/position"
payload_open: "auf"
payload_close: "ab"
payload_stop: "stop"
position_open: 100
position_closed: 0
state_open: "open"
state_opening: "auf"
state_closed: "closed"
state_closing: "ab"
state_stopped: "stop"
optimistic: true
qos: 1
retain: false
...das qos und das optimistic, kann man m.E wieder zurücksetzten. Das hatte ich auf 0 bzw. false
Aber wo ist hier der Fehler mit dem stop?
Spartacus
Zitat von: Spartacus am 29 Januar 2023, 15:26:05
ich habe heute versucht das shutter_Template zu testen, aber leider kommt bei der Auswahl meines enocean Rolladenaktors die Fehlermeldung: "Empty parameters are not allowed"
Mehr passiert dann nicht.
Hattest du zufällig ein Leerzeichen vor dem Device-Namen?
Bei mir läuft das durch, wenn da nur der Device-Name angegeben ist, aber effektiv passiert nichts (was kein großes Wunder ist, denn das attrTemplate kennt nur eine sehr eingeschränkte Typenauswahl, unter der EnOcean nicht ist).
Zum Eigentlichen:
Prinzipiell _glaube_ ich, dass es sinnvoller ist, wenn ein Rollladen von außen kommend immer gleich aussieht, und das sind eigentlich nur die "basic" Readings, also "state" (als Zahl, on/off bzw. läuft (nach unten/oben)) bzw. pct.
Vielleicht magst du dir das attrTemplate mal ansehen, ist allerdings nicht wirklich einfach zu lesen...
Moin, moin,
naja, ich ich habe das ja jetzt so umgebogen, dass nur noch state und position gesendet werden. Mein Problem mit dem "stop" das bleibt. Keine Ahnung warum das stop in HA nicht ausgewertet wird. Habe das schon in der HA Community gepostet! Alles Andere geht ja astrein!
Das Template finde ich irgendwie nicht. Nachdem ich den Befehl nun in der MGB ausgeführt habe, passiert einfach nichts. Wo finde ich das denn den Code?
Aber ehrlich gesagt glaube ich nicht, dass es mein Problem löst.
Spartacus
Zitat von: Spartacus am 30 Januar 2023, 18:33:13
Das Template finde ich irgendwie nicht. Nachdem ich den Befehl nun in der MGB ausgeführt habe, passiert einfach nichts. Wo finde ich das denn den Code?
Der sollte - vorausgesetzt du hast f18 als style - eigentlich direkt unter dem "set" eingeblendet werden.
Du findest ihn aber auch in der mgb-Datei unter dem im Wiki angegebenen Pfad -
https://wiki.fhem.de/wiki/AttrTemplate#Eigene_Templates_entwickeln.
Zitat
Aber ehrlich gesagt glaube ich nicht, dass es mein Problem löst.
Das glaube ich auch nicht, aber es ging ja ggf. darum, die EnOcean-Dinger so mit in die Sammlung aufzunehmen, dass der nächste nicht wieder über dasselbe Problem stolpert, oder...
Moin,
also das ist das was ich sehe (Screenshot) und der Link führt mich m.E nur zu einer allgemeinen Beschreibung zu Templates und nicht zu dem konkreten Code.
Wenn das das "Shutter-Template" ist, dann sind meine Kenntnisse einfach zu dünn um dies zu verstehen, sorry!
Vielleicht kann man meine Einstellungen noch etwas vereinfachen, aber eigentlich bin ich auch ganz zufrieden, mit dem, was da in HA ankommt. Ganz sauber ist es sicherlich nicht, aber es erfüllt seinen Zweck (siehe Screenshot, Rollo) Offenbar liegt das mit dem "stopp"-Zustand an der MQTT Implementierung in HA.
Was mich allerdings etwas stört, ist, dass nach einem Reboot von HA die Zustände der Rollladen als "unknown" auftauchen. Mit retain: true kriegt man das zwar gefixt, aber das könnte, wie Du schon angemerkt hast, auch zu unschönen Effekten führen. Das gefällt mir einfach noch nicht.
Gruß,
Spartacus
Moin zusammen,
ich muss noch einmal die Experten befragen, da ich das Problem selber nicht lösen kann.
Ich betreibe im HA inzwischen auch einen Zigbee2Mqtt. Der Server läuft in einem Docker auf meiner Qnap. Der Mosquitto läuft ebenfalls auf der Qnap in einer separaten VM.
fhem stellt über die MGB ein paar 1wire duofern und enocean Geräte bereit; Zigbee2Mqtt alle meine Zigbee Aktoren und Sensoren über einen externen IP Coordinator
Im HA ist es jetzt aber so, dass nach einem Reboot alle States, die über die fhem Schiene kommen, verloren gehen. Bei den Zigbee2Mqtt-Devices ist das nicht der Fall. Nach ein paar Sekunden, sind die Zustände da. Das funktioniert sehr zuverlässig, ohne Nebeneffekte, wie z.B. ungewollte Schaltaktionen.
Ich hatte das retain Flag bei den fhem Devices mal gesetzt, aber dann habe ich das Problem, dass es zu den sog. Ghost-Schaltaktionen kommt.
Bei den 1w-Sensoren sind die fehlenden Zustände nicht so kritisch, da diese nach ein paar Minuten wieder ok sind, da die Devices ihre Werte senden. Nervig ist das bei den Rolladenaktoren und den Schaltaktoren.
Hat jemand eine Idee, was man da machen kann?
Hallo Gadget
Mein Kompliment. Ohne die vielen Seiten gelesen zu haben, habe ich den Testswitch so umsetzen zu können. Mal schauen, ob ich das auch mit echten Devices so hinbekomme. :)
Servus,
ich bin momentan dabei mit HA etwas rumzuspielen und wollte zumindest sämtliche MQTT Devices die momentan direkt mit dem Fhem Broker kommunizieren, in Richtung HA weiterleiten. (Man kann ja in der Regel in den IOT Devices nie mehr als ein einen Broker angeben)
Da ich bzgl. MQTT eine echte Schnarchnase bin, wollte ich mal fragen wie ich das am Besten anfange.
Wie schon geschrieben, stand jetzt, benötige ich nur eine Bridge zwischen den zwei Brokern, so dass alle MQTT Devices die über Fhem angebunden sind, auch in HA auftauchen.
Viele Grüße
Rubinho
Ich habe versucht aus den diversen Beispielen in diesem Thread eine Bridge zu bauen.
Leider habe ich dadurch Fhem auf die Bretter geschickt.
Fhem legte gefühlt von jedem Device das mit Fhem interagiert ein zusätzliches Device an und irgendwann war dann Feierabend.
Ich musste Fhem hart beenden und die Konfig auf der Konsole bereinigen.
Im Prinzip benötige ich nur eine Bridge beider MQTT Broker.
VG
Rubinho
Wieso benötigst du überhaupt zwei Broker? Verwende einen und alles dürfte gut sein...
Das ist in der Tat mein Endszenario.
Ich hatte ursprünglich der Einfachheit halber den internen Fhem Broker in Betrieb genommen. Dieser ist natrülich fest mit Fhem verdrahtet.
Da man, wie du schon geschrieben hast nur einen Broker benötigt, möchte ich auf einen Externen zu setzen um flexibler zu sein.
Ich werde mich mal durchkämpfen.
Trotzdem danke für die Info.
Das "Umswitchen" ist m.E. kein Hexenwerk. Du zeigst einfach mit einem MQTT2_CLIENT auf den externen Broker, setzt ignoreRegexp so, dass commandos und das homeassistant-autodiscovery-Zeug nicht in FHEM anlanden und läßt das "native MQTT-Gedöns" dann mit dem externen Broker sprechen und änderst an den vom MQTT2_SERVER angelegten Devices dann nur das IODev. Fertig die Laube ;) .
Hat übrigens auch nüscht mit MQTT_GENERIC_BRIDGE zu tun.
Zitat von: Beta-User am 02 März 2023, 16:19:18
Hat übrigens auch nüscht mit MQTT_GENERIC_BRIDGE zu tun.
Nö hat es nicht :)
Der ursprüngliche Gedanke war ja beide Broker miteinander zu bridgen. Ich dachte das wäre der einfache Weg.
Was es wohl nicht ist.
Allerdings macht das gebastel am MQTT mein Fhem sehr instabil.
Keine Ahnung was ich kaputt gemacht habe.
Sobald ich den externen Broker in Betrieb nehme. Wird alles Zäh und ich bekomme im Log nur noch Timeouts von irgendwelchen Verbindungen (z.B. Influx)
Vielleicht boote ich mal alles durch. Sowas soll manchmal helfen :D
Das klingt nach einer unbeabsichtigt verursachten Schleife.
Zum Auffinden könnte es helfen, den MQTT-Traffic am IO (M2C) zu beobachten. Weitere Fragen dazu dann aber bitte in einem gesonderten Thread...
Zitat von: Beta-User am 02 März 2023, 19:52:08
Das klingt nach einer unbeabsichtigt verursachten Schleife.
Ja war es. Ich habs hinbekommen.
Danke für die Info
So, das war auch mein letzter Post in diesem Thread. Habe ihn lange genug gehijackt.
Sorry nochmal.
VG
Rubinho
Zitat von: rubinho am 04 März 2023, 08:48:59Zitat von: Beta-User am 02 März 2023, 19:52:08Das klingt nach einer unbeabsichtigt verursachten Schleife.
Ja war es. Ich habs hinbekommen.
Danke für die Info
So, das war auch mein letzter Post in diesem Thread. Habe ihn lange genug gehijackt.
Sorry nochmal.
VG
Rubinho
So, ich versuche auch schon seit Tagen FHEM -> HA MQTT zu "Bridgen" ....
bisher allerdings recht erfolglos, eventuell hat da noch jemand einen tip zu, versucht habe ich die Anleitung die hier gepostet wurde, danach hatte ich aber mehrmals dasselbe Problem
wie rubinho, vllt kann er ja was dazu schreiben ob es nun geht den einfach zu bridgen.
HA hatte ich dann das Mosquitto Addon installiert, allerdings funktionierte die zusätzliche Konfiguration des DemoSwitches schon nicht (in HA) da HA den nicht bereitstellen wollte wegen eines zukünftigen updates.
Ich habe in FHEM meine ganzen Steckdosen (Tasmota) integriert, natürlich auch diverse Automationen laufen (Trockner, Waschmaschine usw) und würde gerne die Energie auswertungen
in HA machen, sprich die Steckdosen halt auch in HA verfügbar machen.
FHEM läuft auf einem PI4, HA auf einem 2ten PI4, also technisch recht easy gestrickt, trotzdem bekomm ich das nicht ans laufen irgendwie
LG, Sven
EDIT: Nach x-mal löschen der configs unmd neu einrichten läuft es jetzt ....
Dummy ist über FHEM und HA schaltbar, status ändert sich ebenfalls in beiden systemen :)
HA ist ja grausam :)
aber egal, danke allen hier, läuft :)
LG - Sven
Hallo, bei mir ist es so, das der MQTT2_Client immer wieder in disconnected wechselt. Ist das normal ? Liegt das an dem keepaliveTimeout ?
Wenn der Client connected ist wird der state nicht von ha -> fhem oder von fhem -> ha aktualisiert.
List MQTT Server
CONNECTS 2
Clients :MQTT2_DEVICE:MQTT_GENERIC_BRIDGE:
ClientsKeepOrder 1
DEF 1883 global
FD 16
FUUID 62650a0a-f33f-6642-587c-9884ee46095d1d93
NAME mqtt2s
NR 470
PORT 1883
STATE Initialized
TYPE MQTT2_SERVER
eventCount 2
MatchList:
1:MQTT2_DEVICE ^.
2:MQTT_GENERIC_BRIDGE ^.
READINGS:
2023-06-22 18:05:55 nrclients 2
2023-06-22 18:05:39 state Initialized
clients:
mqtt2s_127.0.0.1_58056 1
mqtt2s_192.168.143.242_44977 1
retain:
Attributes:
autocreate simple
respectRetain 0
room System->Gateways
List MQTT_Client
BUF
Clients :MQTT_GENERIC_BRIDGE:MQTT2_DEVICE:
ClientsKeepOrder 1
DEF 192.168.143.242:1883
DeviceName 192.168.143.242:1883
FUUID 64908efc-f33f-6642-415f-1b2e6a1dd3c015d8
NAME ha_MQTT2
NEXT_OPEN 1687451278.21973
NR 508
PARTIAL
STATE disconnected
TYPE MQTT2_CLIENT
clientId fhem
connecting 1
nextOpenDelay 10
nrConnects 129
nrFailedConnects 129
qosCnt 0
qosMaxQueueLength 100
MatchList:
1:MQTT_GENERIC_BRIDGE ^.
2:MQTT2_DEVICE ^.
READINGS:
2023-06-22 18:27:48 state disconnected
qosQueue:
Attributes:
clientId fhem
clientOrder MQTT_GENERIC_BRIDGE MQTT2_DEVICE
keepaliveTimeout 60
msgAfterConnect -r fhem/connection/status connected
msgBeforeDisconnect -r fhem/connection/status disconnected
qosMaxQueueLength 100
room test
subscriptions setByTheProgram
username hamqtt
List Bridge
DEF mqtt room=HASS
FUUID 6490937a-f33f-6642-8872-87fa06624c9c6a9b
IODev ha_MQTT2
NAME mqttGeneric
NR 511
NTFY_ORDER 70-mqttGeneric
STATE in: 0 out: 0 devices: 1
TYPE MQTT_GENERIC_BRIDGE
devspec room=HASS
eventCount 4
prefix mqtt
READINGS:
2023-06-22 18:05:51 IODev ha_MQTT2
2023-06-19 21:05:16 attrTemplateVersion 20211208_MGB_M2D
2023-06-22 18:05:51 device-count 1
2023-06-22 18:05:40 incoming-count 0
2023-06-22 18:05:40 outgoing-count 0
2023-06-22 18:05:51 transmission-state IO device initialized (mqtt2)
2023-06-22 18:05:40 updated-reading-count 0
2023-06-22 18:05:40 updated-set-count 0
devices:
:global:
:defaults:
pub:base mqttGeneric
sub:base mqttGeneric/set
:publish:
*:
mode R
topic {"fhem/$device/$reading"}
demoswitch:
:subscribe:
HASH(0x84d3548)
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:
IODev ha_MQTT2
globalDefaults sub:base=mqttGeneric/set pub:base=mqttGeneric
globalPublish *:topic={"fhem/$device/$reading"}
icon mqtt_bridge_2
room test
stateFormat in: incoming-count out: outgoing-count devices: device-count
verbose 0
ZitatHallo, bei mir ist es so, das der MQTT2_Client immer wieder in disconnected wechselt. Ist das normal ?
Nein.
ZitatLiegt das an dem keepaliveTimeout ?
"keepaliveTimeout 60" bedeutet, dass FHEM alle 60 Sekunden ein PING schickt, und auf ein PONG wartet.
Laut RFC ist der Server verplichtet die Verbindung zu kappen, wenn das PING nach 90 Sekunden nicht empfangen wurde (1.5* keepaliveTimeout).
FHEM kappt auch die Verbindung, falls beim naechsten PING noch keine Antwort auf das Vorherige gekomment ist. Das wird mit loglevel 2 protokolliert.
Gibt es passende Meldungen im FHEM-Log?
MQTT2_SERVER hat zwei Clients mit identischen Namen an localhost und "extern". Ist das derselbe? (Wenn ja: wofür dann Oberhaupt ein CLIENT-Device?!?).
Wenn nein: unterschiedliche ClientID's?
Dir IP xxx.xxx.xxx.242 ist mein Home Assistant auf der ext. NAS ansonsten gibt es nur den 127.0.0.1 ist vom Sonos Bridge localhost. Internals:
CONNECTS 2
Clients :MQTT2_DEVICE:MQTT_GENERIC_BRIDGE:
ClientsKeepOrder 1
DEF 1883 global
FD 16
FUUID 62650a0a-f33f-6642-587c-9884ee46095d1d93
NAME mqtt2s
NR 470
PORT 1883
STATE Initialized
TYPE MQTT2_SERVER
eventCount 2
MatchList:
1:MQTT2_DEVICE ^.
2:MQTT_GENERIC_BRIDGE ^.
READINGS:
2023-06-26 06:31:08 nrclients 2
2023-06-26 06:30:53 state Initialized
clients:
mqtt2s_127.0.0.1_53548 1
mqtt2s_192.168.143.242_53975 1
hmccu:
retain:
Attributes:
autocreate simple
respectRetain 0
room System->Gateways,test
Das mit der .142 verstehe ich nicht.
Wenn das HA ist, dann ist der gleichzeitig Client (von mqtt2s) und Server für den eigentlich hier beschriebenen Weg MQTT2_CLIENT und MGB? Alles auf Port 1883?!? Klingt für mich nach extremer Schleifengefahr...
Falls jemand genau so wie ich darüber "stolpert" - steht natürlich auch hier: https://forum.fhem.de/index.php?topic=90735.0
Damit die states nach einem HA neustart nach wie vor vorhanden sind müssen die von fhem gepublishten messages "retain"-en.
attr testLicht mqttPublish *:topic={"$base/$device/$name"} *:retain=1
Hallo @all,
beschäftige mich auch eben mit dem Thema. Erstmal danke für die Erklärungen.
Bin jetzt soweit, daß ich alle Werte, die ich im HASS in FHEM habe auch in HA empfange. Die Gegenrichtung benötige ich nicht.
In HA bin ich noch nicht so firm, könnte mir jemand die Einbundung der verschiedenen Lacrosse Sensoren verdeutlichen? Ich habe sowohl die Temp/Humidity, als auch die Temp/Temp Sensoren. Zweitere mit dem externen Fühler. Wie binde ich die jeweils ein?
bisher habe ich das so:
sensor:
- name: LaCrosse06_2D_Gefrier
state_topic: "fhem/LaCrosse06_2D_Gefrier/state"
payload_not_available: 'off'
- name: LaCrosse07_AußenNord
state_topic: "fhem/LaCrosse07/state"
payload_not_available: 'off'
in der mqtt.yaml stehen. Von den Temp/Temp Sensoren (hier LaCrosse06_2D_Gefrier) bekomme ich jedoch nur einen Temperaturwert. wie muß ich das ändern?
Danke im Voraus,
Gruß,
Adolar
Hallo gadget und alle zusammen!
Herzlichen Dank für diesen und weitere sehr hilfreiche Beiträge! 👍
Ja, ich weiß, dass der erste Beitrag schon sehr alt ist. Da es aber noch weitere Beiträge in 2023 gab, nehme ich an, dass auch Neu-Einsteiger (wie ich 😉) hieran immer noch Interesse haben.
Falls jemand in Home Assistant ein Problem mit der mqtt Definition in
configuration.yaml hat...
ZitatEs ist nicht möglich mqtt switch durch Hinzufügen von platform: mqtt zur switch-Konfiguration zu konfigurieren. Weitere Informationen zum Einrichten dieser Integration findest du in der Dokumentation.
... probiert es bitte so (dann klappt es wieder) - liegt wohl an einem Home Assistant Update?
mqtt:
- switch:
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"Zitat von: gadget am 26 Oktober 2020, 10:41:19in 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"
Hallo zusammen!
Den demoswitch konnte ich anlegen, und auch die Status-Änderung klappte in alle Richtungen. Allerdings habe ich immer noch Verständnisschwierigkeiten, wie ich nun einen Sensor (bzw. die Readings eines Device) aus FHEM nach Home Assistant bringe (zunächst möchte ich von HA aus nichts schalten) und hoffe, Ihr könnt mir ein paar hilfreiche Hinweise geben.
Aus HA configuration.yaml (ich würde gerne zunächst mit nur einem Reading - outside_temp - testen):
mqtt:
- sensor:
name: fhem_Mythz_outside_temp
state_topic: "fhem/sensor/Mythz/outside_temp"
availability_topic: "fhem/connection/status"
Das Device (Mythz) ist eine Wärmepumpe und liefert eine Vielzahl von (user)Readings an FHEM, u.a. auch outside_temp:
defmod Mythz THZ /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0@14400
attr Mythz devStateIcon opened:10px-kreis-gruen disconnected:10px-kreis-rot
attr Mythz event-min-interval .*:120
attr Mythz event-on-change-reading .*
attr Mythz firmware 2.06
attr Mythz icon sani_heating
attr Mythz interval_sDisplay 15
attr Mythz interval_sFan 60
attr Mythz interval_sGlobal 300
attr Mythz interval_sHC1 300
attr Mythz interval_sHistory 300
attr Mythz interval_sLast10errors 3600
attr Mythz nonblocking 0
attr Mythz room Heizung
attr Mythz showtime 1
attr Mythz simpleReadTimeout 6
attr Mythz userReadings flow_temp:sGlobal.* {(split ' ', ReadingsVal ("Mythz","sGlobal",0))[3]}, \
return_temp:sGlobal.* {(split ' ', ReadingsVal ("Mythz","sGlobal",0))[5]}, \
outside_temp:sGlobal.* {(split ' ', ReadingsVal ("Mythz","sGlobal",0))[1]}, \
dhw_temp:sGlobal.* {(split ' ', ReadingsVal ("Mythz","sGlobal",0))[9]}, \
dhw_hours:sGlobal.* {(split ' ', ReadingsVal ("Mythz","sHistory",0))[7]},\
dhw_heating:sGlobal.* {(split ' ', ReadingsVal ("Mythz","sHistory",0))[5]}
Es gibt noch viel mehr Parameter (nicht als userReadings, sondern direkt vom Device), aber ich wollte es hier nicht überfrachten.
MQTT2_CLIENT:
defmod HA_MQTT2 MQTT2_CLIENT homeassistant.fritz.box:1883
attr HA_MQTT2 clientId fhem
attr HA_MQTT2 clientOrder MQTT_GENERIC_BRIDGE
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 mqttuser
Die Domäne zu Hause lautet ".fritz.box". FHEM läuft auf einem Raspberry Pi 2 und Home Assistant auf einem Raspberry Pi 4 (ich kann FHEM und HA nicht auf ein Gerät bringen).
MQTT_GENERIC_BRIDGE:
defmod mqttGeneric MQTT_GENERIC_BRIDGE mqtt room=HomeAssistant
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 verbose 0
Ich weiß, dass globalPublish nicht empfohlen ist, aber ich hatte es trotz der vielen Hinweise nicht verstanden, wie ich es machen muss beim demoswitch, damit es auch ohne globalPublish funktioniert. Daher würde ich es gerne zunächst belassen, bis ich mit outside_temp Erfolg habe.
Was mir jetzt konkret völlig unklar ist: Wie lege ich in FHEM nun einen Sensor an, damit er outside_temp liest und per MQTT an HA durchreicht? Also wie wird aus einem UserReading ein Sensor für MQTT? Ich hoffe, das ist die korrekte Frage, und dass Ihr mir weiterhelfen könnt.
Vielen Dank vorab für Eure Zeit! 👍
Bin ich der Einzige, den das Thema noch interessiert und der nicht weiß, wie man da ran geht? 🫢
ich quäle mich gerade auch mit dem Thema, hier evtl eine Hilfestellung wie es bei mir funktioniert -
für den Fall dass du MQTT eingerichtet hast und der Dummy Switch wie von dir beschrieben funktioniert:
- FHEM: Mythz in den HASS Room in FHEM, d.h. alle Readings sind damit auch im mqtt
- HA: in der configuration.yaml:
sensor:
- name: MythzTempVorlauf
unique_id: fhem_mythz_temp_vorlauf
state_topic: "fhem/Mythz/TempVorlauf"
unit_of_measurement: "°C"
Damit sollte die Entität auch schon verfügbar sein!
Das ist ja supereinfach! 😀 Ganz lieben Dank für Deinen hilfreichen Tipp! ❤️ Ich hatte schlicht vergessen, Mythz in den "HASS" Raum zu packen (obwohl das so ganz am Anfang vom Thread erklärt wurde. 🫢)
Schon trudeln die ersten Werte durch den MQTT Explorer (lauscht auf Home Assistant). Den nutze ich unter Windows, um mal eben einen schnellen Check machen zu können.
In HA stimmt dennoch etwas noch nicht, denn dort erscheinen die Parameter als "nicht verfügbar" - obwohl sie im MQTT Explorer (auf HA verbunden) erscheinen.
Aber das Ziel ist wohl nicht mehr weit. Ich bin mir nicht sicher, wie die Sensoren konkret in HA zu benennen sind. Bei mir sieht der Abschnitt in configuration.yaml nun so aus:
- sensor:
name: fhem_Mythz_outside_temp
unique_id: fhem_Mythz_outside_temp
state_topic: "fhem/sensor/Mythz/outside_temp"
unit_of_measurement: "°C"
availability_topic: "fhem/connection/status"
Gerne können wir uns hier weiter austauschen, wenn Du magst. Nochmals vielen Dank! 👍
PS: Mein langfristiges Ziel ist, die Daten in HA nach InfluxDB zu schreiben und über Grafana zu visualisieren. Aber eins nach dem anderen...
Zitat von: CaptainSlow am 04 Dezember 2023, 16:29:20sensor:
- name: MythzTempVorlauf
unique_id: fhem_mythz_temp_vorlauf
state_topic: "fhem/Mythz/TempVorlauf"
unit_of_measurement: "°C"
Nach welchem Muster verwendest Du
name,
unique_id und
state_topic?
Und wofür benötigst Du
unique_id, wenn Du bereits
name hast? Reicht nicht eins aus?
PS:
Ah, ich habe (glaube ich) verstanden, woran's liegt. In FHEM habe ich definiert:
*:topic={"fhem/$device/$reading"}Entsprechend muss ich in HA das state_topic genauso definieren, also:
state_topic: "fhem/Mythz/outside_temp"
@CaptainSlow
Bei mir sieht es auf FHEM-Seite so aus (der Raum bei mir heißt "HomeAssistant", nicht "HASS"):
Internals:
DEF mqtt room=HomeAssistant
FUUID xxxxx
IODev HA_MQTT2
NAME mqttGeneric
NR 310
NTFY_ORDER 70-mqttGeneric
STATE in: 0 out: 11 devices: 1
TYPE MQTT_GENERIC_BRIDGE
devspec room=HomeAssistant
eventCount 371
prefix mqtt
READINGS:
2023-12-04 18:44:03 IODev HA_MQTT2
2023-11-29 09:17:04 attrTemplateVersion 20211208_MQTT
2023-12-04 18:44:03 device-count 0
2023-12-04 18:44:02 incoming-count 0
2023-12-04 20:08:11 outgoing-count 367
2023-12-04 20:08:11 transmission-state outgoing publish sent
2023-12-04 18:44:02 updated-reading-count 0
2023-12-04 18:44:02 updated-set-count 0
devices:
:global:
:alias:
: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"}
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 *
Attributes:
IODev HA_MQTT2
globalDefaults sub:qos=2 pub:qos=0 retain=1 base={"fhem/$device"}
globalPublish *:topic={"fhem/$device/$reading"}
icon mqtt_bridge_2
room MQTT
verbose 0
Und bei Dir?
Nach wie vor sehe ich im MQTT-Explorer (verbunden mit Home Assistant), alle Mythz Readings (wie von mir gewollt), aber trotz der einen Sensor-Definition in configuration.yaml steht unter Entwicklungswerkzeuge => Zustände => Entitäten:
sensor.mythz_outside_temp unavailable
Interessanterweise werde ich diesen Sensor auch nicht mehr los, selbst nach Löschung der Sensor-Definition in configuration.yaml und HA-Neustart. Seltsam, oder?
Ich wäre Dir sehr dankbar, wenn Du mir nochmal etwas detaillierter aufzeigen könntest, wie Du einerseits MQTT2 und die MQTT Bridge auf FHEM und andererseits den Sensor in HA definiert hast. Die HA-Konfig hast Du schon geteilt - nochmals danke, aber musstest Du noch mehr für einen Sensor auf HA-Seite tun?
Jetzt scheint es zu klappen, obwohl ich nur 2 weitere Sensoren/Werte in configuration.yaml hinzugefügt, unique_id sowie availability_topic und den Prefix "fhem" aus den Namen (name) entfernt habe:
mqtt:
sensor:
- name: Mythz_outside_temp
state_topic: "fhem/Mythz/outside_temp"
unit_of_measurement: "°C"
- name: Mythz_flow_temp
state_topic: "fhem/Mythz/flow_temp"
unit_of_measurement: "°C"
- name: Mythz_return_temp
state_topic: "fhem/Mythz/return_temp"
unit_of_measurement: "°C"
Dafür gibt es den alten "outside_temp" Sensor mit dem Wert "unavailable" zwar noch, aber es wurde ein neuer Sensor "outside_temp_2" angelegt mit korrektem Wert. Keine Ahnung, woher das kommt, aber ich untersuche das noch.
FHEM-HA 2023-12-05 162000.png
Der "kaputte" Parameter ist von alleine verschwunden. Geht doch. 😊
Ich fragte mich, welcher Weg sinnvoller ist:
- Auf FHEM-Seite sämtliche UserReadings anlegen und dann für jedes UR die Definition in HA (configuration.yaml) eintragen.
- Auf HA-Seite die Definition für größere Readings wie sGlobal, sHC1 etc. in configuration.yaml eintragen, so dass sie komplett von FHEM via MQTT nach HA übertragen werden und dann auf HA-Seite die gewünschten Parameter-Werte aus den json Payloads extrahieren.
Dort (https://forum.fhem.de/index.php?msg=1289698) plädierte immi (https://forum.fhem.de/index.php?action=profile;u=205) (Author des THZ-Moduls) für die 1. Variante auf eine entsprechende Frage einen Beitrag zuvor. Leider gab's vom Fragesteller roliko (https://forum.fhem.de/index.php?action=profile;u=53615) seither keine Reaktion darauf. Ich nehme an, er hat es irgendwie für sich gelöst.
Ich verwende ebenfalls die 1. Variante und bleibe dabei, denn sie funktioniert, und man kann (wie hier im Thread von gadget bereits angesprochen (https://forum.fhem.de/index.php?msg=1146817)) per Copy & Paste ziemlich schnell für sämtliche Sensoren entsprechende Definitionen festlegen.
An Schalter habe ich mich noch nicht gewagt. Aber das wäre der nächste Schritt, so dass ich von HA aus (bzw. der Android HA App) meine Heizung auch steuern kann. Und mit HA kenne ich mich zugegeben besser aus als mit FHEM. 😉
Und noch ein Beispiel für eine Lovelace Karte in HA, welche Fehler aus dem THZ-Modul anzeigt, also Fehler einer Stiebel Eltron/Tecalor LWZ/THZ Luft-Wärmepumpen-Heizung. Diese kann max. 10 Fehler speichern (Nr. 0-9). Über "conditional" im Lovelace YAML Code auf HA werden nur Fehler-Felder gezeigt, die nicht "unknown" oder "n.a." sind, die also echte Fehler-Codes enthalten.
type: vertical-stack
cards:
- type: conditional
conditions:
- condition: state
entity: sensor.mythz_fault0code
state_not: unknown
- condition: state
entity: sensor.mythz_fault0code
state_not: n.a.
card:
type: entities
entities:
- entity: sensor.mythz_fault0code
icon: mdi:alert-outline
name: Fehler
- entity: sensor.mythz_fault0date
icon: mdi:calendar-alert-outline
name: Datum
- entity: sensor.mythz_fault0time
icon: mdi:clock-alert-outline
name: Uhrzeit
state_color: true
- type: conditional
conditions:
- condition: state
entity: sensor.mythz_fault1code
state_not: unknown
- condition: state
entity: sensor.mythz_fault1code
state_not: n.a.
card:
type: entities
entities:
- entity: sensor.mythz_fault1code
icon: mdi:alert-outline
name: Fehler
- entity: sensor.mythz_fault1date
icon: mdi:calendar-alert-outline
name: Datum
- entity: sensor.mythz_fault1time
icon: mdi:clock-alert-outline
name: Uhrzeit
state_color: true
- type: conditional
conditions:
- condition: state
entity: sensor.mythz_fault2code
state_not: unknown
- condition: state
entity: sensor.mythz_fault2code
state_not: n.a.
card:
type: entities
entities:
- entity: sensor.mythz_fault2code
icon: mdi:alert-outline
name: Fehler
- entity: sensor.mythz_fault2date
icon: mdi:calendar-alert-outline
name: Datum
- entity: sensor.mythz_fault2time
icon: mdi:clock-alert-outline
name: Uhrzeit
state_color: true
- type: conditional
conditions:
- condition: state
entity: sensor.mythz_fault3code
state_not: unknown
- condition: state
entity: sensor.mythz_fault3code
state_not: n.a.
card:
type: entities
entities:
- entity: sensor.mythz_fault3code
icon: mdi:alert-outline
name: Fehler
- entity: sensor.mythz_fault3date
icon: mdi:calendar-alert-outline
name: Datum
- entity: sensor.mythz_fault3time
icon: mdi:clock-alert-outline
name: Uhrzeit
state_color: true
- type: conditional
conditions:
- condition: state
entity: sensor.mythz_fault4code
state_not: unknown
- condition: state
entity: sensor.mythz_fault4code
state_not: n.a.
card:
type: entities
entities:
- entity: sensor.mythz_fault4code
icon: mdi:alert-outline
name: Fehler
- entity: sensor.mythz_fault4date
icon: mdi:calendar-alert-outline
name: Datum
- entity: sensor.mythz_fault4time
icon: mdi:clock-alert-outline
name: Uhrzeit
state_color: true
- type: conditional
conditions:
- condition: state
entity: sensor.mythz_fault5code
state_not: unknown
- condition: state
entity: sensor.mythz_fault5code
state_not: n.a.
card:
type: entities
entities:
- entity: sensor.mythz_fault5code
icon: mdi:alert-outline
name: Fehler
- entity: sensor.mythz_fault5date
icon: mdi:calendar-alert-outline
name: Datum
- entity: sensor.mythz_fault5time
icon: mdi:clock-alert-outline
name: Uhrzeit
state_color: true
- type: conditional
conditions:
- condition: state
entity: sensor.mythz_fault6code
state_not: unknown
- condition: state
entity: sensor.mythz_fault6code
state_not: n.a.
card:
type: entities
entities:
- entity: sensor.mythz_fault6code
icon: mdi:alert-outline
name: Fehler
- entity: sensor.mythz_fault6date
icon: mdi:calendar-alert-outline
name: Datum
- entity: sensor.mythz_fault6time
icon: mdi:clock-alert-outline
name: Uhrzeit
state_color: true
- type: conditional
conditions:
- condition: state
entity: sensor.mythz_fault7code
state_not: unknown
- condition: state
entity: sensor.mythz_fault7code
state_not: n.a.
card:
type: entities
entities:
- entity: sensor.mythz_fault7code
icon: mdi:alert-outline
name: Fehler
- entity: sensor.mythz_fault7date
icon: mdi:calendar-alert-outline
name: Datum
- entity: sensor.mythz_fault7time
icon: mdi:clock-alert-outline
name: Uhrzeit
state_color: true
- type: conditional
conditions:
- condition: state
entity: sensor.mythz_fault8code
state_not: unknown
- condition: state
entity: sensor.mythz_fault8code
state_not: n.a.
card:
type: entities
entities:
- entity: sensor.mythz_fault8code
icon: mdi:alert-outline
name: Fehler
- entity: sensor.mythz_fault8date
icon: mdi:calendar-alert-outline
name: Datum
- entity: sensor.mythz_fault8time
icon: mdi:clock-alert-outline
name: Uhrzeit
state_color: true
- type: conditional
conditions:
- condition: state
entity: sensor.mythz_fault9code
state_not: unknown
- condition: state
entity: sensor.mythz_fault9code
state_not: n.a.
card:
type: entities
entities:
- entity: sensor.mythz_fault9code
icon: mdi:alert-outline
name: Fehler
- entity: sensor.mythz_fault9date
icon: mdi:calendar-alert-outline
name: Datum
- entity: sensor.mythz_fault9time
icon: mdi:clock-alert-outline
name: Uhrzeit
state_color: true
Man kann das in HA sicherlich noch schöner gestalten, aber für den Anfang reicht es mir aus.
Ich hoffe, das ist hier nicht zu sehr off-topic. 😉
@CaptainSlow und alle
Das Lesen in HA von Werten inkl. UserReadings aus FHEM funktioniert. Jedoch ist mir noch unklar, wie ich einen FHEM-Wert (Ventilator-Stufe) von HA aus ändern kann bzw. das dafür Nötige einrichten muss.
Konkretes Beispiel: Meine Heizung hat Lüfter-Stufen 0, 1, 2, 3. Der Wert steht in Mythz/07FanStageDay, und ich sehe ihn auch im MQTT-Explorer:
mqtt 2023-12-08 145346.png
Die Konfiguration in HA sollte über MQTT Fan (https://www.home-assistant.io/integrations/fan.mqtt/) funktionieren, aber ab hier steige ich leider aus, d.h. ich verstehe schon nicht, wie ich meine FHEM-Seite korrekt auf der HA-Seite definieren muss, damit es klappt. Sorry, ich stehe etwas auf dem Schlauch. 🤔
Hat jemand bitte einen helfenden Hinweis für mich? Danke! 🙏
Zitat von: sunrise am 08 Dezember 2023, 15:50:33Konkretes Beispiel: Meine Heizung hat Lüfter-Stufen 0, 1, 2, 3. Der Wert steht in Mythz/07FanStageDay, und ich sehe ihn auch im MQTT-Explorer:
Zum Setzen via MQTT mit MQTT_GENERIC_BRIDGE muss (u.a. von HA aus) ein _anderer_ topic verwendet werden (Schleifengefahr!), und der muss dann eben auf der FHEM-Seite auch entsprechend konfiguriert werden (subscribe-Attribut, dort stopic). Genau davon handelt doch dieser Thread...
Abstraktes Beispiel:
set/Mythz/07FanStageDay
Ja, aber wie definiere ich einen echten FHEM-Wert als Schalter?
Folgendes ist doch nur ein Dummy:
attr demoswitch mqttSubscribe state:stopic={"$base/set"}Ich habe hier ein Mythz/07FanStageDay, und mir ist nach der mehrfachen Lektüre dieses ganzen Threads immer noch unklar, was ich tun muss, um das als eine Art Schalter zu definieren.
Bei den Readings (also FHEM => HA, read-only) reichte es aus, in FHEM das Mythz Device in the "HASS" Raum zu stellen und dann auf HA-Seite die Konfiguration für einen Sensor vorzunehmen.
Aber für einen Lüfter-Wert, der zudem auch noch von HA aus gesteuert werden soll? Sorry, ich weiß überhaupt nicht, wo ich da einsteigen muss.
Zitat von: sunrise am 08 Dezember 2023, 17:16:20Aber für einen Lüfter-Wert, der zudem auch noch von HA aus gesteuert werden soll? Sorry, ich weiß überhaupt nicht, wo ich da einsteigen muss.
Es gibt doch hier (und im howto-Thread von Hexenmeister) viele Beispiele für "schaltbares" Zeug via MGB. Leider gibt es nicht sowas wie einen "allgemeingültigen" Standard. Die Schritte sind aber immer dieselben:
1. Finde in "der Außenwelt" (also bei dir: HA) ein "Element" (Gerät, ...), das in Stufen von 0-3 geschaltet werden kann. Das kann z.B. auch ein dimmbares "Licht" sein. FHEM ist es jedenfalls egal, wie es in HA aussieht.
2. Wenn du in HA schaltest, sorge dafür, dass der Wert dann an den Topic gesendet wird, auf dem
3. FHEM das subscribe macht, also mal angenommen, dein "$base" steht für "
Mythz/07FanStageDay", eben an "
Mythz/07FanStageDay/set" (mit stopic, wobei der Reading-Name passen sollte. Ist das wirklich "state"? Oder das Reading "
07FanStageDay" am Device Mythz?!?
Sorry, aber auch hier gilt wieder: nur mit Schnippseln ist es schwierig, und ich (wie die meisten anderen Helfer) haben vermutlich kein THZ-Device und kennen weder dessen Verhalten noch dessen Readings...
Zitat von: Beta-User am 08 Dezember 2023, 17:34:531. Finde in "der Außenwelt" (also bei dir: HA) ein "Element" (Gerät, ...), das in Stufen von 0-3 geschaltet werden kann. Das kann z.B. auch ein dimmbares "Licht" sein. FHEM ist es jedenfalls egal, wie es in HA aussieht.
Das verstehe ich nicht. Ich kann doch nicht etwas in HA finden, das noch gar nicht dort definiert ist.
Es ist doch anders herum: Meine THZ Heizung ist in FHEM eingebunden, und ich kann deren Readings komplett in HA lesen, weil ich alles aus dem THZ-Modul über MQTT rauspuste (globalPublish*) und in HA für jeden mich interessierenden Reading-Wert einen Sensor konfiguriert habe.
(*Ich weiß, das ist schlecht, aber zum Anfangen war's für mich erst einmal ok.)
Nun gibt es in FHEM einen THZ Parameter
p07FanStageDay, der Werte von 0, 1, 2 oder 3 annehmen kann, d.h. ich kann diesen Wert setzen, und dann wird er von FHEM auch so angezeigt. Mir fällt es sehr schwer zu verstehen, wie ich so einen Parameter in FHEM "umbauen" (erweitern?) muss, damit der via MQTT an HA geht und umgekehrt auch von dort gesetzt werden kann.
Die Code-Beispiele kenne ich, aber da sind es z.B. Dimmer oder Schalter, nichts, was ich mit einem 4-stufigen (0, 1, 2, 3) Ventilator einer Heizung vergleichen kann - zumindest verstehe ich es nicht.
Gerne poste ich hier mehr Details (statt nur Schnipsel), aber mir ist nicht klar, was genau von mir benötigt wird. Ich bitte um Verzeihung, dass ich mich blöd anstelle. Ich bin wirklich lernwillig, aber trotz meines Bemühens hat es noch nicht "Klick" gemacht.
Hier die RAW Definition (ohne setstates - bis auf das eine relevante) meines THZ Devices. Es sind auch viele userReadings enthalten, aber das für mich zunächst interessante
p07FanStageDay ist kein userReading, sondern kommt direkt über's Device.
defmod Mythz THZ /dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0@14400
attr Mythz userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
attr Mythz devStateIcon opened:10px-kreis-gruen disconnected:10px-kreis-rot
attr Mythz event-min-interval .*:120
attr Mythz event-on-change-reading .*
attr Mythz firmware 2.06
attr Mythz icon sani_heating
attr Mythz interval_sDisplay 15
attr Mythz interval_sFan 60
attr Mythz interval_sGlobal 300
attr Mythz interval_sHC1 300
attr Mythz interval_sHistory 3600
attr Mythz interval_sLast10errors 3600
attr Mythz nonblocking 0
attr Mythz room Heizung,HomeAssistant
attr Mythz showtime 1
attr Mythz simpleReadTimeout 6
attr Mythz userReadings outsideTemp:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[1]}, \
flowTemp:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[3]}, \
returnTemp:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[5]}, \
hotGasTemp:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[7]}, \
dhwTemp:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[9]}, \
flowTempHC2:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[11]}, \
evaporatorTemp:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[13]}, \
condenserTemp:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[15]}, \
mixerOpen:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[17]}, \
mixerClosed:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[19]}, \
heatPipeValve:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[21]}, \
diverterValve:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[23]}, \
dhwPump:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[25]}, \
heatingCircuitPump:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[27]}, \
solarPump:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[29]}, \
compressor:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[31]}, \
boosterStage3:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[33]}, \
boosterStage2:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[35]}, \
boosterStage1:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[37]}, \
highPressureSensor:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[39]}, \
lowPressureSensor:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[41]}, \
evaporatorIceMonitor:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[43]}, \
signalAnode:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[45]}, \
evuRelease:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[47]}, \
ovenFireplace:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[49]}, \
STB:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[51]}, \
outputVentilatorPower:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[53]}, \
inputVentilatorPower:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[55]},\
mainVentilatorPower:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[57]},\
outputVentilatorSpeed:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[59]}, \
inputVentilatorSpeed:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[61]}, \
mainVentilatorSpeed:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[63]}, \
outsideTempFiltered:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[65]}, \
relHumidity:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[67]}, \
dewPoint:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[69]}, \
P_Nd:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[71]}, \
P_Hd:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[73]}, \
actualPower_Qc:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[75]}, \
actualPower_Pel:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[77]}, \
collectorTemp:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[79]}, \
insideTemp:sGlobal.* {(split ' ',ReadingsVal("Mythz","sGlobal",0))[81]}, \
number_of_faults:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[1]}, \
fault0CODE:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[3]}, \
fault0TIME:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[5]}, \
fault0DATE:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[7]}, \
fault1CODE:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[9]}, \
fault1TIME:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[11]}, \
fault1DATE:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[13]}, \
fault2CODE:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[15]}, \
fault2TIME:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[17]}, \
fault2DATE:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[19]}, \
fault3CODE:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[21]}, \
fault3TIME:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[23]}, \
fault3DATE:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[25]}, \
fault4CODE:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[27]}, \
fault4TIME:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[29]}, \
fault4DATE:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[31]}, \
fault5CODE:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[33]}, \
fault5TIME:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[35]}, \
fault5DATE:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[37]}, \
fault6CODE:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[39]}, \
fault6TIME:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[41]}, \
fault6DATE:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[43]}, \
fault7CODE:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[45]}, \
fault7TIME:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[47]}, \
fault7DATE:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[49]}, \
fault8CODE:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[51]}, \
fault8TIME:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[53]}, \
fault8DATE:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[55]}, \
fault9CODE:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[57]}, \
fault9TIME:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[59]}, \
fault9DATE:sLast10errors.* {(split ' ',ReadingsVal("Mythz","sLast10errors",0))[61]}, \
dhwBoosterStage:sDHW.* {(split ' ',ReadingsVal("Mythz","sDHW",0))[13]}, \
dhwOpMode:sDHW.* {(split ' ',ReadingsVal("Mythz","sDHW",0))[17]}, \
integralHeat:sHC1.* {(split ' ',ReadingsVal("Mythz","sHC1",0))[7]}, \
heatSetTemp:sHC1.* {(split ' ',ReadingsVal("Mythz","sHC1",0))[11]}, \
heatTemp:sHC1.* {(split ' ',ReadingsVal("Mythz","sHC1",0))[13]}, \
seasonMode:sHC1.* {(split ' ',ReadingsVal("Mythz","sHC1",0))[15]}, \
integralSwitch:sHC1.* {(split ' ',ReadingsVal("Mythz","sHC1",0))[17]}, \
hcOpMode:sHC1.* {(split ' ',ReadingsVal("Mythz","sHC1",0))[19]}, \
roomSetTemp:sHC1.* {(split ' ',ReadingsVal("Mythz","sHC1",0))[21]}, \
onHysteresisNo:sHC1.* {(split ' ',ReadingsVal("Mythz","sHC1",0))[33]}, \
offHysteresisNo:sHC1.* {(split ' ',ReadingsVal("Mythz","sHC1",0))[35]}, \
hcBoosterStage:sHC1.* {(split ' ',ReadingsVal("Mythz","sHC1",0))[37]}, \
dhw_heating:sGlobal.* {(split ' ', ReadingsVal ("Mythz","sHistory",0))[5]}, \
dhw_hours:sGlobal.* {(split ' ', ReadingsVal ("Mythz","sHistory",0))[7]}
setstate Mythz 2023-12-08 15:32:45 p07FanStageDay 3defmod HA_MQTT2 MQTT2_CLIENT homeassistant.fritz.box:1883
attr HA_MQTT2 clientId fhem
attr HA_MQTT2 clientOrder MQTT_GENERIC_BRIDGE
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 mqttuser
setstate HA_MQTT2 opened
setstate HA_MQTT2 2023-12-08 11:57:55 state opened
defmod mqttGeneric MQTT_GENERIC_BRIDGE mqtt room=HomeAssistant
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 verbose 0
setstate mqttGeneric in: 0 out: 11 devices: 1
setstate mqttGeneric 2023-12-08 11:57:55 IODev HA_MQTT2
setstate mqttGeneric 2023-11-29 09:17:04 attrTemplateVersion 20211208_MQTT
setstate mqttGeneric 2023-12-08 11:57:55 device-count 0
setstate mqttGeneric 2023-12-08 11:57:55 incoming-count 0
setstate mqttGeneric 2023-12-08 18:23:35 outgoing-count 4544
setstate mqttGeneric 2023-12-08 18:23:35 transmission-state outgoing publish sent
setstate mqttGeneric 2023-12-08 11:57:55 updated-reading-count 0
setstate mqttGeneric 2023-12-08 11:57:55 updated-set-count 0
Zitat von: sunrise am 08 Dezember 2023, 18:27:35Das verstehe ich nicht. Ich kann doch nicht etwas in HA finden, das noch gar nicht dort definiert ist.
Eben. Du musst es dort definieren. Im Prinzip genau so wie du eine MQTT-Leuchte anlegen würdest (ein Tasmota-geflashtes Leuchtmittel, z.B.). (Ich weiß, dass HA sowas in der Regel per "discovery" automatisch machen kann, aber das geht hier nicht und es gibt auch einen manuellen Weg).
Alles, was du in HA schalten willst, muss dort m.E. auch schaltbar angelegt sein. Würde mich überraschen, wenn jemand mit HA-Erfahrung was anderes wüßte... Also statt "sensor" mal ein "light" anlegen (da gibt es bestimmt Optionen, die Grenzen für's dimmen entsprechend zu setzen).
Danke, jetzt habe ich ich richtig verstanden.
Frage an Diejenigen hier, die bereits erfolgreich FHEM-Schalter mit mehreren Stufen in HA angelegt haben:
Habt Ihr dafür in HA Lichter, Schalter oder gar MQTT Fan (https://www.home-assistant.io/integrations/fan.mqtt/) angelegt?
Ich verstehe es schlicht nicht. 🙄 Ein Topic lautet z.B.: fhem/Mythz/p07FanStageDay
Es kann Werte von 0, 1, 2 oder 3 annehmen. Es gibt kein state_topic o.ä., sondern nur dies.
In Beispielen zu Lichtern finde ich u.a. für einen EnOcean Dimmer das:
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"
Leider ist das aber überhaupt nicht auf meinen Fall anwendbar.
Erstens, weiß ich nicht, wie ich ein command_topic umbauen müsste
von: "fhem/Eltako_Aktor_FUD71_19888CA/set"
nach: "fhem/Mythz/p07FanStageDay ... ?"
Und zweitens gibt es bei mir keine "brightness" und somit auch keine entsprechenden command_topics oder state_topics dafür.
Sorry, ich stehe immer noch auf dem Schlauch. Gibt's hier niemand, der einen ähnlichen Fall wie ich hat? Es muss ja keine Heizung sein, aber ein Reading, das 3-4 Werte annehmen kann wäre für mich Anfänger als Einstieg und Beispiel wirklich sehr hilfreich. Dankeschön, wenn sich hierzu noch jemand konkreter äußern könnte. 😉
Und auch danke an Beta-User und andere User, die sich hier schon gemeldet haben! 😊
Zitat von: sunrise am 11 Dezember 2023, 13:49:09Ich verstehe es schlicht nicht. 🙄 Ein Topic lautet z.B.: fhem/Mythz/p07FanStageDay
Es kann Werte von 0, 1, 2 oder 3 annehmen. Es gibt kein state_topic o.ä., sondern nur dies.
Noch ein Versuch:
1. Welche Topics es gibt, kannst du auch mit entscheiden. Wichtig für eine "set"-Anweisung ist nur, dass beide Seiten (Anweisendes HA und "empfangendes FHEM") diesen Topic kennen. Ob der "fhem/Mythz/p07FanStageDay/set" oder "Timbuktu/Hinflug/Lufthansa" lautet, ist komplett egal...
2. Für "aktive" Komponenten braucht man zwingend* einen "Kreis", keine einfache "Linie". Das Topic, auf dem eine Anweisung abzusetzen ist, ist immer ein ANDERES wie das, auf dem die Antwort ("erledigt") kommen sollte. Genau, wie es bei dem "brightness"-Ding der Fall ist. Zwei (!) Topics.
3. Für dein "Ding" hast du jetzt "nur" das Problem, dass es halt kein Licht ist, und der "on/off"-Zustand nicht separat geschaltet werden kann. Von daher würde ich für "state-on" halt einfach nochmal denselben Datenpunkt (fhem/Mythz/p07FanStageDay) nehmen und erst mal den "off"-Wert mit "0" belegen.
4. Wenn es bis dahin immer noch nicht klar ist: Konzentriere dich erst mal nur darauf, den Kreis für "brightness" (1-3) zu schließen. Wenn du mit der HA-Einrichtung nicht weiter kommst, nimm irgendein anderes MQTT-Tool (z.B. mosquitto_pub) und sende den Soll-Wert auf das "set"-Topic. Wie gesagt: Du kannst es frei wählen, es sollte aber anders sein wie das, was du bisher als "sensor" eingetragen hattest (das bleibt für den Rückflug). Und du musst es in FHEM passend konfigurieren (ich empfehle erst mal "Klartext" ohne Variablen für das subscribe-Attribut).
Hoffe, das wird jetzt langsam klarer?
*Ja, man kann es in bestimmten Fällen anders machen, aber das ist m.E. schlechtes Design!
Ich habe die Anbindung von MAX-Geräten aus FHEM in Home Assistant via MQTT automatisiert:
https://github.com/danielrheinbay/fhemMAX2HASS/
Durch die Nutzung des MQTT Discovery Protokolls entfällt die aufwändige und fehleranfällige Konfiguration von zig MQTT-Sensoren in Home Assistant.
Freue mich über Feedback und Verbesserungen, gern in Form von Pull Requests.
Hallo zusammen!
Ich verwende FHEM als "hidden" Automationszentrale zu welcher nur ich Zugriff habe, für den WAF habe ich Home Assistant als Interface. Die Anwesenheit meiner Frau und von mir wird über Owntracks geprüft, unser Sohn verweigert Owntracks und Home Assistant, weshalb ich seine Anwesenheit so recht und schlecht über Home Assistant tracke. Und zwar über den device_tracker seines iPhones. Hier erhalte ich zuverlässig den Status "home" bzw. "not_home" bei An- bzw. Abwesenheit. Den Status möchte ich an FHEM weiterreichen. Nun hat HA die Eigenschaft, dass nur dann ein Event ausgegeben wird, wenn die Zone des iPhones von einer Zone zu einer anderen Zone wechselt (z.B: work->home) Aber nicht, wenn von not_home auf home. Daher kann ich keine Automation in HA triggern und den neuen Status an FHEM übergeben. Aus diesem Grund muss ich über die MQTT-Bridge den aktuellen Zustand weiterreichen.
Bei Switches funktioniert das bei mir einwandfrei:
FHEM:
defmod Presence_Nici dummy
attr Presence_Nici userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
attr Presence_Nici mqttForward all
attr Presence_Nici mqttSubscribe state:stopic={"$base/set"}
attr Presence_Nici room HASS,Development
attr Presence_Nici webCmd on:off
HA:
- name: Presence_Nici
command_topic: "fhem/Presence_Nici/set"
state_topic: "fhem/Presence_Nici/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"
Egal wo ich schalte, das Ergebnis wird an das andere System korrekt "durchgereicht". Nun kann ich aber HA-seitig "home" und "not_home" nicht auf "on" und "off" übersetzen und muss mit den Springs arbeiten. Daher handelt es sich nicht mehr um einen Switch, sondern um einen Sensor (in HA-Nomenklatur). Ich habe das nun so definiert:
FHEM:
defmod Presence_Test dummy
attr Presence_Test userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
attr Presence_Test mqttForward all
attr Presence_Test mqttSubscribe state:stopic={"$base/set"}
attr Presence_Test room HASS,Development
attr Presence_Test webCmd home:not_home
HA:
- name: Presence_Test
state_topic: "fhem/Presence_Test/state"
availability_topic: "fhem/connection/status"
payload_available: "connected"
payload_not_available: "disconnected"
Wenn ich FHEM-seitig zwischen "home" und "not_home" hin- und her schalte, dann wird das HA-seitig (wie bei allen anderen Sensoren - z.B. Luftfeuchte) richtig angezeigt/verändert. Umgekehrt wird der veränderte Status jedoch nicht durchgereicht. Zumindest
command_topic:
bei einem Switch ist nicht zulässig. Was muss ich machen, damit eine Statusänderung auch von HA nach FHEM geht?
Sorry, dass ich auf Deinen doch schon älteren - aber immer noch aktuellen - Hinweis eine Frage habe:
Zitat von: Beta-User am 22 Februar 2021, 11:10:56Bitte aber KEIN globales publish angeben, (auch) das sollte mAn. immer am Device (=> "schrank") konfiguriert werden...
Im Wiki (https://wiki.fhem.de/wiki/MQTT_GENERIC_BRIDGE#Readingwerte_publishen) steht:
attr mySensor mqttPublish temperature|humidity|battery:topic={"$base/$device/$name"}Ich habe hier einen Sensor (Stromzähler Device
MyObis1), für den ich über Wildcards bei
event-on-change-reading einige Parameter berücksichtige:
.*consumption.*,power.*Kann ich entsprechend solche Wildcards dann so für die MGB umsetzen?
attr MyObis1 mqttPublish .*consumption.*|power.*:topic={"fhem/$device/$reading"}Das Topic {...} sieht im Wiki anders aus als in meinem (noch)
globalPublish, das ich nun endlich rauswerfen will, aber möglichst ohne mir dabei etwas zu zerschießen - daher meine Frage, ob/wie ich das richtig umsetze im
attr zum Device. Danke für Deine Hilfe!
Zitat von: sunrise am 29 Januar 2024, 19:11:30Kann ich entsprechend solche Wildcards dann so für die MGB umsetzen?
Hmm, also:
- ob das mit den wildcards so klappt, müßte man austesten, es wird jedenfalls erst mal so akzeptiert...
- die "globalen" settings werden - soweit ich mich entsinne - durch die Settings am einzelnen Device überschrieben (soweit sie passen), und das Gesamt-Ergebnis ist dann an der MGB in "get deviceinfo" sichtbar. Du kannst also durchaus erst mal den Test am Einzeldevice machen, ohne dir groß was zu zerschießen.
Würde mich auch interessieren, ob das so mit ".*" klappt...
Vor dem Testen ggf. dann mal ein "save" aufrufen, damit die letzten Reading-Stände weggeschrieben werden.
Moin,
irgendwie stehe ich hier gewaltig auf dem Schlauch, das Demogerät aus dem ersten Thread in HA zur Anzeige zu bringen.
Zitat von: gadget am 26 Oktober 2020, 10:41:19in der configuration.yaml:
Code Auswählen Erweitern
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.
Ich bin hier genau so vorgegangen, allerdings wird nichts in HA angezeigt. Meine configuration.yaml sieht insgesamt so aus:
# Loads default set of integrations. Do not remove.
default_config:
# Load frontend themes from the themes folder
frontend:
themes: !include_dir_merge_named themes
automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.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"Was mache ich hier falsch? Über nen kleinen Tipp wäre ich sehr dankbar!
Gruß
Michael
Guten Morgen,
danke für die tolle Anleitung @gadget!
Kann mir jemand ein Codebeispiel für einen Homematic Fenstersensor geben?
Ich habe aktuell folgendes:
- binary_sensor:
name: "Optisch_Dachfenster"
unique_id: "optisch_dachfenster"
state_topic: "fhem/Optisch_Dachfenster/state"
payload_on: "open"
payload_off: "closed"
availability_topic: "fhem/connection/status"
payload_available: "connected"
payload_not_available: "disconnected"
Ich verstehe leider nicht wie ich z.B. den Batteriestatus hinzufügen kann.
Hat jemand solch einen Sensor (HM-SEC-SCO) per MQTT in HASS eingebunden?
Grüße, Dave
Moin!
Klinke mich hier mal ein:
Habe FHEM und Mosquitto seit Ewigkeiten bei mir auf einem Ubuntu Server installiert. (natürlich immer wieder upgedated)
Tasmota Devices sind via MQTT (nicht 2) angebunden.
Kann es sein, dass aufgrund der Installation von Home Assistant (u. a. mit der Tasmota Integration und MQTT) FHEM bzw. FTUI "stört" ?
Seit einiger Zeit friert meine Übersichtsseite in der Tablet UI regelmäßig ein. FullyKiosk startet die dann zwar immer wieder neu, aber das passiert so ca. alle paar Minuten und nervt.
Hatte da bisher Home Assistant nicht für verantwortlich gemacht, weil ich eigentlich der Meinung bin, dass doch HA sowie FHEM nur Clients sind und dem Mosquitto Server nur zuhören.
Können die sich gegenseitig stören und die Tablet UI sogar zum einfrieren bringen? (aktualisieren der Seite geht sofort und liefert aktuelle Daten der MQTT Devices)
War der Meinung, dass dieses Phänomen nach einem FHEM Update eingetreten ist.
Fehler im Protokoll von FHEM sieht man diesbezüglich auch nicht wirklich...
Republishen eines Attributes:
Hi zusammen, ich muss hier nochmal nach all den Jahren, die mein System doch halbwegs passabel läuft, mal eine Frage stellen:
Kann ich erzwingen, dass ein Attribut, neu gepublished wird, wenn ich es von außerhalb per mqtt setze?
Folgende Situation: Ich muss aus... Gründen... zwischen Homeassistant und Fhem eine Zahl in einem Fhem Dummy aktuell halten.
Der Fhem-Dummy heißt RolloDummy und hat ein Reading "AktuellerKanal".
Auf der Homeassistant-Seite ist die Entity folgendermaßen definiert:
- name: "Rollo-Kanal"
unique_id: "rollokanal"
state_topic: "fhem/RolloDummy/AktuellerKanal"
command_topic: "fhem/set/RolloDummy/AktuellerKanal"
min: 1
max: 15
auf der Fhem-Seite ist der Dummy folgendermaßen definiert:
defmod RolloDummy dummy
attr RolloDummy userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
attr RolloDummy alexaName Rollokanal
attr RolloDummy genericDeviceType thermostat
attr RolloDummy group Hilfsgeräte
attr RolloDummy homebridgeMapping TargetTemperature=AktuellerKanal::AktuellerKanal,minValue=1.0,maxValue=15.0,minStep=1.0\
CurrentTemperature=RolloDummy:AktuellerKanal, nocache=1
attr RolloDummy mqttPublish AktuellerKanal:topic={"$base/$name"}
attr RolloDummy mqttSubscribe AktuellerKanal:stopic={"$base/AktuellerKanal"}
attr RolloDummy readingList AktuellerKanal
attr RolloDummy room Interfaces->homekit,MQTT_HA,fhem,fhem->Alexa
attr RolloDummy setList AktuellerKanal:1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
attr RolloDummy siriName Rollo Kanal
attr RolloDummy stateFormat {ReadingsVal("RolloDummy","AktuellerKanal",0)}
attr RolloDummy webCmd AktuellerKanal
Wenn ich nun von Homeassistant die Nummer ändere, kann ich sehen, dass fhem/set/RolloDummy mit der Nummer gesendet wird und Fhem diese Nummer auch ünernimmt.
Fhem sendet dann aber kein Update der Nummer raus, weshalb bspw der Slider der Nummer in Homeassistant auf der neuen Nummer steht, das Entity aber kein Update bekommt, weil es auf FHem wartet.
Hat jemand eine Idee, was ich da bei FHem noch einstellen muss?
Vielen Dank! :)
Zitat von: jazzor am 24 April 2024, 21:49:32Republishen eines Attributes:
Hi zusammen, ich muss hier nochmal nach all den Jahren, die mein System doch halbwegs passabel läuft, mal eine Frage stellen:...
Da ich nun meinen Fehler gefunden habe, möchte ich zukünftige Generationen vor dem gleichen Schicksal wie mich bewahren:
Das Standardverhalten von mqttForward ist für Dummy-Geräte nicht "all" sondern "none". Im Gegensatz zu allen anderen Geräten. Damit wird bei Dummy-Geräten nixhts weitergeleitet! Wer lesen kann ist klar im Vorteil :D
P.S.: Ich will gar nicht anfangen, was ich alles versucht habe, weil ich mir sicher war, dass mqqForward immer gilt... ;)
Hallo in die Runde,
ich stehe vor folgender Fragestellung:
Ich habe einen Homematicdimmer (HM-LC-DIM1L-PL-3) und möchte diesen über HA ansteuern.
Dazu habe ich in HA in der einer mqqt.yaml folgendes angelegt:
- light:
- name: "Deckenfluter2"
unique_id: light.Wohnzimmer.Deckenfluter.2
state_topic: "fhem/HM_41E8A6_Dim/state"
brightness_command_topic: "fhem/HM_41E8A6_Dim/brightness"
brightness_scale: "100"
brightness_state_topic: "fhem/HM_41E8A6_Dim/level"
command_topic: "fhem/HM_41E8A6_Dim/set"
payload_on: "on"
payload_off: "off"
qos: 1
optimistic: false
und in fhem:
internals:
DEF 41E8A601
FUUID 5c521477-f33f-f80f-2e74-69eda06aa42fa1e0
LASTInputDev ha_MQTT2
MSGCNT 5
NAME HM_41E8A6_Dim
...
...
...
Attributes:
alexaName Deckenfluter
alias Deckenfluter
genericDeviceType light
homebridgeMapping Brightness=dim::dim,minValue=0,maxValue=100, cmd=dim, minStep=1
model HM-LC-DIM1L-PL-3
mqttSubscribe state:stopic={"$base/set"} pct:stopic={"$base/brightness"}
peerIDs 00000000
room AlexaControl,HASS,Homekit,Wohnzimmer
siriName Deckenfluter
userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0 mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
webCmd statusRequest:toggle:on:off:up:down
Nun stelle ich folgendes Verhalten fest:
1) Wenn ich in fhem den Dimmer bediene werden die Werte auch nach HA übermittelt --> OK
2) Wenn ich in HA den Dimmer bediene kann ich den Dimmer ein-/ausschalten, aber nicht dimmen --> NOK
3) Tausche ich hingegen die Reihenfolge der Parameter im Attribut mqqtSubscribe von
mqttSubscribe state:stopic={"$base/set"} pct:stopic={"$base/brightness"}
auf
mqttSubscribe pct:stopic={"$base/brightness"} state:stopic={"$base/set"} kann ich dimmen, aber nicht mehr ein-/ausschalten über HA --> NOK.
Fazit: Es scheint so zu sein, als ob fhem den zweiten stopic-Parameter nicht parsen kann.
Habt Ihr Tipps für mich?
Grüße
obelix
Hi,
ich stelle vermutlich eine saudoofe Frage.
Ich habe auch eine größere Fhem Umgebung laufen
und baue gerade nebenbei auch Homeassitent auf...
Da ich noch viele FHT80 Thermostate und Antriebe besitze und es für HASS da nichts gibt.
Möchte ich eigentlich meine ganze FHEM Umgebung weiter betreiben und alles über MQTT Generic Bridge laufen lassen.
Die Thermostate laufen nun schon über die Bridge und funktioniert auch in HASS
Nun habe ich gesehen, dass es für HASS eine Tasmota Integration gibt, welche mit Hilfe der Tasmota Discocery Nachricht die Geräte anlegt.
Ich frage mich gerade was ich tun muss um die "tasmota/discovery" Nachrichten über die Bridge weiterzuleiten?
Geht das? oder ist mein Gedanke falsch?
Hallo,
erstmal vielen Dank für die tolle Anleitung in Post #2. Dank der konnte ich meine Lacrosse Temperatur- und Luftfeuchtigkeitssensoren, meine max! Fensterkontakte und meine PCA301 in beide Richtungen sowohl FHEM als auch HA betrieben.
Die max! Heizkörperthermostate habe ich nur in eine Richtung hinbekommen - ich kann die Readings in HA auslesen.
Ich kann sogar die gewünschte Temperatur mit HA hier platzieren:
mosquitto_sub -h ip -u hamqtt -P passwd -t 'fhem/heizungXY/desiredTemperature'
6.0
6.0
10.0
9.0
Aber im Gegensatz zu den Schaltern will max! in FHEM den Wert von HA nicht im Gerät setzen / annehmen?
Was fehlt mir auf der FHEM Seite, dass hier ein set desiredTemperature 9.0 passiert?
Habe diese drei Kombinationen bereits erfolglos probiert:
attr heizungXY mqttSubscribe state:stopic={"$base/set"}
attr heizungXY mqttSubscribe desiredTemperature:stopic={"$base/desiredTemperature"}
attr heizungXY mqttSubscribe state:stopic={"$base/desiredTemperature"}
Zitat von: beckerheinz am 22 Juli 2024, 16:23:13Hallo,
erstmal vielen Dank für die tolle Anleitung in Post #2. Dank der konnte ich meine Lacrosse Temperatur- und Luftfeuchtigkeitssensoren, meine max! Fensterkontakte und meine PCA301 in beide Richtungen sowohl FHEM als auch HA betrieben.
Die max! Heizkörperthermostate habe ich nur in eine Richtung hinbekommen - ich kann die Readings in HA auslesen.
Ich kann sogar die gewünschte Temperatur mit HA hier platzieren:
mosquitto_sub -h ip -u hamqtt -P passwd -t 'fhem/heizungXY/desiredTemperature'
6.0
6.0
10.0
9.0
Aber im Gegensatz zu den Schaltern will max! in FHEM den Wert von HA nicht im Gerät setzen / annehmen?
Was fehlt mir auf der FHEM Seite, dass hier ein set desiredTemperature 9.0 passiert?
Habe diese drei Kombinationen bereits erfolglos probiert:
attr heizungXY mqttSubscribe state:stopic={"$base/set"}
attr heizungXY mqttSubscribe desiredTemperature:stopic={"$base/desiredTemperature"}
attr heizungXY mqttSubscribe state:stopic={"$base/desiredTemperature"}
Ich habe es selbst gelöst.
attr heizungXY mqttSubscribe state:stopic={"$base/set"}
ist richtig - man muss allerdings bei HA mittels Template beim set ein desiredTemperature davorsetzen (da der Befehl in fhem bei max set desiredTemperature 20.5 und nicht nur set 20.5 lautet)
Hallo zusammen,
ich habe diesen informativen Thread der zu meinem Anliegen passt erst jetzt gefunden.
Mein Ziel ist es eine Klimaanlage, die ich in Home Assitant eingebunden habe von FHEM aus zu steuern.
Ich wollte jetzt das ganze mit einem Licht testen um so die Verbindung zwischen HA und FHEM herzustellen.
Eine Frage zur MQTT-Verbindung zwischen HA und FHEM:
Ich habe auf FHEM schon einen MQTT2-Server über den ich einige Tasmota-Device bediene.
Brauche ich dann für die Verbindung trotzdem zusätzlich den MQTT2_CLIENT wie im 2. Post in diesem Thread als Bsp. angegeben oder ist dann der Weg ein anderer?
Vielen Dank.
Grüße
MGB akzeptiert auch einen internen Server als IO. Es ist also kein M2C erforderlich, auf der HASS-Seite ist dann der M2S als Server zu konfigurieren.
Danke dir für die schnelle Antwort.
Das muss ich mir mal anschauen, ob ich das hinbekomme.
Wenn ich beim Versuch scheitere und lieber dem Bsp. aus dem 2. Post hier folgen will, funktioniert das dann problemlos mit dem MQTT2-Server und Client gleichzeitig auf der FHEM-Instanz?
Grüße
Zitat von: Knallfrosch am 22 August 2024, 10:56:17Wenn ich beim Versuch scheitere und lieber dem Bsp. aus dem 2. Post hier folgen will, funktioniert das dann problemlos mit dem MQTT2-Server und Client gleichzeitig auf der FHEM-Instanz?
Warum sollte das scheitern? Einen MQTT2_CLIENT auf einen MQTT2_SERVER in derselben (!) FHEM-Instanz hören zu lassen, geht zwar, erzeugt aber schlicht unnötig Last...
Die Anleitung aus dem 2. Post dürfte "veraltet" sein, mAn. einfacher sollte es mit dem attrTemplate-Feature gehen, siehe Wiki.
Zitat von: Beta-User am 23 August 2024, 08:35:57Warum sollte das scheitern?
Weil ich nur sehr begrenzt Ahnung habe. O:-)
Ich habe schon einige Zeit nach einer Anleitung gesucht, aber bisher habe ich es nicht auf die Reihe bekommen FHEM mit HA bekannt zu machen.
Hallo,
also ich habe etwas Zeit gefunden und versucht das auf die Reihe zu bekommen.
Ich habe es zumindest, mit dem Beispiel auf Seite 2 geschafft.
Die yaml.configuration musste ich aber anpassen. Was wohl an einem Update von HA liegt.
Mit folgender Yaml-Config habe ich es geschafft:
# Loads default set of integrations. Do not remove.
default_config:
# Load frontend themes from the themes folder
frontend:
themes: !include_dir_merge_named themes
automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml
mqtt:
switch:
- unique_id: DemoSwitch
name: "demoswitch"
state_topic: "fhem/demoswitch/state"
command_topic: "fhem/demoswitch/set"
availability_topic: "fhem/connection/status"
payload_available: "connected"
payload_not_available: "disconnected"
payload_on: "on"
payload_off: "off"
state_on: "on"
state_off: "off"
optimistic: false
qos: 0
retain: false
- unique_id: Haengeschrank_1
name: "Haengeschrank_1"
state_topic: "fhem/Haengeschrank_1/state"
command_topic: "fhem/Haengeschrank_1/set"
availability_topic: "fhem/connection/status"
payload_available: "connected"
payload_not_available: "disconnected"
payload_on: "on"
payload_off: "off"
state_on: "on"
state_off: "off"
optimistic: false
qos: 0
retain: falseEinen MQTT-Broker hatte ich schon länger in Betrieb um Tasmota-Device steuern zu können.
Um die Verbindung zum HA herzustellen habe ich dort den MQTT-Broker aktiviert und einen Nutzer "mqtt" angelegt.
In Fhem dann einen MQTT-Client und die MQTT-Bridge.
Nun funktioniert es, dass die (bisher) beiden Switch sich sowohl in FHEM als auch in HA bedienen lassen und der Status übertragen wird.
Soweit so gut.
@Beta-User: Entsprechend deinem Hinweis zur Last in FHEM, wenn ein Server und ein Client gleichzeitig auf der FHEM-Instanz laufen, würde ich gerne die direkte Kommunikation ohne den Client umsetzen.
Kannst du mir da bitte ein paar Tipps geben wie ich das umsetzen kann?
Du schreibst:
Zitatauf der HASS-Seite ist dann der M2S als Server zu konfigurieren.
Muss ich dann in der MQTT-Config in HA unter Server den FHEM-MQTT-Server (IP/Port/Nutzer/PW) eintragen oder muss ich noch mehr machen?
Und damit nicht genug der Fragen:
Wie kann ich Daten die nur in HA verfügbar sind an FEHM übertragen?
Es geht mir also nicht nur um die Schalterstellung eines Switch, sondern um Readings die sich tatsächlich nur mit HA von einer API abrufen lassen.
Vielen Dank für die Hilfe.
Grüße
Zitat von: Knallfrosch am 24 August 2024, 12:12:31Kannst du mir da bitte ein paar Tipps geben wie ich das umsetzen kann?
Mir ist ehrlich gesagt nicht mehr klar, ob du einen oder 2 MQTT-Server (früher: Broker) im Einsatz hast.
Es reicht eigentlich einer, das kann (!) auch ein MQTT2_SERVER sein, du mußt den dann halt in HA entsprechend konfigurieren (vermutlich ist die Terminologie "exterrner Broker" oder so). Wie es genau geht, kann ich dir nicht sagen, ich nutze HA nicht...
UND: Ich würde eine ANDERE Anleitung/Vorgehensweise wählen, nämlich via attrTemplate (da wären die Topic-Strukturen geringfügig anders). Aber das hatte ich eigentlich ja schon erwähnt, dass m.E. die Anleitung "von Seite 2" veraltet ist...
Zitat von: Knallfrosch am 24 August 2024, 12:12:31Wie kann ich Daten die nur in HA verfügbar sind an FEHM übertragen?
Es geht mir also nicht nur um die Schalterstellung eines Switch, sondern um Readings die sich tatsächlich nur mit HA von einer API abrufen lassen.
Vermutlich (!) wird es dort was ähnliches geben wie die MQTT_GENERIC_BRIDGE in FHEM, evtl. reicht es, in der yaml schlicht die Topics zu nennen, auf die gepublisht werden soll...
Zitat von: Knallfrosch am 24 August 2024, 12:12:31Wie kann ich Daten die nur in HA verfügbar sind an FEHM übertragen?
Es geht mir also nicht nur um die Schalterstellung eines Switch, sondern um Readings die sich tatsächlich nur mit HA von einer API abrufen lassen.
Das geht über MQTT Statestream. Siehe dazu hier: https://www.home-assistant.io/integrations/mqtt_statestream/ (https://www.home-assistant.io/integrations/mqtt_statestream/)
Bei mir sieht das in der configuration.yaml so aus:
mqtt_statestream:
base_topic: hass
publish_attributes: true
publish_timestamps: true
include:
entities:
- media_player.webos_tv
- vacuum.deebot
- [... weitere Devices ...]EDIT: Zusätzlich muss man noch eine MQTT-Integration hinzufügen, um Home Assistant mit dem von FHEM bereitgestellten MQTT2_SERVER (also dem Broker) zu verbinden. Da dann evtl. über den "Configure"-Knopf "Enable newly added entities" ausschalten, damit Home Assistant nicht alle anderen MQTT-Geräte automatisch anlegt (keine Ahnung mehr, ob es das tatsächlich machen würde, habs jedenfalls grade nur gesehen, dass ich das damals ausgeschaltet habe).
Siehe dazu hier: https://www.home-assistant.io/integrations/mqtt/#broker-configuration (https://www.home-assistant.io/integrations/mqtt/#broker-configuration)
Dann einfach mit Programmen wie MQTT Explorer o.ä. dem MQTT Traffic lauschen und schauen, was da gesendet wird. Daraus dann in FHEM ein MQTT2_DEVICE bauen.
Und das ist jetzt vielleicht offtopic, weil nicht MQTT_GENERIC_BRIDGE, aber vielleicht hilfts ja jemandem:
Ich benutze Home Assistant nicht als Frontend und habe nur sehr wenige Geräte, die ich darüber anbinde. Deshalb war mir das mit MQTT_GENERIC_BRIDGE zu aufwändig und ich nutze nur eine Kombination aus MQTT Statestream und einer Automation pro Device, die die Befehle, die ich von FHEM aus über MQTT sende, in Home Assistant umsetzt.
z.B. für den oben erwähnten Saugroboter die Automation in Home Assistant:
alias: Deebot command via FHEM
description: ""
trigger:
- platform: mqtt
topic: hass/deebot/cmd
condition: []
action:
- if:
- condition: template
value_template: "{{ trigger.payload == 'auto' }}"
then:
- data: {}
target:
entity_id: vacuum.deebot
action: vacuum.start
- if:
- condition: template
value_template: "{{ trigger.payload == 'pause' }}"
then:
- data: {}
target:
entity_id: vacuum.deebot
action: vacuum.pause
- if:
- condition: template
value_template: "{{ trigger.payload == 'stop' }}"
then:
- data: {}
target:
entity_id: vacuum.deebot
action: vacuum.stop
- if:
- condition: template
value_template: "{{ trigger.payload == 'stop_return' }}"
then:
- data: {}
target:
entity_id: vacuum.deebot
action: vacuum.return_to_base
- if:
- condition: not
conditions:
- condition: template
value_template: "{{ trigger.payload is search (\"auto|pause|stop\") }}"
then:
- target:
entity_id: vacuum.deebot
data:
command: spot_area
params:
rooms: "{{trigger.payload}}"
action: vacuum.send_command
mode: single
Das zugehörige Device in FHEM sieht so aus:
defmod deebot MQTT2_DEVICE deebot
attr deebot alias Deebot T9
attr deebot devicetopic hass/vacuum/deebot
attr deebot icon vacuum_top
attr deebot readingList $DEVICETOPIC/state:.* state\
$DEVICETOPIC/battery_level:.* battery\
$DEVICETOPIC/last_error:.* error\
$DEVICETOPIC/rooms:.* rooms
attr deebot setList auto:noArg hass/deebot/cmd auto\
only_k:noArg hass/deebot/cmd 3\
only_f:noArg hass/deebot/cmd 2\
only_kf:noArg hass/deebot/cmd 3,2\
pause:noArg hass/deebot/cmd pause\
resume:noArg hass/deebot/cmd auto\
stop_return:noArg hass/deebot/cmd stop_return
attr deebot webCmd auto:pause:resume:stop_return
Hallo,
sorry für die späte Rückmeldung.
Ich habe keine Benachrichtigung über neue Beiträge erhalten.
Danke für die Beiträge
Ich schaue mir das mal in den nächsten Tagen in Ruhe nochmal an und melde mich dann wieder.
Grüße
Hallo,
vielen Dank, die Erklärung und Schnipsel haben mir sehr weitergeholfen und ich konnte das ganze nun umsetzen.
Ich musste zwar kämpfen, da ich HA nur aus der Not heraus nutze und in FHEM auch kein Crack bin, aber ich habe es geschafft.
Ich bekomme jetzt die benötigten Werte von HA in FHEM angezeigt und kann dort damit weiterarbeiten.
Vielen Dank nochmal.
Grüße
ich möchte mich hier noch einmal nach längerer Abwesenheit melden, hier eine Anleitung wie es bei mir zwischen FHEM und HomeAssistant funktioniert.
Es werden Sensoren abgefragt, Numbers übertragen etc:
- Dummy in FHEM anlegen:
define d_fanstageday dummy
userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
room HASS
mqttSubscribe state:stopic={"$base/set"}
mqttForward all
Der Dummy kann dann zB mit Werten 0-3 beschrieben werden, statt nur "on" und "off" -> das scheint ja bei einigen ein Problem zu sein bzgl der Umsetzung.
- notify in FHEM anlegen (das Notify schreibt dann in die entsprechenden Geräte, bei mir die Wärmepumpe)
define n_fanstageday notify a b
DEF d_fanstageday:.* set Mythz p07FanStageDay $EVENT (hier ist Mythz meine Wärmepumpe und ich möchte die FanStage bearbeiten, $EVENT ist der Wert aus dem Dummy
- Number in HA anlegen:
- name: Mythzp07FanStageDay
unique_id: fhem_mythz_p07FanStageDay
state_topic: "fhem/Mythz/p07FanStageDay"
command_topic: "fhem/d_fanstageday/set"
mode: box
min: 0
max: 3
step: 1
availability_topic: "fhem/connection/status"
payload_available: "connected"
payload_not_available: "disconnected"
wichtig: hier ist der state_topic direkt aus der Wärmepumpe, der command aber der Dummy --> somit wird auch wirklich zurückgegeben ob die Wärmepumpe umschaltet!
für einen Sensor würde es zB so aussehen (hier brauche ich keinen Switch / Number, sondern nur den Wert von der WP):
- name: MythzTempWarmwasser
unique_id: fhem_mythz_temp_warmwasser
state_topic: "fhem/Mythz/TempWarmwasser"
unit_of_measurement: "°C"
Zitat von: CaptainSlow am 22 November 2024, 14:23:45- Dummy in FHEM anlegen:
Der dummy ist imo in dem Zusammenhang komplett überflüssig! Genau wie das notify.... Mach' das doch direkt.
stimme ich dir zu! allerdings konnte ich auf die Art nur HA Sensoren einbinden, aber alle Stellgrößen (wie Lüfterstufen, Heizmodus usw) konnte ich nicht mit einer direkten Verbindung zum Laufen bekommen.. daher der Umweg.
Im MQTT Explorer wird mir sonst einfach ein zusätzlicher "Set"-Wert angelegt, aber nicht weiter verarbeitet (das gleiche passiert übrigens auch bei den Dummys, hier wird der "Set"-Wert dann aber innerhalb FHEM weiter gegeben durch das Notify.
Wenn du hier ein Beispiel veröffentlichen kannst wie es bei dir mit Direktverbindung funktioniert wäre ich dir dankbar :)
Meine Struktur ist zB innerhalb der MQTT fhem/Mythz/Parameter
Zitat von: CaptainSlow am 25 November 2024, 08:39:31Wenn du hier ein Beispiel veröffentlichen kannst wie es bei dir mit Direktverbindung funktioniert wäre ich dir dankbar :)
Prinzipiell sehe ich keinerlei Problem mit einer "Direktverbindung", du musst halt statt "state" mit dem Readingnamen arbeiten, den du verändern willst (hier also z.B. "p07FanStageDay"). Das ist m.E. doch auch nichts anderes als "pct" bei einem Rollladen, der z.B. hier zu finden wäre:
https://forum.fhem.de/index.php?msg=1124879
Hallo zusammen,
habe erfolgreich den "demoswitch" aus dem zweiten Beitrag eingerichtet.
Nun wollte ich gerne ein Zigbee Gerät aus HASS zurück nach FHEM übertragen.
Im "MQTT2_zigbee_pi" MQTT2_DEVICE wird mir auch das Gerät aus dem Zigbee2MQTT im Log angezeigt wenn ich es schalte aber wohl nicht in FHEM automatisch angelegt!
log_message aus MQTT2_zigbee_pi
z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/00_Buero_Nachtlicht', payload '{"brightness":38,"color_mode":"color_temp","color_options":null,"color_temp":454,"color_temp_startup":454,"last_seen":"2024-12-06T09:46:13+01:00","linkquality":168,"power_on_behavior":null,"state":"OFF","update":{"installed_version":587757105,"latest_version":587757105,"state":"idle"},"update_available":null}'
2024-12-06 09:46:13
Ich finde es einfach nicht.
Hier das "list" des zigbee_pi Gerrätes
Internals:
CID zigbee_pi
DEF zigbee_pi
FUUID 6751f50b-f33f-61e0-7075-8982cf2deb9b3d4d
IODev ha_MQTT2
LASTInputDev ha_MQTT2
MSGCNT 84
NAME MQTT2_zigbee_pi
NR 820
STATE {"state":"online"}
TYPE MQTT2_DEVICE
eventCount 83
ha_MQTT2_MSGCNT 84
ha_MQTT2_TIME 2024-12-06 09:47:14
.DT:
DEVICETOPIC zigbee2mqtt
.attraggr:
.attrminint:
OLDREADINGS:
READINGS:
2024-12-06 08:28:57 attrTemplateVersion 20240628
2024-12-06 09:31:47 devices [{"disabled":false,"endpoints":{"1":{"bindings":[],"clusters":{"input":["genBasic","genIdentify","genOnOff","genLevelCtrl","genTime","genOta","lightingColorCtrl"],"output":["genBasic","genIdentify","genGroups","genScenes","genOnOff","genLevelCtrl","genPollCtrl","lightingColorCtrl","msIlluminanceMeasurement","msTemperatureMeasurement","msRelativeHumidity","msOccupancySensing","ssIasZone","seMetering","haMeterIdentification","haApplianceStatistics","haElectricalMeasurement","touchlink"]},"configured_reportings":[],"scenes":[]},"242":{"bindings":[],"clusters":{"input":["greenPower"],"output":["greenPower"]},"configured_reportings":[],"scenes":[]}},"friendly_name":"Coordinator","ieee_address":"0xe0798dfffe99d833","interview_completed":true,"interviewing":false,"network_address":0,"supported":true,"type":"Coordinator"},{"date_code":"20190312","definition":{"description":"TRADFRI bulb E12/E14/E17, white spectrum, candle, opal, 450/470/440 lm","exposes":[{"features":[{"access":7,"description":"On/off state of this light","label":"State","name":"state","property":"state","type":"binary","value_off":"OFF","value_on":"ON","value_toggle":"TOGGLE"},{"access":7,"description":"Brightness of this light","label":"Brightness","name":"brightness","property":"brightness","type":"numeric","value_max":254,"value_min":0},{"access":7,"description":"Color temperature of this light","label":"Color temp","name":"color_temp","presets":[{"description":"Coolest temperature supported","name":"coolest","value":250},{"description":"Cool temperature (250 mireds / 4000 Kelvin)","name":"cool","value":250},{"description":"Neutral temperature (370 mireds / 2700 Kelvin)","name":"neutral","value":370},{"description":"Warm temperature (454 mireds / 2200 Kelvin)","name":"warm","value":454},{"description":"Warmest temperature supported","name":"warmest","value":454}],"property":"color_temp","type":"numeric","unit":"mired","value_max":454,"value_min":250},{"access":7,"description":"Color temperature after cold power on of this light","label":"Color temp startup","name":"color_temp_startup","presets":[{"description":"Coolest temperature supported","name":"coolest","value":250},{"description":"Cool temperature (250 mireds / 4000 Kelvin)","name":"cool","value":250},{"description":"Neutral temperature (370 mireds / 2700 Kelvin)","name":"neutral","value":370},{"description":"Warm temperature (454 mireds / 2200 Kelvin)","name":"warm","value":454},{"description":"Warmest temperature supported","name":"warmest","value":454},{"description":"Restore previous color_temp on cold power on","name":"previous","value":65535}],"property":"color_temp_startup","type":"numeric","unit":"mired","value_max":454,"value_min":250},{"access":7,"description":"Configure genLevelCtrl","features":[{"access":7,"description":"this setting can affect the \"on_level\", \"current_level_startup\" or \"brightness\" setting","label":"Execute if off","name":"execute_if_off","property":"execute_if_off","type":"binary","value_off":false,"value_on":true},{"access":7,"description":"Defines the desired startup level for a device when it is supplied with power","label":"Current level startup","name":"current_level_startup","presets":[{"description":"Use minimum permitted value","name":"minimum","value":"minimum"},{"description":"Use previous value","name":"previous","value":"previous"}],"property":"current_level_startup","type":"numeric","value_max":254,"value_min":1}],"label":"Level config","name":"level_config","property":"level_config","type":"composite"}],"type":"light"},{"access":2,"description":"Triggers an effect on the light (e.g. make light blink for a few seconds)","label":"Effect","name":"effect","property":"effect","type":"enum","values":["blink","breathe","okay","channel_change","finish_effect","stop_effect"]},{"access":7,"category":"config","description":"Controls the behavior when the device is powered on after power loss","label":"Power-on behavior","name":"power_on_behavior","property":"power_on_behavior","type":"enum","values":["off","on","toggle","previous"]},{"access":7,"category":"config","description":"Advanced color behavior","features":[{"access":2,"description":"Controls whether color and color temperature can be set while light is off","label":"Execute if off","name":"execute_if_off","property":"execute_if_off","type":"binary","value_off":false,"value_on":true}],"label":"Color options","name":"color_options","property":"color_options","type":"composite"},{"access":2,"category":"config","description":"Initiate device identification","label":"Identify","name":"identify","property":"identify","type":"enum","values":["identify"]},{"access":1,"category":"diagnostic","description":"Link quality (signal strength)","label":"Linkquality","name":"linkquality","property":"linkquality","type":"numeric","unit":"lqi","value_max":255,"value_min":0}],"model":"LED1835C6","options":[{"access":2,"description":"Controls the transition time (in seconds) of on/off, brightness, color temperature (if applicable) and color (if applicable) changes. Defaults to `0` (no transition).","label":"Transition","name":"transition","property":"transition","type":"numeric","value_min":0},{"access":2,"description":"When enabled colors will be synced, e.g. if the light supports both color x/y and color temperature a conversion from color x/y to color temperature will be done when setting the x/y color (default true).","label":"Color sync","name":"color_sync","property":"color_sync","type":"binary","value_off":false,"value_on":true},{"access":2,"description":"Sets the duration of the identification procedure in seconds (i.e., how long the device would flash).The value ranges from 1 to 30 seconds (default: 3).","label":"Identify timeout","name":"identify_timeout","property":"identify_timeout","type":"numeric","value_max":30,"value_min":1},{"access":2,"description":"State actions will also be published as 'action' when true (default false).","label":"State action","name":"state_action","property":"state_action","type":"binary","value_off":false,"value_on":true}],"supports_ota":true,"vendor":"IKEA"},"disabled":false,"endpoints":{"1":{"bindings":[],"clusters":{"input":["genBasic","genIdentify","genGroups","genScenes","genOnOff","genLevelCtrl","lightingColorCtrl","touchlink","manuSpecificIkeaUnknown"],"output":["genScenes","genOta","genPollCtrl","touchlink"]},"configured_reportings":[],"scenes":[]},"242":{"bindings":[],"clusters":{"input":[],"output":["greenPower"]},"configured_reportings":[],"scenes":[]}},"friendly_name":"00_Buero_Nachtlicht","ieee_address":"0x680ae2fffe550cb6","interview_completed":true,"interviewing":false,"manufacturer":"IKEA of Sweden","model_id":"TRADFRI bulb E14 WS 470lm","network_address":11678,"power_source":"Mains (single phase)","software_build_id":"2.3.087","supported":true,"type":"Router"}]
2024-12-06 09:15:15 extensions []
2024-12-06 09:15:15 groups []
2024-12-06 09:31:47 info {"commit":"unknown","config":{"advanced":{"availability_blacklist":[],"availability_blocklist":[],"availability_passlist":[],"availability_whitelist":[],"cache_state":true,"cache_state_persistent":true,"cache_state_send_on_startup":true,"channel":11,"elapsed":false,"ext_pan_id":[140,181,44,147,145,184,12,139],"homeassistant_legacy_entity_attributes":false,"last_seen":"ISO_8601_local","legacy_api":false,"legacy_availability_payload":false,"log_debug_namespace_ignore":"","log_debug_to_mqtt_frontend":false,"log_directory":"/config/zigbee2mqtt/log/%TIMESTAMP%","log_file":"log.log","log_level":"info","log_namespaced_levels":{},"log_output":["console","file"],"log_rotation":true,"log_symlink_current":false,"log_syslog":{},"output":"json","pan_id":44494,"report":false,"soft_reset_timeout":0,"timestamp_format":"YYYY-MM-DD HH:mm:ss"},"availability":{},"blocklist":[],"device_options":{"legacy":false},"devices":{"0x680ae2fffe550cb6":{"friendly_name":"00_Buero_Nachtlicht"}},"external_converters":[],"frontend":{"base_url":"/","port":8099},"groups":{},"homeassistant":{"discovery_topic":"homeassistant","experimental_event_entities":false,"legacy_entity_attributes":false,"legacy_triggers":true,"status_topic":"hass/status"},"map_options":{"graphviz":{"colors":{"fill":{"coordinator":"#e04e5d","enddevice":"#fff8ce","router":"#4ea3e0"},"font":{"coordinator":"#ffffff","enddevice":"#000000","router":"#ffffff"},"line":{"active":"#009900","inactive":"#994444"}}}},"mqtt":{"base_topic":"zigbee2mqtt","force_disable_retain":false,"include_device_information":false,"server":"mqtt://192.168.178.125:1883","user":"mqttadmin"},"ota":{"disable_automatic_update_check":false,"update_check_interval":1440},"passlist":[],"permit_join":false,"serial":{"adapter":"ember","disable_led":false,"port":"/dev/ttyUSB0"}},"config_schema":{"definitions":{"device":{"properties":{"debounce":{"description":"Debounces messages of this device","title":"Debounce","type":"number"},"debounce_ignore":{"description":"Protects unique payload values of specified payload properties from overriding within debounce time","examples":["action"],"items":{"type":"string"},"title":"Ignore debounce","type":"array"},"disabled":{"description":"Disables the device (excludes device from network scans, availability and group state updates)","requiresRestart":true,"title":"Disabled","type":"boolean"},"filtered_attributes":{"description":"Filter attributes with regex from published payload.","examples":["^temperature$","^battery$","^action$"],"items":{"type":"string"},"title":"Filtered publish attributes","type":"array"},"filtered_cache":{"description":"Filter attributes with regex from being added to the cache, this prevents the attribute from being in the published payload when the value didn't change.","examples":["^input_actions$"],"items":{"type":"string"},"title":"Filtered attributes from cache","type":"array"},"filtered_optimistic":{"description":"Filter attributes with regex from optimistic publish payload when calling /set. (This has no effect if optimistic is set to false).","examples":["^color_(mode|temp)$","color"],"items":{"type":"string"},"title":"Filtered optimistic attributes","type":"array"},"friendly_name":{"description":"Used in the MQTT topic of a device. By default this is the device ID","readOnly":true,"title":"Friendly name","type":"string"},"homeassistant":{"properties":{"name":{"description":"Name of the device in Home Assistant","title":"Home Assistant name","type":"string"}},"title":"Home Assistant","type":["object","null"]},"icon":{"description":"The user-defined device icon for the frontend. It can be a full URL link to an image (e.g. https://SOME.SITE/MODEL123.jpg) (you cannot use a path to a local file) or base64 encoded data URL (e.g. image/svg+xml;base64,PHN2ZyB3aW....R0aD)","title":"Icon","type":"string"},"optimistic":{"default":true,"description":"Publish optimistic state after set","title":"Optimistic","type":"boolean"},"qos":{"description":"QoS level for MQTT messages of this device","title":"QoS","type":"number"},"retain":{"description":"Retain MQTT messages of this device","title":"Retain","type":"boolean"},"retention":{"description":"Sets the MQTT Message Expiry in seconds, Make sure to set mqtt.version to 5","title":"Retention","type":"number"}},"required":["friendly_name"],"type":"object"},"group":{"properties":{"devices":{"items":{"type":"string"},"type":"array"},"filtered_attributes":{"items":{"type":"string"},"type":"array"},"friendly_name":{"type":"string"},"off_state":{"default":"auto","description":"Control when to publish state OFF or CLOSE for a group. 'all_members_off': only publish state OFF/CLOSE when all group members are in state OFF/CLOSE, 'last_member_state': publish state OFF whenever one of its members changes to OFF","enum":["all_members_off","last_member_state"],"requiresRestart":true,"title":"Group off state","type":["string"]},"optimistic":{"type":"boolean"},"qos":{"type":"number"},"retain":{"type":"boolean"}},"required":["friendly_name"],"type":"object"}},"properties":{"advanced":{"properties":{"adapter_concurrent":{"description":"Adapter concurrency (e.g. 2 for CC2531 or 16 for CC26X2R1) (default: null, uses recommended value)","maximum":64,"minimum":1,"requiresRestart":true,"title":"Adapter concurrency","type":["number","null"]},"adapter_delay":{"description":"Adapter delay","maximum":1000,"minimum":0,"requiresRestart":true,"title":"Adapter delay","type":["number","null"]},"cache_state":{"default":true,"description":"MQTT message payload will contain all attributes, not only changed ones. Has to be true when integrating via Home Assistant","title":"Cache state","type":"boolean"},"cache_state_persistent":{"default":true,"description":"Persist cached state, only used when cache_state: true","title":"Persist cache state","type":"boolean"},"cache_state_send_on_startup":{"default":true,"description":"Send cached state on startup, only used when cache_state: true","title":"Send cached state on startup","type":"boolean"},"channel":{"default":11,"description":"Zigbee channel, changing might require re-pairing some devices! (Note: use a ZLL channel: 11, 15, 20, or 25 to avoid problems)","examples":[15,20,25],"maximum":26,"minimum":11,"requiresRestart":true,"title":"ZigBee channel","type":"number"},"elapsed":{"default":false,"description":"Add an elapsed attribute to MQTT messages, contains milliseconds since the previous msg","title":"Elapsed","type":"boolean"},"ext_pan_id":{"description":"Zigbee extended pan ID, changing requires re-pairing all devices!","oneOf":[{"title":"Extended pan ID (string)","type":"string"},{"items":{"type":"number"},"title":"Extended pan ID (array)","type":"array"}],"requiresRestart":true,"title":"Ext Pan ID"},"last_seen":{"default":"disable","description":"Add a last_seen attribute to MQTT messages, contains date/time of last Zigbee message","enum":["disable","ISO_8601","ISO_8601_local","epoch"],"title":"Last seen","type":"string"},"legacy_api":{"default":true,"description":"Disables the legacy api (false = disable)","requiresRestart":true,"title":"Legacy API","type":"boolean"},"legacy_availability_payload":{"default":true,"description":"Payload to be used for device availability and bridge/state topics. true = text, false = JSON","requiresRestart":true,"title":"Legacy availability payload","type":"boolean"},"log_debug_namespace_ignore":{"default":"","description":"Do not log these namespaces (regex-based) for debug level","examples":["^zhc:legacy:fz:(tuya|moes)","^zhc:legacy:fz:(tuya|moes)|^zh:ember:uart:|^zh:controller"],"title":"Log debug namespace ignore","type":"string"},"log_debug_to_mqtt_frontend":{"default":false,"description":"Log debug level to MQTT and frontend (may decrease overall performance)","requiresRestart":true,"title":"Log debug to MQTT and frontend","type":"boolean"},"log_directory":{"description":"Location of log directory","examples":["data/log/%TIMESTAMP%"],"requiresRestart":true,"title":"Log directory","type":"string"},"log_file":{"default":"log.txt","description":"Log file name, can also contain timestamp","examples":["zigbee2mqtt_%TIMESTAMP%.log"],"requiresRestart":true,"title":"Log file","type":"string"},"log_level":{"default":"info","description":"Logging level","enum":["error","warning","info","debug","warn"],"title":"Log level","type":"string"},"log_namespaced_levels":{"additionalProperties":{"enum":["error","warning","info","debug"],"type":"string"},"default":{},"description":"Set individual log levels for certain namespaces","examples":[{"z2m:mqtt":"warning"},{"zh:ember:uart:ash":"info"}],"propertyNames":{"pattern":"^(z2m|zhc|zh)(:[a-z0-9]{1,})*$"},"title":"Log Namespaced Levels","type":"object"},"log_output":{"description":"Output location of the log, leave empty to suppress logging","items":{"enum":["console","file","syslog"],"type":"string"},"requiresRestart":true,"title":"Log output","type":"array"},"log_rotation":{"default":true,"description":"Log rotation","requiresRestart":true,"title":"Log rotation","type":"boolean"},"log_symlink_current":{"default":false,"description":"Create symlink to current logs in the log directory","requiresRestart":true,"title":"Log symlink current","type":"boolean"},"log_syslog":{"oneOf":[{"title":"syslog (disabled)","type":"null"},{"properties":{"app_name":{"default":"Zigbee2MQTT","description":"The name of the application (Default: Zigbee2MQTT).","title":"Localhost","type":"string"},"eol":{"default":"/n","description":"The end of line character to be added to the end of the message (Default: Message without modifications).","title":"eol","type":"string"},"host":{"default":"localhost","description":"The host running syslogd, defaults to localhost.","title":"Host","type":"string"},"localhost":{"default":"localhost","description":"Host to indicate that log messages are coming from (Default: localhost).","title":"Localhost","type":"string"},"path":{"default":"/dev/log","description":"The path to the syslog dgram socket (i.e. /dev/log or /var/run/syslog for OS X).","examples":["/var/run/syslog"],"title":"Path","type":"string"},"pid":{"default":"process.pid","description":"PID of the process that log messages are coming from (Default process.pid).","title":"PID","type":"string"},"port":{"default":514,"description":"The port on the host that syslog is running on, defaults to syslogd's default port.","title":"Port","type":"number"},"protocol":{"default":"udp4","description":"The network protocol to log over (e.g. tcp4, udp4, tls4, unix, unix-connect, etc).","examples":["udp4","tls4","unix","unix-connect"],"title":"Protocol","type":"string"},"type":{"default":"5424","description":"The type of the syslog protocol to use (Default: BSD, also valid: 5424).","title":"Type","type":"string"}},"title":"syslog (enabled)","type":"object"}],"requiresRestart":true},"network_key":{"description":"Network encryption key, changing requires re-pairing all devices!","oneOf":[{"title":"Network key(string)","type":"string"},{"items":{"type":"number"},"title":"Network key(array)","type":"array"}],"requiresRestart":true,"title":"Network key"},"output":{"description":"Examples when 'state' of a device is published json: topic: 'zigbee2mqtt/my_bulb' payload '{\"state\": \"ON\"}' attribute: topic 'zigbee2mqtt/my_bulb/state' payload 'ON' attribute_and_json: both json and attribute (see above)","enum":["attribute_and_json","attribute","json"],"title":"MQTT output type","type":"string"},"pan_id":{"description":"ZigBee pan ID, changing requires re-pairing all devices!","oneOf":[{"title":"Pan ID (string)","type":"string"},{"title":"Pan ID (number)","type":"number"}],"requiresRestart":true,"title":"Pan ID"},"timestamp_format":{"description":"Log timestamp format","examples":["YYYY-MM-DD HH:mm:ss"],"requiresRestart":true,"title":"Timestamp format","type":"string"},"transmit_power":{"description":"Transmit power of adapter, only available for Z-Stack (CC253*/CC2652/CC1352) adapters, CC2652 = 5dbm, CC1352 max is = 20dbm (5dbm default)","maximum":127,"minimum":-128,"requiresRestart":true,"title":"Transmit power","type":["number","null"]}},"title":"Advanced","type":"object"},"availability":{"description":"Checks whether devices are online/offline","oneOf":[{"title":"Availability (simple)","type":"boolean"},{"properties":{"active":{"description":"Options for active devices (routers/mains powered)","properties":{"timeout":{"default":10,"description":"Time after which an active device will be marked as offline in minutes","requiresRestart":true,"title":"Timeout","type":"number"}},"requiresRestart":true,"title":"Active","type":"object"},"passive":{"description":"Options for passive devices (mostly battery powered)","properties":{"timeout":{"default":1500,"description":"Time after which an passive device will be marked as offline in minutes","requiresRestart":true,"title":"Timeout","type":"number"}},"requiresRestart":true,"title":"Passive","type":"object"}},"title":"Availability (advanced)","type":"object"}],"requiresRestart":true,"title":"Availability"},"ban":{"items":{"type":"string"},"readOnly":true,"requiresRestart":true,"title":"Ban (deprecated, use blocklist)","type":"array"},"blocklist":{"description":"Block devices from the network (by ieeeAddr)","items":{"type":"string"},"requiresRestart":true,"title":"Blocklist","type":"array"},"device_options":{"title":"Options that are applied to all devices","type":"object"},"devices":{"patternProperties":{"^.*$":{"$ref":"#/definitions/device"}},"propertyNames":{"pattern":"^0x[\\d\\w]{16}$"},"type":"object"},"external_converters":{"description":"You can define external converters to e.g. add support for a DiY device","examples":["DIYRuZ_FreePad.js"],"items":{"type":"string"},"requiresRestart":true,"title":"External converters","type":"array"},"frontend":{"oneOf":[{"title":"Frontend (simple)","type":"boolean"},{"properties":{"auth_token":{"description":"Enables authentication, disabled by default","requiresRestart":true,"title":"Auth token","type":["string","null"]},"base_url":{"default":"/","description":"Base URL for the frontend. If hosted under a subpath, e.g. 'http://localhost:8080/z2m', set this to '/z2m'","pattern":"^\\/.*","requiresRestart":true,"title":"Base URL","type":"string"},"host":{"description":"Frontend binding host. Binds to a unix socket when an absolute path is given instead.","examples":["127.0.0.1","::1","/run/zigbee2mqtt/zigbee2mqtt.sock"],"requiresRestart":true,"title":"Bind host","type":["string","null"]},"port":{"default":8080,"description":"Frontend binding port. Ignored when using a unix domain socket","requiresRestart":true,"title":"Port","type":"number"},"ssl_cert":{"description":"SSL Certificate file path for exposing HTTPS. The sibling property 'ssl_key' must be set for HTTPS to be activated.","requiresRestart":true,"title":"Certificate file path","type":["string","null"]},"ssl_key":{"description":"SSL key file path for exposing HTTPS. The sibling property 'ssl_cert' must be set for HTTPS to be activated.","requiresRestart":true,"title":"key file path","type":["string","null"]},"url":{"description":"URL on which the frontend can be reached, currently only used for the Home Assistant device configuration page","requiresRestart":true,"title":"URL","type":["string","null"]}},"title":"Frontend (advanced)","type":"object"}],"requiresRestart":true,"title":"Frontend"},"groups":{"patternProperties":{"^.*$":{"$ref":"#/definitions/group"}},"propertyNames":{"pattern":"^[\\w].*$"},"type":"object"},"homeassistant":{"default":false,"description":"Home Assistant integration (MQTT discovery)","oneOf":[{"title":"Home Assistant (simple)","type":"boolean"},{"properties":{"discovery_topic":{"description":"Home Assistant discovery topic","examples":["homeassistant"],"requiresRestart":true,"title":"Homeassistant discovery topic","type":"string"},"experimental_event_entities":{"default":false,"description":"Home Assistant experimental event entities, when enabled Zigbee2MQTT will add event entities for exposed actions. The events and attributes are currently deemed experimental and subject to change.","title":"Home Assistant experimental event entities","type":"boolean"},"legacy_entity_attributes":{"default":true,"description":"Home Assistant legacy entity attributes, when enabled Zigbee2MQTT will add state attributes to each entity, additional to the separate entities and devices it already creates","title":"Home Assistant legacy entity attributes","type":"boolean"},"legacy_triggers":{"default":true,"description":"Home Assistant legacy triggers, when enabled Zigbee2mqt will send an empty 'action' or 'click' after one has been send. A 'sensor_action' and 'sensor_click' will be discoverd","title":"Home Assistant legacy triggers","type":"boolean"},"status_topic":{"description":"Home Assistant status topic","examples":["homeassistant/status"],"requiresRestart":true,"title":"Home Assistant status topic","type":"string"}},"title":"Home Assistant (advanced)","type":"object"}],"requiresRestart":true,"title":"Home Assistant integration"},"map_options":{"properties":{"graphviz":{"properties":{"colors":{"properties":{"fill":{"properties":{"coordinator":{"type":"string"},"enddevice":{"type":"string"},"router":{"type":"string"}},"type":"object"},"font":{"properties":{"coordinator":{"type":"string"},"enddevice":{"type":"string"},"router":{"type":"string"}},"type":"object"},"line":{"properties":{"active":{"type":"string"},"inactive":{"type":"string"}},"type":"object"}},"type":"object"}},"type":"object"}},"title":"Networkmap","type":"object"},"mqtt":{"properties":{"base_topic":{"default":"zigbee2mqtt","description":"MQTT base topic for Zigbee2MQTT MQTT messages","examples":["zigbee2mqtt"],"requiresRestart":true,"title":"Base topic","type":"string"},"ca":{"description":"Absolute path to SSL/TLS certificate of CA used to sign server and client certificates","examples":["/etc/ssl/mqtt-ca.crt"],"requiresRestart":true,"title":"Certificate authority","type":"string"},"cert":{"description":"Absolute path to SSL/TLS certificate for client-authentication","examples":["/etc/ssl/mqtt-client.crt"],"requiresRestart":true,"title":"SSL/TLS certificate","type":"string"},"client_id":{"description":"MQTT client ID","examples":["MY_CLIENT_ID"],"requiresRestart":true,"title":"Client ID","type":"string"},"force_disable_retain":{"default":false,"description":"Disable retain for all send messages. ONLY enable if you MQTT broker doesn't support retained message (e.g. AWS IoT core, Azure IoT Hub, Google Cloud IoT core, IBM Watson IoT Platform). Enabling will break the Home Assistant integration","requiresRestart":true,"title":"Force disable retain","type":"boolean"},"include_device_information":{"default":false,"description":"Include device information to mqtt messages","title":"Include device information","type":"boolean"},"keepalive":{"default":60,"description":"MQTT keepalive in second","requiresRestart":true,"title":"Keepalive","type":"number"},"key":{"description":"Absolute path to SSL/TLS key for client-authentication","examples":["/etc/ssl/mqtt-client.key"],"requiresRestart":true,"title":"SSL/TLS key","type":"string"},"password":{"description":"MQTT server authentication password","examples":["ILOVEPELMENI"],"requiresRestart":true,"title":"Password","type":"string"},"reject_unauthorized":{"default":true,"description":"Disable self-signed SSL certificate","requiresRestart":true,"title":"Reject unauthorized","type":"boolean"},"server":{"description":"MQTT server URL (use mqtts:// for SSL/TLS connection)","examples":["mqtt://localhost:1883"],"requiresRestart":true,"title":"MQTT server","type":"string"},"user":{"description":"MQTT server authentication user","examples":["johnnysilverhand"],"requiresRestart":true,"title":"User","type":"string"},"version":{"default":4,"description":"MQTT protocol version","examples":[5],"requiresRestart":true,"title":"Version","type":["number","null"]}},"required":["server"],"title":"MQTT","type":"object"},"ota":{"properties":{"disable_automatic_update_check":{"default":false,"description":"Zigbee devices may request a firmware update, and do so frequently, causing Zigbee2MQTT to reach out to third party servers. If you disable these device initiated checks, you can still initiate a firmware update check manually.","title":"Disable automatic update check","type":"boolean"},"ikea_ota_use_test_url":{"default":false,"description":"Use IKEA TRADFRI OTA test server, see OTA updates documentation","requiresRestart":true,"title":"IKEA TRADFRI OTA use test url","type":"boolean"},"update_check_interval":{"default":1440,"description":"Your device may request a check for a new firmware update. This value determines how frequently third party servers may actually be contacted to look for firmware updates. The value is set in minutes, and the default is 1 day.","title":"Update check interval","type":"number"},"zigbee_ota_override_index_location":{"description":"Location of override OTA index file","examples":["index.json"],"requiresRestart":true,"title":"OTA index override file name","type":["string","null"]}},"title":"OTA updates","type":"object"},"passlist":{"description":"Allow only certain devices to join the network (by ieeeAddr). Note that all devices not on the passlist will be removed from the network!","items":{"type":"string"},"requiresRestart":true,"title":"Passlist","type":"array"},"permit_join":{"default":false,"description":"Allow new devices to join (re-applied at restart)","title":"Permit join","type":"boolean"},"serial":{"properties":{"adapter":{"default":"auto","description":"Adapter type, not needed unless you are experiencing problems","enum":["deconz","zstack","zigate","ezsp","auto","ember","zboss"],"requiresRestart":true,"title":"Adapter","type":["string"]},"baudrate":{"description":"Baud rate speed for serial port, this can be anything firmware support but default is 115200 for Z-Stack and EZSP, 38400 for Deconz, however note that some EZSP firmware need 57600","examples":[38400,57600,115200],"requiresRestart":true,"title":"Baudrate","type":"number"},"disable_led":{"default":false,"description":"Disable LED of the adapter if supported","requiresRestart":true,"title":"Disable led","type":"boolean"},"port":{"description":"Location of the adapter. To autodetect the port, set null","examples":["/dev/ttyACM0"],"requiresRestart":true,"title":"Port","type":["string","null"]},"rtscts":{"description":"RTS / CTS Hardware Flow Control for serial port","requiresRestart":true,"title":"RTS / CTS","type":"boolean"}},"title":"Serial","type":"object"},"whitelist":{"items":{"type":"string"},"readOnly":true,"requiresRestart":true,"title":"Whitelist (deprecated, use passlist)","type":"array"}},"required":["mqtt"],"type":"object"},"coordinator":{"ieee_address":"0xe0798dfffe99d833","meta":{"build":0,"ezsp":13,"major":7,"minor":4,"patch":4,"revision":"7.4.4 [GA]","special":0,"type":170},"type":"EmberZNet"},"log_level":"info","network":{"channel":11,"extended_pan_id":10139059148411113000,"pan_id":44494},"permit_join":false,"restart_required":false,"version":"1.42.0","zigbee_herdsman":{"version":"2.1.9"},"zigbee_herdsman_converters":{"version":"20.58.0"}}
2024-12-06 09:47:14 log_level info
2024-12-06 09:47:14 log_message z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/00_Buero_Nachtlicht', payload '{"brightness":38,"color_mode":"color_temp","color_options":null,"color_temp":454,"color_temp_startup":454,"last_seen":"2024-12-06T09:47:14+01:00","linkquality":168,"power_on_behavior":null,"state":"ON","update":{"installed_version":587757105,"latest_version":587757105,"state":"idle"},"update_available":null}'
2024-12-06 09:15:14 state {"state":"online"}
Attributes:
IODev ha_MQTT2
bridgeRegexp zigbee2mqtt/((?!bridge)[A-Za-z0-9._]+)/?.*:.* "zigbee_$1"
comment To check for new updates of the deamon software, you might want to use a separate HTTPMOD device. See HTTPMOD template zigbee2mqtt_daemon_updates for further details.
devicetopic zigbee2mqtt
getList networkmap_raw:noArg raw $DEVICETOPIC/bridge/request/networkmap raw
networkmap_graphviz:noArg graphviz $DEVICETOPIC/bridge/request/networkmap graphviz
icon mqtt
model zigbee2mqtt_bridge
readingList $DEVICETOPIC/bridge/state:.* state
$DEVICETOPIC/bridge/config/devices:.* {}
$DEVICETOPIC/bridge/config/log_level:.* log_level
$DEVICETOPIC/bridge/config/permit_join:.* permit_join
$DEVICETOPIC/bridge/config/rename:.* { json2nameValue($EVENT, 'rename_') }
$DEVICETOPIC/bridge/config:.* { json2nameValue($EVENT) }
$DEVICETOPIC/bridge/log:.*\"type\".\"devices\".\"message\".* devices
$DEVICETOPIC/bridge/log:.* log
$DEVICETOPIC/bridge/logging:.* { json2nameValue($EVENT,'log_') }
$DEVICETOPIC/bridge/response/networkmap:.* { my $type = $EVENT =~ m/.*,"type":"(raw|graphviz)",.*/ ? $1 : 'networkmap'; $EVENT =~ m/{"data":\{.*"value":"?(.*[^"])"?\},"status":"ok"\}/ ? { $type=>$1 } : {} }
$DEVICETOPIC/bridge/devices:.* devices
$DEVICETOPIC/bridge/info:.* info
$DEVICETOPIC/bridge/groups:.* groups
$DEVICETOPIC/bridge/event:.* { json2nameValue($EVENT) }
$DEVICETOPIC/bridge/extensions:.* extensions
$DEVICETOPIC/bridge/response/permit_join:.* { json2nameValue($EVENT) }
$DEVICETOPIC/bridge/definitions:.* {}
room HASS
setList log_level:debug,info,warn,error $DEVICETOPIC/bridge/config/log_level $EVTPART1
permit_join:true,false $DEVICETOPIC/bridge/request/permit_join $EVTPART1
remove:textField $DEVICETOPIC/bridge/config/remove $EVTPART1
ota_update:textField $DEVICETOPIC/bridge/ota_update/update $EVTPART1
ota_update_check:textField $DEVICETOPIC/bridge/ota_update/check $EVTPART1
y_device_setting:textField $DEVICETOPIC/$EVTPART1/set {"$EVTPART2": "$EVTPART3"}
x_bind:textField $DEVICETOPIC/bridge/bind/$EVTPART1 $EVTPART2
x_bind_unbind:textField $DEVICETOPIC/bridge/unbind/$EVTPART1 $EVTPART2
x_device_options:textField $DEVICETOPIC/bridge/config/device_options {"friendly_name":"$EVTPART1","options": {"$EVTPART2": "$EVTPART3"}}
x_group_add_to:textField $DEVICETOPIC/bridge/group/$EVTPART1/add $EVTPART2
x_group_rm_from:textField $DEVICETOPIC/bridge/group/$EVTPART1/remove $EVTPART2
x_group_rm_from_all:textField $DEVICETOPIC/bridge/group/$EVTPART1/remove_all $EVTPART2
x_group_add_group:textField $DEVICETOPIC/bridge/config/add_group $EVTPART1
x_group_rm_group:textField $DEVICETOPIC/bridge/config/remove_group $EVTPART1
z_elapsed:textField $DEVICETOPIC/bridge/config/elapsed $EVTPART1
z_last_seen:disable,ISO_8601,epoch,ISO_8601_local $DEVICETOPIC/bridge/config/last_seen $EVTPART1
z_ban:textField $DEVICETOPIC/bridge/config/ban $EVTPART1
z_rename:textField $DEVICETOPIC/bridge/config/rename {"old":"$EVTPART1","new":"$EVTPART2"}
z_reset_CC:noArg $DEVICETOPIC/bridge/config/reset
setStateList on off
Danke für eure Mühe
Dean
Zitat von: Deanw1975 am 06 Dezember 2024, 10:00:12Nun wollte ich gerne ein Zigbee Gerät aus HASS zurück nach FHEM übertragen.
Da du anschließend von zigbee2mqtt sprichst:
Das ist einfach ein Dienst, der parallel sowohl FHEM wie beliebig viele andere Automatisierungslösungen versort. Infos zur Einbindung von zigbee2mqtt in FHEM findest du im Wiki, und eigentlich sollte eine neue MQTT2_DEVICE-Instanz angelegt worden sein (aber nicht wegen der log-Message, sondern wegen der "originalen" message).
Falls du nicht ganz aktuell bist, vielleicht nochmal ein update fahren, es gab irgendeinen Wackler in json2nameReading(), der jetzt beseitigt sein sollte.
ZitatFalls du nicht ganz aktuell bist, vielleicht nochmal ein update fahren, es gab irgendeinen Wackler in json2nameReading(), der jetzt beseitigt sein sollte.
Betrifft Installationen, die in den letzten 7 Tagen ein update gemacht haben, und im JSON Schlüssel(!) ungewöhnliche Buchstaben verwenden, z.Bsp. { "Küche":7, "12:34:56:78":-13 }.
Soweit ich sehe, ist das hier nicht der Fall.
Zitat von: Beta-User am 06 Dezember 2024, 10:05:50Da du anschließend von zigbee2mqtt sprichst:
Das ist einfach ein Dienst, der parallel sowohl FHEM wie beliebig viele andere Automatisierungslösungen versort. Infos zur Einbindung von zigbee2mqtt in FHEM findest du im Wiki, und eigentlich sollte eine neue MQTT2_DEVICE-Instanz angelegt worden sein (aber nicht wegen der log-Message, sondern wegen der "originalen" message).
Klar, zigbee2mqtt ist an einen Broker in HASS angebunden. Aber dieser muss doch auch die Geräte an FHEM weitergeben können?
Frage ist natürlich wer gibt an FEHM. Der Dienst zigbee2mqtt oder der dazugeöhrige Broker.
Zitat von: Beta-User am 06 Dezember 2024, 10:05:50Falls du nicht ganz aktuell bist, vielleicht nochmal ein update fahren, es gab irgendeinen Wackler in json2nameReading(), der jetzt beseitigt sein sollte.
Wurde durchgeführt
Zitat von: Deanw1975 am 06 Dezember 2024, 11:10:35Aber dieser muss doch auch die Geräte an FHEM weitergeben können?
"Broker" ist alte Terminologie, aber klar, du kannst mehr oder weniger jeden beliebigen MQTT-Server an FHEM anbinden. Wenn der Server extern ist, halt via MQTT2_CLIENT, was bzgl. "autocreate" halt nicht so fancy ist wie MQTT2_SERVER zu verwenden.
Dein Problem bzgl. zigbee2mqtt liegt aber immer noch nicht in der Verbindung HASS<->FHEM, sondern in der Konfiguration von MQTT2_.* in FHEM. Schau dir an, was da in MQTT2_CLIENT an traffic zu sehen ist und befasse dich mit "autocreate" (was m.E. in der Konstaellation eigentlich nicht zu empfehlen ist!), und Themen wie "client order" im Verhältnis zu MQTT_GENERIC_BRIDGE.
Meine Empfehlung wäre, zumindest übergangsweise einen MQTT2_SERVER zu aktivieren und zigbee2mqtt dahin zu verlegen, damit erst mal deine Geräte per autocreate angelegt und (per attrTemplate, das du ja anscheinend gefunden hast) halbwegs sinnvoll konfiguriert werden. Sonst ist das zu zäh. Just my2ct.
Zitat von: Beta-User am 06 Dezember 2024, 11:29:50Dein Problem bzgl. zigbee2mqtt liegt aber immer noch nicht in der Verbindung HASS<->FHEM, sondern in der Konfiguration von MQTT2_.* in FHEM. Schau dir an, was da in MQTT2_CLIENT an traffic zu sehen ist und befasse dich mit "autocreate" (was m.E. in der Konstaellation eigentlich nicht zu empfehlen ist!), und Themen wie "client order" im Verhältnis zu MQTT_GENERIC_BRIDGE.
Im Wiki steht nur
Möchte man autocreate verwenden, um automatisiert MQTT2_DEVICE-Geräte anlegen zu lassen, empfiehlt es sich, auf das erste automatisch angelegte Gerät das template MQTT2_CLIENT_general_bridge anzuwenden. Dadurch werden anschließend bestimmte eingehenden MQTT-Messages für eine Anzahl häufig anzutreffender Gerätetypen in separate, automatisch angelegte MQTT2_DEVICE-Geräte umgeleitet[2].Wo kann ich das "Autocreate" kurzfristig hinterlegen um es nach erfolgreicher Aktion wieder zu löschen?
Zitat von: Beta-User am 06 Dezember 2024, 11:29:50Meine Empfehlung wäre, zumindest übergangsweise einen MQTT2_SERVER zu aktivieren und zigbee2mqtt dahin zu verlegen, damit erst mal deine Geräte per autocreate angelegt und (per attrTemplate, das du ja anscheinend gefunden hast) halbwegs sinnvoll konfiguriert werden. Sonst ist das zu zäh. Just my2ct.
Das wäre dann der zweite Versuch.
Zitat von: Deanw1975 am 06 Dezember 2024, 12:08:25Im Wiki steht nur
Das stimmt auch. Es bezieht sich aber v.a. auf die
"empfohlene Vorgehensweise" mit MQTT2_SERVER.
Wenn du "autocreate" am MQTT2_CLIENT aktivierst (wie, steht wie üblich in der commandref zu diesem Modul), wirst du halt ggf. "Spaß" haben, je nachdem, was du halt sonst noch so an MQTT hängen hast. "Spaß" kann bedeuten: Viel Last an FHEM, (vielleicht) viele Devices, vielleicht "komische" readingList-Einträge, vielleicht sogar unbeabsichtigte Schleifen, whatever. Kurz: Arbeite dich ein, v.a., wenn du MQTT2_CLIENT verwenden willst!
Zitat von: Beta-User am 06 Dezember 2024, 11:29:50Meine Empfehlung wäre, zumindest übergangsweise einen MQTT2_SERVER zu aktivieren und zigbee2mqtt dahin zu verlegen, damit erst mal deine Geräte per autocreate angelegt und (per attrTemplate, das du ja anscheinend gefunden hast) halbwegs sinnvoll konfiguriert werden. Sonst ist das zu zäh. Just my2ct.
Habe ich gemacht:
Zigbee2mqtt auf meinen Fhem MQTT2_SERVER umgestellt. Gerät wurde angelegt.
Template drauf gelegt.
Konnte ich von Fhem aus schalten.
Zignbee wieder auf HASS MQTT-Server umgestellt.
Wenn ich das Gerät von HASS aus schalte, ändert sich auch der Status in FHEM.
Von Fhem aus kann ich keine Änderungen an das Gerät senden.
Erst wenn ich wieder auf den FHEM MQTT_Server in Zigbee anstelle kann ich wieder in FHEM schalten, aber dann nicht mehr in HASS.
Was mache ich falsch?
Danke
Dean
IODev hast du angepasst?
Hallo zusammen,
in Fhem und Homeassistent habe ich den Dummyswitch angelegt.
Kann diesen von beiden Seiten auch schalten.
In Homeassistent wird mir aber der Schalter immer als Status "unbekannt" angezeigt.
Wenn ich den availability_topic, payload_available und payload_not_available in Homeassistent aktiviere, geht der ganze Dummy offline.
mqtt:
- switch:
unique_id: demoswitch
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"
Hier der Eintrag aus FHEM:
Bridge:
nternals:
BUF
Clients :MQTT2_DEVICE:MQTT_GENERIC_BRIDGE:
ClientsKeepOrder 1
DEF 192.168.178.100:1883
DeviceName 192.168.178.100:1883
FD 230
FUUID 677a7828-f33f-61e0-9c2c-64af1a295dc3aaf8
NAME ha_MQTT2
NR 842
PARTIAL
STATE opened
TYPE MQTT2_CLIENT
WBCallback
clientId fhem
eventCount 11
lastMsgTime 1736148829.2737
nextOpenDelay 10
nrConnects 4
qosCnt 67
qosMaxQueueLength 100
.attraggr:
.attrminint:
.clientArray:
MQTT2_DEVICE
MQTT_GENERIC_BRIDGE
MatchList:
1:MQTT2_DEVICE ^.
2:MQTT_GENERIC_BRIDGE ^.
READINGS:
2025-01-06 08:15:58 state opened
qosQueue:
Attributes:
clientId fhem
keepaliveTimeout 60
msgAfterConnect -r fhem/connection/status connected
msgBeforeDisconnect -r fhem/connection/status disconnected
qosMaxQueueLength 100
room MQTT
username xxxxxxxxxx
Im MQTT Explorer sehen ich den Topic zum Status auch in Homeassietent
Was soll ich ändern?
VG
Dean
Zum einen TYPE vom "Dummyswitch" ist ?!?
Zum anderen: Clientorder anschauen!
Zitat von: Beta-User am 06 Januar 2025, 09:05:29Zum einen TYPE vom "Dummyswitch" ist ?!?
Ist ein dummy:
Internals:
FUUID 677a79d8-f33f-61e0-ead4-e2c243464501d492
LASTInputDev ha_MQTT2
MSGCNT 7
NAME demoswitch
NR 844
STATE off
TYPE dummy
eventCount 10
ha_MQTT2_MSGCNT 7
ha_MQTT2_TIME 2025-01-06 08:04:37
.attraggr:
.attrminint:
READINGS:
2025-01-06 08:04:37 state off
Attributes:
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
Was meinst du damit:
Zitat von: Beta-User am 06 Januar 2025, 09:05:29Zum anderen: Clientorder anschauen!
Guten Morgen,
leider habe ich noch keine weitere Reaktion auf meinen beiden Einträge vom 06.1.2025
Kann es sein, dass meine Probleme daran liegen das kein set übertragen wird.
Also dieser Befehl fehlt:
fhem/demoswitch/set
Der Eintrag ist aber hinterlegt:
attr demoswitch mqttSubscribe state:stopic={"$base/set"}"
Der "state" wird übertragen.
Danke
Dean
Zitat von: Deanw1975 am 11 Januar 2025, 06:57:17Guten Morgen,
leider habe ich noch keine weitere Reaktion auf meinen beiden Einträge vom
Hast du denn das Stichwort in deinem Beitrag gesucht und in der commandref nachgeschaut?
Hi "Beta-User"
Bin ich Blind?
in meinem Beitrag steht nichts zu "Clientorder"
Diese soll laut commandref auch nicht relevant sein, wenn autocreate nicht aktiv ist (was der Fall ist)
Oder auch nicht, wenn die wenn die Bridge schon eine ausreichende Order inne hat.
Was ich aus dem zweiten Beitrag hier 1zu1 übernommen hatte.
Wie du dem "List" entnehmen kannst, kann ich die also meinem eigenen Beitrag gar nicht den Begriff "Clientorder" entnehmen:-(
Also was soll ich als "Clientorder" wo eintragen?
Hmm, trotzdem ändern.
Nur, falls es ein M2D geben sollte, das den topic abgreift..
Und mqttForward im MGB commandref nachsehen (dummy-TYPE). Dann aber Schleife prüfen!
Clientorder kann man nur bei MQTT2_CLIENT hinterlegen.
Laut Doku habe ich nun das am client hinterlegt
clientOrder demoswitch mqttGeneric
Das hat aber ein Effekt.
Vor allem, verstehe ich den Sinn nicht.
Aber sicher bekomme ich nur wieder ne Antwort die mich nicht weiter bringt.
ZitatClientorder kann man nur bei MQTT2_CLIENT hinterlegen.
Das geht auch bei MQTT2_SERVER, das ist aber vmtl. in diesem Fall irrelevant.
ZitatclientOrder demoswitch mqttGeneric
So wird das nicht funktionieren: clientOrder benoetigt Modulnamen, wie in der Doku: https://fhem.de/commandref_modular.html#MQTT2_CLIENT-attr-clientOrder
d.h.
attr ha_MQTT2 clientOrder MQTT_GENERIC_BRIDGE MQTT2_DEVICE
ZitatVor allem, verstehe ich den Sinn nicht.
Diese Liste bestimmt die Reihenfolge der Module, die unbekannte Nachrichten verarbeiten.
Per Voreinstellung bekommt MQTT2_DEVICE sie als erstes, und legt eine MQTT2_DEVICE Instanz an.
MQTT_GENERIC_BRIDGE hat dann das Nachsehen.
ZitatAber sicher bekomme ich nur wieder ne Antwort die mich nicht weiter bringt.
Nicht immer haben die (freiwilligen) Helfer Zeit oder Geduld, das nochmal detailliert hinzuschreiben, was sie schon oft gemacht haben, manchmal erwarten sie sogar, dass Hilfesuchende erst die Doku lesen.
Das kann fuer Hilfesuchende frustrierend sein, aber man kann sich damit troesten, dass man hier die Chance hat, den Entwickler direkt zu treffen, was bei bezahlten Produkten nicht der Fall ist.
Zitat von: Deanw1975 am 11 Januar 2025, 17:22:59Vor allem, verstehe ich den Sinn nicht.
Rudi hat das ja dankenswerterweise erklärt.
Vielleicht nochmal der "Datenweg":
"irgendwas" (hier: HomeAssistant) publisht eine Message. Der MQTT-Server (hier extern) schubst es weiter an alle, die den betreffenden Topic abonniert haben. Das sollte hier FHEM mit einer MQTT2_CLIENT-Instanz sein.
In dieser sind keine "subscriptions" per Attribut gesetzt, es kommt also "alles" an. Das kann man prüfen, indem man "show MQTT traffic" in der entsprechenden Instanz anschaltet. Dann wirst du vermutlich sehen, ob/was da ankommt (mein Tipp: viel zu viel...).
Danach wird jede message per "dispatch" weitergereicht. Ist clientOrder nicht gesetzt, bekommt zuerst MQTT2_DEVICE diese message. Falls autocreate NIE gesetzt war, macht es "nichts" und reicht die message an das nächste Modul weiter. Falls aber - aus IRGENDEINEM Grund eine passende readingList da ist (bei weiter deaktiviertem autocreate), kommt nichts bei MGB an. Daher sollte man IMMER die clientOrder setzen, es sei denn, man weiß GENAU, was man tut und wie man Fehler findet.
Dann kommt ggf. die message wirklich bei MGB an. Mit etwas Glück paßt dann die Konfiguration und das entsprechende FHEM-Device (hier: der dummy) wird aktualisiert/geschaltet/whatever.
Falls das passiert ist, kann man sich um den Rückweg kümmern. Zu mqttForward gab es keine Rückmeldung...
Also anders gesagt: Bis wohin funktioniert jetzt die Kette, wenn du von HomeAssistant aus versuchst, den dummy zu "schubsen"?
Weil das ganze kompliziert ist und man sinnvollerweise eine bestimmte Auswahl von Attributen an den diversen Elementen setzt, gibt es "attrTemplate" - auch für MQTT_GENERIC_BRIDGE - mit denen wir vermeiden wollen, dass man jedes Mal von Adam und Eva anzufangen muss...
Danke für eure Erläuterungen
ich habe nun das Device angepasst
Also: clientOrder mqttGeneric demoswitch
Hier mal das List
Internals:
BUF
Clients :mqttGeneric:demoswitch:
ClientsKeepOrder 1
DEF 192.168.178.100:1883
DeviceName 192.168.178.100:1883
FD 173
FUUID 677a7828-f33f-61e0-9c2c-64af1a295dc3aaf8
NAME ha_MQTT2
NR 840
PARTIAL
STATE opened
TYPE MQTT2_CLIENT
WBCallback
clientId fhem
eventCount 1
lastMsgTime 1736759768.42387
nextOpenDelay 10
nrConnects 1
qosCnt 93
qosMaxQueueLength 100
.clientArray:
MatchList:
1:mqttGeneric ^.
2:demoswitch ^.
READINGS:
2025-01-13 03:30:15 state opened
qosQueue:
Attributes:
autocreate no
clientId fhem
clientOrder mqttGeneric demoswitch
keepaliveTimeout 60
msgAfterConnect -r fhem/connection/status connected
msgBeforeDisconnect -r fhem/connection/status disconnected
qosMaxQueueLength 100
room MQTT
username mqtt
Im MQTT Explorer sehe ich immer noch den den Demoswitch der an Homeassistent ankommt.
Aber der Demoswich bleibt immer noch im Status UNBEKANNT.
Ohne Clientordner kann ich auf beiden Seiten schalten, mit Clientorder kann ich Homeassistent nicht mehr schalten, obwohl auch in FHEM der Befehl (laut MQTT Explorer am Fhem Broker) ankommt.
Wenn ich den Clientorner wieder weg nehme, kann ich von beiden Seiten schalten.
Zitat von: Deanw1975 am 13 Januar 2025, 10:28:10Also: clientOrder mqttGeneric demoswitch
Nope! So wie Rudi das geschrieben hatte...
Zitat von: rudolfkoenig am 11 Januar 2025, 19:45:35d.h.
Code Auswählen Erweitern
attr ha_MQTT2 clientOrder MQTT_GENERIC_BRIDGE MQTT2_DEVICE
Und wenn du dann (wieder) den dummy via MQTT schalten kannst, und es "einfach nur" darum geht, dass die Schaltung nicht von FHEM wieder rückwärts gesendet wird, befasse dich mit mqttForward! (oder einer "optimistic"-Einstellung auf der HomeAssistant-Seite).
Hallo, ich möchte jetzt auch meine Geräte aus FHEM in HA sicht- und schaltbar machen. Habe den ganzen Thread hier zweimal gelesen und alles so konfiguriert.
FHEM schickt die Daten vom demoswitch im Raum HASS nach HA und dort sehe ich auch den Status. Wenn ich in FHEM den demoswitch schalte, reagiert HA sofort und zeigt den richtigen Status.
Nur rückwärts klappt es nicht. Wenn ich in HA den demoswitch schalte, welchselt er nach 2 Sekunden wieder zurück und in FHEM passiert nichts.
Ich lausche auch per MQTT-Explorer am FHEM Server, aber das topic "fhem/demoswitch/set" kommt dort nicht an. Auch wenn ich über die Entwicklertools das topic veröffentliche, passiert nichts. Vmtl. fehlt mir noch irgnedwas in HA für die Rücksendung. Aber ich stehe hier auf dem Schlauch.
Hier meine Config:
demoswitch:
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 mqttForward all
attr demoswitch mqttSubscribe state:stopic={"$base/set"}
attr demoswitch room HASS,MQTT2_DEVICE
attr demoswitch webCmd on:off
MQTT2-Client:
defmod myMQTT2Client MQTT2_CLIENT 10.4.70.142:1883
attr myMQTT2Client clientId fhem
attr myMQTT2Client group MQTT
attr myMQTT2Client icon mqtt
attr myMQTT2Client keepaliveTimeout 60
attr myMQTT2Client msgAfterConnect -r fhem/connection/status connected
attr myMQTT2Client msgBeforeDisconnect -r fhem/connection/status disconnected
attr myMQTT2Client qosMaxQueueLength 100
attr myMQTT2Client room MQTT2_DEVICE
attr myMQTT2Client username mqtt-user
MQTT_GENERIC_BRIDGE:
defmod myMQTTGenericBridge MQTT_GENERIC_BRIDGE mqtt room=HASS
attr myMQTTGenericBridge IODev myMQTT2Client
attr myMQTTGenericBridge globalDefaults sub:qos=2 pub:qos=0 retain=1 base={"fhem/$device"}fhem
attr myMQTTGenericBridge globalPublish *:topic={"fhem/$device/$reading"}
attr myMQTTGenericBridge group MQTT
attr myMQTTGenericBridge icon mqtt_bridge_2
attr myMQTTGenericBridge room MQTT2_DEVICE
attr myMQTTGenericBridge stateFormat in: incoming-count out: outgoing-count devices: device-count
HA - configuration.yaml: (wobei alles mit # ja auskommentiert ist)
mqtt:
switch:
- 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"
Wäre für eine kleine Hilfe sehr dankbar.
Viele Grüße
Oh, ich habe gerade chatgpt gefragt und habe daraufhin folgendes am demoswitch dummy geändert:
attr demoswitch mqttSubscribe state:stopic={"fhem/demoswitch/set"}
Jetzt funktioniert es. Warum wird denn das vorherige "$base/set" falsch umgesetzt?
Naja, jetzt funtkioniert es aber...
Zitat von: thgorjup am 14 März 2025, 13:53:48Oh, ich habe gerade chatgpt gefragt und habe daraufhin folgendes am demoswitch dummy geändert:
attr demoswitch mqttSubscribe state:stopic={"fhem/demoswitch/set"}
Jetzt funktioniert es. Warum wird denn das vorherige "$base/set" falsch umgesetzt?
Naja, jetzt funtkioniert es aber...
Vielleicht weil da nochmal "fhem" steht?
Kann nicht recht nachvollziehen, warum der Vorschlag nicht übernommen wird, $base für sub und pub unterschiedlich zu setzen...