EBUS-MQTT2
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,91394.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!
Welches FHEM Modul benötigt man
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.
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:
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.
(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“.
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.
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.
+*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
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.
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….
Hier wird E_07_eBus_bai_Status01+Status02_HWC gewählt.
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
Template: E_01_eBus_bai_readingsgroup_Status01
Template: E_02_eBus_bai_readingsgroup_Status01_Balken
Template: E_03_eBus_bai_readingsgroup_Status02
Template: E_04_eBus_bai_readingsgroup_Status02_Balken
Template: hier noch einige Beispiel Templates die mit devStateIcon erzeugt wurden.
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.
Nach Erweiterung der 3 Zeilen sieht das dann so aus.
Weiterführende Links
Diskussionsthread aus dem Forum: