eBus Schaltung V2 in Betrieb nehmen

[Reinhart]

ja genau

Code Auswählen Erweitern

define EBUS1 ECMD telnet '''ip-raspi-ebusd''':8888   # IP Adresse ebusd einsetzen!!!
attr EBUS1 classdefs bai00.class=/opt/fhem/FHEM/bai00.cfg
attr EBUS1 icon usb
attr EBUS1 requestSeparator 000
attr EBUS1 room Vaillant

define EBUS2 ECMD telnet '''ip-raspi-ebusd''':8889   # IP Adresse ebusd einsetzen!!!
attr EBUS2 classdefs bai00.class=/opt/fhem/FHEM/bai00.cfg
attr EBUS2 icon usb
attr EBUS2 requestSeparator 000
attr EBUS2 room Vaillant


LG

[theotherhalf]

Ja, das hatte ich auch schon so geändert.
Ich meine vielmehr beim Absetzen von händischen Abfragen. Da muss der Port doch auch angegeben sein. Wie wird der da hinein gesetzt?

[Reinhart]

Ja, das hatte ich auch schon so geändert.
Ich meine vielmehr beim Absetzen von händischen Abfragen. Da muss der Port doch auch angegeben sein. Wie wird der da hinein gesetzt?

-p 8889

LG

[theotherhalf]

OK, verstanden.

Beim Absetzen der Abfrage erhalte ich den Wasserdruck des Systems angezeigt:

Code Auswählen Erweitern

pi@raspberrypi:~ $ ebusctl -p 8889 r -f WaterPressure press
1.373

Setze ich dies dann in die .cfg Datei, wird aber ausgegeben "Command not found"

Code Auswählen Erweitern

# Wasserdruck Therme
get Wasserdruck_Therme cmd {"-p 8889 r -f WaterPressure press\n"}
get Wasserdruck_Therme expect ".*\n"
get Wasserdruck_Therme postproc { $_ }

Hat das etwas mit der Portierung zu tun?

[Reinhart]

in die cfg Datei kannst du das nicht so setzen (außerdem ist die Stelle falsch), das habe ich dir weiter oben schon gepostet wie das geht.
Du definierst da 2 unterschiedliche ECMD Devices und je nachdem welches du abfragen willst ist ja ein anderes Port zugeordnet.
Mach es aber mit 2 unterschiedlichen bai.xx.cfg Files das nichts durcheinander kommt. Ich habe das von 2 unterschiedlichen Quellen auch noch nicht gemacht ( umgekehrt schon ) , sollte aber so funktionieren.

Code Auswählen Erweitern

define EBUS1 ECMD telnet '''ip-raspi-ebusd''':8888   # IP Adresse ebusd einsetzen!!!
attr EBUS1 classdefs bai01.class=/opt/fhem/FHEM/bai01.cfg
attr EBUS1 icon usb
attr EBUS1 requestSeparator 000
attr EBUS1 room Vaillant

define EBUS2 ECMD telnet '''ip-raspi-ebusd''':8889   # IP Adresse ebusd einsetzen!!!
attr EBUS2 classdefs bai02.class=/opt/fhem/FHEM/bai02.cfg
attr EBUS2 icon usb
attr EBUS2 requestSeparator 000
attr EBUS2 room Vaillant

Du kannst aber auch alles mit GAEBUS durchführen, aber auch hier musst du 2 unterschiedliche Ports definieren. Ich glaube das wäre für deine Zwecke der bessere und übersichtlichere Weg.

Aber generell gesagt, du brauchst in FHEM nur "Commandref" drücken und nach ECMD suchen und schon hast du eine genaue Beschreibung zur richtigen Syntax, da hat sich ja schon jemand Mühe gemacht um das zu erklären.

LG

[theotherhalf]

Mir war es eben auch schon aufgefallen. Durch das -p 8889 ist es ja doppelt beschrieben, da ja FHEM schon weiss wo es sich den Wert holen soll.
Habe in FHEM 2 EBUS Stränge angelegt und arbeite erst einmal mit einer .cfg Datei. Das scheint zu klappen, denn der Wasserdruck kommt jetzt durch
Danke für deine Hilfe!

[Reinhart]

MQTT verschiedene Möglichkeiten zur Visualisierung der eBus Datensätze.

(alte Methode mit MQTT, bitte nicht mehr verwenden)

MQTT und Mosquitto Server
diese Möglichkeit ist hier beschrieben. 
MQTT Teil1   
MQTT Teil2  

(neue Methode mit MQTT2, bitte diese verwenden)
MQTT2 Teil3 Realisierung mit MQTT2_Client mit oder ohne Mosquitto
                             
Wiki MQTT2 Konfiguration von MQTT2_Device
MQTT2_Wiki Praxisbeispiele eBus
MQTT2_Client Commandref


