eBus - MQTT2

Vorausgesetzt wird hier ein laufender eBus-Dämon. Dessen Einrichtung wird im Artikel EBUS beschrieben.

eBus mit MQTT2 auswerten

https://forum.fhem.de/index.php/topic,97989.0.html

Für die MQTT Kommunikation des eBus wird für die eigentlichen Geräte MQTT2 DEVICE verwendet, damit wird als IO-Device entweder MQTT2_SERVER oder MQTT2_CLIENT verwendet, NICHT beides gleichzeitig! Bitte auch zu beachten, die alten Module MQTT funktionieren nicht nach der Beschreibung in diesem Artikel. Es geht hier um die komplett überarbeitete Version mit dem Namen MQTT2!

Bei der hier beschriebenen Konfiguration der angelegten Devices muss unbedingt die Reihenfolge eingehalten werden.

Anwendung:

Wer eBus komfortabel in FHEM einbinden will, kann dies nun erstmals mit wenigen Mausklicks realisieren. Erstmalig kommt diese neue Technik der von rudolfkönig implementierten Templates zur Anwendung. Templates sind im Prinzip vorgefertigte Schablonen die durch Anklicken dann selbständig den Device mit den darin enthaltenen Vorgaben konfigurieren. Beta-User hat diese Technik dann soweit für den eBus angepasst ( unter anderem die Filter erstellt ) , das sie allen eBus Anwendern zur Verfügung steht. Es kann nun jeder selbst Templates erstellen oder einfach die von mir erstellten vorhandenen Beispiele benutzen. In wenigen Minuten sollte die komplette FHEM Konfiguration dann abgeschlossen sein.

Wer bereits einen Mosquitto Broker installiert hat, kann diesen weiter verwenden, ist aber für die Komunikation mit dem eBus Dämon nicht mehr notwendig!

Uebersicht eBus MQTT

Welches FHEM Modul benötigt man

Nicht MQTT2_SERVER und Mosquitto gleichzeitig laufen lassen, es kann zu verschiedenen Problemen kommen wie gegenseitiges Löschen von Einträgen in FHEM.

Beispiel: Mosquitto Broker ist vorhanden dann benötigt man MQTT2_DEVICE und MQTT2_CLIENT

Beispiel: Mosquitto Broker ist NICHT vorhanden dann benötigt man MQTT2_DEVICE und MQTT2_SERVER

Vorbereitung und Definition am eBus

In der Konfiguration des Dämons ( /etc/default/ebusd ) sollten diese Parameter hinzugefügt werden. Die Topic „ebusd/%circuit/%name“ bitte nicht abändern, da verschiedene Filter auf diesen Ausdruck eingestellt sind.

--accesslevel=* --mqttport=1883 --mqttjson --mqtthost=IpAdresseMQTTSERVER --mqtttopic=ebusd/%circuit/%name

Der MQTTSERVER kann wahlweise der Mosquitto Broker sein, oder der MQTT2_SERVER. Beides wird vermutlich am Raspberry der FHEM Hauptinstanz sein, also die IP-Adresse des Raspberry einsetzen.

Nachfolgend wird davon ausgegangen, dass als Vorgabe für mqtttopic ebusd verwendet wurde. Dies kann geändert werden, es wird aber dringend empfohlen, das mqtttopic in jedem Fall mit ebus... zu beginnen!

Vorbereitung und Definition in FHEM

Unabhängig von dem konkret genutzten IO-Modul (MQTT2_SERVER oder MQTT2_CLIENT) sollte an diesem vor den nachfolgenden Schritten zunächst das autocreate ausgeschaltet werden. Weiter sollte geprüft werden, ob es bereits MQTT2_DEVICE-Geräte gibt, die Einträge in der readingList enthalten, die vom ebus stammen. Da wir die readingList anschließend mit erweiterten JSON-Optionen erstellen wollen, müssen entweder diese Geräte nach dem Deaktivieren des autocreate am IO gelöscht, oder zumindest die readingList entsprechend bereinigt oder gelöscht werden.

Externer Broker

Wer bereits den Mosquitto installiert hat und diesen weiter verwenden möchte, dann diese Konfiguration wählen.

