Shelly Plug US

[madmax]

Hi,

I am creating a new Device and Feature templates for the Shelly Plug US. I am just trying to understand the JSON parsing so I can add other devices in the future. This particular plug sends messages to:


shellyplugus-XXXXXXX/events/rpc


And the response for Power on is:

{
"src": "shellyplugus-083af2008e24",
"dst": "shellyplugus-083af2008e24/events",
"method": "NotifyStatus",
"params": {
"ts": 1657556975.63,
"switch:0": {
"id": 0,
"output": true,
"source": "WS_in"
}
}
} 

I am thinking to get the power state, I would subscribe to:

#TOPIC#/events/rpc:params:switch:0:output 

I am thinking it's not working because there is a colon in "switch:0". I tried escaping it with a backslash but the editor adds two backslashes. If I can get this working I'll add all the features and share them on this forum.

[stefxx]

Yes I can see that the colon would cause some issues. Let me look at the code on how to prevent this.

[madmax]

Thanks

{
"src": "shellyplugus-083af2008e24",
"dst": "shellyplugus-083af2008e24/events",
"method": "NotifyStatus",
"params": {
"ts": 1657559581.48,
"switch:0": {
"id": 0,
"aenergy": {
"by_minute": [
220.533,
220.239,
221.817
],
"minute_ts": 1657559579,
"total": 14.163
}
}
}
} 

Also, this is far less important, but if I wanted to extract just one of the values in by_minute, would it be possible?

[stefxx]

If you install the latest beta, a colon in a Json key payload is supported. Use \\: in the Topic.

Also, you can select the field in an array by using the "array" key in the json. See the "Feature template" in setup. Also, and example can be found in the "Tasmota Watts 2.json" feature template. Note that the array key is 1 based (so first value is 1, not 0).

Let me know how this works for you and if you have any other questions. It seems you are implementing the Shelly Pro devices? I would love to see that so sharing is highly appreciated!

[madmax]

Thank you so much. This worked for the status. I am still struggling to figure out the Switch status on Pro devices. It looks like for the status events, I need to subscribe to #TOPIC#/events/rpc. To turn the device on, I need to subscribe to #TOPIC#/rpc and send a json payload. I'll keep working on it.

I have the following devices I'll be testing: Shelly Plug US, The temperature sensor addon for the Shelly 1PM, Shelly DUO bulb, Shelly Uni, and a shelly i4.

[stefxx]

I only tested it to display the status, per your examples. If it doesn't work for controlling, let me know (with an example) so I can look at it.

[madmax]

Actually, I just got status and control both working for Power. I will post the files for US Plug once I complete all the features. I will post the other devices I add too, Thanks for the quick response!

{
"template": "Shelly Plug US Power",
"name": "Power",
"address": "Power",
"status": [
{
"topics": [
"#TOPIC#/events/rpcarams:switch\\:0utput"
],
"values": [
{
"payload": "false",
"status": "Off",
"image": "off.gif"
},
{
"payload": "true",
"value": 100.0,
"status": "On",
"image": "on.gif"
}
]
}
],
"control": [
{
"topic": "#TOPIC#/rpc",
"values": [
{
"payload": "{"id":0, "src": "homeseer", "method": "Switch.Set", "params":{"id":0,"on":false}}",
"type": "button",
"label": "Off",
"controluse": "off"
},
{
"payload": "{"id":0, "src": "homeseer", "method": "Switch.Set", "params":{"id":0,"on":true}}",
"type": "button",
"value": 100,
"label": "On",
"controluse": "on"
}
]
}
]
} 

[madmax]

One additional problem I am having:

I have an IP address feature template with "#TOPIC#/events/rpcarams:wifi:sta_ip" as the topic.
When I reboot the module, it reports the correct IP address, but soon after, the value is overwritten with nulls (see Homeseer log screenshot). The problem is that sta_ip is not in these messages referenced in the HomeSeer log. See the actual message logged via node-red screenshot. Am I doing something wrong?

[stefxx]

I have an IP address feature template with "#TOPIC#/events/rpcarams:wifi:sta_ip" as the topic.
When I reboot the module, it reports the correct IP address, but soon after, the value is overwritten with nulls (see Homeseer log screenshot). The problem is that sta_ip is not in these messages referenced in the HomeSeer log. See the actual message logged via node-red screenshot. Am I doing something wrong?

You aren't doing anything wrong, this is a bug. Should be fixed in the latest beta. Let me know if that works for you!

[madmax]

Thank you!


When I reboot the module, it first gives the IP address as NULL and then provide the correct IP address twice. I notice in the Homeseer trace, the order logged is reversed, looking like the NULL came most recently - but it works - the correct homeseer status is logged so maybe we don’t need to worry about the trace order. The only standard value I cannot get is the current firmware level. Oddly, It’s not reported on boot but available firmware updates are. To get the current firmware level, you have to subscribe to a user topic, for example: homeseer/rpc and then send a Mqtt message to shellydevice-XXXX with the below payload. Then, the firmware info will be received on homeseer/rpc. I’m assuming this will not work on the plugin because it doesn’t poll and there are no event actions that enable a poll event?

[stefxx]

The only standard value I cannot get is the current firmware level. Oddly, It’s not reported on boot but available firmware updates are. To get the current firmware level, you have to subscribe to a user topic, for example: homeseer/rpc and then send a Mqtt message to shellydevice-XXXX with the below payload. Then, the firmware info will be received on homeseer/rpc. I’m assuming this will not work on the plugin because it doesn’t poll and there are no event actions that enable a poll event?

There are a few approaches possible:
1. Do not poll. Assume the firmware will be updated every now and then (I wouldn't be surprised if it updates every day or less).
2. Create a control button that publishes the message out to trigger the update, in the Feature Json.
3. Create an event to trigger the update

Yes, there are special events actions available to do that. Look the the "MQTT Publish" event.

I would prefer a combination of 2 and 3. So keep the logic in the JSON to have a "refresh" or "update" button on the HS4 feature, and if required create an event that triggers that button.

[madmax]

Thanks! That worked perfectly. I can rely on it to report at intervals but I also added buttons for a manual refresh.

I could add volts, current, firmware updates (and a button to upgrade), accumulated power, etc but I'm not sure I would use those values at this point. Thank you so much for your updates. I have several other new devices to test and add. I'll upload those json files too as I complete.