gpio auf 2tem fhem via MQTT schalten

Begonnen von Trefzy, 08 Mai 2020, 10:10:21

Vorheriges Thema - Nächstes Thema

Trefzy

Hallo zusammen
ich möchte via MQTT von meinem Haupt FHEM einen gpio auf einer 2ten FHEM Instanz schalten. Bisher funktioniert nur die Anzeige auf dem HauptFHEM. Irgendwie reagiert das gpio nicht auf den set Befehl. Die Befehle kommen auf dem MQTT Broker an (getestet mit MQTT.fx). Was ich festgestellt habe ist dass beim HauptFHEM on off gesendet wird und der 2te FHEM sendet AN AUS.
Kann es daran liegen?
Wenn ja wie kann ich das ändern?
Wenn nein kann mir einer sagen wo mein Denkfehler liegt?

HauptFHEM:
define MQTT_Brunnen_Licht MQTT_DEVICE
attr MQTT_Brunnen_Licht IODev Broker_131
attr MQTT_Brunnen_Licht alias Brunnen
attr MQTT_Brunnen_Licht group Beleuchtung
attr MQTT_Brunnen_Licht icon light_light_dim_100
attr MQTT_Brunnen_Licht publishSet on off /GPIO/Brunnen_Licht/state/set
attr MQTT_Brunnen_Licht room 51 Terasse Süd
attr MQTT_Brunnen_Licht stateFormat state
attr MQTT_Brunnen_Licht subscribeReading_state /GPIO/Brunnen_Licht/state
attr MQTT_Brunnen_Licht userReadings _state

2terFHEM:
defmod MQTT_Brunnen_Licht MQTT_BRIDGE gpio_Brunnen_Licht
attr MQTT_Brunnen_Licht IODev Broker_131
attr MQTT_Brunnen_Licht publishState /GPIO/Brunnen_Licht/state
attr MQTT_Brunnen_Licht room MQTT
attr MQTT_Brunnen_Licht stateFormat transmission-state
attr MQTT_Brunnen_Licht subscribeSet /GPIO/Brunnen_Licht/state/set

defmod gpio_Brunnen_Licht RPI_GPIO 23
attr gpio_Brunnen_Licht active_low yes
attr gpio_Brunnen_Licht alias Brunnen
attr gpio_Brunnen_Licht devStateIcon AUS:10px-kreis-rot AN:10px-kreis-gruen
attr gpio_Brunnen_Licht direction output
attr gpio_Brunnen_Licht eventMap on:AN off:AUS
attr gpio_Brunnen_Licht group Beleuchtung
attr gpio_Brunnen_Licht icon light_light_dim_100
attr gpio_Brunnen_Licht room Terasse



Otto123

Hi,

aber das ist doch nur wegen eventMap? eventMap on:AN off:AUS
Mir fehlt irgendwie das Bindeglied?! Wie soll denn dein gpio_Brunnen_Licht überhaupt den Schaltbefehl erhalten? Die Bridge allein macht das doch nicht?
Ich denke da fehlt ein notify oder so was.

Aber vielleicht ist das ein falscher Gedanke.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Beta-User

Zitat von: Otto123 am 08 Mai 2020, 14:30:02
Die Bridge allein macht das doch nicht?
So wie mein Verständnis dieses Moduls ist, ist es genau dafür da...

ABER: ab dem 2. Device, das man auf die Art einbindet, wird es - nach meinem persönlichen Verständnis - schräg: Man braucht nämlich dann je ein MQTT_BRIDGE-Device für jedes der eigentlichen Devices.

@TE:
Wenn du das also ausbauen willst, schau dir lieber MQTT_GENERIC_BRIDGE an: Die macht dasselbe, aber 1:n, und alle MQTT-Einstellungen, die mit einem bestimmten "eigentlich-nicht-MQTT-sprechenden" Device zu tun haben, nimmt man dann via Attribut an diesem Device vor.

(Noch eine Anmerkung: Pi-GPIO sind mMn. aus verschiedenen Gründen keine tolle Idee. Für solche Art Basteleien sollte man einen Microcrontroller einsetzen, just my2ct.)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Otto123

Also ich versuche die Kette zu verstehen (ich hatte wohl die Funktion der Bridge nicht so verinnerlicht)
Ein set MQTT_Brunnen_Licht on erzeugt
ein Nachricht über MQTT /GPIO/Brunnen_Licht/state on
Und im 2.ten FHEM wird daraus durch die Bridge
ein set gpio_Brunnen_Licht on erzeugt welches aber
durch eventMap in ein set gpio_Brunnen_Licht AN gewandelt wird?

Richtig? Das müsste man doch im Eventmonitor alles so sehen?
Funktioniert denn ein set gpio_Brunnen_Licht on ?
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Trefzy

Hallo zusammen,

danke für die Antworten.
ich weiss nicht was passiert ist aber plötzlich geht es obwohl ich nichts verändert habe.
MQTT_GENERIC_BRIDGE schaue ich mir mal an. Eigentlich brauche ich es aber aktuell nicht. Aber wer weiss.
Was ich allerdings feststelle ist das die MQTT Meldungen manchmal bis zu 3 sec verzögert am Broker ankommen. Ist für das Händling nicht so schön. Kann das mit der MQTT Bridge zusammenhängen? Habe nun insgesamt 6 gpios die gesteuert werden. Alles mit eigener Bridge und MQTT-Device. Funktionieren tut alles bis auf dieses Delay. Und das ist auch nicht immer.
Irgendwelche Ideen an was es liegen könnte?
Und 2te Frage...bringt es was die QoS settings auf 2 zu stellen. Erhöht lt Doku den Datenverkehr dafür kommt der Befehl aber nur 1mal und das sicher an. Wie sind eure Erfahrungen?

Beta-User

Bin ziemlich sicher, dass die Verzögerung nicht direkt was mit den MQTT_BRIDGE-Geräten zu tun hat. Vermute eher allgemeine Netzwerkprobleme oder ein irgendwie aus anderen Gründen lahmendes FHEM.

Bei 6 MQTT_BRIDGE Geräten finde ich MQTT_GENERIC_BRIDGE schon sehr viel eleganter. Nur zu meiner Info (ich habe wesentliche Teile der aktuellen Doku zu MQTT beigetragen): Du scheinst ja noch nicht zu lange mit FHEM zugange zu sein. Wie bist du drauf gekommen, das mit MQTT_BRIDGE einzurichten? Und: was könnte man ggf. an der Doku verbessern, dass Neueinsteigern das nicht passiert?

(MQTT_BRIDGE funktioniert zwar, aber dieser Weg ist vergleichsweise unübersichtlich... Selbst der aktuelle Maintainer (ist für beide Bridges zwischenzeitlich derselbe) dürfte das als "outdated" betrachten.).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files