Shelly Power Strip 4 Gen 4

[1100101]

Hi,

I'd like to request support for the product below.
While the Outlets are recognized by deCONZ, and I can switch them on/off individually, electrical measurements/metering information is missing.

More details from Zigbee2MQTT: https://www.zigbee2mqtt.io/devices/S4PL-00416EU.html

I specifically would like to request the ability to configure the light rings of the outlets (LED mode @ Zigbee2MQTT), so I can turn the lights fully off.

Is there already an existing issue for this?

• I have searched the existing issues and there is none for my device

Product name

Shelly Power Strip 4 Gen 4

Manufacturer

Shelly

Model identifier

Power Strip

Device type to add

Switch

Node info

Endpoints and clusters

Basic

Further relevant clusters

Power Configuration

On/Off (Plug 1)

Level Control

Color Control

Thermostat

Simple Metering (Plug 1)

Electrical Measuremeant (Plug 1)

Any other cluster of relevance/interest

[mattreim]

@1100101 A power strip with four measuring points is useful. It's important to ensure the values ​​are accurate, e.g., the consumption in Wh.

shelly_1pm_mini_gen4.json

The switches, consumption, current, power and voltage of the sockets should work with the DDF, but the rest seems to be controlled by the "Shelly RPC Cluster". Perhaps @SwoopX has experience with this.

[1100101]

Thanks for the fast response!
I tried the DDF, and it does seem to work:

Strangely, the value for "current" flickers quite often. It looks like a value > 0 is set, followed immediately by the value 0.
This sometimes goes on for a while.

Any idea what the reason might be?

[mattreim]

When a device is connected, the current value should always be greater than zero. However, in my opinion, the current divisor is 1000, meaning it's measured in mA. Try different devices and also check the "Electrical Measurement" to see if the values ​​are correct.

[1100101]

I've now come around and integrated the powerstrip into my environment.
My (Mini)PC is connected to the first outlet.
This first GIF is a short video from the Phoscon web interface:

Here's a short video from Shelly's own web interface:

(This one was taken maybe a minute after the other one.)

You can see that Phoscon values get zeroed every now and then.
Is this caused by the Shelly itself (its Zigbee implementation), or is it a deconz issue?

[mattreim]

@Smanar can you explain the device's behavior?

[Smanar]

I don't see something bad on the DDF, or similar issue on google.
Just a comment on the DDF "state/power_divisor" is for me useless, it's something fixed, so can use a fixed value, don't need to poll the device every 360s to have the value.

Need some logs to see where the problem is from.
With flags "info" + "info_l2" + "DDF", easy to understand
And flag "APS" + "APS_l2" to see raw value from the device, to see if the device send itlself the 0 value or not.

But as we can see the same issue on power AND current in same time, lot of chance for the issue is hardware.

Can try same reporting used in Z2M

{"cluster":0x0B04,"attrId":0x050b,"min":10,"max":65000,"Change":5}{"cluster":0x0B04,"attrId":0x0508,"min":10,"max":65000,"Change":0x32}{"cluster":0x0B04,"attrId":0x0505,"min":10,"max":65000,"Change":0x01f4}

On the DDF it's this part, just need to change value, not the fields.

        {
          "at": "0x0508",
          "dt": "0x21",
          "min": 1,
          "max": 300,
          "change": "0x00000064"
        },

will be

        {
          "at": "0x0508",
          "dt": "0x21",
          "min": 10,
          "max": 65000,
          "change": "0x00000032"
        },

[mattreim]

The "state/power_divisor" is more for safety reasons, as it changes with some devices at high power levels, but it can be easily checked, e.g., by connecting a fan heater (> 1000W) and observing.

[mattreim]

I checked again and found nothing about "state/power_divisor". @1100101 Therefore, could you please review this DDF again?

shelly_power_strip4_gen4.json

[Smanar]

, as it changes with some devices at high power levels

Seriously ? For me this value was fixed in the firmware.
But for me it's not the problem, because the 0 value appear on power AND current, and this is not used for current.

I suspect a lot the device.
Sometime need to use specific value for report else the device make garbage, but if the issue persist with same setting used in Z2M ......

[mattreim]

Hey @Smanar, since this device is new, it's possible it uses the same divisor as IKEA or LEDVANCE, but that's resolved now. I also think it's more likely a problem with the device itself than the settings or the DDF. Without tests, we can't say anything more about this device anyway.

[1100101]

Alright, sorry for the delay, I haven't had the time to play around with this earlier.
Here are 2 logs with the requested log levels enabled.
The first one is with the 2nd DDF, the other one with the original DDF.
shelly.log
shelly_old_ddf.log

The ID of the strip is 98:a3:16:ff:fe:7b:de:34.
Looking at the values, 98:a3:16:ff:fe:7b:de:34-01 looks like it's the first plug, and 98:a3:16:ff:fe:7b:de:34-04 the last one.

Plug 1 has my PC connected to it, power usage fluctuates.
Plug 2 is unused.
Plug 3 is my motorized desk.
Plug 4 is my monitor, which has a relatively steady power drain of 22W (according to the Shelly).

Grepping the IDs for the plugs/sensors from the logs, I find it interesting, that plug 1 (98:a3:16:ff:fe:7b:de:34-01) has the most occurences, whereas plug 4 (98:a3:16:ff:fe:7b:de:34-04) has the least.
The fact that plug 2, which has nothing plugged in it, show more "action" in the logs than plug 4.

Anyways. I noticed with both DDFs, Phoscon actually only shows power/current values for Plug 1.
The other plugs do have these items, but they're all 0 and never change.

[mattreim]

@1100101 The second DDF was not detected. Please check if the old DDF has been removed. And make sure that the individual sockets can be switched on and off. They must of course be switched on for measurement.

[Smanar]

An exemple from your old log

18:04:44:024 APS-DATA.indication srcAddr: 0xBC93, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0B04, lqi: 255, rssi: -61
18:04:44:025 asdu: 18450a0b05290000
18:04:44:025 a4:c1:38:b4:bb:9e:e9:27-01-0b04/state/power expression: Item.val = Attr.val --> 0

APS-DATA.indication > Mean request from the device
1845 0a 0b05 29 0000
0a > Report attribute
0b05 > is the attribute 0x050B
0x29 > data type
0x0000 > value

So it mean at a moment it's the device that report itself the 0 value, not a miscalculation from deconz.
For me the problem is not from the DDF, can see if with the news values reporting, there is same result.