You really don’t need the Timer for the 5A4CE4 Shelly. It will run immediately anyway so putting it into a timer doesn’t really do anything for you.
But, let’s see if we can adjust this Rule so it scales. As written, you would have to add code to this Rule every time you add a Shelly.
I can see several ways to do this:
Add an announce Item for each Shelly, add those to a Group, and loop through the Group to send the announce command to each in turn.
Add a tag to one of the Items associated with this device, let’s say the Online Item, with the unique address for that given shelly. Put the Online Items into a Group and loop through the Group, constructing the topic to send the announce command to using the tag.
Create a Map in the Rule that maps an Item instead of a tag.
Use a .map file in the Rule and trasnform Action instead of a tag.
I’m sure there are more.
The “proper” way to do this would be 1. This is a separate capability for each device and therefore it should be represented as a Channel on the Generic MQTT Thing that represents this Thing and linked to an Item, so let’s show that. I won’t show the Thing or Item definition, you can figure that out with the examples above.
We will call the Group of Announce Items “Shelly_Announces”.
rule "ask for firmware version" when Channel 'astro:sun:local:noon#event' triggered START then // Loop through the Shelly Announce Items and send the "announce" command to each, 5 seconds apart Shelly_Announces.members.forEach[ shelly, index | createTimer(now.plusSeconds(5*index), [ | shelly.sendCommand("announce") ] ) ] end
The Rule to extract the data would also need to be changed for every new Shelly one adds to the system. Let’s see if we can make it more generic. The only specific part is that switch statement in the middle so I’ll focus there.
Again, there are different ways we can deal with this. This is one of those cases where the REGEX filter we can apply using the MQTT 1.x binding would come in handy as you could just have your FWVer et al Items subscribe to the same topic but only process those that contain the “shelly name” that the Item represents. Perhaps there is already a way we con do this by chaining incoming transformations, which is a feature that the MQTT 2 binding supports.
I’ve only one shelly right now so I can’t fully test it. But it appears to work. And this approach would eliminate the need for the second Rule.
Create a Switch Channel on the Thing for each Shelly that sends “announce” to the command topic for that Shelly device.
Create a Text Channel on the Thing for each Shelly that represents the three pieces of information you care about (IP, FW Version, Firmware Update). These Channels subscribe to shellies/announce and we use a chained transformation to filter on the Shelly name and then extract the value from the JSON.
I don’t use .things files but the Thing would look something like in PaperUI:
The Request Announce Channel is just a switch with a mapping configured so whenever it receives ON or OFF it publishes “announce” to the command topic.
MQTT Command Topic: shellies/shelly1-25A289/command Custom On/Open value: announce Custom Off/Closed value: announce
Now let’s look at the IP Channel.
MQTT state topic: shellies/announce Incoming value transformations: REGEX:(.*shelly1-25A289.*)∩JSONPATH:$.ip
The transformation will match the full message but only if it has the “shelly name”, in this case shelly1-25A289. It appears that there is no error in the logs when the REGEX doesn’t match anything. If it does match then it passes the full JSON to the JSONPATH where the IP field is extracted.
I only have one Shelly set up right now so can’t fully test this, but when I “break” the REGEX on this Thing nothing happens (which is what we want) and when I fix it so it’s correct I get the IP address.
So I recommend implementing all of your second Rule in your Things and link the Items to the Channels.This way the “shelly name” for the device is wholly contained within the Thing freeing you to not know nor care what Shelly decided to name this device in your Rules or your sitemap nor the need to provide some external mapping between that and your chosen Item names.