Shelly EM/3EM Implementation

I'd like to start a discussion about the implementation of the Shelly EM and 3EM. It appears that the 3EM is a beefed up version of the EM with an additional channel of monitoring (still a single output relay). The implementation of both devices will be almost identical, so I will refer to both as the Shelly EM implementation in this post.

The Shelly EM contains two channels of energy/power/voltage monitoring and control of a single low-current relay.

Similar to the Shelly 2.5, I would break this single Shelly EM into two separate Indigo devices. A single device in Indigo would be "connected" to a single channel of the Shelly EM. The device config allows you to choose which channel the indigo device is associated with. If you are monitoring two individual electrical devices with a single Shelly EM, each electrical device would be represented individually in Indigo with their separate power usage, voltage, and so on.

If the implementation above is acceptable, then here are some lingering questions:

1. There is a single controllable relay.
   
   Option 1: Should both of the devices in Indigo be able to control this relay? This would allow for both of the sensors to have authority over the relay and each electrical device could be automated.
   Option 2: A third (getting a bit cluttered now) indigo device to represent the relay only?
   
2. Each channel has energy tracking (like the 1PM and 2.5), so you can monitor and reset usage within Indigo. This allows you to see "over x days, the device has consumed x kWh". However, this device also keeps track of energy sent back to the grid. Should the Indigo energy UI be a combination of these two? If you consume 1.875 kWh and then send back 2.264 kWh (without resetting), then should Indigo display that your energy usage is -0.389 kWh?

Please let me know of any other implementation ideas, or issues that I haven't thought of yet.

Thanks,
Aaron

[jay (support)]

Is there any relation between the two monitor (channels?) and the output? IMO, if the 3 are unrelated, I'd recommend implementing them as 3 devices in a group. From a usability perspective, they are 3 separate "things" that just happen to reside in the same physical device (like an Insteon FanLinc, which is a fan controller and a light controller rolled into one). Then each energy monitor would use the native Indigo UI controls for the energy stuff, and the 3rd would be a standard relay device.

Is there any relation between the two monitor (channels?) and the output? IMO, if the 3 are unrelated, I'd recommend implementing them as 3 devices in a group. From a usability perspective, they are 3 separate "things" that just happen to reside in the same physical device (like an Insteon FanLinc, which is a fan controller and a light controller rolled into one). Then each energy monitor would use the native Indigo UI controls for the energy stuff, and the 3rd would be a standard relay device.

I think that all channels are independent of each other. I don't have a Shelly EM, or the need for one, so maybe Colly can jump in with their use case.

It appears that Shelly intend the relay be used to control a contactor which would switch the load(s) that you are monitoring. I think that you would want this relay to be shared by both devices in Indigo. My plugin is capable of updating multiple Indigo devices from a single MQTT message, so if the relay was turned off by one Indigo device, the other Indigo device would still stay in sync. This is already proven by the shared internal temperature for the Shelly 2.5 devices.

Hi Aaron,
I have only connected one of the current clamps so far. My intention is to monitor my heat pump with that clamp and then the rest with the other for total house consumption. If I'm happy with it I might add another set in time. See screenshot below for what I've working at the minute.
In relation to the separation of the devices, for me I'd agree with Jay - they are separate things in one device and there's no need to group. I can't personally see me using the output for anything.

Hi Aaron,
I have only connected one of the current clamps so far. My intention is to monitor my heat pump with that clamp and then the rest with the other for total house consumption. If I'm happy with it I might add another set in time. See screenshot below for what I've working at the minute.
In relation to the separation of the devices, for me I'd agree with Jay - they are separate things in one device and there's no need to group. I can't personally see me using the output for anything.

I believe my intention is to split each channel of the energy monitoring to two separate Indigo devices (similar to how the Shelly 2.5 is represented as two separate Indigo devices). My main question was regarding how to divide the relay. Should the relay be represented as a third Indigo device? Or should the two indigo devices that represent each channel of monitoring also have an onOff capability where both devices control the same relay?

It is not a problem in my plugin for multiple devices to share hardware. Turning the relay on from one device would automatically propagate to the other device and indicate that the relay is on. I am leaning 70% towards making the relay a separate Indigo device the more I think about it.

