enhance slave mode about ebusd HOT 11 OPEN

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.

from ebusd.

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...

from ebusd.

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.

from ebusd.

add option to define file for own config

from ebusd.

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

from ebusd.

@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.

from ebusd.

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

from ebusd.

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)

from ebusd.

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

from ebusd.

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.

from ebusd.

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)

from ebusd.