Ich eröffne hier mal das Frage/Anwtwort/Hilfe Thread für das Modul MQTT_GENERIC_BRIDGE.
Damit der eigentliche Beitrag Vorstellungsbeitrag nicht durch Probleme oder co unübersichtlich wird.
Der folgende Device will auf einmal (es ging vor Tagen noch) nicht mehr auf Befehle von NodeRed auf dem /state/set topic hören:
Internals:
CFGFN
NAME Streifen
NR 94
STATE on
TYPE dummy
READINGS:
2018-10-11 14:37:58 newstate on
2018-10-11 14:37:58 state on
Attributes:
alexaName Streifen
alexaRoom Wohnzimmer
genericDeviceType light
group Licht
homebridgeMapping Brightness=state,cmd=
icon light_led_stripe_rgb
mqttDefaults base={"homeland/haushalt/elektrik/wohnzimmer/$device"} pub:qos=2 sub:qos=2 retain=1
mqttPublish state:topic={"$base/$name"} state:qos=2 state:retain=1
mqttSubscribe state:stopic=homeland/haushalt/elektrik/wohnzimmer/Streifen/state/set state:qos=2
room Echo,Wohnzimmer
setList state:slider,0,1,100 on off
userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttPublish:textField-long mqttSubscribe:textField-long
webCmd state
Jemand eine Idee? :o
Ich habe noch genau son Teil und da geht alles - unterschied ist nur die homebridge Sache und es ist kein dummy..
*EDIT Aktuelle Erkenntnis: Genau der Bereich ist aktuell in Überarbeitung
Probiere mal die angehängte Version und gebe dem betroffenen Device ein Attribute namens 'mqttForward' mit dem Wert 'all'.
Absolut zauberhaft! 8) ;D
Genau wie es vorher war :-) Nur halt nun schaltbar.
Dann werde ich Commandref schreiben und einchecken :)
:) Danke sehr! :-D
Du schaffst es den WOA Faktor durch deine schnelle Handlung sehr hoch zu halten. :-D
Hätte ich nun erklären müssen, "Das geht nun gerade nicht...." :o Ouha! ;D
Hallo Hexenmeister,
erst einmal eine tolle Idee das Modul. Leider habe ich ein grundlegendes Verständnisproblem, weshalb ich mich mit der Fehlersuche gerade schwer tue. Um ein größeres Verständnis zu bekommen, wollte ich mich erst einmal an die Beispiele aus Deinem ersten Posting aus der Modulvorstellung -> https://forum.fhem.de/index.php/topic,90735.0.html halten.
Als Testgruppe (Raum) verwende ich meine HomeMatic Geräte, genauergesagt einen 6fach Taster. fhem stürzt aber beim Drücken auf eine Taste ab und muss mittels systemctl restart fhem wiederbelebt werden.
Ich habe die Bridge wie folgt konfiguriert:
Internals
DEF mqtt room=CUL_HM
IODev myBroker
NAME mqttGeneric
NR 198
NTFY_ORDER 50-mqttGeneric
STATE ???
TYPE MQTT_GENERIC_BRIDGE
devspec room=CUL_HM
prefix mqtt
Readings
device-count 1 2018-10-12 12:23:38
incoming-count 0 2018-10-12 12:15:36
outgoing-count 0 2018-10-12 12:15:36
transmission-state IO device initialized 2018-10-12 12:15:43
updated-reading-count 0 2018-10-12 12:15:36
updated-set-count 0 2018-10-12 12:15:36
Attributes
IODev myBroker deleteattr
room MQTT deleteattr
verbose 5 deleteattr
Mein Testobjekt ist wie gesagt ein HomeMatic 6fach Taster (HM-PB-6-WM55). Dieser, sowie die einzelnen Channels sind als Device in fhem angelegt.
Attrib-Sektion des 6fach-Schalters:
Attributes
IODev hmusb deleteattr
IOgrp vccu:hmusb deleteattr
autoReadReg 4_reqStatus deleteattr
expert 2_raw deleteattr
firmware 1.2 deleteattr
group Licht deleteattr
model HM-PB-6-WM55 deleteattr
mqttDefaults base={"/TEST/$device"} pub:qos=0 sub:qos=2 retain=0 deleteattr
mqttPublish *:topic={"$base/$name"} *:qos=2 *:retain=0 deleteattr
room CUL_HM,MQTT,Wohnzimmer deleteattr
serialNr XXXXXXXXXX deleteattr
subType remote deleteattr
userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttPublish:textField-long mqttSubscribe:textField-long deleteattr
verbose 5 deleteattr
webCmd getConfig:clear msgEvents deleteattr
Wenn ich in dieser Konstellation auf einen der 6 Taster drücke, stürzt fhem ab. Im Event Monitor erscheint gar nichts. Im Logfile steht folgendes:
2018.10.12 12:56:24 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for FileLog_wz_Lichtschalter_6fach
2018.10.12 12:56:24 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for FileLog_wz_Rolladenschalter_6fach
2018.10.12 12:56:24 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for hmusb
2018.10.12 12:56:24 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for vccu
2018.10.12 12:56:24 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for wz_Lichtschalter_6fach
2018.10.12 12:56:24 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for wz_Lichtschalter_6fach_Btn_01
2018.10.12 12:56:24 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for wz_Lichtschalter_6fach_Btn_02
2018.10.12 12:56:24 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for wz_Lichtschalter_6fach_Btn_03
2018.10.12 12:56:24 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for wz_Lichtschalter_6fach_Btn_04
2018.10.12 12:56:24 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for wz_Lichtschalter_6fach_Btn_05
2018.10.12 12:56:24 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for wz_Lichtschalter_6fach_Btn_06
2018.10.12 12:56:24 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for wz_Rolladenschalter_6fach
2018.10.12 12:56:24 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for wz_Rolladenschalter_6fach_Btn_01
2018.10.12 12:56:24 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for wz_Rolladenschalter_6fach_Btn_02
2018.10.12 12:56:24 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for wz_Rolladenschalter_6fach_Btn_03
2018.10.12 12:56:24 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for wz_Rolladenschalter_6fach_Btn_04
2018.10.12 12:56:24 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for wz_Rolladenschalter_6fach_Btn_05
2018.10.12 12:56:24 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for wz_Rolladenschalter_6fach_Btn_06
2018.10.12 12:56:24 3: Opening myBroker device reddocker:1883
2018.10.12 12:56:24 3: myBroker device opened
2018.10.12 12:56:25 0: Featurelevel: 5.8
2018.10.12 12:56:25 0: Server started with 72 defined entities (fhem.pl:17329/2018-09-12 perl:5.020002 os:linux user:fhem pid:5688)
2018.10.12 12:56:25 1: HMLAN_Parse: hmusb new condition ok
2018.10.12 12:59:21 5: CUL_HM wz_Lichtschalter_6fach prep ACK for 01
2018.10.12 12:59:21 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_done
2018.10.12 12:59:21 5: CUL_HM wz_Lichtschalter_6fach sent ACK:2
2018.10.12 12:59:21 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/battery => ok (qos: 2, retain: 0)
Undefined subroutine &MQTT::GENERIC_BRIDGE::send_publish called at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 1949.
Ich habe MQTT.fx mitlaufen, der auf sämtliche Topcis lauscht: das /TEST/wz_Lichtschalter_6fach/battery wird nicht versendet.
Jetzt bin ich mir nicht sicher, ob ich etwas falsch konfiguriert habe oder ob vielleicht noch ein Fehler im Modul ist?
Schon einmal vielen Dank im Voraus für deine Hilfe.
Viele Grüße
Sascha
:) Ich versuch einfach Mal zu helfen :-)
Kannst du bitte einem die List von deinem 6fach-Schalters noch anfügen nicht das man da was übersieht ;)
Ich hatte nun erst gedacht ggf. ein Loop der es bei Aktivierung dahin schmelzen lässt bis es tot ist..
Ich vermute was anderes.
Die Entscheidende Meldung lautet "Undefined subroutine &MQTT::GENERIC_BRIDGE::send_publish..."
Bedeutet, dass MQTT-Modul nicht geladen ist. Kannst Du mal ein Listing deines Gateways posten? Irgendwas sagt mir, dass das eine MQTT2_SERVER sein wird...
Zitat von: hexenmeister am 12 Oktober 2018, 13:31:02
Ich vermute was anderes.
Die Entscheidende Meldung lautet "Undefined subroutine &MQTT::GENERIC_BRIDGE::send_publish..."
Bedeutet, dass MQTT-Modul nicht geladen ist. Kannst Du mal ein Listing deines Gateways posten? Irgendwas sagt mir, dass das eine MQTT2_SERVER sein wird...
Hier die Einstellungen meines Devices "myBroker":
DeviceOverview
myBroker opened
Internals:
DEF reddocker:1883
DeviceName reddocker:1883
FD 5
NAME myBroker
NOTIFYDEV global
NR 199
NTFY_ORDER 50-myBroker
PARTIAL
STATE opened
TYPE MQTT
buf
msgid 1
ping_received 1
timeout 60
READINGS:
2018-10-12 14:46:11 connection active
2018-10-12 14:36:11 state opened
messages:
Attributes:
room MQTT
Wenn ich testhalber in diesem Objekt (myBroker) ein set publish FHEM/Test absetze, dann kommt das sowohl in meiner Node Red Installation als auch im MQTT.fx an.
Ich bin beim Anlegen des Brokers wie in der fhem MQTT-Einführung angegeben vorgegangen: https://wiki.fhem.de/wiki/MQTT_Einf%C3%BChrung
Viele Grüße
Sascha
Zitat von: Master_Nick am 12 Oktober 2018, 13:18:53
:) Ich versuch einfach Mal zu helfen :-)
Kannst du bitte einem die List von deinem 6fach-Schalters noch anfügen nicht das man da was übersieht ;)
Ich hatte nun erst gedacht ggf. ein Loop der es bei Aktivierung dahin schmelzen lässt bis es tot ist..
Die Settings hatte ich in meinem ersten Post angehangen. Wie erstelle ich "die List"? Ist das der Link "getConfig" in der DeviceOverview?
Tatsächlich verabschiedet sich fhem nach Klick darauf.
Im Log und im Eventlog wird aber nichts festgehalten (habe es jetzt drei mal wiederholt).
OK, das ist alles so korrekt. Frage mich jetzt, warum eine existierende Methode nicht gefunden werden kann... Ist Dein FHEM aktuell? Mache ggf. ein update.
Zitat von: HomeAlone am 12 Oktober 2018, 14:59:25
Im Log und im Eventlog wird aber nichts festgehalten (habe es jetzt drei mal wiederholt).
ZitatUndefined subroutine &MQTT::GENERIC_BRIDGE::send_publish called at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 1949.
Kommt das nicht mehr?
Zitat von: hexenmeister am 12 Oktober 2018, 14:59:45
OK, das ist alles so korrekt. Frage mich jetzt, warum eine existierende Methode nicht gefunden werden kann... Ist Dein FHEM aktuell? Mache ggf. ein update.
Das hatte ich vor meinem Posting bereits gemacht. Inkl. restart ;)
Evtl. noch das alte Problem. Ist in fhem.cfg die Definition von MQTT-Modul erst nach der Generic-Bridge definiert? Eigentlich sollte das keine Probleme mehr bereiten...
Zitat von: hexenmeister am 12 Oktober 2018, 15:00:55
Kommt das nicht mehr?
Sorry, das war ungenau ausgedrückt: Doch, das kommt noch, aber es kommt nichts Neues hinzu - also irgendetwas, was auf einen Fehler während des getConfig hinweist. Hier noch mal sicherheitshalber das Log von (Neustart Server, getConfig, Neustart Server)
Dass der EnOcean Stick nicht gefunden wird passt, da ich zur Eingrenzung des Fehlers alles andere außer dem HM-USB Stick abgezogen habe.
2018.10.12 15:11:13 0: Server shutdown
2018.10.12 15:11:13 1: Shutdown executed
2018.10.12 15:11:14 1: Including fhem.cfg
2018.10.12 15:11:15 3: telnetPort: port 7072 opened
2018.10.12 15:11:16 3: WEB: port 8083 opened
2018.10.12 15:11:16 3: WEBphone: port 8084 opened
2018.10.12 15:11:16 3: WEBtablet: port 8085 opened
2018.10.12 15:11:16 2: eventTypes: loaded 160 events from ./log/eventTypes.txt
2018.10.12 15:11:16 1: HMLAN_Parse: hmusb new condition disconnected
2018.10.12 15:11:16 3: Opening hmusb device 127.0.0.1:1234
2018.10.12 15:11:16 1: HMLAN_Parse: hmusb new condition init
2018.10.12 15:11:16 3: hmusb device opened
2018.10.12 15:11:18 3: Opening USB300 device /dev/serial/by-id/usb-EnOcean_GmbH_EnOcean_USB_300_...-port0
2018.10.12 15:11:18 1: USB300: Can't open /dev/serial/by-id/usb-EnOcean_GmbH_EnOcean_USB_300_...-port0: No such file or directory
2018.10.12 15:11:21 2: EnOcean Cryptographic functions are not available.
2018.10.12 15:11:21 2: EnOcean XML functions available.
2018.10.12 15:11:22 1: Including ./log/fhem.save
2018.10.12 15:11:23 2: TCM USB300 not initialized
2018.10.12 15:11:23 1: usb create starting
2018.10.12 15:11:23 3: Probing CUL device /dev/ttyAMA0
2018.10.12 15:11:24 3: Probing TCM_ESP3 device /dev/ttyAMA0
2018.10.12 15:11:24 3: Probing ZWDongle device /dev/ttyAMA0
2018.10.12 15:11:24 3: Probing FRM device /dev/ttyAMA0
2018.10.12 15:11:29 1: usb create end
2018.10.12 15:11:29 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for FileLog_wz_Lichtschalter_6fach
2018.10.12 15:11:29 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for FileLog_wz_Rolladenschalter_6fach
2018.10.12 15:11:29 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for hmusb
2018.10.12 15:11:29 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for vccu
2018.10.12 15:11:29 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for wz_Lichtschalter_6fach
2018.10.12 15:11:29 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for wz_Lichtschalter_6fach_Btn_01
2018.10.12 15:11:29 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for wz_Lichtschalter_6fach_Btn_02
2018.10.12 15:11:29 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for wz_Lichtschalter_6fach_Btn_03
2018.10.12 15:11:29 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for wz_Lichtschalter_6fach_Btn_04
2018.10.12 15:11:29 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for wz_Lichtschalter_6fach_Btn_05
2018.10.12 15:11:29 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for wz_Lichtschalter_6fach_Btn_06
2018.10.12 15:11:29 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for wz_Rolladenschalter_6fach
2018.10.12 15:11:29 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for wz_Rolladenschalter_6fach_Btn_01
2018.10.12 15:11:29 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for wz_Rolladenschalter_6fach_Btn_02
2018.10.12 15:11:29 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for wz_Rolladenschalter_6fach_Btn_03
2018.10.12 15:11:29 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for wz_Rolladenschalter_6fach_Btn_04
2018.10.12 15:11:29 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for wz_Rolladenschalter_6fach_Btn_05
2018.10.12 15:11:29 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for wz_Rolladenschalter_6fach_Btn_06
2018.10.12 15:11:29 3: Opening myBroker device reddocker:1883
2018.10.12 15:11:29 3: myBroker device opened
2018.10.12 15:11:30 0: Featurelevel: 5.9
2018.10.12 15:11:30 0: Server started with 72 defined entities (fhem.pl:17488/2018-10-08 perl:5.020002 os:linux user:fhem pid:8056)
2018.10.12 15:11:30 1: HMLAN_Parse: hmusb new condition ok
2018.10.12 15:12:16 3: FHEMWEB WEB CSRF error: csrf_532654293983908 ne csrf_143619343739446 for client WEB_192.168.178.102_51738 / command set wz_Lichtschalter_6fach getConfig. For details see the csrfToken FHEMWEB attribute.
2018.10.12 15:12:16 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/state => CMDs_pending (qos: 2, retain: 0)
Undefined subroutine &MQTT::GENERIC_BRIDGE::send_publish called at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 1949.
2018.10.12 15:12:30 1: Including fhem.cfg
2018.10.12 15:12:30 3: telnetPort: port 7072 opened
2018.10.12 15:12:31 3: WEB: port 8083 opened
2018.10.12 15:12:31 3: WEBphone: port 8084 opened
2018.10.12 15:12:31 3: WEBtablet: port 8085 opened
2018.10.12 15:12:31 2: eventTypes: loaded 160 events from ./log/eventTypes.txt
2018.10.12 15:12:32 1: HMLAN_Parse: hmusb new condition disconnected
2018.10.12 15:12:32 3: Opening hmusb device 127.0.0.1:1234
2018.10.12 15:12:32 1: HMLAN_Parse: hmusb new condition init
2018.10.12 15:12:32 3: hmusb device opened
2018.10.12 15:12:34 3: Opening USB300 device /dev/serial/by-id/usb-EnOcean_GmbH_EnOcean_USB_300_...-port0
2018.10.12 15:12:34 1: USB300: Can't open /dev/serial/by-id/usb-EnOcean_GmbH_EnOcean_USB_300_...-port0: No such file or directory
2018.10.12 15:12:36 2: EnOcean Cryptographic functions are not available.
2018.10.12 15:12:36 2: EnOcean XML functions available.
2018.10.12 15:12:38 1: Including ./log/fhem.save
2018.10.12 15:12:38 2: TCM USB300 not initialized
2018.10.12 15:12:38 1: usb create starting
2018.10.12 15:12:39 3: Probing CUL device /dev/ttyAMA0
2018.10.12 15:12:39 3: Probing TCM_ESP3 device /dev/ttyAMA0
2018.10.12 15:12:39 3: Probing ZWDongle device /dev/ttyAMA0
2018.10.12 15:12:39 3: Probing FRM device /dev/ttyAMA0
2018.10.12 15:12:44 1: usb create end
2018.10.12 15:12:45 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for FileLog_wz_Lichtschalter_6fach
2018.10.12 15:12:45 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for FileLog_wz_Rolladenschalter_6fach
2018.10.12 15:12:45 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for hmusb
2018.10.12 15:12:45 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for vccu
2018.10.12 15:12:45 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for wz_Lichtschalter_6fach
2018.10.12 15:12:45 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for wz_Lichtschalter_6fach_Btn_01
2018.10.12 15:12:45 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for wz_Lichtschalter_6fach_Btn_02
2018.10.12 15:12:45 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for wz_Lichtschalter_6fach_Btn_03
2018.10.12 15:12:45 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for wz_Lichtschalter_6fach_Btn_04
2018.10.12 15:12:45 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for wz_Lichtschalter_6fach_Btn_05
2018.10.12 15:12:45 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for wz_Lichtschalter_6fach_Btn_06
2018.10.12 15:12:45 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for wz_Rolladenschalter_6fach
2018.10.12 15:12:45 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for wz_Rolladenschalter_6fach_Btn_01
2018.10.12 15:12:45 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for wz_Rolladenschalter_6fach_Btn_02
2018.10.12 15:12:45 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for wz_Rolladenschalter_6fach_Btn_03
2018.10.12 15:12:45 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for wz_Rolladenschalter_6fach_Btn_04
2018.10.12 15:12:45 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for wz_Rolladenschalter_6fach_Btn_05
2018.10.12 15:12:45 5: MQTT_GENERIC_BRIDGE:DEBUG:> CreateDevicesTable for wz_Rolladenschalter_6fach_Btn_06
2018.10.12 15:12:45 3: Opening myBroker device reddocker:1883
2018.10.12 15:12:45 3: myBroker device opened
2018.10.12 15:12:45 0: Featurelevel: 5.9
2018.10.12 15:12:45 0: Server started with 72 defined entities (fhem.pl:17488/2018-10-08 perl:5.020002 os:linux user:fhem pid:8116)
2018.10.12 15:12:45 1: HMLAN_Parse: hmusb new condition ok
Zitat von: hexenmeister am 12 Oktober 2018, 15:16:34
Evtl. noch das alte Problem. Ist in fhem.cfg die Definition von MQTT-Modul erst nach der Generic-Bridge definiert? Eigentlich sollte das keine Probleme mehr bereiten...
So sieht es in der fhem.cfg aus:
define mqttGeneric MQTT_GENERIC_BRIDGE mqtt room=CUL_HM
attr mqttGeneric IODev myBroker
attr mqttGeneric room MQTT
attr mqttGeneric verbose 5
define myBroker MQTT reddocker:1883
attr myBroker room MQTT
Ich vertausche die beiden gleich mal und berichte. Muss aber jetzt dringend weg. Bis hierhin schon mal vielen, vielen Dank für die fixe Hilfe!
Mich wundert ein bischen, dass die Meldung (Opening myBroker device reddocker:1883) nach dem Initialisierung von der Bridge kommt...
Eigentlich sollte das der Bridge egal sein, sie lädt das MQTT-Modul bei Bedarf nach. Das scheint aus irgendwelchem Grund fehlzuschlagen. Kannst Du bitte nachsehen, welche ID/Version das MQTT-Modul hat? Sollte folgende sein: $Id: 00_MQTT.pm 17362 2018-09-17 12:57:29Z hexenmeister $
Wenn das Vertausche nichts bringt, sende mir bitte relevante Abschnitte aus fhem.cfg (Brocker, Bridge, 6fach Schalter (ohne IDs)) damit will ich versuchen, direkt nachzustellen.
Zitat von: hexenmeister am 12 Oktober 2018, 15:40:20
Kannst Du bitte nachsehen, welche ID/Version das MQTT-Modul hat? Sollte folgende sein: $Id: 00_MQTT.pm 17362 2018-09-17 12:57:29Z hexenmeister $
In /opt/fhem/FHEM/00_MQTT.pm seht im Anfangskommentar:
$Id: 00_MQTT.pm 17362 2018-09-17 12:57:29Z hexenmeister $
ist also die richtige.
Zitat von: hexenmeister am 12 Oktober 2018, 15:40:20
Wenn das Vertausche nichts bringt, sende mir bitte relevante Abschnitte aus fhem.cfg (Brocker, Bridge, 6fach Schalter (ohne IDs)) damit will ich versuchen, direkt nachzustellen.
Das Vertauschen bringt uns schon mal weiter - das Ganze stürzt nicht mehr ab.
Wenn ich auf eine Taste am 6fach-Taster drücke erscheint zudem auch Output im Event Monitor!
Log Output:
2018.10.12 23:30:49 3: Opening myBroker device reddocker:1883
2018.10.12 23:30:49 3: myBroker device opened
2018.10.12 23:30:50 0: Featurelevel: 5.9
2018.10.12 23:30:50 0: Server started with 72 defined entities (fhem.pl:17488/2018-10-08 perl:5.020002 os:linux user:fhem pid:28939)
2018.10.12 23:30:50 1: HMLAN_Parse: hmusb new condition ok
2018.10.12 23:31:01 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/state => CMDs_pending (qos: 2, retain: 0)
2018.10.12 23:31:01 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_pending pending:1
2018.10.12 23:31:01 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/state => CMDs_pending (qos: 2, retain: 0)
2018.10.12 23:31:01 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_pending pending:2
2018.10.12 23:31:01 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/state => CMDs_pending (qos: 2, retain: 0)
2018.10.12 23:31:01 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_pending pending:3
2018.10.12 23:31:01 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/state => CMDs_pending (qos: 2, retain: 0)
2018.10.12 23:31:01 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_pending pending:4
2018.10.12 23:31:01 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/state => CMDs_pending (qos: 2, retain: 0)
2018.10.12 23:31:01 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_pending pending:5
2018.10.12 23:31:01 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/state => CMDs_pending (qos: 2, retain: 0)
2018.10.12 23:31:01 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_pending pending:6
2018.10.12 23:31:01 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/state => CMDs_pending (qos: 2, retain: 0)
2018.10.12 23:31:01 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_pending pending:7
2018.10.12 23:31:01 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/state => CMDs_pending (qos: 2, retain: 0)
2018.10.12 23:31:01 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_pending pending:8
2018.10.12 23:31:01 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/state => CMDs_pending (qos: 2, retain: 0)
2018.10.12 23:31:01 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_pending pending:9
2018.10.12 23:31:02 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/state => CMDs_pending (qos: 2, retain: 0)
2018.10.12 23:31:02 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_pending pending:10
2018.10.12 23:31:02 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/state => CMDs_pending (qos: 2, retain: 0)
2018.10.12 23:31:02 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_pending pending:11
2018.10.12 23:31:02 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/state => CMDs_pending (qos: 2, retain: 0)
2018.10.12 23:31:02 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_pending pending:12
2018.10.12 23:31:02 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/state => CMDs_pending (qos: 2, retain: 0)
2018.10.12 23:31:02 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_pending pending:13
2018.10.12 23:31:02 3: CUL_HM set wz_Lichtschalter_6fach getConfig
Event Monitor:
2018-10-12 23:33:49 MQTT myBroker connection: active
2018-10-12 23:33:59 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: outgoing publish sent
2018-10-12 23:33:59 MQTT_GENERIC_BRIDGE mqttGeneric outgoing-count: 14
2018-10-12 23:33:59 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: outgoing publish sent
2018-10-12 23:33:59 MQTT_GENERIC_BRIDGE mqttGeneric outgoing-count: 15
2018-10-12 23:33:59 CUL_HM wz_Lichtschalter_6fach battery: ok
2018-10-12 23:33:59 CUL_HM wz_Lichtschalter_6fach wz_Lichtschalter_6fach_Btn_01 Short
2018-10-12 23:33:59 CUL_HM wz_Lichtschalter_6fach_Btn_01 Short 1_47 (to vccu)
2018-10-12 23:33:59 CUL_HM wz_Lichtschalter_6fach_Btn_01 trigger: Short_47
2018-10-12 23:33:59 CUL_HM wz_Lichtschalter_6fach_Btn_01 trigger_cnt: 47
2018-10-12 23:34:00 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: outgoing publish sent
2018-10-12 23:34:00 MQTT_GENERIC_BRIDGE mqttGeneric outgoing-count: 16
2018-10-12 23:34:00 CUL_HM wz_Lichtschalter_6fach CMDs_pending
2018-10-12 23:34:00 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: outgoing publish sent
2018-10-12 23:34:00 MQTT_GENERIC_BRIDGE mqttGeneric outgoing-count: 17
2018-10-12 23:34:00 CUL_HM wz_Lichtschalter_6fach CMDs_pending
2018-10-12 23:34:01 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: outgoing publish sent
2018-10-12 23:34:01 MQTT_GENERIC_BRIDGE mqttGeneric outgoing-count: 18
2018-10-12 23:34:01 CUL_HM wz_Lichtschalter_6fach CMDs_pending
2018-10-12 23:34:01 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: outgoing publish sent
2018-10-12 23:34:01 MQTT_GENERIC_BRIDGE mqttGeneric outgoing-count: 19
2018-10-12 23:34:01 CUL_HM wz_Lichtschalter_6fach CMDs_pending
2018-10-12 23:34:02 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: outgoing publish sent
2018-10-12 23:34:02 MQTT_GENERIC_BRIDGE mqttGeneric outgoing-count: 20
2018-10-12 23:34:02 CUL_HM wz_Lichtschalter_6fach CMDs_pending
2018-10-12 23:34:02 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: outgoing publish sent
2018-10-12 23:34:02 MQTT_GENERIC_BRIDGE mqttGeneric outgoing-count: 21
2018-10-12 23:34:02 CUL_HM wz_Lichtschalter_6fach CMDs_pending
2018-10-12 23:34:03 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: outgoing publish sent
2018-10-12 23:34:03 MQTT_GENERIC_BRIDGE mqttGeneric outgoing-count: 22
2018-10-12 23:34:03 CUL_HM wz_Lichtschalter_6fach CMDs_pending
2018-10-12 23:34:03 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: outgoing publish sent
2018-10-12 23:34:03 MQTT_GENERIC_BRIDGE mqttGeneric outgoing-count: 23
2018-10-12 23:34:03 CUL_HM wz_Lichtschalter_6fach CMDs_pending
2018-10-12 23:34:04 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: outgoing publish sent
2018-10-12 23:34:04 MQTT_GENERIC_BRIDGE mqttGeneric outgoing-count: 24
2018-10-12 23:34:04 CUL_HM wz_Lichtschalter_6fach CMDs_pending
2018-10-12 23:34:04 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: outgoing publish sent
2018-10-12 23:34:04 MQTT_GENERIC_BRIDGE mqttGeneric outgoing-count: 25
2018-10-12 23:34:05 CUL_HM wz_Lichtschalter_6fach CMDs_pending
2018-10-12 23:34:05 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: outgoing publish sent
2018-10-12 23:34:05 MQTT_GENERIC_BRIDGE mqttGeneric outgoing-count: 26
2018-10-12 23:34:05 CUL_HM wz_Lichtschalter_6fach CMDs_pending
2018-10-12 23:34:05 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: outgoing publish sent
2018-10-12 23:34:06 MQTT_GENERIC_BRIDGE mqttGeneric outgoing-count: 27
2018-10-12 23:34:06 CUL_HM wz_Lichtschalter_6fach CMDs_pending
2018-10-12 23:34:06 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: outgoing publish sent
2018-10-12 23:34:06 MQTT_GENERIC_BRIDGE mqttGeneric outgoing-count: 28
2018-10-12 23:34:06 CUL_HM wz_Lichtschalter_6fach CMDs_done
2018-10-12 23:34:27 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: outgoing publish sent
2018-10-12 23:34:27 MQTT_GENERIC_BRIDGE mqttGeneric outgoing-count: 29
2018-10-12 23:34:27 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: outgoing publish sent
2018-10-12 23:34:27 MQTT_GENERIC_BRIDGE mqttGeneric outgoing-count: 30
2018-10-12 23:34:27 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: outgoing publish sent
2018-10-12 23:34:27 MQTT_GENERIC_BRIDGE mqttGeneric outgoing-count: 31Und das getConfig läuft auch durch:
Log Output bei getConfig:
2018.10.12 23:31:02 3: CUL_HM set wz_Lichtschalter_6fach getConfig
2018.10.12 23:33:59 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_processing... pending:12
2018.10.12 23:33:59 5: CUL_HM wz_Lichtschalter_6fach prep ACK for 01
2018.10.12 23:33:59 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_processing... pending:12
2018.10.12 23:33:59 5: CUL_HM wz_Lichtschalter_6fach sent ACK:2
2018.10.12 23:33:59 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/battery => ok (qos: 2, retain: 0)
2018.10.12 23:33:59 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/state => wz_Lichtschalter_6fach_Btn_01 Short (qos: 2, retain: 0)
2018.10.12 23:33:59 3: wz_notifyEsszimmertischLichtToggle return value: Please define wz_Dimmer_Esstisch first
2018.10.12 23:34:00 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_processing... pending:12
2018.10.12 23:34:00 5: CUL_HM wz_Lichtschalter_6fach sent ACK:2
2018.10.12 23:34:00 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_pending pending:12
2018.10.12 23:34:00 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/state => CMDs_pending (qos: 2, retain: 0)
2018.10.12 23:34:00 4: CUL_HM wz_Lichtschalter_6fach dupe: dont process
2018.10.12 23:34:00 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_processing... pending:11
2018.10.12 23:34:00 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_processing... pending:11
2018.10.12 23:34:00 5: CUL_HM wz_Lichtschalter_6fach sent ACK:2
2018.10.12 23:34:00 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_pending pending:11
2018.10.12 23:34:00 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/state => CMDs_pending (qos: 2, retain: 0)
2018.10.12 23:34:00 4: CUL_HM wz_Lichtschalter_6fach dupe: dont process
2018.10.12 23:34:00 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_processing... pending:10
2018.10.12 23:34:01 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_processing... pending:10
2018.10.12 23:34:01 5: CUL_HM wz_Lichtschalter_6fach sent ACK:2
2018.10.12 23:34:01 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_pending pending:10
2018.10.12 23:34:01 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/state => CMDs_pending (qos: 2, retain: 0)
2018.10.12 23:34:01 4: CUL_HM wz_Lichtschalter_6fach dupe: dont process
2018.10.12 23:34:01 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_processing... pending:9
2018.10.12 23:34:01 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_processing... pending:9
2018.10.12 23:34:01 5: CUL_HM wz_Lichtschalter_6fach sent ACK:2
2018.10.12 23:34:01 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_pending pending:9
2018.10.12 23:34:01 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/state => CMDs_pending (qos: 2, retain: 0)
2018.10.12 23:34:01 4: CUL_HM wz_Lichtschalter_6fach dupe: dont process
2018.10.12 23:34:01 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_processing... pending:8
2018.10.12 23:34:02 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_processing... pending:8
2018.10.12 23:34:02 5: CUL_HM wz_Lichtschalter_6fach sent ACK:2
2018.10.12 23:34:02 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_pending pending:8
2018.10.12 23:34:02 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/state => CMDs_pending (qos: 2, retain: 0)
2018.10.12 23:34:02 4: CUL_HM wz_Lichtschalter_6fach dupe: dont process
2018.10.12 23:34:02 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_processing... pending:7
2018.10.12 23:34:02 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_processing... pending:7
2018.10.12 23:34:02 5: CUL_HM wz_Lichtschalter_6fach sent ACK:2
2018.10.12 23:34:02 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_pending pending:7
2018.10.12 23:34:02 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/state => CMDs_pending (qos: 2, retain: 0)
2018.10.12 23:34:02 4: CUL_HM wz_Lichtschalter_6fach dupe: dont process
2018.10.12 23:34:02 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_processing... pending:6
2018.10.12 23:34:03 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_processing... pending:6
2018.10.12 23:34:03 5: CUL_HM wz_Lichtschalter_6fach sent ACK:2
2018.10.12 23:34:03 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_pending pending:6
2018.10.12 23:34:03 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/state => CMDs_pending (qos: 2, retain: 0)
2018.10.12 23:34:03 4: CUL_HM wz_Lichtschalter_6fach dupe: dont process
2018.10.12 23:34:03 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_processing... pending:5
2018.10.12 23:34:03 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_processing... pending:5
2018.10.12 23:34:03 5: CUL_HM wz_Lichtschalter_6fach sent ACK:2
2018.10.12 23:34:03 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_pending pending:5
2018.10.12 23:34:03 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/state => CMDs_pending (qos: 2, retain: 0)
2018.10.12 23:34:04 4: CUL_HM wz_Lichtschalter_6fach dupe: dont process
2018.10.12 23:34:04 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_processing... pending:4
2018.10.12 23:34:04 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_processing... pending:4
2018.10.12 23:34:04 5: CUL_HM wz_Lichtschalter_6fach sent ACK:2
2018.10.12 23:34:04 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_pending pending:4
2018.10.12 23:34:04 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/state => CMDs_pending (qos: 2, retain: 0)
2018.10.12 23:34:04 4: CUL_HM wz_Lichtschalter_6fach dupe: dont process
2018.10.12 23:34:04 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_processing... pending:3
2018.10.12 23:34:04 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_processing... pending:3
2018.10.12 23:34:04 5: CUL_HM wz_Lichtschalter_6fach sent ACK:2
2018.10.12 23:34:04 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_pending pending:3
2018.10.12 23:34:04 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/state => CMDs_pending (qos: 2, retain: 0)
2018.10.12 23:34:05 4: CUL_HM wz_Lichtschalter_6fach dupe: dont process
2018.10.12 23:34:05 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_processing... pending:2
2018.10.12 23:34:05 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_processing... pending:2
2018.10.12 23:34:05 5: CUL_HM wz_Lichtschalter_6fach sent ACK:2
2018.10.12 23:34:05 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_pending pending:2
2018.10.12 23:34:05 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/state => CMDs_pending (qos: 2, retain: 0)
2018.10.12 23:34:05 4: CUL_HM wz_Lichtschalter_6fach dupe: dont process
2018.10.12 23:34:05 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_processing... pending:1
2018.10.12 23:34:05 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_processing... pending:1
2018.10.12 23:34:05 5: CUL_HM wz_Lichtschalter_6fach sent ACK:2
2018.10.12 23:34:05 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_pending pending:1
2018.10.12 23:34:05 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/state => CMDs_pending (qos: 2, retain: 0)
2018.10.12 23:34:06 4: CUL_HM wz_Lichtschalter_6fach dupe: dont process
2018.10.12 23:34:06 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_processing... pending:0
2018.10.12 23:34:06 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_done
2018.10.12 23:34:06 5: CUL_HM wz_Lichtschalter_6fach sent ACK:2
2018.10.12 23:34:06 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/state => CMDs_done (qos: 2, retain: 0)
2018.10.12 23:34:06 4: CUL_HM wz_Lichtschalter_6fach dupe: dont process
2018.10.12 23:34:27 5: CUL_HM wz_Lichtschalter_6fach prep ACK for 01
2018.10.12 23:34:27 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_done
2018.10.12 23:34:27 5: CUL_HM wz_Lichtschalter_6fach sent ACK:2
2018.10.12 23:34:27 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/battery => ok (qos: 2, retain: 0)
2018.10.12 23:34:27 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/CMDs_done => (qos: 2, retain: 0)
2018.10.12 23:34:27 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/state => wz_Lichtschalter_6fach_Btn_01 Short (qos: 2, retain: 0)
2018.10.12 23:34:27 3: wz_notifyEsszimmertischLichtToggle return value: Please define wz_Dimmer_Esstisch first
2018.10.12 23:37:03 5: CUL_HM wz_Lichtschalter_6fach prep ACK for 01
2018.10.12 23:37:03 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_done
2018.10.12 23:37:03 5: CUL_HM wz_Lichtschalter_6fach sent ACK:2
2018.10.12 23:37:03 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/battery => ok (qos: 2, retain: 0)
2018.10.12 23:37:03 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/CMDs_done => (qos: 2, retain: 0)
2018.10.12 23:37:04 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/state => wz_Lichtschalter_6fach_Btn_01 Short (qos: 2, retain: 0)
2018.10.12 23:37:04 3: wz_notifyEsszimmertischLichtToggle return value: Please define wz_Dimmer_Esstisch first
2018.10.12 23:40:09 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/state => CMDs_pending (qos: 2, retain: 0)
2018.10.12 23:40:09 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_pending pending:1
2018.10.12 23:40:09 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/state => CMDs_pending (qos: 2, retain: 0)
2018.10.12 23:40:09 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_pending pending:2
2018.10.12 23:40:09 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/state => CMDs_pending (qos: 2, retain: 0)
2018.10.12 23:40:09 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_pending pending:3
2018.10.12 23:40:09 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/state => CMDs_pending (qos: 2, retain: 0)
2018.10.12 23:40:09 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_pending pending:4
2018.10.12 23:40:09 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/state => CMDs_pending (qos: 2, retain: 0)
2018.10.12 23:40:09 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_pending pending:5
2018.10.12 23:40:09 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/state => CMDs_pending (qos: 2, retain: 0)
2018.10.12 23:40:09 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_pending pending:6
2018.10.12 23:40:09 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/state => CMDs_pending (qos: 2, retain: 0)
2018.10.12 23:40:09 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_pending pending:7
2018.10.12 23:40:09 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/state => CMDs_pending (qos: 2, retain: 0)
2018.10.12 23:40:09 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_pending pending:8
2018.10.12 23:40:09 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/state => CMDs_pending (qos: 2, retain: 0)
2018.10.12 23:40:09 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_pending pending:9
2018.10.12 23:40:09 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/state => CMDs_pending (qos: 2, retain: 0)
2018.10.12 23:40:09 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_pending pending:10
2018.10.12 23:40:09 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/state => CMDs_pending (qos: 2, retain: 0)
2018.10.12 23:40:09 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_pending pending:11
2018.10.12 23:40:09 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/state => CMDs_pending (qos: 2, retain: 0)
2018.10.12 23:40:09 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_pending pending:12
2018.10.12 23:40:09 5: MQTT_GENERIC_BRIDGE:DEBUG:> publish: /TEST/wz_Lichtschalter_6fach/state => CMDs_pending (qos: 2, retain: 0)
2018.10.12 23:40:09 5: CUL_HM wz_Lichtschalter_6fach protEvent:CMDs_pending pending:13Und siehe da: MQTT.fx und Node Red bekommen die Nachrichten.
D.h. mit der Vertauschung funktioniert es:
define myBroker MQTT reddocker:1883
attr myBroker room MQTT
define mqttGeneric MQTT_GENERIC_BRIDGE mqtt room=CUL_HM
attr mqttGeneric IODev myBroker
attr mqttGeneric room MQTT
attr mqttGeneric verbose 5
Noch mal vielen Dank für die Hilfe!
Viele Grüße,
Sascha
Ich kann seit ein paar Tagen Fhem nicht mehr starten, wenn meine Bridge in der Config ist. Der Startprozess endet mit folgender Meldung:
Undefined subroutine &MQTT::GENERIC_BRIDGE::client_subscribe_topic called at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 1425.
Die Zeilenangabe war bei den ersten Fehlermeldungen auch mal bei 1241. Beim einzigen Device mit einem Subcribe sieht das Attribut so aus:
attr EPSD mqttSubscribe state:topic=EPSD/state battery:topic=EPSD/battery info:topic=EPSD/info error:topic=EPSD/error bootcount:topic=EPSD/bootcount lastEvent:topic=EPSD/lastEvent sleeptime:topic=EPSD/sleeptime
Davor hat eigentlich alles wie erwartet funktioniert.
Die Definition sieht so aus:
define EPSD_Bridge MQTT_GENERIC_BRIDGE
attr EPSD_Bridge DbLogExclude .*
attr EPSD_Bridge IODev mqtt
attr EPSD_Bridge room EPSD
define mqtt MQTT 127.0.0.1:1883
attr mqtt DbLogExclude .*
attr mqtt room Wohnzimmer,ZigBee
Ich habe auch noch ein paar Xiaomi Geräte über ZigBee2MQTT laufen und damit zum selben Zeitpunkt Probleme bekommen, da die Xiaomi Bridge plötzlich nicht mehr lief. Mittlerweile habe ich dort den Fehler gefunden und es läuft wieder. Sollte aber eigentlich nichts mit der Generier Bridge zu tun haben?
Und alles up to date? :o
Sonst schalte doch mal die Xiaomi nochmal ab. Und versuche es dann.
Auch als die Xiaomi Bridge nicht lief, trat das Problem auf. Fhem und Raspbian Stretch sind beide auf dem jeweils neusten Stand. Wenn ich die Generic Bridge während des Betriebs wieder rein nehmen, läuft Fhem auch weiter. Erst nach einem Neustart geht dann nichts mehr.
Ich vermute hier ein Problem mit dem Laden der Module aufgrund falscher Reihenfolge in der fhem.cfg. Wenn die Bridge vor dem MQTT-Instanz definiert ist, würde das erklären. Ich habe was eingebaut, was ggf. MQTT-Modul in der Bridge nachlädt. Bitte morgen ein Update machen. Ich hoffe, das Problem tritt dann nicht mehr auf.
;) Ggf ist ein Umstieg auf ConfigDB empfehlenswert?
Aus meiner Sicht in den meisten Fällen eher nicht.
Konfigdateien ist ein altbewährtes simple Konzept, was gut funktioniert. Wozu verkomplizieren?
:) Sehe da nun nix kompliziertes an der Config DB.
Hat halt den Vorteil, es gibt keine Reihenfolge.
Es ist technisch komplexer. Ich sehe halt keinen Vorteil bei ConfigDB.
Und die Dateien sind (aus meiner Sicht) übersichlicher, einfacher zu sichern und zurück zu spielen, bei Bedarf auch einfacher zu ändern.
Reihenfolge gibt es immer, die Module werden ja nicht alle gleichzeitig geladen. Ich weiß nicht, wie das in ConfigDB geregelt ist (vermutlich durch Sortierung nach ID), aber wenn dort die Reihenfolge mal nicht stimmt, wird es (vor Allem für Anfänger) deutlich schwieriger sein, dies zu beheben. ;)
Eigentlich ist es keine große Sache mit configDB.
Das Reihenfolgethema gibt es da auch.
Ich habe nach dem Wechsel zu configDB jetzt mehrfach die Server-HW getauscht und bin dabei geblieben, vor allem, weil ich die Versionierung als integrierte Option gut finde und v.a., weil mir seitdem auch keine Devices mehr unbeabsichtigt verloren gegangen sind - das hatte ich mit OWX vorher mehrfach.
Aber wie gesagt: ist keine große Diskussion.
Der enorme Vorteil einer DB ist, man könnte wenn man gut ist (und Betateilchen macht bisher den starken Eindruck ;) ) die Notwendige Reihenfolge über Constraints verpflichtend einpflegen. Somit wäre die Reihenfolge des Definierens in FHEM egal.
Aber - reine Vermutung.
Ich hatte über die Jahre deutlich mehr Probleme mit der cfg als mit der config DB ;-)
Reihenfolge ist Modulspezifisch und muss dort auch gelöst werden (jedenfalls, soweit mir bekannt). Aber wenn man si h an die Reihenfolge erst IO, dann Device von vornherein hält (und das IO ggf später ändert, aber nie löscht...), gibts wenig Probleme.
Manche scheinen aber zu glauben, das Löschen und neu Anlegen wäre einfacher.
Zitat von: Beta-User am 15 Oktober 2018, 11:54:01
Reihenfolge ist Modulspezifisch und muss dort auch gelöst werden (jedenfalls, soweit mir bekannt).
Yep. Sauber programmiert, stellt das kein Problem dar.
Zitat von: Beta-User am 15 Oktober 2018, 11:54:01
Manche scheinen aber zu glauben, das Löschen und neu Anlegen wäre einfacher.
Manchmal schon. Vor allem beim Testen kann es schon nötig sein, IO zu löschen.
Zitat von: hexenmeister am 15 Oktober 2018, 16:52:48
Manchmal schon. Vor allem beim Testen kann es schon nötig sein, IO zu löschen.
Agreed. War auch nicht auf Testszenarien gemünzt, sondern bezog sich auf ein immer häufiger anzutreffendes Vorgehen normaler user.
Zitat von: hexenmeister am 14 Oktober 2018, 21:28:02
Ich vermute hier ein Problem mit dem Laden der Module aufgrund falscher Reihenfolge in der fhem.cfg. Wenn die Bridge vor dem MQTT-Instanz definiert ist, würde das erklären. Ich habe was eingebaut, was ggf. MQTT-Modul in der Bridge nachlädt. Bitte morgen ein Update machen. Ich hoffe, das Problem tritt dann nicht mehr auf.
Es lag tatsächlich an der Reihenfolge. Das MQTT Modul war erst nach der Bridge in der Config. Hatte es gestern Abend nochmal getauscht und damit hat es auch wieder funktioniert. Heute hab ich dann ein Update gemacht und nun scheint es auch wieder in anderer Reihenfolge zu funktionieren.
Hallo,
vielen Dank erstmal für das gelungende Modul :-)
Hat jemand schon mal das retain Flag gesetzt?
Scheint bei mir nicht zu funktionieren. Ich habe in
den mqttDefaults folgendes gesetzt:
qos=1 retain=1
Leider bekomme ich nicht den letzten Status übermittelt, beim
Anmelden über einen neuen Client.
Der Versuch über die MQTT_BRIDGE funktioniert und ich bekomme
den letzten Status beim connect eines neuen Clients.
Steht im Commandref nicht *:qos und *:retain? ;)
Ne, stop, du hast recht. Muss ich mir ansehen.
Also über mqttPublish und
*:retain=1
funktioniert es.
Nur meine mqttDefaults wollen nicht :-)
Ich schaue mir an wenn ich wieder zuhause bin (in 2 Wochen). Schneller komme ich leider nicht dazu.
Zitat von: erulez am 17 Oktober 2018, 19:43:59
Also über mqttPublish und
*:retain=1
funktioniert es.
Nur meine mqttDefaults wollen nicht :-)
Funktioniert es nur mittels
*: oder auch mit spezifischem Reading also z. B.:
state:retain=1Vom Feeling her würde ich sagen, funktioniert nicht. Das war mir aber gar nicht als Idee gekommen... hab mir damit beholfen in NodeRed Inject once zu nutzen bis ein Wert kommt :-D
Habe Thermometer mittels der Generic Bridge in MQTT und ich merkte irgendwie ist nie ein Wert da wenn ich NodeRed neu deploye (wobei es sich ja neu anmeldet in MQTT).
@hexenmeister :-) Ich hoffe es ist Urlaub und dann genieße diesen bitte erst mal.
Ich wünsche einen schönen Urlaub.
Ich kann absolut mit dem mqttPublish leben, hätte
ich vielleicht auch früher draufkommen können es
so zu probieren.
Zitathab mir damit beholfen in NodeRed Inject once zu nutzen bis ein Wert kommt :-D
Habe Thermometer mittels der Generic Bridge in MQTT und ich merkte irgendwie ist nie ein Wert da wenn ich NodeRed neu deploye (wobei es sich ja neu anmeldet in MQTT).
Mit NodeRed fange ich jetzt erst an :-) Fhem User bin ich schon seit Jahren, allerdings
liegt mir Perl nicht wirklich.
Projekt ist es als Oberfläche iobroker zu nutzen und NodeRed als Logic. Fhem bleibt für die
devices und mqtt ist dann die "Schnittstelle". So der Plan :-)
Da brauch ich halt "retain" damit iobroker beim Verbinden den Status von Fenster, Licht, Temperaturen, ...
richtig anzeigt.
:) Aber funktioniert es denn nun NUR mit *:retain=1 oder auch mit state:retain=1 :-D ?
ZitatAber funktioniert es denn nun NUR mit *:retain=1 oder auch mit state:retain=1 :-D ?
Werde ich heute Abend mal mit nen Testtopic ausprobieren :-)
Ich berichte.
Vielen Dank für die guten Wünsche. Es ist wirklich ein Urlaub :) Ab morgen geht es weg.
Habe kurz nachgesehen und denke den Fehler gefunden zu haben. Testet mal bitte (am besten ausgibig) die angehängte Version.
Sieht sehr gut aus! :-)
Da wo sonst nach einem neu Start von NodeRed nix war kommen nun fleißig die retainten werte :-)
Danke!
Danke funktioniert, Schönen Urlaub :)
Danke, bin gerade auf Gran Canaria angekommen :)
Hallo zusammen,
ich habe folgendes Problem: Bei mir funktioniert nur folgende Version der MQTT_GENERIC_BRIDGE korrekt:
version 0.9.9 by hexenmeister
$Id: 10_MQTT_GENERIC_BRIDGE.pm 17444 2018-09-30 21:30:54Z hexenmeister $
Bei aktuelleren Versionen (ich habe nur die Version vom 18.10.2018 per Update geholt) wird ein Teil der Devices nicht mehr gepublisht. Im nachfolgenden Listing der Bridge werden Devices wie Dodenhof_Diesel oder buderus_kessel korrekt zum Broker gesendet, myLaCrosseGateway1 (humidity, temperature) z.B. jedoch nicht.
List von MQTT_GENERIC_BRIDGE:
Internals:
DEF mqtt Dodenhof_Diesel,Dodenhof_Super,Ottersberg_Diesel,Fischerhude_Diesel,HMS100T_a4aa,ku_hms100tf,myLaCrosseGateway1,nico_hms100t,denise_hms100tf,myLuftsensor,buderus_kessel,bo_licht_mitte,wz_li_mitte,wz_li_kamin,wz_schrank,wz_li_fluter,wz_li_lesen,wz_steckdose1,schlafen_hms100tf,tempGefrierschrank
IODev myMQTT
NAME mqttGeneric
NR 309
NTFY_ORDER 50-mqttGeneric
STATE dev: 20 in: 429 out: 616
TYPE MQTT_GENERIC_BRIDGE
devspec Dodenhof_Diesel,Dodenhof_Super,Ottersberg_Diesel,Fischerhude_Diesel,HMS100T_a4aa,ku_hms100tf,myLaCrosseGateway1,nico_hms100t,denise_hms100tf,myLuftsensor,buderus_kessel,bo_licht_mitte,wz_li_mitte,wz_li_kamin,wz_schrank,wz_li_fluter,wz_li_lesen,wz_steckdose1,schlafen_hms100tf,tempGefrierschrank
prefix mqtt
READINGS:
2018-10-27 13:53:36 device-count 20
2018-10-27 14:30:20 incoming-count 429
2018-10-27 14:31:24 outgoing-count 616
2018-10-27 14:31:24 transmission-state outgoing publish sent
2018-10-27 00:00:58 updated-reading-count 0
2018-10-27 14:30:20 updated-set-count 429
devices:
Dodenhof_Diesel:
:publish:
Diesel:
last 1540643478.06555
mode R
topic {"/SmartHome/$device/$reading"}
Dodenhof_Super:
:publish:
Super:
last 1540643478.01182
mode R
topic {"/SmartHome/$device/$reading"}
Fischerhude_Diesel:
:publish:
Diesel:
last 1540643484.18966
mode R
topic {"/SmartHome/$device/$reading"}
HMS100T_a4aa:
:defaults:
pub:base {"/SmartHome/$device/$reading"}
sub:base {"/SmartHome/$device/$reading"}
:publish:
batteryState:
mode R
topic {"$base"}
temperature:
last 1540643157.34209
mode R
topic {"$base"}
Ottersberg_Diesel:
:publish:
Diesel:
last 1540643484.41082
mode R
topic {"/SmartHome/$device/$reading"}
bo_licht_mitte:
:publish:
state:
last 1540627877.95304
mode R
topic {"/SmartHome/$device/get"}
:subscribe:
HASH(0x45548d8)
buderus_kessel:
:publish:
/system/sensors/temperatures/outdoor_t1:
last 1540643283.6315
mode R
topic {"/SmartHome/$device/$reading"}
denise_hms100tf:
:publish:
*:
mode R
topic {"/SmartHome/$device/$reading"}
ku_hms100tf:
:publish:
*:
mode R
topic {"/SmartHome/$device/$reading"}
myLaCrosseGateway1:
:publish:
*:
mode R
topic {"/SmartHome/$device/$reading"}
myLuftsensor:
:publish:
*:
mode R
topic {"/SmartHome/$device/$reading"}
nico_hms100t:
:publish:
*:
mode R
topic {"/SmartHome/$device/$reading"}
schlafen_hms100tf:
:publish:
*:
mode R
topic {"/SmartHome/$device/$reading"}
tempGefrierschrank:
:subscribe:
HASH(0x456b080)
wz_li_fluter:
:publish:
state:
mode R
topic {"/SmartHome/$device/get"}
:subscribe:
HASH(0x4554848)
wz_li_kamin:
:publish:
*:
mode R
topic {"/SmartHome/$device/get"}
:subscribe:
HASH(0x4554740)
wz_li_lesen:
:publish:
state:
mode R
topic {"/SmartHome/$device/get"}
:subscribe:
HASH(0x4554818)
wz_li_mitte:
:publish:
state:
mode R
topic {"/SmartHome/$device/get"}
:subscribe:
HASH(0x456aa20)
wz_schrank:
:publish:
state:
last 1540622856.11358
mode R
topic {"/SmartHome/$device/get"}
:subscribe:
HASH(0x456a858)
wz_steckdose1:
:publish:
state:
mode R
topic {"/SmartHome/$device/get"}
:subscribe:
HASH(0x456ae58)
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 *
message_ids:
subscribe:
/SmartHome/bo_licht_mitte/set
/SmartHome/wz_li_mitte/set
/Esp1wire@14211345/28.ff9b3b811402.f1/Temperature
/SmartHome/wz_schrank/set
/SmartHome/wz_li_fluter/set
/SmartHome/wz_steckdose1/set
/SmartHome/wz_li_kamin/set
/SmartHome/wz_li_lesen/set
subscribeExpr:
^\/SmartHome\/bo_licht_mitte\/set$
^\/SmartHome\/wz_li_mitte\/set$
^\/Esp1wire@14211345\/28.ff9b3b811402.f1\/Temperature$
^\/SmartHome\/wz_schrank\/set$
^\/SmartHome\/wz_li_fluter\/set$
^\/SmartHome\/wz_steckdose1\/set$
^\/SmartHome\/wz_li_kamin\/set$
^\/SmartHome\/wz_li_lesen\/set$
subscribeQos:
/Esp1wire@14211345/28.ff9b3b811402.f1/Temperature 0
/SmartHome/bo_licht_mitte/set 0
/SmartHome/wz_li_fluter/set 0
/SmartHome/wz_li_kamin/set 0
/SmartHome/wz_li_lesen/set 0
/SmartHome/wz_li_mitte/set 0
/SmartHome/wz_schrank/set 0
/SmartHome/wz_steckdose1/set 0
Attributes:
DbLogExclude .*
IODev myMQTT
room 40_keller
stateFormat dev: device-count in: incoming-count out: outgoing-count
verbose 0
List myLaCrosseGateway1:
Internals:
Clients :PCA301:EC3000:LaCrosse:Level:EMT7110:KeyValueProtocol:CapacitiveLevel
DEF 192.168.48.33:81
DeviceName 192.168.48.33:81
FD 22
NAME myLaCrosseGateway1
NR 212
NTFY_ORDER 50-myLaCrosseGateway1
PARTIAL
RAWMSG OK VALUES LGW 14558639 UpTimeSeconds=3621,UpTimeText=0Tg. 1Std. 0Min. 21Sek. ,WIFI=WLAN1,ReceivedFrames=82,FramesPerMinute=3,RSSI=-78,FreeHeap=16400,LD.Min=0.37,LD.Avg=0.41,LD.Max=32.92,OLED=none
STATE initialized
TIMEOUT 0.5
TYPE LaCrosseGateway
model LaCrosseITPlusReader.Gateway.1.30
myLaCrosseGateway1_MSGCNT 11652
myLaCrosseGateway1_TIME 2018-10-27 14:33:28
nextOpenDelay 2
settings (1=RFM69 f:868960 r:6631) + DHT22 + SC16IS750 (0x90) {IP=192.168.48.33}]
Helper:
DBLOG:
humidity:
myDbLog:
TIME 1540643531.67819
VALUE 43
state:
myDbLog:
TIME 1540641185.0626
VALUE initialized
temperature:
myDbLog:
TIME 1540643531.67819
VALUE 21.6
MatchList:
1:PCA301 ^\S+\s+24
2:EC3000 ^\S+\s+22
3:LaCrosse ^(\S+\s+9 |OK\sWS\s)
4:EMT7110 ^OK\sEMT7110\s
5:Level ^OK\sLS\s
6:KeyValueProtocol ^OK\sVALUES\s
7:CapacitiveLevel ^OK\sCL\s
READINGS:
2018-10-27 14:33:21 humidity 43
2018-10-27 14:33:28 state initialized
2018-10-27 14:33:21 temperature 21.6
helper:
Attributes:
event-on-change-reading .*
initCommands 1,868960,120i v
mode WiFi
mqttPublish *:topic={"/SmartHome/$device/$reading"}
ownSensors both
room 01_wohnzimmer,PCA301
timeout 120, 30
usbFlashCommand ./FHEM/firmware/esptool.py -b 57600 -p [PORT] write_flash -ff 80m -fm dio -fs 4MB-c1 0x00000 [BINFILE] > [LOGFILE]
userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
verbose 0
Woran kann es liegen?
Grüße
Rainer
Seit dem update am 20 Oktober funktionieren meine Sensoren nicht mehr
ein zurückspielen der alten Version behebt das Problem
Ein Beispiel wie meine Sensoren so definiert sind
Readings werden nicht mehr aktualisiert.
Internals:
DEF 158d00022fddda weather.v1 xiaomi_gateway
IODev xiaomi_gateway
LASTInputDev xiaomi_gateway
MODEL weather.v1
MSGCNT 1030
NAME aussen_wetterstation
NR 206
SID 158d00022fddda
STATE 3.31 °C, 88.80 %, 96.21 kPa
TYPE XiaomiSmartHome_Device
VERSION 1.33
xiaomi_gateway_MSGCNT 1030
xiaomi_gateway_TIME 2018-10-28 09:20:46
READINGS:
2018-10-28 09:18:45 batteryState ok
2018-10-28 09:18:45 batteryVoltage 3.0
2018-10-28 09:18:45 heartbeat 158d00022fddda
2018-10-28 09:20:46 humidity 88.80
2018-10-28 09:20:46 pressure 96.21
2018-10-28 09:20:46 temperature 3.31
Attributes:
mqttPublish *:topic={"/sensor/balkon/$reading"}
room MiSmartHome
stateFormat temperature °C, humidity %, pressure kPa
Internals:
IODev Mosquito
NAME mqtt_device_balkon_pressure
NR 816
STATE 96.21
TYPE MQTT_DEVICE
.attraggr:
.attrminint:
.qos:
* 0
.retain:
* 0
READINGS:
2018-10-28 09:20:46 absFeuchte 5.4
2018-10-28 09:20:46 dewpoint 1.6
2018-10-28 09:20:46 humidity 88.80
2018-10-28 09:20:46 pressure 96.21
2018-10-28 09:20:46 temperature 3.31
2018-10-28 09:20:46 transmission-state incoming publish received
message_ids:
sets:
subscribe:
/sensor/balkon/battery_level
/sensor/balkon/humidity
/sensor/balkon/pressure
/sensor/balkon/pressure/state
/sensor/balkon/temperature
subscribeExpr:
^\/sensor\/balkon\/battery_level$
^\/sensor\/balkon\/humidity$
^\/sensor\/balkon\/pressure$
^\/sensor\/balkon\/pressure\/state$
^\/sensor\/balkon\/temperature$
subscribeQos:
/sensor/balkon/battery_level 0
/sensor/balkon/humidity 0
/sensor/balkon/pressure 0
/sensor/balkon/pressure/state 0
/sensor/balkon/temperature 0
subscribeReadings:
/sensor/balkon/battery_level:
cmd
name battery_level
/sensor/balkon/humidity:
cmd
name humidity
/sensor/balkon/pressure:
cmd
name pressure
/sensor/balkon/pressure/state:
cmd
name state
/sensor/balkon/temperature:
cmd
name temperature
Attributes:
DbLogExclude .*
IODev Mosquito
icon mqtt_device
room Mqtt
stateFormat pressure
subscribeReading_battery_level /sensor/balkon/battery_level
subscribeReading_humidity /sensor/balkon/humidity
subscribeReading_pressure /sensor/balkon/pressure
subscribeReading_state /sensor/balkon/pressure/state
subscribeReading_temperature /sensor/balkon/temperature
und mit dummy
Internals:
.lastTimeabsFeuchte 1540714834.16896
.lastTimedewpoint 1540715459.8091
.lastTimehumidity 1540715630.66208
.lastTimestate 1540715459.78608
DEF 20
IODev myJeeLink
LASTInputDev myJeeLink
LaCrosse_lastRcv 2018-10-28 09:34:13
MSGCNT 730
NAME sensor_wetterstation
NR 787
STATE T: 2.2 H: 1
TYPE LaCrosse
addr 20
battery_new 0
bufferedH 1
bufferedT 2.2
corr1 0
corr2 0
myJeeLink_MSGCNT 730
myJeeLink_RAWMSG OK WS 32 1 255 255 255 0 0 1 194 0 21 255 255 0
myJeeLink_TIME 2018-10-28 09:34:13
previousH 1
previousR 0
previousT 2.2
sensorType 1=TX22
.attraggr:
.attreocr:
.*
.attrminint:
humidity:300
temperatur:800
dewpoint:3600
state:800
absFeuchte:800
Helper:
DBLOG:
humidity:
logdb:
TIME 1540715630.70721
VALUE 1
temperature:
logdb:
TIME 1540715459.82841
VALUE 2.2
READINGS:
2018-10-28 09:33:50 absFeuchte 0.1
2018-10-28 09:34:13 battery ok
2018-10-28 09:33:50 dewpoint -49.0
2018-10-28 09:34:13 error 0
2018-10-28 09:34:13 humidity 1
2018-10-28 09:34:13 rain 0
2018-10-28 08:59:55 statDewpointTendency 1h: -37.7 2h: -37.7 3h: -37.7 6h: -37.7
2018-10-28 08:59:55 statHumidityTendency 1h: -1 2h: -1 3h: -1 6h: -1
2018-10-28 09:34:13 statRain Hour: 0.0 Day: 0.0 Month: 0.0 Year: 0.0
2018-10-28 08:59:55 statRainLast Hour: 0.0 Day: 0.0 Month: 0.0 Year: - (since: )
2018-10-28 08:59:55 statTemperatureTendency 1h: +0.7 2h: +1.0 3h: -0.1 6h: -1.6
2018-10-28 09:30:59 state T: 2.2 H: 1
2018-10-28 09:34:13 temperature 2.2
2018-10-28 09:34:13 windDirectionDegree 45
2018-10-28 09:34:13 windDirectionText NE
2018-10-28 09:34:08 windGust 5.5
2018-10-28 09:34:13 windSpeed 2.1
helper:
_98_statistics statistic.geraete
Attributes:
DbLogExclude .*
DbLogInclude temperature:3600,humidity:3600
IODev myJeeLink
alexaName aussentemperatur,aussen temperatur,draussen,terasse
alias wetterstation
event-min-interval humidity:300,temperatur:800,,dewpoint:3600,state:800,absFeuchte:800
event-on-change-reading .*
genericDeviceType thermometer
group aussentemp
homebridgeMapping clear CurrentRelativeHumidity=humidity CurrentTemperature=temperature
icon temperature_humidity
mqttPublish *:topic={"sensor/balkon/$reading"}
room Alexa,LaCrosse
Internals:
NAME wetterstation
NR 193
STATE 2.2
TYPE dummy
READINGS:
2018-10-28 09:20:34 absFeuchte 0.1
2018-10-28 09:31:00 dewpoint -49.0
2018-10-28 09:33:50 humidity 1
2018-10-28 08:59:55 statDewpointTendency 1h: -37.7 2h: -37.7 3h: -37.7 6h: -37.7
2018-10-28 08:59:55 statHumidityTendency 1h: -1 2h: -1 3h: -1 6h: -1
2018-10-28 08:59:55 statTemperatureTendency 1h: +0.7 2h: +1.0 3h: -0.1 6h: -1.6
2018-10-28 09:31:00 state T: 2.2 H: 1
2018-10-28 09:31:00 temperature 2.2
2018-10-28 09:34:13 windDirectionDegree 45
2018-10-28 09:34:13 windDirectionText NE
2018-10-28 09:34:08 windGust 5.5
2018-10-28 09:34:08 windSpeed 2.1
Attributes:
mqttDefaults base=sensor/keller
mqttSubscribe *:topic={"sensor/balkon/$reading"}
readingList temperature dewpoint humidity windspeed rain
room MQTT
stateFormat temperature
Ich habe auch das Problem, dass ein Device nicht publisht.
version 0.9.9 by hexenmeister
$Id: 10_MQTT_GENERIC_BRIDGE.pm 17564 2018-10-18 20:28:34Z hexenmeister $
define SzYeelight YeeLight 192.168.178.84
attr SzYeelight devStateIcon {my $power=ReadingsVal($name,"power","off");;my $mode=ReadingsVal($name,"color_mode","RGB");;if($power eq "off"){Color::devStateIcon($name,"rgb","rgb","power");;}else{if($mode eq "RGB"){Color::devStateIcon($name,"rgb","rgb","bright");;}elsif($mode eq "color temperature"){Color::devStateIcon($name,"rgb",undef,"bright");;}}}
attr SzYeelight group Licht
attr SzYeelight mqttForward all
attr SzYeelight mqttPublish rgb|bright|ct|power|state:topic={"stat/$device/$reading"} rgb|bright|ct|power|state:retain=1
attr SzYeelight mqttSubscribe rgb|bright|ct|power:stopic={"cmnd/$device/$reading"}
attr SzYeelight room Schlafzimmer
attr SzYeelight webCmd rgb:bright:ct:rgb ffffff:rgb ff0000:rgb 00ff00:rgb 0000ff:on:off
attr SzYeelight widgetOverride bright:colorpicker,BRI,0,1,100 ct:colorpicker,CT,1700,10,6500 rgb:colorpicker,RGB
Versucht mal die Publishs zu löschen und erneut hinzufügen.
Ich war mir nicht sicher, ob ich bei mal mal einen Fehler drin hatte oder ob das reine entfernen und neu adden reichte. :-)
Bei mir reicht es die Version vom 30.09. einzuspielen und ein reload auf das Modul zu machen. Das Publishing startet umgehend.
Grüße
Rainer
Bei mir geht ebenso alles mit der Version vom 18.10..
Hallo zusammen,
bin wieder zurück nach längeren Abwesenheit.
Ich schaue mir die gemeldeten Probleme nach und nach an.
Grüße
Alexander
Zitat von: Master_Nick am 31 Oktober 2018, 21:44:47
Versucht mal die Publishs zu löschen und erneut hinzufügen.
bringt keine Besserung.
Ich hab leider kein YeeLight &co. Mit Dummies lässt sich kein Problem nachvollziehen. Oder ich verstehe das Problem nicht. Ist Empfang das Problem, oder das Senden? Oder beides?
Ich habe beider angesprochenen Versionen vergliechen, ein Bug gefunden und gefixt (hat jedoch mit dem Problem eher nichts zu tun) und eigentlich keine Hinweise gesehen. Höchstens eine vermeintlich harmlose Änderung habe ich im Verdacht. Diese habe ich jetzt zurückgedreht und hänge die neue Version im Anhang an. Bitte testen. Falls das Problem weiterhin besteht, müssen wir es genauer beschreiben und mit Dummies nachtellen können.
Hallo hexenmeister,
die Version funktioniert bei mir nicht, die Werte temperature und humidity werden nicht an den Broker gesendet.
Was soll ich zur Verfügung stellen, damit man das nachvollziehen kann?
Grüße
Rainer
Oha! Ja, ich sehe, dass was kaputt ist, ich suche mal nach der Ursache.
Ich habe mir mal die beiden Module im Diff angesehen und habe dann eine Änderung nach der anderen wieder Rückgängig gemacht.
Als ich die Zeile 896
#my $defaultReadingMap = $publishMap->{'*'} if defined $publishMap;
einkommentiert habe und die Zeile 897
my $defaultReadingMap = $devMap->{':defaults'} if defined $publishMap;
auskommentiert habe, lief es bei mir.
Vielleicht hilft das.
Grüße
Rainer
Zitat von: hexenmeister am 04 November 2018, 16:25:20
Ich hab leider kein YeeLight &co. Mit Dummies lässt sich kein Problem nachvollziehen. Oder ich verstehe das Problem nicht. Ist Empfang das Problem, oder das Senden? Oder beides?
Ich habe beider angesprochenen Versionen vergliechen, ein Bug gefunden und gefixt (hat jedoch mit dem Problem eher nichts zu tun) und eigentlich keine Hinweise gesehen. Höchstens eine vermeintlich harmlose Änderung habe ich im Verdacht. Diese habe ich jetzt zurückgedreht und hänge die neue Version im Anhang an. Bitte testen. Falls das Problem weiterhin besteht, müssen wir es genauer beschreiben und mit Dummies nachtellen können.
nur das publishen ist ein Problem. Es wird einfach nicht raus geschrieben auf die eingestelten Topics. Das Empfangen geht.
Ich warte auf die nächste Testversion und werde dann testen.
Zitat von: ergerd am 04 November 2018, 18:24:53
Ich habe mir mal die beiden Module im Diff angesehen und habe dann eine Änderung nach der anderen wieder Rückgängig gemacht.
Als ich die Zeile 896
#my $defaultReadingMap = $publishMap->{'*'} if defined $publishMap;
einkommentiert habe und die Zeile 897
my $defaultReadingMap = $devMap->{':defaults'} if defined $publishMap;
auskommentiert habe, lief es bei mir.
Vielleicht hilft das.
Grüße
Rainer
TOP, Danke!
Nach der Änderung geht es bei mir auch wieder.
Alles was mit * gepublisht wird, scheint davon betroffen zu sein.
Das war eine überhastete Optimierungsorgie von mir >:(
Danke Rainer für die Fehlersuche!
Im Anhang die fehlerbereinigte Version, diese werde ich auch noch zeitnah einchecken.
meine Yeelight sendet auch mit der neue Version nix :(
Hallo hexenmeister,
habe die Version gerade eingespielt, sie läuft bei mir. Dann muss das Problem bei Phantomato noch ein anderes sein.
Ich habe leider kein Yeelight, so kann ich da wohl nicht unterstützen.
Danke und Grüße
Rainer
Also bei mir läuft es auch mit der neuen Version.
@ Phantomato hast du FHEM neu gestartet nachdem du die Datei kopiert hast?
Dann bin ich erstmal leider ratlos.
Ich habe dein Fall mit einem dummy, soweit es geht, nachgebaut und es funktioniert wie es soll. Alle Werte kommen an.
Probiere mal bitte aus, ob meine Bastelei bei dir auch nicht geht:
defmod test_SzYeelight dummy
attr test_SzYeelight devStateIcon {my $power=ReadingsVal($name,"power","off");;my $mode=ReadingsVal($name,"color_mode","RGB");;if($power eq "off"){Color::devStateIcon($name,"rgb","rgb","power");;}else{if($mode eq "RGB"){Color::devStateIcon($name,"rgb","rgb","bright");;}elsif($mode eq "color temperature"){Color::devStateIcon($name,"rgb",undef,"bright");;}}}
attr test_SzYeelight group Licht
attr test_SzYeelight mqttPublish rgb|bright|ct|power|state:topic={"stat/$device/$reading"} rgb|bright|ct|power|state:retain=0
attr test_SzYeelight mqttSubscribe rgb|bright|ct|power:stopic={"cmnd/$device/$reading"}
attr test_SzYeelight readingList rgb bright ct power
attr test_SzYeelight room TEST_Reported
attr test_SzYeelight webCmd rgb:bright:ct:rgb ffffff:rgb ff0000:rgb 00ff00:rgb 0000ff:on:off
attr test_SzYeelight widgetOverride bright:colorpicker,BRI,0,1,100 ct:colorpicker,CT,1700,10,6500 rgb:colorpicker,RGB
Zitat von: SamNitro am 04 November 2018, 21:36:03
@ Phantomato hast du FHEM neu gestartet nachdem du die Datei kopiert hast?
ja hatte ich, hauptsächlich "reload 10_MQTT_GENERIC_BRIDGE.pm" (Befehl stimmt oder?) als auch ein "shutdown restart" (keine Ahnung zu welchen Zeitpunkt). Die Datei hatte ich nach "opt/fhem/FHEM" kopiert. War auch der Meinung, dass die Rechte stimmen würde.
Dann den Dummy von Hexenmeister ausprobiert. Ging auch nicht. Also nochmal "update" & "shutdown restart". Und siehe da es läuft. :D :D :D
Keine Ahnung was sich quer gestellt hat aber jetzt tuts 8)
Ist auch egel, Hauptsache, es läuft :)
Bin heute endlich dazu gekommen, JSON-Unterstützung für Subscribe anzusehen.
Wie ich es schon vermutet habe, kann diese leicht mit Hilfe von "expression" in mqttSubscribe realisiert werden. 8)
Eine kleine Modifikation im Code machte das noch etwas einfacher und hier ist ein Beispiel für funktionierende Konfiguration:
json:topic=/TEST/json json:expression={json2nameValue($message)}
Sendet man jetzt z.B. folgende JSON: {"jtest1":"jval1","jtest2":"jval2"} dann werden zwei Readings (jtest1 und jtest2) entsprechend angelegt/aktualisiert.
Jetzt mache ich mich an die Unterstützung von MQTT2 :)
Zitat von: hexenmeister am 11 November 2018, 23:18:54
Bin heute endlich dazu gekommen, JSON-Unterstützung für Subscribe anzusehen.
Wie ich es schon vermutet habe, kann diese leicht mit Hilfe von "expression" in mqttSubscribe realisiert werden. 8)
Eine kleine Modifikation im Code machte das noch etwas einfacher und hier ist ein Beispiel für funktionierende Konfiguration:
json:topic=/TEST/json json:expression={json2nameValue($message)}
Sendet man jetzt z.B. folgende JSON: {"jtest1":"jval1","jtest2":"jval2"} dann werden zwei Readings (jtest1 und jtest2) entsprechend angelegt/aktualisiert.
Bin mal wieder am testen.
Kannst du mir da auf die Sprünge helfen?
Mein Sonoff POW sendet in Json für das Reading ENERGY folgendes.
{"Time":"2018-11-12T17:20:41","ENERGY":{"Total":0.061,"Yesterday":0.002,"Today":0.002,"Period":0,"Power":7,"Factor":0.39,"Voltage":225,"Current":0.080}}Wie muss ich das JSON auflösen? Wobei mich das nur ab "ENERGY": interessiert.
Komme mit deinem Beispiel nicht zurecht. :'(
illy
Kannst genauso nehmen, wie es ist (nur Topic wäre noch anzupassen):
json:topic=/TEST/json json:expression={json2nameValue($message)}
Auswahl von Readings aus JSON ist derzeit nich möglich, werden alle genommen. Wäre das wichtig?
Zitat von: hexenmeister am 12 November 2018, 18:13:49
Kannst genauso nehmen, wie es ist (nur Topic wäre noch anzupassen):
json:topic=/TEST/json json:expression={json2nameValue($message)}
Auswahl von Readings aus JSON ist derzeit nich möglich, werden alle genommen. Wäre das wichtig?
So, hat funktioniert, aber leider nur 1 mal aufgelöst?
d.h. Während das Reading Energy --> "Time":"2018-11-12T19:56:20 refreshed,
passiert keine Json Auflösung mehr.
d.H. 2018-11-12 19:43:00 Zeitstempel bleibt stehen.
Siehe auch List:
Internals:
NAME myTest3
NR 134
STATE off
TYPE dummy
OLDREADINGS:
READINGS:
2018-11-12 19:56:21 ENERGY {"Time":"2018-11-12T19:56:20","ENERGY":{"Total":0.062,"Yesterday":0.002,"Today":0.004,"Power":0,"Factor":0.00,"Voltage":0,"Current":0.000}}
2018-11-12 19:43:00 ENERGY_Current 0.000
2018-11-12 19:43:00 ENERGY_Factor 0.00
2018-11-12 19:43:00 ENERGY_Power 0
2018-11-12 19:43:00 ENERGY_Today 0.004
2018-11-12 19:43:00 ENERGY_Total 0.062
2018-11-12 19:43:00 ENERGY_Voltage 0
2018-11-12 19:43:00 ENERGY_Yesterday 0.002
2018-11-12 19:43:00 Time 2018-11-12T19:42:59
2018-11-12 19:56:53 state OFF
Attributes:
devStateIcon on:black_Steckdose.on off:black_Steckdose.off
eventMap ON:on OFF:off
mqttPublish state:topic=cmnd/sonoff_pw2/POWER1
mqttSubscribe state:stopic=stat/sonoff_pw2/POWER1
ENERGY:topic=tele/sonoff_pw2/SENSOR json:expression={json2nameValue($message)}
room MQTT
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:offParallel mit MQTT2_CLIENT und MQTT2_DEVICE
sieht das so aus.
READINGS:
2018-11-12 20:06:00 ENERGY_Current 0.000
2018-11-12 20:06:00 ENERGY_Factor 0.00
2018-11-12 20:06:00 ENERGY_Period 0
2018-11-12 20:06:00 ENERGY_Power 0
2018-11-12 20:06:00 ENERGY_Today 0.004
2018-11-12 20:06:00 ENERGY_Total 0.062
2018-11-12 20:06:00 ENERGY_Voltage 0
2018-11-12 20:06:00 ENERGY_Yesterday 0.002
2018-11-12 19:56:53 POWER OFF
2018-11-12 20:06:00 Time 2018-11-12T20:06:00
2018-11-12 19:56:53 state OFFBilly
Ah! Ne, die Expression muss zu dem Topic-Namen gehören. Wenn schon "ENERGY:topic=tele/sonoff_pw2/SENSOR", dann auch "ENERGY:expression={json2nameValue($message)}"
P.S. und das eigentliche JSON-String wird gar nicht erst in einem Reading gespeichert.
Zitat von: hexenmeister am 12 November 2018, 20:14:17
Ah! Ne, die Expression muss zu dem Topic-Namen gehören. Wenn schon "ENERGY:topic=tele/sonoff_pw2/SENSOR", dann auch "ENERGY:expression={json2nameValue($message)}"
P.S. und das eigentliche JSON-String wird gar nicht erst in einem Reading gespeichert.
Top jetzt alles wie es soll! :)
ZitatAuswahl von Readings aus JSON ist derzeit nich möglich, werden alle genommen. Wäre das wichtig?
Muß nicht sein.
Danke jetzt werde ich wohl langsam die MQTT_GENERIC_BRIDGE auch auf meinen heißen Systemen implementieren. 8)
Ich experimentiere gerade wieder mit der MQTT_GENERIC_BRIDGE, da sie wirklich genial komfortabel in fhem integriert ist - und in der Hoffung auf baldige Unterstützung von TLS-geschützter Kommunikation mit einem externen MQTT-Broker ;).
Klappt soweit auch bestens, allerdings stelle ich gerade fest, dass auch ein HM-Device "mitpublished", obwohl es nicht in den Räumen definiert ist, die ich in der Bridge konfiguriert habe.
Die Brigde ist wie folgt konfiguriert:
defmod mqttGeneric MQTT_GENERIC_BRIDGE mqtt room=ZWave,room=EnOcean
attr mqttGeneric IODev mqtt_smartgulp2
attr mqttGeneric globalPublish *:topic={"fhempub/$device/$reading"}
attr mqttGeneric globalTypeExclude *:power
attr mqttGeneric icon mqtt_device
attr mqttGeneric room MQTT,Zentralen
Für die Geräte in den Räumen ZWave und EnOcean habe ich keine spezifische MQTT-Konfiguration vorgenommen.
Folgende Message fängt mein MQTT.fx auf:
fhempub/d_rpcBidCos_RF/No events from interface CB2001178072 for 600 seconds
Im Eventlog erscheint (schon vor Einrichtung der Brigde) folgende Mitteilung, welche ich auch als korrekt erachte, wenn ich für 10 Minuten keine HM-Devices bediene (habe nur zwei Funkschalter):
2018.11.15 10:32:09 2 : HMCCURPCPROC: [d_rpcBidCos_RF] Received no events from interface CB2001178072 for 600 seconds
[...]
2018.11.15 10:42:09 2 : HMCCURPCPROC: [d_rpcBidCos_RF] Received no events from interface CB2001178072 for 600 seconds
Dieses Device ist weder im Raum ZWave noch im Raum EnOcean hinterlegt. Die Definition sieht wie folgt aus:
defmod d_rpcBidCos_RF HMCCURPCPROC 192.168.178.231 BidCos-RF
attr d_rpcBidCos_RF alias CCU RPC BidCos-RF
attr d_rpcBidCos_RF eventMap /rpcserver on:on/rpcserver off:off/
attr d_rpcBidCos_RF icon cul_cul
attr d_rpcBidCos_RF room HomeMatic,Zentralen
attr d_rpcBidCos_RF stateFormat rpcstate/state
attr d_rpcBidCos_RF verbose 2
setstate d_rpcBidCos_RF running/OK
setstate d_rpcBidCos_RF 2018-11-15 09:12:09 rpcstate running
setstate d_rpcBidCos_RF 2018-11-15 09:12:09 state OK
Laut meinem Verständnis dürften die Nachrichten dieses Devices nicht via MQTT gepublished werden, oder?
Die TLS Unterstützung wird kommen, indem MQTT2_CLIENT als IODev unterstützt wird. Die erste Alpha-Version habe ich bereits, sie ist jedoch noch lange nicht einsatzfähig.
DevSpec, was man im define angeben kann, dient lediglich dazu, die entsprechenden Geräte mit userAttr-Einträgen auszustatten, damit man an den entsprechenen Geräten die mqtt*-Attribute konfigurieren kann. Du verwendest eine globale Publish-Funktion, sie schickt einfach alles weg, was nicht durch exclude ausgeschlossen ist.
Ich schreibe auf die 'Wunschliste' dein Anwendungsfall. Sollte sich durch eine Prüfung gegen devspec realisieren lassen. Bin mir jedoch noch nicht sicher, ob das eine gute Idee ist, kann an der anderen Seite zu Verwirrung führen (nach dem Motto, warum wird etwas NICHT gesendet).
Zitat von: hexenmeister am 15 November 2018, 11:18:27
DevSpec, was man im define angeben kann, dient lediglich dazu, die entsprechenden Geräte mit userAttr-Einträgen auszustatten, damit man an den entsprechenen Geräten die mqtt*-Attribute konfigurieren kann. Du verwendest eine globale Publish-Funktion, sie schickt einfach alles weg, was nicht durch exclude ausgeschlossen ist.
Ich schreibe auf die 'Wunschliste' dein Anwendungsfall. Sollte sich durch eine Prüfung gegen devspec realisieren lassen. Bin mir jedoch noch nicht sicher, ob das eine gute Idee ist, kann an der anderen Seite zu Verwirrung führen (nach dem Motto, warum wird etwas NICHT gesendet).
OK, das erklärt das Verhalten, Danke für die Erklärung.
Dennoch möchte ich zur Diskussion stellen, ob das von mir verstandene Verhalten nicht das sinnvollere wäre: Warum sollte die Bridge alle Geräte über MQTT anbinden, wenn ich per devspec spezifisch Gruppen angegeben habe?
Anders ausgedrückt: Ich möchte doch nur für diejenigen Geräte/Gruppen/Räume/... die mqtt-Attribute setzen können, an deren Überwachung ich interessiert bin.
Die Beschreibung in der commandref zur MQTT_GENERIC_BRIDGE liest sich für mich auch so, dass die Überwachung durch die devspec auf eine/mehrere bestimmte Gruppen begrenzt wird:
ZitatDer zweite Parameter ('devspec') erlaubt die Menge der zu ueberwachenden Geraeten zu begrenzen (sonst werden einfach alle ueberwacht, was jedoch Performance kosten kann). Beispiel fuer devspec: 'TYPE=dummy' oder 'dummy1,dummy2'. Bei kommaseparierten Liste duerfen keine Leerzeichen verwendet werden! s.a. devspec
und bei den Beispielen
Zitat
Bridge fuer alle Geraete in einem bestimmten Raum:
defmod mqttGeneric MQTT_GENERIC_BRIDGE mqtt room=Wohnzimmer
attr mqttGeneric IODev mqtt
Wie gesagt: Ich verstehe jetzt, wie es aktuell funktioniert und kann entsprechend alles Ungewünschte mit der Zeit, wenn die jeweiligen Messages versendet werden filtern, finde dieses Vorgehen aber fehleranfälliger, aufwendiger und weniger intuitiv.
Vielleicht kann ja auch jemand anderes ein Beispiel nennen, wo das aktuelle Verhalten notwendig ist - wie gesagt, sehe gerade keins und es ist immer einfach zu verstehen, wenn man den use case kennt. :)
Zitat von: hexenmeister am 15 November 2018, 11:18:27
Die TLS Unterstützung wird kommen, indem MQTT2_CLIENT als IODev unterstützt wird. Die erste Alpha-Version habe ich bereits, sie ist jedoch noch lange nicht einsatzfähig.
Da freue ich mich schon drauf! *
thumbsup*
ZitatKlappt soweit auch bestens, allerdings stelle ich gerade fest, dass auch ein HM-Device "mitpublished", obwohl es nicht in den Räumen definiert ist, die ich in der Bridge konfiguriert habe.
Habe jetzt so eine Prüfung hinterlegt (nur Geräte berücksichtigen, die zu dem DevSpec im DEF passen). Habe allerdings nur minimal getestet (eigentlich nur, ob überhaupt noch Nachrichten rausgehen). Werde heute einchecken. Bitte testen, ob das so wie gewünscht funktioniert.
Zu MQTT2 Unterstützung...
Werde heute eine Version einchecken, wo zumindest Empfangn von Nachrichten über MQTT2(CLIENT und SERVER) funktioniert. Muss noch gründlich getestet werden.
Habe zum Thema einen neuen Thread aufgemacht: https://forum.fhem.de/index.php/topic,93255.msg858912.html#msg858912
@Hexenmeister
Zitat von: hexenmeister am 11 November 2018, 23:18:54
Bin heute endlich dazu gekommen, JSON-Unterstützung für Subscribe anzusehen.
Wie ich es schon vermutet habe, kann diese leicht mit Hilfe von "expression" in mqttSubscribe realisiert werden. 8)
json:topic=/TEST/json json:expression={json2nameValue($message)}
In MQTT2_DEVICE ist in der Klammer
{ json2nameValue($EVENT) }Könnte man
{json2nameValue($message)} angleichen da beide Welten ja über MQTT_GENERIC_BRIDGE zusammenwachsen?
Gruß Billy
Könnte man natürlich, aber zu welchem Zweck? Ich sehe eigentlich keine Notwendigkeit sowohl die Bridge als auch MQTT2_DEVICE gleichzeitig zu verwenden. Bridge kann ja das andere komplett ersetzen und auch vice-versa. Die Frage ist nur, wie man es haben möchte. Ausserdem erscheint mir message an dieser Stelle treffender als EVENT.
Wenn natürlich eine gute Begründung existiert, lassen ich mich überzeugen.
Zitat von: hexenmeister am 16 November 2018, 09:05:14
Wenn natürlich eine gute Begründung existiert, lassen ich mich überzeugen.
Nur "same name for same thing".
Aber nicht wesentlich.
Zitat von: hexenmeister am 15 November 2018, 22:30:01
Habe jetzt so eine Prüfung hinterlegt (nur Geräte berücksichtigen, die zu dem DevSpec im DEF passen). Habe allerdings nur minimal getestet (eigentlich nur, ob überhaupt noch Nachrichten rausgehen). Werde heute einchecken. Bitte testen, ob das so wie gewünscht funktioniert.
Habe die Version jetzt getestet: Meine EnOcean, ZWave und HomeMatic Räume jeweils einzeln, zu zweit oder zu dritt in devspec eingebunden: Funktioniert einwandfrei! Die nicht definierten Klassen (Räume) werden nicht gepublished, so wie es sein soll. :)
Super vielen Dank für die fixe Implementierung!
Danke fürs Testen, das nimmt mir viel Arbeit ab :)
Zitat von: hexenmeister am 15 November 2018, 22:32:12
Zu MQTT2 Unterstützung...
Werde heute eine Version einchecken, wo zumindest Empfangn von Nachrichten über MQTT2(CLIENT und SERVER) funktioniert. Muss noch gründlich getestet werden.
Habe zum Thema einen neuen Thread aufgemacht: https://forum.fhem.de/index.php/topic,93255.msg858912.html#msg858912
Klasse! Komme erst später am Abend oder morgen früh zum Testen, werde das aber definitiv machen! Super Sache!
Zitat von: HomeAlone am 16 November 2018, 11:12:39
Klasse! Komme erst später am Abend oder morgen früh zum Testen, werde das aber definitiv machen! Super Sache!
Rudi hat netterweise ein paar Erweiterungen in die MQTT2* Module integriert. Ich vermute jedoch, dass erstmal mein Modul nichts mehr senden kann. Ich muss eine kleine Änderung durchführen, komme heute jedoch aller Voraussicht nach nicht mehr dazu. Kann also sein, dass nach dem Update morgen mein Modul mit mqtt2 ein-zwei Tage nicht richtig läuft.
Zitat von: hexenmeister am 11 November 2018, 23:18:54
Bin heute endlich dazu gekommen, JSON-Unterstützung für Subscribe anzusehen.
Wie ich es schon vermutet habe, kann diese leicht mit Hilfe von "expression" in mqttSubscribe realisiert werden. 8)
Eine kleine Modifikation im Code machte das noch etwas einfacher und hier ist ein Beispiel für funktionierende Konfiguration:
json:topic=/TEST/json json:expression={json2nameValue($message)}
Sendet man jetzt z.B. folgende JSON: {"jtest1":"jval1","jtest2":"jval2"} dann werden zwei Readings (jtest1 und jtest2) entsprechend angelegt/aktualisiert.
Jetzt mache ich mich an die Unterstützung von MQTT2 :)
Moin Alex,
grad gesehen, dass json schon drin ist. Funktioniert super. Danke dir.
Jetzt steht einem Ersetzen aller mqtt's gegen Generic_dummys nix mehr im Weg.
Jo, sollte alles funktionieren. Auch mit mqtt2. Melde dich, wenn etwas nicht funktioniert.
Binjetzt am implementieren der MQTT_GENERIC_BRIDGE auf meine Produktivsysteme.
Das sieht gut aus. :D sowohl mit IODev MQTT alsauch IODev MQTT2_CLIENT.
Mal eine Frage, was bringt eine Wechsel von IODev MQTT zu IODev MQTT2_CLIENT.
Welchen Vorteil hat das wenn ja alles über die MQTT_GENERIC_BRIDGE angebunden ist?
Gibt es auch Nachteile?
Im Moment ist mqtt2-client erst in der Entwicklung, kann also auch Probleme machen.
Umstellen würde ich persönlich im Moment nicht, funktioniert ja soweit. Erst bei einer Neuinstallation oder einem Servertausch hätte mqtt2-client Vorteile, da keine Perl-Komponenten erforderlich sind (cpan).
Zitat von: Billy am 20 November 2018, 11:25:16
Welchen Vorteil hat das wenn ja alles über die MQTT_GENERIC_BRIDGE angebunden ist?
Gibt es auch Nachteile?
Vorteile? Ein wenig Geschmachssache. Die Bridge erlaubt einfachere Konfiguration der MQTT-Bindings direkt in den jeweiligen Devices.
Nachteile sollte es nicht geben. Da die Bridge noch relativ neu ist, könnte es noch Bugs in bestimmten Situationen geben. Läuft jedoch bei mir schon länger in der produktiven Umgebung ohne Probleme.
Sorry, vielleicht habe ich mich missverständlich ausgedrückt. MQTT_GENERIC_BRIDGE ist für mich gesetzt!
Ich meinte welchen Vorteil bringt es die MQTT_GENERIC_BRIDGE an MQTT2_CLIENT anzubinden?
Oder ist es besser als IODev MQTT-Brooker zu belassen?
Solange es läuft, würde ich es so lassen.
Ist derzeit auch vermutlich die stabilste und performanteste Lösung. Der große Vorteil von mqtt2_client ist SSL-Unterstützung.
Zitat von: hexenmeister am 20 November 2018, 17:06:39
Solange es läuft, würde ich es so lassen.
Ist derzeit auch vermutlich die stabilste und performanteste Lösung. Der große Vorteil von mqtt2_client ist SSL-Unterstützung.
Danke, SSL-Unterstützung brauche ich z.Zt. nicht, also lasse ich es so. ;)
Zitat von: Beta-User am 20 November 2018, 11:36:58
Im Moment ist mqtt2-client erst in der Entwicklung, kann also auch Probleme machen.
Umstellen würde ich persönlich im Moment nicht, funktioniert ja soweit. Erst bei einer Neuinstallation oder einem Servertausch hätte mqtt2-client Vorteile, da keine Perl-Komponenten erforderlich sind (cpan).
MQTT2_CLIENT hat den entscheidenden Vorteil, dass die Kommunikation mit dem MQTT-Server TLS-verschlüsselt ablaufen kann. Wenn Du also den mosquitto nicht lokal auf dem fhem Server aufgesetzt und die Kommunikation in Mosquitto auf localhost beschränkt hast, ist die Verwendung von MQTT aus Sicherheitsgründen meiner Meinung nach in Produktivsystemen nicht empfehlenswert.
Allerdings kommt es bei mir (und anderen auch) aktuell zu Verbindungsproblemen mit dem MQTT2_CLIENT.
Hallo hexenmeister,
ich bin deinem Aufruf (https://forum.fhem.de/index.php/topic,93642.msg863166.html#msg863166) gefolgt und beschäftige mich eben mit. MQTT_GENERIC_BRIDGE
Weniger ist mehr ;-)
Deinem Beispiel folgend habe ich einen Dummy angelegt.
Internals:
CFGFN
LASTInputDev mqtt2_server
MSGCNT 49
NAME s2xdummy
NR 5945
STATE on
TYPE dummy
mqtt2_server_MSGCNT 49
mqtt2_server_TIME 2018-11-27 19:31:26
OLDREADINGS:
READINGS:
2018-11-27 19:31:26 select ON
2018-11-27 19:31:26 state ON
Attributes:
DbLogExclude .*
eventMap ON:on OFF:off
mqttPublish state|select:topic=cmnd/teststecki1/POWER
mqttSubscribe state|select:topic=stat/teststecki1/POWER
readingList select
room MQTT
webCmd on:off
"state"reagiert schön, auf das externe Schalten am Sonoff-Gerät.
Aber eine Frage habe ich, angenommen das zu schaltende Gerät ist aus, aber nicht erreichbar oder reagiert nicht.
Kann man "state" dann irgendwie abfangen und der Dummy bleibt dann weiterhin auf "off", wenn eben kein Feedback vom Sonoff zurückkommt?
Ich hoffe, ich konnte mich halbwegs verständlich ausdrücken?
Ich reagiere zwar per Notify auf den LWT eines jeden MQTT-Gerätes, aber meine Frau bekommt die Nachricht nicht, wenn dann der Schalter in Homekit einfach aus bleibt, wüsste sie, dass da was nicht stimmt.
btw:
Wenn schon ein MQTT2_DEVICE auf dem Topic lauscht, kommt am Dummy nichts mehr an, richtig?
Schöne Grüße,
Patrick
Zitat von: hexenmeister am 11 November 2018, 23:18:54
Bin heute endlich dazu gekommen, JSON-Unterstützung für Subscribe anzusehen.
Wie ich es schon vermutet habe, kann diese leicht mit Hilfe von "expression" in mqttSubscribe realisiert werden. 8)
Eine kleine Modifikation im Code machte das noch etwas einfacher und hier ist ein Beispiel für funktionierende Konfiguration:
json:topic=/TEST/json json:expression={json2nameValue($message)}
Sendet man jetzt z.B. folgende JSON: {"jtest1":"jval1","jtest2":"jval2"} dann werden zwei Readings (jtest1 und jtest2) entsprechend angelegt/aktualisiert.
Jetzt mache ich mich an die Unterstützung von MQTT2 :)
Gibt es hier auch Unterstützung in der anderen Richtung? Also Versenden eines JSON-Objektes (oder JSON-Strings) bei einem Publish?
Hintergrund ist, dass andere Services, wie z.B. Zigbee2MQTT einen JSON-String oder ein komplettes JSON-Objekt publishen. JSON-Strings oder JSON-Objekte lassen sich in fast allen Systemen einfach abfragen / erweitern (in meinem konkreten Fall: Node-Red). Aktuell bekomme ich von Node-Red, wenn ich die von fhem gepublishten Messages verarbeiten will, einen Syntaxfehler gemeldet.
Ich habe jetzt einmal zu Fuß probiert, beim publishen einen JSON-String zu erzeugen, scheitere aber daran, etwas JSON-mäßiges zu bekommen, da ich laut commandref lediglich auf readings zurückgreifen darf:
(Format: <reading>:topic=<topic>)Was ich gerne würde, wäre etwas in der Art wie folgt:
*:topic={"fhempub/$device"} payload":"{\"$name\":\"expression={"message: $value"}"}
(wobei ich auch hier nicht sicher bin, ob ich die Syntax von expression richtig verstanden habe, aber ich hoffe, es wird klar, was die Idee dahinter ist.
Im Endeffekt möchte ich einen JSON-String als Rückgabe bekommen, so in der Art:
{"topic":"fhempub/az_Fensterkontakt","payload":"{\"contact\":true}Das hätte den charmanten Vorteil, dass man den Payload geschickt noch um weitere Komponenten erweitern kann: Z.B. um eine Ergänzung des Raums, für den die Meldung gilt, oder die Art der Meldung (Bewegung/Licht/...)
Eventuell lässt sich das auch jetzt schon realisieren, ich verstehe aber aktuell nicht wie.
Zitat von: der-pw am 27 November 2018, 19:44:24
Deinem Beispiel folgend habe ich einen Dummy angelegt.
Internals:
CFGFN
LASTInputDev mqtt2_server
MSGCNT 49
NAME s2xdummy
NR 5945
STATE on
TYPE dummy
mqtt2_server_MSGCNT 49
mqtt2_server_TIME 2018-11-27 19:31:26
OLDREADINGS:
READINGS:
2018-11-27 19:31:26 select ON
2018-11-27 19:31:26 state ON
Attributes:
DbLogExclude .*
eventMap ON:on OFF:off
mqttPublish state|select:topic=cmnd/teststecki1/POWER
mqttSubscribe state|select:topic=stat/teststecki1/POWER
readingList select
room MQTT
webCmd on:off
"state"reagiert schön, auf das externe Schalten am Sonoff-Gerät.
Aber eine Frage habe ich, angenommen das zu schaltende Gerät ist aus, aber nicht erreichbar oder reagiert nicht.
Kann man "state" dann irgendwie abfangen und der Dummy bleibt dann weiterhin auf "off", wenn eben kein Feedback vom Sonoff zurückkommt?
Ich hoffe, ich konnte mich halbwegs verständlich ausdrücken?
Ich reagiere zwar per Notify auf den LWT eines jeden MQTT-Gerätes, aber meine Frau bekommt die Nachricht nicht, wenn dann der Schalter in Homekit einfach aus bleibt, wüsste sie, dass da was nicht stimmt.
Hm. Verstehe. Naja, die Bridge lauscht auf Änderung eines Readings und gibt diese weiter (und natürlich leitet auch eine MQTT Nachricht hinein). Die Änderung ist im Gerät also schon stattgefunden und kann durch die Bridge nicht unterbunden werden. Was man natürlich machen kann, ist die Readings zu trennen. Wenn man nicht mit 'set on', sondern mit 'set select on' arbeitet, dannwird 'state' auch nicht geändert, nur 'select'. Bei einer ankommender MQTT-Nachricht zieht dann auch state mit. Ansonsten könnte man mit 'expression' Arbeiten, sollte möglich sein. Muss ich ausprobieren. Die Idee ist dabei folgende: man setzt in expression den state auf 'set_on' oder so, sendet aber 'on' weiter. Irgendwie so. Commandref wird helfen ;)
Zitat von: der-pw am 27 November 2018, 19:44:24
btw:
Wenn schon ein MQTT2_DEVICE auf dem Topic lauscht, kommt am Dummy nichts mehr an, richtig?
Nein, sind völlig unabhängig voneinander. Mehrere Geräte (oder Readings in selben Gerät) können unabhängig auf die gleiche TOpics lauschen.
Auf "set select" zu schalten und auf "state" den Zustand zu validieren ist eine gute Idee!
ZitatNein, sind völlig unabhängig voneinander.
Dann muss ich nochmal gucken. Aktuell ist es so, sobald über autocreate ein MQTT2_DEVICE angeleget wird, dass auf den Topics lautsch, die ich auch im Dummy anlege, kommt das "subscribe" am Dummy nicht mehr an.
Wenn du mqtt2_client verwendest, dann könnte es sein, dass es da Wechselwirkungen gibt. Die mqtt2 Unterstützung ist noch recht neu. Müsste ich mal ansehen.
Wegen json Versand habe ich paar Ideen, wie man das bequem machen kann. Kommt noch, muss Zeit finden
Zitat von: hexenmeister am 28 November 2018, 17:16:55
Wenn du mqtt2_client verwendest, dann könnte es sein, dass es da Wechselwirkungen gibt. Die mqtt2 Unterstützung ist noch recht neu. Müsste ich mal ansehen.
Ich verwende MQTT2_DEVICE in Verbindung mit MQTT2_SERVER.
Wenn es das Zusammenspiel ebenfalls betrifft, sag bescheid, wenn ich irgendwie was testen soll. ;-)
Testen ist immer gut, ich stelle immer wieder fest, dass jeder seine eigene Anwendungsszenarien hat, die mir teilweise gar nicht einfallen würden :D
Wird evtl. etwas dauern - stecke leider beruflich wie privat voll im 'Jahresendstress'. >:(
Zitat von: hexenmeister am 28 November 2018, 17:18:03
Wegen json Versand habe ich paar Ideen, wie man das bequem machen kann. Kommt noch, muss Zeit finden
Passt, Dankeschön.
Heisst im Umkehrschluss dann leider auch, dass ich das von mir gewünschte Konstrukt (gültiges JSON-String / oder JSON-Objekt) aktuell auch nicht von Hand erzeugen kann, oder?
Zitat von: HomeAlone am 29 November 2018, 12:38:49
Heisst im Umkehrschluss dann leider auch, dass ich das von mir gewünschte Konstrukt (gültiges JSON-String / oder JSON-Objekt) aktuell auch nicht von Hand erzeugen kann, oder?
Das sollte gehen; früher hatte ich auch mal "normales" MQTT im Einsatz und manches an Sendestring dann mit "toJSON()" zusammengestrickt; das ging auch über 00_MQTT raus.
Startpunkte für Beispiele, die evtl. weiterhelfen: https://forum.fhem.de/index.php/topic,91394.msg839718.html#msg839718
Leider finde ich den Rest an funktionierenden Beispielen nicht mehr....
Gruß, Beta-User
Wird natürlich gehen. Z.B. könnte man mit einem userReading eine neue Reading aus anderen Readings so befüllen, dass dort JSON-String sntsteht. Die Bridge wird ihn, falls erwünscht, brav transportieren. Oder man nimmt 'expression' (s. Commandref zu der GenricBridge) und modifiziert ein zu übertragendes Reading-Inhalt 'on the fly'.
Zitat von: hexenmeister am 29 November 2018, 13:02:00
Wird natürlich gehen. Z.B. könnte man mit einem userReading eine neue Reading aus anderen Readings so befüllen, dass dort JSON-String sntsteht. Die Bridge wird ihn, falls erwünscht, brav transportieren. Oder man nimmt 'expression' (s. Commandref zu der GenricBridge) und modifiziert ein zu übertragendes Reading-Inhalt 'on the fly'.
Ich tue mich gerade schwer damit, eine JSON-konforme Message mit der MQTT_GENERIC_BRIDGE zu generieren.
Was ich möchte: Ich möchte einen JSON-konformen Output für die Message erhalten. Dieser soll so aufgebaut sein, dass das Topic einem bestimmten Präfix (fhempub/<Gerätename>) entspricht. In der Nachricht soll JSON-konform das Setting und dessen Wert als Paar übertragen werden. In plain MQTT würde das z.B. so aussehen: {"state":"on"}.
Zunächst ist mir aufgefallen, dass, wenn ich die Variable $base benutze, gar kein Output am Broker ankommt. Habe das mit den letzten beiden Beispielen von mqttPublish ausprobiert. Hier sollte entweder darauf hingewiesen werden, dass $base bei Verwendung dringend definiert sein muss oder aber $base sollte einfach durch einen Leerstring ersetzt werden, so dass ein $base/$name einfach nur als /$name aufgelöst wird. In der MQTT_GENERIC_BRIDGE habe ich lediglich
Weiter in meinen Versuchen. Ändere ich also das topic, bekomme ich auch Output, aber ich verstehe nicht, wie die Definition zum Output passt:
*:topic={"fhempub/$device/$name"} reading:expression={$value="message: $value"}Ich würde erwarten, dass in der Message nun der $value um den Text "message: " ergänzt wird - dies passiert aber nicht. Die Message ist weiterhin dim 0 oder dim 99. Ich hätte hier wie gesagt "message: dim 0" bzw. "message dim 99" erwartet.
Um zu überprüfen ob das "message: " nicht als Keyword zu interpretieren sei, habe ich sicherheitshalber wie folgt definiert:
*:topic={"fhempub/$device"} reading:expression={$value="message: $name/$value"}Aber auch hier bleibt die Message bei "dim 0" bzw "dim 99" wenn ich den Schalter betätige.
Da ich an dieser Stelle schon ein Verständnisproblem bzgl. der Syntax habe (oder vielleicht ist es ja auch ein Fehler ;) ) würde ich mich über eine Hilfestellung freuen.
Eine Syntax a la:
*:topic={"fhempub/$device"} message={"$name":"$value"}wäre für diesen Anwendungsfall toll - gerne aber auch anders, nur ich bekomme es auch nach vielem Herumprobieren leider nicht hin.
Schon einmal vielen Dank im Voraus für das Erhellen des aktuell tief schwarzen Dunkels...
Problem verstanden. Muss zuhause ausprobieren. Versuche heute dazu zu kommen. Bin ein wenig gestresst :o
$base Problem gelöst. Morgen per Update.
Den Rest schaue ich mir später (morgen?) an.
Zitat von: hexenmeister am 06 Dezember 2018, 22:56:29
$base Problem gelöst. Morgen per Update.
Habe es überprüft und jetzt werden auch messages bei nicht definiertem $base verschickt - das $base wird sinnigerweise durch einen Leerstring ersetzt. Danke schon mal dafür.
Zitat von: hexenmeister am 06 Dezember 2018, 22:56:29
Den Rest schaue ich mir später (morgen?) an.
Das wäre klasse! :)
Bei der weiteren Suche nach einer Lösung bin ich auf folgende Antwort von Dir in einem anderen Thread gestoßen:
https://forum.fhem.de/index.php/topic,93175.msg857755.html#msg857755
Das dortige Beispiel habe ich einmal auf das reading state angewandt:
state:topic={"fhempub/$device"} state:expression={"{\"$reading\":\"$value\"}"}und siehe da, ich bekomme für ein bestimmtes Reading (hier: state) die gewünschte Antwort als sauberes JSON-Objekt, das auch von Node-Red nicht mehr bemeckert wird.
Das klappt so auch wunderbar, wenn ich diesen Ausdruck in der Bridge unter globalPublish hinterlege.
In meiner Naivität, habe ich das Ganze veralgemeinern wollen:
*:topic={"fhempub/$device"} *:expression={"{\"$reading\":\"$value\"}"}Was aber leider nicht matched.
Aber ich bin schon mal wieder ein Stückchen weiter. :) Mühsam ernährt sich das Eichhörnchen... ;)
Bin bis Mittwoch im Ausland. Kann mich leider erst dann damit beschäftigen.
Ich denke ich erstelle eine Hilfsfunktion zum bequemen verpacken von Readings in json. Etwa sowas expression={tojson({"name" => "reading"}).
Zitat von: hexenmeister am 10 Dezember 2018, 21:30:27
Bin bis Mittwoch im Ausland. Kann mich leider erst dann damit beschäftigen.
Ich denke ich erstelle eine Hilfsfunktion zum bequemen verpacken von Readings in json. Etwa sowas expression={tojson({"name" => "reading"}).
Keine Eile - nur Ungeduld ;)
Habe mal ein wenig recherchiert: Es gibt bereits eine Perl-Library für JSON, die alle notwendigen Funktionen enthält: https://www.tutorialspoint.com/json/json_perl_example.htm
Die könntst Du vermutlich verwenden, um den Aufwand gering zu halten.
Eventuell könnte man die JSON-Funktionen global als Modul/Erweiterung/Library? in fhem zur Verfügung stellen. In einer ersten Version die Funktionen des Moduls 1:1 wrappen und dann um sinnvolle Funktionen erweitern - wie z.B. readings<->[JSON|JSON-String]. Dann müsste nicht jeder Modulentwickler das Rad neu erfinden.
Habe zudem gesehen, dass bereits an einigen Stellen teilweise Funktionaltitäten für JSON-Support geschaffen wurden, wenn ich das richtig sehe aber überwiegend im Rahmen zu bestimmten Modulen:
- expandJSON() -> https://forum.fhem.de/index.php?topic=69067.0 Wrappen der Werte eines JSON Strings in individuelle Readings
- toJSON() und Diskussion über Gegenpart dazu (der wohl auch schon in MQTT2_... implementiert ist?) -> https://forum.fhem.de/index.php/topic,90208.15.html
- JsonList2 aus der commandref -> https://fhem.de/commandref.html#JsonList2 -> Scheint spezifisch für irgendwelche Buderus Geräte zu sein?
- Und dann bin ich auf diesen Thread gestoßen -> https://forum.fhem.de/index.php/topic,90208.0.html der sich mit der Fragestellung beschäftigt, ob die Funktionen des Perl-Moduls für JSON oder native Implementierungen sinniger seien...
Ich könnte mir vorstellen, dass die Nutzung des Perl JSON-Moduls den geringsten Aufwand bedeutet.
Hoffe, ich konnte ein wenig Recherchearbeit abnehmen - beim Programmieren kann ich leider nicht so viel helfen. :(
Viele Grüße
Sascha
entsprechende Funktionalität gibt es bereits in fhem.pl und kann eig. genutzt werden. Es geht hier nur darum, die Verwendung möglichst einfach unf bequem zu gestallten.
Moin Alex, ich versuch grad mal meine Blocking Calls zu vermindern (mit perfmon und apptime). Hab schon viele Bösewichte abgesägt, aber aktuell ist mqtt bzw. MQTT Gen.Bri. mein größter Blocker mit häufig über 1s.
Bei mir kommen zwar so um die 30 incoming-counts in der Minute, aber das sollte ja nicht mqtt in fhem ausreizen. Liegt es vielleicht an dem json2Name?
Ich werde mal eine minimal-FHEM Instanz nehmen, dort die Bridge einrichten und nur 1 Gerät Messages hinschicken lassen. Und dann halt mit und ohne json Auswertung.
Hat jemand anders ähnliche Erfahrungen mit apptime gemacht? Ich bin mir allerdings auch nicht sicher, wie gut man apptime trauen kann bzw. ob es nicht manchmal mehr zu interpretieren gibt als man direkt sieht. Sowas wie nachgeschaltete Events.
EDIT: am json liegt es nicht. Im minimal FHEM braucht es Max 100ms
EDIT2: Hab mir das mal im Event Log angeschaut.
Ist es normal, dass das Verarbeiten von ca. 10 Reading 400ms braucht?
2018-12-14 17:43:44.805 MQTT_GENERIC_BRIDGE mqqtGB transmission-state: incoming publish received
2018-12-14 17:43:44.832 MQTT_GENERIC_BRIDGE mqqtGB incoming-count: 54
2018-12-14 17:43:44.845 dummy Swi_Heizung ENERGY_Current: 0.304
2018-12-14 17:43:44.857 MQTT_GENERIC_BRIDGE mqqtGB updated-reading-count: 426
2018-12-14 17:43:44.867 dummy Swi_Heizung ENERGY_TotalStartTime: 2018-11-22T15:23:08
2018-12-14 17:43:44.880 MQTT_GENERIC_BRIDGE mqqtGB updated-reading-count: 427
2018-12-14 17:43:44.890 dummy Swi_Heizung ENERGY_Voltage: 223
2018-12-14 17:43:44.902 MQTT_GENERIC_BRIDGE mqqtGB updated-reading-count: 428
2018-12-14 17:43:44.927 dummy Swi_Heizung ENERGY_Total: 73.867
2018-12-14 17:43:44.940 MQTT_GENERIC_BRIDGE mqqtGB updated-reading-count: 429
2018-12-14 17:43:44.949 dummy Swi_Heizung ENERGY_ApparentPower: 68
2018-12-14 17:43:44.962 MQTT_GENERIC_BRIDGE mqqtGB updated-reading-count: 430
2018-12-14 17:43:44.996 dummy Swi_Heizung ENERGY_Yesterday: 1.233
2018-12-14 17:43:45.011 MQTT_GENERIC_BRIDGE mqqtGB updated-reading-count: 431
2018-12-14 17:43:45.023 dummy Swi_Heizung ENERGY_Factor: 0.75
2018-12-14 17:43:45.037 MQTT_GENERIC_BRIDGE mqqtGB updated-reading-count: 432
2018-12-14 17:43:45.047 dummy Swi_Heizung Time: 2018-12-14T17:43:43
2018-12-14 17:43:45.060 MQTT_GENERIC_BRIDGE mqqtGB updated-reading-count: 433
2018-12-14 17:43:45.089 dummy Swi_Heizung ENERGY_Today: 0.899
2018-12-14 17:43:45.103 MQTT_GENERIC_BRIDGE mqqtGB updated-reading-count: 434
2018-12-14 17:43:45.113 dummy Swi_Heizung ENERGY_Period: 1
2018-12-14 17:43:45.126 MQTT_GENERIC_BRIDGE mqqtGB updated-reading-count: 435
2018-12-14 17:43:45.155 dummy Swi_Heizung ENERGY_Power: 51
2018-12-14 17:43:45.168 MQTT_GENERIC_BRIDGE mqqtGB updated-reading-count: 436
2018-12-14 17:43:45.179 dummy Swi_Heizung ENERGY_ReactivePower: 45
2018-12-14 17:43:45.192 MQTT_GENERIC_BRIDGE mqqtGB updated-reading-count: 437
Kämpfe gerade mit MQTT_GENERIC_BRIDG,
habe es mit:
defmod mqttGeneric MQTT_GENERIC_BRIDGE Mqtg
attr mqttGeneric IODEV myBroker
angelegt.
Device-List:
Internals:
CFGFN
DEF Mqtg
IODev myBroker
NAME mqttGeneric
NR 171
NTFY_ORDER 50-mqttGeneric
STATE ???
TYPE MQTT_GENERIC_BRIDGE
devspec .*
prefix Mqtg
Helper:
DBLOG:
device-count:
DBLogging:
TIME 1544794672.56157
VALUE 0
transmission-state:
DBLogging:
TIME 1544794672.60464
VALUE IO device initialized (mqtt)
READINGS:
2018-12-14 14:37:52 device-count 0
2018-12-14 14:37:15 incoming-count 0
2018-12-14 14:37:15 outgoing-count 0
2018-12-14 14:37:52 transmission-state IO device initialized (mqtt)
2018-12-14 14:37:15 updated-reading-count 0
2018-12-14 14:37:15 updated-set-count 0
devices:
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:
subscribeExpr:
subscribeQos:
Attributes:
IODev myBroker
myBroker ist eine MQTT-Serverinstanz auf dem Raspberry. Die läuft auch. Hab auch einige MQTT-Devices im Fhem laufen.
Müsste nicht MQTT_GENERIC_BRIDGE jetzt selbständig relevante Devices 'einsammeln' und in seine Readings (Counter) anzegen?
Oder verstehe ich das Modul falsch?
Bevor ich jetzt ein 3. edit aufmache.
Hab mir das nochmal in Ruhe angeschaut und mit dem json2... braucht das Auswerten grob 400ms.
Nehme ich expandjson schafft FHEM es unter 100ms
Zitat von: Fuchsbau am 14 Dezember 2018, 15:58:06
Müsste nicht MQTT_GENERIC_BRIDGE jetzt selbständig relevante Devices 'einsammeln' und in seine Readings (Counter) anzegen?
Oder verstehe ich das Modul falsch?
Due Bridge sammelt nichts selbständig, sondern stellt in den Devices einige zusätzliche Attribute, mit deren Hilfe die MQTT-Transport konfiguriert werden kann. Erst dann werden diese gezählt. Steht alles in Commandref beschrieben.
Also 10 Readings alleine zu aktualisieren ist nicht die Welt, auch 30 pro minute ist gar nichts. Ich habe mehr Last, ohne 'Hänger'. Allerding verwende bischer JSON fast gar nicht. Ich denke, das Problem liegt genau daran. Ich sehe zwei Lösungsansätze: 1. die performantere JSON-Implementierung suchen/wählen uind 2. Parsen von JSON als 'BlockingCall' implementieren. Lösung 2 ist programmiertechnisch etwas auwendiger.
Ich werde Zeit suchen, mit eine JSON-Infrastruktur zum Testen aufzubauen. Irgendwo liegt sogar ein neuer Sonoff, den ich bestellt aber nie verwendet hatte.
Zitat von: hexenmeister am 14 Dezember 2018, 22:41:34
Also 10 Readings alleine zu aktualisieren ist nicht die Welt, auch 30 pro minute ist gar nichts. Ich habe mehr Last, ohne 'Hänger'. Allerding verwende bischer JSON fast gar nicht. Ich denke, das Problem liegt genau daran. Ich sehe zwei Lösungsansätze: 1. die performantere JSON-Implementierung suchen/wählen uind 2. Parsen von JSON als 'BlockingCall' implementieren. Lösung 2 ist programmiertechnisch etwas auwendiger.
Ich werde Zeit suchen, mit eine JSON-Infrastruktur zum Testen aufzubauen. Irgendwo liegt sogar ein neuer Sonoff, den ich bestellt aber nie verwendet hatte.
Genieß lieber die Feiertage. ;)
Ich werde erstmal wieder zurück auf expandjson gehen.
Hab jetzt mal die längeren jsons umgestellt und komme in apptime auf ein average von grob 100 statt 400. Das deckt sich ja auch ganz gut mit meinen Event Monitor Forschungen.
EDIT: Ich seh grad, dafür braucht ej3 jetzt 60ms avg.
Ist zusammen allerdings immer noch unter 200ms
Guten Morgen, ich habe das tolle Modul Generic Bridge installiert, habe jedoch bei Einbindung über MQTT2_CLIENT (an mosquito) immer folgende Fehlermeldung erhalten:
2018.12.16 12:07:49 1: IOT.vollmer2: ERROR: Ignoring function subscribe
Das Subscribe wurde auch nicht ausgeführt.
Nach Code Änderung in MQTT2_CLIENT (Z 411 in MQTT2_CLIENT_Write) von
} elsif($function eq "subscriptions" ) {
auf
} elsif($function eq "subscriptions" || $function eq "subscribe") {
kann ich endlich aus ein subscribe absetzen.
Ich habe jedoch die Module noch nicht durchschaut. Ist es vielleicht ein Fehler in meiner Implementation oder ist es tatsächlich ein Modulfehler?
...
Client:Internals:
CFGFN /media/usb0/fhem/FHEM/00_Utils_Vo_MQTT.cfg
DEF 192.168.100.60:1883
DeviceName 192.168.100.60:1883
NAME IOT.vollmer2
NR 571
STATE opened
TYPE MQTT2_CLIENT
clientId fhemIOT2
connecting 1
READINGS:
2018-12-16 12:23:44 state opened
Attributes:
autocreate 1
clientId fhemIOT2
devStateIcon (opened):rc_dot .*:rc_dot@red
disable 0
group MQTT
keepaliveTimeout 1200
lwt fhem/Zentralen/IOT2 offline
lwtRetain 1
msgAfterConnect -r fhem/Zentralen/IOT2 online
room Zentralen
subscriptions setByTheProgram
Bridge:Internals:
CFGFN /media/usb0/fhem/FHEM/00_Utils_Vo_MQTT.cfg
DEF mqtt (TF|House)Open.warn
IODev IOT.vollmer
NAME mqtt2_Open.warn
NR 694
NTFY_ORDER 50-mqtt2_Open.warn
STATE outgoing publish sent
TYPE MQTT_GENERIC_BRIDGE
devspec (TF|House)Open.warn
prefix mqtt
READINGS:
2018-12-16 12:31:41 device-count 2
2018-12-16 12:34:41 incoming-count 1
2018-12-16 12:34:41 outgoing-count 4
2018-12-16 12:34:41 transmission-state outgoing publish sent
2018-12-16 12:31:00 updated-reading-count 0
2018-12-16 12:34:41 updated-set-count 1
devices:
:global:
:defaults:
pub:base {"fhem/Zentralen"}
pub:retain 0
sub:base {"fhem/Zentralen"}
sub:retain 0
HouseOpen.warn:
:publish:
state:
last 1544959971.87915
mode R
topic {"$base/HouseOpen"}
:subscribe:
HASH(0x3e00168)
TFOpen.warn:
:publish:
state:
last 1544960081.22187
mode R
topic {"$base/TFOpen"}
:subscribe:
HASH(0x411d860)
HASH(0x3e07978)
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 *
message_ids:
subscribe:
fhem/Zentralen/HouseOpen/check
fhem/Zentralen/TFOpen/check
fhem/Zentralen/TFOpen/open
subscribeExpr:
^fhem\/Zentralen\/HouseOpen\/check$
^fhem\/Zentralen\/TFOpen\/check$
^fhem\/Zentralen\/TFOpen\/open$
subscribeQos:
fhem/Zentralen/HouseOpen/check 0
fhem/Zentralen/TFOpen/check 0
fhem/Zentralen/TFOpen/open 0
Attributes:
IODev IOT.vollmer
globalDefaults base={"fhem/Zentralen"} retain=0
group MQTT,helperNotifyer
room Alarm
stateFormat transmission-state
Ursache gefunden - siehe unten
Mhhh.... ;D
Was mach ich denn gerade falsch? Ich habe einen Dummy in FHEM mit MQTT_GENERIC_BRIDGE hängen der auf NodeRed Seite Logik schaltet. Aber es wird einfach nichts gepublished.
Internals:
NAME Lautsprecher
NR 311
STATE on
TYPE dummy
READINGS:
2018-12-16 14:20:09 state on
Attributes:
devStateIcon on:10px-kreis-gruen off:10px-kreis-rot .*:hourglass
group Klingel
icon audio_sound
mqttDefaults base={"homeland/haushalt/doors/doormodule/frontdoor/speaker"} pub:qos=2 sub:qos=2 retain=1
mqttForward all
mqttPublish state:topic={"$base/$name/set"} state:qos=2 state:retain=1
mqttSubscribe state:topic={"$base/$name"} state:qos=2
room Haustür
setList on off
userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
*EDIT* Mein Problem äußerte sich woanders... https://forum.fhem.de/index.php/topic,94542.msg872598.html#msg872598
Aber das Problem war wohl "state:topic={"$base/$name/set"} state:qos=2" damit kann man nachvollziehbar das MQTT Modul in FHEM töten.
Geht das noch nicht? Da Variablen zu nutzen? state:topic={"$base/$name/set"}set state:qos=2 oder state:topic={"$base/$name"}/set state:qos=2 mag er beides net.
Funktionieren tut es nur mit "mqttSubscribe state:topic=homeland/haushalt/heizung/Heizungssteuerung/state/set state:qos=2"
Auch nochmal zum Thema retain...
Wende ich es falsch an? boost und windowOpen werden von NodeRed immer als nicht definiert angemeckert - somit vermute ich sie sind nicht mit Retain im MQTT.
Internals:
DEF 00:1A:22:0C:18:D4 TouchPi3
MAC 00:1A:22:0C:18:D4
NAME Wohnzimmer_Thermostat
NR 130
STATE Gewünschte Temperatur: 20.5 Fenster auf/zu: 0 Boost: 0 Ventil: 80
TYPE EQ3BT
VERSION 2.0.5
loglevel 4
READINGS:
2018-07-03 23:40:42 battery ok
2018-12-16 15:27:40 bluetoothDevice hci0
2018-12-16 15:28:24 boost 0
2018-11-24 10:48:51 childlock 1
2018-12-16 15:28:56 consumption 5373.802
2018-12-16 15:28:56 consumptionToday 115.532
2018-12-16 00:03:07 consumptionYesterday 99.536
2018-12-16 15:16:03 desiredTemperature 20.5
2018-07-03 23:40:42 ecoMode 0
2018-12-16 13:49:09 errorCount-setBoost 2
2018-12-13 21:02:26 errorCount-setDesiredTemperature 4
2018-12-13 21:12:59 errorCount-updateStatus 25
2018-12-13 20:00:34 errorCount-updateSystemInformation 1
2018-12-16 15:28:16 firmware 110
2018-12-16 15:28:24 lastChangeBy FHEM
2018-07-03 23:40:43 mode Manual
2018-12-16 15:28:56 valvePosition 80
2018-12-16 15:28:20 windowOpen 0
helper:
currenthcidevice 0
handlesetBoost 0x0411
handleupdateStatus 0x0411
handleupdateSystemInformation 0x0411
listensetBoost
listenupdateStatus 02 01 29 50 04 29
listenupdateSystemInformation 01 6e 00 00 7f 75 81 61 67 65 65 60 67 64 a6
retryCountersetBoost 0
retryCounterupdateStatus 0
retryCounterupdateSystemInformation 0
valuesetBoost 4500
valueupdateStatus 03120C100F1C
valueupdateSystemInformation 00
hcidevices:
0
Attributes:
alexaName Heizung
alexaRoom Wohnzimmer
genericDeviceType thermostat
group Klima
icon sani_heating
mqttDefaults base={"homeland/haushalt/heizung/$device"} pub:qos=2 sub:qos=2 retain=1
mqttPublish desiredTemperature:topic={"$base/$name"} desiredTemperature:qos=2 desiredTemperature:retain=1 boost:topic={"$base/$name"} boost:qos=2 boost:retain=1 windowOpen:topic={"$base/$name"} windowOpen:qos=2 windowOpen:retain=1 valvePosition:topic={"$base/$name"} valvePosition:qos=2 valvePosition:retain=1
mqttSubscribe desiredTemperature:stopic=homeland/haushalt/heizung/Wohnzimmer_Thermostat/desiredTemperature/set desiredTemperature:qos=2 boost:stopic=homeland/haushalt/heizung/Wohnzimmer_Thermostat/boost/set boost:qos=2
room Echo,Messungen,Wohnzimmer
sshHost TouchPi3
stateFormat Gewünschte Temperatur: desiredTemperature Fenster auf/zu: windowOpen Boost: boost Ventil: valvePosition
userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
verbose 1
Bei meinen Tests ist mir noch etwas aufgefallen: Mir fehlt die Möglichkeit, beim Eintreten eines events (z.B. Änderung des state Attributes), nicht nur auf dieses zugreifen zu können, sondern auf beliebige Elemente des devices, um diese via publish an (hier) Node-Red weiterzuleiten.
Z.B. möchte ich neben dem Device Namen (geht ja über $device) auch noch mitteilen, um welchen Device Type es sich handelt. Das kann man entweder im Attribut group festhalten oder bei einigen devices wird das im Attribut subtype festgehalten (EnOcean Switches).
Frage: Geht es aktuell schon und ich bekomme es nur nicht hin oder wäre es möglich, das noch mit einzubauen? (publish mit beliebigen Readings des betroffenen Devices befüllen).
Vorweihnachtliche Grüße
Sascha
Mit 'expression' kann man die Nachricht redefinieren. Ich überlege mir, eine Hilfsfunktion zu schreiben, die man einfacher in Expression verwenden kann.
Hätte noch die Frage zum Retain und das Thema mit den $base $name sachen beim subscribe ( https://forum.fhem.de/index.php/topic,94542.msg877319.html#msg877319 ).
Ist die Verwendung von Retain (ich möchte es nutzen) mit der folgenden Art gewährleistet?
Ich habe manchmal das Gefühl es sind keine retainten... (weil nix ankommt beim neu deploy von node red)
mqttDefaults base={"homeland/haushalt/heizung/$device"} pub:qos=2 sub:qos=2 retain=1
mqttPublish desiredTemperature:topic={"$base/$name"} desiredTemperature:qos=2 desiredTemperature:retain=1 boost:topic={"$base/$name"} boost:qos=2 boost:retain=1 windowOpen:topic={"$base/$name"} windowOpen:qos=2 windowOpen:retain=1 valvePosition:topic={"$base/$name"} valvePosition:qos=2 valvePosition:retain=1
mqttSubscribe desiredTemperature:stopic=homeland/haushalt/heizung/Wohnzimmer_Thermostat/desiredTemperature/set desiredTemperature:qos=2 boost:stopic=homeland/haushalt/heizung/Wohnzimmer_Thermostat/boost/set boost:qos=2
Ich habe nicht vergessen, nur die Zeit ist gerade etwas knapp :/
Zum retain: habe getestet und kann bestätigen, dass das in Verbindung mit MQTT2_CLIENT nicht funktioniert. Mit MQTT und MQTT2_SERVER dagegen schon. Muss in das MQTT2_CLIENBT-Modul reinschauen. Entweder ist das dort gar nicht implementiert, oder erwartet andere Parameter als MQTT2_SERVER. Ich melde mich wieder...
Habe mir den Code in MQTT2_CLIENT angesehen. Dort ist die eigentliche Logik für 'retain' gar nicht implementiert. Dagegen kann die Bridge nichts ausrichten. Tut mir leid.
Man kann es gut sehen in der folgenden Methode. Es wird zwar ein entsprechendes Parameter erwartet (und davor auch korrekt übergeben), aber niergendwo mehr benutzt.
# send topic to client if its subscriptions matches the topic
sub
MQTT2_CLIENT_doPublish($@)
{
my ($hash, $topic, $val, $retain, $immediate) = @_;
my $name = $hash->{NAME};
return if(IsDisabled($name));
$val = "" if(!defined($val));
my $msg = pack("C",0x30).
MQTT2_CLIENT_calcRemainingLength(2+length($topic)+length($val)).
pack("n", length($topic)).
$topic.$val;
MQTT2_CLIENT_send($hash, $msg, $immediate)
}
Da es im Commandref als implementierte Feature beschrieben ist, halte ich es für einen Bug. Erstele am besten einen entsprechenden neuen Thread.
Hallo zusammen,
folgendes Problem,
ein Dummy ist wie folgt definiert:
define display dummy
attr display userReadings rechteck
attr display mqttPublish rechteck:topic=/display1/rectangle
dazu gibt es ein notify, welches das userReading rechteck des dummy display verändert sobald state des dummy display auf 1 gesetzt wird:
define display_notify_1 notify display:1 setreading display rechteck 1,1,10,10,50000
das notify funktioniert auch soweit und setzt das userReading rechteck des dummies auf den gewünschten Wert. Allerdings wird der Wert nicht gepublisht.
Setze ich jedoch im Webinterface von fhem mit dem gleichen Befehl des notifys,
setreading display rechteck 1,1,10,10,50000
so wird gepublisht.
Hab ich irgendwo einen Denkfehler?
VG
joschi2009
Wird denn in beiden Fällen ein Event ausgelöst?
ja, in beiden Fällen das gleiche event
Ob dich das der Lösung näher bringt weiß ich nicht, aber wenn du eh setreading nimmst, warum machst dann ein userreading? Brauchst doch gar nicht
ja, so fit bin ich noch nicht, aber auch ohne userReading kein Unterschied.
Aber Danke für die Antwort
Ich wüsste auch nicht wirklich warum es nicht gehen sollte mit notify. Kannst es nochmal mit DOIF probieren (finde ich eh eleganter) aber dürfte keinen Unterschied machen.
auch schon probiert, gleiches Ergebnis :(... naja mal ne Nacht drüber schlafen.
kleines Update, das Phänomen tritt anscheinend nur bei dummy-Devices auf.
@hexenmeister - sofern die Antwort an mich geht :-D
Ich habe MQTT 1 (Mosquitto) mit der normalen Bridge von dir. Und da hinterfrage ich ein wenig, ob das Retain geht :-D Mit MQTT2 bin ich net unterwegs - wüsste nicht warum ^^
Zitat von: hexenmeister am 29 Dezember 2018, 22:39:52
Habe mir den Code in MQTT2_CLIENT angesehen. Dort ist die eigentliche Logik für 'retain' gar nicht implementiert. Dagegen kann die Bridge nichts ausrichten. Tut mir leid.
Man kann es gut sehen in der folgenden Methode. Es wird zwar ein entsprechendes Parameter erwartet (und davor auch korrekt übergeben), aber niergendwo mehr benutzt.
# send topic to client if its subscriptions matches the topic
sub
MQTT2_CLIENT_doPublish($@)
{
my ($hash, $topic, $val, $retain, $immediate) = @_;
my $name = $hash->{NAME};
return if(IsDisabled($name));
$val = "" if(!defined($val));
my $msg = pack("C",0x30).
MQTT2_CLIENT_calcRemainingLength(2+length($topic)+length($val)).
pack("n", length($topic)).
$topic.$val;
MQTT2_CLIENT_send($hash, $msg, $immediate)
}
Da es im Commandref als implementierte Feature beschrieben ist, halte ich es für einen Bug. Erstele am besten einen entsprechenden neuen Thread.
@Master_Nick
Mit MQTT funktioniert Retain definitiv. Habe zwar nicht mit NodeRed getestet, sondern mit MQTT-Spy. Sende ich etwas mit Retain, dann wird eine neue Lasche, die danch geöffnet wird und diese (oder alle) Topics aboniert gleich mit diesem Wert beliefert. Sende ich ohne Retain, passiert das nicht.
Zitat von: joschi2009 am 31 Dezember 2018, 00:15:21
Hallo zusammen,
folgendes Problem,
ein Dummy ist wie folgt definiert:
define display dummy
attr display userReadings rechteck
attr display mqttPublish rechteck:topic=/display1/rectangle
dazu gibt es ein notify, welches das userReading rechteck des dummy display verändert sobald state des dummy display auf 1 gesetzt wird:
define display_notify_1 notify display:1 setreading display rechteck 1,1,10,10,50000
das notify funktioniert auch soweit und setzt das userReading rechteck des dummies auf den gewünschten Wert. Allerdings wird der Wert nicht gepublisht.
Setze ich jedoch im Webinterface von fhem mit dem gleichen Befehl des notifys,
setreading display rechteck 1,1,10,10,50000
so wird gepublisht.
Hab ich irgendwo einen Denkfehler?
VG
joschi2009
sehr komisch. Muss ich nachstellen...
Okay dann muss ich mal analysieren.
Also mit dem wie ich es da eingestellt habe passt es laut dir?
mqttDefaults base={"homeland/haushalt/heizung/$device"} pub:qos=2 sub:qos=2 retain=1
mqttPublish desiredTemperature:topic={"$base/$name"} desiredTemperature:qos=2 desiredTemperature:retain=1 boost:topic={"$base/$name"} boost:qos=2 boost:retain=1 windowOpen:topic={"$base/$name"} windowOpen:qos=2 windowOpen:retain=1 valvePosition:topic={"$base/$name"} valvePosition:qos=2 valvePosition:retain=1
mqttSubscribe desiredTemperature:stopic=homeland/haushalt/heizung/Wohnzimmer_Thermostat/desiredTemperature/set desiredTemperature:qos=2 boost:stopic=homeland/haushalt/heizung/Wohnzimmer_Thermostat/boost/set boost:qos=2
Habe gerade genau dein Code-Schnippsel verwendet mit einem Dummy. Dann disiredTemperature gesetzt und danach mit mosquitto_sub abgefragt.
$ mosquitto_sub -h 192.168.0.15 -t homeland/haushalt/heizung/testr/desiredTemperature
12
^C
Prompt kam der Wert. Dann den Wert gelöscht.
mosquitto_pub -t homeland/haushalt/heizung/testr/desiredTemperature -n -r
Schon kommt nicht mehr.
Testdummy:
defmod testr dummy
attr testr mqttDefaults mqttDefaults base={"homeland/haushalt/heizung/$device"} pub:qos=2 sub:qos=2 retain=1
attr testr mqttPublish desiredTemperature:topic={"$base/$name"} desiredTemperature:qos=2 desiredTemperature:retain=1 boost:topic={"$base/$name"} boost:qos=2 boost:retain=1 windowOpen:topic={"$base/$name"} windowOpen:qos=2 windowOpen:retain=1 valvePosition:topic={"$base/$name"} valvePosition:qos=2 valvePosition:retain=1
attr testr mqttSubscribe desiredTemperature:stopic=homeland/haushalt/heizung/Wohnzimmer_Thermostat/desiredTemperature/set desiredTemperature:qos=2 boost:stopic=homeland/haushalt/heizung/Wohnzimmer_Thermostat/boost/set boost:qos=2
attr testr readingList desiredTemperature
attr testr room TEST_Reported
attr testr setList desiredTemperature
Dann muss der Fehler in meinem function Block liegen, dass ich einfach von einer Abarbeitung ausgehe die so nicht stattfindet :-D
Danke für deine Mühe!
Hi,
ich stelle grade komplett von FHEM2FHEM und RFHEM auf MQTT um (und da ist so einiges). Klappt mit Sensoren auch wunderbar welche einfach nur ihre Readings zum Broker werfen sollen auch deren State erhalte ich problemlos.
Ich beisse mir nur grade an schaltbaren devices die Zähne aus deren state zu erhalten :(
Hier mal ein bsp Device:
Internals:
DEF MCP23017:PortB4
DEVICE MCP23017
NAME GarageLicht
NOTIFYDEV MCP23017,global
NR 36
NTFY_ORDER 50-GarageLicht
READING PortB4
STATE off
TYPE readingsProxy
CONTENT:
MCP23017 1
READINGS:
2019-01-05 02:14:54 lastCmd off
2019-01-05 01:28:41 state off
Attributes:
group MCP23017 Outputs
mqttPublish *:topic={"garage/GarageLicht/$reading"}
mqttSubscribe state:stopic={"garage/GarageLicht/set"}
room GPIO-Devices
setFn {($CMD eq "on")?"PortB4 off":"PortB4 on"}
setList on off
userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
valueFn {($VALUE eq "on")?"off":"on"}
Und hier das Device als MQTT_CLIENT:
Internals:
CFGFN
IODev mqtt
NAME GarageLicht
NR 30848
STATE off
TYPE MQTT_DEVICE
qos *:2
OLDREADINGS:
READINGS:
2019-01-05 01:27:02 state off
2019-01-05 01:27:02 transmission-state outgoing publish completed
message_ids:
publishSets:
:
topic garage/GarageLicht/set
values:
on
off
toggle
on-for-timer
off-for-timer
sets:
off
off-for-timer
on
on-for-timer
toggle
subscribe:
garage/GarageLicht/state
subscribeExpr:
^garage\/GarageLicht\/state$
subscribeQos:
garage/GarageLicht/state 0
subscribeReadings:
garage/GarageLicht/state:
cmd
name state
Attributes:
IODev mqtt
cmdIcon on:general_an off:general_aus
group Licht
icon light_ceiling
publishSet on off toggle on-for-timer off-for-timer garage/GarageLicht/set
qos 2
room Garage
subscribeReading_state garage/GarageLicht/state
Kann mir wer helfen wo da mein Fehler ist?
Bist Du sicher, daß Du nicht das publish und das subscribe vertauscht hast?
Zitat
Attributes:
group MCP23017 Outputs
mqttPublish *:topic={"garage/GarageLicht/$reading"}
mqttSubscribe state:stopic={"garage/GarageLicht/set"}
Hehe ja das vertauscht man gerne mal.
Wobei ich in meinem Setup auch den Fall habe, dass je nachdem wer am Ende das Device schaltet (FHEM oder eben ein ESP8266 der im Wifi ist) dann ist das set entweder als publish (garage/GarageLicht/set) (wie es die Regel ist) oder aber wenn FHEM einen Device schaltet der z. B. 433 Mhz wäre dann wäre das publish garage/GarageLicht/$reading.
Ich denke man kann das immer ganz schön so erklären oder sich selber verdeutlichen.
Den aktuellen Zustand eines Gerätes erfährt man auf "garage/GarageLicht/" und Schaltbefehle gehen gegen "garage/GarageLicht/set". Wenn nun aber so spezial Krams dazu kommt wie ein Gerät hat kein eigenes MQTT sondern FHEM schaltet da was völlig eigenes. Dann muss man halt nochmal ne Ecke mehr mit bedenken ;-)
@Dersch so wirklich 100% klar was sagen, kann ich bei deinem Beispiel nur, wenn ich die Seite des Garagenlichts kennen würde also die Config der Topics auf der Seite :-) (Achtung Wifi Config meist mit enthalten)
Eines fällt mir aber direkt auf.
Bei mir würde es immer wenn das eine "garage/GarageLicht/$reading" ist beim set "garage/GarageLicht/$reading/set" lauten.
Hallo,
ich würde mich freuen, wenn mir bezüglich dem globalen Subscribe jemand helfen könnte.
Ich bin mir nicht sicher, ob das in der aktuellen Version (deren Versionsnummer ich im übrigen auch nirgends gefunden habe, jedenfalls der letzte 'update'-Stand) schon funktioniert.
Aktuell erstelle ich die MQTT_GENERIC_BRIDGE und bekomme alles auf den Broker:
define mqttGeneric MQTT_GENERIC_BRIDGE
attr mqttGeneric IODev lb_mosquitto
attr mqttGeneric globalDefaults sub:qos=2 pub:qos=0 retain=1
attr mqttGeneric globalPublish *:topic={"fhem/$device/$reading"}
Jedoch habe ich den generischen umgekehrten Weg nicht gefunden. Ehrlich gesagt bin ich erschlagen vor Optionen bei mqttSubscribe, und weiß noch nicht mal, ob das überhaupt das richtige ist.
Im Prinzip möchte ich einfach nur generisch, für alle in FHEM angelegten Geräte, ein SET über MQTT auslösen. Muss ich da jetzt für jedes einzelne Gerät jetzt ein eigenes Topic erstellen, damit ich einen Befehl empfangen kann, oder geht das generisch, und wenn, wie würde so eine Zeile ausschauen.
Exemplarisch habe ich eine HS100-Steckdose
define Kueche_HS100 TPLinkHS110 192.168.1.2
Via Broker möchte ich jetzt sowas publishen wie
set/fhem/Kueche_HS100 = on
Gleichermaßen sollte das auch bei anderen Devices funktionieren beispielsweise
set/fhem/NUKIDevice1234 = lock
Wie müsste so eine generische Subscription aussehen? Ich werde leider aus der Doku nicht schlau.
Danke und viele Grüße,
Christian
Die Doku sagt:
ZitatglobalSubscribe ! TODO - wird derzeit nicht unterstuetzt und wird moeglicherweise gar nicht implementiert !
Und genau so ist es auch. Ich habe diese Feature angedacht, aber nicht fertiggestellt. Ehrlich gesagt, halte ich so ein globales 'Setzen' für etwas gefählich, man kann sich damit schnell Sicherheitslücken 'einbauen'. Daher bin ich mir nicht sicher, ob ich es wirklich machen soll. Es ist aus meiner Sicht besser, nur die Geräte damit bestücken, die man wirklich schalten will. Da es sich um einen eimaligen Aufwand handelt (viel Copy-Paste), halte ich es für vertretbar.
Hallo!
Sorry...ich werde auch irgendwie nicht ganz schlau daraus.
Ich mache gerade meine ersten gehversuche mit MQTT. Ich möchte gerne das Dashboard von Node-RED ausprobieren.
Ich habe eine Definition:
defmod mqttGeneric MQTT_GENERIC_BRIDGE
attr mqttGeneric IODev MQTT
attr mqttGeneric globalDefaults sub:qos=2 pub:qos=0 retain=1
attr mqttGeneric globalPublish *:topic={"/fhem/$device/$reading"}
Und lasse mir alle Events in FHEM übermitteln. Diese kommen auch problemlos in Node-Red an.
Sehe ich das richtig, dass dieser Weg zu viele Events erzeugt? Und die Systemauslastung dadurch stark ansteigt? Wie ist denn dann der empfohlene Weg? Nur die wirklich benötigten Readings alle einzeln hinterlegen? Oder für jedes Device dann eine eigene MQTT_GENERIC_BRIDGE?
Ich habe im EventMonitor gesehen, dass die Bridge ebenfalls viele Events erzeugt. Diese sind doch eigentlich für die Funktion niht weiter relevant...oder? Dann könnte ich diese deaktivieren.
Das Empfangen der Nachrichten habe ich ebenfalls noch nicht verstanden. Die generische Subscription ist nicht eingebaut. Das hatte ich gelesen. Aber der Weg über mqttSubscribe sollte doch eigentlich funktionieren?
Ich bekomme hier nur "this attribute is not allowed here" sobald ich versuche etwas einzutragen.
Vielen Dank für dieses Modul!
Gruß
Bismosa
globalPublish erzeugt zu viele Events, da vieles übertragen wird, was nicht weiter von Interesse ist. Man kann ggf. etwas mit Exclude ausfiltern.
Systemlast? Je nach Installationsgröße, aber trotzdem unnötig.
Eine Bridge reicht völlig aus. Definiere die benötigten Readings für publish und subscribe (mittels mqttPublish und mqttSubscribe) direkt in den betroffenen Devices, nicht in der Bridge selbst.
Hallo!
Danke für die schnelle Antwort. Nun ist der Groschen gefallen.
Im Test ist meine Systemlast sehr gering. Frische Installation nur mit MQTT und einem Dummy auf einer Virtuellen Maschine auf dem PC zum testen. Daher interessiert mich das...damit ich später nicht darauf reinfalle.
Ich bin nicht darauf gekommen, dass ich die Readings in den entsprechenden Devices setzen muss. Damit klappt es auf Anhieb! Danke!
Nun kann ich weiter testen.
Gruß
Bismosa
Meine Frage betrifft das mapping von state.
Hintergrund:
wenn ich bei einem Dummy z.B. normal state mit mqttPublish state:topic=cmnd/sonoff_pw2/POWER1 publishe
ist das Ergebnis in Mosquitto z.B. on oder off
wenn ich im Dummy --> eventMap used:on stop:off setze dann wird wie gewünscht
mit mqttPublish state:topic=cmnd/sonoff_pw2/POWER1 used und stop zum Mosquitto gepublished :)
Bei einem Homematic Switch z.B. HM-LC-SW1-PL2 geht das mit dem eventMap nicht. :-\
Da behelfe ich mir mit einem notify das dieses mapping zu mosquitto macht.
Wäre es denkbar dieses state mapping in die MQTT_GENERIC_BRIDGE einzubauen oder gibt es das schon?
Habe ich was übersehen oder gibt es eine andere einfache Lösung.
Billy
Kann leider nichts dazu sagen. eventMap ist ja genau dafür da, warum das bei HM-Device nicht funktioniert müsste man in einem entsprechenden Forum-Zweig fragen.
Ansonsten könnte man das mit der Bridge mit hilfe von 'expression' (s. Commandref) schon bewerkstelligen. Auch wenn das nicht dafür gedacht war.
Zitat von: hexenmeister am 10 Januar 2019, 07:32:03
Kann leider nichts dazu sagen. eventMap ist ja genau dafür da, warum das bei HM-Device nicht funktioniert müsste man in einem entsprechenden Forum-Zweig fragen.
Ansonsten könnte man das mit der Bridge mit hilfe von 'expression' (s. Commandref) schon bewerkstelligen. Auch wenn das nicht dafür gedacht war.
Danke, mit 'expression' geht was ich möchte. Deckt sich ja auch mit diesem thread.
Frage: Syntax MQTT_GENERIC_BRIDGE value-mapping
https://forum.fhem.de/index.php/topic,93188.msg857849.html#msg857849 (https://forum.fhem.de/index.php/topic,93188.msg857849.html#msg857849)
mit
state:topic=fhem/status/alarm/test_2 state:expression={($value eq 'off')?'stop':'on'} komme ich zum gewünschten Ergebnis!
EDIT:
Wie kann ich hier noch das retain flag setzten? ist mir nicht gelungen.Mit diesem publish
state:topic=fhem/status/alarm/test_2 state:retain=1 state:expression={($value eq 'off')?'stop':'on'}funktioniert auch retain! Super!!!
Billy
Dein Problem scheint gelöst zu sein. Freut mich :)
Zitat von: hexenmeister am 06 Januar 2019, 22:35:31
Ehrlich gesagt, halte ich so ein globales 'Setzen' für etwas gefählich, man kann sich damit schnell Sicherheitslücken 'einbauen'.
Den Sicherheitsaspekt kann ich nicht teilen - das ist genauso sicher/unsicher wie wenn ich den Status per HTTP setze. Ist halt nur ein anderes Protokoll, läuft genauso mit Authentifizierung usw.
Vielleicht kann mir trotzdem jemand weiterhelfen um ein Device einzeln zu setzen:
Per Eingabe würde ich die HS100 aktivieren mit:
set Kueche_HS100 on
Geben tut's on und off, und das würde ich per MQTT senden.
Wie würde dazu das mqttSubscribe aussehen?
attr lb_mosquitto mqttSubscribe state:stopic={"command/fhem/Kueche_HS100"} state:expression={Kueche_HS100=$value}
... hätte ich probiert, aber FHEM reagiert nicht darauf nicht.
Ich versteh die Syntaxhilfe von mqttSubscribe einfach nicht. Es sind ja Beispiele da, aber die sind nicht erklärt.
lg, Christian
Zitat von: christiantf am 11 Januar 2019, 16:14:11
Ich versteh die Syntaxhilfe von mqttSubscribe einfach nicht. Es sind ja Beispiele da, aber die sind nicht erklärt.
lg, Christian
Kennst du das? -->
Anwendungsfälle und Beispiele für MQTT_GENERIC_BRIDGEhttps://forum.fhem.de/index.php/topic,91642.msg841368.html#msg841368 (https://forum.fhem.de/index.php/topic,91642.msg841368.html#msg841368)
Vielleicht hilfts es dir!
@Hexenmeister --> Der Thread ist leider nur schwer zu finden. Die Idee mit eingängigen Beispielen hat mir schon öfters geholfen.
Du solltest vielleicht in der Überschrift "Anwendungsfälle und Beispiele für
MQT_GENERIC_BRIDGE" das MQT in MQTT ändern. ;)
dann findet man das leichter.
@Billy Jetzt kenn ich's ;-)
Jetzt hab ich
attr Kueche_HS100 mqttSubscribe state:stopic=command/fhem/Kueche_HS100
Sollte das richtig sein? Funktionieren tut's leider nicht. Sollte man im Log nicht irgendwas sehen, dass FHEM das Topic subscribed?
Es ist einfach so, als wäre die Zeile nicht da. Im MQTT-Spy sehe ich mein Publish mit mosquitto_pub an command/fhem/Kueche_HS100 = on, ich bekomme auch alle anderen Readings von der Generic_Bridge, aber meine Subscription wird ignoriert.
Vielleicht könnte jemand die konkrete Lösung posten. Wenn ich's einmal gesehen hab, versteh ich's hoffentlich! ;-)
Mach mal noch testweise einen "/" vor das command.
Zitat von: Beta-User am 11 Januar 2019, 17:11:52
Mach mal noch testweise einen "/" vor das command.
Unüblich, und funktioniert leider auch nicht - hab's in allen Kombinationen durchprobiert (mit/ohne / in FHEM, und mit/ohne / im mosquitto_pub).
Müsste ich das Subscribe des Topics im Log sehen?
Zitat von: christiantf am 11 Januar 2019, 17:15:30
Unüblich, [...]
:) Dachte ich auch, aber bei meinen (leider auch - aus anderen Gründen) erfolglosen Tests (mit MQTT2_SERVER) hatte ich wenigstens mit mosquitto_sub den Eindruck, dass das "einen Client mehr" erzeugt, und auch die Beispiele in der cref haben oft ein "einleitendes "/".
@hexenmeister:
Hat es einen Grund, dass das in dem eher unüblichen Format in der commandref steht bzw. sollte man irgendwie erläutern, wann man das warum benötigt?
Kleine Verständnisfrage. Warum werden bei allen Beispielen dummys als "remote" Device verwendet? Ich nehme bisher MQTT_DEVICE als Modul.
Zitat von: Dersch am 11 Januar 2019, 17:51:54
Kleine Verständnisfrage. Warum werden bei allen Beispielen dummys als "remote" Device verwendet? Ich nehme bisher MQTT_DEVICE als Modul.
Das war für mich zuerst auch ungewöhnlich.
Die MQTT_GENERIC_BRIDGE versorgt bestehende Devices mit MQTT Attributen. Wo es kein Device gibt, musst du ein Dummy definieren und an der
MQTT_GENERIC_BRIDGE anmelden.
Vorteil du hast bei allen Devices das gleiche Umfeld und bekommst mit get mqttGeneric devinfo alle Mqtt Devices in einer Übersicht.
Übrigens ist ein MQTT_DEVICE nichts anderes als ein Dummy mit mqtt Attributen.
Hoffe das hilft.
Ah ok vielen Dank ! Dann tüftel ich mal weiter um es endlich komplett zu verstehen und Fhem2fhem ersetze :)
Ich finde es immer noch ungewöhnlich.
@hexenmeister: Sollte man nicht neuerdings empfehlen, alles, was nicht in FHEM direkt als Gerät über ein anderes Modul vorhanden ist (CUL_HM usw.) als MQTT2_DEVICE anzulegen?
Hintergrund: Man braucht "irgendwas" dafür, und nach meiner bisherigen Erfahrung gehört MQTT2_DEVICE zu den Geräten, die am einfachsten optisch ansprechend zu konfigurieren sind.
Man braucht halt (ggf. zusätzlich) ein MQTT2-IO (Client, wenn man weiter mosquitto/ext. Broker im Einsatz hat)....
Zitat Hexenmeister am: 16 November 2018 hier:
https://forum.fhem.de/index.php/topic,91984.msg859281/topicseen.html#msg859281 (https://forum.fhem.de/index.php/topic,91984.msg859281/topicseen.html#msg859281)
ZitatIch sehe eigentlich keine Notwendigkeit sowohl die Bridge als auch MQTT2_DEVICE gleichzeitig zu verwenden.
Bridge kann ja das andere komplett ersetzen und auch vice-versa. Die Frage ist nur, wie man es haben möchte.
Hat sich da was verändert? Bei mir deckt die Bridge eigentlich alles ab.
Zum Hintergrund nochmal:
Im Kern ist das Protokoll sehr simpel, alle Lösungen funktionieren irgendwie, die Mischung MQTT2-IO+Gen.-Bridge ist noch etwas hakelig, aber das dürfte eine Frage der Zeit sein.
Wer heute in MQTT einsteigt, sollte (und das ist wohl auch hexenmeisters heutige Tendenz, anders als evtl. noch vor ein paar Wochen) nativ MQTT sprechendes Zeug mit einem MQTT2-IO in FHEM einbinden und MQTT2_DEVICE nutzen. Das ist schlicht und ergreifend für Neulinge am einfachsten zu konfigurieren (funktional und optisch), JSON ist kein Thema und auch die Sendeseite ist da sehr flexibel, was das Basteln nahezu beliebiger Formate angeht.
Die "Lücke" dabei ist die "ver-MQTT-ung" von Nicht-MQTT-Devices. Das kann die Bridge am universellsten, nur eben mit der Einschränkung, dass die nicht zusammen mit autocreate an einem MQTT2-IO genutzt werden kann.
Im Moment ist das die einzige Einschränkung, es dürfte aber auch nur eine Frage der Zeit sein, bis diese behoben ist.
Es gibt aber weder einen Grund, irgendwas umzubauen, schon gleich nicht, wenn man _irgendeinen_ Weg verstanden hat, wie man zu einem bestimmten Ergebnis kommt. Und auch die Aussage ist ok, dass man mit den alten Wegen (fast) alles abdecken kann.
Wer allerdings irgendwann Verschlüsselung will, braucht dann ein MQTT2-IO (es sei denn, das kommt irgendwann auch bei MQTT(1), was ich aber ehrlich gesagt im Moment nicht glaube).
Ich hab's jetzt mit Telnet gemacht.
mqttSubscribe funktioniert bei mir nicht, oder die Beispiele (genau genommen Syntaxangaben) sind zu unklar, um das korrekt einzurichten.
Es gibt im Forum leider auch kein Beispiel, wo jemand mqttSubscribe mit einem konkreten Device erfolgreich gemacht hat.
Zitat von: christiantf am 12 Januar 2019, 12:58:10
mqttSubscribe funktioniert bei mir nicht, oder die Beispiele (genau genommen Syntaxangaben) sind zu unklar, um das korrekt einzurichten.
Es gibt im Forum leider auch kein Beispiel, wo jemand mqttSubscribe mit einem konkreten Device erfolgreich gemacht hat.
Verstehe ich nicht.
Einfaches Beispiel. In 5 Minuten angelegt.
Dummy myTest4 published (sendet in diesem Fall on/off)
defmod myTest4 dummy
attr myTest4 userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
attr myTest4 mqttPublish state:topic=fhem/status/alarm/test_4 state:retain=0
attr myTest4 room MQTT
attr myTest4 setList on offDummy myTest5 subscribed (empfängt)
mqttSubscribe state:topic=fhem/status/alarm/test_4defmod myTest5 dummy
attr myTest5 userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
attr myTest5 mqttSubscribe state:topic=fhem/status/alarm/test_4
attr myTest5 room MQTTd.h. myTest5 nimmt immer den Status von myTest4 an (on oder off).
@Beta-User und wenn man nur einen Mosquitto also MQTT1 hat? Dennoch mit dem MQTT2 Io? :-D Das würde ich nicht ganz verstehen.
Zitat von: Billy am 11 Januar 2019, 16:26:41
@Hexenmeister --> Der Thread ist leider nur schwer zu finden. Die Idee mit eingängigen Beispielen hat mir schon öfters geholfen.
Du solltest vielleicht in der Überschrift "Anwendungsfälle und Beispiele für MQT_GENERIC_BRIDGE" das MQT in MQTT ändern. ;)
dann findet man das leichter.
Asche auf mein Haupt! Danke für den Hinweis!
Zitat von: Beta-User am 11 Januar 2019, 17:29:35
:) Dachte ich auch, aber bei meinen (leider auch - aus anderen Gründen) erfolglosen Tests (mit MQTT2_SERVER) hatte ich wenigstens mit mosquitto_sub den Eindruck, dass das "einen Client mehr" erzeugt, und auch die Beispiele in der cref haben oft ein "einleitendes "/".
@hexenmeister:
Hat es einen Grund, dass das in dem eher unüblichen Format in der commandref steht bzw. sollte man irgendwie erläutern, wann man das warum benötigt?
Nö. Es gibt keinen Grund. Habe beim Testen und Entwickeln so verwedet und so in Beispiele kopiert. Jeder kann natürlich die Topics frei wählen.
Zitat von: Beta-User am 11 Januar 2019, 18:42:45
@hexenmeister: Sollte man nicht neuerdings empfehlen, alles, was nicht in FHEM direkt als Gerät über ein anderes Modul vorhanden ist (CUL_HM usw.) als MQTT2_DEVICE anzulegen?
Hintergrund: Man braucht "irgendwas" dafür, und nach meiner bisherigen Erfahrung gehört MQTT2_DEVICE zu den Geräten, die am einfachsten optisch ansprechend zu konfigurieren sind.
Wohl Geschmackssache. Ich mag den Syntax von MQTT2_DEVICE nicht wirklich. Mir gefällt es besser mit den Dummy's. Ich würde entweder die Bridge oder die MQTT2_DEVICEs verwenden, sonst ist das irgendwie chaotisch.
Zitat von: Beta-User am 11 Januar 2019, 20:24:21
Zum Hintergrund nochmal:
Im Kern ist das Protokoll sehr simpel, alle Lösungen funktionieren irgendwie, die Mischung MQTT2-IO+Gen.-Bridge ist noch etwas hakelig, aber das dürfte eine Frage der Zeit sein.
Wer heute in MQTT einsteigt, sollte (und das ist wohl auch hexenmeisters heutige Tendenz, anders als evtl. noch vor ein paar Wochen) nativ MQTT sprechendes Zeug mit einem MQTT2-IO in FHEM einbinden und MQTT2_DEVICE nutzen. Das ist schlicht und ergreifend für Neulinge am einfachsten zu konfigurieren (funktional und optisch), JSON ist kein Thema und auch die Sendeseite ist da sehr flexibel, was das Basteln nahezu beliebiger Formate angeht.
Die "Lücke" dabei ist die "ver-MQTT-ung" von Nicht-MQTT-Devices. Das kann die Bridge am universellsten, nur eben mit der Einschränkung, dass die nicht zusammen mit autocreate an einem MQTT2-IO genutzt werden kann.
Im Moment ist das die einzige Einschränkung, es dürfte aber auch nur eine Frage der Zeit sein, bis diese behoben ist.
Es gibt aber weder einen Grund, irgendwas umzubauen, schon gleich nicht, wenn man _irgendeinen_ Weg verstanden hat, wie man zu einem bestimmten Ergebnis kommt. Und auch die Aussage ist ok, dass man mit den alten Wegen (fast) alles abdecken kann.
Wer allerdings irgendwann Verschlüsselung will, braucht dann ein MQTT2-IO (es sei denn, das kommt irgendwann auch bei MQTT(1), was ich aber ehrlich gesagt im Moment nicht glaube).
Die Probleme lösen wir sicher nach und nach.
Was man nimmt, ist ein wenig frage der Vorlieben. Die verschiedene Lösungen machen im Prinzip das Selbe, nur auf eine etwas andere Weise.
Es ist schwer eine generelle Empfehlung zu geben. Ich persönlich halte z.B. Autocreate und Co. für eine recht üble Sache, vor allem für Einsteiger. Solange es geht, ist es gut, wenn aber etwas nicht so will, dann stellt sich raus, dass man die Funktionsweise nicht verstanden hat und nicht weiter weiß. Macht man alles selbst - weiß man sih auch später zu helfen. Aber das ist halt meine Meinung, andere schwören drauf.
Ich würde sagen, lest Commandref und etscheidet, was einem besser passt.
Zitat von: christiantf am 11 Januar 2019, 16:14:11
Den Sicherheitsaspekt kann ich nicht teilen - das ist genauso sicher/unsicher wie wenn ich den Status per HTTP setze. Ist halt nur ein anderes Protokoll, läuft genauso mit Authentifizierung usw.
Ja und genau daher sollte man HTTP auch nicht mehr verwenden. Standardfall, bzw. was die meiste Verwenden, ist bei MQTT eben unverschlüsselt und ohne Authentifizierung. Daher ist der Sicherheitsaspekt durchaus vorhanden und von Bedeutung. Außerdem ist es immer bessen, wenn man explizit etwas freigibt und nicht von vornherein für alle (auch künftig angelegte) Geräte.
Zitat von: christiantf am 11 Januar 2019, 16:14:11
Wie würde dazu das mqttSubscribe aussehen?
attr lb_mosquitto mqttSubscribe state:stopic={"command/fhem/Kueche_HS100"} state:expression={Kueche_HS100=$value}
... hätte ich probiert, aber FHEM reagiert nicht darauf nicht.
Ich versteh die Syntaxhilfe von mqttSubscribe einfach nicht. Es sind ja Beispiele da, aber die sind nicht erklärt.
Das sieht eigentlich richtig aus:
Zitatattr Kueche_HS100 mqttSubscribe state:stopic=command/fhem/Kueche_HS100
ZitatSollte das richtig sein? Funktionieren tut's leider nicht. Sollte man im Log nicht irgendwas sehen, dass FHEM das Topic subscribed?
Es ist einfach so, als wäre die Zeile nicht da. Im MQTT-Spy sehe ich mein Publish mit mosquitto_pub an command/fhem/Kueche_HS100 = on, ich bekomme auch alle anderen Readings von der Generic_Bridge, aber meine Subscription wird ignoriert.
Sonderbar. Im Commandref steht, wie man die Geräte und darauf angemeldete 'publish' und 'subscribe' anzeigen kann:
get <bridge> derinfoZitat:
ZitatGibt eine Liste der ueberwachten Geraete aus, deren Namen zu dem optionalen regulaerem Ausdruck entsprechen. Fehlt der Ausdruck, werden alle Geraete aufgelistet. Zusaetzlich werden bei 'publish' und 'subscribe' verwendete Topics angezeigt incl. der entsprechenden Readinsnamen.
Bitte immer die verwendete Konfiguration posten, nicht nur die Auschschnitte. Dann kann man das auch genau(er) nachstellen und letztendlich besser weiter helfen.
Zitat von: christiantf am 12 Januar 2019, 12:58:10
Ich hab's jetzt mit Telnet gemacht.
mqttSubscribe funktioniert bei mir nicht, oder die Beispiele (genau genommen Syntaxangaben) sind zu unklar, um das korrekt einzurichten.
Es gibt im Forum leider auch kein Beispiel, wo jemand mqttSubscribe mit einem konkreten Device erfolgreich gemacht hat.
Ähm... Es gab hier Beispiele ohne Ende. Z.B. das: https://forum.fhem.de/index.php/topic,91642.msg841370.html#msg841370
Ein Beispiel anhand einer 'echten' EnOcean-Gerät. Link zu dem Thread war hier ja schon gepostet.
Auch die Syntaxangabn sind penibel im Commandref festgehalten. Was brauchst Du mehr?
Wenn etwas nicht klar ist, bitte etwas konkretter. Bis jetzt kann ich nur sagen, dass im meisten Fällen das geschriebene verstanden zu werden scheint ;)
Zitat von: Master_Nick am 12 Januar 2019, 14:34:53
@Beta-User und wenn man nur einen Mosquitto also MQTT1 hat? Dennoch mit dem MQTT2 Io? :-D Das würde ich nicht ganz verstehen.
Wenn alles schon läuft, würde ich es auch so lassen, meine Installationen baue ich auch nicht um. Bei neuen spricht (fast) nichts gegen die Verwendung von MQTT2_CLIENT. Es gibt noch Probleme mit autocreate und mqtt1 ist (zumindest theoretisch) etwas performanter, da sparsamer mit Ressourcen umgeht. Ob man das messen (oder gar merken) würde - steht auf einem anderen Blatt.
Zitat von: hexenmeister am 12 Januar 2019, 16:14:53
Die Probleme lösen wir sicher nach und nach.
Was man nimmt, ist ein wenig frage der Vorlieben. Die verschiedene Lösungen machen im Prinzip das Selbe, nur auf eine etwas andere Weise.
Es ist schwer eine generelle Empfehlung zu geben. Ich persönlich halte z.B. Autocreate und Co. für eine recht üble Sache, vor allem für Einsteiger. Solange es geht, ist es gut, wenn aber etwas nicht so will, dann stellt sich raus, dass man die Funktionsweise nicht verstanden hat und nicht weiter weiß. Macht man alles selbst - weiß man sih auch später zu helfen. Aber das ist halt meine Meinung, andere schwören drauf.
Ich würde sagen, lest Commandref und etscheidet, was einem besser passt.
Bin sehr froh, dass ihr beiden das vollends zu einem guten Ineinanderwirken bekommen werdet!
Ansonsten: Wer commandref lesen kann und will, wird sich in der Regel auch zu helfen wissen, egal welchen Weg er im Detail nimmt...
Und dass es eigentlich besser wäre, wenn jeder etwas tiefer in die Themen einsteigen würde, wäre vermutlich auch gut. Allein: Die Erfahrung lehrt, dass cref immer die letzte Quelle ist, die ein bestimmter Nutzerkreis zu Rate zieht (lieber wird hier gemault...).
Meine Erfahrung mit - zugegebenermaßen eher exotischen Anwendungsfällen (aus "klassischer MQTT-Sicht" und den hier bisher vorhandenen Lösungen) - ist eben die, dass es mit MQTT2 in allen Fällen nicht komplizierter und in einigen sehr viel einfacher war, das umzusetzen, was ich persönlich brauchte. Da ist autocreate eingeschlossen, aber eben auch immer mit dem Vorbehalt, dass ich da schon eine recht konkrete Vorstellung hatte, wie der Hase so läuft und Rudi so freundlich war, manches in verblüffender Weise in code umzusetzen....
Zitat von: hexenmeister am 12 Januar 2019, 16:07:42
Wohl Geschmackssache. Ich mag den Syntax von MQTT2_DEVICE nicht wirklich. Mir gefällt es besser mit den Dummy's. Ich würde entweder die Bridge oder die MQTT2_DEVICEs verwenden, sonst ist das irgendwie chaotisch.
Ja, absolut, das ist eine Geschmackssache (und vermutlich auch Gewohnheitsfrage). Geht halt "alles auf einmal" mit widgetOverride, JSON-Erstellung usw.. Fand es am Anfang auch gewöhnungsbedürftig, hatte da aber auch noch nicht wirklich viele Dummys "aufgehübscht". Jetzt glaube ich beides verstanden zu haben, und zwischenzeitlich ist einiges an Beispielen in den templates drin.
Daher meine Tendenz, Anfängern eher den MQTT2_DEVICE-Weg zu empfehlen (und die Bridge dann "nur noch", um "normale" Devices mqtt-fähig zu machen - das finde ich aber eine klasse Sache!). Könnte man vermutlich auch einfach per notify und publish über das MQTT2-IO, aber das ist m.E. deutlich unübersichtlicher.
Aber klar: Jeder wie er kann und mag, nur nach Möglichkeit die Dinge nicht durcheinanderbringen (es passiert leider vielen, die MQTT2 für eine neue Version des Protokolls halten und nicht für eine bloße Alternative innerhalb FHEM...)
Hallo zusammen,
ich bekomme beim start von FHEM diese Meldung:
No I/O device found for MQTT_GENERIC_BRIDGE
Es funktioniert aber alles..
Hier meine bridge:
Internals:
DEF mqtt Wetterstation,Gartenhaus
IODev MQTT
NAME MQTT_GENERIC_BRIDGE
NR 608
NTFY_ORDER 50-MQTT_GENERIC_BRIDGE
STATE outgoing publish sent
TYPE MQTT_GENERIC_BRIDGE
devspec Wetterstation,Gartenhaus
prefix mqtt
READINGS:
2019-01-13 20:47:47 device-count 2
2019-01-13 20:28:17 incoming-count 0
2019-01-13 20:55:24 outgoing-count 39
2019-01-13 20:55:23 transmission-state outgoing publish sent
2019-01-13 20:28:17 updated-reading-count 0
2019-01-13 20:28:17 updated-set-count 0
devices:
:global:
:defaults:
pub:retain 1
sub:retain 1
Gartenhaus:
:publish:
Raintoday:
mode R
topic {"/Gartenhaus/$reading"}
Windspeed:
last 1547409324.08038
mode R
topic {"/Gartenhaus/$reading"}
Wetterstation:
:publish:
humidity:
last 1547409259.66948
mode R
topic {"/Wetterstation/$reading"}
temperature:
last 1547409259.77479
mode R
topic {"/Wetterstation/$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 *
message_ids:
subscribe:
subscribeExpr:
subscribeQos:
Attributes:
IODev MQTT
alias MQTT Bridge
globalDefaults retain=1
group MQTT
icon mqtt
room FHEM
stateFormat transmission-state
Was habe ich vergessen ?
VG Klaus
Gute Frage, die Meldung kommt aus fhem.pl. Vermutlich ist die Bridge vor dem IODev in Config definiert.
Zitat von: hexenmeister am 13 Januar 2019, 21:45:49
Vermutlich ist die Bridge vor dem IODev in Config definiert.
Habe ich bereits gecheckt....
define MQTT MQTT 127.0.0.1:1883
attr MQTT alias MQTT Broker
attr MQTT event-on-update-reading no
attr MQTT icon mqtt_broker
attr MQTT keep-alive 120
attr MQTT last-will /FHEM/status crashed
attr MQTT room FHEM
attr MQTT stateFormat state connection
attr MQTT verbose 2
define MQTT_GENERIC_BRIDGE MQTT_GENERIC_BRIDGE mqtt Wetterstation,Gartenhaus,HZ.zt,Wohnzimmer_LCD,GA.tor
attr MQTT_GENERIC_BRIDGE IODev MQTT
attr MQTT_GENERIC_BRIDGE alias MQTT Bridge
attr MQTT_GENERIC_BRIDGE globalDefaults retain=1
attr MQTT_GENERIC_BRIDGE group MQTT
attr MQTT_GENERIC_BRIDGE icon mqtt
attr MQTT_GENERIC_BRIDGE room FHEM
attr MQTT_GENERIC_BRIDGE stateFormat transmission-state
attr MQTT_GENERIC_BRIDGE verbose 2Merkwürdig ist das.
Das ist es. Leider momentan keine Idee :/
Hallo
Habe heute mein fhem geupdatet und seitdem ist fhem nicht mehr bedienbar
mein eventmonitor läuft über vor lauter Meldungen
Siehe
incoming-count 22682
outgoing-count 102063
innerhalb kurzer Zeit.
Ein zurückspielen der vorgänger Version behebt erst mal das Problem
Ines
Internals:
IODev mqtt
NAME mqttGeneric
NR 172
NTFY_ORDER 50-mqttGeneric
STATE dev: 18 in: 22682 out: 102063
TYPE MQTT_GENERIC_BRIDGE
devspec .*
prefix mqtt
READINGS:
2019-01-15 11:54:54 device-count 18
2019-01-15 22:57:40 incoming-count 22682
2019-01-15 22:57:40 outgoing-count 102063
2019-01-15 22:57:40 transmission-state outgoing publish sent
2019-01-15 22:55:44 updated-reading-count 2099
2019-01-15 22:57:40 updated-set-count 20410
devices:
Bogenlampe:
:defaults:
pub:base {"Smarthome/licht/$device/$reading"}
sub:base {"Smarthome/licht/$device/$reading"}
:publish:
*:
mode R
topic {$base}
:subscribe:
HASH(0x4190720)
HASH(0x4190d68)
HASH(0x4190618)
HASH(0x4190cc0)
Deckenlampe:
:defaults:
pub:base {"Smarthome/licht/$device/$reading"}
sub:base {"Smarthome/licht/$device/$reading"}
:publish:
*:
mode R
topic {$base}
:subscribe:
HASH(0x420be40)
HASH(0x420bd38)
HASH(0x420bfa8)
HASH(0x420bc48)
Tischlampe:
:defaults:
pub:base {"Smarthome/licht/$device/$reading"}
sub:base {"Smarthome/licht/$device/$reading"}
:publish:
*:
mode R
topic {$base}
:subscribe:
HASH(0x420c158)
HASH(0x420c248)
HASH(0x420c350)
HASH(0x420c4b8)
Tischlampe2:
:defaults:
pub:base {"Smarthome/licht/$device/$reading"}
sub:base {"Smarthome/licht/$device/$reading"}
:publish:
*:
mode R
topic {$base}
:subscribe:
HASH(0x4182a38)
HASH(0x4181300)
HASH(0x419f680)
HASH(0x420c560)
Yeelight_andre:
:defaults:
pub:base {"Smarthome/licht/$device/$reading"}
sub:base {"Smarthome/licht/$device/$reading"}
:publish:
*:
mode R
topic {$base}
:subscribe:
HASH(0x41826d8)
HASH(0x4185a80)
HASH(0x4182810)
HASH(0x4182708)
Yeelight_flur:
:defaults:
pub:base {"Smarthome/licht/$device/$reading"}
sub:base {"Smarthome/licht/$device/$reading"}
:publish:
*:
mode R
topic {$base}
:subscribe:
HASH(0x419eb70)
HASH(0x41829a8)
HASH(0x4182660)
Yeelight_inesa:
:defaults:
pub:base {"Smarthome/licht/$device/$reading"}
sub:base {"Smarthome/licht/$device/$reading"}
:publish:
*:
mode R
topic {$base}
:subscribe:
HASH(0x419edc8)
HASH(0x4194840)
aussen_wetterstation:
:publish:
*:
mode R
topic {"/sensor/balkon/$reading"}
fensterkontakt_briefkasten:
:defaults:
pub:base {"/".AttrVal($device,'room','')."/$device/$reading"}
sub:base {"/".AttrVal($device,'room','')."/$device/$reading"}
:publish:
*:
mode R
topic {$base}
fensterkontakt_kellertuer:
:defaults:
pub:base {"/".AttrVal($device,'room','')."/$device/$reading"}
sub:base {"/".AttrVal($device,'room','')."/$device/$reading"}
:publish:
*:
mode R
topic {$base}
fensterkontakt_schlafzimmer:
:defaults:
pub:base {"/".AttrVal($device,'room','')."/$device/$reading"}
sub:base {"/".AttrVal($device,'room','')."/$device/$reading"}
:publish:
*:
mode R
topic {$base}
fensterkontakt_wohnzimmerterasse:
:defaults:
pub:base {"/".AttrVal($device,'room','')."/$device/$reading"}
sub:base {"/".AttrVal($device,'room','')."/$device/$reading"}
:publish:
*:
mode R
topic {$base}
flur_bewegung:
:defaults:
pub:base Smarthome/flur
sub:base Smarthome/flur
:publish:
_state:
last 1547586858.06023
mode R
topic {"$base/bewegung/$name"}
batteryVoltage:
mode R
topic {"$base/bewegung/$name"}
state:
last 1547586858.03932
mode R
topic {"$base/bewegung/$name"}
keller_bewegung:
:defaults:
pub:base Smarthome/keller
sub:base Smarthome/keller
:publish:
_state:
last 1547589383.75983
mode R
topic {"$base/bewegung/$name"}
batteryVoltage:
last 1547589383.73848
mode R
topic {"$base/bewegung/$name"}
state:
last 1547586858.1316
mode R
topic {"$base/bewegung/$name"}
keller_temp_luftdruck:
:publish:
*:
mode R
topic {"/sensor/keller/$reading"}
oben_bewegung:
:defaults:
pub:base Smarthome/schlafzimmer
sub:base Smarthome/schlafzimmer
:publish:
_state:
last 1547586747.25309
mode R
topic {"$base/bewegung/$name"}
batteryVoltage:
mode R
topic {"$base/bewegung/$name"}
state:
last 1547586747.22998
mode R
topic {"$base/bewegung/$name"}
waschmachine_keller:
:publish:
state:
mode R
topic Smarthome/keller/waschmaschine/set
:subscribe:
HASH(0x4275a30)
wetterstation:
:defaults:
pub:base sensor/keller
sub:base sensor/keller
:subscribe:
HASH(0x4275bc8)
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 *
message_ids:
subscribe:
Smarthome/licht/Yeelight_schlafzimmer/hue
Smarthome/licht/Yeelight_flur/bright
Smarthome/licht/Deckenlampe/RGB
Smarthome/licht/Deckenlampe/set
Smarthome/licht/Bogenlampe/set
Smarthome/licht/Yeelight_schlafzimmer/bright
Smarthome/licht/Tischlampe/HSV
Smarthome/licht/Deckenlampe/HSV
Smarthome/licht/Tischlampe2/dim
sensor/balkon/+
Smarthome/licht/Tischlampe/RGB
Smarthome/licht/Tischlampe2/RGB
Smarthome/licht/Tischlampe2/set
Smarthome/licht/Bogenlampe/RGB
Smarthome/licht/Tischlampe2/HSV
Smarthome/licht/Deckenlampe/dim
Smarthome/licht/Bogenlampe/HSV
Smarthome/licht/Bogenlampe/dim
Smarthome/keller/waschmaschine/state
Smarthome/licht/Tischlampe/dim
Smarthome/licht/Yeelight_flur/set
Smarthome/licht/Yeelight_schlafzimmer/set
Smarthome/licht/Tischlampe/set
subscribeExpr:
^Smarthome\/licht\/Yeelight_flur\/bright$
^Smarthome\/licht\/Deckenlampe\/RGB$
^Smarthome\/licht\/Deckenlampe\/set$
^Smarthome\/licht\/Bogenlampe\/set$
^Smarthome\/licht\/Yeelight_schlafzimmer\/bright$
^Smarthome\/licht\/Tischlampe\/HSV$
^Smarthome\/licht\/Deckenlampe\/HSV$
^Smarthome\/licht\/Tischlampe2\/dim$
^sensor\/balkon\/([^/]+)$
^Smarthome\/licht\/Tischlampe\/RGB$
^Smarthome\/licht\/Tischlampe2\/RGB$
^Smarthome\/licht\/Tischlampe2\/set$
^Smarthome\/licht\/Bogenlampe\/RGB$
^Smarthome\/licht\/Tischlampe2\/HSV$
^Smarthome\/licht\/Deckenlampe\/dim$
^Smarthome\/licht\/Bogenlampe\/HSV$
^Smarthome\/licht\/Bogenlampe\/dim$
^Smarthome\/keller\/waschmaschine\/state$
^Smarthome\/licht\/Tischlampe\/dim$
^Smarthome\/licht\/Yeelight_flur\/set$
^Smarthome\/licht\/Yeelight_schlafzimmer\/set$
^Smarthome\/licht\/Tischlampe\/set$
subscribeQos:
Smarthome/keller/waschmaschine/state 0
Smarthome/licht/Bogenlampe/HSV 0
Smarthome/licht/Bogenlampe/RGB 0
Smarthome/licht/Bogenlampe/dim 0
Smarthome/licht/Bogenlampe/set 0
Smarthome/licht/Deckenlampe/HSV 0
Smarthome/licht/Deckenlampe/RGB 0
Smarthome/licht/Deckenlampe/dim 0
Smarthome/licht/Deckenlampe/set 0
Smarthome/licht/Tischlampe/HSV 0
Smarthome/licht/Tischlampe/RGB 0
Smarthome/licht/Tischlampe/dim 0
Smarthome/licht/Tischlampe/set 0
Smarthome/licht/Tischlampe2/HSV 0
Smarthome/licht/Tischlampe2/RGB 0
Smarthome/licht/Tischlampe2/dim 0
Smarthome/licht/Tischlampe2/set 0
Smarthome/licht/Yeelight_flur/bright 0
Smarthome/licht/Yeelight_flur/set 0
Smarthome/licht/Yeelight_schlafzimmer/bright 0
Smarthome/licht/Yeelight_schlafzimmer/set 0
sensor/balkon/+ 0
Attributes:
IODev mqtt
icon mqtt
room MQTT
stateFormat dev: device-count in: incoming-count out: outgoing-count
Welche Version war vorher? Was zeigt eventMonitor? Etwas im Log? Zeigt MQTTSpy eine Nachrichtenflut?
Hallo
Die letzte Version war von Mitte Dezember 10_MQTT_GENERIC_BRIDGE.pm 17905 2018-12-06
Der Eventmonitor wurde förmlich überflutet von Events der MQTT_GENERIC_BRIDGE.
Im log steht dann dieses
2019.01.15 00:42:20 3: Bogenlampe set HSV 60, 100, 100 with ramp: 0, flags:
2019.01.15 00:42:20 3: Deckenlampe set HSV 60, 0, 100 with ramp: 0, flags:
2019.01.15 00:42:20 3: Bogenlampe set HSV 0, 100, 100 with ramp: 0, flags:
2019.01.15 00:42:20 3: Bogenlampe set HSV 60, 100, 24 with ramp: 0, flags:
2019.01.15 00:42:20 3: Bogenlampe set HSV 60, 100, 100 with ramp: 0, flags:
2019.01.15 00:42:20 3: Bogenlampe set HSV 0, 100, 100 with ramp: 0, flags:
2019.01.15 00:42:21 3: Deckenlampe set HSV 60, 100, 100 with ramp: 0, flags:
2019.01.15 00:42:21 3: Deckenlampe set HSV 60, 0, 100 with ramp: 0, flags:
2019.01.15 00:42:21 3: Bogenlampe set HSV 0, 100, 24 with ramp: 0, flags:
2019.01.15 00:42:21 3: Bogenlampe set HSV 60, 100, 100 with ramp: 0, flags:
2019.01.15 00:42:21 3: Bogenlampe set HSV 0, 100, 100 with ramp: 0, flags:
2019.01.15 00:42:21 3: Deckenlampe set HSV 60, 100, 100 with ramp: 0, flags:
2019.01.15 00:42:22 3: Deckenlampe set HSV 60, 0, 100 with ramp: 0, flags:
2019.01.15 00:42:22 3: Bogenlampe set HSV 0, 100, 24 with ramp: 0, flags:
2019.01.15 00:42:22 3: Bogenlampe set HSV 60, 100, 100 with ramp: 0, flags:
2019.01.15 00:42:22 3: Bogenlampe set HSV 0, 100, 100 with ramp: 0, flags:
2019.01.15 00:42:22 3: Deckenlampe set HSV 60, 100, 100 with ramp: 0, flags:
2019.01.15 00:42:22 3: Deckenlampe set HSV 60, 0, 100 with ramp: 0, flags:
2019.01.15 00:42:22 3: Bogenlampe set HSV 0, 100, 24 with ramp: 0, flags:
2019.01.15 00:42:23 3: Bogenlampe set HSV 60, 100, 100 with ramp: 0, flags:
2019.01.15 00:42:23 3: Bogenlampe set HSV 0, 100, 100 with ramp: 0, flags:
2019.01.15 00:42:23 3: Deckenlampe set HSV 60, 100, 100 with ramp: 0, flags:
2019.01.15 00:42:23 3: Deckenlampe set HSV 60, 0, 100 with ramp: 0, flags:
2019.01.15 00:42:23 3: Bogenlampe set HSV 0, 100, 24 with ramp: 0, flags:
2019.01.15 00:42:23 3: Bogenlampe set HSV 60, 100, 100 with ramp: 0, flags:
2019.01.15 00:42:23 3: Bogenlampe set HSV 0, 100, 100 with ramp: 0, flags:
2019.01.15 00:42:24 3: Deckenlampe set HSV 60, 100, 100 with ramp: 0, flags:
2019.01.15 00:42:24 3: Deckenlampe set HSV 60, 0, 100 with ramp: 0, flags:
2019.01.15 00:42:24 3: Deckenlampe set HSV 60, 100, 100 with ramp: 0, flags:
2019.01.15 00:42:24 3: Bogenlampe set HSV 0, 100, 24 with ramp: 0, flags:
2019.01.15 00:42:24 3: Bogenlampe set HSV 60, 100, 100 with ramp: 0, flags:
2019.01.15 00:42:24 3: Bogenlampe set HSV 0, 100, 100 with ramp: 0, flags:
2019.01.15 00:42:25 3: Deckenlampe set HSV 60, 100, 100 with ramp: 0, flags:
2019.01.15 00:42:25 3: Deckenlampe set HSV 60, 0, 100 with ramp: 0, flags:
2019.01.15 00:42:25 3: Bogenlampe set HSV 0, 100, 24 with ramp: 0, flags:
2019.01.15 00:42:25 3: Bogenlampe set HSV 0, 100, 24 with ramp: 0, flags:
2019.01.15 00:42:25 3: Bogenlampe set HSV 60, 100, 100 with ramp: 0, flags:
2019.01.15 00:42:25 3: Bogenlampe set HSV 0, 100, 100 with ramp: 0, flags:
2019.01.15 00:42:25 3: Deckenlampe set HSV 60, 100, 100 with ramp: 0, flags:
2019.01.15 00:42:26 3: Deckenlampe set HSV 60, 0, 100 with ramp: 0, flags:
Wie man sieht macht wohl die Deckenlampe und Bogenlampe Probleme komischerweise
habe ich aber nichts gemacht kein licht eingeschalten oder so.
Die Lampen sind so definiert (Milight)
Internals:
CONNECTION bridge-V3
DEF RGBW2 bridge-V3:192.168.178.40:8899
IP 192.168.178.40
LEDTYPE RGBW2
NAME Deckenlampe
NR 187
NTFY_ORDER 50-Deckenlampe
PORT 8899
PROTO 0
SLOT 6
STATE off
TYPE WifiLight
READINGS:
2019-01-15 23:14:45 RGB 000000
2019-01-15 23:14:45 brightness 0
2019-01-15 23:14:45 hue 0
2019-01-15 23:14:45 saturation 0
2019-01-15 23:14:45 state off
helper:
COMMANDSET on off dim dimup dimdown HSV RGB sync pair unpair
colorLevel 0
colorValue 134
llLock 0
mode 0
targetHue 60
targetSat 100
targetTime 1547590485.80732
targetVal 100
whiteLevel 0
COLORMAP:
168
167
167
166
166
165
165
164
163
163
162
162
161
161
160
159
159
158
158
157
157
156
156
155
154
154
153
153
152
152
151
150
150
149
149
148
148
147
146
146
145
145
144
144
143
142
142
141
141
140
140
139
139
138
137
137
136
136
135
135
134
133
132
132
131
130
129
129
128
127
126
126
125
124
123
122
122
121
120
119
119
118
117
116
116
115
114
113
113
112
111
110
109
109
108
107
106
106
105
104
103
103
102
101
100
99
99
98
97
96
96
95
94
93
93
92
91
90
90
89
88
87
87
86
86
85
85
84
84
83
83
82
82
81
81
80
79
79
78
78
77
77
76
76
75
75
74
74
73
73
72
71
71
70
70
69
69
68
68
67
67
66
66
65
65
64
63
63
62
62
61
61
60
60
59
59
58
58
57
57
56
55
54
54
53
52
51
50
50
49
48
47
46
46
45
44
43
42
42
41
40
39
38
38
37
36
35
34
34
33
32
31
30
30
29
28
27
26
26
25
24
23
22
22
21
20
19
18
18
17
16
15
14
14
13
12
11
10
10
9
9
8
7
6
5
4
3
2
2
1
0
254
253
252
251
250
249
248
247
246
245
244
243
243
242
241
240
239
238
237
236
235
234
233
232
231
230
229
229
228
227
226
225
224
223
222
221
220
219
218
217
216
215
215
214
213
212
211
210
209
208
207
207
206
205
205
204
203
203
202
201
201
200
199
199
198
197
197
196
195
195
194
193
193
192
191
191
190
189
189
188
187
187
186
185
185
184
183
183
182
181
181
180
179
179
178
177
177
176
175
175
174
173
173
172
171
171
170
169
169
GAMMAMAP:
0
0.182084917038383
0.470591230357907
0.820096073367633
1.21622432924022
1.65107624587364
2.11950570346478
2.61783651126499
3.14328343499055
3.69364788963403
4.26714092851856
4.86227250061747
5.47777824197178
6.112568939676
6.76569440648595
7.43631690144944
8.12369109476553
8.82714865073238
9.54608615125084
10.2799554881179
11.0282561143647
11.7905287188301
12.566350006457
13.3553283490082
14.1571001291331
14.971326642687
15.7976914549342
16.6358981290745
17.4856682626968
18.3467397808198
19.2188654442296
20.1018115396355
20.9953567242883
21.899291002556
22.8134148158172
23.7375382301393
24.6714802087245
25.615067958155
26.5681363391464
27.5305273339062
28.5020895633382
29.4826778482926
30.4721528098611
31.470380504392
32.4772320894657
33.4925835175601
34.5163152545402
35.5483120204638
36.5884625504948
37.6366593739748
38.6927986099313
39.7567797774927
40.8285056198529
41.9078819405719
42.994817451133
44.0892236287856
45.1910145838062
46.3001069353943
47.4164196955005
48.5398741599513
49.6703938062953
50.8079041978503
51.9523328934805
53.1036093626722
54.2616649055192
55.4264325772608
56.5978471170475
57.7758448806357
58.9603637767409
60.1513432067978
61.3487240079
62.5524483987055
63.7624599281173
64.9787034265577
66.2011249596724
67.429671784312
68.6642923066494
69.9049360423029
71.1515535783445
72.4040965370806
73.6625175415008
74.9267701822992
76.1968089863762
77.4725893867394
78.7540676937228
80.0412010674534
81.3339474914964
82.6322657476148
83.9361153915856
85.2454567300145
86.5602507980997
87.8804593382937
89.2060447798182
90.5369702189896
91.8731994003132
93.21469669831
94.5614271000383
95.9133561882787
97.2704501253487
98.6326756375187
100
hlCmdQueue:
llCmdQueue:
Attributes:
devStateIcon {Color_devStateIcon(ReadingsVal($name,"RGB","000000"))}
mqttDefaults base={"Smarthome/licht/$device/$reading"}
mqttPublish *:topic={$base}
mqttSubscribe state:stopic=Smarthome/licht/Deckenlampe/set dim:stopic=Smarthome/licht/Deckenlampe/dim RGB:stopic=Smarthome/licht/Deckenlampe/RGB HSV:stopic=Smarthome/licht/Deckenlampe/HSV
room Licht
webCmd on:off:dim:RGB ffffff:RGB ff0000:RGB 00ff00:RGB 0000ff:RGB ffff00
widgetOverride dim:colorpicker,BRI,0,1,100 ct:colorpicker,CT,1700,10,6500 RGB:colorpicker,RGB
Wie gesagt habe ich die alte Version zurückgespielt und jetzt scheint es wieder zu laufen.
merkwürdig...
Sagt mir leider nichts.
Seit dem 06.12. gas es mehrere Versionen. Um es einzugrenzen, würde ich gerne wissen, ab welcher genau das beschriebene Verhalten anfängt.
Kannst Du bitte folgende Versionen (in dieser Reihenfolge) ausprobieren?
https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/10_MQTT_GENERIC_BRIDGE.pm?rev=18066&format=txt
https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/10_MQTT_GENERIC_BRIDGE.pm?rev=18067&format=txt
https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/10_MQTT_GENERIC_BRIDGE.pm?rev=18077&format=txt
Hallo
Werde ich ausprobieren und berichten danke
Gleich mit der ersten Version aus deiner Liste tritt das Problem wieder auf.
Ich werde jetzt diese beiden Lampen aus meiner Konfiguration rausnehmen und
beobachten ob dann das Problem weiterhin besteht
Problem verstanden und kann auch nachstellen.
Du hast direkt ein 'Kreis' erzeugt.
Wenn Du per MQTT an die 'Deckenlampe' etwas sendest, z.B. an Smarthome/licht/Deckenlampe/RGB, dann wird ein Reading namens RGB geändert, was dazuführt, dass dieser gleich an Smarthome/licht/Deckenlampe/RGB (so ist das in deinem $base definiert) und so im Kreis.
Als Lösung setze Attribut mqttForward none, dann wird es nicht weitergeleitet und der Kreis ist unterbrochen.
Warum das mit der älteren Version funktioniert hat? Bin mir nicht sicher, danke aber, das lag an einer inkorrekten Evaluierung von {$base}, vermutlich wird mit {"$base"} auch in der alten Version nicht funktionieren.
Teste bitte die angehängte Version. Damit sollen Kreise verhindert werden, aber die andere Readings, die in Folge geändert wurden, werden trotzdem gesendet (z.B. wenn RGB erhalten wurde, dann wird zwar nicht RGB gesendet, aber hue, saturation, state etc.)
mqttForward none ist weiterhin nötig, ich prüfe, ob diese künftig entfallen kann.
Einen wunderschönen guten Tag! 8)
Mir ist aufgefallen, dass die setExtension auf "1" keine Wirkung mehr zeigt.
Timer etc bleiben der Liste der Möglichkeiten fern.
Noch jemand das Problem? Betrifft aber auch native MQTT Devices.
Muss gerade mal grübeln wo es wohl thematisch rein gehört.
Hallo
Konnte inzwischen das Problem selber lösen weil deine angeängte auch keine Besserung brachte.
dazu habe ich den code etwas umgeschrieben.
Sorry für die späte Rückmeldung war in letzter Zeit ziemlich eingespannt
Ines
Hallo
Erstmal ein großes Lob an den Entwickler dieses Moduls. Echt klasse.
Ich kapier nur eines nicht ganz und zwar:
Wie bekomme ich es jetzt hin dass ein fhem device (z. B. SZ_LICHT) den Befehl 'on' bekommt also 'set SZ_LICHT on' wenn der Befehl 'on' im Topic meinZuhause/SZ_LICHT reinkommt? Was bzw. wie muss ich das beim device SZ_LICHT attr mqttSubscribe angeben?
;)
Erlaube mir zur Sondierung die Frage: Hast du mit MQTT schon Erfolge verzeichnet oder ist das der Einstieg?
Generell sollte dein SZ_LICH ein Subscribe auf meinZuhause/SZ_LICHT/set haben
Bei MQTT empfiehlt es sich ein Kommadotopic zu haben und ein Statustopic.
meinZuhause/SZ_LICHT <- da würde der Device seinen Status kund tun
meinZuhause/SZ_LICHT/set <- da kommen Schaltbefehele an
Somit machst du ein Subscribe in FHEM auf "meinZuhause/SZ_LICHT/set" und schaltest auf Topic "meinZuhause/SZ_LICHT/set".
Subscribe = Höre auf etwas in einem bestimmten Topic
Publish = Schreibe etwas in ein bestimmtest Topic
Sofern dein Device auf "on" hört würde es dann an gehen.
Wichtig ist trage dein Device noch in deiner MQTT_Generic_Bridge ein.
Den Rest (sofern ich nun nix vergessen habe) übernimmt dann das Modul.
Hallo Master Nick
Danke für deine Antwort.
Mit MQTT kenne ich mich bereits einigermaßen aus. Habe auch die 3 teilige Einführung gelesen...
Publishen funktioniert nur mit dem subscriben habe ich noch kleine Schwierigkeiten.
Werd ich morgen gleich ausprobieren. Hab leider Nachtschicht :(
Auf jeden Fall danke für deine Erklärung :)
Kein Thema!
Du kannst auch mal mittels "list SZ_LICHT" mal zeigen was dein Gerät so an Eigenschaften hat - dann kann ich bei Problemen noch mehr sagen als so.
Hallo Nick,
bin gerade in der Arbeit dazu gekommen das mal zu testen aber es funktioniert irgendwie nicht...
habe es mit dem Rollo im Wohnzimmer probiert.
Hier ist das list vom Rollo:
Internals:
DEF 050DF2F8
FUUID 5c45aee9-f33f-19dd-77df-b9ddc1f08b7a0bbe
IODev TCM_ESP3_0
LASTInputDev TCM_ESP3_0
MSGCNT 51
NAME WZ_ROLLO_LI
NR 76
NTFY_ORDER 50-WZ_ROLLO_LI
STATE 87
TCM_ESP3_0_DestinationID FFFFFFFF
TCM_ESP3_0_MSGCNT 51
TCM_ESP3_0_PacketType 1
TCM_ESP3_0_RSSI -80
TCM_ESP3_0_ReceivingQuality good
TCM_ESP3_0_RepeatingCounter 0
TCM_ESP3_0_SubTelNum 6
TCM_ESP3_0_TIME 2019-01-28 23:19:50
TYPE EnOcean
OLDREADINGS:
READINGS:
2019-01-28 23:19:50 anglePos -90
2019-01-28 23:19:50 block unlock
2019-01-28 23:19:50 endPosition not_reached
2019-01-28 23:19:50 position 87
2019-01-28 23:19:50 state stop
2019-01-28 23:19:50 statePosition 87
helper:
Attributes:
IODev TCM_ESP3_0
alias Wohnzimmer Rollo links
cmdIcon up:fts_shutter_up stop:fts_shutter_manual down:fts_shutter_down
comMode confirm
eep A5-3F-7F
eventMap opens:up closes:down
fp_Home 398,662,7,wz_rollo_li,
group Rollos
manufID 00D
model Eltako_FSB61
mqttDefaults pub:qos=0 sub:qos=2 retain=0
mqttPublish state:topic=100/1/user/WZ_ROLLO_LI
mqttSubscribe state:stopic={"100/1/user/WZ_ROLLO_LI/set"}
room Rollos,Wohnzimmer
shutTime 35
shutTimeCloses 40
stateFormat statePosition
subDef FFB42F83
subType manufProfile
userReadings statePosition {
if(ReadingsVal($name,"state","0") eq "up"
or ReadingsVal($name,"state","0") eq "down"
or ReadingsVal($name,"state","0") eq "closed")
{ReadingsVal($name,"state",0)}
elsif(ReadingsVal($name,"state",0) eq "open_ack" or ReadingsVal($name,"state","0") eq "open") {
"opened"
}
else {ReadingsVal($name,"position",0)};;}
userattr Benutzerdefinierte Benutzerdefinierte_map Bereich Bereich_map Bereichaaa Bereichaaa_map Raum Raum_map Rollos Rollos_map WZ_ROLLO_LI WZ_ROLLO_LI_map structexclude
verbose 2
webCmd control:up:stop:down
widgetOverride control:slider,0,10,100
sehe ich das jetzt falsch oder müsste bei einem "up" oder "down" im Topic 100/1/user/WZ_ROLLO_LI/set sich das Rollo entweder nach unten oder oben bewegen?
Zur Info: IODev der Bridge ist MQTT2_Client und dieser ist mit einem externem mosquitto- Server erfolgreich verbunden.
Hier noch das list der MQTT_GENERIC_BRIDGE:
Internals:
CFGFN
FUUID 5c4ed36a-f33f-19dd-9985-bcd534e7c98b6fad
IODev MQTT2_BROKER
NAME mqtt_generic_bridge
NR 7761
NTFY_ORDER 50-mqttGeneric
STATE ???
TYPE MQTT_GENERIC_BRIDGE
devspec .*
prefix mqtt
CHANGED:
incoming-count: 176
incoming-count: 177
incoming-count: 178
incoming-count: 179
incoming-count: 180
READINGS:
2019-01-28 23:31:19 device-count 2
2019-01-28 23:31:30 incoming-count 180
2019-01-28 23:19:50 outgoing-count 59
2019-01-28 23:19:50 transmission-state outgoing publish sent
2019-01-28 11:03:22 updated-reading-count 0
2019-01-28 11:03:22 updated-set-count 0
devices:
SZ_ROLLO_FENSTER:
:publish:
userState:
last 1548707944.24268
mode R
topic 100/1/user/SZ_ROLLO_FENSTER
:subscribe:
WZ_ROLLO_LI:
:defaults:
pub:qos 0
pub:retain 0
sub:qos 2
sub:retain 0
:publish:
statePosition:
last 1548713990.89712
mode R
topic 100/1/user/WZ_ROLLO_LI
:subscribe:
HASH(0x6c52ae0)
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 MQTT2_BROKER
room MQTT
Und wie man sieht bekommt die Bridge auch etwas der Messages mit, nur eben das set funktioniert leider nicht
Lg Daniel
Muss FSB61 nicht mit set position xxx anstatt set xxx gesteuert werden (ich verwende FSB14, dort ist das so)? Letzteres hast in dem subscribe definiert.
Hallo hexenmeister.
Erstmal Gratulation zu deinem super Modul und danke für die Zeit (und wahrscheinlich auch Nerven) die du investiert hast. Echt cool.
Nein bei meinen Aktoren funktioniert das mit up, down, stop usw. diese Befehle sind auch wie du im Bild sehen kannst bei den set Befehlen dabei.
Lg
Danke
Dann sollte das senden von up, down etc. bei den Geräte ankommen.
Was wird ausgegeben bei get devinfo an der bridge?
Bei devinfo kommt folgendes:
WZ_ROLLO_LI
publish:
statePosition => 100/1/user/WZ_ROLLO_LI (mode: R; qos: 0)
subscribe:
state <= 100/1/user/WZ_ROLLO_LI/set (mode: S)
Ich kann es nicht glauben aber jetzt funktioniert es. Hab beim MQTT2_CLIENT autocreate ausgeschaltet und seit dem funktionierts.
Ich bin sooooo happy. :) Danke für eure Hilfe alle :)
Ich hab da aber trotzdem noch eine Frage und zwar taucht bei mir des öfteren im FHEM-Logfile folgende 2 Zeilen auf:
SERVERIP:PORT disconnected, waiting to reappear (MQTT2_BROKER)
SERVERIP:PORT reappeared (MQTT2_BROKER)
(MQTT2_BROKER ist mein MQTT2_CLIENT)
Ist das normal?
Lg
Zitat von: XxX_Cobra_XxX am 29 Januar 2019, 08:29:52
Ich kann es nicht glauben aber jetzt funktioniert es. Hab beim MQTT2_CLIENT autocreate ausgeschaltet und seit dem funktionierts.
Jep, ist ein bekanntes Problem, ist im Forum bereits beschrieben. Dank Rudi gibt es jedoch schon eine Lösung. Gestern habe ich dann eine neue Version der Bridge eingecheckt, damit sollte es auch mit autocreate funktionieren. Sinnvoll ist das jedoch nicht, da autocreate (in diesem Fall) unnötige (zusätzliche) MQTT2_DEVICE-Instanzen erstellen würde.
Zitat von: XxX_Cobra_XxX am 29 Januar 2019, 08:36:58
Ich hab da aber trotzdem noch eine Frage und zwar taucht bei mir des öfteren im FHEM-Logfile folgende 2 Zeilen auf:
SERVERIP:PORT disconnected, waiting to reappear (MQTT2_BROKER)
SERVERIP:PORT reappeared (MQTT2_BROKER)
(MQTT2_BROKER ist mein MQTT2_CLIENT)
Ist das normal?
Lg
Nein. Die Verbindung zum Broker geht verloren. Kann ja mal passieren, aber oft sollte das nicht sein.
Sorry habe meinen Thread falsch veröffentlicht unter https://forum.fhem.de/index.php?topic=96657.msg897294#msg897294 (https://forum.fhem.de/index.php?topic=96657.msg897294#msg897294).
Kann mir trotzdem jemand seine funktionierende Schalter-Device-Definition mit mqttSubscribe und mqTTPublish sowie den passenden Node-Red-Flow zur Verfügung stellen? Bei mir haut das nicht hin und ich lande immer wieder in einer Endlos-Schleife.
Vielen Dank im Voraus.
Frank
Zitat von: hexenmeister am 29 Januar 2019, 09:35:35
Jep, ist ein bekanntes Problem, ist im Forum bereits beschrieben. Dank Rudi gibt es jedoch schon eine Lösung. Gestern habe ich dann eine neue Version der Bridge eingecheckt, damit sollte es auch mit autocreate funktionieren. Sinnvoll ist das jedoch nicht, da autocreate (in diesem Fall) unnötige (zusätzliche) MQTT2_DEVICE-Instanzen erstellen würde.
Super danke für die Info
mit heutigem Update kommt folgende Fehlermeldung ununterbrochen:
ERROR: >< returned by the MQTT_GENERIC_BRIDGE ParseFn is invalid, notify the module maintainer
Nachstellen konnte ich nicht (bitte in solchen Fällen etwas mehr Info), denke jedoch gefixt zu haben.
Also zunächst mal einen riesen Dank für dieses tolle Modul - endlich eine komfortable Kopplung meiner FHEM-Instanzen :)
Nach meiner Beobachtung ist der Fehler nicht durch ein Update der Bridge sondern durch ein Update des MQTT2_DEVICE, welches ich am Montag bekommen habe, ausgelöst worden - die Bridge war in dem Updatelauf nicht mit dabei.
Der Fehler besteht leider auch nach dem Update heute weiterhin.
Ich habe zunächst nacheinander alle MQTTSubsscribe und MQTTPublish einzeln entfernt um einen Tippfehler auszuschliessen. Am Ende musste ich feststellen, dass es reicht, wenn ich die Bridge anlege. Der Fehler kommt sofort - immer mehrfach alle 10-70 Sekunden.
Vielleicht hilft es: der MQTT2_Client disconnected immer, wenn die Bridge anglegt wird, kurz.
Ich habe einen aktuellen mosquitto laufen auf den die Bridge mittels des mosquitto-Moduls connected. Alle "direkten" MQTT-Devices (tasmota und zigbee2mqtt) sind als MQTT2_Device angelegt und hängen an einem MQTT2_Client. Die Bridge übernimmt "nur" den Austausch von Sets und Readings zwischen den verschiedenen FHEM-Instanzen.
Auch bei verbose 5 bleibt es bei der selben Fehlermeldung, Freezes löst der Fehler nicht aus - mehr fiel mir zur Analyse leider nicht ein :'(
ja, Fehler leider immer noch vorhanden.
List Bridge:
Internals:
FUUID 5c433a92-f33f-5738-fdfd-432d50910ec53d4a
IODev myBroker
NAME mqttGeneric
NR 708
NTFY_ORDER 50-mqttGeneric
STATE IO device initialized (mqtt2)
TYPE MQTT_GENERIC_BRIDGE
devspec .*
prefix mqtt
CHANGED:
incoming-count: 1
incoming-count: 2
incoming-count: 3
incoming-count: 4
incoming-count: 5
incoming-count: 6
incoming-count: 7
incoming-count: 8
incoming-count: 9
incoming-count: 10
incoming-count: 11
incoming-count: 12
incoming-count: 13
incoming-count: 14
incoming-count: 15
READINGS:
2019-01-30 09:27:06 device-count 0
2019-01-30 09:28:57 incoming-count 15
2019-01-30 09:26:56 outgoing-count 0
2019-01-30 09:27:06 transmission-state IO device initialized (mqtt2)
2019-01-30 09:26:56 updated-reading-count 0
2019-01-30 09:26:56 updated-set-count 0
devices:
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:
DbLogExclude .*
IODev myBroker
event-on-change-reading .*
stateFormat transmission-state
verbose 0
List Server:
Internals:
CONNECTS 5
DEF 1884 global
FD 24
FUUID 5c433a93-f33f-5738-2768-0654c36e1b20da8b
NAME myBroker
NR 812
PORT 1884
STATE Initialized
TYPE MQTT2_SERVER
READINGS:
2019-01-30 09:27:12 RETAIN {"tele/kuehlschrank/LWT":"Online","tele/mopedlader/LWT":"Online","tele/outlander/LWT":"Online","tele/sonoff-3522/LWT":"Online","tele/trockner/LWT":"Online"}
2019-01-30 09:27:11 nrclients 5
2019-01-30 09:26:57 state Initialized
clients:
myBroker_192.168.0.186_6489 1
myBroker_192.168.0.188_49482 1
myBroker_192.168.0.189_49479 1
myBroker_192.168.0.196_52402 1
myBroker_192.168.0.197_49268 1
retain:
tele/kuehlschrank/LWT:
ts 1548836832.41329
val Online
tele/mopedlader/LWT:
ts 1548836831.56402
val Online
tele/outlander/LWT:
ts 1548836832.02279
val Online
tele/sonoff-3522/LWT:
ts 1548836831.78652
val Online
tele/trockner/LWT:
ts 1548836831.85998
val Online
Attributes:
DbLogExclude .*
autocreate 1
group Zentrale
icon mqtt
room Zentrale
verbose 0
List Client:
Internals:
BUF
FD 68
NAME myBroker_192.168.0.186_6489
NR 887
PEER 192.168.0.186
PORT 6489
SNAME myBroker
SSL
STATE Connected
TEMPORARY 1
TYPE MQTT2_SERVER
WBCallback
cflags 238
cid DVES_C22239
keepalive 10
lastMsgTime 1548837092.14639
lwt tele/kuehlschrank/LWT:Offline
protoNum 4
protoTxt MQTT
usr DVES_USER
READINGS:
2019-01-30 09:27:11 state Connected
subscriptions:
cmnd/DVES_C22239/# 1548836832.45794
cmnd/kuehlschrank/# 1548836832.45773
cmnd/sonoffs/# 1548836832.45788
Attributes:
room hidden
Hier nochmal ein Logauszug mit verbose 5:
2019.01.30 21:26:28 1: ERROR: >< returned by the MQTT_GENERIC_BRIDGE ParseFn is invalid, notify the module maintainer
2019.01.30 21:26:28 5: End notify loop for MQTT2_DVES_E895AC
2019.01.30 21:26:28 5: End notify loop for Verbrauch
2019.01.30 21:26:28 5: Starting notify loop for Verbrauch, 1 event(s), first is MQTT2_DVES_E895AC.SENSOR_ENERGY_Power: <html><div style="width:500px; text-align:center; border: 1px solid #ccc; background:-webkit-linear-gradient(left, red 0%, rgba(0,0,0,0) 0%)">0 Watt</div></html>
2019.01.30 21:26:28 5: Starting notify loop for MQTT2_DVES_E895AC, 3 event(s), first is SENSOR_Time: 2019-01-30T21:26:29
2019.01.30 21:26:28 1: ERROR: >< returned by the MQTT_GENERIC_BRIDGE ParseFn is invalid, notify the module maintainer
2019.01.30 21:26:28 5: End notify loop for MQTT2_DVES_E895AC
2019.01.30 21:26:28 5: createNotifyHash
2019.01.30 21:26:28 5: Starting notify loop for MQTT2_DVES_E895AC, 4 event(s), first is STATE_Wifi_RSSI: 86
Habe mal eine Frage zu dem Modul.
Bin gerade dabei den Einsatz des Moduls zu testen.
In dem Zuge mache ich mir auch schon länger Gedanken über meine "MQTT - Topic - Struktur".
Ich würde gerne einige Readings über das Modul in mehr als ein Topic Publishen.
Ist das möglich?
Wenn ich 2 Einträge für ein Reading mache nimmt das Modul den letzten Eintrag.
Ist es überhaupt vorgesehen, dass man ein Reading (mehrere) in mehrere Topics published?
Beispiel:
Gewünscht wäre das reading "temperature" in die beiden unten genannte Topics zu publishen.
temperature:topic={"fhem/lacrosse/$device/$reading"} temperature:topic={"smarthome/buero/$reading"}
Danke und Gruß,
jostereo
Moin,
aus meiner Sicht wäre es einfacher die Devices auf ein und das selbe Topic zu subscriben, als mehrfach das gleiche ins MQTT zu publishen.
Oder spricht da was gegen?
Zitat von: jostereo am 06 Februar 2019, 12:33:10
Habe mal eine Frage zu dem Modul.
Bin gerade dabei den Einsatz des Moduls zu testen.
In dem Zuge mache ich mir auch schon länger Gedanken über meine "MQTT - Topic - Struktur".
Ich würde gerne einige Readings über das Modul in mehr als ein Topic Publishen.
Ist das möglich?
Wenn ich 2 Einträge für ein Reading mache nimmt das Modul den letzten Eintrag.
Ist es überhaupt vorgesehen, dass man ein Reading (mehrere) in mehrere Topics published?
Beispiel:
Gewünscht wäre das reading "temperature" in die beiden unten genannte Topics zu publishen.
temperature:topic={"fhem/lacrosse/$device/$reading"} temperature:topic={"smarthome/buero/$reading"}
Danke und Gruß,
jostereo
Ohh sorry muss mich da korrigieren.
Die Frage wurde schonmal gestellt und auch von Hexenmeister bereits beantwortet:
https://forum.fhem.de/index.php/topic,91642.msg858587.html#msg858587
Es wurde zwar noch keine endgültige Erfolgsmeldung gegeben.
Gehe aber mal davon aus, dass es mit dem Tipp gehen sollte.
Ich teste das heute Abend mal.
Gruß,
jostereo
Zitat von: jostereo am 06 Februar 2019, 13:35:03
Gehe aber mal davon aus, dass es mit dem Tipp gehen sollte.
Ich hab's damals getestet ;)
Zitat von: hexenmeister am 06 Februar 2019, 20:44:28
Ich hab's damals getestet ;)
@Hexenmeister
Habs jetzt gerade auch getestet.
Mir ist dabei aufgefallen das es mit "festen" Topics (wie du im Beispiel hattest) super funktioniert.
Allerdings scheint es nicht mit den "Ersetzungsvariablen" zu funktioniern.
Beispiel:
humidity:expression={"fhem/lacrosse/temp/humidity"=>$message, "smarthome/lacrosse/temp/humidity"=>$message}Funktioniert
humidity:expression={"fhem/lacrosse/$device/$reading"=>$message, "smarthome/lacrosse/$device/$reading"=>$message}Funktioniert nicht.
Ist das so gewollt oder mache ich da noch einen Fehler?
Gruß,
jostereo
Teste bitte noch mal morgen nach dem Update.
Zitat von: hexenmeister am 09 Februar 2019, 23:21:09
Teste bitte noch mal morgen nach dem Update.
Hi Hexenmeister,
die Anpassung durch das Update von dir heute funktioniert.
Die Variablen werden sauber ersetzt.
Vielen Dank für die schnelle Anpassung.
Hallo,
blöde Frage, aber bei mir steht als STATE immer nur "???". Kein "Initialized" oder "Open" oder ähnliches.
An was liegt das bzw. wie kann ich es ändern?
Danke für die Antwort.
Grüße Frank
Die Bridge nutzt den STATE nicht von alleine. Daher bleibt das undefiniert. Wenn man was anderes dort haben will, verwendet man dafür vorgesehene FHEM-Mittel.
attr <bridge-name> stateFormat Mickey Mouse
oder eben
attr <bridge-name> stateFormat dev: device-count in: incoming-count out: outgoing-count
Hallo Hexenmeister
vielen Dank!
Grüße
Hallo zusammen,
ich versuche nun seit längerem Velux Rollläden und Fenster über das KLF und MQTT an mein Loxone System anzubinden. Dazu habe ich entsprechend einer Anleitung eine MQTT_GENERIC_BRIDGE definiert und diese konfiguriert, sodass sie mir alle Readings der 2 Fenster und 2 Rollläden liefert. Ich kann nun auch schon die aktuelle Position aller 4 Dinger in meinem Loxone System sehen.
Hier das Listing meiner MQTT_GENERIC_BRIDGE Definition:
Internals:
FUUID 5c66fde9-f33f-148c-0155-86d01b75ecd2f71e
IODev lb_mosquitto
NAME mqttGeneric
NR 30
NTFY_ORDER 50-mqttGeneric
STATE ???
TYPE MQTT_GENERIC_BRIDGE
devspec .*
prefix mqtt
READINGS:
2019-02-15 21:52:41 device-count 0
2019-02-15 21:49:27 incoming-count 0
2019-02-15 21:52:13 outgoing-count 53
2019-02-15 21:52:41 transmission-state unsubscription acknowledged
2019-02-15 21:49:27 updated-reading-count 0
2019-02-15 21:49:27 updated-set-count 0
devices:
:global:
:defaults:
pub:qos 0
pub:retain 1
sub:qos 2
sub:retain 1
:publish:
*:
mode R
topic {"Terrasse/$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 *
message_ids:
subscribe:
subscribeExpr:
subscribeQos:
Attributes:
IODev lb_mosquitto
globalDefaults sub:qos=2 pub:qos=0 retain=1
globalPublish *:topic={"Terrasse/$device/$reading"}
Ebenso ein Listing als Beispiel für einen Rollladen:
Internals:
CHANGED
DEF 192.168.0.147:51200 0
DeviceName 192.168.0.147:51200
FUUID 5c66f796-f33f-148c-8c18-0e90a51d5efc8bfd
IODev Velux
LASTInputDev Velux
MSGCNT 5
NAME Velux_0
NR 21
NodeID 0
STATE 0 stop
TYPE KLF200Node
Velux_MSGCNT 5
Velux_TIME 2019-02-15 21:52:10
READINGS:
2019-02-15 21:52:10 MP 51173
2019-02-15 21:52:10 MPtarget 51200
2019-02-15 18:32:06 actuatorAddress 6cab30
2019-02-15 18:32:06 backboneReferenceNumber 781c66
2019-02-15 18:33:17 buildNumber 16
2019-02-15 18:51:53 execution stop
2019-02-15 18:32:06 ioManufacturer VELUX
2019-02-15 18:51:12 lastCommandOriginator SAAC
2019-02-15 18:51:12 lastControl FHEM
2019-02-15 18:51:53 lastMasterExecutionAddress abc5b1
2019-02-15 18:51:53 lastRunStatus EXECUTION COMPLETED
2019-02-15 18:51:53 lastStatusReply COMMAND COMPLETED OK
2019-02-15 18:33:17 model VELUX SML Roller Shutter
2019-02-15 18:33:17 name Rollladen rechts
2019-02-15 18:32:06 nodeTypeSubType Roller Shutter
2019-02-15 18:33:17 nodeVariation NOT SET
2019-02-15 18:51:53 operatingState Done
2019-02-15 18:51:53 pct 0
2019-02-15 18:33:17 powerMode ALWAYS ALIVE
2019-02-15 18:33:17 productCode SML
2019-02-15 18:33:17 productGroup 1
2019-02-15 18:33:17 productType 1
2019-02-15 18:33:17 production 2017 week 33
2019-02-15 18:51:53 remaining 0
2019-02-15 18:33:17 serial 86 12820 90 17 33 887
2019-02-15 21:52:10 sessionID 18
2019-02-15 18:51:53 sessionInformationCode 20000500
2019-02-15 21:52:10 sessionStatusOwner USER
2019-02-15 18:51:53 state off
2019-02-15 18:51:12 target 0
2019-02-15 18:51:12 targetArrival 2019-02-15 18:51:52
2019-02-15 18:33:17 velocity Supported
Attributes:
alias Rollladen rechts
devStateIcon .*up:fts_shutter_up:toggle .*down:fts_shutter_down:toggle \d.stop:fts_window_2w:toggle 1\d.stop:fts_shutter_10:toggle 2\d.stop:fts_shutter_20:toggle 3\d.stop:fts_shutter_30:toggle 4\d.stop:fts_shutter_40:toggle 5\d.stop:fts_shutter_50:toggle 6\d.stop:fts_shutter_60:toggle 7\d.stop:fts_shutter_70:toggle 8\d.stop:fts_shutter_80:toggle 9\d.stop:fts_shutter_90:toggle 100.stop:fts_shutter_100:toggle
room Terrasse
stateFormat pct execution
webCmd pct
Was ich jetzt aber nicht schaffe ist, der umgekehrte Weg. Ich möchte also auf dem Loxone System den Prozentwert eingeben der angefahren werden soll und das Ding fährt dann dort hin. Ich weiß nicht wie das Subscribe genau funktioniert und wie ich den Befehl eingeben muss. Ein globales Subscribe analog dem globalen Reading gibt es ja nicht.
Das Topic (also aktuell das Reading) für die Prozentausgabe lautet Terrasse/Velux_0/pct. Ich nehme also an, dass man dann auf dieses Topic auch ein set ausführen muss. In FHEM heißt es set Velux_0 pct xxx wobei xxx für den Prozentwert steht.
List für den Mosquitto
Internals:
DEF 192.168.0.146:1883
DeviceName 192.168.0.146:1883
FD 4
FUUID 5c66fddf-f33f-148c-5e9d-99f6a72f1f9a10c0
NAME lb_mosquitto
NOTIFYDEV global
NR 29
NTFY_ORDER 50-lb_mosquitto
PARTIAL
STATE opened
TYPE MQTT
buf
msgid 6
ping_received 1
timeout 60
READINGS:
2019-02-15 22:01:28 connection active
2019-02-15 21:49:28 state opened
messages:
Attributes:
Laufen tut das ganze über auf einem Loxberry wo der MQTT Gateway läuft.
Bitte kann mir da jemand einen Tipp geben bevor ich gänzlich verzweifle.
Danke!
ZitatEin globales Subscribe analog dem globalen Reading gibt es ja nicht.
Ich bereue mittlerweile, globalPublish eingebaut zu haben. Das war eher zum Testen und dazu gedacht, alles per MQTT raus zu pusten. Ist im Allgemeinen KEINE gute Idee.
Mit globalSubscribe wäre es dann schon grenzwertig und wird es in dieser Form nicht geben.
Beide Wege sollen an einzelnen Devices jeweils einzeln per 'mqttPublish' und 'mqttSubscribe' definiert werden.
Syntax ist in Commandref beschrieben.
Du brauchst in den Geräten etwas in der Art:
attr <name> mqttSubscribe pct:stopic=Terrasse/Velux_0/pct/set
attr <name> mqttPublish pct:topic=Terrasse/Velux_0/pct/statePublish und Subscribe auf das selbe Topic würde ich nicht tun.
Hi zusammen,
ich arbeite mich gerade langsam an das Thema MQTT ran. Aktuell probiere ich mit diesem Modul mir eine Struktur aufzubauen bzw. das Thema "Learning By Doing" zu verstehen.
Ich habe in FHEM nun ein Device, dass mehrere Readings hat, die alle mit der Bezeichnung "level" beginnen und dann durchnummeriert sind (level0, level1, level2 etc.). Ich würde nun gerne alle diese Readings per RegEx abfangen. Aber das scheint nicht zu gehen - oder ich mache es einfach falsch. Was sehr gut sein kann ;-)
Wenn ich als Attribut
level0:topic={"$base/$name"}
setze bekomme ich natürlich das Reading in MQTT.fx, dass ich zum testen verwende, angezeigt sobald sich der Status ändert. Gut soweit.
Wenn ich aber
level.*:topic={"$base/$name"}
setze (um alle Readings die mit "level" beginnen zu bekommen) passiert nichts, es kommt kein Wert bei Änderung in MQTT.fx.
Kann das Modul kein RegEx oder mache ich nur etwas falsch? Und wenn ja, was?
Danke!
Nein, RegEx wird an dieser Stelle nicht unterstützt (sonst stünde das ja in commandref, gell? ;) )
Probiere mal mit
attr <dev> mqttSubscribe *:topic={"$base/$reading"}
Zitat von: hexenmeister am 15 Februar 2019, 22:31:12
Ich bereue mittlerweile, globalPublish eingebaut zu haben. Das war eher zum Testen und dazu gedacht, alles per MQTT raus zu pusten. Ist im Allgemeinen KEINE gute Idee.
Mit globalSubscribe wäre es dann schon grenzwertig und wird es in dieser Form nicht geben.
Beide Wege sollen an einzelnen Devices jeweils einzeln per 'mqttPublish' und 'mqttSubscribe' definiert werden.
Syntax ist in Commandref beschrieben.
Du brauchst in den Geräten etwas in der Art:
attr <name> mqttSubscribe pct:stopic=Terrasse/Velux_0/pct/set
attr <name> mqttPublish pct:topic=Terrasse/Velux_0/pct/state
Danke so hat das funktioniert. Kann jetzt endlich über die MQTT meine Velux Rollläden und Fenster ansprechen.
Top Support!
Publish und Subscribe auf das selbe Topic würde ich nicht tun.
Hi,
kann man in der expression auch bspw. eigene Perl-Funktionen aufrufen?
Etwa so:
callFunction:topic={"$base/callFunction/set"} callFunction:expression={MyFunction($NAME,$value)}
Sollte funktionieren, muss aber vollqualifiziert angegeben werden, also mit Package. Etwa: main::MyFunction
Ich komme leider allein nicht weiter und benötige Unterstützung.
Meine Konfiguration:
Raspi RPI03 im EG soll mit Raspi RPI02 im Technikraum kommunizieren. Dort lauft ein 1-wire Busmaster mit mehreren DS18B20 und einem DS2406, der eine Pumpe schalten soll. Die Kommunikation soll über MQTT2 erfolgen.
Auf RPI03 ist ein MQTT2_Server und eine MQTT_GENERIC_BRIDGE.
Internals:
CONNECTS 4
DEF 1883 global
FD 65
FUUID 5c7aa366-f33f-6b6f-30ee-94bbc96e2be2933b
NAME myMQTT2_Server
NR 1739
PORT 1883
STATE Initialized
TYPE MQTT2_SERVER
READINGS:
2019-03-02 17:09:46 nrclients 0
2019-03-02 17:09:46 state Initialized
clients:
retain:
Attributes:
autocreate 1
room 9.6_System
Die Bridge
Internals:
CFGFN
FUUID 5c7aa44c-f33f-6b6f-a209-66cf32965cf10c9a
IODev myMQTT2_Server
NAME myMQTT_GenericBridge
NR 1771
NTFY_ORDER 50-myMQTT_GenericBridge
STATE dev: 2 in: 737 out: 0
TYPE MQTT_GENERIC_BRIDGE
devspec .*
prefix mqtt
CHANGED:
incoming-count: 451
incoming-count: 452
viele weiter incoming-count
incoming-count: 736
incoming-count: 737
READINGS:
2019-03-02 17:37:23 device-count 2
2019-03-02 17:58:15 incoming-count 737
2019-03-02 16:42:04 outgoing-count 0
2019-03-02 16:42:04 transmission-state IO device initialized (mqtt2)
2019-03-02 16:42:04 updated-reading-count 0
2019-03-02 16:42:04 updated-set-count 0
devices:
SW_Zirku_RPI02:
:defaults:
pub:base haus/UG/Technikraum
sub:base haus/UG/Technikraum
:publish:
:subscribe:
HASH(0x72df1e0)
Temp_Zirku_Box_RPI02:
:defaults:
pub:base haus/UG/Technikraum
sub:base haus/UG/Technikraum
:subscribe:
HASH(0x71bdb68)
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 myMQTT2_Server
room 9.6_System
stateFormat dev: device-count in: incoming-count out: outgoing-count
verbose 5
Auf RPI02 ist ein MQTT2_Client und eine MQTT_GENERIC_BRIDGE:
Internals:
BUF
DEF 192.168.178.64:1883
DeviceName 192.168.178.64:1883
FD 10
FUUID 5c759f0d-f33f-60c4-cc4b-d23771a43522e4d3
NAME myMQTT2_Client
NR 27
PARTIAL
STATE opened
TYPE MQTT2_CLIENT
WBCallback
clientId myMQTT2Client
lastMsgTime 1551546016.78529
nextOpenDelay 5
READINGS:
2019-03-02 17:04:41 state opened
Attributes:
room 9.6_System
verbose 0
Die Bridge
Internals:
FUUID 5c76e3a6-f33f-60c4-489d-87dce9715b91ee30
IODev myMQTT2_Client
NAME mqttGenericBridge
NR 28
NTFY_ORDER 50-mqttGenericBridge
STATE dev: 8 in: 0 out: 1675
TYPE MQTT_GENERIC_BRIDGE
devspec .*
prefix mqtt
READINGS:
2019-03-02 16:13:53 device-count 2
2019-03-02 15:59:08 incoming-count 0
2019-03-02 18:01:01 outgoing-count 1675
2019-03-02 18:01:01 transmission-state outgoing publish sent
2019-03-02 15:59:08 updated-reading-count 0
2019-03-02 15:59:08 updated-set-count 0
devices:
SW_Zirku:
:defaults:
pub:base haus/UG/Technikraum
sub:base haus/UG/Technikraum
:publish:
sensed.A:
last 1551546052.48048
mode R
topic haus/UG/Technikraum/SW_Zirku/sensed.A
sensed.B:
last 1551546052.48853
mode R
topic haus/UG/Technikraum/SW_Zirku/sensed.B
:subscribe:
HASH(0x17caab0)
HASH(0xa37f90)
Temp_Zirku_Box:
:defaults:
pub:base haus/UG/Technikraum
sub:base haus/UG/Technikraum
:publish:
temperature:
last 1551546061.38456
mode R
topic {"$base/Temp_Zirku_Box/temperature"}
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 myMQTT2_Client
alias MQTT generic bridge
room 9.6_System
stateFormat dev: device-count in: incoming-count out: outgoing-count
verbose 5
Die Bridge auf dem RPI02 sendet brav und soweit ich das beurteilen kann, auch das Richtige.
2019.03.02 18:03:37.003 5: MQTT_GENERIC_BRIDGE:DEBUG:> [mqttGenericBridge] publish: haus/UG/Technikraum/Temp_Zirku_Box/temperature => 22.125 (qos: 0, retain: 0)
2019.03.02 18:03:38.090 5: MQTT_GENERIC_BRIDGE:DEBUG:> [mqttGenericBridge] publish: haus/UG/Technikraum/SW_Zirku/sensed.A => 1 (qos: 0, retain: 0)
2019.03.02 18:03:38.099 5: MQTT_GENERIC_BRIDGE:DEBUG:> [mqttGenericBridge] publish: haus/UG/Technikraum/SW_Zirku/sensed.B => 1 (qos: 0, retain: 0)
Die Bridge auf dem RPI03 empfängt aber, wie ich meine, nur einen Teil davon und aktualisiert daher auch nicht das dummy.
2019.03.02 18:04:23.169 5: MQTT_GENERIC_BRIDGE: [myMQTT_GenericBridge] Parse (MQTT2_SERVER : 'myMQTT2_Server'): Msg: myMQTT2Client => haus/UG/Technikraum/SW_Zirku/sensed.A1
2019.03.02 18:04:23.179 5: MQTT_GENERIC_BRIDGE: [myMQTT_GenericBridge] Parse (MQTT2_SERVER : 'myMQTT2_Server'): Msg: myMQTT2Client => haus/UG/Technikraum/SW_Zirku/sensed.B1
2019.03.02 18:04:30.066 5: MQTT_GENERIC_BRIDGE: [myMQTT_GenericBridge] Parse (MQTT2_SERVER : 'myMQTT2_Server'): Msg: myMQTT2Client => haus/UG/Technikraum/Temp_Zirku_Box/temperature22.0625
Dummy, das aktualisiert werden soll:
Internals:
FUUID 5c76e58c-f33f-6b6f-e33a-996c02ed3ad38207
NAME Temp_Zirku_Box_RPI02
NR 1731
STATE 22.1°C
TYPE dummy
READINGS:
2019-03-02 15:59:03 temperature 22.0625
Attributes:
icon icoTemp
mqttDefaults base=haus/UG/Technikraum
mqttSubscribe temperature:topic={"$base/Temp_Zirku_Box/temperature"}
readingList temperature
room 3.4_Technik
stateFormat {sprintf("%.1f",ReadingsVal("Temp_Zirku_Box_RPI02","temperature",0))."°C"}
Internals:
FUUID 5c782ed0-f33f-6b6f-3571-a68bd4b5774ce7d0
NAME SW_Zirku_RPI02
NR 1737
STATE PIO.A 0
TYPE dummy
READINGS:
2019-03-02 17:05:24 PIO.A 0
2019-03-02 15:56:51 PIO.B 0
2019-03-02 15:58:51 sensed.A 1
2019-03-02 15:58:51 sensed.B 1
2019-02-28 21:46:44 state PIO.A 0
Attributes:
mqttDefaults base=haus/UG/Technikraum
mqttSubscribe sensed.A:topic={"$base/SW_Zirku/sensed.A"}
readingList sensed.A sensed.B PIO.A PIO.B
room 3.4_Technik
setList PIO.A:0,1 PIO.B:0,1
Ich habe im Forum gesucht und alles mögliche versucht, jedoch will es einfach nicht auf Dauer funktionieren. Ich hatte eine Kommunikation erhalten, aber seit einem Restart des RPI03 klappt es nicht mehr. Bevor ich auf fhem2fehm gehe hatte ich gehofft, jemand der sich besser auskennt sieht das Problem oder kann mir einen Tip geben.
Viele Grüße Jürgen
P.S.: Ich sehe gerade, dass auf dem RPI03 noch ein MQTT2_Server angelegt wurde, der die IP des RPI02 hat aber im hidden-Raum ist. Muss das so sein?
Internals:
BUF
FD 60
NAME myMQTT2_Server_192.168.178.53_49800
NR 2005
PEER 192.168.178.53
PORT 49800
SNAME myMQTT2_Server
SSL
STATE Connected
TEMPORARY 1
TYPE MQTT2_SERVER
WBCallback
cflags 2
cid myMQTT2Client
keepalive 30
lastMsgTime 1551547246.99345
protoNum 3
protoTxt MQIsdp
READINGS:
2019-03-02 17:04:41 state Connected
subscriptions:
# 1551542681.37933
Attributes:
room hidden
Zitat von: bmwfan am 02 März 2019, 18:16:17
Ich habe im Forum gesucht und alles mögliche versucht, jedoch will es einfach nicht auf Dauer funktionieren. Ich hatte eine Kommunikation erhalten, aber seit einem Restart des RPI03 klappt es nicht mehr. Bevor ich auf fhem2fehm gehe hatte ich gehofft, jemand der sich besser auskennt sieht das Problem oder kann mir einen Tip geben.
Ich glaube, ich hatte das selbe Problem mit MQTT-Server in FHEM, es scheint als würde zwar die Nachricht übermittelt, jedoch fehlt der Wert. Das ".... => 1 ...." in der Nachricht. War bei mir ähnlich.
Da ich Docker im Einsatz habe, hatte ich mir einfach Mosquitto als Container installiert ohne weiter zu analysieren. Damit hatte es dann auf Anhieb geklappt.
Kannst ja mal zum Test Mosquitto installieren und sowohl Raspberry 1 als auch Raspberry 2 als Client konfigurieren. Alternativ gibt es auch kostenlose MQTT-Server im Internet. Zum Test allemal ausreichend. Einfach mal Google'n ... https://diyprojects.io/8-online-mqtt-brokers-iot-connected-objects-cloud/#.XHrQ-ohKg2w
Edit: habe vergessen, sollte es mit Mosquitto klappen könnte es ein Bug im Fhem-MQTT-Server sein. Bitte gib Bescheid, dann versuche ich auch mein Problem nachzustellen als Input zur weiteren Suche.
Es gibt wohl ein Problem in Zusammenarbeit von der GenericBridge und MQTT2_SERVER. Liegt recht sicher an der art, wie die Bridge mit dem Server-Modul kommuniziert. Ich werde mir das Problem ansehen, ich weiß jedoch noch nicht, wann ich dazu komme.
Hi, ich habe noch ein paar Fragen zu der Generic Bridge:
1. Ich würde den payload gerne etwas erweitern und per JSON übertragen. Auf Seite 8 habe ich die Lösung mit einer :expression gefunden, jedoch hätte ich bei Statusänderungen gerne ein payload wie diesen:
stat/home/max/Paul_f1/stat {"date":"2019-03-03 18:50:15","state":"opened"}
stat/home/max/Paul_f1/stat {"date":"2019-03-03 18:59:15","state":"closed"}
Zusätzlich fände ich eine Art heartbeat nicht schlecht:
stat/home/max/Paul_f1/stat {"date":"2019-03-03 19:56:57","state":"closed","lastOpenend":"2019-03-03 17:30:21", "RSSI":"-85.5","battery":"ok"}
Ist das möglich?
Momentan löse ich das mit einer Mischung aus DOIF und AT Befehlen. Das funktioniert ganz gut, doch wahrscheinlich wäre es mit einer Generic Bridge einfacher.
Beste Grüße
Patric
Zitat von: PPP01 am 04 März 2019, 08:43:04
Zusätzlich fände ich eine Art heartbeat nicht schlecht:
stat/home/max/Paul_f1/stat {"date":"2019-03-03 19:56:57","state":"closed","lastOpenend":"2019-03-03 17:30:21", "RSSI":"-85.5","battery":"ok"}
Ist das möglich?
Momentan löse ich das mit einer Mischung aus DOIF und AT Befehlen. Das funktioniert ganz gut, doch wahrscheinlich wäre es mit einer Generic Bridge einfacher.
das sollte über LWT (Last will and testament) möglich sein. Diese Nachricht wird gesendet wenn ein MQTT-Device offline geht oder eine definierte Zeit nicth reagiert. Heartbeat umgekehrt, sobald der Client nichts macht sendest du ein OFFLINE worauf du wiederrum reagieren könntest.
Doku MQTT2_CLIENT
lwt <topic> <message>
set the LWT (last will and testament) topic and message, default is empty.
Moin.
Ich bitte vielmals um Entschuldung, dass ich mir nicht den kompletten Thread durchgelesen habe... Schande über mein Haupt.
Ich wollte gerade mit der MQTT_GENERIC_BRIDGE experimentieren um Sensordaten auf meinen (Testaufbau) SmartMirror zu bekommen.
Bei einem:
define MQTT_Bridge MQTT_GENERIC_BRIDGE
bekomme ich immer als Antwort:
Cannot load module MQTT_GENERIC_BRIDGE
Bei einem:
reload 10_MQTT_GENERIC_BRIDGE.pm
sagt FHEM mir folgendes:
Can't continue after import errors at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 408.
BEGIN failed--compilation aborted at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 445.
Liegt das igendwie an meiner Installation? Habe auch schon die aktuelle Version vom FHEM-Server geholt. Keine Besserung.
Danke im Voraus.
Grüße^^
Zitat von: PPP01 am 04 März 2019, 08:43:04
Hi, ich habe noch ein paar Fragen zu der Generic Bridge:
1. Ich würde den payload gerne etwas erweitern und per JSON übertragen. Auf Seite 8 habe ich die Lösung mit einer :expression gefunden, jedoch hätte ich bei Statusänderungen gerne ein payload wie diesen:
stat/home/max/Paul_f1/stat {"date":"2019-03-03 18:50:15","state":"opened"}
stat/home/max/Paul_f1/stat {"date":"2019-03-03 18:59:15","state":"closed"}
Zusätzlich fände ich eine Art heartbeat nicht schlecht:
stat/home/max/Paul_f1/stat {"date":"2019-03-03 19:56:57","state":"closed","lastOpenend":"2019-03-03 17:30:21", "RSSI":"-85.5","battery":"ok"}
Ist das möglich?
Momentan löse ich das mit einer Mischung aus DOIF und AT Befehlen. Das funktioniert ganz gut, doch wahrscheinlich wäre es mit einer Generic Bridge einfacher.
Beste Grüße
Patric
Sicher, mit expression kann man sich praktisch jeden Output zusammenzimmern.
Wenn mit dem Heartbeat eine regelmäßige Nachricht gemeint ist, die auch dann versendet wird, wenn sich gar nichts geändert hat, dann geht das mit der Bridge alleine nicht.
Zitat von: roman1528 am 07 März 2019, 01:15:34
Cannot load module MQTT_GENERIC_BRIDGE
Can't continue after import errors at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 408.
BEGIN failed--compilation aborted at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 445.
Liegt das igendwie an meiner Installation? Habe auch schon die aktuelle Version vom FHEM-Server geholt. Keine Besserung.
Bridge verwendet immer (noch) das MQTT Modul, auch wenn MQTT2* als IO verwendet wird. MQTT-Modul benötigt bestimmte Perl-Bibliotheken. Vermutlich sind sie bei Dir nicht installiert. Ist im Wiki-MQTT-Eintrag alles beschrieben.
Zitat von: hexenmeister am 07 März 2019, 08:13:37
Bridge verwendet immer (noch) das MQTT Modul, auch wenn MQTT2* als IO verwendet wird. MQTT-Modul benötigt bestimmte Perl-Bibliotheken. Vermutlich sind sie bei Dir nicht installiert. Ist im Wiki-MQTT-Eintrag alles beschrieben.
Moin.
Ja.. das war's. Wer lesen kann ist klar im Vorteil ;D
Besten Dank!
Grüße^^
Habe jetzt von MQTT2_Server auf MQTT umgestellt. Jetzt klappt die Übertragung von Messdaten, jedoch das Schalten eines Schalters über einen Dummy in einer anderen Instanz (RPI02) klappt nicht. Ich habe das Beispiel in https://forum.fhem.de/index.php/topic,91642.msg841370.html#msg841370 (https://forum.fhem.de/index.php/topic,91642.msg841370.html#msg841370) nachgebildet und viele Varianten versucht, die EIN bzw. AUS-Befehle werden aber nicht übernommen.
Im ausführenden Raspi (RPI03):
Internals:
FUUID 5c7a3834-f33f-6b6f-cbc2-6c834c51d46b27bc
NAME du_ZirkuStatus_set
NR 1753
STATE EIN
TYPE dummy
READINGS:
2019-03-07 20:31:55 state EIN
Attributes:
mqttDefaults base=haus/UG/Technikraum
mqttPublish state:topic={"$base/$device/set"} state:retain=0
room 3.4_Technik,9.8.2_Dummys
setList EIN AUS und das Sendeprotokoll:
MQTT_GENERIC_BRIDGE:DEBUG:> [myMQTT_GenericBridge] publish: haus/UG/Technikraum/du_ZirkuStatus_set/set => EIN (qos: 0, retain: 0)
Das List im empfangenden Raspi (RPI02):
Internals:
FUUID 5c7a3ba0-f33f-60c4-3d40-3bc7d123b3c787e8
NAME du_ZirkuStatus_set_RPI03
NR 29
STATE AUS
TYPE dummy
READINGS:
2019-03-06 21:58:26 state AUS
Attributes:
mqttDefaults base=haus/UG/Technikraum
mqttSubscribe state:stopic={"$base/du_ZirkuStatus_set/set"}
room 9.8.2_Dummys,3.4_Technik
und das LOG:
MQTT_GENERIC_BRIDGE: [mqttGenericBridge] Parse (MQTT2_CLIENT : 'myMQTT2_Client'): Msg: myMQTT2Client => haus/UG/Technikraum/du_ZirkuStatus_set/setEIN
Hat jemand eine Idee, woran das liegt und wie ich das zum funktionieren bringe?
Grüße Jürgen
Bei mir funktioniert es mit Deinem Setup...
Erste Fhem Instanz:
defmod du_ZirkuStatus_set dummy
attr du_ZirkuStatus_set mqttDefaults base=haus/UG/Technikraum
attr du_ZirkuStatus_set mqttPublish state:topic={"$base/$device/set"} state:retain=0
attr du_ZirkuStatus_set setList EIN AUS
Zweite Fhem Instanz:
defmod du_ZirkuStatus_set_R dummy
attr du_ZirkuStatus_set_R mqttDefaults base=haus/UG/Technikraum
attr du_ZirkuStatus_set_R mqttSubscribe state:stopic={"$base/du_ZirkuStatus_set/set"}
Habe allerdings nicht ganz aktuellen Stand, MQTT und MQTT_GENERIC_BRIDGE Module sind natürlich aktuell.
Edit: Ich teste mit MQTT. Dein Log für 2. Raspi deutet jedoch auf MQTT2
MQTT_GENERIC_BRIDGE: [mqttGenericBridge] Parse (MQTT2_CLIENT : 'myMQTT2_Client'): Msg: myMQTT2Client => haus/UG/Technikraum/du_ZirkuStatus_set/setEIN
Da gab es ein Problem. Probiere mal morgen nach dem Update. s. https://forum.fhem.de/index.php?topic=98249.new#new
@hexenmeister:
Nach dem Update von gestern kann ich das Gerät am RPI02 vom RPI03 aus schalten. Besten Dank. Verwende am RPI03 MQTT und am RPI02 MQTT2_Client.
Nun mal sehen, wie stabil die Verbindung ist.
Grüße Jürgen
@hexenmeister:
Die Übertragung hängt sich immer noch ab und zu auf. Nach restart des Haupt-Fhem, auf dem MQTT-Server läuft, geht sie wieder. Im LOG ist kein Fehler sichtbar, lediglich die Messwerte kommen nicht mehr an.
Du meintest, MQTT2_Client könnte in MQTT getauscht werden. Ich bin mir aber nicht im klaren, ob ich dann MQTT_DEVICE's oder MQTT_BRIDGE's zusätzlich zur MQTT_GENERIC_BRIDGE für meinen 1-wire Schalter und die Temperatursensoren benötige.
Werde aus dem Wiki nicht schlau. Das MQTT_Gateway ist doch die GENERIC_BRIDGE, oder nicht? Wenn ja, brauche ich für ein physikalisches Device wie einen 1-wire Schalter oder Sensor jeweils ein eigenes MQTT_Device und für jeweils ein FHEM-Device (vermute z.B. ein DOIF...) eine MQTT_BRIDGE?
Grüße Jürgen
Hallo,
anscheinend gibt es immer noch Probleme zw. der GenericBridge und MQTT2* Module. Mir fehlt gerade leier die Zeit, mich damit auseinander zu setzen.
Versuche doch auf der anderen Seite auch mit dem MQTT Modul. Würde mich interessieren, ob dann alles stabil wird. Meine Umgebung läuft in dieser Konstellation seit Monaten problemlos.
Wenn Du MQTT2_DEVICE-Geräte hast, musst Du diese dann natürlich umstellen. Am besten dann alles mit Hilfe von GenericBridge machen, sie kann alle Device-Module (MQTT_DEVICE, MQTT_BRIDGE, MQTT2_DEVICE) funktional ersetzen.
ZitatDas MQTT_Gateway ist doch die GENERIC_BRIDGE, oder nicht?
Ich würde sagen, der Gateway ist entweder MQTT2_CLIENT oder MQTT. Die GenericBridge vermittelt innerhalb von FHEM. MQTT_DEVICES brauchst Du nicht, diese Rolle können Dummy-Geräte einnehmen. Was Du mit DOIF machen willst, ist mir nicht klar. Aber ich kenne mich da nicht aus, ich verwende selbst kein DOIF.
Beispiel für einen Sensore, die per MQTT seine Werte empfängt. Kein 1wire, aber prinzipiell besteht da kein Unterschied.
defmod DG_FL_PIR01 dummy
attr DG_FL_PIR01 alias Bewegungsmelder Flur DG
attr DG_FL_PIR01 group Bewegung und Licht
attr DG_FL_PIR01 icon motion_detector
attr DG_FL_PIR01 mqttDefaults base={"haus/dg/fl"}
attr DG_FL_PIR01 mqttSubscribe *:topic={"$base/pir01/$reading"}
attr DG_FL_PIR01 readingList brightness motion
attr DG_FL_PIR01 room Flur DG
attr DG_FL_PIR01 stateFormat Licht: brightness, Motion: motion
Hier noch ein Beispiel mit Onewire. Die Hardware ist ein ESP mit ESPEasy drauf.
defmod HA_Heizung dummy
attr HA_Heizung alias Heizung Temperaturen
attr HA_Heizung group Warmwasser
attr HA_Heizung icon sani_buffer_temp_all
attr HA_Heizung mqttDefaults base={"haus/anschlussraum"}
attr HA_Heizung mqttSubscribe Fernwaerme-Ruecklauf-Gesamt:topic={"$base/heizung/Fernwaerme_Ruecklauf_Gesamt/temperature"}\
Fernwaerme-Ruecklauf-Heizung:topic={"$base/heizung/Fernwaerme_Ruecklauf_Heizung/temperature"}\
Fernwaerme-Ruecklauf-Warmwasser:topic={"$base/heizung/Fernwaerme_Ruecklauf_Warmwasser/temperature"}\
Fernwaerme-Vorlauf-Warmwasser:topic={"$base/heizung/Fernwaerme_Vorlauf_Warmwasser/temperature"}\
Fernwaerme-Vorlauf_Heizung:topic={"$base/heizung/Fernwaerme_Vorlauf_Heizung/temperature"}\
Kaltwasser-Anschluss:topic={"$base/heizung/Kaltwasser_Anschluss/temperature"}\
Warmwasser-Entnahme:topic={"$base/heizung/Warmwasser_Entnahme/temperature"}\
Warmwasser-Rueckfluss:topic={"$base/heizung/Warmwasser_Rueckfluss/temperature"}\
Warmwasser-Speicher:topic={"$base/heizung/Warmwasser_Speicher/temperature"}\
Warmwasser-Speicher-Oben:topic={"$base/heizung/Warmwasser_Speicher_Oben/temperature"}\
rssi:topic={"$base/system/RSSI"}
attr HA_Heizung room Heizung
Habe auf MQTT zur MQTT_Generic_Bridge auf RPI03 und RPI02 umgestellt. Läuft seit 3 Tagen ohne jede Probleme.
Ich wollte als nächstes den eBUS meiner Vaillant Heizung anschliessen. Dazu gibt es ein Modul, das inzwischen mit MQTT funktioniert und ein Template von Rudolf.
Siehe Links: https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#eBus (https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#eBus) und https://wiki.fhem.de/wiki/MQTT2_DEVICE#attrTemplate (https://wiki.fhem.de/wiki/MQTT2_DEVICE#attrTemplate)
So wie ich das verstehe, allerdings nur mit MQTT2-Device. Das bedeutet, dass ich für den eBUS zusätzlich zur Generic-Bridge ein MQTT2-Device definieren muss, auf das ich dann das Template anwenden kann? Das Device stört dann auch nicht die 1-Wire Übertragung über MQTT?
Grüße Jürgen
Zitat von: bmwfan am 12 März 2019, 22:27:53
Ich wollte als nächstes den eBUS meiner Vaillant Heizung anschliessen. Dazu gibt es [...]
Im Prinzip müßte das auch in der "alten" MQTT-Welt gehen, aber die Datenstrukturen, die der ebus-Dämon liefert, sind nicht ganz trivial (m.E. jedenfalls).
Vorschlag: Du kannst auch die subscriptions von MQTT2_CLIENT so einschränken, dass nur ebus-Nachrichten durchkommen, dann kannst du da autocreate auf complex stellen und erst mal sehen, was das so anlegt.
Wenn du dann noch Lust dazu hast, kannst du das ja nach "MQTT-alt" übersetzen ;) .
Grundsätzlich wäre ich an einem Erfahrungsbericht sehr interessiert, wie das geklappt hat, dann würde ich das ggf. als Tipp noch ins Wiki zu dem ebus-Teil aufnehmen. (Bitte dann aber in der Heizungs-Abteilung, da gibt es einen Thread, der sich mit den ebus-templates befaßt).
GenericBridge kann vollständig andere MQTT-DEVICE/BRIDGE-Module funktional ersetzen. Man muss aber die Datenstrukturen kennen und per Hand anlegen. Evtl. wirklich temporär mit zusätzlichen MQTT2_CLIENT und MQTT2_DEVICE Daten sammeln und dann subscribe-attribute für GenericBridge erstellen.
Sehr interessant wäre es natürlich trotzdem, warum Bridge in Deiner Konstellation mit MQTT2* nicht stabil läuft... >:(
Zitat von: hexenmeister am 13 März 2019, 15:52:18
Sehr interessant wäre es natürlich trotzdem, warum Bridge in Deiner Konstellation mit MQTT2* nicht stabil läuft... >:(
Das ist in der Tat ein interessanter Punkt.
Zitat von: hexenmeister am 13 März 2019, 15:51:06
GenericBridge kann vollständig andere MQTT-DEVICE/BRIDGE-Module funktional ersetzen. Man muss aber die Datenstrukturen kennen und per Hand anlegen. Evtl. wirklich temporär mit zusätzlichen MQTT2_CLIENT und MQTT2_DEVICE Daten sammeln und dann subscribe-attribute für GenericBridge erstellen.
Na ja, da man im Ergebnis sowieso "irgendein" Device braucht, um die ganzen gesammelten Daten "dranzuhängen", kann man auch gleich MQTT2_DEVICE nehmen. Das "Problem" ist ja nur, dass sich autocreate und die GenericBridge nach meinem Kenntnisstand nicht wirklich gut vertragen.
ABER: man kann die Subscriptions in MQTT2_CLIENT ja derart einschränken, dass "sonst nichts" durchkommt außer den ebus-Geschichten. Dann sollte es mit autocreate eigentlich "ungefährlich" sein, oder habe ich was am Prinzip nicht verstanden?
Kann man natürlich. Ich mag eher Dummies, scheint mit transparenter und leichtgewichtiger, ist aber eine reine Geschmackssache.
Paralleler Einsatz von zwei IO-Typen wäre sicher nicht das gelbe vom Ei. Höchtens zum 'Abgucken' der Paramter, dann einmal alles richtig mit der Bridge einstellen und nie wieder Ärger mit autocreate-Magik ;)
Zitat von: hexenmeister am 13 März 2019, 18:55:36
Paralleler Einsatz von zwei IO-Typen wäre sicher nicht das gelbe vom Ei. Höchtens zum 'Abgucken' der Paramter, dann einmal alles richtig mit der Bridge einstellen und nie wieder Ärger mit autocreate-Magik ;)
Zwischenzeitlich habe ich darüber auch etwas nachgedacht und finde das jetzt noch weniger dramatisch. Der CLIENT verhält sich ggf. dem mosquitto doch im Prinzip auch nicht anders als - sagen wir ein tasmota-Gerät , nur dass er halt (wie z.B. wie mosquitto_sub auch) über dieselbe IP kommt wie die weiteren MQTT-IOs. Das gilt jedenfalls ab dem Moment, an dem man die subscriptions entsprechend setzt.
Das Eingrenzen der Subscription ist essentiell, aber außer dem, dass der User da Unsinn treiben kann, wenn er das löscht, kann ich jetzt keinen Punkt mehr erkennen, der gegen diese Lösung spräche.
Und ein MQTT2_DEVICE ist m.E. eigentlich auch nur ein leicht modifizierter dummy - kein Grund, letzteren für transparenter zu halten; die Syntax ist halt leicht anders, aber auch nicht schwer, jedenfalls nach meinem persönlichen Eindruck (der aber zugegebenermaßen mit Erfahrung damit gefärbt ist) leichter, als das in die Generic-Bridge-Sprache zu übersetzen.
Jeder halt, wie er es gewohnt ist...
Der (aus meiner Sicht wichtiger) Vorteil der alten MQTT-IO ist die Tatsache, dass die Subscribtions automatisch verwaltet werden. Es wird immer nur das bestellt, was auch gebraucht wird.
Hallo hexenmeister,
ich nutze die MQTT_GENERIC_BRIDGE in Verbindung mit dem MQTT2_CLIENT und würde gerne einige readings vom publish ausschliessen (ro-Counter00 bis 09).
Laut Commandref sollte das mit dem Bridge Attribut globalDeviceExclude und/oder globalTypeExclude funktionieren.
Das funktioniert bei mir aber nicht, ich habe folgende Konstellationen ausprobiert.
attr bridge globalTypeExclude ModbusAttr:ro-Counter00 ModbusAttr:ro-Counter01 ModbusAttr:ro-Counter02
attr bridge globalDeviceExclude mbSlave01:ro-Counter00 mbSlave01:ro-Counter01 mbSlave01:ro-Counter02
das ganze Device zu filtern funktioniert, aber eben nicht auf readings ebene
attr bridge globalTypeExclude ModbusAttr:*
attr bridge globalDeviceExclude mbSlave01:*
auch das habe ich versucht, aber dadurch wird nur der Wert entfernt, veröffentlicht wird trotzdem, obwohl laut CommandRef "Ist der Rueckgabewert undef, dann wird das Setzen/Ausfuehren unterbunden."
attr mbSlave01 state:topic={"$base/state"} *:topic={"$base/r/$name"} *:atopic={"$base/a/$name"} ro-Counter00|ro-Counter01|ro-Counter02:expression={$reading=undef}
oder
attr mbSlave01 state:topic={"$base/state"} *:topic={"$base/r/$name"} *:atopic={"$base/a/$name"} ro-Counter00|ro-Counter01|ro-Counter02:expression={undef}
mache ich da was falsch?
Grüße Marco
Moin!
Das ging früher schon mal, müsste ich testen. Umzugsbegingt komme ich in den nächsten paar Wochen leider nicht dazu. Bis dahin wäre eine Lösung, die gewünschten Readings direkt anbieten anstatt *. Ist eh sicherer. ;)
vg
Alexander
Moin Alex,
da ich grad zwangsweise meine eine FHEM-Instanz neu aufsetzen muss (blöde SD-Karte ;) ) stolpere ich mal wieder über expandJSON.
Gibt es da mittlerweile von dir neue Bemühungen bzgl. JSON? Oder ist expandJSON da immer noch das schnelle Maß der Dinge?
Gruß
Maui
Hi!
Die oft angefragte JSON-Unterstützung kann einfach mit Hilfe von 'expression' realisiert werden. Dafür eignet sich eine in fhem.pl bereits vorhandene Methode: json2nameValue. Als Parameter soll $message verwendet werden.
Beispiel:
attr <dev> mqttSubscribe json:topic=/XTEST/json json:expression={json2nameValue($message)}
Grüße
Alexander
Hallo,
ich möchte gerne mein Gast-WLAN über MQTT ein- und aussschalten können. Dazu habe ich folgendes definiert:
defmod rp_FB_GWLAN1 readingsProxy FritzBox:box_guestWlan
attr rp_FB_GWLAN1 devStateIcon on:it_wifi@green:off off:it_wifi@red:on
attr rp_FB_GWLAN1 event-on-change-reading .*
attr rp_FB_GWLAN1 mqttPublish state:topic={"fhem2mqtt/guestwlan/state"}
attr rp_FB_GWLAN1 mqttSubscribe state:stopic=mqtt2fhem/guestwlan/state/set state:qos=2
attr rp_FB_GWLAN1 room Wohnzimmer
attr rp_FB_GWLAN1 setFn {($CMD eq "on")?"guestWlan on":"guestWlan off"}
attr rp_FB_GWLAN1 setList on off
Beim Klicken in FHEM wird auch brav der state an den Broker "gepublished", nur das mit dem subscribe will nicht. Egal was ich sende, der on bzw. off Befehl wird nicht angenommen und der state ändert sich nicht.
Kann mir mal jemand einen Schubs geben, wie der mqttsubscribe aussehen müsse und was genau ich an den Broker schicken müsste, damit das Device umschaltet?
Danke im Voraus.
Frank
@frankreed
Mein Attribut fürs Schalten sieht vereinfacht so aus:
attr <device> mqttSubscribe state:stopic={"$base/$device/$reading/set"}
Folglich fehlt bei Deinem mqttSubscribe die geschweifte Klammer samt den Anführungszeichen. Das Attribut müsste eher so aussehen - vorausgesetzt der MQTT-Pfad stimmt ansonsten:
attr rp_FB_GWLAN1 mqttSubscribe state:stopic={"mqtt2fhem/guestwlan/state/set"} state:qos=2
Nee, geht nicht. Ich habe mqtt2fhem/guestwlan/state/set off abgesetzt, aber das Ding reagiert nicht..... :-(
@frankreed
Das Problem ist im Zweifel recht schwierig einzukreisen. Du müsstest einmal ermitteln, wo Deine MQTT-Nachricht verschwindet:
- Hast Du mosquitto_sub, o.ä. zum Prüfen verwendet, um festzustellen, welche Nachricht vom MQTT-Server tatsächlich versendet wird ...
- Ist Dein FHEM-MQTT-Client (MQTT oder MQTT2) richtig konfiguriert ...
- Ist die MQTT_GENERIC-BRIDGE richtig konfiguriert (Ist der Wert vom Reading incoming-count > 0) ...
Ich schau' morgen nochmal nach. Bett ruft bzw. Wecker um 04:15 Uhr...
@frankreed
Im Zusammenhang mit MQTT2 ist mir übrigens noch aufgefallen, dass u.U. nach einer Änderung der MQTT_GENERIC_BRIDGE-Definition ein FHEM-Neustart notwendig war ...
Die Klammern mit Anführungszeichen sind nur notwendig, wenn Topic als Expression bejandelt werden soll, z.B. wenn Variablen enthalten sind.
Auf den ersten Blick sehe ich den Fehler nicht. Kann leider auch nicht nachstellen, umzugsbegingt habe ich gerade keine Server am Laufen.
GenericBridge kann Informationen zu den angemeldeten Geräte anzeigen. Setze mal "get devinfo" an der Bridge ab, da sollte dein Device auftauchen und die subscribe-Topic angezeigt werden.
Hallo,
jetzt funktioniert es. Ich habe mir mit Hilfe der Awendungsbeispiele "Aktoren, die in einer FHEM-Instanz definiert sind, aus einer anderen schalten" einen Dummy Switch angelegt und die Topics daraus 1:1 sowohl in den Gast-Wlan-Schalter als auch in den Dummy kopiert (zum Testen ist das ja egal)
Sowohl über den Dummy als auch über NodeRed kann ich jetzt schalten.
Da muss was mit meinen subscribe/publish-Topics nicht gestimmt haben.
Problem ist also gelöst.
Danke an alle
Hi zusammen,
ich habe aktuell das Problem, dass in einem Dummy-Device nicht alle Werte per MQTT published werden.
Das Dummy-Device bekommt per Notify zwei zusätzliche Readings (lastset, lastunset) per setreading angepappt. state habe ich außerdem. Klar, ist standard.
Wenn sich der state ändert springt (je nachdem) eins von zwei Notifys an, macht das setreading (erstellt bzw. updated das reading) und schreibt darin die aktuelle Uhrzeit + Datum. Das funktioniert soweit auch. Auch sehe ich im Event-Monitor einen entsprechenden Eintrag.
Und genau diesen Inhalt (Datum + Zeit) möchte ich per MQTT rausschicken um ihn in Node Red weiter zu bearbeiten bzw. darzustellen.
Aber egal was ich mache, state wird gepublished, die beiden setreadings "lastset" und "lastunset" kommen nicht raus.
Ich habe mir auch schon alle Topics in MQTT.fx per "#" aboniert. Aber selbst da kommen die beiden readings "lastset" und "lastunset" nicht mit. Die werden also definitiv nicht published. Aber warum? Fehler von mir oder ein Bug? statt $name habe ich auch schon $reading versucht ohne damit mehr Erfolg zu haben.
Internals:
FUUID 5c4adb72-f33f-b8cb-e949-c81481837a34c5c0
NAME Alarmanlage.Status
NR 92
STATE Unscharf
TYPE dummy
Helper:
DBLOG:
state:
LogDB:
TIME 1556142356.28454
VALUE Unscharf
READINGS:
2019-04-24 23:45:16 lastset 2019-04-24 23:45:16
2019-04-24 23:45:56 lastunset 2019-04-24 23:45:56
2019-04-24 23:45:56 state Unscharf
Attributes:
DbLogExclude .*
DbLogInclude state
devStateIcon Scharf:secur_locked@red Unscharf:secur_open@grey Warten:hourglass@orange
icon building_security
mqttPublish *:topic={"$base/Alarmanlage/$device/$name"}
room Alarm,Eingang
Kann gerade nicht ausprobieren, habe keine Testumgebung. Möglicherweise schlägt der Schutz von Endlos-Loops zu.
Probiere das Attribut mqttForward auf all zu setzen.
Gerade versucht, hilft auch nicht.
Ich würde mich hier mal mit anhängen. Ich hatte mir den Hauptthread mal ein wenig durchgelesen aber so wirklich kapiert was ich machen muss hab ich nicht, liegt da dran das ich Smarthome Einsteiger bin und dazu dann auch noch FHEM Neuling. Folgendes möchte ich gerne tun und denke das die MQTT Generic Bridge das richtige dafür ist.
Aktuelles Szenario ::
FHEM <-> Signalduino Stick <-> Jarolift Modul -> Jarolift Rollos.
Soweit läuft alles, eingerichtet, angelernt und die Rollos lassen sich in Fhem wunderbar steuern. So mein Problem was ich jetzt habe, ich hatte mich davor ein wenig in OpenHab eingearbeitet und die Rollos mit einem anderen Gateway gesteuert, da ich damit nicht zufrieden bin und das neue Gateway viel stabiler läuft dies aber leider nur für FHEM gibt, würde ich das gerne weiterhin per OH steuern mit einer MQTT Bridge über FHEM.
Da ich in OH soweit schon alles eingerichtet habe wie Räume, Astro Funktion, Random runter fahrende Rollos usw und ich mich dort wenigstens schon ein wenig auskenne, würde ich dies gerne als Steuerzentrale weiter nutzen.
Nun bräuchte ich hier vllt mal Hilfe an einem konkreten Beispiel meiner Komponenten, wie ich das ganze miteinander verbinde. Leider komm ich hierbei überhaupt nicht klar. Würde mir da jemand helfen und ich würde einen Rollo erfolgreich durchreichen können, würde ich den Rest selber hinbekommen.
Das ganze sieht wie folgt aus. @hexenmeister
In FHEM habe ich die MQTT Verbindung hergestellt. Siehe Screen 1
So dann habe ich eine Bridge zu einem FHEM Device eingerichtet, aber ich glaube hier stimmt schon was nicht oder ? Unter State habe ich nur ???
Siehe Screen 2
Ich kann das ganz auch nicht über z.b. MQTT fx ansteuern, was es aber machen sollte :
Dort habe ich unter published Jaro_FB/Set eingegeben und im Fenster darunter down 1. So sollte der Rollo eigentlich fahren, passieren tut nichts.
In der FHEM Config sieht es so aus.
# MQTT Brdige zu OpenHab
define openhab MQTT 127.0.0.1:1883
setuuid openhab 5ccb0b33-f33f-fc62-2405-25098b868b494548
define MQTT_Jarolift MQTT_BRIDGE Jaro_FB
setuuid MQTT_Jarolift 5ccca400-f33f-fc62-b91c-3511e543a7d05148
attr MQTT_Jarolift IODev openhab
attr MQTT_Jarolift publishReading_LastAction_Channel_01 /Jaro_FB/LastAction_Channel_01
attr MQTT_Jarolift publishReading_LastAction_Channel_02 /Jaro_FB/LastAction_Channel_02
attr MQTT_Jarolift publishReading_LastAction_Channel_03 /Jaro_FB/LastAction_Channel_03
attr MQTT_Jarolift publishReading_LastAction_Channel_04 /Jaro_FB/LastAction_Channel_04
attr MQTT_Jarolift publishReading_LastAction_Channel_05 /Jaro_FB/LastAction_Channel_05
attr MQTT_Jarolift publishReading_LastAction_Channel_06 /Jaro_FB/LastAction_Channel_06
attr MQTT_Jarolift publishReading_LastAction_Channel_07 /Jaro_FB/LastAction_Channel_07
attr MQTT_Jarolift publishReading_LastAction_Channel_08 /Jaro_FB/LastAction_Channel_08
attr MQTT_Jarolift publishReading_LastAction_Channel_09 /Jaro_FB/LastAction_Channel_09
attr MQTT_Jarolift publishReading_LastAction_Channel_10 /Jaro_FB/LastAction_Channel_10
attr MQTT_Jarolift publishReading_LastAction_Channel_11 /Jaro_FB/LastAction_Channel_11
attr MQTT_Jarolift publishReading_LastAction_Channel_12 /Jaro_FB/LastAction_Channel_12
attr MQTT_Jarolift publishReading_button /Jaro_FB/button
attr MQTT_Jarolift publishReading_channel /Jaro_FB/channel
attr MQTT_Jarolift publishReading_channel_control /Jaro_FB/channel_control
attr MQTT_Jarolift publishReading_counter_receive /Jaro_FB/counter_receive
attr MQTT_Jarolift publishReading_counter_send /Jaro_FB/counter_send
attr MQTT_Jarolift publishReading_last_digits /Jaro_FB/last_digits
attr MQTT_Jarolift publishReading_serial_receive /Jaro_FB/serial_receive
attr MQTT_Jarolift publishReading_state /Jaro_FB/state
attr MQTT_Jarolift publishReading_user_info /Jaro_FB/user_info
attr MQTT_Jarolift publishReading_user_modus /Jaro_FB/user_modus
attr MQTT_Jarolift publishState 1
attr MQTT_Jarolift subscribeSet Jaro_FB/set
Irgendwo mache ich was falsch, ich weiß aber momentan leider nicht wo. Ich denke irgendwas mit dem Bridge Device
Im letzten Screen noch das Device an sich zu sehen, mit was man die Rollos steuert.
Kennst Du folgenden Beitrag https://forum.fhem.de/index.php/topic,91642.0.html (https://forum.fhem.de/index.php/topic,91642.0.html)?
In Deinen Ausführungen verwendest Du übrigens MQTT_BRIDGE und nicht MQTT_GENERIC_BRIDGE.
Shit, das ist dann wieder zweierlei. Was ist da der Unterschied und reicht die normale auch?
MQTT_BRIDGE kenne ich nicht - bin mir auch nicht sicher, ob die noch wirklich unterstützt wird.
Ich nutze MQTT_GENERIC_BRIDGE, um "normale" FHEM-Geräte (z.B. HUE-Lampen, Homematic-Thermostate) MQTT-fähig zu machen.
M.E. sollte man IMMER die Generic-Bridge nehmen, wenn man in das Thema einsteigt. Einmal verstanden, kann man beliebig viele Devices "vermqtten", und die erforderlichen Attribute sind überall verfügbar.
(Die Einzel-Bridge sollte eigentlich nach Contrib, just my2ct...)
Hallo,
ich habe das Problem, dass der retain Flag nicht zu funktionieren scheint. Wenn ich zu einer Topic subscribe bekomme ich keine Werte obwohl der retain Flag gesetzt war.
MQTT Generic Bridge:
version 1.1.7 by hexenmeister
$Id: 10_MQTT_GENERIC_BRIDGE.pm 18821 2019-03-07 20:18:23Z hexenmeister $
Broker:
mosquitto version 1.4.10 (build date Wed, 13 Feb 2019 00:45:38 +0000)
mosquitto is an MQTT v3.1 broker.
FHEM:
define MqttGenericBridge MQTT_GENERIC_BRIDGE
setuuid MqttGenericBridge 5c7a8d2d-f33f-990b-7e21-e3e9036eb0063a17
attr MqttGenericBridge IODev MQTTBroker
attr MqttGenericBridge room System
define WzEnableMotionDetection dummy
setuuid WzEnableMotionDetection 5c7a8d2d-f33f-990b-73ac-a1a05a2d1064a4d9
attr WzEnableMotionDetection alias Bewegungsmelder Wohnzimmer
attr WzEnableMotionDetection devStateIcon on:on:off off:off:on
attr WzEnableMotionDetection genericDeviceType switch
attr WzEnableMotionDetection homebridgeMapping on=state,cmdOn=on,cmdOff=off
attr WzEnableMotionDetection mqttForward all
attr WzEnableMotionDetection mqttPublish state:topic={"stat/$device/$reading"} *:retain=1
attr WzEnableMotionDetection mqttSubscribe state:stopic={"cmnd/$device/$reading"}
attr WzEnableMotionDetection room Alexa,Wohnzimmer
attr WzEnableMotionDetection setList on off
attr WzEnableMotionDetection webCmd on:off
Edit:
Funktioniert nicht: attr WzEnableMotionDetection mqttPublish state:topic={"stat/$device/$reading"} *:retain=1
das funktioniert aber attr WzEnableMotionDetection mqttPublish state:topic={"stat/$device/$reading"} state:retain=1
Funktioniert tatsächlicht nicht. Muss ich schauen.
Probiere mal bitte die angehängte Version aus.
Ist eine Testversion mit dieser und paar anderen Fehlerkorrekturen und einer Feature-Erweiterung (einfachere Möglichkeit, zu einem Reading mehrere Nachrichten gleichzeitig zu versenden). Läuft bei mir bereits stabil.
vielen Dank für den schnellen Bugfix. Retain funktioniert wieder. Super :D
Edit: Viel Spaß mit dem Bier heute Abend ;)
Die neue Version ist jetzt ins Repo eingecheckt (ab Morgen per Update).
Danke für den Fehlerbericht und das Testen! (Prost! ;D)
Ich habe nach dem letzten Update das Problem mit der Bridge keine Werte mehr published zu bekommen. Ich kann aber ohne Problem die Geräte hinter der Bridge steuern.
version 1.2.1 by hexenmeister
$Id: 10_MQTT_GENERIC_BRIDGE.pm 19477 2019-05-28 16:27:14Z hexenmeister $
nternals:
DEF mqtt GarageBewegung,GarageTorReed,GaragePflanzenlampe,GarageHeizung,GarageKompressor,GarageLicht,TeBachWasserzufuhr,GarageDHT22,GarageHelligkeitInnen,GarageHelligkeitAussen,GarageTempFeuchteInnen,GarageTempFeuchteAussen,GarageLCD,GarageTempRohr,GarageTempVerteiler,GarageTempWasser,GarageTor
FUUID 5c686efa-f33f-2c64-630f-1e1b7e1d0259a375
IODev FHEMmqtt
NAME mqttGeneric
NR 74
NTFY_ORDER 50-mqttGeneric
STATE ???
TYPE MQTT_GENERIC_BRIDGE
devspec GarageBewegung,GarageTorReed,GaragePflanzenlampe,GarageHeizung,GarageKompressor,GarageLicht,TeBachWasserzufuhr,GarageDHT22,GarageHelligkeitInnen,GarageHelligkeitAussen,GarageTempFeuchteInnen,GarageTempFeuchteAussen,GarageLCD,GarageTempRohr,GarageTempVerteiler,GarageTempWasser,GarageTor
prefix mqtt
READINGS:
2019-05-29 22:54:17 device-count 15
2019-05-29 22:44:00 incoming-count 2
2019-05-29 22:35:49 outgoing-count 0
2019-05-29 22:44:00 transmission-state incoming publish received
2019-05-29 22:35:49 updated-reading-count 0
2019-05-29 22:44:01 updated-set-count 2
devices:
:global:
:defaults:
pub:qos 2
pub:retain 0
sub:qos 2
sub:retain 0
GarageBewegung:
:publish:
*:
mode R
topic {"garage/GarageBewegung/$reading"}
GarageDHT22:
:publish:
*:
mode R
topic {"garage/GarageTempNetzwerk/$reading"}
GarageHeizung:
:publish:
*:
mode R
topic {"garage/GarageHeizung/$reading"}
:subscribe:
HASH(0x36e3470)
GarageHelligkeitAussen:
:publish:
*:
mode R
topic {"garage/GarageHelligkeitAussen/$reading"}
GarageHelligkeitInnen:
:publish:
*:
mode R
topic {"garage/GarageHelligkeitInnen/$reading"}
GarageKompressor:
:publish:
*:
mode R
topic {"garage/GarageKompressor/$reading"}
:subscribe:
HASH(0x36e2d08)
GarageLicht:
:publish:
*:
mode R
topic garage/GarageLicht
:subscribe:
HASH(0x36e2c90)
GaragePflanzenlampe:
:publish:
*:
mode R
topic {"garage/GaragePflanzenlampe/$reading"}
:subscribe:
HASH(0x36e0aa0)
GarageTempFeuchteAussen:
:publish:
*:
mode R
topic {"garage/GarageTempFeuchteAussen/$reading"}
GarageTempFeuchteInnen:
:publish:
*:
mode R
topic {"garage/GarageTempFeuchteInnen/$reading"}
GarageTempRohr:
:publish:
*:
mode R
topic {"garage/GarageTempRohr/$reading"}
GarageTempVerteiler:
:publish:
*:
mode R
topic {"garage/GarageTempVerteiler/$reading"}
GarageTempWasser:
:publish:
*:
mode R
topic {"garage/GarageTempWasser/$reading"}
GarageTorReed:
:publish:
*:
mode R
topic {"garage/GarageTorReed/$reading"}
TeBachWasserzufuhr:
:publish:
*:
mode R
topic {"garage/TeBachWasserzufuhr/$reading"}
:subscribe:
HASH(0x36e52c8)
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 *
message_ids:
subscribe:
garage/GaragePflanzenlampe/set
garage/GarageKompressor/set
garage/TeBachWasserzufuhr/set
garage/GarageLicht/set
garage/GarageHeizung/set
subscribeExpr:
^garage\/GaragePflanzenlampe\/set$
^garage\/GarageKompressor\/set$
^garage\/TeBachWasserzufuhr\/set$
^garage\/GarageLicht\/set$
^garage\/GarageHeizung\/set$
subscribeQos:
garage/GarageHeizung/set 0
garage/GarageKompressor/set 0
garage/GarageLicht/set 0
garage/GaragePflanzenlampe/set 0
garage/TeBachWasserzufuhr/set 0
Attributes:
IODev FHEMmqtt
globalDefaults pub:qos=2 sub:qos=2 retain=0
room MQTT,Zentral
Beispiel Sensor:
Auf dem MQTT Bridge FHEM
Internals:
DEF 28.FFA99CA41604 60
FUUID 5c686ef9-f33f-2c64-3c87-6523e66bb1b2e1c0
IODev OWServerGarage
LAST_READ_FAILED 0
NAME GarageTempRohr
NOTIFYDEV global
NR 71
NTFY_ORDER 50b-GarageTempRohr
STATE temperature: 17.875 alarm: 0
TYPE OWDevice
READINGS:
2018-12-30 19:45:46 address 28FFA99CA4160434
2019-05-29 23:01:13 alarm 0
2019-05-29 23:01:13 state temperature: 17.875 alarm: 0
2019-05-29 23:01:13 temperature 17.875
2018-12-30 19:45:43 temphigh 50
2018-12-30 19:45:35 templow 5
2018-12-30 19:46:46 type DS18B20
fhem:
address 28.FFA99CA41604
alerting 1
bus bus.0
interfaces temperature
interval 60
getters:
address
crc8
family
fasttemp
id
locator
r_address
r_id
r_locator
temperature
temperature10
temperature11
temperature12
temperature9
temphigh
templow
type
polls:
temperature
setters:
temphigh
templow
state:
temperature
Attributes:
IODev OWServerGarage
model DS18B20
mqttPublish *:topic={"garage/GarageTempRohr/$reading"}
room OWDevice
userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
Auf der anderen Seite:
Internals:
FUUID 5c432079-f33f-c2c3-2cd6-be12dd45b1446527
IODev mqtt
NAME GarageTempRohr
NR 336
STATE T: 16.1875 °C
TYPE MQTT_DEVICE
qos *:2
READINGS:
2019-05-29 08:18:47 alarm 0
2019-05-29 08:18:47 temperature 16.1875
2019-05-29 22:29:34 transmission-state subscription acknowledged
message_ids:
sets:
subscribe:
garage/GarageTempRohr/+
garage/GarageTempRohr/alarm
garage/GarageTempRohr/temperature
subscribeExpr:
^garage\/GarageTempRohr\/([^/]+)$
^garage\/GarageTempRohr\/alarm$
^garage\/GarageTempRohr\/temperature$
subscribeQos:
garage/GarageTempRohr/+
garage/GarageTempRohr/alarm 0
garage/GarageTempRohr/temperature 0
subscribeReadings:
garage/GarageTempRohr/alarm:
cmd
name alarm
garage/GarageTempRohr/temperature:
cmd
name temperature
Attributes:
IODev mqtt
autoSubscribeReadings garage/GarageTempRohr/+
group Umweltsensoren
icon temp_temperature
qos 2
room Garage
stateFormat T: temperature °C
subscribeReading_alarm garage/GarageTempRohr/alarm
subscribeReading_temperature garage/GarageTempRohr/temperature
Moin, ich bin paar Tage weg, sodass ich erst am Sonntag dazu kommen kann, nach dem Fehler zu suchen. Empfehle bis dahin die vorherige Version zu verwenden.
Zitat von: hexenmeister am 30 Mai 2019, 02:27:48
Moin, ich bin paar Tage weg, sodass ich erst am Sonntag dazu kommen kann, nach dem Fehler zu suchen. Empfehle bis dahin die vorherige Version zu verwenden.
Ok, danke und schönes langes Wochenende.
Mit Version (welche ich im Backup vom letzten Stand vorfand)
version 1.1.7 by hexenmeister
$Id: 10_MQTT_GENERIC_BRIDGE.pm 18821 2019-03-07 20:18:23Z hexenmeister $Werden auch wieder outgoing messages gesendet.
Internals:
DEF mqtt GarageBewegung,GarageTorReed,GaragePflanzenlampe,GarageHeizung,GarageKompressor,GarageLicht,TeBachWasserzufuhr,GarageDHT22,GarageHelligkeitInnen,GarageHelligkeitAussen,GarageTempFeuchteInnen,GarageTempFeuchteAussen,GarageLCD,GarageTempRohr,GarageTempVerteiler,GarageTempWasser,GarageTor
FUUID 5c686efa-f33f-2c64-630f-1e1b7e1d0259a375
IODev FHEMmqtt
NAME mqttGeneric
NR 74
NTFY_ORDER 50-mqttGeneric
STATE ???
TYPE MQTT_GENERIC_BRIDGE
devspec GarageBewegung,GarageTorReed,GaragePflanzenlampe,GarageHeizung,GarageKompressor,GarageLicht,TeBachWasserzufuhr,GarageDHT22,GarageHelligkeitInnen,GarageHelligkeitAussen,GarageTempFeuchteInnen,GarageTempFeuchteAussen,GarageLCD,GarageTempRohr,GarageTempVerteiler,GarageTempWasser,GarageTor
prefix mqtt
READINGS:
2019-05-30 09:56:23 device-count 15
2019-05-30 09:56:30 incoming-count 8
2019-05-30 09:57:35 outgoing-count 14
2019-05-30 09:57:35 transmission-state outgoing publish sent
2019-05-30 09:56:12 updated-reading-count 0
2019-05-30 09:56:30 updated-set-count 8Grüße
Dirk
Gesucht, gefunden, gelöst :)
War ein Fehler, habe bei der letzten Erweiterung etwas nicht bedacht. Danke für den Bug-Report!
Sehr gut, danke :) Ab wann ist es über Update verfügbar?
Ich habe da noch ein anderes Problem, aber das besteht seit dem ich MQTT_DEVICE und MQTT_BRIDGE nutze. Ich weiß nicht ob das an mir oder am Modul liegt.
Ich bekomme bei Devices welche ein Topic subscribed haben (zum steuern) und gleichzeitig ihre readings publishen sollen einfach keine Messages. Also steuern geht, ihren state publishen geht nicht.
Beispiel device (es sind einige)
Auf der MQTT_BRIDGE Seite:
Internals:
DEF MCP23017:PortB7
DEVICE MCP23017
FUUID 5c686ef4-f33f-2c64-3dbd-fea08bc69dfaae8b
NAME GaragePflanzenlampe
NOTIFYDEV global,MCP23017
NR 32
NTFY_ORDER 50-GaragePflanzenlampe
READING PortB7
STATE off
TYPE readingsProxy
CONTENT:
MCP23017 1
READINGS:
2019-05-30 10:18:01 lastCmd off
2019-05-30 10:18:01 state off
Attributes:
group MCP23017 Outputs
mqttForward all
mqttPublish state:topic={"garage/GaragePflanzenlampe/state"}
mqttSubscribe state:stopic={"garage/GaragePflanzenlampe/set"}
room GPIO-Devices
setFn {($CMD eq "on")?"PortB7 off":"PortB7 on"}
setList on off
userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
valueFn {($VALUE eq "on")?"off":"on"}
Auf der MQTT_DEVICE Seite:
Internals:
FUUID 5c432079-f33f-c2c3-1d4d-8bb91305bd4bac31
IODev mqtt
NAME GaragePflanzenlampe
NR 318
STATE off
TYPE MQTT_DEVICE
qos *:2
READINGS:
2019-06-02 10:55:07 state off
2019-06-02 11:14:54 transmission-state subscription acknowledged
message_ids:
publishSets:
:
topic garage/GaragePflanzenlampe/set
values:
on
off
toggle
on-for-timer
off-for-timer
sets:
off
off-for-timer
on
on-for-timer
toggle
subscribe:
garage/GaragePflanzenlampe/state
subscribeExpr:
^garage\/GaragePflanzenlampe\/state$
subscribeQos:
garage/GaragePflanzenlampe/state 0
subscribeReadings:
garage/GaragePflanzenlampe/state:
cmd
name state
Attributes:
IODev mqtt
cmdIcon on:general_an off:general_aus
group Licht
icon light_led
publishSet on off toggle on-for-timer off-for-timer garage/GaragePflanzenlampe/set
qos 2
room Garage
subscribeReading_state garage/GaragePflanzenlampe/state
In der Konstellation bekomme ich auf den Topic /garage/GaragePflanzenlampe/state nichts also generell bekomme ich kein Topic state von der MQTT_BRIDGE Seite.
Das einzeige was ich bekomme ist ein Topic /garage/GaragePflanzenlampe/set das bringt mir aber erstmal nichts. (was mich auch stark wundert da ich ja das Topic zum publishen auf state gesetzt habe) Ich möchte auf der MQTT_DEVICE Seite auch mitbekommen wenn sich der state auf der Bridge Seite ändert weil es dort lokal geschaltet wurde.
Also wie muss ich ein Device auf unter MQTT_BRIDGE konfiguieren damit es sein state published?
Grüße
Dirk
Habe das Verhalten nachgestellt und hin und her ausprobiert. Das Problem scheint noch vor der Bridge zu liegen. Es werden in der Kombination (Dummy/ReadingsProxy) keine Events an die Bridge geliefert und ich verstehe gerade nicht warum :(
Mit nur enem Dummy funktioniert es dagegen ohne Probleme.
Ah ok, was macht den ein readingsproxy anders als ein dummy? Da es bisher nicht aufgefallen ist bin ich wohl der einzige der das so verwendet :(
Das weiß ich (noch) nicht. Werde versuchen rauszufinden. Generell sind ja Events da, nur an die Bridge kommt nichts an. Vermutlich sehe ich gerade den Wald vor lauter Bäumen nicht.
Ok schonmal Danke für deine Hilfe. Wenn ich was für dich testen oder probieren kann oder so sag Bescheid.
Moin Alexander. Ich hab da grad ein Problem, bei dem ich nicht weiter weiß.
Ich habe mehrere FHEM Instanzen und bewusst nur eine mit Telegram Bot.
Ich schicke mir per MQTT GB die Nachrichten auf den Telegram Host und leite ihn dort an den Bot weiter.
Klappt auch problemlos mit einfachen Meldungen. Nun nutze ich aber auch Monitoring und wenn einige Fenster offen sind geht die Gesammelte Meldung nicht über die Bridge. Ich weiß nicht ob es an bestimmten Zeichen liegt oder der String zu lang ist.
Vielleicht hast du ja spontan eine Idee.
Internals:
FUUID 5cdd0927-f33f-f22a-4809-081008701e8b6ef2
NAME telebot
NR 47
STATE ???
TYPE dummy
READINGS:
2019-06-05 09:10:40 message Die folgenden 5 Fenster sind schon länger geöffnet:
- fk_bad_oben
- fk_bad_unten
- fk_kueche
- fk_sz
- fk_terrasse
Im Raum "ts_beamer" ist es sehr feucht.
Attributes:
mqttPublish message:topic=fhem/telebot/message
readingList message
room 9_Tech
Moin!
Was mir spontan einfällt: vlt. gibt es ein Problem mit dem Zeilenumbruch, ich meine ähnliches Problem hatte ich mit dem Bot (allerding in NodeRed).
Probiere mal so eine Nachricht direkt über Telegram-Device abzusetzen.
Bei der Bridge dürfte das eigentlich kein Problem sein (weder Größe noch Zeilenumbrüche), ich werde mal ausprobieren.
Direkt funktioniert es. Das hatte ich ja bis vor paar Wochen so als noch alles auf einem Fhem System lief.
Aber ich teste es nochmal. Es kommt ja gar nicht beim Ziel System an die Nachricht bzw. Wird gar nicht an den mosquitto gesendet.
Ok, muss ich nachsehen, möglicherweise geht die Nachricht auch im MQTT-Modul kaputt. Benutzt Du MQTT oder MQTT_CLIENT/SERVER?
Als Modul MQTT und als Server mosquitto
Ich habe grad mal noch ein wenig am Host geguckt.
Auch mit verbose 5 kommt bei der GB scheinbar nix an.
Einfache Meldungen gehen problemlos
2019.06.05 19:11:25 5: MQTT_GENERIC_BRIDGE:DEBUG:> [mqttGB] publish: fhem/telebot/message => hallo (qos: 0, retain: 0)
Und auch wenn ich den Text nehme, den er rüber schicken soll und händisch kopiere und per set nochmal einfüge an das Reading klappt es auch.
Es kann also eigentlich nur die Leerzeile am Beginn sein oder andere nervige Steuerzeichen.
Kannst Du mal den genauen Text üpost, was Du verwendest hast? Bei mir gehen Zeilenumbbrüche etc. problemlos in einem Dummy in Reasings rein.
Zitat von: hexenmeister am 05 Juni 2019, 00:29:29
Das weiß ich (noch) nicht. Werde versuchen rauszufinden. Generell sind ja Events da, nur an die Bridge kommt nichts an. Vermutlich sehe ich gerade den Wald vor lauter Bäumen nicht.
Entgegen meiner ersten Vermutung, kommen Events doch bi er Bridge an. Aaaber...
... es funktioniert eben nicht mit 'state'. Ich verwende in der Bridge Schleife für die Events eines Gerätes:
foreach my $event (@{deviceEvents($dev,1)}) {
...
}Zweites Argument in deviceEvents bedeutet, dass auch 'state' als z.B. 'state: off' ausgegeben werden soll. Das nimmt die Routine aus dem Device-Hash aus $hash->{CHANGEDWITHSTATE}. Und dieser ist bei dem Update über die readingsProxy eben nicht da, nur $hash->{CHANGED}:
Zitat{
'INTRIGGER' => 1,
'CONTENT' => {
'MCP23017' => 1
},
'NTFY_TRIGGERTIME' => '2019-06-05 23:36:08',
'INSET' => 1,
'READING' => 'PortB7',
'NOTIFYDEV' => 'global,MCP23017',
'CHANGED' => [
'off'
],
'NTFY_ORDER' => '50-GaragePflanzenlampe',
'.attrminint' => [],
'FUUID' => '5cf6dbc3-f33f-447f-992a-3bb0ff1e7da3b0e8',
'TYPE' => 'readingsProxy',
'READINGS' => {
'state' => {
'VAL' => 'off',
'TIME' => '2019-06-05 23:36:08'
},
'lastCmd' => {
'TIME' => '2019-06-05 23:36:08',
'VAL' => 'off'
}
},
'DEF' => 'MCP23017:PortB7',
'NR' => 21030,
'NAME' => 'GaragePflanzenlampe',
'.triggerUsed' => 1,
'DEVICE' => 'MCP23017',
'STATE' => 'off',
'.attraggr' => [],
'CFGFN' => ''
};
Zum Vergleich wie es aussieht, wenn GenericBridge state direkt an einem Dummy setzt:
Zitat
2019.06.05 23:51:37 1: MQTT_GENERIC_BRIDGE:DEBUG:> [mqttGeneric] Notify for MCP23017X event: state: off STATE: off $VAR1 = {
'NTFY_TRIGGERTIME' => '2019-06-05 23:51:37',
'NR' => 21211,
'TYPE' => 'dummy',
'READINGS' => {
'state' => {
'VAL' => 'off',
'TIME' => '2019-06-05 23:51:37'
}
},
'FUUID' => '5cf6dde5-f33f-447f-bc26-8019992311b5c145',
'INTRIGGER' => 1,
'STATE' => 'off',
'.attraggr' => [],
'CFGFN' => '',
'CHANGEDWITHSTATE' => [
'state: off'
],
'.attrminint' => [],
'CHANGED' => [
'off'
],
'.triggerUsed' => 1,
'NAME' => 'MCP23017X'
};
Keine Ahnung, warum das bei readingsProxy so ist. Ich überlege mir, wie ich das sauber und nebenwirkungsfrei in der GenericBridge erkennen kann...
Probiere mal die angehängte Version. Bei mir funktioniert diese in deinem Fall. Ich hoffe, es gibt dabei keine Nebenwirkungen.
Auf den ersten Blick sieht es gut aus!!! :D ich teste und beobachte mal
Vielen Dank für deine Mühe
Zitat von: Maui am 05 Juni 2019, 19:20:17
Ich habe grad mal noch ein wenig am Host geguckt.
Auch mit verbose 5 kommt bei der GB scheinbar nix an.
Einfache Meldungen gehen problemlos
2019.06.05 19:11:25 5: MQTT_GENERIC_BRIDGE:DEBUG:> [mqttGB] publish: fhem/telebot/message => hallo (qos: 0, retain: 0)
Und auch wenn ich den Text nehme, den er rüber schicken soll und händisch kopiere und per set nochmal einfüge an das Reading klappt es auch.
Es kann also eigentlich nur die Leerzeile am Beginn sein oder andere nervige Steuerzeichen.
Ich glaube, das Problem ist in der Bridge. Aber nicht beim Empfang, sondern beim Senden. Es funktioniert irgendwie nicht, Nachrichten mit Zeilenumbrüchen zu versenden. Heute ist aber schon zu spät zum weitersuchen. :o
Zitat von: hexenmeister am 06 Juni 2019, 00:49:45
Ich glaube, das Problem ist in der Bridge. Aber nicht beim Empfang, sondern beim Senden. Es funktioniert irgendwie nicht, Nachrichten mit Zeilenumbrüchen zu versenden. Heute ist aber schon zu spät zum weitersuchen. :o
Guten Morgen. Auch wenn du es wohl schon gefunden hast, hier nochmal 2 Screens.
1. wird erstellt und nicht gesendet, 2. geht problemlos durch die Bridge.
Zitat von: hexenmeister am 06 Juni 2019, 00:19:55
Probiere mal die angehängte Version. Bei mir funktioniert diese in deinem Fall. Ich hoffe, es gibt dabei keine Nebenwirkungen.
Also bisher kann ich keine ungewollten Nebenwirkungen feststellen.
Jetzt eine Testversion für mehrzeilige Texte, bitte ausprobieren. :)
Zitat von: hexenmeister am 06 Juni 2019, 23:45:19
Jetzt eine Testversion für mehrzeilige Texte, bitte ausprobieren. :)
Erster Test sieht gut aus. Morgen teste ich weiter. Zu spät. Danke schonmal.
Gruß Maui
Habe die nue Version jetzt eingecheckt.
Eine Unschönheit hat das readingsProxy-Patch schon. Da Die Bridge nicht explizit mitgeteilt bekommt, dass es sich in diesem Fall um 'state' handelt, versucht sie das selbst zu erkennen. Die Erkennung wird fehlschlagen, wenn man versucht, über die Bridge an ein readingsProxy-Gerät für 'state' ein Wert (eine Zeichenkette) mit mindestens einem Doppelpunkt und unmittelbar folgendem Leerzeichen zu senden. Die Bridge wird das Teil vor dem Doppelpunkt fälscherweise als Readingsnamen annehmen. Sicher könnte man diese Heuristik etwas schlauer machen, ich denke jedoch, das Problem liegt an dem Zusammenspiel zw. readingsProxy-Modul und dem FHEM selbst. Dort sollte man auch nach einer generellen Lösung suchen.
Also ich konnte heute den Tag über keine negativen Effekte ausmachen bzgl. Leerzeilen.
Das hast du aber vermutlich noch nicht eingecheckt, oder?
doch, morgen wird die neue Version per Update verfügbar
Kann der Maintainer vom readingsProxy Modul da nicht abhilfe schaffen?
Vermutlich. Ich habe reingeschaut, auf den ersten Blick wird da alles korrekt gemacht. Ich müsst das mal in dem Entwicklerbereich posten.
Hallo,
ich versuche gerade FHEM dazu zu bekommen Werte per MQTT zu publishen. Aber es kommen keine Daten am MQTT server an. Die Verbindung wird erfolgreich aufgebaut. Ich sehe auch, dass FHEM sich für TOPICs subscribed hat aber publish geht nicht.
Config:
# grep -i mqtt fhem.cfg
attr global userattr cmdIcon devStateIcon:textField-long devStateStyle icon mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long sortby webCmd webCmdLabel:textField-long widgetOverride
attr Velux_0 mqttPublish EXECUTION|LASTCONTROL|LASTRUNSTATUS|LASTSTATUSREPLY|OPERATINGSTATE|PCT|STATE|TARGET:topic={"2og/dachfenster/$name"}
attr Velux_0 mqttSubscribe EXECUTION|LASTCONTROL|LASTRUNSTATUS|LASTSTATUSREPLY|OPERATINGSTATE|PCT|STATE|TARGET:stopic={"2og/dachfenster/$reading/set"}
define symcon_mqtt MQTT 172.18.0.2:1024
setuuid symcon_mqtt 5d065f76-f33f-304b-8aea-778a42dbae7d0df1
define mqttGeneric MQTT_GENERIC_BRIDGE
setuuid mqttGeneric 5d065f7d-f33f-304b-3b16-c7d9452d340e7a5a
attr mqttGeneric IODev symcon_mqtt
attr mqttGeneric globalDefaults sub:qos=2 pub:qos=0 retain=1
Ich finde den Fehler nicht ;-( Danke!
Hm. Readings in GRO?BUCHSTABEN funktionieren nicht. Ich werde mal suchen warum nicht...
Ähm. Nö, geht doch. Wenn man dummy richtig definiert...
Mein Testaufbau:
defmod dummy dummy
attr dummy mqttPublish EXECUTION|LASTCONTROL|LASTRUNSTATUS|LASTSTATUSREPLY|OPERATINGSTATE|PCT|STATE|TARGET:topic={"2og/dachfenster/$name"}
attr dummy mqttSubscribe EXECUTION|LASTCONTROL|LASTRUNSTATUS|LASTSTATUSREPLY|OPERATINGSTATE|PCT|STATE|TARGET:stopic={"2og/dachfenster/$reading/set"}
attr dummy readingList aaa EXECUTION LASTCONTROL LASTRUNSTATUS LASTSTATUSREPLY OPERATINGSTATE PCT STATE TARGET
attr dummy setList aaa EXECUTION LASTCONTROL LASTRUNSTATUS LASTSTATUSREPLY OPERATINGSTATE PCT STATE TARGET
und dann bei "set dummy LASTCONTROL test" kommen auch braw die Werte in MQTTExplorer.
Werden denn bei deinem Device Events generiert?
Hello,
Any idea why MQTT_GENERIC_BRIDGE stopped seeing my device?
define mqtt MQTT2_CLIENT 192.168.254.20:1888
attr mqtt room zMQTT
attr mqtt username mqttuser
attr mqtt subscriptions /Mythz/+/set
attr mqtt debug 1
attr mqtt verbose 5
define mqttGeneric MQTT_GENERIC_BRIDGE mqtt Mythz
attr mqttGeneric IODev mqtt
attr mqttGeneric defaults sub:qos=2 pub:qos=0 retain=0
attr mqttGeneric globalPublish *:topic={"/$device/$reading"}
attr mqttGeneric room zMQTT
It was working before but after I updated fhem - I can only see
device-count 0
Debug shows strange excludes:
initialized: 1
device data records: $VAR1 = {
':global' => {
':publish' => {
'*' => {
'topic' => '{"/$device/$reading"}',
'mode' => 'R'
}
}
}
};
subscriptionTab: $VAR1 = undef;
subscription helper array: $VAR1 = undef;
exclude type map: $VAR1 = {
'sub' => {
'MQTT_GENERIC_BRIDGE' => '*',
'MQTT_BRIDGE' => 'transmission-state',
'MQTT_DEVICE' => 'transmission-state',
'FHEMWEB' => '*',
'telnet' => '*',
'MQTT' => 'transmission-state',
'Global' => '*'
},
'pub' => {
'MQTT_DEVICE' => 'transmission-state',
'FHEMWEB' => '*',
'telnet' => '*',
'MQTT_BRIDGE' => 'transmission-state',
'MQTT_GENERIC_BRIDGE' => '*',
'Global' => '*',
'MQTT' => 'transmission-state'
}
};
exclude reading map: $VAR1 = {};
exclude device map: $VAR1 = {};
When I restored Fhem files backup from April, it started working again (still, with debug info and device count = 0 as above).
yes, globalPublish was brocken. please try attached version.
Hi,
ich verwende schon seit einige Zeit mit Begeisterung dieses Modul. Jetzt habe ich gerade das erste Mal was gefunden, dass mir Probleme macht. Ich hoffe es kann vielleicht jemand weiterhelfen :)
Ich hab testweise sowas angelegt:
attr kue.rolladen.links mqttSubscribe test:stopic=/test/position test:expression={closeBlindAndTurnFibaro("kue.rolladen.links",0,0)}
Intention:
Ich möchte ein Topic erstellen das eine Perl Methode aufruft, welche bei meinen Rollos Position und Tilt gemeinsam steuert. closeBlindAndTurnFibaro ist eine Methode in meiner myUtils.pl die ich anderswo zb. in DOIFs verwende.
Problem:
Topic lässt ich aufrufen, nur findet der closeBlindAndTurnFibaro nicht. Bin zu wenig Perl bzw Fhem Experte :) Kann ich hier myModules inkluden oder mit einem Prefix die Methoden darin verwenden oder geht das generell nicht?
Log beim Aufruf des Topics:
2019.07.08 22:45:05 2: MQTT_GENERIC_BRIDGE: [mqttGeneric] onmessage: error while evaluating expression ('{closeBlindAndTurnFibaro("kue.rolladen.links",0,0)}'') eval error: Undefined subroutine &MQTT::GENERIC_BRIDGE::closeBlindAndTurnFibaro called at (eval 414992) line 1.
Danke!
MQTT_GENERIC_BRIDGE verwendet Packages. Probiere der Methode "main::" vorranzustellen: "main::closeBlindAndTurnFibaro..."
Hat funktioniert! Vielen Dank für deine schnelle Antwort und Hilfe :)!
Ich bin gerade dabei meine mqtt Welt zu optimieren.
Mit einem Device das 2 Stati hat kann ich mit:
state:topic=fhem/status/alarm/test_2 state:expression={($value eq 'off')?'stop':'on'}
problemlos z.B. zu meinem Home-Status-Display publishen.
Wie sieht es aus, wenn mein Device 3 Stati meldet!
Das geht schon lange über 3 notifies.
notify Waermebedarf:demand set Broker_Syn publish retain:1 fhem/status/alarm/hz_waermebedarf on
notify Waermebedarf:idle set Broker_Syn publish retain:1 fhem/status/alarm/hz_waermebedarf off
notify Waermebedarf:off set Broker_Syn publish retain:1 fhem/status/alarm/hz_waermebedarf stop
Gibt es einen Weg das einfacher wie im obigen Beispiel über --> state:expression={($value eq ...............?
in der Gerneric Bridge zu realisieren?
Gruß Billy
Sollte sich eigentlich als "normale Abfragekaskade" erweitern lassen:
state:topic=fhem/status/alarm/test_2 state:expression={($value eq 'off')?'stop':($value eq 'idle')?'off':'on'}
Danke super, wieder was gelernt. und Code gespart! :)
Billy
Hallo,
befasse mich das erste mal mit der MQTT_GENERIC_BRIDGE und bin etwas ratlos.
Scheitere schon an der Definition.
Auf meinem Hauptsystem und 2. (Test)-Raspi, beide aktuell, bekomme ich ein
Cannot load module MQTT_GENERIC_BRIDGE
define mqttGenericBridge MQTT_GENERIC_BRIDGE mqtt du_Unifi_MQTT
attr mqttGenericBridge IODev MQTT2_CLIENT
Die 10_MQTT_GENERIC_BRIDGE.pm ist auf beiden Systemen vorhanden, die Rechte passen auch.
Verstehe das nicht was übersehe ich bzw. habe ich überlesen, welche Information kann ich noch liefern das mir geholfen werden kann.
Gruß
Thomas
Vermutung: Du nutzt jeweils ein "2"-er IO-Modul?
Dann wird ein (1) Perl-Modul benötigt, das erforderlich ist, damit im Hintergrund 00_MQTT.pm geladen werden kann (sollte im log stehen, welches, alternativ auch im Wiki zu "MQTT").
Richtig
Mir war hier
Zitat von: Beta-User am 11 Juli 2019, 17:08:56
Vielleicht schaust du dir im Wiki den MQTT-Artikel an (der genau so heißt), da ist ziemlich aktuell, aber evtl. noch überarbeitungswürdig, der aktuelle Stand der Dinge .....
schon nicht klar was genau gemeint war, dachte es gäb eine eigene Wiki-Seite und finde sie bloß nicht. Jetzt ist mir klar das dieser (https://wiki.fhem.de/wiki/MQTT#MQTT_GENERIC_BRIDGE) Artikel gemeint war und fälschlicherweise -warum auch immer- diese Anmerkung mit
libmodule-pluggable-perl als veraltet angesehen habe.
Ein Blick ins Log, wie von dir angemerkt, hätte diesen Hinweis aber auch gegeben.
Sorry und Danke ::)
@hexenmeiste Maaahlzeit :-)
Erst mal ne wichtige Frage - nutzt deine Bridge das dbus library?
Ich hab gerade ein größeres Problem - sobald ich die MQTT_GENERIC_BRIDGE nutze in FHEM fängt der definierte Broker ne Menge zu tun und dann Disconnect und Reconnect.... dann wieder was tun und wieder Disconnect... da er jedes mal retained topics holt keine Gute Sache :-D
Ich habe 20 Devices über die MQTT_GENERIC_BRIDGE - generell hatte ich das schon mal als ich einige topics falsch mit sub oder pub behandelt hatte.
Könntest du mir daher noch einmal sagen (alternativ zeigen wo es steht) wie genau ich nun es schreiben muss wo man Variablen nutzen kann und wo nicht :-D
Generell kam das ganze nun mit meinem Umzug von FHEM in das offizielle Docker Containerchen.
Ich teste aber auch gerade, ob es nativ auf dem PI das Problem hätte.
*EDIT* -> Auch auf dem Pi ist das Problem vorhanden - also kein Docker Problem.
Achtung etwas mehr Zeilen... geht net anders zum veranschaulichen.. das folgende passiert im Loop.
2019-07-22 09:41:22 MQTT MQTT_Broker DISCONNECTED
2019-07-22 09:41:22 MQTT MQTT_Broker connection: connecting
2019-07-22 09:41:22 MQTT MQTT_Broker CONNECTED
2019-07-22 09:41:22 MQTT MQTT_Broker connection: connected
2019-07-22 09:41:22 MQTT_DEVICE Rolladen_AZ transmission-state: subscribe sent
2019-07-22 09:41:23 MQTT_DEVICE Roombot_T_1000 transmission-state: subscribe sent
2019-07-22 09:41:23 MQTT_DEVICE SonOff_Touch1_1 transmission-state: subscribe sent
2019-07-22 09:41:23 structure Jorin_PC on
2019-07-22 09:41:23 MQTT_DEVICE Sonoff_Basic_1 transmission-state: subscribe sent
2019-07-22 09:41:23 MQTT_DEVICE Sonoff_Basic_2 transmission-state: subscribe sent
2019-07-22 09:41:23 MQTT_DEVICE Sonoff_Dual_1_1 transmission-state: subscribe sent
2019-07-22 09:41:23 MQTT_DEVICE Sonoff_Dual_1_2 transmission-state: subscribe sent
2019-07-22 09:41:23 MQTT_DEVICE Sonoff_S20_1 transmission-state: subscribe sent
2019-07-22 09:41:23 MQTT_DEVICE Sonoff_S20_2 transmission-state: subscribe sent
2019-07-22 09:41:23 MQTT_DEVICE Sonoff_S20_3 transmission-state: subscribe sent
2019-07-22 09:41:23 MQTT_DEVICE Sonoff_S20_4 transmission-state: subscribe sent
2019-07-22 09:41:24 MQTT_DEVICE Sonoff_S20_5 transmission-state: subscribe sent
2019-07-22 09:41:24 MQTT_DEVICE Sonoff_S20_6 transmission-state: subscribe sent
2019-07-22 09:41:24 MQTT_DEVICE Sonoff_S20_7 transmission-state: subscribe sent
2019-07-22 09:41:24 MQTT_DEVICE Sonoff_S20_8 transmission-state: subscribe sent
2019-07-22 09:41:24 MQTT_DEVICE doormodule transmission-state: subscribe sent
2019-07-22 09:41:24 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: subscribe sent
2019-07-22 09:41:24 MQTT_DEVICE unicolor_rgb_strip_wohnzimmer transmission-state: subscribe sent
2019-07-22 09:41:24 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: subscribe sent
2019-07-22 09:41:24 MQTT MQTT_Broker connection: active
2019-07-22 09:41:24 MQTT_DEVICE Rolladen_AZ transmission-state: subscription acknowledged
2019-07-22 09:41:24 MQTT_DEVICE Rolladen_AZ transmission-state: incoming publish received
2019-07-22 09:41:24 MQTT_DEVICE Rolladen_AZ online: true
2019-07-22 09:41:24 MQTT_DEVICE Rolladen_AZ transmission-state: incoming publish received
2019-07-22 09:41:24 MQTT_DEVICE Rolladen_AZ 0
2019-07-22 09:41:24 MQTT_DEVICE Roombot_T_1000 transmission-state: subscription acknowledged
2019-07-22 09:41:25 MQTT_DEVICE Roombot_T_1000 transmission-state: incoming publish received
2019-07-22 09:41:25 MQTT_DEVICE Roombot_T_1000 availablebyte: 0
2019-07-22 09:41:25 MQTT_DEVICE Roombot_T_1000 transmission-state: incoming publish received
2019-07-22 09:41:25 MQTT_DEVICE Roombot_T_1000 chargesource: Timed out reading chargingsource
2019-07-22 09:41:25 MQTT_DEVICE Roombot_T_1000 transmission-state: incoming publish received
2019-07-22 09:41:25 MQTT_DEVICE Roombot_T_1000 chargestate: Timed out reading chargestate
2019-07-22 09:41:25 MQTT_DEVICE Roombot_T_1000 transmission-state: incoming publish received
2019-07-22 09:41:25 MQTT_DEVICE Roombot_T_1000 command: Docking
2019-07-22 09:41:25 MQTT_DEVICE Roombot_T_1000 transmission-state: incoming publish received
2019-07-22 09:41:25 MQTT_DEVICE Roombot_T_1000 mode: Timed out reading mode
2019-07-22 09:41:25 MQTT_DEVICE Roombot_T_1000 transmission-state: incoming publish received
2019-07-22 09:41:25 MQTT_DEVICE Roombot_T_1000 onduty: Off Duty
2019-07-22 09:41:25 MQTT_DEVICE Roombot_T_1000 transmission-state: incoming publish received
2019-07-22 09:41:25 MQTT_DEVICE Roombot_T_1000 online: true
2019-07-22 09:41:25 MQTT_DEVICE Roombot_T_1000 transmission-state: incoming publish received
2019-07-22 09:41:25 MQTT_DEVICE Roombot_T_1000 Standby
2019-07-22 09:41:25 MQTT_DEVICE SonOff_Touch1_1 transmission-state: subscription acknowledged
2019-07-22 09:41:25 MQTT_DEVICE SonOff_Touch1_1 transmission-state: incoming publish received
2019-07-22 09:41:25 MQTT_DEVICE SonOff_Touch1_1 on
2019-07-22 09:41:25 MQTT_DEVICE SonOff_Touch1_1 transmission-state: incoming publish received
2019-07-22 09:41:25 MQTT_DEVICE SonOff_Touch1_1 off
2019-07-22 09:41:25 structure Jorin_PC on
2019-07-22 09:41:25 MQTT_DEVICE Sonoff_Basic_1 transmission-state: subscription acknowledged
2019-07-22 09:41:25 structure Jorin_PC on
2019-07-22 09:41:25 MQTT_DEVICE Sonoff_Basic_1 transmission-state: incoming publish received
2019-07-22 09:41:25 structure Jorin_PC on
2019-07-22 09:41:25 MQTT_DEVICE Sonoff_Basic_1 on
2019-07-22 09:41:25 structure Jorin_PC on
2019-07-22 09:41:25 MQTT_DEVICE Sonoff_Basic_1 transmission-state: incoming publish received
2019-07-22 09:41:25 structure Jorin_PC on
2019-07-22 09:41:25 MQTT_DEVICE Sonoff_Basic_1 on
2019-07-22 09:41:25 MQTT_DEVICE Sonoff_Basic_2 transmission-state: subscription acknowledged
2019-07-22 09:41:25 MQTT_DEVICE Sonoff_Basic_2 transmission-state: incoming publish received
2019-07-22 09:41:25 MQTT_DEVICE Sonoff_Basic_2 on
2019-07-22 09:41:25 MQTT_DEVICE Sonoff_Basic_2 transmission-state: incoming publish received
2019-07-22 09:41:25 MQTT_DEVICE Sonoff_Basic_2 off
2019-07-22 09:41:25 MQTT_DEVICE Sonoff_Dual_1_1 transmission-state: subscription acknowledged
2019-07-22 09:41:25 MQTT_DEVICE Sonoff_Dual_1_1 transmission-state: incoming publish received
2019-07-22 09:41:25 MQTT_DEVICE Sonoff_Dual_1_1 on
2019-07-22 09:41:26 MQTT_DEVICE Sonoff_Dual_1_2 transmission-state: incoming publish received
2019-07-22 09:41:26 MQTT_DEVICE Sonoff_Dual_1_2 on
2019-07-22 09:41:26 MQTT_DEVICE Sonoff_Dual_1_1 transmission-state: incoming publish received
2019-07-22 09:41:26 MQTT_DEVICE Sonoff_Dual_1_1 off
2019-07-22 09:41:26 MQTT_DEVICE Sonoff_Dual_1_2 transmission-state: subscription acknowledged
2019-07-22 09:41:26 MQTT_DEVICE Sonoff_Dual_1_1 transmission-state: incoming publish received
2019-07-22 09:41:26 MQTT_DEVICE Sonoff_Dual_1_1 on
2019-07-22 09:41:26 MQTT_DEVICE Sonoff_Dual_1_2 transmission-state: incoming publish received
2019-07-22 09:41:26 MQTT_DEVICE Sonoff_Dual_1_2 on
2019-07-22 09:41:26 MQTT_DEVICE Sonoff_Dual_1_2 transmission-state: incoming publish received
2019-07-22 09:41:26 MQTT_DEVICE Sonoff_Dual_1_2 off
2019-07-22 09:41:26 MQTT_DEVICE Sonoff_S20_1 transmission-state: subscription acknowledged
2019-07-22 09:41:27 MQTT_DEVICE Sonoff_S20_1 transmission-state: incoming publish received
2019-07-22 09:41:27 MQTT_DEVICE Sonoff_S20_1 on
2019-07-22 09:41:27 MQTT_DEVICE Sonoff_S20_1 transmission-state: incoming publish received
2019-07-22 09:41:27 MQTT_DEVICE Sonoff_S20_1 off
2019-07-22 09:41:27 MQTT_DEVICE Sonoff_S20_2 transmission-state: subscription acknowledged
2019-07-22 09:41:27 MQTT_DEVICE Sonoff_S20_2 transmission-state: incoming publish received
2019-07-22 09:41:27 MQTT_DEVICE Sonoff_S20_2 on
2019-07-22 09:41:27 MQTT_DEVICE Sonoff_S20_2 transmission-state: incoming publish received
2019-07-22 09:41:27 MQTT_DEVICE Sonoff_S20_2 off
2019-07-22 09:41:27 MQTT_DEVICE Sonoff_S20_3 transmission-state: subscription acknowledged
2019-07-22 09:41:28 MQTT_DEVICE Sonoff_S20_3 transmission-state: incoming publish received
2019-07-22 09:41:28 MQTT_DEVICE Sonoff_S20_3 on
2019-07-22 09:41:28 MQTT_DEVICE Sonoff_S20_3 transmission-state: incoming publish received
2019-07-22 09:41:28 MQTT_DEVICE Sonoff_S20_3 off
2019-07-22 09:41:28 MQTT_DEVICE Sonoff_S20_4 transmission-state: subscription acknowledged
2019-07-22 09:41:28 MQTT_DEVICE Sonoff_S20_4 transmission-state: incoming publish received
2019-07-22 09:41:28 MQTT_DEVICE Sonoff_S20_4 on
2019-07-22 09:41:28 MQTT_DEVICE Sonoff_S20_4 transmission-state: incoming publish received
2019-07-22 09:41:28 MQTT_DEVICE Sonoff_S20_4 off
2019-07-22 09:41:28 MQTT_DEVICE Sonoff_S20_5 transmission-state: subscription acknowledged
2019-07-22 09:41:29 MQTT_DEVICE Sonoff_S20_5 transmission-state: incoming publish received
2019-07-22 09:41:29 MQTT_DEVICE Sonoff_S20_5 on
2019-07-22 09:41:29 MQTT_DEVICE Sonoff_S20_5 transmission-state: incoming publish received
2019-07-22 09:41:29 MQTT_DEVICE Sonoff_S20_5 off
2019-07-22 09:41:29 MQTT_DEVICE Sonoff_S20_6 transmission-state: subscription acknowledged
2019-07-22 09:41:29 MQTT_DEVICE Sonoff_S20_6 transmission-state: incoming publish received
2019-07-22 09:41:29 MQTT_DEVICE Sonoff_S20_6 on
2019-07-22 09:41:29 MQTT_DEVICE Sonoff_S20_6 transmission-state: incoming publish received
2019-07-22 09:41:29 MQTT_DEVICE Sonoff_S20_6 off
2019-07-22 09:41:29 MQTT_DEVICE Sonoff_S20_7 transmission-state: subscription acknowledged
2019-07-22 09:41:30 MQTT_DEVICE Sonoff_S20_7 transmission-state: incoming publish received
2019-07-22 09:41:30 MQTT_DEVICE Sonoff_S20_7 off
2019-07-22 09:41:30 MQTT_DEVICE Sonoff_S20_7 transmission-state: incoming publish received
2019-07-22 09:41:30 MQTT_DEVICE Sonoff_S20_7 off
2019-07-22 09:41:30 MQTT_DEVICE Sonoff_S20_8 transmission-state: subscription acknowledged
2019-07-22 09:41:30 MQTT_DEVICE Sonoff_S20_8 transmission-state: incoming publish received
2019-07-22 09:41:30 MQTT_DEVICE Sonoff_S20_8 off
2019-07-22 09:41:30 MQTT_DEVICE Sonoff_S20_8 transmission-state: incoming publish received
2019-07-22 09:41:30 MQTT_DEVICE Sonoff_S20_8 off
2019-07-22 09:41:30 MQTT_DEVICE doormodule transmission-state: subscription acknowledged
2019-07-22 09:41:30 MQTT_DEVICE doormodule transmission-state: incoming publish received
2019-07-22 09:41:30 MQTT_DEVICE doormodule on
2019-07-22 09:41:30 MQTT_DEVICE doormodule transmission-state: incoming publish received
2019-07-22 09:41:30 MQTT_DEVICE doormodule off
2019-07-22 09:41:30 MQTT_DEVICE doormodule transmission-state: incoming publish received
2019-07-22 09:41:31 MQTT_DEVICE doormodule on
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: subscription acknowledged
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: incoming publish received
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric incoming-count: 1861
2019-07-22 09:41:31 EQ3BT Flur_Thermostat desiredTemperature 4.5
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric updated-set-count: 1489
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: incoming publish received
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric incoming-count: 1862
2019-07-22 09:41:31 EQ3BT Arbeitszimmer_Thermostat desiredTemperature 4.5
2019-07-22 09:41:31 DOIF Heizungssteuerung_Arbeitszimmer cmd_nr: 4
2019-07-22 09:41:31 DOIF Heizungssteuerung_Arbeitszimmer cmd: 4
2019-07-22 09:41:31 DOIF Heizungssteuerung_Arbeitszimmer cmd_event: Heizungssteuerung
2019-07-22 09:41:31 DOIF Heizungssteuerung_Arbeitszimmer cmd_4
2019-07-22 09:41:31 EQ3BT Wohnzimmer_Thermostat desiredTemperature 4.5
2019-07-22 09:41:31 DOIF Heizungssteuerung_Wohnzimmer cmd_nr: 5
2019-07-22 09:41:31 DOIF Heizungssteuerung_Wohnzimmer cmd: 5
2019-07-22 09:41:31 DOIF Heizungssteuerung_Wohnzimmer cmd_event: Heizungssteuerung
2019-07-22 09:41:31 DOIF Heizungssteuerung_Wohnzimmer cmd_5
2019-07-22 09:41:31 dummy Heizungssteuerung off
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric updated-reading-count: 373
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: incoming publish received
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric incoming-count: 1863
2019-07-22 09:41:31 dummy Lautsprecher on
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric updated-reading-count: 374
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: incoming publish received
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric incoming-count: 1864
2019-07-22 09:41:31 EQ3BT Badezimmer_Thermostat desiredTemperature 4.5
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric updated-set-count: 1490
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: incoming publish received
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric incoming-count: 1865
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: outgoing publish sent
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric outgoing-count: 190
2019-07-22 09:41:31 IT Spot on
2019-07-22 09:41:31 CUL nanoCUL raw: is000000000FFF
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric updated-set-count: 1491
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: incoming publish received
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric incoming-count: 1866
2019-07-22 09:41:31 EQ3BT Kueche_Thermostat desiredTemperature 4.5
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric updated-set-count: 1492
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: incoming publish received
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric incoming-count: 1867
2019-07-22 09:41:31 EQ3BT Schlafzimmer_Thermostat desiredTemperature 4.5
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric updated-set-count: 1493
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: incoming publish received
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric incoming-count: 1868
2019-07-22 09:41:31 EQ3BT Kinderzimmer_Thermostat desiredTemperature 4.5
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric updated-set-count: 1494
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: incoming publish received
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric incoming-count: 1869
2019-07-22 09:41:31 EQ3BT Arbeitszimmer_Thermostat desiredTemperature 4.5
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric updated-set-count: 1495
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: incoming publish received
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric incoming-count: 1870
2019-07-22 09:41:31 EQ3BT Wohnzimmer_Thermostat desiredTemperature 4.5
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric updated-set-count: 1496
2019-07-22 09:41:31 MQTT_DEVICE unicolor_rgb_strip_wohnzimmer transmission-state: subscription acknowledged
2019-07-22 09:41:31 MQTT_DEVICE unicolor_rgb_strip_wohnzimmer transmission-state: incoming publish received
2019-07-22 09:41:31 MQTT_DEVICE unicolor_rgb_strip_wohnzimmer online: true
2019-07-22 09:41:31 MQTT_DEVICE unicolor_rgb_strip_wohnzimmer transmission-state: incoming publish received
2019-07-22 09:41:31 MQTT_DEVICE unicolor_rgb_strip_wohnzimmer rgb: 000000
2019-07-22 09:41:31 MQTT_DEVICE unicolor_rgb_strip_wohnzimmer transmission-state: incoming publish received
2019-07-22 09:41:31 MQTT_DEVICE unicolor_rgb_strip_wohnzimmer rgbmqtt: 0
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: subscription acknowledged
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: incoming publish received
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric incoming-count: 1871
2019-07-22 09:41:31 EQ3BT Flur_Thermostat desiredTemperature 4.5
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric updated-set-count: 1497
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: incoming publish received
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric incoming-count: 1872
2019-07-22 09:41:31 EQ3BT Arbeitszimmer_Thermostat desiredTemperature 4.5
2019-07-22 09:41:31 DOIF Heizungssteuerung_Arbeitszimmer cmd_nr: 4
2019-07-22 09:41:31 DOIF Heizungssteuerung_Arbeitszimmer cmd: 4
2019-07-22 09:41:31 DOIF Heizungssteuerung_Arbeitszimmer cmd_event: Heizungssteuerung
2019-07-22 09:41:31 DOIF Heizungssteuerung_Arbeitszimmer cmd_4
2019-07-22 09:41:31 EQ3BT Wohnzimmer_Thermostat desiredTemperature 4.5
2019-07-22 09:41:31 DOIF Heizungssteuerung_Wohnzimmer cmd_nr: 5
2019-07-22 09:41:31 DOIF Heizungssteuerung_Wohnzimmer cmd: 5
2019-07-22 09:41:31 DOIF Heizungssteuerung_Wohnzimmer cmd_event: Heizungssteuerung
2019-07-22 09:41:31 DOIF Heizungssteuerung_Wohnzimmer cmd_5
2019-07-22 09:41:31 dummy Heizungssteuerung off
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric updated-reading-count: 375
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: incoming publish received
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric incoming-count: 1873
2019-07-22 09:41:31 dummy Lautsprecher on
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric updated-reading-count: 376
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: incoming publish received
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric incoming-count: 1874
2019-07-22 09:41:31 EQ3BT Badezimmer_Thermostat desiredTemperature 4.5
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric updated-set-count: 1498
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: incoming publish received
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric incoming-count: 1875
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: outgoing publish sent
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric outgoing-count: 191
2019-07-22 09:41:31 IT Spot on
2019-07-22 09:41:31 CUL nanoCUL raw: is000000000FFF
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric updated-set-count: 1499
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: incoming publish received
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric incoming-count: 1876
2019-07-22 09:41:31 EQ3BT Kueche_Thermostat desiredTemperature 4.5
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric updated-set-count: 1500
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: incoming publish received
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric incoming-count: 1877
2019-07-22 09:41:31 EQ3BT Schlafzimmer_Thermostat desiredTemperature 4.5
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric updated-set-count: 1501
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: incoming publish received
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric incoming-count: 1878
2019-07-22 09:41:31 EQ3BT Kinderzimmer_Thermostat desiredTemperature 4.5
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric updated-set-count: 1502
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: incoming publish received
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric incoming-count: 1879
2019-07-22 09:41:31 EQ3BT Arbeitszimmer_Thermostat desiredTemperature 4.5
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric updated-set-count: 1503
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric transmission-state: incoming publish received
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric incoming-count: 1880
2019-07-22 09:41:31 EQ3BT Wohnzimmer_Thermostat desiredTemperature 4.5
2019-07-22 09:41:31 MQTT_GENERIC_BRIDGE mqttGeneric updated-set-count: 1504
2019-07-22 09:41:31 MQTT MQTT_Broker DISCONNECTED
2019-07-22 09:41:31 MQTT MQTT_Broker connection: connecting
2019-07-22 09:41:31 MQTT MQTT_Broker CONNECTED
Achso auch hab ich noch des hier gefunden:
2019.07.22 11:43:45 1: PERL WARNING: Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.32), passed through in regex; marked by <-- HERE in m/^(.*)({ <-- HERE .*})(.*)$/ at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 1358.
Habe nun gestern herausgefunden :-D
Selbst bei nur einem Device wo ich die MQTT_GENERIC_BRIDGE verwende knallt es -> ich werde also meine Definitionen nochmal genau prüfen - muss sich ja was geändert haben. Somit sollte der Fehler bei mir liegen - hoffe ich.
Die Warnung hier bleibt logischerweise bestehen:
2019.07.22 11:43:45 1: PERL WARNING: Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.32), passed through in regex; marked by <-- HERE in m/^(.*)({ <-- HERE .*})(.*)$/ at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 1358.
So ich konnte nun isolieren was mir immer den MQTT Broker weg ballert...
Sobald ich das hier als subscribe bei meinem Device (Arbeitszimmer_Thermostat) setze:
desiredTemperature:stopic={"$base/desiredTemperature/set"} desiredTemperature:qos=2 boost:stopic={"$base/boost/set"} boost:qos=2oder auch in dieser Form:
desiredTemperature:stopic={"homeland/haushalt/heizung/Arbeitszimmer_Thermostat/desiredTemperature/set"} desiredTemperature:qos=2 boost:stopic={"homeland/haushalt/heizung/Arbeitszimmer_Thermostat/boost/set"} boost:qos=2Geht nix mehr..... der Broker seines Zeichens IO Device der Generic Bridge fängt dann an mit Disconnect reconnect...im Loop
Natürlich merkt man das auch der FHEM Instanz an - die wird zäh wie Kaugummi.
2019-08-01 15:27:16 MQTT MQTT_Broker connection: active
2019-08-01 15:27:22 MQTT MQTT_Broker DISCONNECTED
2019-08-01 15:27:24 MQTT MQTT_Broker connection: active
2019-08-01 15:27:31 MQTT MQTT_Broker DISCONNECTED
2019-08-01 15:27:33 MQTT MQTT_Broker connection: active
2019-08-01 15:27:40 MQTT_DEVICE Roombot_T_1000 chargesource: No Charging Source
2019-08-01 15:27:40 MQTT MQTT_Broker DISCONNECTED
2019-08-01 15:27:42 MQTT MQTT_Broker connection: active
2019-08-01 15:27:51 TPLinkHS110 Steckdose_Waschmaschine daily_average: 468
2019-08-01 15:27:51 MQTT MQTT_Broker DISCONNECTED
2019-08-01 15:27:52 MQTT MQTT_Broker connection: active
2019-08-01 15:27:58 MQTT MQTT_Broker DISCONNECTED
2019-08-01 15:28:00 MQTT MQTT_Broker connection: active
2019-08-01 15:28:06 MQTT MQTT_Broker DISCONNECTED
2019-08-01 15:28:07 MQTT MQTT_Broker connection: active
2019-08-01 15:28:13 MQTT MQTT_Broker CONNECTED
2019-08-01 15:28:20 MQTT MQTT_Broker DISCONNECTED
2019-08-01 15:28:22 MQTT MQTT_Broker connection: activeBisher erkenne ich meinen Fehler nicht.... :o
Entferne ich das Subscribe - ist alles sofort wieder in Ordnung.
Auch anhand vom Beispiel in der Commandref - kann ich jetzt nix falsches erkennen.
Zitatattr <dev> mqttSubscribe desired-temperature:stopic={"/TEST/temperature/set"}
Zitatattr <dev> mqttSubscribe temperature:topic=/TEST/temperature test:qos=0 *:topic={"/TEST/$reading/value"}
*EDIT* Mir scheint mit
desiredTemperature:stopic={"$base/desiredTemperature/set"} boost:stopic={"$base/boost/set"} funktioniert es nun.
Warum es komplett abgeht mit gesetztem qos für die 2 readings (desiredTemperature:qos=2 und boost:qos=2) ist mir unklar und auch laut commandref nicht "soll". :o
:o Ich vermute einen Fehler gefunden zu haben:
Ein pub:qos=2 sub:qos=2 in den mqttDefaults eines Devices wirkt sich nicht auf subscribe aus.
mqttDefaults base={"homeland/haushalt/heizung/$device"} pub:qos=2 sub:qos=2
mqttPublish desiredTemperature|boost|windowOpen|valvePosition:topic={"$base/$name"} desiredTemperature|boost|windowOpen|valvePosition:qos=2 desiredTemperature|boost|windowOpen|valvePosition:retain=1
mqttSubscribe desiredTemperature:stopic={"$base/desiredTemperature/set"} boost:stopic={"$base/boost/set"}
Dabei ist es egal, ob pub:qos=2 sub:qos=2 oder qos=2 in den defaults steht.
Die genric bridge gibt bei devinfo aus:
publish:
boost => homeland/haushalt/heizung/Arbeitszimmer_Thermostat/boost (mode: R; qos: 2; retain)
desiredTemperature => homeland/haushalt/heizung/Arbeitszimmer_Thermostat/desiredTemperature (mode: R; qos: 2; retain)
valvePosition => homeland/haushalt/heizung/Arbeitszimmer_Thermostat/valvePosition (mode: R; qos: 2; retain)
windowOpen => homeland/haushalt/heizung/Arbeitszimmer_Thermostat/windowOpen (mode: R; qos: 2; retain)
subscribe:
boost <= homeland/haushalt/heizung/Arbeitszimmer_Thermostat/boost/set (mode: S)
desiredTemperature <= homeland/haushalt/heizung/Arbeitszimmer_Thermostat/desiredTemperature/set (mode: S)
Es fehlt also das QOS bei subscribe.
Ansonsten bleibt mein Problem bestehen - dauerhafte Reconnects des MQTT Brokers wenn ich die Generic Bridge hier mit nutze:
Sensoren (mehrere):
mqttDefaults base={"homeland/haushalt/heizung/Arbeitszimmer_Thermostat"} pub:qos=2 sub:qos=2 retain=1
mqttPublish temperature|humidity:topic={"$base/$name"} temperature|humidity:qos=2 temperature|humidity:retain=1
Thermostate (mehrere):
mqttDefaults base={"homeland/haushalt/heizung/$device"}
mqttPublish desiredTemperature|boost|windowOpen|valvePosition:topic={"$base/$name"} desiredTemperature|boost|windowOpen|valvePosition:qos=2 desiredTemperature|boost|windowOpen|valvePosition:retain=1
mqttSubscribe desiredTemperature:stopic={"$base/desiredTemperature/set"} boost:stopic={"$base/boost/set"} desiredTemperature|boost:qos=2
Lüftung:
mqttDefaults base={"homeland/haushalt/heizung/Badezimmer_Thermostat"} pub:qos=2 sub:qos=2 retain=1
mqttPublish state:topic={"$base/ventOn"} state:qos=2 state:retain=1
Spot:
mqttDefaults base={"homeland/haushalt/elektrik/wohnzimmer/$device"} pub:qos=2 sub:qos=2 retain=1
mqttPublish state:topic={"$base/$name"} state:qos=2 state:retain=1
mqttSubscribe state:stopic={"$base/state/set"} state:qos=2
Trockner:
mqttDefaults base={"homeland/haushalt/waschkeller/trockner"} pub:qos=2 pub:retain=1
mqttPublish process:topic={"$base/state"} process:qos=2 process:retain=1
Waschmaschine:
mqttDefaults base={"homeland/haushalt/waschkeller/waschmaschine"} pub:qos=2 pub:retain=1
mqttPublish process:topic={"$base/state"} process:qos=2 process:retain=1
Lautsprecher:
mqttDefaults base={"homeland/haushalt/doors/doormodule/frontdoor/speaker"} pub:qos=2 sub:qos=2 retain=1
mqttForward all
mqttPublish state:topic={"$base/$name"} state:qos=2 state:retain=1
mqttSubscribe state:stopic={"$base/state/set"} state:qos=2
Das hier:
subscribe:
boost <= homeland/haushalt/heizung/Flur_Thermostat/boost/set (mode: S; qos: 2)
desiredTemperature <= homeland/haushalt/heizung/Flur_Thermostat/desiredTemperature/set (mode: S; qos: 2)
Erreiche ich nur darüber, dass ich es beim subscribe angebe.
Ich werde jetzt mal Device für Device einbinden.... wenn es dann wieder geht - dann muss es irgendwie ne Art Timing/RaceCondition sein oder sowas.... Ab einer gewissen menge von Devices - ich habe 21 Stück - evtl muss man da was takten?
vorl. Ergebnis: Bisher habe ich alle Devices bis auf 3 - bei jedem dieser einzelnen kam es direkt zu problemen - wieder hinzugefügt. Global definiertes QOS schert sich das subrscribe weiter nicht drum. Nun erstmal ins Freibad...
Neue Erkenntnisse: Die 3 Geräte habe ich weiter nicht eingepflegt - dafür fing gerade das gleiche Problem mit den bereits eingebundenen an - mir scheint es ist wirklich ein Timing Problem - denn vorangegangen war ein FHEM Neustart. Selbst mit nur einem Device besteht das Problem des disconnectenden Brokers.
So besteht das Problem:
mqttSubscribe desiredTemperature:stopic={"$base/desiredTemperature/set"} boost:stopic={"$base/boost/set"} desiredTemperature|boost:qos=2
So nicht:
mqttSubscribe desiredTemperature:stopic={"$base/desiredTemperature/set"} boost:stopic={"$base/boost/set"}
Ist da was defekt oder mache ich etwas falsch @hexenmeister?
Nabend, ich versuche gerade die FHEM Bridge ans Laufen zu bekommen.
Ich habe aber Probleme das er meine Sensoren nur "bei Lust" akzeptiert".
FHEM 6 ist relativ "clean" Heute frisch installiert - Eigentlich soll dieses FHEM nur die Werte an ein anderes liefern ...
fhem.pl 21573 2020-04-01 16:26:14Z rudolfkoenig
96_allowed.pm 21197 2020-02-14 14:32:04Z rudolfkoenig
90_at.pm 17561 2018-10-18 14:45:30Z rudolfkoenig
98_autocreate.pm 20791 2019-12-20 17:30:57Z rudolfkoenig
91_eventTypes.pm 14888 2017-08-13 12:07:12Z rudolfkoenig
01_FHEMWEB.pm 21367 2020-03-06 12:32:42Z rudolfkoenig
92_FileLog.pm 20826 2019-12-25 19:06:07Z rudolfkoenig
98_help.pm 21551 2020-03-31 11:01:06Z betateilchen
00_MQTT.pm 21587 2020-04-03 21:49:47Z hexenmeister
10_MQTT_GENERIC_BRIDGE.pm 19737 2019-06-28 15:56:35Z hexenmeister
75_msgConfig.pm 18995 2019-03-22 20:09:53Z loredo
11_OWDevice.pm 14523 2017-06-16 05:15:56Z neubert
10_OWServer.pm 16501 2018-03-27 11:27:13Z neubert
99_SUNRISE_EL.pm 18732 2019-02-25 13:15:34Z rudolfkoenig
99_Utils.pm 21112 2020-02-04 10:02:12Z rudolfkoenig
98_version.pm 15140 2017-09-26 09:20:09Z markusbloch
Blocking.pm 17553 2018-10-17 15:56:35Z rudolfkoenig
DevIo.pm 20174 2019-09-16 18:04:03Z rudolfkoenig
GPUtils.pm 19666 2019-06-20 11:17:29Z CoolTux
HttpUtils.pm 21529 2020-03-28 07:15:44Z rudolfkoenig
Meta.pm 21008 2020-01-18 10:22:10Z loredo
msgSchema.pm 21075 2020-01-29 19:46:59Z CoolTux
No Id found for OWNet-3.1p5.pm
RTypes.pm 10476 2016-01-12 21:03:33Z borisneubert
TcpServerUtils.pm 21344 2020-03-03 11:10:07Z rudolfkoenig
fhemweb.js 21316 2020-02-29 20:24:41Z rudolfkoenig
Meine Config:
defmod MQTT MQTT 192.168.2.3:1883
attr MQTT alias Verbindung zu MQTT DSRV3
attr MQTT last-will /fhem/status crashed
attr MQTT on-connect /topic/status connected
attr MQTT room 99_MQTT
und
defmod mqttGeneric MQTT_GENERIC_BRIDGE mqtt room=Temps
attr mqttGeneric IODev MQTT
attr mqttGeneric alias Brücke - sammelt Lokale MQTT Infos ein
attr mqttGeneric debug 1
attr mqttGeneric globalDefaults sub:qos=2 pub:qos=0 retain=1
attr mqttGeneric room 99_MQTT
attr mqttGeneric stateFormat Devices device-count<br/>\
Raus outgoing-count<br/>\
Rein incoming-count
attr mqttGeneric verbose 5
Dann 5 Sensoren - Nur 3 Stück zeigt er an.
Als Beispiel mal einer der klappt.
defmod DS18B20_FFF659931604 OWDevice 28.FFF659931604 60
attr DS18B20_FFF659931604 userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
attr DS18B20_FFF659931604 IODev OWServerMW10
attr DS18B20_FFF659931604 alias MW10PFOben
attr DS18B20_FFF659931604 model DS18B20
attr DS18B20_FFF659931604 mqttPublish temperature:topic=/haus/sensor/temperature/MW10PFOben
attr DS18B20_FFF659931604 room Temps
Der auch ...
defmod DS18B20_AA24CF3B1401 OWDevice 28.AA24CF3B1401 60
attr DS18B20_AA24CF3B1401 userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
attr DS18B20_AA24CF3B1401 IODev OWServerMW10
attr DS18B20_AA24CF3B1401 alias MW10SolarVL
attr DS18B20_AA24CF3B1401 model DS18B20
attr DS18B20_AA24CF3B1401 mqttPublish temperature:topic=/haus/sensor/temperature/MW10SolarVL
attr DS18B20_AA24CF3B1401 room Temps
Der hier ging mal - Nach einem Neustart nicht mehr ??
defmod DS18B20_AA86753B1401 OWDevice 28.AA86753B1401 60
attr DS18B20_AA86753B1401 userattr mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
attr DS18B20_AA86753B1401 IODev OWServerMW10
attr DS18B20_AA86753B1401 alias MW10PF Mitte
attr DS18B20_AA86753B1401 model DS18B20
attr DS18B20_AA86753B1401 mqqtPublish temperature:topic=/haus/mw10/temperature/MW10PFMitte
attr DS18B20_AA86753B1401 mqttDisable incoming
attr DS18B20_AA86753B1401 mqttForward all
attr DS18B20_AA86753B1401 room Temps
2 weitere würde ich auch gerne ans Laufen kriegen.
Dort habe ich auch dies ...
mqqtPublish temperature:topic=/haus/mw10/temperature/MW10PFUnten
Aber das Device wird nicht angenommen.
Werte bekommen die Sensoren alle 60sec.
Die Debug Info zeigt auch nur 3 / Ein debugReinit bringt nichts.
initialized: 1
device data records: $VAR1 = {
'DS18B20_FF32F5831603' => {
':publish' => {
'temperature' => {
'topic' => '/haus/sensor/temperature/MW10WaWaRL',
'last' => '1586379448.85751',
'mode' => 'R'
}
}
},
':global' => {
':publish' => {},
':defaults' => {
'pub:qos' => '0',
'pub:retain' => '1',
'sub:qos' => '2',
'sub:retain' => '1'
}
},
'DS18B20_AA24CF3B1401' => {
':publish' => {
'temperature' => {
'last' => '1586379447.94551',
'topic' => '/haus/sensor/temperature/MW10SolarVL',
'mode' => 'R'
}
}
},
'DS18B20_FFF659931604' => {
':publish' => {
'temperature' => {
'mode' => 'R',
'last' => '1586379449.95557',
'topic' => '/haus/sensor/temperature/MW10PFOben'
}
}
}
};
subscriptionTab: $VAR1 = undef;
subscription helper array: $VAR1 = [];
exclude type map: $VAR1 = {
'sub' => {
'MQTT_BRIDGE' => 'transmission-state',
'MQTT_GENERIC_BRIDGE' => '*',
'FHEMWEB' => '*',
'telnet' => '*',
'MQTT' => 'transmission-state',
'MQTT_DEVICE' => 'transmission-state',
'Global' => '*'
},
'pub' => {
'MQTT_BRIDGE' => 'transmission-state',
'MQTT_GENERIC_BRIDGE' => '*',
'FHEMWEB' => '*',
'telnet' => '*',
'MQTT' => 'transmission-state',
'MQTT_DEVICE' => 'transmission-state',
'Global' => '*'
}
};
exclude reading map: $VAR1 = {};
exclude device map: $VAR1 = {};
Was mache ich falsch ?
Hallo,
bin grad dabei, die generic bridge auf zwei fhem-instanzen einzurichten, um diese (anstatt fhem2fhem) miteinander zu verbinden.
Dabei bin ich auf folgende Frage gestoßen:
Gibt es eigentlich eine Möglichkeit, alle Readings/Attribute für ein device zu publishen?
Hintergrund ist, zu testen, ob alles von einer Instanz richtig zu der anderen wandert. Interne Readings kann man bei den meisten (oder allen?) devices ja nicht setzen, um ein publish auszulösen.
Ich hoffe, ich habe eine entsprechende Funktion nicht in der Doku überlesen....
cheers,
Pula
Hallo nochmal,
ich hoffe, irgendwer liest diesen thread noch.
Ich habe folgendes Problem:
Würde gerne die kodi-devices vom Haupt-fhem auf die nicht zeitkritische fhem-instanz verschieben und die Readings per mqtt_generic_bridge zum Haupt-Fhem schicken. "Leider" legt das kodi-modul ziemlich viele Readings dynamisch an (zb die Readings für die einzelnen channels).
Gibt es eine Möglichkeit, per mqtt_generic_bridge fehlende readings/attribute auch gleich anlegen zu lassen?
cheers,
Pula
Zitat von: skynet am 08 April 2020, 23:00:25
Nabend, ich versuche gerade die FHEM Bridge ans Laufen zu bekommen.
Ich habe aber Probleme das er meine Sensoren nur "bei Lust" akzeptiert".
...
Was mache ich falsch ?
Nicht "bei Lust", sondern wenn die Attributnamen richtig geschrieben werden. Am besten die Oberfläche verwenden.
Es gibt keinen mit dem Namen "mqqtPublish".
Zitat von: pula am 28 Mai 2020, 15:10:50
Hallo,
bin grad dabei, die generic bridge auf zwei fhem-instanzen einzurichten, um diese (anstatt fhem2fhem) miteinander zu verbinden.
Dabei bin ich auf folgende Frage gestoßen:
Gibt es eigentlich eine Möglichkeit, alle Readings/Attribute für ein device zu publishen?
Hintergrund ist, zu testen, ob alles von einer Instanz richtig zu der anderen wandert. Interne Readings kann man bei den meisten (oder allen?) devices ja nicht setzen, um ein publish auszulösen.
Ich hoffe, ich habe eine entsprechende Funktion nicht in der Doku überlesen....
cheers,
Pula
Readings und auch Attribute kann man senden und empfangen (auch alle, mit *:topic und *:atopic). Internals kann man weder setzen nocht senden, noch empfangen. Das sind, wie der Name schon sagt, die Internen Daten des Gerätemoduls.
Zitat von: pula am 29 Mai 2020, 15:34:33
Hallo nochmal,
ich hoffe, irgendwer liest diesen thread noch.
Ich habe folgendes Problem:
Würde gerne die kodi-devices vom Haupt-fhem auf die nicht zeitkritische fhem-instanz verschieben und die Readings per mqtt_generic_bridge zum Haupt-Fhem schicken. "Leider" legt das kodi-modul ziemlich viele Readings dynamisch an (zb die Readings für die einzelnen channels).
Gibt es eine Möglichkeit, per mqtt_generic_bridge fehlende readings/attribute auch gleich anlegen zu lassen?
cheers,
Pula
Ja, aber es wird mit ziemlicher Sicherheit nicht funktionieren, an beiden Seiten ein Kodi-Device zu verwenden. Eine Seite muss mit Dummy nachgebaut werden.
Zitat von: hexenmeister am 29 Mai 2020, 18:55:45
Readings und auch Attribute kann man senden und empfangen (auch alle, mit *:topic und *:atopic). Internals kann man weder setzen nocht senden, noch empfangen. Das sind, wie der Name schon sagt, die Internen Daten des Gerätemoduls.
Sorry, ich hatte mich ungenau ausgedrückt. Was ich meinte, war ob es möglich ist alle per Befehl zu publishen (und nicht erst, wenn sich etwas ändert oder ein Reading/Attribut ein update erfährt). Sozusagen ein send all now....
cheers,
Pula
Zitat von: hexenmeister am 29 Mai 2020, 18:57:42
Ja, aber es wird mit ziemlicher Sicherheit nicht funktionieren, an beiden Seiten ein Kodi-Device zu verwenden. Eine Seite muss mit Dummy nachgebaut werden.
Sorry, ich muss an der Genauigkeit meiner Beschreibungen arbeiten.
Was ich hier meinte:
In dem dummy-device (das auf der "empfangenden" Seite das Kodi-device nachbilden soll) werden Atrribute/Readings die nicht existieren ja von mqtt_generic_bridge nicht angelegt, oder irre ich mich hier? Da das kodi-device hier laufend viele Dinge anlegt (zb neue channels), müsste man den dummy jedesmal anpassen, oder?
Cheers,
Pula
Hexenmeister hat's doch geschrieben!
Zitat von: hexenmeister am 29 Mai 2020, 18:55:45
Readings und auch Attribute kann man senden und empfangen (auch alle, mit *:topic und *:atopic).
Probiers doch einfach mal aus! Dann wirst du sehen was geht! ;)
Billy
Nice!
Danke für den Hinweis. Scheint zu funktionieren, hatte ich nicht erwartet!
Danke an hexenmeister für dieses tolle Modul!
Cheers,
Pula
Sowas wie send all gibt s bisher nicht.
Allerdings kann man schon generisch alle Readings senden und auch empfangen. DIese werden dann beim ersten Empfang angelegt. Steht in der Doku sogar mit Beispiel.
attr <dev> mqttSubscribe *:topic={"/TEST/$reading"}
Hier: der Part des Topics, wo $reading steht, wird hier als eine (ggf. neue) Readings interpretiert.
Das funktioniert ja wuderbar so weit.
Auf die Gefahr hin, mich noch einmal zu blamieren, weil ich den Thread/die Doku nicht genau genug gelesen habe:
Habt ihr auch eine Idee, wie man mit commands umgehen könnte?
Zum Beispiel unterstützt das Kodi-Modul ein command "msg", das einen übergebenen String dann an kodi sendet und den String dann auf dem TV einblendet. Das geht so jetzt natürlich nicht....
Cheers,
Pula
Zitat von: pula am 03 Juni 2020, 13:06:32
Das geht so jetzt natürlich nicht....
Doch ;D
Dafür gibt es spezielle topic Syntax, es werden dann Befehle ausgeführt. Halte Ausschau nach stopic.
VIELEN DANK! Das klappt ja hervorragend.
Nur der Vollständigkeit halber: Ist es sinnvoll, das so zu definieren:
*:stopic={"fhem/$device/$reading"}
Oder gibt das Probleme, falls "normale" readings definiert werden?
Ein zusätzliches
*:topic={"fhem/$device/$reading"}
wird hier ja kaum zielführend sein.
Wie ist das gedacht? Für "normale" readings und attribute das topic verwenden (also *:topic....) und die Kommandos dann per stopic explizit auflisten?
Sorry, dass ich hier so penetrant nachfrage, ich will es nur verstehen...
Cheers,
Pula
Auf denselben Topic zu mappen ist natürlich nicht sinnvoll. Einzelnauflisten muss man jedoch auch nicht.
Die Pfade sollen sich unterscheiden.
Z.B.:
*:topic={"fhem/$device/readigs/$reading"}
*:stopic={"fhem/$device/cmds/$reading"}
Ah, super! Das ist des "Rätsels" Lösung :-)
Vielen Dank nochmal für das tolle Modul und auch für die Geduld beim Beantworten der (wahrscheinlich schon diskutierten) Fragen!
Cheers,
Pula
@Hexenmeister
Du hast mir vor langer Zeit eine Frage gestellt?
Auswahl von Readings aus JSON ist derzeit nicht möglich, werden alle genommen. Wäre das wichtig?
Zitat von: hexenmeister am 12 November 2018, 18:13:49
Kannst genauso nehmen, wie es ist (nur Topic wäre noch anzupassen):
json:topic=/TEST/json json:expression={json2nameValue($message)}
Auswahl von Readings aus JSON ist derzeit nich möglich, werden alle genommen. Wäre das wichtig?
Könnte ich ab und zu gebrauchen.
Hast du eine IDEE?
Billy
Zitat von: Billy am 31 August 2020, 17:33:36
Hast du eine IDEE?
Da man json2nameValue() verwenden kann, sollte das mit der erweiterten Form möglich sein:
- entweder ein jsonMap an die Funktion übergeben oder
- das (recht neue) 4. Argument "filter" nutzen (ist eine regex).
Bitte um Info, wenn dazu mehr input erforderlich ist, für beides ist vermutlich noch recht wenig Material zu finden ($JSONMAP schon, aber man kann da afaik auch einen Hash übergeben, und dafür gibt es noch wenig Beispiele).
Danke, ist im Augenblick nicht wichtig, war nur über den alten Thread gestolpert.
Hätte ja sein können, dass es was gibt was ich noch nicht kenne. ;)
OK, du kanntest demnach das 4. Argument von json2nameValue() schon ;) ?
(Vielleicht solltest du ein konkretes Beispiel von einem JSON liefern und Info, was du daraus denn verwenden willst, sonst ist es schwierig zu helfen. Das Thema ist ziemlich abstrakt).
Hallo,
kurze Zwischenfrage:
Ich verwende den fhem-internen MQTT2_SERVER für die Anbindung einiger Tasmota-Geräte.
Weiterhin verwende ich als Frontend Home Assistant und da läuft auch nochmal ein Mosquitto mit drauf.
Die Verbindung von fhem zu Home Assistant macht ein MQTT-Device in fhem, das auf den Mosquitto-Broker verweist und eine MQTT_GENERIC_BRIDGE mit globalPublish, eingeschränkt auf einen fhem-room.
Die fhem-Devices, die ich in HomeAssistant verwenden will, packe ich dann zusätzlich in diesen room.
Das klappt soweit erstmal ganz gut.
Jetzt stehe ich vor dem Problem, dass ich auch die readings eines Tasmota-Device (MQTT2_DEVICE), das an fhem über den internen MQTT2_SERVER angebunden ist, an HomeAssistant weiterleiten will. Wenn ich das in den entsprechenden fhem-room packe, wird das aber von der Bridge offenbar ignoriert und in Home Assistant kommt nichts an. Auch dann, wenn ich refrehsUserAttr auslöse, und bei dem Tasmota-Gerät
attr <tasmota-device> mqttForward all
setze. Ist das "by-design" nicht möglich, oder mache ich was falsch ? Gibt es hier eine "elegante" Lösung, oder muss ich mit dummy / readingsproxy und zig notifiys rumtricksen ?
Grüße, gadget
Habe zwar keine Ahnung von Home Assistant. :'(
Kann sich HA nicht direkt mit Tasmota verbinden, ohne Umweg über FHEM etc?
klar, aber das "Brain" meiner Hausautomatisierung soll weiterhin fhem sein. Home Assistant nutze ich nur als hübsches Frontend für die Mitbewohner.
Hallo an alle,
kurze Frage, wie setzt man mit MQTT_GENERIC_BRIDGE einen "get update" ab?
Habe in Nodered meine Homematic Heizungsthermostate integriert und es wäre schön
wenn beim Aufrufen der Seite auch gleich die aktuellen Werte geholt werden.
Jemand eine Idee?
was soll "get update" denn machen ? Lass die messages deiner geräte mit retain=1 senden (z.B. in den global defaults der MQTT_GENERIC_BRIDGE). Dann speichert der mqtt broker die letzte Nachricht und Nodered bekommt sofort nach Start den letzten Stand des topics. Falls du auch in fhem bei deinen Heizungsthermostaten keine aktuellen Werte hast, musst Du erst mal den Homematic-Teil in Ordnung bringen, siehe z.B.
Zitathttps://forum.fhem.de/index.php/topic,40189.msg641541.html#msg641541
"get update" holt die aktuellen Werte von der CCU ab und weil die Werte sich ändern, feuert auch die MQTT_GENERIC_BRIDGE.
Mit Retain senden bringt garnichts, weil NodeRed die MQTT Verbindung zu Mosquitto die ganze Zeit aufrecht erhält...
ich kenne Homematic jetzt nicht genau, aber ich würde erwarten dass deine homematic devices sich von selbst aktualisieren, wenn sich der Zustand ändert ?! So kenne ich das jedenfalls von MAX! und FritzDect 301. Wenn Du allerdings von Nodered was in fhem auslösen willst, kannst Du dir ja bei deinem Device ein zusätzliches stopic zum Auslösen anlegen, also z.B.
set <hmdevice> mqttSubscribe desired-temp:stopic={"$base/desired-temp/set"} statusRequest:stopic={"$base/statusRequest"}und da dann von NodeRed aus ein Leerzeichen hinschicken oder so.
In der commandref
Zitathttp://192.168.178.39:8083/fhem/docs/commandref_DE.html#CUL_HM
finde ich zu HomeMatic übrigens kein "get update" ? Ich nehme an Du meinst "status request" ?
Edit: Das solltest Du IMHO auch nicht allzu oft machen bei batteriebetriebenen Geräten ....
Zitat von: gadget am 13 September 2020, 13:16:56
In der commandref finde ich zu HomeMatic übrigens kein "get update" ? Ich nehme an Du meinst "status request" ?
Hab ein Screenshot angehängt, es handelt sich um ein HMCCUDEV.
ein "get" is IMHO bei der MQTT_GENERIC_BRIDGE nicht implementiert. Du könntest rumtricksen z.B. mit einem MQTT_DEVICE, das auf einem topic Befehle empfängt und die dann über ein notify ausführt. Also so was ähnliches wie in
Zitathttps://www.loxwiki.eu/pages/viewpage.action?pageId=70353530
Ich würde das aber auf zumindest auf "get" einschränken, also im notify
my $cmnd = "get ".$1; und dann auf das topic von Nodered aus das get-Kommando senden (ohne get davor).
Oder du machst Dir bei denen HM-Geräten ein userreading, mappst das mit einem mqtt Subscribe ("topic" statt "stopic") und reagierst mit einem Notify oder DOIF auf Updates dieses Readings und die Reaktion kann ja auch ein get .... sein.
Sehr gut, Danke :-)
Hab nen Dummy erstellt, dessen Notify das "get update" an der CCU auslöst. Klappt!
Hallo hexenmeister,
schau mal bitte in https://forum.fhem.de/index.php/topic,118586.msg1131337.html#msg1131337 - ich versuche rauszufinden, warum in einer Kombination aus DOIF, MQTT_Generic_Bridge und eocr/event-min-interval kein Publish stattfindet.
Danke dir.
Moin :-)
Ich weiß hier ist nicht mehr viel lost, da eigentlich wohl eine andere Bridge das abgelöst hat.
ich nutze die hier weiter produktiv und wunderte mich über folgende Entdeckung:
mqttPublish
state:topic={"$base/$name"} state:qos=1 state:retain=1
Das genutzt um einen state (on/off) zu publishen und irgendwie wird das retain aber nicht umgesetzt - so sieht es zumindest für mich aus.
Client mqtt_pub received PUBLISH (d0, q1, r0, m18, 'homeland/haushalt/energy/saving/state', ... (5 bytes))
Client mqtt_pub sending PUBACK (m18, rc0)
homeland/haushalt/energy/saving/state false
Was mache ich falsch?
Settings für die Bridge im Device sind:
mqttDefaults base={"homeland/haushalt/energy/saving"}
mqttForward all
mqttPublish state:topic={"$base/$name"} state:qos=1 state:retain=1
mqttSubscribe state:stopic={"$base/state/set"}
PS: Ich scheine das gleiche Problem aber auch bei normalen MQTT Devices zu haben - auch da kein retain O_o Am Mosquitto liegt es net aus Node-Red kommt mit Retain.
Habt dank :-)
https://forum.fhem.de/index.php/topic,131618.msg1257838.html#msg1257838
Kann es sein, dass das limit des mosquitto-Servers überschritten ist: https://stackoverflow.com/questions/67344858/mqtt-mosquitto-broker-does-not-sent-all-retained-messages (https://stackoverflow.com/questions/67344858/mqtt-mosquitto-broker-does-not-sent-all-retained-messages) (1020 per default, wenn ich das richtig interpretiert habe).
MQTT_GENERIC_BRIDGE ist mAn. auch weiter aktuell, es wurde nur daran gearbeitet, dass man es auch (besser) mit MQTT2_(CLIENT|SERVER) nutzen kann.
Also ich nutze ja gar keinen MQTT2 daher sollte mich das gar nicht touchieren oder? @Ralli
Mh Limits würde das Log mir ja aufweisen - wäre so meine Denkweise. @Beta-User
Ich schaue mal, ob ich was finde. Hatte aber auch die DB vom mosquitto nun gekillt - somit sollte da nix großes drin sein und dennoch geht es nicht.
Mein Mosquitto ist in FHEM mittels Modul 00_MQTT.pm eingebunden.
Zitat von: Master_Nick am 18 Januar 2023, 14:03:08
Mh Limits würde das Log mir ja aufweisen - wäre so meine Denkweise. @Beta-User
Welches Log? Möglicherweise das mosquitto-log, aber sicher wäre ich mir da nicht, dass man da viel findet...
Vielleicht mal schauen, was 00_MQTT so versendet (verbose 5 müßte u.a. auch die gesendeten Messages aufzeichnen)?
Zitat von: Beta-User am 18 Januar 2023, 14:14:42
Welches Log? Möglicherweise das mosquitto-log, aber sicher wäre ich mir da nicht, dass man da viel findet...
Vielleicht mal schauen, was 00_MQTT so versendet (verbose 5 müßte u.a. auch die gesendeten Messages aufzeichnen)?
Sehr guter Ansatz - und siehe da....
2023.01.18 14:17:22 5 : MQTT_GENERIC_BRIDGE:DEBUG:> [mqttGeneric] publish: homeland/haushalt/energy/saving/state => false (qos: 2, retain: 1Damn ... es ist nicht innerhalb FHEM - dann geh ich mal forschen.
Danke!
Bin ich denn richtig gewickelt - das r0 bei mosquitto clients ist retain 0 oder?
:)
Viel Spaß beim suchen...
Zitat von: Master_Nick am 18 Januar 2023, 14:18:11
Bin ich denn richtig gewickelt - das r0 bei mosquitto clients ist retain 0 oder?
Ich denke schon, müßte aber auch in der Doku schauen. Was "aktuell" da ist, müßte man z.B. mit mosquitto_sub rausfinden. Das in eine Datei pipen, und Zeilen zählen ;) ?
Allgemeiner Hinweis: nach diversen Diskussionen u.a. mit Rudi zu den QoS und retain-Themen bin ich zwischenzeitlich eher skeptisch, was den großflächigen Einsatz dieser Optionen angeht. Manche Geräte sind in der Richtung auch eher weniger vorsichtig, so dass man uU. - je nach Umfeld - relativ schnell eine Menge Topics zusammenbringt, auf die "irgendjemand" per retain sendet.
War einer der Gründe, warum zwischenzeitlich (6.2) auch M2S die retain-Messages im default nicht für einen Neustart abspeichert...
Um Schaltzustände bei Licht klar zu halten ist das tatsächlich ganz angenehm.
Egal was passiert - die richten sich dann nach dem was der letzte "retained" Schaltbefehl war.
Ja. Wir hatten hier aber auch schon unmotivierte Rollladenfahrten mitten in der Nacht. Weniger angenehm...
(wir brauchen das nicht zu vertiefen; ist ja ok, wenn es für dich paßt!).
Hehe - ja man will es nicht überall -> bin ich bei dir :-)
Jips passen muss es.
ich hatte auch schon mein WTF... und hab Retain an vielen Stellen raus geworfen.
Mein aktuelles Problem ist -> einiges wird als Retained gesendet und das von FHEM anscheinend nicht angenommen als Retain (Work in Progress was das Debugging an geht).
Die Mischung ist seeehr nervig -> Licht an mitten in der Nacht weil ein Einschaltbefehl retained war aber der Ausschalt nicht :-D
Zitat von: Master_Nick am 18 Januar 2023, 15:34:13
Mein aktuelles Problem ist -> einiges wird als Retained gesendet und das von FHEM anscheinend nicht angenommen als Retain (Work in Progress was das Debugging an geht).
Die Mischung ist seeehr nervig -> Licht an mitten in der Nacht weil ein Einschaltbefehl retained war aber der Ausschalt nicht :-D
Ähm, bin nicht sicher, was den Ablauf angeht...
Zum einen wirkt sich das ja nur aus, wenn eine Seite neu gestartet wird, also (nur mit entsprechender Einstellung!) der Mosquitto oder FHEM.
Aber: Wenn erst was mit flag gesendet wird und dann ohne, ist am Ende nichts mehr da, wenn der Befehl zwischenzeitlich nicht zugestellt werden konnte. Falls sowas vorkommt (ist eine MQTT-App im Spiel?), wird dieser "Platz" ggf. auch für ein anderes retain frei... (Insbesondere, falls es diese 1000/1020-Beschränkung ist).
"Aber: Wenn erst was mit flag gesendet wird und dann ohne, ist am Ende nichts mehr da, wenn der Befehl zwischenzeitlich nicht zugestellt werden konnte"
Ich nutze es ja so, dass wenn ein Device (SonOff z. B.) neu startet er einen retained Befehl bekommt um den Zustand von vorm Neustart anzunehmen.
Das gar nichts mehr da ist wenn auf ein und dem selben Punkt erst Retain und dann ohne kommt - muss ich mal testen - weiß ich nicht :-D
Ich teste nun mal dies hier was ich gefunden habe auf Stackoverflow bezüglich mosquitto:
max_inflight_messages count
The maximum number of outgoing QoS 1 or 2 messages that can be in the process of being transmitted simultaneously. This includes messages currently going through handshakes and messages that are being retried. Defaults to 20. Set to 0 for no maximum. If set to 1, this will guarantee in-order delivery of messages.
max_queued_messages count
The maximum number of QoS 1 or 2 messages to hold in the queue (per client) above those messages that are currently in flight. Defaults to 1000. Set to 0 for no maximum (not recommended). See also the queue_qos0_messages and max_queued_bytes options.
**Edit: Mh aus FHEM kommt immer noch unretained ???
Ich verlager das mal hier heraus zu einem allgemeinen Problem. Bin gespannt. --> https://forum.fhem.de/index.php/topic,131709.0.html