The documentation carries a warning about the timing of requests:
define an appropriate value of update_interval for each of them. Otherwise the default update interval of 10 seconds will be used which can lead to unprocessed read and write requests.
However there is no hint about how the defined requests will get ordered for processing.
I note a couple of values missing and the log has no hint about that they ever are requested (and might have failed). I would expect that requests with a longer update_interval would get priority over more frequent ones, as missing a frequent one will quickly get another chance, whereas a sensor with longer break will eventually never get fetched at all.
Maybe they really get requested but get an error in reply. I could not make up any hint about such in the logs either, not even in very_detailled.
If requests get dumped, they should not get dumped in every loop. Each one should get a fair chance. Either keep it for filling a communication gap or swap it against one that is re-scheduled quickly anyway.
I opt for at least a logging output, when a request is due but cannot placed into the queue.
If the requests are ordered right after reading the config file and then processed top down, until the next loop, then it would be helpful to get this list dumped in the log, so we might recognize, when it gets too long and what requests likely will get dumped - the ones on the bottom of the list.
Unfortunately the Viessman documentation about valid datapoints and their proper request is very incomplete. It needs a lot of try and error, requesting data on suspicion and see what happens.
... it would be extremely helpful to have a possibility to request a datapoint on the fly, like with a web form or terminal command.
The documentation carries a warning about the timing of requests:
However there is no hint about how the defined requests will get ordered for processing.
I note a couple of values missing and the log has no hint about that they ever are requested (and might have failed). I would expect that requests with a longer
update_intervalwould get priority over more frequent ones, as missing a frequent one will quickly get another chance, whereas a sensor with longer break will eventually never get fetched at all.Maybe they really get requested but get an error in reply. I could not make up any hint about such in the logs either, not even in
very_detailled.If requests get dumped, they should not get dumped in every loop. Each one should get a fair chance. Either keep it for filling a communication gap or swap it against one that is re-scheduled quickly anyway.
I opt for at least a logging output, when a request is due but cannot placed into the queue.
If the requests are ordered right after reading the config file and then processed top down, until the next loop, then it would be helpful to get this list dumped in the log, so we might recognize, when it gets too long and what requests likely will get dumped - the ones on the bottom of the list.
Unfortunately the Viessman documentation about valid datapoints and their proper request is very incomplete. It needs a lot of try and error, requesting data on suspicion and see what happens.
... it would be extremely helpful to have a possibility to request a datapoint on the fly, like with a web form or terminal command.