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