search

john30 / ebusd

daemon for communication with eBUS heating systems
GNU General Public License v3.0
560 stars 130 forks source link

Conditions/Polling #145

Closed rellla closed 5 years ago

rellla commented 6 years ago

Hi, does defining a condition in the csv automatically mean, that evaluating the condition is solved by polling with the defined interval? https://github.com/rellla/ebusd-configuration/blob/WIP_bartl/ebusd-2.1.x/de/bartl_tem/bartl.csv#L9 are my conditions which need to execute https://github.com/rellla/ebusd-configuration/blob/WIP_bartl/ebusd-2.1.x/de/bartl_tem/bartl.csv#L6 in order to be evaluated.

Now, sometimes get a read timeout with that poll: Here is the log: https://gist.github.com/rellla/bbf3a53a5947a113014cb0949b553224

Having that condition is necessary, because this is the only way i currently can think of, how to differentiate between expert- and userlevel parameters. IDs depend on the currently set parameterlevel. Sadly a same ID can be a different command, so omitting the [*] condition prefixes lead to duplicaty ID errors...

So my questions:

I'm referencing https://forum.fhem.de/index.php/topic,29737.msg720195.html#msg720195, which should be a result of the timeouts...

Thanks rellla

john30 commented 6 years ago

yes, having a condition uses the polling mechanism to resolve the condition value. It is resolved in lowest priority though, so any other message with polling enabled (e.g. by using "r1" as the type in the CSV) will be queried with higher priority i.e. more often than those imposed by conditions. Regarding your CSV: I don't think there is a better way of doing this than by conditions. The read timeouts shouldn't impose any problem, as the conditions will be kept if the message runs into a timeout. There is no means of setting the interval for conditions right now.

rellla commented 6 years ago

Ok thanks. So then I'll stay with the conditions' concept.

What could be possible reasons for such timeouts? And is there a way to increase the timeout value? I tried setting "--receivetimeout=200000", but i'm not sure, if this is the related parameter because it seems to have no effect...

EDIT: Fyi i changed the upper range value in ebusd code to 200000 first and built it myself ...

john30 commented 6 years ago

such a receive timeout is way beyond what the specification allows, thats why it is limited to 200ms in ebusd. furthermore, this is only the time in which an addressed slave is expected to answer. your timeout is another issue. it seems the addressed device is not willing to answer at all to the request. I can't tell you why though.

rellla commented 6 years ago

thanks again. one last question though:

i assume it wouldn't be easily possible to implement some retrying mechanism like https://github.com/john30/ebusd/blob/master/src/ebusd/bushandler.cpp#L334 into the bushandler routines. i ask that, because from my users side of view, the polling is just a normal send to the addressed device. though for now i think i can ignore this issue.

at first i have find out, if my problems here: https://forum.fhem.de/index.php/topic,29737.msg719884.html#msg719884 and https://forum.fhem.de/index.php/topic,29737.msg720195.html#msg720195 have to do with the [condition] polling at all.

and in the meantime i will try to understand the code, especially BusHandler::handleSymbol() ;)

rellla

john30 commented 6 years ago

for the polled messages it is not desired to use a retry mechanism, as those are repeated anyway... but this could be added as an extra commandline parameter I guess