Arbitration lost

[Koky05]

Description

In every try to load configuration it end with arbitration lost error message. It starts on version 22.1.
I have Vaillant VR470F + VR61

Actual behavior

[main error] scan config 15: ERR: arbitration lost

Expected behavior

load of configuration.

ebusd version

22.3

ebusd arguments

ebusd: image: john30/ebusd:devel container_name: ebusd depends_on: - mqtt #ports: # - "8888:8888/tcp" restart: unless-stopped privileged: true network_mode: host environment: - TZ=Europe/Bratislava - EBUSD_ARCH=amd64 - EBUSD_SCANCONFIG=full - EBUSD_CONFIGPATH=/etc/ebusd/ebusd-configuration/ebusd-2.1.x/en - EBUSD_LOGAREAS=all - EBUSD_LOGLEVEL=info - EBUSD_ACCESSLEVEL=* - EBUSD_MQTTHOST=192.168.2.7 - EBUSD_MQTTPORT=1883 - EBUSD_MQTTUSER=XXXX - EBUSD_MQTTPASS=YYYY - EBUSD_MQTTTOPIC=ebusd - EBUSD_MQTTJSON= - EBUSD_MQTTINT=/etc/ebusd/mqtt-hassio.cfg - EBUSD_MQTTVERBOSE= - EBUSD_MQTTRETAIN= - EBUSD_MQTTCHANGES= volumes: - "/etc/localtime:/etc/localtime:ro" - "/volume1/docker/ebusd/data:/data" - "/volume1/docker/ebusd:/ebusd" - "/volume1/docker/ebusd/config:/etc/ebusd" - "/volume1/docker/ebusd/log:/var/log" command: -d enh:192.168.1.15:9999 -l /var/log/ebusd.log

Operating system

other

CPU architecture

x64

Dockerized

devel

Hardware interface

adapter 3 WiFi

Related integration

MQTT Home Assistant via mqtt-hassio.cfg

Logs

ebusd_logs.txt

[john30]

not much to tell if no log is provided, but anyway: since the device in question (VR470F) seems to be RF based, the timing is a bit different for those and I'd recommend to increase the latency value to ebusd to at least 50ms

[Koky05]

2022-08-03 17:54:17.696 [bus info] scan 04 cmd: 3104070400
2022-08-03 17:54:17.696 [bus debug] start request 31
2022-08-03 17:54:17.696 [bus debug] arbitration start with 31
2022-08-03 17:54:17.824 [bus debug] arbitration lost (timed out)
2022-08-03 17:54:17.824 [bus debug] ERR: arbitration lost during ready, retry
2022-08-03 17:54:17.824 [bus debug] start request 31
2022-08-03 17:54:17.825 [bus debug] arbitration start with 31
2022-08-03 17:54:17.955 [bus debug] arbitration lost (timed out)
2022-08-03 17:54:17.955 [bus debug] ERR: arbitration lost during ready, retry
2022-08-03 17:54:17.955 [bus debug] start request 31
2022-08-03 17:54:17.955 [bus debug] arbitration start with 31
2022-08-03 17:54:18.084 [bus debug] arbitration lost (timed out)
2022-08-03 17:54:18.084 [bus debug] ERR: arbitration lost during ready, retry
2022-08-03 17:54:18.085 [bus debug] start request 31
2022-08-03 17:54:18.085 [bus debug] arbitration start with 31
2022-08-03 17:54:18.142 [update info] received MS cmd: 1050b505023001 / 0101
2022-08-03 17:54:18.142 [update notice] received unknown MS cmd: 1050b505023001 / 0101
2022-08-03 17:54:18.236 [bus debug] arbitration lost (timed out)
2022-08-03 17:54:18.236 [bus debug] notify request: ERR: arbitration lost

I have only this info's in log and I use default valus for latency. But even I try with 120ms latency I got same values.

[john30]

looks as if your adapter can't write to the bus at all. sure you've set up ebusd-esp correctly and also the jumpers on the adapter?

[Koky05]

Sometimes it works (after few restarts), but just like for half of day and then same situation happens. Now I am receiving only broadcast messages like uptime and outdoor temperature. I did not change jumpers, but maybe summer heat has something with it. It is in closed room with heater/boiler so it could by too hot for PCB.

[john30]

@thoro please don't misuse other ones ticket if it is not 100% related, which is not the case due to completely different setup (interface, OS, hardware)

[john30]

