MQTT cycletime for values /powermeter/# are frozen at 10s

[TomBrett72]

What happened?

The global MQTT cycle time was set to 20s. But */powermeter/# values are sent in 10s intervall

To Reproduce Bug

already restart of the DTU and try setup other values, f.i. 15s, no change.

Expected Behavior

For monitoring I use a simple android MQTT-dashboard and therefore I need the same MQTT cycletime for all values.

Install Method

Pre-Compiled binary from GitHub

What git-hash/version of OpenDTU?

2024.06.03

Relevant log/trace output

No response

Anything else?

[spcqike]

I haven’t had a look at the code yet, but you can try to set your powermeter interval to 10s. That can only be done by editing the config file. So download your config, set powermeter interval to 20, upload your config.

[schlimmchen]

@spcqike That workaround might not work for him, as that interval is not synchronized with the MQTT publish interval. AFAIK that is important for his application.

I need the same MQQT cycletime for all values.

I am doubtful, but I am not going to argue with your needs. Let me mention, however, that the timepoints at which the individual data points are published drifts over time. Each software component uses its own "last published" timestamp and then waits for another MQTT publish interval to elapse. The data is not synchronized.

You are correct that all values published by the upstream project always follow the MQTT publish interval. Most features also respect this interval, regardless of how often data arrives from the respective peripheral. However, the power meter implementation "historically" does not.

I think it is much more useful to publish new data as it arrives, rather than to follow a particular schedule. In that spirit, I think that the bug you are reporting is not a bug. Also, changing this to follow the MQTT publish interval will be perceived as a regression by some users, especially those who use OpenDTU-OnBattery as their main interface to the power meter (serial SML, serial SDM in particular). If data suddenly only arrives every MQTT interval at the broker even though they explicitly set the power meter interval to something less than that, their data will have less resolution.

Instead, I think we should keep publishing on an event-driven basis and add a configuration switch which allows users to force to wait for the MQTT publish interval to elapse. I, personally, don't think anyone should (have to) use that switch ever.

The thing that I don't like and which was pointed out now, it that the components behave differently. Something should be done.

[Robert-Schimanek]

I encountered similar behavior, although I would not call it a bug, as the 10-second interval of a responsible power meter loop is hard-coded in the config. I thus migrated the MQTT publish directly after the MQTT power meter value arrival weeks ago and am happy with the result.

[TomBrett72]

Thanks alot for all comments! You are all right. @schlimmchen I like the way of your thinking. You are the developer, I just use, try to use ;) 1) I agree, it is no bug, the software does what it's supposed to do. 2) Just no circumstances. I also think I´m the only one who might need this switch. My visualization is a really cheap solution that I got from YouTube as a beginner in MQTT. The flaw with this app is that it simply plots only 1000 values. If you send 1 per second, then you have only ~15minutes. I have GRAFANA at work, but I´m not able to manage such databases without the IT professionals. 3) I tried the way @spcqike and... it works! all fine for me! In my eyes we can close this topic.

[schlimmchen]

Nice to read that the workaround works for you. As you agree that such a switch would be of limited use, I will close this issue as suggested by you.