### 1a. Broker in FHEM anlegen ###
define MQTT_via_mosquitto MQTT2_CLIENT 127.0.0.1:1883
attr MQTT_via_mosquitto room MQTT2_DEVICE,System

FHEM-Interner Server

Wer keinen Mosquitto installiert hat kann diese Konfiguration wählen. Dazu wird einfach der MQTT2-SERVER definiert.

### 1b. oder MQTT Server  anlegen ###
define ebusMQTT MQTT2_SERVER 1883 global
attr ebusMQTT room MQTT2_SERVER

"ebus-Bridge"

Nun wird noch ein Device benötigt, welcher mit einem der oben genannten Module kommuniziert und das Filter (bridgeRegexp) für den eBus beinhaltet. Auf Basis dieses Device werden später alle ankommenden JSON Telegramme vom eBus Dämon automatisch als Reading angelegt.

### 2. MQTT_Device definieren
define MQTT2_ebusd MQTT2_DEVICE ebusd
attr MQTT2_ebusd IODev ebusMQTT
attr MQTT2_ebusd room MQTT2_DEVICE

Es kann auch ein ggf. vom MQTT2_SERVER bereits automatisch angelegtes Device genutzt werden, bei Verwendung von MQTT2_CLIENT sollte das Device wie oben dargestellt manuell erstellt werden; es ist dabei darauf zu achten, dass die CID dem Basispfad des Topic-trees entspricht, der bei der Konfiguration des ebus-Dämons verwendet wurde.

Auf das Device MQTT2_ebusd wird nun folgendes Template angwendet:

Template E_00_eBus_daemon_splitter

Eingabe im Splitter aendern

Gibt es noch keine readingList mit ebus-spezifischen Einträgen, erscheint ein Fenster. In diesem kann der Name ausgewählt werden, gebt hier anstatt DEV_ID „ebus“ ein und drückt „ok“

Zur Kontrolle bitte prüfen ob hier auch die „bridgeRegexp“ vom Template richtig gesetzt wurde.

bridgeRegexp prüfen

(ebus..*?)/(bai|\d+|cc|e7f|ehp|f\d\d|hc|he.|hmu|hwc|mc|mc.\d|omu|omu.\d|pms|rcc|rcc.\d|sc|sdr_p|ui|uih|v\d\d|v81.\d|vd\d|vl\d|vr_\d\d|zeo)/.*:.* "$1_$2"
(ebus..*?)/(global|broadcast|general|scan([^/]*))/.*:.* "$1"

Nach der Konfiguration des bridge-Devices muß autocreate am IO-Device wieder aktiviert werden. Da hierbei die vom ebus-Dämon gesendeten JSON-Informationen in vielen Installationen nur sinnvoll genutzt werden können, wenn die Statusmeldungen jeweils getrennt dargestellt werden, setzen wir auf dem MQTT2_SERVER oder dem MQTT2_CLIENT ( je nachdem welcher verwendet wurde) das Attribut „autocreate“ auf „complex“.

autocreate auf complex setzen

Complex hat den Sinn, das JSONMAP mit dem Namen des Readings automatisch gesetzt wird. Statt dem Reading 0_value wird daraus dann ein Stautus01_0_value. Dies ist gerade bei den Statusmeldungen wichtig, da sie sich sonst mit gleichem Readingnamen gegenseitig überschreiben.

Nun heißt es etwas zurück lehnen und warten bis die MQTT Telegramme vom eBus eingetroffen sind, das kann einige Minuten dauern. Dabei wird in der Regel sowohl die readingList am Device MQTT2_ebusd erweitert, wie auch ein oder mehrere neue MQTT2_DEVICE-Geräte angelegt.

Das attrTemplate läd eine weitere attrTemplate-file und 99_myUtils-Code vom FHEM-Server nach. Beides steht dann auch unmittelbar zur Nutzung zur Verfügung. Es ist daher seit 01/2020 nicht mehr erforderlich, selbst myUtils-Code anzulegen wie die nachfolgend dargestellt!

myUtils-Code