@Koky05 I don't think temperature will have such an influence. what are we talking about? 50 degrees or higher?
can you post a raw logging with bytes (--lograwdata=bytes) from a successful arbitration and a non successful?

[Koky05]

Today I try it recreate with lograwdata but have no luck with arbitration all finish as lost. Only broadcast messages works for me. I try restart ebus adapeter and also use controller on my heater during scanning.

Ebusctl info:
version: ebusd 22.4.v22.4-1-g7d8a871
device: 192.168.2.31:9999, enhanced
access: *
signal: acquired
symbol rate: 55
max symbol rate: 93
reconnects: 0
masters: 3
messages: 127
conditional: 4
poll: 0
update: 8
address 03: master #11
address 08: slave #11, scanning
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=F4700;SW=0124;HW=6102"
address 31: master #8, ebusd
address 36: slave #8, ebusd, scanning
address 50: slave, scanned "MF=Vaillant;ID=V6100;SW=0306;HW=1902", loaded "vaillant/50.v61.mc.csv"
ebusd_logs.txt

[john30]

from the logs it looks as if your adapter can't write to the bus at all. please post the jumper settings here as well as the config page of ebusd-esp.

in order to make sure the adapter itslef is able to write, reconfigure it to USB direct mode (i.e. no Wemos sitting on top, J1+J4 set accordingly, connected through USB, jumpered to non-enhanced, ebusd on the host set to use a direct (non-enhanced) USB serial device, and then try again

[Koky05]

Sorry but I don't own movable device to direct connection with ebus. I need to work it wirelessly. Or you know how to connect it to cellphone for test purpouse?

[john30]

I repeat:

please post the jumper settings here as well as the config page of ebusd-esp.

in order to make sure the adapter itslef is able to write, reconfigure it to USB direct mode (i.e. no Wemos sitting on top, J1+J4 set accordingly, connected through USB, jumpered to non-enhanced, ebusd on the host set to use a direct (non-enhanced) USB serial device, and then try again

[Koky05]

I check jumpers and it is setted up to RPi (J1 and J4) WiFi (J12 pins 6 and 7) and Enhanced protocol (J12 pins 9 and 10).
I do not own mobile device (only cell phone) to dierct connection so I can not test it without WiFi.

[john30]

there is no pin 9 or 10 on J12

[Koky05]

My bad. I count it from other side.
So it is on J12 1-2 and 4-5 pins.

[Koky05]

I apply setting recommanded by kalledausb in issue #680 and restart heater and my communication for now working. I am curios for how long. So for now I leave this there open and wait if problem was solved by change of configuration:

starting ebusd with high latency/receivetimeout/acquiretimeout values (80000/10000/20000) and set acquireretries to 10.

[Koky05]

So after 5 days of running it today stoped with same error arbitration lost on all three masters. (15.f47, 50.V61 and 26.f47.2). Only broadcast still working.

[john30]

is the WIFI signal strength good enough?

again, not much more to tell if no logs or further details are provided

[Koky05]

WiFi signal is strength enough.
So only solution will be to catch 5 days detail logs? Because it take that long from normal running to lost arbitration. Maybe som cache problem?

[john30]

do you have the latest version of ebusd-esp (20221105)? if not, please update it.

then paste the output of the log tab from the www UI here when the arbitration lost message is logged

[Koky05]

After upgrade to ebusd-esp (20221105) it looks stabile:

version: ebusd 22.4.v22.4-28-gbc3e611
update check: revision v22.4 available, broadcast.csv: different version available, memory.csv: different version available, vaillant/15.f47.csv: different version available, vaillant/50.v61.mc.csv: different version available, vaillant/bai.0010015600.inc: different version available, vaillant/broadcast.csv: different version available, vaillant/errors.inc: different version available, vaillant/general.csv: different version available, vaillant/hcmode.inc: different version available, vaillant/iotestbmc.inc: different version available, vaillant/scan.csv: different version available, vaillant/tempsetpoints.inc: different version available, vaillant/timercc.inc: different version available, vaillant/timerhc.inc: different version available, vaillant/timerhwc.inc: different version available, vaillant/yield3d43.inc: different version available
device: 192.168.2.31:9999, enhanced
access: *
signal: acquired
symbol rate: 23
max symbol rate: 117
min arbitration micros: 1
max arbitration micros: 53
min symbol latency: 8
max symbol latency: 55
reconnects: 0
masters: 4
messages: 985
conditional: 6
poll: 681
update: 10
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0116;HW=9602", loaded "vaillant/bai.0010015600.inc" ([HW=9602]), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=F4700;SW=0124;HW=6102", loaded "vaillant/15.f47.csv"
address 26: slave, scanned "MF=Vaillant;ID=F4700;SW=0124;HW=6102", loaded "vaillant/26.f47.2.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd, scanning
address 50: slave, scanned "MF=Vaillant;ID=V6100;SW=0306;HW=1902", loaded "vaillant/50.v61.mc.csv"
address f1: master #10
address f6: slave #10, scanned "MF=Vaillant;ID=F4700;SW=0124;HW=6102", loaded "vaillant/f6.f47.3.csv"

[Koky05]

So it is 10 days up and running and no Arbitration lost. Looks like latest ebusd-esp in combination with older firmware and longer timeouts make it works.

[Koky05]

Today it starts again with error. Log from ebus adapter:

10:00:45.8: wifi evt 1
10:00:48.6: wifi evt 8
10:00:50.8: wifi evt 2
10:00:52.9: wifi evt 0
10:00:54.9: check eBUS conn
10:00:55.2: check eBUS conn: 0
10:00:55.2: eBUS >SYN enh
10:00:55.3: skip
10:00:55.3: setup: error=0, wifi=1, ip=1
10:01:00.3: start
10:01:45.1: conn 192.168.2.7:55832
10:02:10.8: disconn
10:02:15.9: conn 192.168.2.7:55866

[gtclub123]

Have the same problem.
Maybe someone can help
s6-rc: info: service s6rc-oneshot-runner: starting
s6-rc: info: service s6rc-oneshot-runner successfully started
s6-rc: info: service fix-attrs: starting
s6-rc: info: service fix-attrs successfully started
s6-rc: info: service legacy-cont-init: starting
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service legacy-services: starting
s6-rc: info: service legacy-services successfully started

ebusd --foreground --mqtthost=core-mosquitto --mqttport=1883 --mqttuser=addons --mqttpass=bool1zoh2maj9roongeing3rohhooPh8eefie4azohyohfei7EephiiVaesehahc --scanconfig --mqttjson --mqttint=/etc/ebusd/mqtt-hassio.cfg --mqtttopic=ebusd --device=/dev/ttyUSB0 --log=all:notice
2023-01-15 00:58:26.395 [main notice] ebusd 23.1.p20230106 started with auto scan on device /dev/ttyUSB0
2023-01-15 00:58:27.922 [bus notice] bus started with own address 31/36
2023-01-15 00:58:27.934 [bus notice] signal acquired
2023-01-15 00:58:28.327 [mqtt notice] connection established
2023-01-15 00:58:42.767 [bus notice] new master 03, master count 2
2023-01-15 00:58:48.826 [main error] scan config 08: ERR: arbitration lost
2023-01-15 00:59:01.224 [main error] scan config 08: ERR: arbitration lost

[gtclub123]

Adapter is eBus Coupler USB by Esera

[thoro]

@gtclub123 Just doesn't work, their adapters have a writing issue, see: #735

You can still get some values with read-only. But I would recommend to get a ebus-adapter v3(.1)

[gtclub123]

Maybe incorect switches?
They write in faq
After you receive data from the eBus coupler, the setting is not entirely wrong and we can rule out a defect in the bus coupler with a high degree of probability.

It can have two causes:

On the configuration of ebusd. The USB interface is configured with ebusd by default with a latency of 0.
When configuring, you must also transfer a higher latency time. Please refer to the ebusd software manual for further details.
Interestingly, ebusd has a default latency of 50ms for ETH applications. We assume that the value 0 is an error. However, you can configure the latency time when starting the service. Please refer to the ebusd documentation for more details.

If you supply the bus coupler via a power pack, depending on the type of power pack, problems may arise if you have not grounded the minus output voltage. In other words, connect the yellow/green connection to the negative side of the power supply.
Disturbances often occur with DIN rail power supplies in particular, since the power supplies are intended for machines in which the negative voltage is always grounded and EMC interference is derived from this.

[gtclub123]

@gtclub123 Just doesn't work, their adapters have a writing issue, see: #735

You can still get some values with read-only. But I would recommend to get a ebus-adapter v3(.1)

I have tryed readonly.
But getting another error.
s6-rc: info: service s6rc-oneshot-runner: starting
s6-rc: info: service s6rc-oneshot-runner successfully started
s6-rc: info: service fix-attrs: starting
s6-rc: info: service fix-attrs successfully started
s6-rc: info: service legacy-cont-init: starting
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service legacy-services: starting
s6-rc: info: service legacy-services successfully started

ebusd --foreground --mqtthost=core-mosquitto --mqttport=1883 --mqttuser=addons --mqttpass=bool1zoh2maj9roongeing3rohhooPh8eefie4azohyohfei7EephiiVaesehahc --readonly --scanconfig --mqttjson --latency=50 --mqttint=/etc/ebusd/mqtt-hassio.cfg --mqtttopic=ebusd --device=/dev/ttyUSB0 --log=all:notice
2023-01-17 16:09:12.786 [main notice] ebusd 23.1.p20230106 started read only with auto scan on device /dev/ttyUSB0
2023-01-17 16:09:14.354 [bus notice] bus started with own address 31/36
2023-01-17 16:09:14.366 [bus notice] signal acquired
2023-01-17 16:09:14.792 [mqtt notice] connection established
2023-01-17 16:09:26.927 [bus notice] new master 03, master count 1
2023-01-17 16:09:34.358 [main error] scan config 08: ERR: element not found

[Koky05]

After some time I start to receive again messige arrbitration lost:
EBUSD on version 23.2-amd64
eBUS adapter v3.0 (WiFi version with D1Mini) with Build 20221215 and FW: 20221231-offset.hex

#eBus Deamon
ebusd:
image: john30/ebusd:latest
container_name: ebusd
depends_on:
- mqtt
#ports:
# - "8888:8888/tcp"
restart: unless-stopped
privileged: true
network_mode: host
environment:
- TZ=Europe/Bratislava
- EBUSD_DEVICE=ens:192.168.2.31:9999
- EBUSD_ARCH=amd64
- EBUSD_SCANCONFIG=full
- EBUSD_CONFIGPATH=/etc/ebusd/ebusd-configuration/ebusd-2.1.x/en
- EBUSD_CONFIGLANG=EN
- EBUSD_LOGAREAS=all
- EBUSD_LOGLEVEL=error
- EBUSD_LATENCY=80000
- EBUSD_ACQUIRETIMEOUT=80000
- EBUSD_RECEIVETIMEOUT=80000
- EBUSD_ACQUIRERETRIES=10
- EBUSD_SENDRETRIES=10
- EBUSD_ACCESSLEVEL=*
- EBUSD_MQTTHOST=${MQTT_HOST}
- EBUSD_MQTTPORT=1883
- EBUSD_MQTTUSER=${MQTT_USER}
- EBUSD_MQTTPASS=${MQTT_PASSWORD}
- EBUSD_MQTTTOPIC=ebusd
- EBUSD_MQTTJSON=
- EBUSD_MQTTINT=/etc/ebusd/mqtt-hassio.cfg
- EBUSD_MQTTVERBOSE=
- EBUSD_MQTTRETAIN=
- EBUSD_MQTTCHANGES=
- EBUSD_LOGFILE=/var/log/ebusd.log
- EBUSD_LOGRAWDATA=
- EBUSD_LOGRAWDATAFILE=/var/log/ebusd_hex.log
volumes:
- "/etc/localtime:/etc/localtime:ro"
- "/volume1/docker/ebusd/data:/data"
- "/volume1/docker/ebusd:/ebusd"
- "/volume1/docker/ebusd/config:/etc/ebusd"
- "/volume1/docker/ebusd/log:/var/log"

eBUS Log:

11:57:04.8: wifi evt 8
11:57:07.6: wifi evt 2
11:57:09.8: wifi evt 0
11:57:11.7: wifi evt 3
11:57:13.7: check eBUS conn
11:57:14.0: check eBUS conn: 0
11:57:14.0: eBUS >SYN enh
11:57:14.1: skip
11:57:14.1: skip first 1
11:57:14.1: setup: error=0, wifi=1, ip=1
11:57:19.1: start
11:57:22.6: conn 192.168.2.7:37844

_ebusd_logs.txt
ebusd_hex.log

[john30]

probably related to wifi issues. if not, then it might be an issue with ESP firmware, thus wrong repo (use https://github.com/john30/ebusd-esp/ instead)

[Koky05]

It worked for two or more months without any issue and yes I use ESP FW from mentioned repo. Also I load new PIC FW it works for two days and then it again send only arbitration lost.