Ebusd query timeout

[ronan-fontenay]

Hi,

Short description of the issue :
Query seems to timeout, master is well identified (Thermaplus Boiler) but unable to find any (scanned elements).

Software :
$dpkg -l | grep ebusd

ii ebusd 3.0 amd64 eBUS daemon.
ii ebusd-configuration 2.1.b143f39-en all

OS :
$uname -a

Linux ThinkPad-T410 4.10.0-28-generic #32-Ubuntu SMP Fri Jun 30 05:32:18 UTC 2017 x86_64 >x86_64 x86_64 GNU/Linux

Ebusd feedback:
$sudo ebusd --scanconfig -f

2017-11-12 12:37:01.862 [main notice] ebusd 3.0.595c7c0 started
2017-11-12 12:37:01.865 [bus notice] bus started with own address 31/36
2017-11-12 12:37:01.885 [bus notice] signal acquired
2017-11-12 12:37:11.866 [main notice] starting initial broadcast scan
2017-11-12 12:37:11.917 [bus error] send to fe: ERR: read timeout, retry
2017-11-12 12:37:11.960 [bus error] send to fe: ERR: read timeout, retry
2017-11-12 12:37:12.003 [bus error] send to fe: ERR: read timeout, retry
2017-11-12 12:37:12.046 [bus error] send to fe: ERR: read timeout
2017-11-12 12:37:12.046 [main error] initial scan failed: ERR: read timeout
2017-11-12 12:38:40.790 [bus notice] new master 03, master count 2
2017-11-12 12:38:42.057 [main error] scan config 08: ERR: read timeout
2017-11-12 12:40:44.159 [main notice] update check: revision v3.0 available, broadcast.csv: newer version available, memory.csv: different version available

Ebus state :
ebusctl state

signal acquired, 23 symbols/sec (29 max), 2 masters

Ebus info :
ebusctl info

version: ebusd 3.0.595c7c0
signal: acquired
symbol rate: 19
max symbol rate: 29
reconnects: 0
masters: 2
messages: 71
conditional: 10
poll: 0
update: 4
address 03: master #11
address 31: master #8, ebusd
address 36: slave #8, ebusd

I've tried the following with no success :
$sudo setserial /dev/ttyUSB0 low_latency
As mentionned in Issue79

$ebusd -f -c /tmp --logareas bus --loglevel info --lograwdata=bytes -d /dev/ttyUSB0
Is returning <aa reliably.

I'm new with Ebusd, hope I didn't miss something. However, thanks for the great (and huge) job done here !

Ronan

[john30]

first of all: there are no configuration files available for your device, so you'll have to let ebusd listen to what's going on on the bus and then try to decode that stuff yourself, which is a rather hard and painful job.
Regarding the missing identification: some devices are known to not respond to the identification message, so that might not even be a problem. Anyway, you might want to add some extra latency in case the device is just responding slower than actually allowed by using --receivetimeout with a value higher than the default 25000 usec.
after that, you can try to initiate a manaul scan using "ebusctl scan" and check a little bit later, if that worked with "ebusdctl scan result".

[ronan-fontenay]

Thank's for the feedback. At least, I'm on the right way 👍

A quick grab result done tonight :

$ebusctl grab result
1008b5040100 / 0a00ffffffffffffff0080 = 53
1008b5070108 / 026400 = 27
1008b5110101 / 0942410080ff6d0000ff = 159
1008b5110102 / 050214824c78 = 53
10feb516080012382317110517 = 27
1008b512020000 / 00 = 26
1008b51302050a / 0101 = 3
1008b510090000006effff010100 / 0101 = 159`

It might be very close to the #46.

John, do you mind if I follow up on this thread for this subject of what do you prefer ?

[john30]

at least you have a vaillant device, so some of the generic definitions (those in *.inc files) are most probably valid. I'd prefer if you open a new issue here https://github.com/john30/ebusd-configuration/issues as this repo is for development of the daemon itself, not the configuration files. please also post a scan result and an info result there to identify the device.
since you get messages now, i guess this timeout issue is no longer open, right?

[ronan-fontenay]

You're right, let's close. I'll grab data, analyze and then open a issue there to follow up.

Thanks again !