Queue monitoring

[abuisine]

This is a feature request:

It would be interesting to be able to monitor the "load" of the messages queue, in order to adjust update_interval settings. It is particularly difficult to assess when the queue might be overloaded, thus a value being graphed (for instance in HomeAssistant) would be nice.

A gauge of the size of the queue, or a counter of the queue being full events would greatly help in that regard.

[adorobis]

Not sure if this should be requested as a separate issue but my observation is that the requests are sent too often, therefore the boiler does not have enough time/capacity to respond. Even if the frequency is not high, some requests are lost due to the fact that all of them are sent at the same time or in very short timeframe. This should be more sequential I think (if I understand the way it works now).

[adorobis]

BTW, I guess this feature nor the queue mechanism might not get implemented before this platform is official on esphome, so I'd suggest to include relevant section in the documentation. I can propose a content, @j0ta29 please let me know where I should do it. Should I propose a change directly in your repo for the esphome-doc (https://github.com/j0ta29/esphome-docs)?

[j0ta29]

@abuisine , requests in the queue from ESP to the Viessmann device come (and go) very quickly. Though the bandwidth between the systems is 4800 baud, the "load" in the queue will change very fast within a second. I doubt that this fast changing value can be sent to Home Assistant in a adequate speed. What do think about a binary_sensor "overload" (with a hysteresis behavior) that will be send to HA every few seconds? Nevertheless, currently I do not have access to the queue and its current load as it is implemented within the VitoWiFi library. As @bertmelis stated, he plans to outsource the queue management out of the VitoWiFi library to the client (which is in our case the ESP optolink component). If that happens we can discover a queue overload and implement this sensor.

@adorobis , you are totally right with your assumption, that the traffic of request have the same behavior as the rush hour on our streets every morning and evening (That's the reason I drive to work after 9 o'clock ;-)). The current mechanism to smooth out this peaks is the queue within the VitoWifi library. From this queue the request are sent sequentially to the Viessmann device. I have no idea how to make this "more sequential" except to increase the queue size. Unfortunately, the size of the queue cannot be changed by the optolink component. So we end here at the same point: Queue management has to be implemented (or at least be controlled) in the optolink component.

[j0ta29]

BTW, I guess this feature nor the queue mechanism might not get implemented before this platform is official on esphome, so I'd suggest to include relevant section in the documentation. I can propose a content, @j0ta29 please let me know where I should do it. Should I propose a change directly in your repo for the esphome-doc (https://github.com/j0ta29/esphome-docs)? @adorobis , thank you very much for this offer which I totally appreciate. If you like to deep dive in ESPHome doku, feel free to fork the repo and create a pull request. Here the guys from ESPHome describes the process: https://esphome.io/guides/contributing.html?highlight=contribute. Or just send me a snipped of text.

[adorobis]

I think I'll be able to edit it only once the optolink documentation is merged with esphome. Can't see it there yet to be edited.

[j0ta29]

You have to create the fork from https://github.com/j0ta29/esphome-docs (my fork), not from https://github.com/esphome/esphome-docs (official ESPHome)

[bertmelis]

I'll create/adjust the (backwards compatible) methods in VitoWiFi for this to be possible.

One word of explanation though: the queue in V1 of VitoWiFi doesn't have a real hardcoded size. The maximum size is twice the number of datapoints defined. This was done with the idea that the maximum amount of requests equals to "each datapoint reading each datapoint writing".

I'll have VitoWiFi return bool when reading or writing individual datapoints.

[adorobis]

You have to create the fork from https://github.com/j0ta29/esphome-docs (my fork), not from https://github.com/esphome/esphome-docs (official ESPHome)

Thanks! I've submitted a pull request for this and for dealing with negative values.

[abuisine]

What do think about a binary_sensor "overload" (with a hysteresis behavior) that will be send to HA every few seconds? Nevertheless, currently I do not have access to the queue and its current load as it is implemented within the VitoWiFi library. As @bertmelis stated, he plans to outsource the queue management out of the VitoWiFi library to the client (which is in our case the ESP optolink component). If that happens we can discover a queue overload and implement this sensor.

Let me precise the idea I have in mind:

• the bandwidth in terms of updates is limited
• a typical user of this project will most probably overload the bus with requests
• update_intervals can not be left with their default values with no information whatsoever about the bus being overloaded
  • because it silently adds delay to any value being monitored
  • and it silently discards some requests (which is quite problematic when turning on or off some registers)

I feel that we need a pretty precise statistic about the bus being overloaded. Not just a boolean saying that there might have been an overload within the last 5 minutes.

The important part to me : in order to adjust update_intervals, I need a feedback loop, I need to understand if the overload is massive, or rare. And I therefore can confirm that my update_intervals configuration is reasonable from a bus bandwitdh standpoint ... or not.

I got this feeling that keeping track of all "full queue" events (in the actual vitowifi implementation) within a counter, would help me derive this information and produce a pretty precise graph about the potential saturation of the bus. But I might be wrong :)

[bertmelis]

size_t VitoWiFi::queueSize() const; was added too. I'll publish a new version to platformio later. Changes are not yet merged.

[j0ta29]

@bertmelis , will queueSize() return the size of queue or the current load?

[bertmelis]

As the name suggests, the size of the queue. What is your definition of the current load?

[j0ta29]

My definition of "load" was the number of entries in the queue and "size" the maximum numbers of entries. But such a thing does not exist in STL queues (as far a I understand). Totally accepted: "size" is the correct terminology.