Releases

Hi Aaron,
Using latest version of the plugin and was trying to set up a trigger for an i3 "temperature status" of either "High" or "Very High"
...
So I'd like to set up a trigger as outlined above but didn't see an option to. Have I missed something? If not can you consider adding this in a future update?

I have this implemented in the 0.6.0 branch on GitHub. The Shelly 1PM, Shelly 2.5, and Shelly i3 now have an additional "temperature-status" state that will either be "Normal", "High", or "Very High".

There is a new event defined by the plugin named "Any Abnormal Temperature Status" which you can use as a catch-all trigger. If you trigger on this event, then the trigger will be executed each time ANY device has its temperature-status changed away from "Normal". If you want more fine-grained triggering, then you should be able to simply trigger off of the new state for a specific device.

Let me know if you run into any issues or have any feedback.
Thanks,
Aaron

Any chance you can prevent RGBW2 channels (white) from going to 100% each time they're turned on and instead preserve the previously set brightness level?

Any change you can prevent RGBW2 channels (white) from going to 100% each time they're turned on and instead preserve the previously set brightness level?

I checked the Shelly documentation, and I think this might be possible. If you are able to send some raw MQTT commands, then I can confirm.

1. Set the brightness via Indigo to 50%
2. Send the payload 'off' to "shellies/<your device identifier>/white/<CHANNEL>/command"
3. Confirm the output is now off, Indigo shows the device as off, and Indigo shows the brightness as 0%
4. Send the payload 'on' to "shellies/<your device identifier>/white/<CHANNEL>/command"
5. Confirm the device turned on to the previous brightness (50%)

Note that <CHANNEL> is the numbers 0, 1, 2, 3 (just subtract 1 from the channel you selected in the device config)

Some examples using mosquitto_pub from the command line:

Code: Select all

Step #2: mosquitto_pub -h '192.168.1.7' -t 'shellies/shellyrgbw2-AA53A3/white/0/command' -m 'off'
Step #4: mosquitto_pub -h '192.168.1.7' -t 'shellies/shellyrgbw2-AA53A3/white/0/command' -m 'on'


Brightness is preserved when turning off/on with the command topic.

Using MQTT Explorer, this is what I see when turning ON from Indigo on the SET topic:
{"turn": "on", "brightness": 100}

Like using the command topic, if I publish manually to the SET topic with {"turn": "on"} then brightness is preserved.

Brightness is preserved when turning off/on with the command topic.

Using MQTT Explorer, this is what I see when turning ON from Indigo on the SET topic:
{"turn": "on", "brightness": 100}

Like using the command topic, if I publish manually to the SET topic with {"turn": "on"} then brightness is preserved.

Ok so that confirms it is possible and much easier (rather than the plugin needing to remember previous brightness values). I think I will elect to add a configurable option in the devices to choose how a device behaves when it is turned on from Indigo. Maybe a checkbox "Turn on to previous brightness".

I believe this will apply to the other dimmable devices (Dimmer, Bulbs, etc.), so I will update those as well.

Any chance you can prevent RGBW2 channels (white) from going to 100% each time they're turned on and instead preserve the previously set brightness level?

This is now implemented in the 0.7.0 branch on GitHub. There is a new checkbox in the device configs to enable this behavior. I have tested with my Bulb Duo's and it works as expected. This means it works for the Dimmer and all other Bulbs due to some code sharing. I added this behavior to the RGBW in both color and white modes, so please let me know if you experience any issues with those devices.

Thanks,
Aaron

Well v0.6.0 did not last long (3 hours!), any idea why I get this in the logs

Code: Select all

  Loading plugin "ShellyMQTT 0.7.0"
   Starting plugin "ShellyMQTT 0.7.0" (pid 72222)
   ShellyMQTT                      Log level set to info
   Started plugin "ShellyMQTT 0.7.0"
   ShellyMQTT                      Starting "Bathroom Window Motion"...
   ShellyMQTT                      Starting "Garage Door - Shelly1-98F4ABF3C817"...
   ShellyMQTT                      Starting "Server Room Double Socket"...
   ShellyMQTT                      Starting "shellies/shelly1pm-98F4ABF27186"...
   ShellyMQTT                      Starting "Shelly i3 Channel 1"...
   ShellyMQTT                      Starting "Shelly i3 Channel 2"...
   ShellyMQTT                      Starting "Shelly i3 Channel 3"...
   ShellyMQTT                      Starting "Shelly Uni Relay 1"...
   ShellyMQTT                      Starting "Shelly Uni Relay 2"...
   MQTT Connector Warning          Queue for message type 'shellies' has 11 messages pending
   MQTT Connector Warning          Queue for message type 'shellies' has 12 messages pending
   MQTT Connector Warning          Queue for message type 'shellies' has 13 messages pending
   MQTT Connector Warning          Queue for message type 'shellies' has 14 messages pending
   MQTT Connector Warning          Queue for message type 'shellies' has 15 messages pending
   MQTT Connector Warning          Queue for message type 'shellies' has 16 messages pending
   MQTT Connector Warning          Queue for message type 'shellies' has 17 messages pending
   MQTT Connector Warning          Queue for message type 'shellies' has 18 messages pending
   MQTT Connector Warning          Queue for message type 'shellies' has 19 messages pending
   MQTT Connector Warning          Queue for message type 'shellies' has 20 messages pending
   MQTT Connector Warning          Queue for message type 'shellies' has 21 messages pending
   MQTT Connector Warning          Queue for message type 'shellies' has 22 messages pending
   MQTT Connector Warning          Queue for message type 'shellies' has 23 messages pending
   MQTT Connector Warning          Queue for message type 'shellies' has 24 messages pending
   MQTT Connector Warning          Queue for message type 'shellies' has 25 messages pending
   MQTT Connector Warning          Queue for message type 'shellies' has 26 messages pending
   MQTT Connector Warning          Queue for message type 'shellies' has 27 messages pending
   MQTT Connector Warning          Queue for message type 'shellies' has 28 messages pending
   MQTT Connector Warning          Queue for message type 'shellies' has 29 messages pending
   MQTT Connector Warning          Queue for message type 'shellies' has 30 messages pending
   MQTT Connector Warning          Queue for message type 'shellies' has 31 messages pending
   MQTT Connector Warning          Queue for message type 'shellies' has 32 messages pending
   MQTT Connector Warning          Queue for message type 'shellies' has 32 messages pending
   MQTT Connector Warning          Queue for message type 'shellies' has 32 messages pending
   MQTT Connector Warning          Queue for message type 'shellies' has 32 messages pending
   MQTT Connector Warning          Queue for message type 'shellies' has 33 messages pending
   MQTT Connector Warning          Queue for message type 'shellies' has 34 messages pending
   MQTT Connector Warning          Queue for message type 'shellies' has 34 messages pending
   MQTT Connector Warning          Queue for message type 'shellies' has 35 messages pending
   MQTT Connector Warning          Queue for message type 'shellies' has 36 messages pending
   MQTT Connector Warning          Queue for message type 'shellies' has 37 messages pending
   MQTT Connector Warning          Queue for message type 'shellies' has 20 messages pending
   MQTT Connector Warning          Queue for message type 'shellies' has 20 messages pending

31 Mar 2021 at 17:43:48



Well v0.6.0 did not last long (3 hours!), any idea why I get this in the logs

Code: Select all

  Loading plugin "ShellyMQTT 0.7.0"
   Starting plugin "ShellyMQTT 0.7.0" (pid 72222)
   ShellyMQTT                      Log level set to info
   Started plugin "ShellyMQTT 0.7.0"
   ShellyMQTT                      Starting "Bathroom Window Motion"...
   ShellyMQTT                      Starting "Garage Door - Shelly1-98F4ABF3C817"...
   ShellyMQTT                      Starting "Server Room Double Socket"...
   ShellyMQTT                      Starting "shellies/shelly1pm-98F4ABF27186"...
   ShellyMQTT                      Starting "Shelly i3 Channel 1"...
   ShellyMQTT                      Starting "Shelly i3 Channel 2"...
   ShellyMQTT                      Starting "Shelly i3 Channel 3"...
   ShellyMQTT                      Starting "Shelly Uni Relay 1"...
   ShellyMQTT                      Starting "Shelly Uni Relay 2"...
   MQTT Connector Warning          Queue for message type 'shellies' has 11 messages pending
   MQTT Connector Warning          Queue for message type 'shellies' has 12 messages pending
   MQTT Connector Warning          Queue for message type 'shellies' has 13 messages pending
   MQTT Connector Warning          Queue for message type 'shellies' has 14 messages pending
   ...
   MQTT Connector Warning          Queue for message type 'shellies' has 20 messages pending
   MQTT Connector Warning          Queue for message type 'shellies' has 20 messages pending

31 Mar 2021 at 17:43:48



Did this only occur on plugin startup? This looks like the result from forcing those device to announce on startup (each device will immediately republish values for upwards of 10 topics each). You can get a full explanation for what is occurring here in a previous post.

As long as the error queue does not continually grow, then there are no major issues. We are at the mercy of the Indigo inter-plugin communication pipe to transfer messages between ShellyMQTT and MQTTConnector, so any small hitch in Indigo will also cause a slowdown and messages can get queued.

Looking through the logs it is not just Shellies but all the MQTT connections I have, obviously a case of too many MQTT messages arriving, the worse I saw was 50 queued but usually only 2 or 3 times a day, no reason I can see.
I can live with it, just wondered why it was happening, off to read post you pointed out.

I can live with it, just wondered why it was happening, off to read post you pointed out.

Joe has a new MQTTConnector (v0.4.8 and later) that lets us change the threshold before those message appear. I personally have my threshold set to 50 messages before the warning are logged.

I am on 0.4.9 and set queue to 30 but as can be seen I still get the warning from 11 to 37.

This is now implemented in the 0.7.0 branch on GitHub.

Latest branch on Git is 0.6.0 - in master and in releases. The last commits all look like they're temp related, I don't see anything about the brightness - did you forget to commit the latest changes?

This is now implemented in the 0.7.0 branch on GitHub.

Latest branch on Git is 0.6.0 - in master and in releases. Did you publish under the previous release number?

I don’t have it packaged as a full release yet, but you can switch to the 0.7.0 branch from the branch drop down. Here is a direct link: https://github.com/AaronLionsheep/ShellyMQTT/tree/0.7.0

OK, got it. I hadn't noticed you were pushing under different branches.

I have ordered a Shelly 1 and a 1pm from the new plus serie. Haven’t found any documentation for the mqtt settings for tem.
Will probably be a week or two before I receive them but will let you know as soon at they arrives.


Sent from my iPad with Tapatalk