invalid address if not default (conflict issue)

[eh-gh]

Description

Hi

I was not able to setup a remote control for wolf heater using ebusd (adapter 3.1), therefore I bought the official module ISM8.
I'm able to control the system using ISM8I and my goal is now to find out, what ebus messages are sent with ISM8.

Current setup: CGB-2, MM-2, BM-2, ISM8, ebusd adapter 3.1

Actual behavior

Without changing the ebusd address I got a conflict on address 31

root@rpi3-2:/home/pi/repos# ebusctl i version: ebusd 23.2.23.2-50-gef8be013 update check: revision 23.2 available device: /dev/ttyUSB0, enhanced high speed access: * signal: acquired symbol rate: 41 max symbol rate: 148 min arbitration micros: 5 max arbitration micros: 53 min symbol latency: 7 max symbol latency: 8 scan: finished reconnects: 0 masters: 5 messages: 8 conditional: 0 poll: 0 update: 0 address 03: master #11 address 08: slave #11, scanned "MF=Wolf;ID= !;SW=8000;HW=0000" address 30: master #3 address 31: master #8, ebusd, conflict address 35: slave #3, scanned "MF=Wolf;ID=;SW=0204;HW=0100" address 36: slave #8, ebusd, scanning address 51: slave, scanned "MF=Kromschroeder;ID= ;SW=0100;HW=-" address 70: master #4 address 75: slave #4, scanned "MF=Kromschroeder;ID= ;SW=0100;HW=-" address 85: slave, scanning address f1: master #10

if I set address like --address=32 or --address=0x20 or --address=0x32, I got the error message:
invalid address
2023-11-02 08:26:34.605 [main error] invalid arguments

if I set --address=31 (the default) it works fine

Expected behavior

I would like to set the address in order to avoid the conflict

ebusd version

current source from git

ebusd arguments

--scanconfig --address=32 --device=ens:/dev/ttyUSB0 --latency=50 --port=8888 --enablehex --enabledefine --configpath=/home/pi/repos/ebusd-configuration/ebusd-2.x.x/de/wolf --accesslevel=* --lograwdata --logfile=/var/log/ebusd.log --lograwdatafile=/var/log/ebusd_raw.log --log=all:debug

Operating system

Debian 12 (Bookworm) / Ubuntu 22-23 / Raspberry Pi OS 12 (including lite)

CPU architecture

arm64

Dockerized

None

Hardware interface

adapter 3.1 USB

Related integration

other

Logs

invalid address
2023-11-02 08:26:34.605 [main error] invalid arguments

[eh-gh]

fyi:

with --address=0x1f or with --address=0x33, it works fine like:

root@rpi3-2:/home/pi/repos# ebusctl i
version: ebusd 23.2.23.2-50-gef8be013
update check: revision 23.2 available
device: /dev/ttyUSB0, enhanced high speed
access: *
signal: acquired
symbol rate: 57
max symbol rate: 144
min arbitration micros: 5
max arbitration micros: 13
min symbol latency: 7
max symbol latency: 10
scan: finished
reconnects: 0
masters: 6
messages: 8
conditional: 0
poll: 0
update: 0
address 03: master #11
address 08: slave #11, scanned "MF=Wolf;ID= !;SW=8000;HW=0000"
address 30: master #3
address 31: master #8
address 33: master #13, ebusd
address 35: slave #3, scanned "MF=Wolf;ID=;SW=0204;HW=0100"
address 38: slave #13, ebusd
address 51: slave, scanned "MF=Kromschroeder;ID= ;SW=0100;HW=-"
address 70: master #4
address 75: slave #4, scanned "MF=Kromschroeder;ID= ;SW=0100;HW=-"
address 85: slave, scanning
address f1: master #10

[john30]

of course, if another participant uses the address, there will be aconflict. that's why ebusd has the "-a" option in the first place

[eh-gh]

Hi John,

maybe it was not clear enough: the --address=0x32 is not possible to specify even if there is no device reported to have this address.
I think it is easy to reproduce:

root@rpi3-2:/home/pi# /usr/bin/ebusd -f --address=0x32 --device=ens:/dev/ttyUSB0
invalid address
2023-11-05 12:46:00.984 [main error] invalid arguments

root@rpi3-2:/home/pi# /usr/bin/ebusd -f --address=0x33 --device=ens:/dev/ttyUSB0
2023-11-05 12:46:07.114 [bus notice] device status: resetting
2023-11-05 12:46:07.114 [main notice] ebusd 23.2.23.2-50-gef8be013 started with broadcast scan on device: /dev/ttyUSB0, enhanced high speed
2023-11-05 12:46:07.950 [bus notice] bus started with own address 33/38
2023-11-05 12:46:07.950 [bus notice] signal acquired
2023-11-05 12:46:07.950 [bus notice] new master 30, master count 2
2023-11-05 12:46:07.951 [bus notice] device status: reset, supports info
2023-11-05 12:46:07.951 [bus notice] new master 03, master count 3
2023-11-05 12:46:07.951 [update notice] received unknown MM cmd: 3003502203cc0100
2023-11-05 12:46:08.020 [bus notice] device status: extra info: firmware 1.1[8419].2[73c8], jumpers 0x13

tnx
eh

[john30]

thats because it is not a valid master address

[eh-gh]

Hi John,

Tnx. I appreciate your additional comment.
br
eh