eBUS Adapter 3.0 Inbetriebnahme

[baumhous3]

Hallo,

ich habe meinen Adapter auch bekommen und wollte ihn heute morgen einrichten.

Anschluss erfolgt per LAN. Die Jumper habe ich entsprechend gesetzt. Jedoch bekomme ich keine LAN-Verbindung zum Adapter aufgebaut. Die blaue LED blinkt dabei permanent mit den ca. 4x pro Sekunde, weshalb ich davon ausgehe, dass die DHCP Vergabe nicht klappt. Woran kann dies ggf. liegen?

Der Anschluss selbst scheint i.O. zu sein, da sowohl im Switch als angeschlossen angezeigt wird und auch auf dem LAN-Modul des Adapters die grüne Leuchte leuchtet.

[john30]

Anschluss erfolgt per LAN. Die Jumper habe ich entsprechend gesetzt. Jedoch bekomme ich keine LAN-Verbindung zum Adapter aufgebaut. Die blaue LED blinkt dabei permanent mit den ca. 4x pro Sekunde, weshalb ich davon ausgehe, dass die DHCP Vergabe nicht klappt. Woran kann dies ggf. liegen?

Was hast Du denn für einen DHCP Server?

[john30]

Es hat jetzt auch mal geklappt, dann wieder nicht.

was heißt das genau? Also im Sinne der Antwort vom ebusd.

Temperatur konnte ich gar nicht über MQTT verstellen.

dann bitte mehr Details dazu geben, so kann ich absolut nichts dazu sagen (ebusd Log, MQTT Topic samt Content und Antwort).

Auf dem ebusd geht es leider auch nur manchmal

heißt was genau? wie ist die Antwort zum Kommando und wie setzt du es ab?

, und dann auch unzuverlässig, sprich er nimmt den Befehl, aber macht nichts:

Code Auswählen Erweitern

root@ebusd:/etc/default# ebusctl w -c 430 HwcQuickVetoTemp 22
done


das würde dann wiederum an der Heizung liegen, denn mehr als die Message abschicken, kann ebusd auch nicht tun.

root@ebusd:/etc/default# ebusctl r -f -c 430 HwcQuickVetoTemp
55.0[/code]

bist Du sicher, dass nicht ein anderes Gerät den Wert überschreibt?
Wie sehen denn jetzt deine EBUSD_OPTS aus?
Und bist Du noch auf der Wemos Verbindung?
Du hast zuletzt geschrieben, dass es jetzt stabil läuft. Wie ist denn jètzt das Setup?

[baumhous3]

Was hast Du denn für einen DHCP Server?

Nutze den Standard DHCP-Server der FritzBox

[timekeeper]

Nach ein paar kleinen Anfangsschwierigkeiten läuft nun mein ebus-Adaper (per LAN) und der ebusd reibungslos. Danke für die tolle Arbeit.

Ich habe noch eine Frage zum aktiven Auslesen von Werten:
Ich habe mir ein Script geschrieben, welches per ebusctl ausgewählte Werte meiner Vaillant-Therme ausliest. Dabei verwendet ich die Parameter "-p 1 -m 30".
Nun zu meinen Fragen:

• Im Wiki steht "-m SECONDS   only return cached value if age is less than SECONDS": Bedeutet dies, dass der Wert zyklisch abgefragt wird oder einmalig?
• Wie binde ich mein Script am besten ein?
• Welche Bedeutung und welchen Wertebereich hat die Priorität
• Muss ich etwas beachten, um den Bus nicht zu überlasten?

Herzlichen Dank im Voraus
Hermann

[Reinhart]

-m liest aus dem Cache, -f ( force ) liefert dir aktuelle Daten und zwingt den Adapter zu einer aktuellen Abfrage.
Den Bus überlasten kannst du wenn du zu kurz hintereinander abfragst. Das System ist ja nicht dazu konzipiert hier ständig auszulesen, sondern oberste Priorität hat die Steuerung und der interne Infomationsfluß der Heizung. Bei einer Heizung ist ohnehin alles träge und wenn die Abstände der Abfragen in etwa 5 - 10 Minuten hast ist das in meinen Augen genug. Manche Werte benötigt man ohnehin nur einmal am Tag. Jede Abfrage mit -f ist ein Sendebefehl am Bus!

Man kann aber auch überlegen ob man nicht schon die Broadcast ausnutzt ( Status01 ), die kommen alle paar Sekunden und liefern schon wichtige Parameter wie Vorlauf, Rücklauf, Warmwassertemp, Aussentemp.