Achtung: MQTT muss auch in in der eBus Config konfiguriert werden.

Code Auswählen Erweitern

--accesslevel=* --mqttport=1883 --mqttjson --mqtthost=10.0.0.5 --mqtttopic=ebusd/%circuit/%name
Dazu sollten mindestens diese Punkte definiert werden (IP-Adresse natürlich von eurem Fhem Server/Broker einsetzen, nicht vom eBusd!). Der Name "ebusd" in der Topic sollte so eingehalten, wenn die hier nachfolgenden Beispiele und die Templates benutzt werden.

Unabhängig vom eBus wurde ja hier im Forum MQTT2 völlig neu entwickelt (besten Dank an die Entwickler) und bietet auch für den Einsatz des eBus komfortable Möglichkeiten. Nachdem John30 einen kleinen Fix eingechekt hat sind die MQTT2 Entwicklungen nun auch für den eBus voll nutzbar.


Schritt 1 Vorbereitung


Dies ist die Vorarbversion einer Beschreibung und wurde im Wiki komplett neu aufbereitet, bitte diese benutzen!

Die Entwickler vom MQTT2 haben hier völlig neuartige Methoden entwickelt um die Konfiguration der Devices sehr komfortabel zu gestalten. Dazu wurden "templates" eingeführt, welche man einfach, nachdem der Device automatisch angelegt wurde, auswählt und schon wird die dafür hinterlegte Konfiguration des Devices hinzugefügt.
Beqeumer kann man das eigentlich nicht durchführen. Selbst wenn das Template nicht zu 100% passt, kann man es anwenden und nachher noch auf die persönlichen Bedürfnisse etwas anpassen (Zentrierung, Ausrichtung, Sytle etc).

Diese Templates liegen am Fhem Raspi unter: /opt/fhem/FHEM/lib/AttrTemplate
Nachfolgende angehängte Templates können einfach mit Copy und Paste als "mqtt2.ebus.template" dort gespeichert werden. Nach der Speicherung oder Änderung einmalig das Template neu einlesen damit es dann in der Auswahlliste zur Verfügung steht.

Code Auswählen Erweitern

{ AttrTemplate_Initialize() }
in der Commando Zeile von Fhem eingeben


Schritt 2 MQTT2 definieren

Definition in Fhem:  define <name> MQTT2_CLIENT <host>:<port>


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

Code Auswählen Erweitern

### 1a. Broker in Fhem anlegen ###
define ebusMQTT MQTT 127.0.0.1:1883
attr ebusMQTT room MQTT2_DEVICE,System

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

Code Auswählen Erweitern

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

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 alle ankommenden JSON Telegramme vom eBus Dämon automatisch als Reading angelegt.

Code Auswählen Erweitern

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


Wer bereits einen Mosquitto Server am Raspi laufen hat, kann diesen ohne Probleme weiter laufen lassen. Wer aber keinen Broker am Laufen hat, der soll den neuen MQTT2_Server benutzen. Nicht beide gleichzeitig laufen lassen, entweder MQTT2-SERVER oder Mosquitto.

Diese Definition wie gewohnt in die Fhem Eingabezeile (Zeile für Zeile) kopieren
Durch das Attribut "autocreate complex" am MQTT2-SERVER werden nun alle Devices automatisch mit einem JSONmap angelegt. Dazu müssen aber einmalig MQTT Telegramme mitgelauscht werden. Der eBus überträgt aber von sich aus außer den Broadcasts und beim Scanvorgang keine Telegramme via MQTT.

Es ist daher erforderlich alle gewünschten Datenpunkte über einen Timer zyklisch abzufragen.


Schritt 3 Timer für zyklische MQTT Abfrage

Hier ein Beispiel eines Timers wie alle 5 Minuten vorausgewählte Datensätze abgeholt werden können.
Die Zyklus Zeit könnt ihr hier ebenfalls nach belieben einstellen.

Code Auswählen Erweitern

define EBUS.TIMER 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/OutdoorstempSensor/get;
set ebusMQTT publish ebusd/bai/Status02/get

Dadurch werden durch das obige Attribut "autocreate" alle vorausgewählten Datenpunkte als Devices automatisch angelegt und zyklisch gepollt.
Dieser Timer wird NICHT automatisch angelegt, sondern muss einmalig in die Kommandozeile von Fhem kopiert werden.
Nachdem der MQTT2_Client auf "autocreate 1" geschaltet wurde, starten wir den EBUS.MQTT Timer mit "execNow" und die Abfragen der konfigurierten Datenpunkte werden gestartet.
Nach einer kurzen Zeit sollten nun die neuen MQTT Devices erstellt worden sein.



Schritt 4 Template anwenden

