[BUG] Schneider Exxact Wiser outlet reporting W & Wh a factor 1000 off #1889
Comments
|
Can you try to read from the cluster You can do it from the device view -> Admin Zigbee device --> Clusters Once you get the values try to increasse the divisor value x1000. |
|
Tried it now - divisor was set to 1000. multiplier to 1. Tried to change it but it seems to just revert back to the same values. |
|
My bad, the attributes are read only 🤦🏻♂️ : It seems extrange to me because divisor already has the 1000 divisor value. Which Zigbee gateway are you using? |
|
I'm using a ConBee II with the latest available firmware (0x26780700). (Connected via an extension cable to an Intel NUC running the updated HassOS/HA :-) HA 2022.11.1 |
|
Have you tried to remove and pair the device again? |
|
The device (devices actually, I have 3 of them, one I've had some time, and two new ones I just got) was recently paired, but I guess I can try to re-pair it. |
|
Is the same behavior in all three devices? |
|
Yes, same on all three. Firmware 0x020612ff, sw_build_id 002.006.018 R |
|
I still believe that the problem must be elsewhere but if you want to try, there is a quirk for your device: schneider_plug.py"""Schneider Electric plugs quirks."""
from zigpy.profiles import zha
from zigpy.quirks import CustomCluster, CustomDevice
from zigpy.zcl.clusters.general import (
Basic,
GreenPowerProxy,
Groups,
Identify,
OnOff,
Ota,
Scenes,
)
from zigpy.zcl.clusters.homeautomation import Diagnostic, ElectricalMeasurement
from zigpy.zcl.clusters.smartenergy import DeviceManagement, Metering
from zhaquirks.const import (
DEVICE_TYPE,
ENDPOINTS,
INPUT_CLUSTERS,
MODELS_INFO,
OUTPUT_CLUSTERS,
PROFILE_ID,
)
class MeteringCluster(CustomCluster, Metering):
"""Fix the Metering divisor."""
MULTIPLIER = 0x0301
DIVISOR = 0x0302
_CONSTANT_ATTRIBUTES = {MULTIPLIER: 1, DIVISOR: 1000000}
class SocketOutlet2(CustomDevice):
"""Schneider Electric Socket outlet 2."""
signature = {
MODELS_INFO: [("Schneider Electric", "SOCKET/OUTLET/2")],
ENDPOINTS: {
6: {
# "profile_id": 260,
# "device_type": "0x0009",
# "in_clusters": ["0x0000","0x0003","0x0004","0x0005","0x0006","0x0702","0x0708","0x0b04","0x0b05","0xfc04"],
# "out_clusters": ["0x0019"]
PROFILE_ID: 0x0104,
DEVICE_TYPE: zha.DeviceType.MAIN_POWER_OUTLET,
INPUT_CLUSTERS: [
Basic.cluster_id,
Identify.cluster_id,
Groups.cluster_id,
Scenes.cluster_id,
OnOff.cluster_id,
Metering.cluster_id,
DeviceManagement.cluster_id,
ElectricalMeasurement.cluster_id,
Diagnostic.cluster_id,
0xFC04,
],
OUTPUT_CLUSTERS: [Ota.cluster_id],
},
242: {
# "profile_id": 41440,
# "device_type": "0x0061",
# "in_clusters": [],
# "out_clusters": ["0x0021"]
PROFILE_ID: 41440,
DEVICE_TYPE: 97,
INPUT_CLUSTERS: [],
OUTPUT_CLUSTERS: [GreenPowerProxy.cluster_id],
},
},
}
replacement = {
ENDPOINTS: {
6: {
PROFILE_ID: 0x0104,
DEVICE_TYPE: zha.DeviceType.MAIN_POWER_OUTLET,
INPUT_CLUSTERS: [
Basic.cluster_id,
Identify.cluster_id,
Groups.cluster_id,
Scenes.cluster_id,
OnOff.cluster_id,
MeteringCluster,
DeviceManagement.cluster_id,
ElectricalMeasurement.cluster_id,
Diagnostic.cluster_id,
0xFC04,
],
OUTPUT_CLUSTERS: [Ota.cluster_id],
},
242: {
PROFILE_ID: 41440,
DEVICE_TYPE: 97,
INPUT_CLUSTERS: [],
OUTPUT_CLUSTERS: [GreenPowerProxy.cluster_id],
},
},
}You will need to enable the local quirk in your instalation. There is a guide about enabling custom quirks: Create in your local quirk folder a new Restart HA, remove and pair you device again. |
|
Maybe related to: #1705 |
|
With that local quirk installed and the devices re-paired the Instantaneous Demand (W) figure is right (881W), however I wonder if not the Summation Delivered now becomes a factor 1000 too low instead - which was correct before. I wonder if we're chasing the wrong thing and perhaps it's the ZCL_ATTR_METERING_SUMMATION_FORMATTING and ZCL_ATTR_METERING_DEMAND_FORMATTING attributes that isn't used correctly somewhere? I'm no Zigbee expert so this might be totally wrong but... Summation formatting has the value "bitmap8.64|8|2|1" and Demand Formatting has "none" when I try to read them. If I read the zcl metering cluster documentation correctly that should mean 01001011 = The instantaneous_demand attribute value is 873311 and current_summ_delivered is 1200 right now. A reasonable interpretation of those numbers at 873.311 W and 1.2 kWH (seems reasonable since I re-pair:ed it) |
That makes sense because
According to (i.e.) ZHA: That would be like (but don't sure because not make sense to me with the result 🤷🏻♂️): There are a few examples here: So, do you think we could have fixed it by just setting the Maybe with a little of trial and error we can get the right 'format'. You can try with: class MeteringCluster(CustomCluster, Metering):
"""Fix the Metering divisor."""
MULTIPLIER = 0x0301
DIVISOR = 0x0302
DEMMAND_FORMATTING = 0x0304
# _CONSTANT_ATTRIBUTES = {MULTIPLIER: 1, DIVISOR: 1000000}
_CONSTANT_ATTRIBUTES = {DEMMAND_FORMATTING: 75} |
|
Hmm.. Nope, doesn't work. It seems to ignore the demand_formatting stuff. I've been reading the core/homeassistant/components/zha/sensor.py code a bit to try to understand what's happening. A couple of observations: class SmartEnergySummation, starting at line 472, unit_of_measure_map: 0x00 = ENERGY_KILO_WATT_HOUR class SmartEnergyMetering, starting at line 424, unit_of_measure_map: 0x00 = POWER_WATT Notice here: no cooked-stuff with the multiplier/divisor! And unit_of_measurement is 0x00 so for Summation it will execute the cooked stuff and ignore the channel.summa_formatter, but for the Instantaneous Demand stuff it will call the demand_formatter. Looking at the formatter code in smartenergy.py, line 213, it seems to assume that unit_of_measurement always means kW: This feels a bit wrong and I think that multiplication of value_float -> value_watt by 1000 should be removed, or the value sent to it divided by 1000 in sensor.py, or add similar code that checks unit_of_measurement that summation does - this one is probably easiest. I'm no Python programmer so I'm a bit unsure how to implement a quirk that overrides this though... |
|
I modified the quirk with this and then re-pair:ed the outlet and now I get sane values for both Instantaneous Demand and Summation Delivered... However I still think that the code in core/homeassistant/components/zha/sensor.py at line 424 is suspect and possibly should be fixed similar to the code at line 472. |
|
What are you looking at in ZHA? https://github.com/home-assistant/core/blob/7614aba401ffd4041d9dac09344d37b7525c4685/homeassistant/components/zha/sensor.py#L424 The code from your block comment is from a quirk and not ZHA itself. |
|
Yes, my code is from the quirk we discussed previously in this thread. I just removed the code we were testing there. But what I suspect is the real problem (also written about above) is in core/homeassistant/components/zha/sensor.py class SmartEnergySummation, starting at line 472, unit_of_measure_map: 0x00 = ENERGY_KILO_WATT_HOUR but: class SmartEnergyMetering, starting at line 424, unit_of_measure_map: 0x00 = POWER_WATT Notice here: no cooked-stuff with the multiplier/divisor! And unit_of_measurement is 0x00 so for Summation it will execute the cooked stuff and ignore the channel.summa_formatter, but for the Instantaneous Demand stuff it will call the demand_formatter. So perhaps add the same " if self._channel.unit_of_measurement != 0:" test to the this code? I'd test this on my HA installation but I don't know how to do that since I'm running HassIO on my system. |
|
No the quirk should be setting the correct values for multiplier and divisor. |
Sure, but how? If we set divisor to 1000 (which it already is by default from the device btw) then Summation is correct, but Instantaneous becomes 1000 times to high. If we set divisor to 1000000 then Instantaneous is correct, but Summation gets 1000 times too low... |
|
I believe that there is something at least 'extrange' to me. In Zigbee specification I can read: As I understand, if there are a multiplier/divisor it aplies to all measurements. But, in ZHA there is something diferent in how is applied in |
|
Full transparency I responded the first time to just the last comment without reading the thread. Let me look through the entire thing later tonight to see what the deal is. |
|
I wish I had some other zigbee devices with power metering that provides these attributes, but my only other (zigbee) device is an Aqara Plug, and it doesn't support them (at least not at the firmware level that one is at :-). Would have been interesting to compare things :-) |
|
I may have some that support both. I’ll try to investigate tonight/tomorrow depending on availability |
You can copy all the zha folder as a |
|
Hello. |
|
OK I have devices that support both of these that do return values correctly (Sengled bulbs - not quirked) What is the device actually reporting for both of these attributes?
I am fairly certain I have some plugs in a bin somewhere that work right too. I can look for them later... the device is saying its uom is kWh... are you publishing both values in kWh? |
|
I'm sorry, don't understand what info you want. The problem we have is that the sensor named Instant... is reporting energy x1000, in my example above the correct value should be 2053,132W or even better 2053W. |
|
@krlssn please, attach the device diagnostic with a screenshoot for the current values. |
|
|
|
Instantaneous is current power draw for the device… meaning what it is consuming at that instant |
|
The multiplier/divisor attributes are read only and couldn't be changed from UI. |
|
Looking at the data I have come to the same conclusion as David (but much slower):
Putting 2 plugs in serial (the affected one and another well working one) would confirm the suspicions. So probably the solution goes through the quirk that Peter proposes. For these attributes, the formatting don't play any role in the code (also, didn't would change the value, just the format), so not relevant. |
|
So you mean that if Schneider fix a FW update of the device it would be fixed? Does this only affect HA (ZHA) connected devices or devices connected through Wisers own app too? |
|
What I mean is, if that is a firmware bug as it seems, probably SE will patch it. Then it could be that we can find devices with new firmware version (because SE sells the devices with the new version or because users update its devices through SE gateway). I don't know if Wiser app exposes the values correctly or not, but every manufacturer can do a particular interpretation from the Zigbee specifications, so maybe they in its app are showing the values in other way (and fine with the metering values) despite the device don't follow the standar.
My point is to compare between 2 devices with 'instantaneous demmand' metering to see its cluster attribute values. |
|
Ok, then I guess FB wallplug don't talk "the same language" and it won't help here. No idea if Schneider will fix fw, if it is no problem in their own app I guess their priority is lower and a fix from you would be awesome. Understand the problem if/when different FW appear. |
|
And here it is...
That quirk is applied to the SE devices: We don't thank Z2M enough for the work they do there. @ptrrkssn if you don't mind you can create the PR yourself, if possible also adding the signature for the |
|
Sounds perfect😄 What do I need to do/what should I add to my system to get the correct scaled values? |
|
You can wait to the next HA release to see if the quirk has been added to the version. The quirk would be the one from #1889 (comment) There is a guide about enabling custom quirks: Create in your local quirk folder a new Restart HA, remove and pair you device again. |
|
Thank you! If I wait until it comes in future HA release, do I have to unpair/pair devices to get correct values or do it "autoupdate"? |
|
I can't tell you for sure, but as a standar procedure I will suggest you to perform the unpair/pair to be sure. |
|
Hi |
|
There's no an easy way to know it. The first thing will be to have a PR/fix/quirk to look for. And there's no PR yet for this issue. So, until someone creates a PR and that would be merged the fix don't be available to all the users. |
|
Update:
|
|
I would suggest to create a new I would put all together in the same file and the same quirk, probably in a signature = {
MODELS_INFO: [
("Schneider Electric", "SOCKET/OUTLET/1"),
("Schneider Electric", "SOCKET/OUTLET/2"),
],
ENDPOINTS: {
.../... |
|
New *py file if someone needs it. Working for me with both WDE002182 (2way) and WDE002172 (1way). Gives me correct values in "instantaneous_demand". Checked the site https://github.com/zigpy/zha-device-handlers/compare but not sure what to do, needs comparing to open PR and this stuff is new to me so I dont know what to "compare" to open a new pull request. |
TheJulianJES
added
the
custom quirk available
|
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions. |
|
I just added my 2-way outlet and ran into this very issue. I am using the latest version of Home Assistant (running on a HA Green). Using SkyConnect and ZHA. So is there a way to get this merged into an actual release or how does that work? |
|
As I understand the fix (quirk) needs to be added as a pull request first, then it can be added into future release of ZHA integration in HA. I didnt manage how to do this. I still need to "inactivate" and reactivate the quirk every time I update HA (and some other steps). Had been very nice to get this fixed. I think it's ZHA people who need to merge this when the PR is created.
I read somewhere that zigbee2mqtt integration has fixed this, but i'm not very happy to rebuild my entire Zigbee network. Feel free to try opening a pull request, this stuff is new to me, I don't think it should be that hard to do 😏
|
Well I've been looking for a reason to get into Python... So I guess this is it. Will look into creating a PR. |
Based on the code supplied by krlssn in comment zigpy#1889 (comment)
|
This PR should mostly be ready now: From what I've read in this thread, it seems like we can't use the formatter attributes for this, as that also affects the total summation delivered. Please confirm if the following code works when it's installed as a custom quirk. """Schneider Electric (Wiser) Outlet Quirks."""
from zigpy.profiles import zgp, zha
from zigpy.quirks import CustomCluster, CustomDevice
from zigpy.zcl.clusters.general import (
Basic,
GreenPowerProxy,
Groups,
Identify,
OnOff,
Ota,
Scenes,
)
from zigpy.zcl.clusters.homeautomation import Diagnostic, ElectricalMeasurement
from zigpy.zcl.clusters.smartenergy import DeviceManagement, Metering
from zhaquirks.const import (
DEVICE_TYPE,
ENDPOINTS,
INPUT_CLUSTERS,
MODELS_INFO,
OUTPUT_CLUSTERS,
PROFILE_ID,
)
class MeteringCluster(CustomCluster, Metering):
"""Custom Metering cluster to fix instantaneous demand value multiplied by 1000."""
def _update_attribute(self, attrid, value):
if attrid == self.AttributeDefs.instantaneous_demand.id:
value = value / 1000
super()._update_attribute(attrid, value)
class SocketOutlet(CustomDevice):
"""Schneider Electric Socket outlet WDE002182, WDE002172."""
signature = {
MODELS_INFO: [
("Schneider Electric", "SOCKET/OUTLET/1"),
("Schneider Electric", "SOCKET/OUTLET/2"),
],
ENDPOINTS: {
# <SimpleDescriptor endpoint=1 profile=260 device_type=9
# device_version=0
# input_clusters=[0, 3, 4, 5, 6, 1794, 1800, 2820, 2821, 64516] output_clusters=[25]>
6: {
PROFILE_ID: zha.PROFILE_ID,
DEVICE_TYPE: zha.DeviceType.MAIN_POWER_OUTLET,
INPUT_CLUSTERS: [
Basic.cluster_id,
Identify.cluster_id,
Groups.cluster_id,
Scenes.cluster_id,
OnOff.cluster_id,
Metering.cluster_id,
DeviceManagement.cluster_id,
ElectricalMeasurement.cluster_id,
Diagnostic.cluster_id,
0xFC04,
],
OUTPUT_CLUSTERS: [
Ota.cluster_id,
],
},
242: {
PROFILE_ID: zgp.PROFILE_ID,
DEVICE_TYPE: zgp.DeviceType.PROXY_BASIC,
INPUT_CLUSTERS: [],
OUTPUT_CLUSTERS: [
GreenPowerProxy.cluster_id,
],
},
},
}
replacement = {
ENDPOINTS: {
6: {
PROFILE_ID: zha.PROFILE_ID,
DEVICE_TYPE: zha.DeviceType.MAIN_POWER_OUTLET,
INPUT_CLUSTERS: [
Basic.cluster_id,
Identify.cluster_id,
Groups.cluster_id,
Scenes.cluster_id,
OnOff.cluster_id,
MeteringCluster,
DeviceManagement.cluster_id,
ElectricalMeasurement.cluster_id,
Diagnostic.cluster_id,
0xFC04,
],
OUTPUT_CLUSTERS: [
Ota.cluster_id,
],
},
242: {
PROFILE_ID: zgp.PROFILE_ID,
DEVICE_TYPE: zgp.DeviceType.PROXY_BASIC,
INPUT_CLUSTERS: [],
OUTPUT_CLUSTERS: [
GreenPowerProxy.cluster_id,
],
},
},
} |
|
@TheJulianJES Loaded with your code, seems to work for me. Shows correct values. I guess you haven't changed anything with summation delivered, that one takes some time (hours) to see if it's correct. Hope this can lead to get the solution into ZHA so I won't have to use the local quirk, would be nice to be able to update HA without de- and reactivate the quirk every time! I have another filename but inside my file is the code in your message above (#1889 (comment)). |
|
Thanks for testing! |
|
Update/permanent fix: Updated to HA Core 2024.3.1 today and now everything seems to work without enabling my local/custom quirk again after this update. Instantaneous demand now gives me correct values "out of the box". Thank you @TheJulianJES and everybody else in this thread that helped to fix this issue!
|
Describe the bug
Schneider Exxact Wiser outlet seems to report W and Wh a factor 1000 off (or HA/ZHA seems to think so at least). Ie a 900W load is reported as 900kW
To Reproduce
Steps to reproduce the behavior:
Plug in an 600-900W electrical element into the outlet, check the power usage in Home Assistant for the device...
Expected behavior
W & Wh numbers displayed a factor 1000 less.. In the screenshot below it should be 881W not 881840W...
Screenshots
Device signature
Diagnostic information
Additional logs
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: