eBus Schaltung V2 in Betrieb nehmen

[john30]

Mit ebusd-esp 20171230 behält der Wemos die Konfiguration über mehrere Kalt- und Warmstart hinweg, auch nach zwei Tagen Dauerbetrieb. Mit einem zweiten Wemos verhält es sich identisch.
Damit ist also mein Problem mit der verlorenen Konfiguration anscheinend gelöst.

Ah, sehr schön!

Die eBus-Verkabelung habe ich schon erneuert (Telefonkabel durch 0,75qmm Stromkabeladern ersetzt). Wenn ich die Heizungsregelung hochfahre blinken rote&grüne LED (die gelbe leuchtet dauerhaft). Nach ca. einer Minute hört die rote LED auf zu blinken und nur noch die grüne blinkt - das war aber vorher auch schon so.

Es kann jetzt einfach noch ein Latenzproblem mit Deinem WLAN sein. Nimm mal in /etc/default/ebusd noch den Parameter "--receivetimeout=50000" dazu, damit ist ebusd nicht mehr gar so pingelig, was die erlaubte Antwortzeit eines Slave betrifft.

[msfox]

Die eBus-Verkabelung habe ich schon erneuert (Telefonkabel durch 0,75qmm Stromkabeladern ersetzt).

Welchen Querschnitt sollten denn die Kabel mindestens (maximal) haben. Ich wollte 2 Adern aus einem CAT6-Kabel nehmen.

[dkreutz]

Hallo John,

Es kann jetzt einfach noch ein Latenzproblem mit Deinem WLAN sein. Nimm mal in /etc/default/ebusd noch den Parameter "--receivetimeout=50000" dazu, damit ist ebusd nicht mehr gar so pingelig, was die erlaubte Antwortzeit eines Slave betrifft.

Mit folgender Konfiguration

Code Auswählen Erweitern

EBUSD_OPTS="-d 192.168.100.94:9999 -l /var/log/ebusd.log --scanconfig --latency=20000 --loglevel=debug --receivetimeout=50000"

sieht es leider nicht besser aus

Code Auswählen Erweitern

2018-01-03 11:56:15.731 [bus notice] signal acquired
2018-01-03 11:56:25.659 [main debug] performing regular tasks
2018-01-03 11:56:28.740 [network info] [00001] client connection opened 127.0.0.1
2018-01-03 11:56:28.740 [main debug] >>> info
2018-01-03 11:56:28.741 [main debug] <<< version: ebusd 3.0pre.bbc4d04
signal: acquired
symbol rate: 5
max symbol rate: 5
reconnects: 0
maste ...
2018-01-03 11:56:28.740 [network debug] [00001] wait for result
2018-01-03 11:56:28.742 [network info] [00001] connection closed
2018-01-03 11:56:29.741 [network debug] dead connection removed - 0
2018-01-03 11:56:33.741 [main debug] performing regular tasks
2018-01-03 11:56:40.452 [network info] [00002] client connection opened 127.0.0.1
2018-01-03 11:56:40.453 [main debug] performing regular tasks
2018-01-03 11:56:40.453 [main debug] >>> scan full
2018-01-03 11:56:40.453 [network debug] [00002] wait for result
2018-01-03 11:56:40.454 [bus info] scan 02 cmd: 3102070400
2018-01-03 11:56:40.454 [main debug] <<< done
2018-01-03 11:56:40.455 [network info] [00002] connection closed
2018-01-03 11:56:40.648 [bus debug] arbitration delay 89 micros
2018-01-03 11:56:40.648 [bus info] arbitration delay 89 - 89 micros
2018-01-03 11:56:40.648 [bus debug] switching from ready to send command
2018-01-03 11:56:40.654 [bus debug] send/receive symbol latency 5 ms
2018-01-03 11:56:40.654 [bus info] send/receive symbol latency 5 - 5 ms
2018-01-03 11:56:40.659 [bus debug] send/receive symbol latency 5 ms
2018-01-03 11:56:40.668 [bus debug] send/receive symbol latency 8 ms
2018-01-03 11:56:40.668 [bus info] send/receive symbol latency 5 - 8 ms
2018-01-03 11:56:40.673 [bus debug] send/receive symbol latency 5 ms
2018-01-03 11:56:40.673 [bus debug] switching from send command to send command CRC
2018-01-03 11:56:40.679 [bus debug] send/receive symbol latency 5 ms
2018-01-03 11:56:40.679 [bus debug] switching from send command CRC to receive command ACK
2018-01-03 11:56:40.769 [bus debug] notify request: ERR: read timeout
2018-01-03 11:56:40.769 [bus info] scan 04 cmd: 3104070400
2018-01-03 11:56:40.769 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2018-01-03 11:56:40.895 [bus debug] arbitration delay 68 micros
2018-01-03 11:56:40.895 [bus info] arbitration delay 68 - 89 micros
2018-01-03 11:56:40.895 [bus debug] switching from ready to send command
2018-01-03 11:56:40.901 [bus debug] send/receive symbol latency 5 ms
2018-01-03 11:56:40.906 [bus debug] send/receive symbol latency 5 ms
2018-01-03 11:56:40.912 [bus debug] send/receive symbol latency 6 ms
2018-01-03 11:56:40.918 [bus debug] send/receive symbol latency 5 ms
2018-01-03 11:56:40.918 [bus debug] switching from send command to send command CRC
2018-01-03 11:56:40.924 [bus debug] send/receive symbol latency 6 ms
2018-01-03 11:56:40.924 [bus debug] switching from send command CRC to receive command ACK
2018-01-03 11:56:41.014 [bus debug] notify request: ERR: read timeout
2018-01-03 11:56:41.015 [bus info] scan 05 cmd: 3105070400
2018-01-03 11:56:41.015 [bus debug] ERR: read timeout during receive command ACK, switching to skip

Was bedeuten die Meldung "client connection opened 127.0.0.1" - müsste hier nicht die IP des ebusd-esp stehen?
Und was bedeutet "dead connection removed"?

VG
Dominik

[dkreutz]

Welchen Querschnitt sollten denn die Kabel mindestens (maximal) haben. Ich wollte 2 Adern aus einem CAT6-Kabel nehmen.

Für kurze Kabellängen sollte das ausreichen, zumal bei CAT-Kabeln die Adern paarweise verdrillt und insgesamt abgeschirmt sind.
Ich hatte vorher ein altes Telefonkabel verwendet, da ist mir aber durch das häufige hantieren mit dem Wemos (für Tests immer wieder ab/an-stecken) auch schon eine Ader gebrochen.
Irgendwo habe ich eine eBus-Spezifikation gefunden, da stand 0.7qmm Querschnitt - allerdings für Kabellängen >100m.

VG
Dominik

[ihatedenhasen]

Hallo
die V2.0 hängt nun am Bus und unter ebusctl info habe ich Versionsinformationen speziell auch der .csv bekommen.
Wie update ich jetzt richtig? Benötige dafür Hilfe ...

Code Auswählen Erweitern

pi@FHEM:~ $ ebusctl info
version: ebusd 3.0.v3.0-30-g89c4612
update check: version 3.1 available, broadcast.csv: different version available, vaillant/15.430.csv: different version available, vaillant/bai.308523.inc: different version available, vaillant/broadcast.csv: different version available, vaillant/errors.inc: different version available, vaillant/hcmode.inc: different version available
signal: acquired
symbol rate: 22
max symbol rate: 123
min arbitration micros: 2083
max arbitration micros: 3594
min symbol latency: 5
max symbol latency: 5
reconnects: 0
masters: 3
messages: 430
conditional: 19
poll: 0
update: 9
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0414;HW=7401", loaded "vaillant/bai.308523.inc" ([PROD='0010004289']), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=43000;SW=0136;HW=2002", loaded "vaillant/15.430.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd

unter ebusd -V ist v3.1

Code Auswählen Erweitern

pi@FHEM:~ $ ebusd -V
ebusd 3.1.v3.0-36-g60a18d1

[MichaelV]

So, bei mir läuft nun alles: ebus Platine hängt an der Wärmepumpe, überträgt per WLAN die Daten an ebusd und von dort wandern sie dann per MQTT in ioBroker. Soweit also alles Bestens und das ausgiebige Testen und Probieren kann beginnen.

Was bedeuten die Meldung "client connection opened 127.0.0.1" - müsste hier nicht die IP des ebusd-esp stehen?

Diesen Eintrag siehst Du, wenn du lokal auf dem Rechner auf dem der ebusd läuft z.B. ebusctl info aufrufst.

die V2.0 hängt nun am Bus und unter ebusctl info habe ich Versionsinformationen speziell auch der .csv bekommen.
Wie update ich jetzt richtig? Benötige dafür Hilfe ...

Soweit ich es verstanden habe, funktioniert die Versionsprüfung der Config-Files nicht richtig und Du kannst das ignorieren.

Ich hatte noch das Problem, als ich in ebusd den Parameter -r gesetzt hatte, dass keine Daten mehr zwischen der Platine und ebusd übertragen wurden. Wollte zur Sicherheit nur lesen, aber nachdem ich den Parameter wieder rausgenommen habe klappte alles.

Eine Frage habe ich noch zum Parameter --scanconfig: Benötige ich den noch oder kann ich auch irgendwo festlegen, welche config files genommen werden sollen?

Vielen Dank für Eure Hilfe,
Michael

[Reinhart]

Welchen Querschnitt sollten denn die Kabel mindestens (maximal) haben. Ich wollte 2 Adern aus einem CAT6-Kabel nehmen.

schau bitte in die Spezifikation, Punkt 10.1.2, Seite 19/20!


LG
Reinhart

[Reinhart]

eBusd und MQTT

hier geht es zu Teil 2 der automatischen Abfragen via MQTT

Da sich doch einige Anwender schon mit der Möglichkeit des MQTT Protokolls am eBus beschäftigen, möchte ich hier ein paar Beispiele für Neueinsteiger zeigen..
Das MQTT Protokoll bietet schon ein paar Features die man nicht außer acht lassen sollte. Es ist hervorragend bei schlechteren Verbindungen geeignet und ist sehr stabil und zuverlässig.
Als erstes muss es am Client (dort wo Fhem läuft) installiert werden. Dazu gibt es unzählige Artikel im Netz oder auch hier im Fhem Wiki. Für MQTT  ist eine spezielle Version von ebusd zu installieren, siehe dazu Johns Wiki.

Code Auswählen Erweitern

EBUSD_OPTS="-d /dev/ttyUSB0 -p 8888 -l /var/log/ebusd.log  --scanconfig --mqtthost=10.0.0.5 --mqttport=1883 --mqttjson --mqtttopic=sonoff_ebus/%circuit/%name"

in der /etc/default/ebusd die opts, MQTT + JSON aktivieren und Topic Namen vergeben!
mqtthost = dort wo der Broker läuft (FHEM)
mqttjson = JSON Format aktivieren
mqttport = Brokerport, Default  1883
mqtttopic = Topic einstellen die bestimmt dann das ankommende Textformat und somit das subscribeReading.

Erster Test in der Mosquitto Konsole:
Eine Konsole (ssh) dort öffnen wo der Broker läuft und folgendes eingeben:
mosquitto_sub -d -v -t \#
das filtert nun alle ankommenden MQTT Strings und zeigt sie an.

Nun ein zweites Konsolenfenster öffnen und einen MQTT Befehl absetzen:

Code Auswählen Erweitern

mosquitto_pub -q 2 -t sonoff_ebus/bai/flowtemp/get -m "r -f flowtemp temp"
Das fragt nun die Vorlauftemperatur vom eBus via MQTT ab und im ersten Konsolenfenster sollte nun folgendes erscheinen:

Code Auswählen Erweitern

