Only get "signal lost" once

[jvanoosterhout]

Dear John and others,

Great job building such a versatile ebus deamon, though I have some trouble getting it started.

Hardware:

• eBUS Adapter Shield v5 connected via USB
• Raspbery pi 4 (1gb ram)
• Brink Renovent Excellent 400 plus (irrelevant for now, found several configuration files though did nog start using them as the basics do not seem to work)
  • ebus is working and tested as I have a working Brink Air Control unit connected to the bus.

Software:

• Pi operating System: fresh installed and updated Debian GNU/Linux 12 (bookworm arm64)
• ebusd
  • 23.3.23.3-94-g254517f9 (build from source, 🙈 I noticed too late I could just install a release version)
    • command: ebusd -f -d /dev/ttyACM0 --httpport=8889 --accesslevel=* --latency=60 --loglevel=debug -c /home/jeroenvanoosterhout/Workspace/Domotica/MV/mvconfig
  • lates build in Docker
    • command: docker run -it --rm --device=/dev/ttyACM0 -p 8888 john30/ebusd -d ens:/dev/ttyACM0 --httpport=8887 --loglevel=debug
• ebus firmware
  • 2024-10-08
  • 2024-08-25 (I noticed "massively changed USB serial driver" in the changelog for the 10-08 version, and thus also tried this version)

Behavior:
The green light of the ebus adapter V5 flashes frequently suggesting it receives data from mv MV. Though no matter hou I start the ebusd (normal or Docker) or disregard the firmware, it prints one time these "final" lines:

2024-10-20 11:42:02.361 [bus notice] bus started with own address 31/36
2024-10-20 11:42:02.362 [bus notice] signal acquired
2024-10-20 11:42:04.010 [bus debug] ERR: read timeout during skip, switching to no signal
2024-10-20 11:42:04.010 [bus error] signal lost
2024-10-20 11:42:12.362 [main debug] performing regular tasks

The last line is repeated over time and every now and then the [network debug] prints a lot of lines. In case only ctrl+c and repeat the command, it only prints "bus started with own address 31/36." and then starts repeating "performing regular tasks". I need to reconnect the USB in order to get "signal acquired" again.

Additional information:
from ebusctl info I get (normal way only, running from docker gives "error connecting to localhost:8888". yes, I do not understand docker although I am familiar with its concept, probably I have to define the endpoint to the outside world, the two installation conflict or something like that):
version: ebusd 23.3.23.3-94-g254517f9
device: /dev/ttyACM0, serial
access: *
signal: no signal
reconnects: 0
masters: 1
messages: 145
conditional: 0
poll: 0
update: 0
address 31: master #8, ebusd
address 36: slave #8, ebusd

Further, I played some with the --accesslevel and --latency. As I knew from an previous project with seral data over USB I even set "sudo chmod 777 /dev/ttyACM0" to be sure everything and everyone could write and execute on the device. I also disconnected the Brink Air Control unit.

This behavior seems very different from other posts/repositories of brink or other devices, I would appreciate any help.

Jeroen

Update:

Maybe I did not searched well enough though the discussions. I just found this post (#1289 (comment)) which seems similar. I did not change any setting on the ebus adapter, meaning it might not be on the serial setting. As such I think this needs checking first.

I also found an other post about the version being set wrong on the adapter (#774 (comment)) I will check that as well, although I noticed a difference with my situation that the ebusctl prints “signal: acquired” instead of “ signal: no signal” in my case.

[jvanoosterhout]

😅 It was indeed changing the ebus to output via serial. The awkward thing is, I did found the setting while configuring/exploring the adapter the first time. Though I remember I could not find any information on the meaning of the setting or the need to change them (and I still cannot find it). As I did not want to risk potentially losing acces via the accespoint, I did not change the setting.

@john30: Two suggestions to improve 1) This might not be the right place to suggest this though, please consider updating the https://adapter.ebusd.eu/v5/steps.en.html page with something like: "De default output of the adapter is over WIFI, when using USB, RPI or ethernet ouput, configure this in ... [web page http://192.168.4.1 or easi>]"
2) The "[bus notice] signal acquired" seems misleading or potentially wrong as (to me) it suggest the adapter received a signal. As the ebus adapter was not configured correctly there could not have been a signal over usb to the demon in the first place suggesting the daemon could not have known there was a signal.