In the Shelly App both power devices can turn On/Off the relay. However if, which would be my use case, I wanted to use the relay based on a value being exceeded then I would be using Indigo intelligence to do this so having the relay as a separate device would work perfectly. I don't see much of an advantage/disadvantage having it linked to the power device. Thats my thoughts anyhow

[jay (support)]

Indigo users are used to Indigo devices doing 1 thing unless the functionality is tied together explicitly (temp sensors on a thermostat, energy monitoring data on a wall wart which monitors energy consumption of the thing on its load, etc). Artificially tying them together without an explicit reason will just cause confusion IMO.

Indigo users are used to Indigo devices doing 1 thing unless the functionality is tied together explicitly (temp sensors on a thermostat, energy monitoring data on a wall wart which monitors energy consumption of the thing on its load, etc). Artificially tying them together without an explicit reason will just cause confusion IMO.

Ok that makes sense. There is no direct tie between an individual channel and the single relay.

In the Shelly App both power devices can turn On/Off the relay. However if, which would be my use case, I wanted to use the relay based on a value being exceeded then I would be using Indigo intelligence to do this so having the relay as a separate device would work perfectly. I don't see much of an advantage/disadvantage having it linked to the power device. Thats my thoughts anyhow

Ok, so most likely the Shelly EM will be represented by 3 Indigo devices: 2 Power monitors and 1 relay controller.
This would mean that the Shell 3EM would be represented by 4 Indigo devices: 3 Power monitors and 1 relay controller.

One last question: How should energy be displayed? I believe (from they API) that each channel reports energy consumed AND energy returned to grid. I will make both of these values available as individual states, but how should the Indigo UI present the energy usage in the side panel?

Energy UI

Screen Shot 2020-03-13 at 5.42.26 PM.png (167.65 KiB) Viewed 3887 times

Should this total usage show the net usage? A given period after resetting usage in Indigo would be the difference in energy consumed and energy returned. I don't personally use this device, but if I did (and had a case where sometimes energy was returned) I would like to see that over a period of time, this device actually returned 5.2 kWh to the grid (UI in the red circle would show -5.2 kWh). But I would be able to see in my states list that I consumed 4 kWh and returned 9.2 kWh.

Thanks for the feedback,
Aaron

I don't see a use case for returned energy in my setup at the minute so don't have a strong view either way. With other z-wave devices I have they just continually accumulate - not something I pass too much remarks to. Maybe some other users might have a view.

I don't see a use case for returned energy in my setup at the minute so don't have a strong view either way. With other z-wave devices I have they just continually accumulate - not something I pass too much remarks to. Maybe some other users might have a view.

Ok so that settles it then - it will be configurable!

This energy monitoring stuff is new to me, so I may be a bit overexcited with it at the moment.

If you have MQTT Explorer, would you mind sharing a screenshot of all the data it outputs? The Shelly API is great to indicate what the data should be, but it is helpful to have an actual example of what the data looks like.

Is this ok?

Is this ok?

Yes that is perfect. Thank you!

I have both the Shelly EM and 3EM added in the latest version, 0.0.7 (https://github.com/AaronLionsheep/Shell ... /tag/0.0.7).

There are "Shelly EM Meter", "Shelly 3EM Meter", and "Shelly EM Relay" devices defined that should break a single device up into to 3 or 4 Indigo devices.

Great work Aaron, working perfectly. Added a 2nd current sensor earlier with no issues. Will add to my Shelly collection once the postal services return to some form of normality.
Colly

Hi Aaron,
I've been meaning to create a few dashboards in Grafana with energy usage per day/week/month/year. Having looked at this for a bit tonight I think it would be beneficial to have the Total Energy data brought in to Indigo -

Code: Select all

"shellies/shellyem-<deviceid>/emeter/<i>/total

This is the total energy in Wh (accumulated in device's non-volatile memory). The data is stored in the device and will be included in the next value returned after if it went offline for a period. This would allow for more accurate comparison with the utility bill and in future when I get a smart meter. An example of the Shelly going offline could be a restart of my Mac Mini.
Colly