v 0.3 upgrade

Posted on
Sun Feb 14, 2021 6:08 pm
agame offline
Posts: 420
Joined: Jul 13, 2017
Location: Melbourne, Australia

v 0.3 upgrade

just upgraded to your new plugin store version., thank you!

mostly using shelly 1/pm and temperature add ons.

everything seems be working (required a reload of MQTT Connector plugin to get rid of error messages).


Only caveat is I am now getting repeating warning messages on one device I wasn't before:

Code: Select all
15 Feb 2021 at 10:57:33 am
   MQTT Connector Warning          Queue for message type 'gate' has 11 messages pending

15 Feb 2021 at 10:58:03 am
   MQTT Connector Warning          Queue for message type 'gate' has 11 messages pending


15 Feb 2021 at 10:59:25 am
   MQTT Connector Warning          Queue for message type 'gate' has 11 messages pending
   MQTT Connector Warning          Queue for message type 'gate' has 12 messages pending
   MQTT Connector Warning          Queue for message type 'gate' has 12 messages pending


Any clue how to get rid of that error?.That device is a shelly 1 with 3 temperature sensors, so probably generating more traffic than others...it does appear be working fine.

Posted on
Sun Feb 14, 2021 6:16 pm
aaronlionsheep offline
Posts: 87
Joined: Feb 24, 2019
Location: Virginia, USA

Re: v 0.3 upgrade

So that is the warning from the MQTT Connector that there is a trigger queuing message of a message type for "gate". I would double check that you have a device that is consuming that message type. What MQTT Topic Match triggers do you have setup?

Does that number repeatedly grow? Don't forget there is no log message for when the queue is subsequently emptied. This might be a case where the device just reports too quickly (and with a lot of data from 3 sensors) and the connector plugin reports a small queue. Joe released a new version of MQTTConnector yesterday where you can configure the threshold for these log messages. You could also try updating and increasing that limit to hide those messages.

Thanks,
Aaron

Posted on
Sun Feb 14, 2021 7:47 pm
agame offline
Posts: 420
Joined: Jul 13, 2017
Location: Melbourne, Australia

Re: v 0.3 upgrade

ah, ok i will download the new broker and play with the timeouts.

I currently have a separate topic for each Shelly. So this one is

Code: Select all
Match: shellies
Match: [name of this shelly]
Match: any


The backlog is almost always 11 messages. It once grew to 13.

I have two more Shellies to configure today that will also carry multiple temperature sensors (managing solar hot water). I will see if they throw the same warnings.
Last edited by agame on Sun Feb 14, 2021 8:04 pm, edited 1 time in total.

Posted on
Sun Feb 14, 2021 7:53 pm
aaronlionsheep offline
Posts: 87
Joined: Feb 24, 2019
Location: Virginia, USA

Re: v 0.3 upgrade

agame wrote:
ah, ok i will download the new broker and play with the timeouts.

I currently have a separate topic for each Shelly. So this one is

Code: Select all
Match: shellies
Match: [name of this shelly]
Match: any




Ok, so you could actually just have one trigger that does a match on:

Code: Select all
Match: shellies
Match: Any


and use a single message type for all shelly devices. There is nothing wrong with the way you have separated them, but I find it easier to only need to remember a single message type when adding new devices.

agame wrote:
The backlog is almost always either 11 messages. It once grew to 13.

I have two more Shellies to configure today that will also carry multiple temperature sensors (managing solar hot water). I see if they throw the same warnings.


So this confirms that it is just due to a high rate of incoming messages and the connector is just letting you know they are queued. I would just raise the threshold in the new connector plugin so that this doesn't show as often. I would be concerned if it continually grew because that would indicate that messages are never consumed (this isn't your case though).

Posted on
Sun Feb 14, 2021 8:00 pm
agame offline
Posts: 420
Joined: Jul 13, 2017
Location: Melbourne, Australia

Re: v 0.3 upgrade

thanks for that.

I've raised the threshold to 15 and so far no more errors.

Agree life would be easier with fewer topics...but I'd thought your advice in the plugin notes was to subdivide them to avoid this sort of situation? Ages ago did have queuing messages on other devices, I think I subdivided at that point - do you think it would be fine to go back to a collective topic?

Posted on
Sun Feb 14, 2021 8:05 pm
aaronlionsheep offline
Posts: 87
Joined: Feb 24, 2019
Location: Virginia, USA

Re: v 0.3 upgrade

agame wrote:
thanks for that.

I've raised the threshold to 15 and so far no more errors.

Agree life would be easier with fewer topics...but I'd thought your advice in the plugin notes was to subdivide them to avoid this sort of situation? Ages ago did have queuing messages on other devices, I think I subdivided at that point - do you think it would be fine to go back to a collective topic?


Ah so that was written in a time before I had enough devices to understand the amount of traffic that is generated and how the plugins handle it. There is an Indigo server with well over 20 devices running using a single trigger with no problems. The "problem" occurs when we have multiple devices that line up on the same 30-second update cycle, but this is uncommon unless multiple devices are sharing a power source.

Before you have too many devices to go back and update, I would try a single topic with a "global" message type. If you start seeing some queueing then I would solve that by raising that threshold to just higher than the largest queue size you start seeing.

Hope that helps,
Aaron

Posted on
Sun Feb 14, 2021 8:57 pm
agame offline
Posts: 420
Joined: Jul 13, 2017
Location: Melbourne, Australia