Nun benötigen wir noch etwas Code für die Balkendarstellung in FHEM. Dieser Code wird in die 99_myUtils.pm kopiert.

 sub Balkenanzeige($) 
 {
    # Zuweisung der übergebenen Variablen
    my ($val) = @_;
    # Konfiguration des maximal übergebenen Werts (hier wäre der höchste zu erwartende Wert = 3)
    my $maxValue = 70;
    # Normalisierung auf 100%-Wert
    my $percent = $val / $maxValue * 100;
    # Definition des valueStyles
    my $stylestring = 'style="'.
        'width: 200px; '.
	'text-align:center; '.
	'border: 1px solid #ccc ;'. 
	'background-image: -webkit-linear-gradient(left,red '.$percent.'%, rgba(0,0,0,0) '.$percent.'%); '.
	'background-image:    -moz-linear-gradient(left,blue '.$percent.'%, rgba(0,0,0,0) '.$percent.'%); '. 
	'background-image:     -ms-linear-gradient(left,red '.$percent.'%, rgba(0,0,0,0) '.$percent.'%); '. 
	'background-image:      -o-linear-gradient(left,red '.$percent.'%, rgba(0,0,0,0) '.$percent.'%); '. 
	'background-image:         linear-gradient(left,red '.$percent.'%, rgba(0,0,0,0) '.$percent.'%);"';
    # Rückgabe des definierten Strings
    return $stylestring;
 }

Ebenfalls muss noch das Modul Color.pm ordnungsgemäß eingebunden werden. Dieses Modul wird zur farbigen Darstellung wie es in den Templates verwendet wird benötigt.

define colorInit notify global:INITIALIZED {use Color}

Regelmäßige Werteabfrage

Es kann aber in der Zwischenzeit noch die Timer gesteuerte Abfrage definiert werden.

defmod get_ebus_updates at +*00:15:00 set ebusMQTT publish ebusd/430/Hc1HeatCurve/get;
set ebusMQTT publish ebusd/430/HwcTempDesired/get;
set ebusMQTT publish ebusd/bai/WaterPressure/get;
set ebusMQTT publish ebusd/bai/FlowTemp/get;
set ebusMQTT publish ebusd/bai/ReturnTemp/get;
set ebusMQTT publish ebusd/bai/FanSpeed/get;
set ebusMQTT publish ebusd/bai/WPPWMPower/get;
set ebusMQTT publish ebusd/bai/OutdoorstempSensor/get;
set ebusMQTT publish ebusd/bai/Status02/get
set ebusMQTT publish ebusd/bai/FanHours/get
set ebusMQTT publish ebusd/bai/HcHours/get
set ebusMQTT publish ebusd/bai/HwcHours/get
set ebusMQTT publish ebusd/bai/HwcStarts/get

Diese „get“ sind nur Beispiele, wer weitere Readings abfragen möchte einfach die Liste in der FHEM Eingabe erweitern. Ebenfalls kann der Timer auf persönliche Bedürfnisse angepasst werden.

ebus-Spezifische weitere Templates

Installation

Das Basis-attrTemplate für ebus läd eine weitere attrTemplate-file und 99_myUtils-Code vom FHEM-Server nach. Beides steht dann auch unmittelbar zur Nutzung zur Verfügung. Es ist daher seit 01/2020 nicht mehr erforderlich, die Datei selbst aus dem Forum nachzuladen wie die nachfolgend noch dargestellt!

Um die eBus Templates benutzen zu können, müssen sie erst im Verzeichnis „/opt/fhem/FHEM/lib/AttrTemplate“ installiert werden. Hier kann das Mustertemplate „mqtt2.ebus.template“ herunter geladen werden. Dieses Template dann in das Verzeichnis kopieren. Vor der erstmaligen Benutzung muss dieses template noch Initialisiert werden, sonst wird es in der Templateliste nicht angezeigt.

Bitte das Template immer aus dem richtigen Device (zB: MQTT2_ebusd_430 für die Heizkurve) installieren, ansonsten wird das Reading des Device nicht gefunden bzw. falsch zugeordnet.

vor der ersten Benutzung in der Eingabezeile eingeben

Dazu in der FHEM Eingabezeile eingeben:

{ AttrTemplate_Initialize() }

Anwendung der Templates

Wenn bereits die ersten Messwerte eingetroffen sind und die Devices mit den Readings angelegt wurden, können die Templates angelegt werden. D.h. in der Templateliste das gewünschte auswählen (hier MQTT2_ebusd_bai). Die eBus Templates beginnen alle mit E….

Das gewünschte Template auswählen, die Readings müssen allerdings in diesem Device enthalten sein

Hier wird E_07_eBus_bai_Status01+Status02_HWC gewählt.

Das Template hat die gewünschte Konfiguration in FHEM durchgeführt

Ergebnis des Template, Heizkurve und Warmwassertemperatur

Hier das Ergebnis von HC1HeatCurve+HWCTempDesired

Muster Templates

Es sind auch noch einige Mustertemplates vorhanden die auf Basis von readingsGroup erstellt wurden und ein farbiges Design besitzen. Diese Templates werden nicht im Device, sondern im Room „eBus“ angelegt. Der Kreativität der Anwender sind hier fast keine Grenzen gesetzt, die Werkzeuge sind vorhanden.

Achtung: die hier gewählte Nummerierung kann sich im Laufe der Zeit ändern, da die Templates öfters erweitert/geändert werden.

Template: E_05_eBus_bai_readingsgroup_Set_Hcurve_Hotwater

Set hcurve und HWCtemdesired

Template: E_01_eBus_bai_readingsgroup_Status01

Statusmeldung als Readingsgroup

Template: E_02_eBus_bai_readingsgroup_Status01_Balken

EStatusmeldung als Readingsgroup mit Balkenanzeige

Template: E_03_eBus_bai_readingsgroup_Status02

Statusmeldung als Readingsgroup

Template: E_04_eBus_bai_readingsgroup_Status02_Balken

Statusmeldung als Readingsgroup mit Balkenanzeige

Template: hier noch einige Beispiel Templates die mit devStateIcon erzeugt wurden.

Templates auf Basis devStateIcon

Templates erweitern

Die Templates können vom User selbst leicht erweitert werden. Dies kann entweder im fertigen "define/defmod" oder aber auch im Template vorgenommen werden.

Als Beispiel erweitern wir hier die readingsgroup "eBusset" um die Temperatur zur Nachtabsenkung.

<>,<Name>,< Ist>,<      Soll>
MQTT2_ebusd_430:<%message_tendency_steady>,<Heizkurve>,Hc1HeatCurve_curve_value,<sollcurve>
MQTT2_ebusd_430:<%sani_water_hot>,<Warmwasser>,HwcTempDesired_temp1_value,<sollwater>
MQTT2_ebusd_430:<%temp_temperature_min>,<Nachtabsenkung>,Hc1NightTemp_temp1_value,<sollnight>

Dazu erweitern wir als erstes hier die letzte Zeile der Definition

{'eBusSet.sollcurve'=>'Hc1HeatCurve_curve_value:uzsuDropDown,0.20,0.70,0.90,1.00,1.10,1.20,1.30,1.40,1.50,1.60,1.70',
'eBusSet.sollwater'=>'HwcTempDesired_temp1_value:uzsuDropDown,50.0,51.0,52.0,53.0,54.0,55.0,56.0,57.0,58.0,59.0,60.0',
'eBusSet.sollnight'=>'Hc1NightTemp_temp1_value:uzsuDropDown,10.0,11.0,12.0,13.0,14.0,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0'}

dann die Sollwertvorgabe um die Hc1NightTemp_temp1_value mit den Vorgaben

{'Hc1HeatCurve_curve_value' => '{"style=\"color:\x23".substr(Color::pahColor(5,10,15,$VALUE*10,0),0,6)."\""}', 
'HwcTempDesired_temp1_value' => '{"style=\"color:\x23".substr(Color::pahColor(20,40,60,$VALUE,0),0,6)."\""}',
'Hc1NightTemp_temp1_value' => '{"style=\"color:\x23".substr(Color::pahColor(10,15,20,$VALUE,0),0,6)."\""}'}

und schließlich wird noch die dynamische Farbgebung des Sollwertes angepasst.

set ebusMQTT publish ebusd/430/Hc1NightTemp/get;

damit auch der Messwert abgefragt wird, muss noch ein Eintrag im EBUS.TIMER dazu gehängt werden.

Nachtabsenkung Sollwert über readingsgroup

Nach Erweiterung der 3 Zeilen sieht das dann so aus.

Weiterführende Links

Diskussionsthread aus dem Forum: