My goal is to poll about 70 registers from a PLC, reorganise them and send them through MQTT.
I asked some questions here about this (Thx for the replies).
The problem:
when I poll my plc, I have a set of values.I need to create topics and I don' want to saturate my MQTT flow (all data sent at the same time) at the same moment. Some values should be sent approximatively every minute, some every hour. Some if they change.
I used some delay function (x messages per minute, send on change) but it becomes a real mess.
My idea: use prime numbers in delays to avoid a simultaneous flow to my MQTT broker. With that, except if I'm clearly mistaken, I avoid the send collision and then I have nice "little flows" instead of a river of data.
*Note: if I send too much data in a quick flow, my broker has no problem to handle them but my Hubitat that handle the data sent by my MQTT broker seems to slow down...
Your answer ?
Man, you're nuts, read the doc and try to build a nice custom loop
Man, strange idea, but why not ?
Man, don't spend your time on this, send all your data, your broker should take 100 values without problems (but I don't know for your hubitat)
Thing is probably called "load balancing" via scheduling algorithms and it is definitely right thing to do especially if one your system components seems to be in trouble tho handle the load.
Not an easiest task to figure out by all means.
tagging @hotNipi
Thank you.
Unfortunately, this can't be possible. MQTT is not officially supported and they can't help me in this matter. It's third party apps and I can play with them, but on my own.
I'll try then differently (load balancing or timed polls) but I need to learn a little (little ??) more about this.
Tagging is nice but how can I help? I'm not an expert of load balancing technology (what ever kind). The task you are planning to do is complicated and needs deep knowledge about components and communication in between them. I have too little to be helpful on this topic.
I'm not sure why the delay in rate limit mode won't work for you (just before MQTT) - it will space out all your messages into a stream with whatever gap you need.
Not sure why you think Modbus or MQTT is the problem here. Your original post just says that Hubitat slows down.
It will probably work (I'm testing different options). It seems that delay will be the easiest solution.
For modbus, for unknown reasons, when I poll my plc at lower rates, I obtain errors (connection errors) and that is strange to me. Normally polling at higher speed (not lower) could generate some communication errors. Have to investigate here too (later).
MQTT has no problems: the messaging structure is ok, the cpu is enough and I have no missed messages.
I made today some tests that clarify things: I poll my modbus unit at the normal speed (1 poll every 10 seconds) and delay the value sending to my functions later (once every minute or every 2 minutes). Then my MQTT broker processes them and send the little regular flow to Hubitat. All seems better now.
