search

rvdbreemen / OTGW-firmware

A ESP8266 devkit firmware for the Nodoshop version of the Opentherm Gateway (OTGW)
MIT License
144 stars 34 forks source link

MQTT publishing intervals #30

Open renehonig opened 3 years ago

renehonig commented 3 years ago

@rvdbreemen et. al., thanks a lot for your efforts on this nice project, much appreciated!

In the current setup values are published to the MQTT server at a pretty high frequency (multiple times/sec). This is nice for debugging, but puts quite some load on the system and is probably not really necessary for most users. Would it be an idea to set a publishing interval on the data (e.g. every 30 secs) and maybe have a debugging mode for publishing values like otmessage?

Unrelated, but maybe of interest: there is an excellent and very mature project that has comparable functionality for the Bosch (and related brands like Nefit) EMS bus. It might be beneficial to talk to @proddy, the creator of that one to compare notes.

rvdbreemen commented 3 years ago

@ReneHonig the MQTT topics are generated based on the incoming OT message, they are publish as they come in. Some msg translate in multiple updates (like the status message). The frequency of those message I do not control at this point. I understand what you are asking for, a "rate limited" publishing. However this would change the 'realtime' nature of the current design. A 'flame' status could be there for less than the interval you set, or, stay a lot longer than that.

The publishing of the otmessage I could make optional, I agree on that btw. The reason I added it, is simply because the original OTmonitor app (by Bron Schelte) had that same function. I wondered if anyone would even do something with it, it is very usefull for recording the incoming OT msg stream however. Making that optional would be something I would consider.

Recap:

For the related project, thanks for the link. Will look at it.

rvdbreemen commented 3 years ago

I played around with pushing on change model. Thanks to Sjors for putting it in my head to try. But I am running into a wall. The publishing of topics only on change will not work in the end, as you could have setpoints that would only be published once.

For now I don't see the value of intervals or the push-on-change only, as the sideeffects are not things you want.

If you don't want to topics, then don't subscribe to them. If you need sensors not to appear in Homeassistant you can simple delete the sensors from the mqqtha.cfg file. Just the delete the sensors you do not need. That simple.

The otmsg setting is added to the current dev branch, and will come along with the next relese.

renehonig commented 3 years ago

Maybe interesting to look at the EMS-ESP approach to this. The project differentiates between 'outbound data' and 'sending commands' and you can set publishing intervals for the different 'devices', where 0 sec is 'publish on change'. This is the relevant documentation.

Understand this may not be a priority, but thought it would be worthwhile to share the approach they landed at after a number of iterations and discussions.

rvdbreemen commented 3 years ago

@ReneHonig thanks for the links. Looks interesting indeed, it's definitly something to investigate. Also it seems to the project is very simlar to what I am trying to do, it's for the EMS bus, so I have to investigate.

I can look at what he did, and then reconsider the solution I take.

bluewalk commented 2 years ago

@rvdbreemen I am seeing loads of publishes to topics like otgw/value/otgw-XXX/ch_enable, otgw/value/otgw-XXX/centralheating etc with the same value over and over.

Would it be possible to add a little if statement comparing the new value with the old value and only publish when the value changes?

Reason I'm asking is that software using these topics get flooded with the same value multiple times a second.

rvdbreemen commented 2 years ago

@bluewalk wat software are you using? The topic seem to come from the OTmonitor software and not from the ESP firmware. I am correct?

rvdbreemen commented 2 years ago

Rereading your request. Your suggestion has been asked before. The topic is frequently updated because the status is send frequently. What is the reason this might be a problem for you?

bluewalk commented 2 years ago

Rereading your request. Your suggestion has been asked before. The topic is frequently updated because the status is send frequently. What is the reason this might be a problem for you?

At the moment it's flooding logs of my domotics and updating the value in my domotics with the same value seems unnecessary and redundant (beetje onnodig). Aside from flooding the MQTT server but it's supposed to be able to handle that though.

rvdbreemen commented 2 years ago

I'll reconsider this for a future release. It was already back on the backlog "todo" I just noticed.

bluewalk commented 2 years ago

Great, thanks! If I have time I might have a look and create a PR 👍 Seems like there's no logic for storing the values at the moment.

rvdbreemen commented 2 years ago

If you have some time to spent then a PR is more than welcome.

Actually there is a data model for all values of OpenTherm. I even have an old branch for publish on change logic. I really need to refactor that code.

bluewalk commented 2 years ago

I did a quick hack of adding a check to each is_value_valid in the print functions to compare value to either _value or OTdata.u16() which seems to work. It ain't pretty but functions for now.

Looking forward to your refactored code regarding sending the MQTT messages :-)