Client mosqsub/10819-Raspberry received PUBLISH (d0, q0, r0, m0, 'sonoff_ebus/bai/flowtemp/get', ... (18 bytes))
sonoff_ebus/bai/flowtemp/get r -f flowtemp temp
Client mosqsub/10819-Raspberry received PUBLISH (d0, q0, r0, m0, 'sonoff_ebus/bai/FlowTemp', ... (64 bytes))
sonoff_ebus/bai/FlowTemp {
     "temp": {"value": 49.94},
     "sensor": {"value": "ok"}}
Somit ist alles ok und wir können in FHEM definieren und richten das Modul expandJSON ein.

Code Auswählen Erweitern

define ej3 expandJSON (Sonoff.*:.*:.{.*.*{.*.*}})
hier wird nach dem Devicenamen beginnend mit Sonoff... gefiltert. Deshalb heißt auch mein eBus Device ,,Sonoff_ebusd". Der kann aber einen beliebigen Namen haben, es muss da nur das Filter angepasst werden. ExpandJSON legt dann automatisch die Reading an, sofern in Fhem das Attribut mit subscribeReading definiert wurde.

Code Auswählen Erweitern

define Sonoff_ebus MQTT_DEVICE
attr Sonoff_ebus IODev myBroker
attr Sonoff_ebus stateFormat {sprintf("Vorlauf: %.1f Ruecklauf: %.1f Warmwasser: %.1f Aussentemp.: %.1f", ReadingsVal($name,"0_value",0), ReadingsVal($name,"1_value",0), ReadingsVal($name,"3_value",0), ReadingsVal($name,"2_value",0) )}
attr Sonoff_ebus subscribeReading_Ruecklauf sonoff_ebus/bai/ReturnTemp
attr Sonoff_ebus subscribeReading_Status01 sonoff_ebus/bai/Status01
attr Sonoff_ebus subscribeReading_Vorlauf sonoff_ebus/bai/FlowTemp

Die Syntax ist denkbar einfach und ist wie oben dargestellt.
subscribeReading_Status01 = der Teil der hinter dem _ steht wird dann von ExpandJSON als Reading angelegt.
sonoff_ebus/bai/Status01 = Topicname/CSV-File/eBusReading

Hier ein Beispiel (Heizkurve) wie man einen Wert via MQTT schreiben kann:

Code Auswählen Erweitern

# write -c 430 Hc1HeatCurve
define Sonoff_ebuswrite MQTT_DEVICE
attr Sonoff_ebuswrite IODev myBroker
attr Sonoff_ebuswrite publishSet state sonoff_ebus/430/Hc1HeatCurve/set
attr Sonoff_ebuswrite stateFormat state
attr Sonoff_ebuswrite webCmd 0.20:0.90:1.00:1.10:1.20:1.30:1.40:1.50:1.60:1.70

Ob das File "430" oder anders heißt hängt von eurer Heizanlage ab.

Die wesentlichen Vorteile von MQTT liegen darin, wenn man es nur auf Statusmeldungen auslegt hat man alle paar Sekunden neue Messdaten ohne aktiv den Bus zu befragen da es ja Broadcasts sind und diese live hereinkommen ohne sie anzustoßen! ECMD braucht dabei nicht eingerichtet zu werden da es völlig unabhängig davon arbeitet.

Es funktioniert aber auch beides, ECMD und MQTT kommen sich nicht in die Quere, also ideal zum Testen!

Laut John ist die MQTT Implementierung noch in der Entwicklungsphase aber es bietet schon alles was das Herz begehrt.

Ach ja, bei untem angehängten Bild "ebuswrite" wird einfach auf eine Zahl gedrückt und sofort wird dieser Wert als neue Heizkurve zum eBus geschrieben.

Formatierung:
Wer die Ausgabe lieber mehrzeilig haben möchte (siehe Bild, Style), kann mit stateFormat die auch untereinander formatieren und mit devStateStyle rechtsbündig ausgeben.

Code Auswählen Erweitern