Da der MQTT2_Client ja nicht weiß um welchen Datentyp es sich handelt, kann dieser mit einem Template blitzschnell konfiguriert werden.
Dazu nehmen wir den automatisch erstellen Device "MQTT2_ebusd_bai". Durch anklicken auf den Namen wird dieser ausgewählt und wir setzen bei "set MQTT2_ebusd_bai attrTemplate" das Template "E_01_eBus_Satus01" auswählen und nachfolgendes drücken von "set".
Bitte nicht vergessen jetzt "Save Config" drücken, diese wird jetzt rot sein weil die Konfiguration erweitert wurde.
Der Device MQTT2_ebusd_bai ist nun automatisch durch das Template konfiguriert worden und zeigt jetzt ein Icon und den Vorlauf, Ruecklauf,  Warmwasser, Aussentemp und den Pumpenstatus rechtsbündig untereinander in der Fhem Gui an.

Wer eine Calormatic oder ähnliches hat kann nun auch beim Device "MQTT2_ebusd_xxx" (xxx steht für den Namen der Calormatic, zB: 430) das Template "E_02_eBus_Hc1HeatCurve" anwählen. Ebenso wie oben wird das Device konfiguriert, ein Icon angezeigt und der Istwert der Heizkurve und daneben ein DropDownMenü zum Verstellen der Heizkurve angezeigt.
Ich glaube wer das jetzt so angewendet hat wird die Vorteile der Templates schnell erkennen. Auch wenn ein Template nicht unbedingt zum Datentyp passt, kann man sich hier schnell ein Muster holen und nach den persönlichen Vorstellungen anpassen.
Ebenso könnt ihr die Templates beliebig erweitern und anderen Usern zur Verfügung stellen.


sonstiges
Wenn ihr noch andere MQTT Devices als den eBus habt (zB: Sonoff) werden auch diese Devices alle automatisch auftauchen.
Auch hier gilt bei jedem Device kann das entsprechende Template zugeordnet werden. Im Augenblick (30.12.2018) sind 28 Templates vorhanden.
Wie man selbst Templates erstellt und wie vorgegangen werden soll ist hier beschrieben.   
Eine weitere Konfiguration für ECMD braucht bei dieser beschriebenen Methode des MQTT2_Clients nicht durchgeführt werden!

Im Anhang noch ein Bild, hier wurden beide eBus Templates angewendet und dadurch automatisch konfiguriert.
Ebenso angehängt das eBus Template als Muster.

Hier geht es zu einer genaueren Beschreibung im Wiki.

edit: 01.04.19 added new template with Timeprog
edit: 02.04.19 corrected template (Timeprog)
edit: 02.04.19 corrected template jsonmap, ValueSuffix

LG
Reinhart

[pc1246]

Moin zusammen
Nun habe ich leider mal ein Problem. Nach einem Netzwerkupdate bei mir zu hause, laeuft der eBus leider nicht mehr.

Code Auswählen Erweitern

version: ebusd 3.0.595c7c0
update check: version 3.3 available, broadcast.csv: newer version available
signal: no signal
reconnects: 2
masters: 1
messages: 11
conditional: 0
poll: 0
update: 4
address 31: master #8, ebusd
address 36: slave #8, ebusd
Es gab auch mal die Situation, dass der Bus funktioniert hat, aber trotzdem nicht ok war! (no signal)

Code Auswählen Erweitern

version: ebusd 3.0.595c7c0
update check: version 3.3 available, broadcast.csv: newer version available
signal: no signal
reconnects: 0
masters: 3
messages: 13
conditional: 0
poll: 0
update: 4
address 03: master #11
address 08: slave #11
address 10: master #2
address 31: master #8, ebusd
address 36: slave #8, ebusd

Seltsamerweise ist aber die gelbe LED an und die gruene LED ist auch am Flackern. Wenn die Rote aufblinkt, sieht es auch so aus, als ob eine Antwort kommt.
Wie kann ich dem auf die Schliche kommen?
Eingesetzt habe ich eine V2 mit Erweiterung und Wemos. Dieser laesst sich auch vom RPI, auf dem der eBus laeuft, anpingen.
Gruss Christoph

[Reinhart]

Was meinst du genau mit "Netzwerkupdate"?
Hat sich vielleicht das Gateway geändert und geht denn das Webinterface des Wemos noch?

Irgendwas muss sich ja geändert haben, den das der Adapter in diesem Zusammenhang stirbt wäre ja reiner Zufall.
Schön wäre jetzt, wenn du den Adapter mit dem Uart verbinden könntest, dann kann man den Fehler schon stark eingrenzen und den Adapter selbst ausschließen. Mir ist schon klar, das dies unter Umständen nicht so leicht zu bewerkstelligen ist wenn dies die örtliche Installation nicht erlaubt, aber helfen würde es zur Fehlersuche.

LG

[pc1246]

