MQTT Bugs?

[berkinet]

I have found 2 anomalies (aka possible bugs).

1. I have a trigger to set the message type for a shim

   

   Screenshot 2025-12-05 at 11.54.44.png (154.77 KiB) Viewed 137 times

   This works fine. However, periodically it becomes un-enabled. I have no idea why, and nothing is logged. FWIW, this only seems to happen if I shift focus from the folder containing the trigger.
2. In the Shim device, I have found that when changing the device type, the device states are not deleted. So, even if the changed configuration no longer maintains those states, they still appear in the device display. Also, once the precision is set, changing it seems to have no effect.

Let me know if there is any additional information I can provide.

[FlyingDiver]

This works fine. However, periodically it becomes un-enabled. I have no idea why, and nothing is logged. FWIW, this only seems to happen if I shift focus from the folder containing the trigger.

Un-enabled where? You mean in the main Indigo Device list window? The comm-enabled checkbox? Or somewhere else?

In the Shim device, I have found that when changing the device type, the device states are not deleted. So, even if the changed configuration no longer maintains those states, they still appear in the device display. Also, once the precision is set, changing it seems to have no effect.

Yeah, changing the device type isn't supported very well, as all the custom attributes from the old type are not deleted. Doing that would really make the code more complicated. Best to just create a new device.

Changing precision should work. Can you create a GitHub issue for that?

[berkinet]

Un-enabled where? You mean in the main Indigo Device list window? The comm-enabled checkbox? Or somewhere else?

Sorry if I wasn’t clear. This is the trigger that sets the keyword for the shim to look for. So, it is the “trigger enabled” checkbox in the Trigger list

Yeah, changing the device type isn't supported very well, as all the custom attributes from the old type are not deleted. Doing that would really make the code more complicated. Best to just create a new device.

Changing precision should work. Can you create a GitHub issue for that?

Agreed, it is probably not worth the effort to clean up when they shim device is altered.

I will see if I can get some evidence on the precision issue. Though, it may be linked to the First issue of trash hanging around in the device description. This was the same shim device that was showing the states that were no longer in use.

[FlyingDiver]

Un-enabled where? You mean in the main Indigo Device list window? The comm-enabled checkbox? Or somewhere else?

Sorry if I wasn’t clear. This is the trigger that sets the keyword for the shim to look for. So, it is the “trigger enabled” checkbox in the Trigger list

Interesting. The plugin doesn't explicitly enable or disable triggers. Not sure how that would happen.

[berkinet]

Interesting. The plugin doesn't explicitly enable or disable triggers. Not sure how that would happen.

Me neither.

[berkinet]

Interesting. The plugin doesn't explicitly enable or disable triggers. Not sure how that would happen.

Me neither.

DOH!!!

At some point the device was flooding the MQTT server with constant message. So, I created a repeating scheduled action to run every 10 minutes and enable the trigger for 4 seconds to capture an update, and then disable the trigger for 5 minutes. Then, the vendor added an option to set how often updates should be sent. So, I set it for 10 minutes. But, I had forgotten about my "fix." This effectively blocked any updates.