ebusctl listen immediately stops when any parameter is supplied.

[thomaskilian]

Description

Normal output here:

2ad9b828-ebusd:/# ebusctl  listen
listen started

sc Act = 1;BrennerAus;1;1;1;0;0;0;0;0;0;Summer;0;0;0;0;0;Heating;0;48.0;66.0;65.0;0.0;32;27.133;8

works fine. But

2ad9b828-ebusd:/# ebusctl  listen -U
listen started

2ad9b828-ebusd:/# 

any option supplied just stops with no output.

Here's the info-part:

2ad9b828-ebusd:/# ebusctl  info
version: ebusd 23.2.p20230716
update check: version 23.3 available
device: 192.168.2.136:9999, enhanced, firmware 1.1[460f].1[460f]
access: *
signal: acquired
symbol rate: 57
max symbol rate: 129
min 
```arbitration micros: 13
max arbitration micros: 1936
min symbol latency: 1
max symbol latency: 55
scan: finished
reconnects: 0
masters: 7
messages: 731
conditional: 0
poll: 56
update: 7
address 00: master #1
address 03: master #11
address 08: slave #11, scanned "MF=Kromschroeder;ID=W ;SW=0215;HW=0101", loaded "kromschroeder/08..sc.csv"
address 30: master #3
address 31: master #8, ebusd
address 35: slave #3, scanned "MF=Kromschroeder;ID=W ;SW=2634;HW=0000", loaded "kromschroeder/35..hc1.csv"
address 36: slave #8, ebusd, scanning
address 51: slave, scanned "MF=Kromschroeder;ID=W ;SW=3234;HW=0001", loaded "kromschroeder/51..hc2.csv"
address 52: slave, scanned "MF=Kromschroeder;ID=W ;SW=3234;HW=0001"
address 70: master #4
address 75: slave #4, scanned "MF=Kromschroeder;ID=W ;SW=2634;HW=0000", loaded "kromschroeder/75..hc2.csv"
address f0: master #5
address f1: master #10
address f5: slave #5, scanned "MF=Kromschroeder;ID=W ;SW=3234;HW=0001", loaded "kromschroeder/f5..hc3.csv"
address f6: slave #10, scanned "MF=Kromschroeder;ID=WWST?;SW=0215;HW=0101", loaded "kromschroeder/f6..sc.csv"

### Actual behavior

see above

### Expected behavior

see above

### ebusd version

23.3

### ebusd arguments

ebusd on HA v 23.2.5

### Operating system

other

### CPU architecture

arm64

### Dockerized

same as ebusd version

### Hardware interface

Adapter Shield v5 via WiFi

### Related integration

MQTT Home Assistant via mqtt-hassio.cfg

### Logs

2024-06-27 17:13:49.226 [bus notice] <70f105070955ffd0000080ffffffae00
2024-06-27 17:13:49.306 [update info] received MM cmd: f0f10507095503d0000080ffffff
2024-06-27 17:13:49.308 [update notice] received update-read hc3 Set: hotwater;stopconsumer;13.00;-;-;-;-
2024-06-27 17:13:49.310 [bus notice] <f0f10507095503d0000080ffffff8100
2024-06-27 17:13:49.453 [update info] received MS cmd: 7051501004661c0280 / 091a1030201b20200000
2024-06-27 17:13:49.456 [update notice] received update-read hc2 Act QQ=70: 28.398;Program;128;13.0;8.0;24.0;32;27;hotwater;32;0;0
2024-06-27 17:13:49.499 [bus notice] <7051501004661c0280e500091a1030201b20200000b500
2024-06-27 17:13:53.009 [bus info] poll cmd: 3108500003c112c9
2024-06-27 17:13:53.160 [update info] sent MS cmd: 3108500003c112c9 / 03000100
2024-06-27 17:13:53.162 [update notice] sent poll-read sc DHWSensorDefective QQ=31: 1
2024-06-27 17:13:53.162 [bus notice] >3108500003c112c94a<000300010079>00
2024-06-27 17:13:56.039 [update info] received MM cmd: 30f1050709550480000080ff65ff
2024-06-27 17:13:56.042 [update notice] received update-read hc1 Set: hotwater;startconsumer;8.00;-;-;50.5;-
2024-06-27 17:13:56.044 [bus notice] <30f1050709550480000080ff65ff0400
2024-06-27 17:13:56.132 [update info] received BC cmd: 30fe09030476009402
2024-06-27 17:13:56.134 [update notice] received update-read hc1 BCAST1: 660
2024-06-27 17:13:56.139 [bus notice] <30fe090304760094026b
2024-06-27 17:13:58.032 [update info] received BC cmd: 30fe090304780018fc

etc, but that's not an issue here

[gasman1844]

I got listen -u to work by starting listen without any parameter and then adding the parameter after it's started, as follows

~ $  ebusctl listen 
listen started

broadcast vdatetime = 15:24:13;29.06.2024
listen -u
listen continued

1076b5110101 09ffff0080ff6d0000ff
1076b512030f0001 076d03000080ff03
1076b51009000000ffffff050000 0101
0376b51206130019000006 0200ff

[thomaskilian]

Ah, thanks for the tip! I'll try that later then :-) If that's intended behavior it should be documented that way. Otherwise (according to the help's suggestion) I'd consider this a bug. And I might be able to adapt the help, I guess)

P.S. yes, that worked and I now can see the not decoded messages which presumably com from my solar controller.