attr ebus_status devStateStyle style="text-align:right"
attr ebus_status stateFormat {sprintf("Vorlauf: %.1f <br>Ruecklauf: %.1f <br>Warmwasser: %.1f <br>Aussentemp.: %.1f <br>Pumpe: %s", ReadingsVal($name,"0_value",0), ReadingsVal($name,"1_value",0), ReadingsVal($name,"3_value",0), ReadingsVal($name,"2_value",0), ReadingsVal($name,"5_value",0))}

LG
Reinhart

[dkreutz]

Hallo,

Mein Adapter will immer noch nicht mit der Heizungsregelung sprechen - siehe weiter oben.
Mit der älteren ebusd-esp Version war ich auch schon weiter, dort wurde ein Gerät auf den Adressen Master F1 und Slave F6 gefunden (was laut Spezifikation für "Heizungsregelung" reserviert ist).

@John hat WLAN/Netzwerklatenzen ins Spiel gebracht, aber der receivetimeout Parameter zeigt keine Wirkung. Mir ist aufgefallen, dass die Wemos mit ESP-Easy bei Zugriffen über das Webinterface  seit ein paar Tagen immer wieder verzögert reagieren , d.h. die Seite baut sich erst nach ein paar Sekunden auf oder es kommt eine leere Seite (Parallel beschwert sich die Ehefrau, dass das iPad nicht mehr so gut auf dem Sofa funktioniert, seitdem ich "das mit der Haustechnik mache"). Recherche nach "Fritzbox Wemos Probleme" brachte die Erkenntnis, dass es Probleme mit dem 5GHz WLAN geben kann. Nachdem ich 5Ghz-WLAN deaktiviert habe, reagieren die ESP-Easy Wemos wieder "normal". Warum das so ist, kann ich nicht sagen - es hat seit längerem keine Fritzbox-Updates o.ä. gegeben... 
Interessanterweise verbindet sich der ebusd-esp Wemos mit der Fritzbox die "um die Ecke" montiert ist, der ESP-Easy Wemos auf der Erweiterungsplatine aber mit dem Fritz-WLAN-Repeater der im Dachstudio platziert ist...

Neue Erkenntnis zum ebusd-esp - ist der ebusd Dienst gestoppt sagt das ebusd-esp Webinterface:

Code Auswählen Erweitern

ebusd connected: yes
eBUS signal: no signal

ist ebusd gestoppt erscheint jedoch:

Code Auswählen Erweitern

ebusd connected: no
eBUS signal: acquired

Woran könnte das liegen?

Was micht noch irritiert ist die ebusd-Version: ebusd sagt

Code Auswählen Erweitern

$ ebusd -V
ebusd 3.0pre.bbc4d04
Der Paketmanager sagt mir aber

Code Auswählen Erweitern

$ dpkg -l | grep ebusd
ii  ebusd                                 3.1                                       armhf        eBUS daemon.

Es gibt aber laut "which ebusd" nur eins unter "/usr/bin". Wie bekomme ich denn die Version korrekt installiert?

[andig]

Hallo Zusammen,

kurzer Ergebnisbericht. Platine C mit Wemos lief auf Anhieb:

  - Platine an EBUS anschließen: Gelbe LED leuchtet
  - OSX: zum Wemos flashen vorher CHG340 Treiber für HighSierra installieren, anderenfalls kein USB Port
  - Wemos mit Stromversorgung anschließen: Grüne + Rote LED blinkt
  - Wemos Reset: Grüne LED blinkt, Wemod UI zeigt "connected"
  - ebusd: device und latenz angeben: `-d 192.168.0.46:9999 --latency=20000`

Ging in Summe unglaublich schnell und glatt- keine 3 Stunden für Alles :

Vielen Dank an alle "Macher"!

[Markus.]

Hallo Zusammen,

will jetzt mal anfangen intensiver zu testen.. Hab da direkt mal eine Frage bezüglich der LEDs .. Wenn man die Platine über den Wemos mit Spannung versorgt, aber den Ebus selber noch nicht angeschlossen hat. Müssen da eigentlich eine oder mehrere LEDs schon leuchten? Oder bekommen die ihre Spannung vom Ebus selber?

Gruß

