enhance slave mode

[Giermann]

Recent use cases reminded me that it's sometimes useful to separate 1 ebus into 2, which might require to emulate one or more clients. It would be very handy if ebusd would support a slave device mode with the capability to define a set of supported messages and their answer, that ebusd should send.

Maybe that's a too complex enhancement and should be done in a separate project, but I don't know any other projects dealing with ebus. Maybe ebusd could simply provide a method to interfere bus messages?
Or some library mode to use from other scripts or programs?
Then it could just hand over all messages to some "plug in", which is then able to respond via ebusd?

[john30]

this is already supported up to the point where ebusd has to answer to queries from another participant. here the new constant value fields come in handy but variables and a store of variable values might be needed as well.

[Giermann]

Ah, okay - I didn't get the sense of #39 as there's not much explanation.
But yes, I could imagine using the normal cache of ebusd - so defining a read/write constant value field would enable to issue an "ebusctl w ConstantValueField 13" to set the value to respond to readings from bus...

[john30]

the idea of the variables is somewhat different, i.e. the definition in CSV would allow for using "=$variable" instead of a constant value as referred to by #39, and then ebusd would be able to answer those from the internal variables. of course there would also need to be a command allowing to change those variables.

[john30]

add option to define file for own config

[lildadou]

Could you document how to configure the ebusd slave responses?

Edit: I've found my answer
https://github.com/john30/ebusd/wiki/3.1.-TCP-client-commands#answer

[lildadou]

@john30 If I understand the ebusd source code correctly, the response is returned by ebusd just after receiving the CRC byte from the master (and provided that getAnswer has found a response).

Even counting the time to receive the SYN byte and neglecting CPU time, the first byte of the response would have to arrive at the adapter in less than 0.5ms; an eternity compared to my 3ms network latency.

So I'd like to know whether the response mode will also work with an adapter contacted via Ethernet.

[john30]

I don't really get your point, what exactly do you expect/want to know?

[lildadou]

Will the answer functionality of ebusd work if my ebus adapter is connected via WiFi (or Ethernet cable)?
(My previous post set out my concerns about latency)

[john30]

it is not related to the underlying hardware being used as it is an ebusd feature

[lildadou]

I understood that this was a feature of ebusd but I didn't understand how it could work if my ebusd was 3ms away from the ebus adapter.
If my concerns don't make sense to you then I may have misunderstood something important about how ebusd or ebus works.

[john30]

an addressed device is allowed to answer within 20ms iirc, so a latency below 10ms is fine. the tricky part is the arbitration of the sender that has to be done with an accuracy of around 100 us (microseconds indeed) which is impossible when done in user space from a host. that's why we developed the various adapters with logic on it (ESP32C3 or formerly PIC)