Ich würde aber lieber die Abfragesteuerung aus der Applikation mit einem Timer machen, da ist es komfortabler und du kannst es jederzeit ändern.

So eine typische Abfrage via MQTT könnte so ausssehen:

Code Auswählen Erweitern

+*00:10: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/Status02/get;
set ebusMQTT publish ebusd/bai/HcHours/get;
set ebusMQTT publish ebusd/bai/HwcStarts/get
das ist jetzt in FHEM, aber du hast sicher im iobroker auch Timer zur Verfügung!

Die unten angehängten Bilder sind alle aus den Statusmeldungen generiert.

LG

[timekeeper]

Danke für die schnelle Antwort.
Ich verwende openhab, nicht iobroker. Und deshalb läuft die Kommunikation über dessen binding, nicht über MQTT.
Timer habe ich dort natürlich, ich weiß nur nicht, was ich hierfür triggern muss.
Mir geht es auch gar nicht darum, permanent alle Werte abzufragen. Da aber meine Vaillant ab und zu herumzickt und man nicht mitbekommt, wenn sie im Keller eine Fehlermeldung ausspuckt und in den Notbetrieb geht, steht man plötzlich mit kaltem Wasser unter der Dusche. Deshalb würde ich gerne zyklisch den currenterror abfragen, um eine Telegram-Notification zu versenden, falls sich da etwas tut.

Hermann

[rob]

Hallo.

Heute bin ich nun endlich auch zum Testen gekommen 
- Therme stromlos gemacht
- Adapter LAN-Version an die Switch angeschl.
- ebus zur Therme dazu geklemmt
- Adapter Strom gegeben
- Therme eingeschaltet
- Fhem in Docker gestartet

Code Auswählen Erweitern


docker run -d --rm --device=/dev/bus/usb/ --net=testnet -p 8083:8083 --name fhem  fhem/fhem

- MQTT-Server angelegt und ebus-Template gesetzt
- ebusd in Docker gestartet

Code Auswählen Erweitern


docker run --rm -it --net=testnet --name ebus -p 8888 john30/ebusd -f --scanconfig -d udp:192.168.222.188:9999 --latency=80 --accesslevel=* --address=ff --mqttport=1883 --mqttjson --mqtthost=fhem --mqtttopic=ebusd/%circuit/%name --mqttchanges


--> Kommunikation MQTT klappt

Code Auswählen Erweitern


2021-03-21 12:13:19.956 [main notice] ebusd 21.1.v21.1-3-g62221bb started with auto scan
2021-03-21 12:13:20.161 [bus notice] bus started with own address ff/04
2021-03-21 12:13:20.172 [mqtt notice] connection established
2021-03-21 12:15:30.226 [main notice] update check: version 21.2 available


Code Auswählen Erweitern


Internals:
   CFGFN     
   CID        ebusd
   DEF        ebusd
   DEVICETOPIC MQTT2_ebusd_21.1_1
   FUUID      6057376c-f33f-10f2-373a-36496dae4bb63402
   IODev      myMQTT_Server
   LASTInputDev myMQTT_Server
   MSGCNT     108
   NAME       MQTT2_ebusd_21.1_1
   NR         55
   STATE      Status:
1:true
Signal:
2:signal
<br>Uptime: 0 000 00:24
   TYPE       MQTT2_DEVICE
   myMQTT_Server_MSGCNT 108
   myMQTT_Server_TIME 2021-03-21 13:38:08
   OLDREADINGS:
   READINGS:
     2021-03-21 13:15:30   associatedWith  MQTT2_ebusd_21.1_1
     2021-03-21 13:09:40   attrTemplateVersion 20200522 or prior
     2021-03-21 13:10:32   datetime       
     2021-03-21 13:10:32   eeprom         
     2021-03-21 13:10:32   error           
     2021-03-21 13:38:08   formatedUptime  0 000 00:24
     2021-03-21 13:10:32   id             
     2021-03-21 13:10:32   queryexistence 
     2021-03-21 13:10:32   ram             
     2021-03-21 13:13:20   running         true
     2021-03-21 13:13:30   scan            "finished"
     2021-03-21 13:10:32   signoflife     
     2021-03-21 13:10:32   state           getAll
     2021-03-21 13:15:30   updatecheck     "version 21.2 available"
     2021-03-21 13:38:08   uptime          1488
     2021-03-21 13:13:20   version         "ebusd 21.1.v21.1-3-g62221bb"
Attributes:
   IODev      myMQTT_Server
   autocreate 1
   bridgeRegexp (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"
   comment    NOTE: additional templates and code have been downloaded from svn (contrib).
   devStateIcon 1.true:it_net 1.false:it_net@red  2.true:lan_rs485 2.false:lan_rs485@red
   icon       sani_boiler_temp
   model      eBus_daemon_splitter
   readingList ebusd/broadcast/datetime:.* datetime
ebusd/broadcast/error:.* error
ebusd/broadcast/id:.* id
ebusd/broadcast/queryexistence:.* queryexistence
ebusd/broadcast/signoflife:.* signoflife
ebusd_21.1_1:ebusd/memory/eeprom:.* eeprom
ebusd_21.1_1:ebusd/memory/ram:.* ram
ebusd/global/scan:.* scan
ebusd/global/updatecheck:.* updatecheck
   room       MQTT2_DEVICE
   setList    getKnown:noArg ebusd/list onlyknown
  getAll:noArg ebusd/list
   stateFormat Status:
1:running
Signal:
2:signal
<br>Uptime: formatedUptime
   userReadings formatedUptime:uptime.* {my $m = ReadingsVal($name,"uptime",0)/60;; return sprintf "0 000 00:%02d", $m if $m < 60;; my $h = $m / 60;; $m %= 60;; return sprintf "0 000 %02d:%02d", $h, $m if $h < 24;; my $d = $h / 24;; $h %= 24;; return sprintf "0 %03d %02d:%02d", $d, $h, $m if $d <365;; my $y = $d / 365;; $d %= 365;; return sprintf "%d %03d %02d:%02d", $y, $d, $h, $m}


--> ebusctl i sagt "no signal"

Code Auswählen Erweitern


root@708e219e024d:/# ebusctl i
version: ebusd 21.1.v21.1-3-g62221bb
update check: version 21.2 available
access: *
signal: no signal
reconnects: 0
masters: 1
messages: 11
conditional: 0
poll: 0
update: 4
address 04: slave #25, ebusd
address ff: master #25, ebusd


--> die grüne LED flackert und blinkt ganz wild, als würden ganz viele Telegramme drüberflattern
--> Verkabelung ebus habe ich mehrfach gecheckt
--> Jumper stehen wie im Wiki beschrieben
--> Adapter ist aus dem Container heraus erreichbar:

Code Auswählen Erweitern


root@6086aff6bf43:/# ping 192.168.222.188
PING 192.168.222.188 (192.168.222.188) 56(84) bytes of data.
64 bytes from 192.168.222.188: icmp_seq=1 ttl=127 time=2.18 ms
64 bytes from 192.168.222.188: icmp_seq=2 ttl=127 time=1.20 ms
64 bytes from 192.168.222.188: icmp_seq=3 ttl=127 time=0.971 ms
64 bytes from 192.168.222.188: icmp_seq=4 ttl=127 time=1.26 ms
64 bytes from 192.168.222.188: icmp_seq=5 ttl=127 time=1.16 ms
^C
--- 192.168.222.188 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 0.971/1.358/2.180/0.423 ms
root@6086aff6bf43:/#


Habe ich noch irgendwo einen Lapsus drinnen? Was kann/ sollte ich noch testen?

Vielen Dank und beste Grüße
rob

[chris371]

Hallo zusammen,

auch ich habe in der Woche meinen (USB-)Adapter bekommen und ihn jetzt am Wochenende eingebaut. Ihr habt ja wirklich professionelle Arbeit abgeliefert und super dokumentiert - vielen Dank dafür! 

Hardware und ebusd laufen (aus den Sourcen kompiliert in einer VM auf einer Synology DS920+) soweit stabil die letzte Nacht über. Auch die Heizung scheint sich nicht am neuen Busteilnehmer zu stören. Ich habe eine Vaillant auroMATIC 620/3 mit zusätzlichem Mischermodul VR60/3, Therme ecoTEC plus VC206/5 und VPM Trinkwasserstation an einem Schichtspeicher.

Beim ersten ausprobieren hatte ich Bedenken, weil anscheinend viel auf den Bus gesendet wird. Die rote LED blieb nicht länger als vielleicht 3 Sekunden aus. Hatte daraufhin den ebusd mit --readonly gestartet, aber damit hat er lt. "ebusctl i" dann keine CSVs mehr geladen, obwohl nach einiger Zeit alle Slaves mit ID, SW und HW bekannt waren. Nächster Versuch war mit --pollinterval=0, aber damit wollte der ebusd gar nicht mehr starten:

Code Auswählen Erweitern

Mar 20 17:57:14 smh ebusd[25024]: ebusd: scanconfig without polling may lead to invalid files included for certain products!
Mar 20 17:57:14 smh ebusd[25024]: Try `ebusd --help' or `ebusd --usage' for more information.
Ist das ein Bug?
Was wird da eigentlich gepollt? Die Auswahl der zu pollenden Werte müsste ich doch auch irgendwo konfigurieren können?

Letztlich lief dann mit dieser Config alles wunderbar die Nacht durch:

Code Auswählen Erweitern

EBUSD_OPTS="--scanconfig --accesslevel=* --latency=20000 --pollinterval=61 -d enh:/dev/ttyUSB0 --address=ff"

[john30]

Nutze den Standard DHCP-Server der FritzBox

um einen defekten USR auszuschließen, könntest Du mal auf eine fixe IP umstellen?

[john30]

- ebusd in Docker gestartet

Code Auswählen Erweitern


docker run --rm -it --net=testnet --name ebus -p 8888 john30/ebusd -f --scanconfig -d udp:192.168.222.188:9999 --latency=80 --accesslevel=* --address=ff --mqttport=1883 --mqttjson --mqtthost=fhem --mqtttopic=ebusd/%circuit/%name --mqttchanges


der Adapter kann kein UDP und je nachdem, wie der Jumper fürs enhanced Protokoll steht (Auslieferungszustand: enhanced), musst Du entweder "-d enh:192.168.222.188:9999" (enhanced) oder "-d tcp:192.168.222.188:9999" (nicht enhanced) nehmen.

[john30]

Code Auswählen Erweitern

Mar 20 17:57:14 smh ebusd[25024]: ebusd: scanconfig without polling may lead to invalid files included for certain products!
Mar 20 17:57:14 smh ebusd[25024]: Try `ebusd --help' or `ebusd --usage' for more information.
Ist das ein Bug?

nein, das Scannen der Geräte geht nur in Kombination mit Polling.

Was wird da eigentlich gepollt? Die Auswahl der zu pollenden Werte müsste ich doch auch irgendwo konfigurieren können?

Die ID der Geräte und die Nachrichten, die mit Poll Priorität versehen sind.

[rob]

der Adapter kann kein UDP...

Danke Dir, jetzt klappt es:

Code Auswählen Erweitern


root@91ad7941eb6b:/# ebusctl i
version: ebusd 21.1.v21.1-3-g62221bb
update check: version 21.2 available
access: *
signal: acquired
symbol rate: 38
max symbol rate: 46
min arbitration micros: 4
max arbitration micros: 9
min symbol latency: 15
max symbol latency: 23
reconnects: 0
masters: 4
messages: 14
conditional: 0
poll: 0
update: 4
address 04: slave #25, ebusd
address 07: master #16
address 0c: slave #16, scanned "MF=-;ID=??;SW=-;HW=-"
address 30: master #3
address 35: slave #3, scanned "MF=Kromschroeder;ID=W ;SW=2726;HW=-"
address f1: master #10
address f6: slave #10, scanned "MF=Kromschroeder;ID=WWST?;SW=1200;HW=0302"
address ff: master #25, ebusd


Ich hatte mich an der Docker-Doku orientiert. Die ist wahrscheinlich universeller formuliert, weil ja auch UDP-fähige Geräte im Einsatz sein könnten. Verstanden.

Dann mach ich mal an die CSV-Dinger, was ich aber wie angeregt in einem anderen Fred forcieren werde

Abermals vielen Dank, beste Grüße und einen schönen Sonntag noch
rob

[john30]

zum Thema WIFI:
Ich hab jetzt Delays gemessen in den Varianten USB, Ethernet und Wemos und die Ergebnisse sind nicht unbedingt überraschend:
- Ethernet hat das kürzeste Send-Receive Delay bei 7/8/11 ms (min/mittel/max)
- USB folgt vom Mittelwert dahinter mit 13/17/32
- last but not least der Wemos mit 12/26/135

Wirklich unschön sind natürlich die sporadischen Wemos Ausreißer mit teilweise über 100 ms Verzögerung. Das ist andererseits nachvollziehbar in einem durchaus beanspruchten Umfeld mit zig weiteren WLANs in der Nähe (ja, mein WLAN ist wirklich schrottig). Deshalb hat es mich wie gesagt nicht sonderlich überrascht.

Meine Empfehlung daher: Beim Einsatz von Wemos das Maximum an Latency einstellen mit `--latency=100´.
Ethernet braucht theoretisch keine Latency, aber bissl was schadet vermutlich nicht und ich empfehle `--latency=20´.
Und weil USB Serial selbst im jetzigen enhanced protocol mit 9600 Bd auch nicht wahnsinnig flott ist, würde ich hier mit `--latency=20´ ins Rennen gehen.
Beim Raspi hab ich in Erinnerung, dass der UART wegen des Kernel Moduls bis zu 4 Bytes puffert, weshalb auch hier eine Latency Abhilfe schaffen kann. 4*5ms wären 20, aber ich denke `--latency=40´ wäre ein guter Wert.

[baumhous3]

um einen defekten USR auszuschließen, könntest Du mal auf eine fixe IP umstellen?

Habe nun eine fixe IP vergeben und nun klappt die Verbindung
Bekomme auch Daten von der Lüftung. Nur kriege ich jetzt keine Daten mehr von der Heizung, die vorher lief über den esera adapter.

Er zeigt mir zwar die Vaillant an (siehe unten), jedoch kommen dort keine Daten.
Die KWL hingegen wird im find / scan result nicht angezeigt, liefert jedoch fleißig Daten per MQTT. Woran kann das nun liegen?

Sieht wie folgt aus:
Einstellungen:

Code Auswählen Erweitern

EBUSD_OPTS1="-d 192.168.178.50:5007 --mqtthost=127.0.0.1 --mqttport=1883 --mqttjson --scanconfig --configpath=PATH"
EBUSD_OPTS2="-d enh:192.168.178.65:9999 --mqtthost=127.0.0.1 --mqttport=1883 --mqttjson --scanconfig --configpath=/etc/ebusd --address=ff"

Ergebnisse:

Code Auswählen Erweitern

pi@raspberrypi:~ $ sudo service ebusd status
● ebusd.service - LSB: controls ebusd, the daemon for communication with eBUS heating systems.
   Loaded: loaded (/etc/init.d/ebusd; generated)
   Active: active (running) since Sun 2021-03-21 18:45:45 CET; 2min 42s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 449 ExecStart=/etc/init.d/ebusd start (code=exited, status=0/SUCCESS)
    Tasks: 9 (limit: 4915)
   CGroup: /system.slice/ebusd.service
           ├─471 /usr/bin/ebusd --pidfile /var/run/ebusd1.pid -d 192.168.178.50:5007 --mqtthost=127.0.0.1 --mqttport=1883 --mqttjson --scanconfig --configpath=PATH
           └─484 /usr/bin/ebusd --pidfile /var/run/ebusd2.pid -d enh:192.168.178.65:9999 --mqtthost=127.0.0.1 --mqttport=1883 --mqttjson --scanconfig --configpath=/etc/

Mär 21 18:45:45 raspberrypi systemd[1]: Starting LSB: controls ebusd, the daemon for communication with eBUS heating systems....
Mär 21 18:45:45 raspberrypi ebusd[449]: Starting ebusd1: ebusd.
Mär 21 18:45:45 raspberrypi ebusd[449]: Starting ebusd2: ebusd.
Mär 21 18:45:45 raspberrypi systemd[1]: Started LSB: controls ebusd, the daemon for communication with eBUS heating systems..


pi@raspberrypi:~ $ ebusctl info
version: ebusd 21.2.v21.2
update check: OK
signal: acquired
symbol rate: 24
max symbol rate: 94
min arbitration micros: 3
max arbitration micros: 5
min symbol latency: 9
max symbol latency: 12
reconnects: 0
masters: 4
messages: 3
conditional: 0
poll: 0
update: 0
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=HMU00;SW=0307;HW=0403"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=72000;SW=0118;HW=7703"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 71: master #9
address 76: slave #9, scanned "MF=Vaillant;ID=VWZ00;SW=0307;HW=0403"


pi@raspberrypi:~ $ ebusctl scan result
08;Vaillant;HMU00;0307;0403
15;Vaillant;72000;0118;7703
76;Vaillant;VWZ00;0307;0403