Einleitung
Vor einige Zeit hatte ich mich ja intensiv mit dem Thema Funk Protokolle auseinandergesetzt und mich bewusst für EnOcean entschieden. Zu diesem Zeitpunkt war es für mich auf vielerlei Hinsicht das beste Protokoll. Um die Bastelaktivitäten etwas zu beschränken, bin ich dann irgendwann von meiner EnOcean Pi Umgebung, welche ich für die Tests genutzt habe auf ein Weinzierl EnOcean Gateway <Type> gegangen. Selbiger arbeitet einwandfrei und kümmert sich um einige EnOcean Licht Aktoren in der Küche.
Nun wollte ich noch weitere Aktoren integrieren, doch bin dabei leider an die Grenzen gestoßen. Nicht etwas, weil die Anzahl der Aktoren nicht ausreichend ist, sondern weil das Gateway bestimmte Geräte EEPs nicht unterstützt. Insbesondere die Produkte von NodOn (Bewerbungsmelder und Micro Smart Plugin) konnte ich nicht direkt in das Gateway einbinden. Elend lange Recherchen im Internet förderten dann zu Tage, dass auch andere dieses Problem haben und es vom Herstellers keine Anpassungen geben wird. Ich hatte das Thema EEP Unterstützung massiv unterschätzt und stand jetzt mit einem Gateway dar, dass bestimmte Geräte nicht unterstützt und welches auch nicht erweitert werden konnte.
Mein Hauptargument für EnOcean war ja eigentlich die Offenheit und die herstellerübergreifende Unterstützung des Protokolls. Dem ist aber nicht so. Nachdem ich mich etwas abgeregt hatte, musste also eine neue Strategie her. Und wie immer ein solchen Situationen heißt es dann Selbermachen. Also bin ich wieder auf meine altbewährte Raspberry Platform gegangen um zu schauen, ob es nicht doch etwas besser geht.
Um die Sende- und Empfangsleistung zu verbessern, habe ich mich für einen USB EnOcean Stick mit SMA Schnittstelle für eine externe Antenne entschieden. Nach etwas Recherche habe ich dann das diesen Stick bestellt.
Erste Funktionstests
Als Basis habe ich das aktuelle Raspian OS (Linux raspi-test-2 4.19.97-v7l+ #1294 SMP Thu Jan 30 13:21:14 GMT 2020 armv7l GNU/Linux), also die Debian 10.3 Basis genommen.
Direkt nach dem Einstecken des Sticks wurde selbiger auch direkt erkannt und auch das UART Interface wurde auf ttyUSB0 gemappt
kernel: [134209.304162] usb 1-1.3: new full-speed USB device number 4 using xhci_hcd kernel: [134209.460435] usb 1-1.3: New USB device found, idVendor=0403, idProduct=6001, bcdDevice= 6.00 kernel: [134209.460452] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 kernel: [134209.460466] usb 1-1.3: Product: FT232R USB UART kernel: [134209.460479] usb 1-1.3: Manufacturer: FTDI kernel: [134209.460491] usb 1-1.3: SerialNumber: A908ORDH kernel: [134209.467140] ftdi_sio 1-1.3:1.0: FTDI USB Serial Device converter detected kernel: [134209.467291] usb 1-1.3: Detected FT232RL kernel: [134209.470560] usb 1-1.3: FTDI USB Serial Device converter now attached to ttyUSB0
Der Stick nutzt den FT232R FTDI Chip, welcher relativ häufig als Serial / USB Bridge bei USB Geräten zum Einsatz kommt. So jetzt noch schnell schauen, ob auch Signale ankommen.
sudo stty -F /dev/ttyUSB0 57600 sudo hexdump < /dev/ttyUSB0
Dann mal den button auf einem PTM215 DB gedrückt und geschaut ob was kommt. Ja, es kommen Daten an.
sudo hexdump < /dev/ttyUSB0 0000000 0055 0707 7a01 30f6 f9fe 1b59 0030 ffff 0000010 ffff 0031 5511 0700 0107 f67a fe00 59f9
EnOcean Telegram Monitor installieren
Da die Datenauswertung über hexdump etwas mühsam ist, habe ich mich auf die Suche nach besseren EnOcean Telegram Analyse-Tools gemacht. Ich bin dann auf node-enocean-utils gestoßen. Diese kleinen Programme sind sehr hilfreich bei der Diagnose von EnOcean Telegrammen.
Die Installation geht fix:
cd ~ git clone https://github.com/futomi/node-enocean-utils.git cd node-enocean-utils sudo npm install serialport --unsafe-perm --build-from-source cd tools sudo node analyzer.js /dev/ttyUSB0
Achtung: Manchmal kommt nach dem ersten Start die Meldung „ERROR: No USB gateway was found.“. Dann einfach nochmal starten.
Und schon kommen die ersten Telegramme rein. Hier mein Klick auf den PTM215 als Dump vom node-enocean-utils.
=============================================================================================================================================== [Summary] - HEX |55 00 07 07 01 7A F6 30 FE F9 59 1B 30 00 FF FF FF FF 37 00 6F - Packet Type |RADIO_ERP1 (Radio telegram) - Device Name |Unknown - Device ID |0000FEF9591B - Manufacturer |Unknown - EEP |Unknown - RORG |Unknown - FUNC |Unknown - TYPE |Unknown - Data |Unknown - Learn |Unknown - Known |false - RSSI |-55 dBm - CRC |invalid ----------------------------------------------------------------------------------------------------------------------------------------------- [Telegram] - Sync. Byte |55 |55 - Header |00 07 07 01| - Data Length |00 07 |7 byte - Optional Length |07 |7 byte - Packet Type |01 |RADIO_ERP1 (Radio telegram) - CRC8H |7A |valid - Data |F6 30 FE ..| - R-ORG |F6 |RPS telegram (0xF6) - Data_DL |30 | - Originator-ID |FE F9 59 1B|FE F9 59 1B - Status |30 |Original sender, 0 - Optional Data |00 FF FF ..| - SubTelNum |00 |0 - Destination ID |FF FF FF FF|FF FF FF FF - dBm |37 |-55 dBm - SecurityLevel |00 |0 - CRC8D |6F |valid =============================================================================================================================================== [Summary] - HEX |55 00 07 07 01 7A F6 00 FE F9 59 1B 20 00 FF FF FF FF 36 00 CC - Packet Type |RADIO_ERP1 (Radio telegram) - Device Name |Unknown - Device ID |0000FEF9591B - Manufacturer |Unknown - EEP |Unknown - RORG |Unknown - FUNC |Unknown - TYPE |Unknown - Data |Unknown - Learn |Unknown - Known |false - RSSI |-54 dBm - CRC |invalid ----------------------------------------------------------------------------------------------------------------------------------------------- [Telegram] - Sync. Byte |55 |55 - Header |00 07 07 01| - Data Length |00 07 |7 byte - Optional Length |07 |7 byte - Packet Type |01 |RADIO_ERP1 (Radio telegram) - CRC8H |7A |valid - Data |F6 00 FE ..| - R-ORG |F6 |RPS telegram (0xF6) - Data_DL |00 | - Originator-ID |FE F9 59 1B|FE F9 59 1B - Status |20 |Original sender, 0 - Optional Data |00 FF FF ..| - SubTelNum |00 |0 - Destination ID |FF FF FF FF|FF FF FF FF - dBm |36 |-54 dBm - SecurityLevel |00 |0 - CRC8D
Dieser Monitor kann bei der Fehlersuche im Bereich EnOcean sehr hilfreich sein, wenn man ihn auf einem zweiten Raspberry installiert und so alle EnOcean Telegramme abhört. Die bereits durchgeführte Dekodierung macht es einem zusätzlich leicht die Daten mit den EnOcean Spezifikationen für das entsprechende EPP abzugleichen.
FHEM als MQTT – EnOcean Gateway
Da ich aus der Vergangenheit bereits einige Erfahrungen mit FHEM gesammelt habe, habe ich es als ersten Testkandidaten für mein MQTT – EnOcean Gateway genommen.
Als Basis habe ich ein Raspian Image auf Buster genommen und natürlich erstmal alles aktualisiert. Wichtig ist beim Einsatz eines EnOceanPi, dass die serielle Schnittstelle vorher freigeräumt wird. Details hierzu im folgenden post.
pi@fhempi:~ $ uname -a Linux fhempi 4.19.97-v7l+ #1294 SMP Thu Jan 30 13:21:14 GMT 2020 armv7l GNU/Linux pi@fhempi:~ $ more /etc/debian_version 10.4
Bei der FHEM Installation habe ich mich am fhem Wiki bzw. hier orientiert.
pi@fhempi:/etc $ sudo wget -qO - http://debian.fhem.de/archive.key | sudo apt-key add - OK pi@fhempi:/etc $ echo "deb http://debian.fhem.de/nightly/ /" | sudo tee -a /etc/apt/sources.list deb http://debian.fhem.de/nightly/ / pi@fhempi:/etc $ more /etc/apt/sources.list deb http://raspbian.raspberrypi.org/raspbian/ buster main contrib non-free rpi # Uncomment line below then 'apt-get update' to enable 'apt-get source' #deb-src http://raspbian.raspberrypi.org/raspbian/ buster main contrib non-free rpi deb http://debian.fhem.de/nightly/ / pi@fhempi:/etc $ sudo apt update Hit:1 http://raspbian.raspberrypi.org/raspbian buster InRelease Hit:2 http://archive.raspberrypi.org/debian buster InRelease Get:3 http://debian.fhem.de/nightly InRelease [1912 B] Get:4 http://debian.fhem.de/nightly Packages [1187 B] Fetched 3099 B in 1s (2954 B/s) Reading package lists... Done Building dependency tree Reading state information... Done All packages are up to date. pi@fhempi:/etc $ sudo apt-get install fhem <....>
Dann der erste Blick auf das Web-Interface mit http://192.168.0.31:8083/fhem und hier erstmal in das Log schauen.
2020.05.15 11:57:49 1: Including fhem.cfg 2020.05.15 11:57:49 3: WEB: port 8083 opened 2020.05.15 11:57:49 2: eventTypes: loaded 2 events from ./log/eventTypes.txt 2020.05.15 11:57:49 3: Opening TCM_ESP3_0 device /dev/ttyUSB0 2020.05.15 11:57:49 3: Setting TCM_ESP3_0 serial parameters to 57600,8,N,1 2020.05.15 11:57:49 3: TCM_ESP3_0 device opened 2020.05.15 11:57:49 1: Including ./log/fhem.save 2020.05.15 11:57:49 1: Messages collected while initializing FHEM:SecurityCheck: WEB is not password protected Protect this FHEM installation by defining an allowed device with define allowed allowed You can disable this message with attr global motd none 2020.05.15 11:57:49 3: TCM TCM_ESP3_0 set reset 2020.05.15 11:57:50 2: TCM TCM_ESP3_0 RESPONSE: OK 2020.05.15 11:57:50 2: TCM TCM_ESP3_0 Attribute sendInterval 0 initialized 2020.05.15 11:57:50 3: TCM TCM_ESP3_0 get baseID 2020.05.15 11:57:50 2: TCM TCM_ESP3_0 RESPONSE: BaseID: FFB07280 RemainingWriteCycles: 0A 2020.05.15 11:57:50 3: TCM TCM_ESP3_0 get version 2020.05.15 11:57:50 2: TCM TCM_ESP3_0 RESPONSE: APIVersion: 02060300 APPVersion: 020B0100 ChipID: 01A160E5 ChipVersion: 454F0103 Desc: GATEWAYCTRL 2020.05.15 11:57:50 3: TCM TCM_ESP3_0 set mode 00 2020.05.15 11:57:50 2: TCM TCM_ESP3_0 RESPONSE: NOT_SUPPORTED 2020.05.15 11:57:50 3: TCM TCM_ESP3_0 set smartAckMailboxMax 0 2020.05.15 11:57:50 2: TCM TCM_ESP3_0 RESPONSE: OK 2020.05.15 11:57:50 2: TCM TCM_ESP3_0 smartAckMailboxMax 0 initialized 2020.05.15 11:57:50 3: TCM TCM_ESP3_0 set maturity 01 2020.05.15 11:57:50 2: TCM TCM_ESP3_0 RESPONSE: OK 2020.05.15 11:57:50 2: TCM TCM_ESP3_0 maturity 01 initialized 2020.05.15 11:57:50 3: TCM TCM_ESP3_0 set repeater 0000 2020.05.15 11:57:50 2: TCM TCM_ESP3_0 RESPONSE: OK 2020.05.15 11:57:50 2: TCM TCM_ESP3_0 repeater 0000 initialized 2020.05.15 11:57:50 2: TCM TCM_ESP3_0 initialized 2020.05.15 11:57:50 1: usb create starting 2020.05.15 11:57:50 3: Probing ZWDongle device /dev/serial1 2020.05.15 11:57:51 3: Probing CUL device /dev/ttyS0 2020.05.15 11:57:51 1: usb create end 2020.05.15 11:57:51 0: Featurelevel: 6 2020.05.15 11:57:51 0: Server started with 7 defined entities (fhem.pl:21940/2020-05-14 perl:5.028001 os:linux user:fhem pid:490)
Der EnoceanPi wurde als TCM_ESP3_0 erkannt, soweit also alles gut. Jetzt nochmal schnell einen update des FHEM über den Befehl „update“ in der Web-Kommandozeile. Ich habe mir angewöhnt, den FHEM Service n ach einem Update immer über die Konsole neu zu starten.
sudo systemctl restart fhem.service
Einlernen von EnOcean Device NodOn MicroSmartPlug
Als Testobject für die Anbindung habe ich mich für einen Switching Actor entschieden. Ich habe seit längerem einen NodOn MicroSmartPlug rumliegen, der nie richtig mit meinem Weinzierl EnOcean Gateway funktioniert hat. Dann muss man halt selbst ran.
Zum einlernen muss der TCM_ESP3_0 erstmal in den Lernmodus gesetzt werden. Dazu muss in der Web-Kommandozeile „set TCM_ESP3_0 teach 600“ eingegeben werden. Auf dem NodOn Switch muss der Taster drei Sekunden gedrückt werden, damit der Teach-in Vorgang gestartet wird.
Im Log ist dann folgendes zu sehen.
2020.05.15 12:07:12 3: TCM TCM_ESP3_0 set teach 600 2020.05.15 12:07:23 1: EnOcean Unknown device with SenderID 0582F709 and UTE telegram, please define it. 2020.05.15 12:07:23 2: autocreate: define EnO_0582F709 EnOcean 0582F709 EnOcean:1:D4:A00146000E01D2:0582F709:00:02FFFFFFFF3C00 2020.05.15 12:07:23 2: EnOcean define EnO_0582F709 EnOcean 0582F709 EnOcean:1:D4:A00146000E01D2:0582F709:00:02FFFFFFFF3C00 2020.05.15 12:07:23 2: EnOcean define FileLog_EnO_0582F709 FileLog ./log/EnO_0582F709-%Y.log EnO_0582F709 2020.05.15 12:07:23 2: EnOcean define SVG_EnO_0582F709 SVG FileLog_EnO_0582F709:EnO_power4energy4:CURRENT 2020.05.15 12:07:23 2: EnOcean EnO_0582F709 UTE teach-in response send to 0582F709 2020.05.15 12:07:23 2: EnOcean EnO_0582F709 UTE teach-in accepted EEP D2-01-0E Manufacturer: ID-RF
Im Log sieht man sehr gut, dass der Anlernvorgang funktioniert hat und automatisch (autocreate) ein Gerät in der FHEM Konfiguration erstellt wurde. Hier ist jetzt zu prüfen, ob die korrekte EnOcean Adresse: 0582F709 und die korrekte EEP Nummer D2-01-0e angelernt wurden. Insbesondere die EEP Nummer sollte mit der vom EnOcean Hersteller genannten Nummer identisch sein. Ansonsten kann es sein, dass nichts funktioniert weil die EnOcean Telegramme ein anderes Formt haben. Nun gibt es auch im FHEM Hauptmenü einen EnOcean Menüeintrag. Darunter wird dann auch das Gerät angezeigt und über on/off kann es bereits geschaltet werden.
Konfiguration MQTT
Also auf der EnOcean Seite sind wir erstmal fertig. Nun muss noch ein MQTT Interface definiert werden, über das die MQTT Nachrichten empfangen werden. Da ich bereits einen zentralen MQTT Broker auf einem anderen Server haben, muss ich nur den MQTT Client auf dem FHEM installieren.
Ich habe mich, um mich in die FHEM spezifischen Konfigurationen einzuarbeiten, erstmal mit den Inhalten dieser Seite vertraut gemacht. Da ich ja in meinem Netz bereits einen MQTT Broker habe, geht es jetzt nur darum einen MQTT Client für FHEM zu konfigurieren.
Dazu sind im ersten Schritt zwei Konfigurationen notwendig. I/O Device MQTT2_CLIENT anlegen.
- I/O Device MQTT2_Client erstellen
- Client Module MQTT_Generic_Bridge erstellen.
Zur Erstellung des I/O Devices muss in /opt/fhem/fhem.cfg nur die folgende Zeile hinzugefügt werden.
define fhemmqtt MQTT2_CLIENT 192.168.0.2:1883
<fhemmqtt> ist der Name des Brokers und kann frei gewählt werden. Achtung: Ich hatte Probleme als der Name auf myBroker konfiguriert war. Es gab dann immer einen Disconnect und Reconnect zum zentralen MQTT Broker alle 3 Sekunden. Die IP Adresse des externen Brokers und die Port Adresse sind natürlich entsprechend anzupassen.
Als nächstes wird dann noch ein Client Module geladen, welches dann die Kommunikation zwischen dem EnOcean Device und dem MQTT2_Client herstellt. Hierzu ebenfalls die folgende Zeile in /opt/fhem/fhem.cfg hinzufügen.
define mqttGeneric MQTT_GENERIC_BRIDGE attr mqttGeneric IODev fhemmqtt
Wichtig ist hier natürlich, dass das Attribut mqttGeneric IODev auf den Namen des MQTT2_Clients (hier ist es fhemmqtt) zeigt.
Konfiguration EnOcean Device für MQTT
Damit das EnOcean Device auch auf die eingehenden MQTT Nachrichten reagiert und ggf. auch Nachrichten an den MQTT Broker schicken kann, müssen diese Geräte über ein Attribut konfiguriert werden. In der bekannten Logik von MQTT bedeutet es, dass für Subscribe und Publish der entsprechende Topic konfiguriert werden muss.
Die Config des EnOcean Devices wird dazu einfach um zwei attr Einträge (mqttPublish und mqttSubscribe) ergänzt.
define EnO_0582F709 EnOcean 0582F709 setuuid EnO_0582F709 5ebe77eb-f33f-e7fc-3e37-a22d849d752b2030 attr EnO_0582F709 IODev TCM_ESP3_0 attr EnO_0582F709 comMode biDir attr EnO_0582F709 defaultChannel 0 attr EnO_0582F709 devChannel 1 attr EnO_0582F709 eep D2-01-0E attr EnO_0582F709 manufID 046 attr EnO_0582F709 mqttPublish channel0:topic=fhem/smartswitch/status attr EnO_0582F709 mqttSubscribe set dim:stopic=fhem/smartswitch/setdim attr EnO_0582F709 room EnOcean attr EnO_0582F709 subDef FFB07281 attr EnO_0582F709 subType actuator.01 attr EnO_0582F709 teachMethod UTE
Nun sollte das EnOcean Device auf MQTT Befehle hören. Das ganze lässt sich gut mit einem MQTT Client wie z.B. MQTTExplorer für MacOS, Windows etc. oder mit MQTTfx simulieren und prüfen.
Sollte etwas nicht funktionieren, dann wäre der erste Schritt das Logging auf FHEM bzgl. der Module hochzudrehen. Dies geschieht über ein Attribut verbose mit dem entsprechenden Log-Level. Details sind hier.
define fhemmqtt MQTT2_CLIENT 192.168.0.2:1883 attr fhemmqtt verbose 4 define mqttGeneric MQTT_GENERIC_BRIDGE attr mqttGeneric IODev fhemmqtt attr mqttGeneric verbose 4
Dann noch den folgenden Befehlt und die verschiedenen Aktionen können nachverfolgt werden. Hier das Ausschalten des Switches.
2020.05.17 12:15:14 5: fhemmqtt: received PUBLISH (0)(23)fhem/smartswitch/setdim0 2020.05.17 12:15:14 5: fhemmqtt: dispatch autocreate=no\000fhemmqtt\000fhem/smartswitch/setdim\0000 2020.05.17 12:15:14 5: MQTT_GENERIC_BRIDGE: [mqttGeneric] Parse (MQTT2_CLIENT : 'fhemmqtt'): Msg: fhem/smartswitch/setdim => 0 2020.05.17 12:15:14 3: EnOcean set EnO_0582F709 off 2020.05.17 12:15:14 5: MQTT_GENERIC_BRIDGE:DEBUG:> [mqttGeneric] publish: fhem/smartswitch/status => off (qos: 0, retain: 0) 2020.05.17 12:15:14 5: fhemmqtt: sending PUBLISH 0(28)(0)(23)fhem/smartswitch/statusoff 2020.05.17 12:15:14 5: fhemmqtt: received PUBLISH (0)(23)fhem/smartswitch/statusoff 2020.05.17 12:15:14 5: fhemmqtt: dispatch autocreate=no\000fhemmqtt\000fhem/smartswitch/status\000off 2020.05.17 12:15:14 5: MQTT_GENERIC_BRIDGE: [mqttGeneric] Parse (MQTT2_CLIENT : 'fhemmqtt'): Msg: fhem/smartswitch/status => off
NodOn PIR Motion Sensor
So, das war jetzt erstmal die Testkonfig für das EnOcean/MQTT Gateway mit einem NodOn MicroSmartPlug. Und da ich noch ein weitere Gerät von NodOn, den PIR Motion Sensor habe, geht es auch gleich weiter
Der PIR Motion Sensor ist nicht nur ein EnOcean Bewegungsmelder, sondern er kann auch die Helligkeit in Lux messen. Durch die Bauform ist er zudem sehr mobil und auch das Design finde ich recht ansprechend.
Zum Einlernen des Sensors muss FHEM wieder in den Teach-in Modus gesetzt werden. Danach muss ein kleiner Taster am Sensor kurz betätigt werden, damit selbiger das Teach-in Telegram sendet.
Im Log ist dann folgendes zu sehen:
2020.05.17 19:39:38 3: TCM TCM_ESP3_0 set teach 600 2020.05.17 19:39:46 1: EnOcean Unknown device with SenderID 058AEC49 and 4BS telegram, please define it. 2020.05.17 19:39:46 2: autocreate: define EnO_058AEC49 EnOcean 058AEC49 EnOcean:1:A5:1C184680:058AEC49:00:03FFFFFFFF2D00 2020.05.17 19:39:46 2: EnOcean define EnO_058AEC49 EnOcean 058AEC49 EnOcean:1:A5:1C184680:058AEC49:00:03FFFFFFFF2D00 2020.05.17 19:39:46 2: EnOcean define FileLog_EnO_058AEC49 FileLog ./log/EnO_058AEC49-%Y.log EnO_058AEC49 2020.05.17 19:39:46 2: EnOcean EnO_058AEC49 4BS teach-in accepted EEP A5-07-03 Manufacturer: ID-RF 2020.05.17 19:39:46 2: EnOcean define SVG_EnO_058AEC49 SVG FileLog_EnO_058AEC49:EnO_motion:CURRENT 2020.05.17 19:39:46 2: EnOcean define SVG_EnO_058AEC49_2 SVG FileLog_EnO_058AEC49:EnO_voltage4:CURRENT 2020.05.17 19:40:43 2: AttrTemplates: got 159 entries 2020.05.17 19:42:26 3: EnOcean set EnO_0582F709 off
… und prompt ist das Gerät im fhem.cfg enthalten.
define EnO_058AEC49 EnOcean 058AEC49
setuuid EnO_058AEC49 5ec184f2-f33f-e7fc-2774-452f88b1c224e459
attr EnO_058AEC49 IODev TCM_ESP3_0
attr EnO_058AEC49 eep A5-07-03
attr EnO_058AEC49 manufID 046
attr EnO_058AEC49 room EnOcean
attr EnO_058AEC49 subType occupSensor.03
attr EnO_058AEC49 teachMethod 4BS
define FileLog_EnO_058AEC49 FileLog ./log/EnO_058AEC49-%Y.log EnO_058AEC49
setuuid FileLog_EnO_058AEC49 5ec184f2-f33f-e7fc-78b9-7a67ca07703ecd45
attr FileLog_EnO_058AEC49 logtype EnO_motion:Motion4brightness4:Motion/Brightness,EnO_voltage4:Voltage,text
attr FileLog_EnO_058AEC49 room EnOcean
define SVG_EnO_058AEC49 SVG FileLog_EnO_058AEC49:SVG_EnO_058AEC49:CURRENT
setuuid SVG_EnO_058AEC49 5ec184f2-f33f-e7fc-09fe-d8ba666fb8f4de71
attr SVG_EnO_058AEC49 room Plots
attr SVG_EnO_058AEC49 title "EnO_058AEC49 Min $data{min1}, Max $data{max1}, Last $data{currval1}"
define SVG_EnO_058AEC49_2 SVG FileLog_EnO_058AEC49:SVG_EnO_058AEC49_2:CURRENT
setuuid SVG_EnO_058AEC49_2 5ec184f2-f33f-e7fc-0d1c-6bdebef7e0c07878
attr SVG_EnO_058AEC49_2 room Plots
attr SVG_EnO_058AEC49_2 title "EnO_058AEC49 Min $data{min1}, Max $data{max1}, Last $data{currval1}"
In der GUI kann man jetzt unter dem Gerät die entsprechenden „Readings“ sehen. Readings sind Werte, die ausgelesen werden können. Diese wollen wir auslesen und über MQTT an den Broker schicken. Der wichtigste Wert ist dabei „motion“ und daher versuchen wir diesen als ersten.
Und wenn wir nun der Logik des ersten Gerätes folgen, dann ist die notwendige Ergänzung an der fhem.cfg klar.
attr EnO_058AEC49 mqttPublish motion:topic=fhem/pir/status
Wie man oben im Device View sehen kann, liefert der Sensor in Summe 6 readings, wobei eigentlich nur 5 interessant sind. Um diese Readings jetzt in den MQTT Nachrichten in einem JSON darzustellen, damit z.B. NodeRed das git verarbeiten kann habe ich mir folgende Config gebaut. Hier werden die Readings mit Werten, also brightness und voltage im value ohne Doublequotes im String hinterlegt und bei den Text-Readings gibt es dann um den Value dann Doublequotes.
attr EnO_058AEC49 mqttPublish *:topic={"fhem/$device"} motion|battery|state:expression={toJSON({$name=>$value})} brightness|voltage:expression={"{\"$name\":".$value."}"}
Mein Versuchsaufbau für das MQTT-EnOcean Gateway auf Basis von FHEM ist erstmal abgeschlossen und ich starte jetzt den Alltagstest.