Real-Time updating Speed and Queueing

After some extended testing, I have noticed that the real-time updating of the Shim devices is too slow.

The Smappee is creating MQTT messages every second. This is handled by the MQTT plugin OK AFAICS.
I have a trigger set to run an action to update three variables.

If I associate two Shim devices with the MQTT device, the lag gradually builds up because the queueing can't keep up.
Therefore the readings being displayed by the devices states are not meaningful.

Not sure what the answer to this is but it looks like (for this application, at the moment) I will have to rely on variable updates.

How long is it running in that configuration before the lag becomes noticeable? Did you disable the variable update triggers while testing the Shim devices? And are you using the dispatch check box in the trigger configuration? Or using a separate action to do the dispatch?

Lastly, can you put the MQTT Connector plugin in detailed debugging mode for a minute or so? I'm specifically looking for the line that has "triggerCheck queueMessage, queue =" in it. It should have the identifier for the queue, then a number in parentheses. That number is the size of the queue (how many messages are waiting to be fetched).

I just looked at the Shim message handler code, that gets the notifications from the Connector plugin and retrieves the messages. I see a potential optimization I can make to handle high rates of messages. I'll see if I can get a version with that in it out later today.

It was probably (make that definitely) me

I went back to first principles and reset everything to the optimum setup and now the queue is showing 1.

It was up to 2910 before I reset everything - which explains why I thought it was lagging.

I have re-enabled the variable action update and the Shim devices and variables are in step (give or take a second or so).

Apologies for the false-alarm.

It was probably (make that definitely) me

I went back to first principles and reset everything to the optimum setup and now the queue is showing 1.

It was up to 2910 before I reset everything - which explains why I thought it was lagging.

I have re-enabled the variable action update and the Shim devices and variables are in step (give or take a second or so).

Apologies for the false-alarm.

No, there's definitely some issues that I need to figure out how to deal with. If the MQTT Connector is running, but MQTT Shims is not, or there are no devices configured for a specific Message Type, then the queue for that Message Type will grow indefinitely. And the current code will only fetch one message from the queue per notification, which won't reduce the queue on the Connector side.

So I'm reworking the Shim side code to fetch the (possible) backlog of messages. The complicating factor is that there's a one to many relationship between queued messages and devices to be updated. So it's a loop through the notifications (which only happen when both plugins are running), then loop through both the queued messages and the devices. Which is ugly.

Release 0.0.4 - https://github.com/FlyingDiver/Indigo-Shims/releases

Handles backlogged messages now.

Warning: Plugin has been renamed. Disable and remove old plugin before installing this one. Nothing else will need to be changed.

Both plugin updates installed and all working.

Thanks for the updates.