Re: v 0.3 upgrade

okay then, i'll look at simplifying the triggers.

Posted on
Sun Feb 14, 2021 9:17 pm
FlyingDiver offline
User avatar
Posts: 5005
Joined: Jun 07, 2014
Location: Southwest Florida, USA

Re: v 0.3 upgrade

The initial queue warning at 10 messages was a total WAG when I first implemented the system. I had no idea people would be using so many sensors with such fast updates that the queue would ever get that high. As Aaron says, I made it configurable in the current version.

joe (aka FlyingDiver)
my plugins: http://forums.indigodomo.com/viewforum.php?f=177

Posted on
Sun Feb 14, 2021 10:40 pm
agame offline
Posts: 420
Joined: Jul 13, 2017
Location: Melbourne, Australia

Re: v 0.3 upgrade

thanks for the insight, increasing to 15 appears to have solved my problem.

It does have me a bit intrigued how to correlate a queue of a particular size with a real-world time lag? Is there any rule of thumb for what might contribute a significant lag? I guess playing with a light switch by trial-and-error would show that but harder to know with temperature readings.

Posted on
Mon Feb 15, 2021 8:08 am
aaronlionsheep offline
Posts: 87
Joined: Feb 24, 2019
Location: Virginia, USA

Re: v 0.3 upgrade

agame wrote:
thanks for the insight, increasing to 15 appears to have solved my problem.

It does have me a bit intrigued how to correlate a queue of a particular size with a real-world time lag? Is there any rule of thumb for what might contribute a significant lag? I guess playing with a light switch by trial-and-error would show that but harder to know with temperature readings.


So I think the queued log message might be misconstrued as indicating there is lag/delay in the processing. Months back, I needed to do some performance debugging and I found that ShellyMQTT can take a message from the MQTTConnector queue (over the Indigo inter-plugin communication layer) and process that message by updating various Indigo components in some ridiculously small amount of time. If I remember correctly it was in the sub-millisecond range.

So let's say Shelly MQTT can fully dequeue and process a message in 1 millisecond. Here is the MQTT message log (using mosquito_sub on my terminal) with the timestamp of when my computer received this batch of messages from the broker.

Code: Select all
> mosquitto_sub -h 192.168.1.7 -t "shellies/#" -F "%U %t %p"

1613395907.631712000 shellies/ShellyBulbDuo-D0CF64/light/0 on
1613395907.634397000 shellies/ShellyBulbDuo-D0CF64/light/0/status {"ison":true,"source":"mqtt","has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"brightness":100,"white":0,"temp":2700}
1613395907.634452000 shellies/ShellyBulbDuo-D0CF64/light/0/power 9.00
1613395907.634496000 shellies/ShellyBulbDuo-D0CF64/light/0/energy 64393

So my Shelly Duo published 4 messages in an update with the first being at 1613395907.631712000 and the last being at 1613395907.634496000 - these are Unix timestamps with enough decimals to reach the nanosecond range. These 4 messages were published in a span of 0.002784 seconds. You can even see that some messages were published with 0.00004 seconds in between.

They way Joe has programmed his plugin to show these "queue has x" messages is - as soon as the queue is filled above a threshold, the message is logged. There is nothing wrong with this, but we just have to understand what it really means in this case.

For the sake of argument, let's say that a Shelly device can publish messages at a rate that is 10x faster than what ShellyMQTT can dequeue and process them (proof is above). So this means that when you have a really active device, like your Shelly 1 with 3 sensors, it will publish a huge amount of individual messages on those separate topics. It looks like this could be up to 17 individual messages based on their API. This essentially means that 15-16 messages will be received while ShellyMQTT is still potentially processing the first or second message. Here is where we now have 15/16 messages queued, and the log entry appears.

If we look at the big picture, that queue will be empty in another 16 milliseconds. Basically, ignore or adjust the threshold (25-50 is probably safe depending on how "chatty" your devices are) of that log message UNLESS that queue number is growing continuously. That is what I believe that message was designed for - to indicate that we are queueing messages but not consuming them with a Shims device or another Indigo plugin (ShellyMQTT).

I hope that provides some insight and/or satisfies you rather than blindly changing a number to make a message go away. If anything, it was a fun exercise for me this morning :lol:

-Aaron

Posted on
Mon Feb 15, 2021 8:17 am
FlyingDiver offline
User avatar
Posts: 5005
Joined: Jun 07, 2014
Location: Southwest Florida, USA

Re: v 0.3 upgrade

Good summary, Aaron. And to just put some context here, the reason the Connector plugin has an internal queue is because I didn't think that other plugins could process messages using the device states and Indigo's normal trigger mechanisms fast enough. Turns out I was entirely correct. I just didn't think that specific devices would do bursts of 15+ messages in a few milliseconds.

I'm going to change the default value to 30 in the next update.

joe (aka FlyingDiver)
my plugins: http://forums.indigodomo.com/viewforum.php?f=177

Posted on
Mon Feb 15, 2021 3:09 pm
agame offline
Posts: 420
Joined: Jul 13, 2017
Location: Melbourne, Australia

Re: v 0.3 upgrade

ah thanks for the lucid explanation!
I can now relax without worrying Shellies are clagging my system.

Page 1 of 1

Who is online

Users browsing this forum: No registered users and 1 guest