I was transitioning from wired P1 to WIFI P1, so I didn't want a new plugin creating another set of devices and risk losing the history.
I did try (a bit) to do the same (what I do outside) inside a plugin, but it would need multithreading inside the plugin and it's too cumbersome.
What is needed in fact is a version of the built-in P1 with LAN that is able to send a HTTP GET every x seconds, not just wait for telegrams to come by themselves. Maybe I'll start looking in the C sources.
jvdz wrote: Friday 02 January 2026 9:56
Didn't simply changing that setting to 5 seconds instead of 10 work for you?
My solution has successive sampling points, all adding to the latency:
- The meter itself samples every 1s and sends a telegram.
- The WIFI dongle gets all telegrams, but only sends the last one when asked.
- My "service" polls every 5s - it will get a telegram maybe 1s old and will push it to Domoticz.
- Domoticz samples every 10s, meaning it skips telegrams until the sampling point. When it will choose one, it can be 5s old from my service.
Conclusion: For a wired P1 Domoticz can be off by 1s, for my new solution it can be off by 6s.
Yeah, many choices are possible, depending on what you expect from the system. I was always targeting 10s cycle time in Domoticz and I can live with 6s latency.
But clearly the service poll time should be <= domoticz poll time, otherwise domoticz will use several times the same telegram.