Markus

[john30]

Neue Erkenntnis zum ebusd-esp - ist der ebusd Dienst gestoppt sagt das ebusd-esp Webinterface:

Code Auswählen Erweitern

ebusd connected: yes
eBUS signal: no signal

ist ebusd gestoppt erscheint jedoch:

Code Auswählen Erweitern

ebusd connected: no
eBUS signal: acquired

Woran könnte das liegen?

das weiß ich gerade auch nicht. Signalstatus wird mit Timeout festgestellt, vielleicht geht da was schief, muss ich mal anschauen (gerade keine Zeit dafür).

Was micht noch irritiert ist die ebusd-Version: ebusd sagt

Code Auswählen Erweitern

$ ebusd -V
ebusd 3.0pre.bbc4d04
Der Paketmanager sagt mir aber

Code Auswählen Erweitern

$ dpkg -l | grep ebusd
ii  ebusd                                 3.1                                       armhf        eBUS daemon.

Es gibt aber laut "which ebusd" nur eins unter "/usr/bin". Wie bekomme ich denn die Version korrekt installiert?

Wurde schon früher intensiv diskutiert. Wird beim nächsten ebusd Release korrigiert.

[Reinhart]

will jetzt mal anfangen intensiver zu testen.. Hab da direkt mal eine Frage bezüglich der LEDs .. Wenn man die Platine über den Wemos mit Spannung versorgt, aber den Ebus selber noch nicht angeschlossen hat. Müssen da eigentlich eine oder mehrere LEDs schon leuchten? Oder bekommen die ihre Spannung vom Ebus selber?

Wenn du dir den Schaltplan ansiehst, dann kann die PowerLed (5V) und die Tx Led erst leuchten wenn der eBus angeschlossen wurde. Die Rx könnte leuchten wenn der Uart/Wemos das Rx Signal aus unbekannten Gründen auf Ground zieht.

- Powerled bekommt Spannung vom eBus und sollte auch zeigen das der Bus angeschlossen ist
- RxLed bekommt die Spannung erst wenn OK1 durchsteuert oder der Uart/Wemos aus irgend einem Grund auf Ground zieht (Kurschluß etc).
- TxLed leuchtet wenn OK2 durchsteuert (Uart auf Low geht) und der eBus angeschlossen ist.

Wenn du den Wemos mit Power versorgst wird lediglich die Funkverbindung aufgebaut und das Webinterface des Wemos sollte erreichbar sein. Man braucht vorm eBus keine Angst haben, es kann nicht viel passieren weil der kurzschlußfest ist, lediglich Überspannung sollte er nicht abbekommen! Platine anschließen und beobachten ob sich an der Heizung was ändert und ob eventuell angeschlossene Geräte wie Calormatic etc. noch funktionieren. Wenn der eBus einen Kurzschluß hat funktioniert keine Kommunikation mehr am Bus, erst wenn dieser wieder behoben ist.

Bitte bei den Leds aufpassen und keine "normalen" Leds einsetzen, es müssen schaltungsbedingt unbedingt "LowCurrent" (2-8 mA) sein! Die wir mitliefern passen!

LG
Reinhart

[Markus.]

Halo Zusammen,

ich habe ja die Version ohne MQTT installiert..
Wenn ich jetzt mit folgendem Befehl die Version mit MQTT installiere, wird dann die laufende Version überschrieben?

Code Auswählen Erweitern


EBUSDPACKAGE=ebusd-3.1_armhf-jessie_mqtt1.deb
wget https://github.com/john30/ebusd/releases/download/v3.1/$EBUSDPACKAGE
sudo dpkg -i --force-overwrite $EBUSDPACKAGE


Oder muss ich neben der geänderten Config noch was beachten? Mosquitto und so läuft bereits..


Gruß

Markus

[Reinhart]

Das passt schon, du musst ohnehin in /etc/default/ebusd auf MQTT anpassen.

Schau dir aber vorher in der Broker Konsole die Json Strings an bevor du dich über die FHEM Konfiguration stürzt.

LG