Moin Reinhart
Danke fuer Deine Antwort. Leider muss ich die Woche auf Dienstreise, so dass ich mich erst am Samstag wieder kuemmern kann.
Den UART kann ich dann aber problemlos testen. Ich habe ja auch noch einen weiteren Adapter, und noch den RPI-Adapter!
Ich hatte halt gehofft, ich kann erstmal mit ein paar Befehlen testen, wo der Hase eventuell im Pfeffer liegt.
Evtl. kann ich ja von unterwegs noch mal was rausfinden, VPN steht ja.
Gruss Christoph

[pc1246]

Hallo
VPN funktioniert.
Was mich wundert, ist die Tatsache, dass es Signal accquired meldet.

Code Auswählen Erweitern

state_ebus signal acquired 2019-01-14 16:46:10
Aber saemtliche Werte nicht gefunden werden.

Code Auswählen Erweitern

470-Hc1ActualFlowTempDesired ERR: element not found 2019-01-14 19:15:05
Mal sehen, ob ich irgendwie was finden kann. Erstmal muss ich aber was essen!
Das Netzwerk, um das kurz noch zu erklaeren, musste ich im WLAN komplett neu strukturieren. Ich wollte eigentlich WDS machen, was aber wohl mit beiden Frequenzbaendern gleichzeitig nicht geht. Wenn denn das Netz komplett hin ist, dann quittieren die Wemos das mit Absturz.
Gruss Christoph

[Reinhart]

aha, gestern war aber noch "no Signal".
WDS hatte ich auch nach einigen Probemonaten wegen der Störanfälligkeit wieder aufgegeben. Der einzige wirkliche Vorteil wäre ja der Zellenwechsel (Hot Spot Wechsel) ohne Verbindungsabbruch. Ich habe es damals mit dd-wrtg getestet, bin aber der Meinung das SOHO Geräte da nicht so das gelbe vom Ei sind.

Aber "Element not found" ist ja eine andere Sache und hat nichts mit der Verbindung zu tun. Hast du zufällig einen Watchdog laufen der dir den Dämon öfters startet?

LG
Reinhart

[pc1246]

Hallo Reinhart
Nein ich habe eigentlich nichts weiter am Laufen. Sorry gestern war ich dann doch zu KO! (750km in 5:45 und dann auch noch gearbeitet!)
Ich hatte ja gleich das Gefuehl, dass auf dem eBus alles normal aussieht. Tja wie soll ich das jetzt pruefen? Heute will das VPN auch nicht, Hotel wird auch voller!
Dann muss ich am WE doch mal die serielle dranmachen. Da muss ich erstmal forschen was ich alles umstellen muss!
Gruss Christoph (Der gerade im Handball mitfiebert!)
BTW: Was macht euer Schnee?

[Reinhart]

ich würde dir auch empfehlen das in Ruhe via Uart zu testen. Viel kann es ja nicht sein wenn vorher alles geklappt hat. Über VPN läufst du Gefahr irgendwas zum hängen zu bringen und bei 750Km Entfernung ist das nicht gut. Bei Fernwartungen ist der kritische Punkt immer das Netzwerk und genau da hattest du ja Probleme.

Ja, der Schnee ist nicht mehr so arg, ich hab noch 50cm aber es taut schon langsam. So habe ich mehr Zeit zum Löten des RPI Renners!

LG

[Gyrinx]

Hallo Zusammen,

aktuell habe ich meinen EBUS nun lauffähig und bekomme auch schon die ersten Informationen.
Ich hänge aber bei ein paar Problemen fest:

1. Timer

Ich kann den Timer nicht verwenden, da FHEM diesen nicht annimmt:

Code Auswählen Erweitern


define EBUS.MQTT at +*00:05:00 {
  fhem("set Mosquitto publish ebusd/430/Hc1HeatCurve/get");
  fhem("set Mosquitto publish ebusd/bai/WaterPressure/get");
  fhem("set Mosquitto publish ebusd/bai/FlowTemp/get");
  fhem("set Mosquitto publish ebusd/bai/ReturnTemp/get");
  fhem("set Mosquitto publish ebusd/bai/OutdoorstempSensor/get");
}


Code Auswählen Erweitern


Fehlermeldung:

issing right curly or square bracket at (eval 8877) line 1, at end of line
syntax error at (eval 8877) line 1, at EOF

Unknown command fhem("set, try help.
Unknown command fhem("set, try help.
Unknown command fhem("set, try help.
Unknown command fhem("set, try help.
Unknown command }, try help.


Ich vermute, der Befehl gehört nicht dorthin?

Weiterhin laden die Templates von Reinhart nicht BAI oder die VC430 sondern das, was auf den beiden Bildern zu sehen ist.

(https://www.bilder-upload.eu/thumb/256820-1548081258.png)
(https://www.bilder-upload.eu/thumb/dd6d79-1548081310.png)

Vielleicht könnt Ihr mir helfen