Closed ptrrkssn closed 1 week ago
javicalle
commented
1 year ago Can you try to read from the cluster MeteringCluster (Endpoint id: 1, Id: 0x0702, Type: in) the attributes divisor (id: 0x0302) and multiplier (id: 0x0301)?
You can do it from the device view -> Admin Zigbee device --> Clusters Select the cluster and attribute and push the "get attribute" button.
Once you get the values try to increasse the divisor value x1000.
ptrrkssn
commented
1 year ago 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.
javicalle
commented
1 year ago 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?
ptrrkssn
commented
1 year ago 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 SUP 2022.10.2 OS 9.3 Frontend 20221102.1
javicalle
commented
1 year ago Have you tried to remove and pair the device again? It seems that the value is already here so no clear to me if the quirk would work.
ptrrkssn
commented
1 year ago 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.
javicalle
commented
1 year ago Is the same behavior in all three devices?
ptrrkssn
commented
1 year ago Yes, same on all three. Firmware 0x020612ff, sw_build_id 002.006.018 R
javicalle
commented
1 year ago I still believe that the problem must be elsewhere but if you want to try, there is a quirk for your device:
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 schneider_plug.py file and put the suggested quirk in file.
Restart HA, remove and pair you device again. Check that the device is loading the quirk and that the device signature has changed.
javicalle
commented
1 year ago Maybe related to: #1705
ptrrkssn
commented
1 year ago 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 = 0 = do not suppress leading zeros 1 = ? 001 = 1 digit to the right of decimal point 011 = 3 digits to the left of the decimal point
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)
javicalle
commented
1 year ago 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.
That makes sense because instantaneous_demand and current_summ_delivered are afected by the same multiplier and divisor:
If I read the zcl metering cluster documentation correctly that should mean 01001011 = 0 = do not suppress leading zeros 1 = ? 001 = 1 digit to the right of decimal point 011 = 3 digits to the left of the decimal point
According to (i.e.) ZHA:
That would be like (but don't sure because not make sense to me with the result 🤷🏻♂️): 0 = do not suppress leading zeros 1001 = 9 digits to the left of decimal point (bits 3-6) 011 = 3 digits to the right of the decimal point (bits 0-2)
There are a few examples here:
So, do you think we could have fixed it by just setting the demand_formatting?
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 ...
def formatter(self, value: int) -> int | float:
"""Numeric pass-through formatter."""
if self._channel.unit_of_measurement != 0:
return self._channel.summa_formatter(value)
cooked = float(self._channel.multiplier * value) / self._channel.divisor
return round(cooked, 3)class SmartEnergyMetering, starting at line 424, unit_of_measure_map: 0x00 = POWER_WATT ...
def formatter(self, value: int) -> int | float:
"""Pass through channel formatter."""
return self._channel.demand_formatter(value)
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:
def _formatter_function(
self, selector: FormatSelector, value: int
) -> int | float | str:
"""Return formatted value for display."""
value_float = value * self.multiplier / self.divisor
if self.unit_of_measurement == 0:
# Zigbee spec power unit is kW, but we show the value in W
value_watt = value_float * 1000
if value_watt < 100:
return round(value_watt, 1)
return round(value_watt)
if selector == self.FormatSelector.SUMMATION:
assert self._summa_format
return self._summa_format.format(value_float).lstrip()
assert self._format_spec
return self._format_spec.format(value_float).lstrip()
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...
ptrrkssn
commented
1 year ago 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.
class MeteringCluster(CustomCluster, Metering):
"""Fix the Instataneous Demand value."""
INSTANTANEOUS_DEMAND = 0x0400
def _update_attribute(self, attrid, value):
if attrid == self.INSTANTANEOUS_DEMAND:
value = value / 1000.0
super()._update_attribute(attrid, value)
dmulcahey
commented
1 year ago 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.
ptrrkssn
commented
1 year ago 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 where:
class SmartEnergySummation, starting at line 472, unit_of_measure_map: 0x00 = ENERGY_KILO_WATT_HOUR
def formatter(self, value: int) -> int | float:
"""Numeric pass-through formatter."""
if self._channel.unit_of_measurement != 0:
return self._channel.summa_formatter(value)
cooked = float(self._channel.multiplier * value) / self._channel.divisor
return round(cooked, 3)but:
class SmartEnergyMetering, starting at line 424, unit_of_measure_map: 0x00 = POWER_WATT
def formatter(self, value: int) -> int | float:
"""Pass through channel formatter."""
return self._channel.demand_formatter(value)
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.
dmulcahey
commented
1 year ago No the quirk should be setting the correct values for multiplier and divisor.
dmulcahey
commented
1 year ago ptrrkssn
commented
1 year ago 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...
javicalle
commented
1 year ago I believe that there is something at least 'extrange' to me.
In Zigbee specification I can read:
D.3.2.2.4Formatting
The following set of attributes provides the ratios and formatting hints required to transform the
received summations, consumptions, temperatures, or demands/ rates into displayable values.
If the Multiplier and Divisor attribute values are non-zero, they are used in conjunction with the
SummationFormatting, ConsumptionFormatting, DemandFormatting, and
TemperatureFormatting attributes.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 SmartEnergyMetering and SmartEnergySummation. Shouldn't it be applied in the same way in both cases?
dmulcahey
commented
1 year ago 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.
ptrrkssn
commented
1 year ago 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 :-)
dmulcahey
commented
1 year ago I may have some that support both. I’ll try to investigate tonight/tomorrow depending on availability
javicalle
commented
1 year ago 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.
You can copy all the zha folder as a custom_components in HA and edit the desired class.
krlssn
commented
1 year ago Hello.
I have installed 2 WDE002172 (Wiser 1 way outlet), same as @ptrrkssn but with one outlet. Exactly the same problem. Following this and hope you find a solution, if I can help with anything please tell me. Home assistant on NUC, Conbee II stick (ZHA), FW on my sockets is 0x020612ff
Picture below is with washing machine, even I think summation (kWh) is correct and Instantaneous (W) is wrong.
dmulcahey
commented
1 year ago 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?
krlssn
commented
1 year ago 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.
javicalle
commented
1 year ago @krlssn please, attach the device diagnostic with a screenshoot for the current values.
krlssn
commented
1 year ago 
Like this?
dmulcahey
commented
1 year ago Instantaneous is current power draw for the device… meaning what it is consuming at that instant
javicalle
commented
1 year ago Yes, but also the device diagnostics (to the Right of "KONFIGURERA OM", the 3 dots, 'download diagnostics').
It will be better if there are some load in the device that will give a "instantaneous demand"
krlssn
commented
1 year ago 
This is with 767W load (235Vx3,3A=about 767W)
And this was much code😊
{
"home_assistant": {
"installation_type": "Home Assistant OS",
"version": "2022.11.2",
"dev": false,
"hassio": true,
"virtualenv": false,
"python_version": "3.10.7",
"docker": true,
"arch": "x86_64",
"timezone": "Europe/Stockholm",
"os_name": "Linux",
"os_version": "5.15.74",
"supervisor": "2022.10.2",
"host_os": "Home Assistant OS 9.3",
"docker_version": "20.10.18",
"chassis": "embedded",
"run_as_root": true
},
"custom_components": {},
"integration_manifest": {
"domain": "zha",
"name": "Zigbee Home Automation",
"config_flow": true,
"documentation": "https://www.home-assistant.io/integrations/zha",
"requirements": [
"bellows==0.34.2",
"pyserial==3.5",
"pyserial-asyncio==0.6",
"zha-quirks==0.0.85",
"zigpy-deconz==0.19.0",
"zigpy==0.51.5",
"zigpy-xbee==0.16.2",
"zigpy-zigate==0.10.3",
"zigpy-znp==0.9.1"
],
"usb": [
{
"vid": "10C4",
"pid": "EA60",
"description": "*2652*",
"known_devices": [
"slae.sh cc2652rb stick"
]
},
{
"vid": "1A86",
"pid": "55D4",
"description": "*sonoff*plus*",
"known_devices": [
"sonoff zigbee dongle plus v2"
]
},
{
"vid": "10C4",
"pid": "EA60",
"description": "*sonoff*plus*",
"known_devices": [
"sonoff zigbee dongle plus"
]
},
{
"vid": "10C4",
"pid": "EA60",
"description": "*tubeszb*",
"known_devices": [
"TubesZB Coordinator"
]
},
{
"vid": "1A86",
"pid": "7523",
"description": "*tubeszb*",
"known_devices": [
"TubesZB Coordinator"
]
},
{
"vid": "1A86",
"pid": "7523",
"description": "*zigstar*",
"known_devices": [
"ZigStar Coordinators"
]
},
{
"vid": "1CF1",
"pid": "0030",
"description": "*conbee*",
"known_devices": [
"Conbee II"
]
},
{
"vid": "10C4",
"pid": "8A2A",
"description": "*zigbee*",
"known_devices": [
"Nortek HUSBZB-1"
]
},
{
"vid": "0403",
"pid": "6015",
"description": "*zigate*",
"known_devices": [
"ZiGate+"
]
},
{
"vid": "10C4",
"pid": "EA60",
"description": "*zigate*",
"known_devices": [
"ZiGate"
]
},
{
"vid": "10C4",
"pid": "8B34",
"description": "*bv 2010/10*",
"known_devices": [
"Bitron Video AV2010/10"
]
}
],
"codeowners": [
"@dmulcahey",
"@adminiuga",
"@puddly"
],
"zeroconf": [
{
"type": "_esphomelib._tcp.local.",
"name": "tube*"
},
{
"type": "_zigate-zigbee-gateway._tcp.local.",
"name": "*zigate*"
},
{
"type": "_zigstar_gw._tcp.local.",
"name": "*zigstar*"
}
],
"dependencies": [
"file_upload"
],
"after_dependencies": [
"onboarding",
"usb",
"zeroconf"
],
"iot_class": "local_polling",
"loggers": [
"aiosqlite",
"bellows",
"crccheck",
"pure_pcapy3",
"zhaquirks",
"zigpy",
"zigpy_deconz",
"zigpy_xbee",
"zigpy_zigate",
"zigpy_znp"
],
"is_built_in": true
},
"data": {
"ieee": "**REDACTED**",
"nwk": 7696,
"manufacturer": "Schneider Electric",
"model": "SOCKET/OUTLET/1",
"name": "Schneider Electric SOCKET/OUTLET/1",
"quirk_applied": false,
"quirk_class": "zigpy.device.Device",
"manufacturer_code": 4190,
"power_source": "Mains",
"lqi": 255,
"rssi": -70,
"last_seen": "2022-11-16T18:51:46",
"available": true,
"device_type": "Router",
"signature": {
"node_descriptor": "NodeDescriptor(logical_type=<LogicalType.Router: 1>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress|RxOnWhenIdle|MainsPowered|FullFunctionDevice: 142>, manufacturer_code=4190, maximum_buffer_size=82, maximum_incoming_transfer_size=82, server_mask=11264, maximum_outgoing_transfer_size=82, descriptor_capability_field=<DescriptorCapability.NONE: 0>, *allocate_address=True, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=False, *is_full_function_device=True, *is_mains_powered=True, *is_receiver_on_when_idle=True, *is_router=True, *is_security_capable=False)",
"endpoints": {
"6": {
"profile_id": 260,
"device_type": "0x0009",
"in_clusters": [
"0x0000",
"0x0003",
"0x0004",
"0x0005",
"0x0006",
"0x0702",
"0x0708",
"0x0b04",
"0x0b05",
"0xfc04"
],
"out_clusters": [
"0x0019"
]
},
"242": {
"profile_id": 41440,
"device_type": "0x0061",
"in_clusters": [],
"out_clusters": [
"0x0021"
]
}
}
},
"active_coordinator": false,
"entities": [
{
"entity_id": "button.tvattmaskin_identify",
"name": "Schneider Electric SOCKET/OUTLET/1"
},
{
"entity_id": "sensor.tvattmaskin_instantaneous_demand",
"name": "Schneider Electric SOCKET/OUTLET/1"
},
{
"entity_id": "sensor.tvattmaskin_power_factor",
"name": "Schneider Electric SOCKET/OUTLET/1"
},
{
"entity_id": "sensor.tvattmaskin_rms_current",
"name": "Schneider Electric SOCKET/OUTLET/1"
},
{
"entity_id": "sensor.tvattmaskin_rms_voltage",
"name": "Schneider Electric SOCKET/OUTLET/1"
},
{
"entity_id": "select.tvattmaskin_start_up_behavior",
"name": "Schneider Electric SOCKET/OUTLET/1"
},
{
"entity_id": "sensor.tvattmaskin_summation_delivered",
"name": "Schneider Electric SOCKET/OUTLET/1"
},
{
"entity_id": "switch.tvattmaskin_switch",
"name": "Schneider Electric SOCKET/OUTLET/1"
}
],
"neighbors": [
{
"device_type": "Coordinator",
"rx_on_when_idle": "On",
"relationship": "Sibling",
"extended_pan_id": "**REDACTED**",
"ieee": "**REDACTED**",
"nwk": "0x0000",
"permit_joining": "Unknown",
"depth": "0",
"lqi": "208"
},
{
"device_type": "Router",
"rx_on_when_idle": "On",
"relationship": "Sibling",
"extended_pan_id": "**REDACTED**",
"ieee": "**REDACTED**",
"nwk": "0x04BB",
"permit_joining": "Unknown",
"depth": "15",
"lqi": "119"
},
{
"device_type": "Router",
"rx_on_when_idle": "On",
"relationship": "Sibling",
"extended_pan_id": "**REDACTED**",
"ieee": "**REDACTED**",
"nwk": "0x0DC8",
"permit_joining": "Unknown",
"depth": "15",
"lqi": "110"
},
{
"device_type": "Router",
"rx_on_when_idle": "On",
"relationship": "Sibling",
"extended_pan_id": "**REDACTED**",
"ieee": "**REDACTED**",
"nwk": "0x4071",
"permit_joining": "Unknown",
"depth": "15",
"lqi": "255"
},
{
"device_type": "Router",
"rx_on_when_idle": "On",
"relationship": "Sibling",
"extended_pan_id": "**REDACTED**",
"ieee": "**REDACTED**",
"nwk": "0x6887",
"permit_joining": "Unknown",
"depth": "15",
"lqi": "47"
},
{
"device_type": "Router",
"rx_on_when_idle": "On",
"relationship": "Sibling",
"extended_pan_id": "**REDACTED**",
"ieee": "**REDACTED**",
"nwk": "0x9C8F",
"permit_joining": "Unknown",
"depth": "15",
"lqi": "73"
},
{
"device_type": "Router",
"rx_on_when_idle": "On",
"relationship": "Sibling",
"extended_pan_id": "**REDACTED**",
"ieee": "**REDACTED**",
"nwk": "0xB297",
"permit_joining": "Unknown",
"depth": "15",
"lqi": "74"
},
{
"device_type": "Router",
"rx_on_when_idle": "On",
"relationship": "Parent",
"extended_pan_id": "**REDACTED**",
"ieee": "**REDACTED**",
"nwk": "0xF351",
"permit_joining": "Unknown",
"depth": "15",
"lqi": "103"
}
],
"endpoint_names": [
{
"name": "MAIN_POWER_OUTLET"
},
{
"name": "unknown 97 device_type of 0xa1e0 profile id"
}
],
"user_given_name": "Tv\u00e4ttmaskin",
"device_reg_id": "2424302b35adbc47618ca9aed109f849",
"area_id": "tvattstuga",
"cluster_details": {
"6": {
"device_type": {
"name": "MAIN_POWER_OUTLET",
"id": 9
},
"profile_id": 260,
"in_clusters": {
"0x0000": {
"endpoint_attribute": "basic",
"attributes": {
"0x0004": {
"attribute_name": "manufacturer",
"value": "Schneider Electric"
},
"0x0005": {
"attribute_name": "model",
"value": "SOCKET/OUTLET/1"
}
},
"unsupported_attributes": {}
},
"0x0003": {
"endpoint_attribute": "identify",
"attributes": {},
"unsupported_attributes": {}
},
"0x0004": {
"endpoint_attribute": "groups",
"attributes": {},
"unsupported_attributes": {}
},
"0x0005": {
"endpoint_attribute": "scenes",
"attributes": {},
"unsupported_attributes": {}
},
"0x0006": {
"endpoint_attribute": "on_off",
"attributes": {
"0x0000": {
"attribute_name": "on_off",
"value": 1
},
"0x4003": {
"attribute_name": "start_up_on_off",
"value": 255
}
},
"unsupported_attributes": {}
},
"0x0702": {
"endpoint_attribute": "smartenergy_metering",
"attributes": {
"0x0000": {
"attribute_name": "current_summ_delivered",
"value": 568
},
"0x0200": {
"attribute_name": "status",
"value": 0
},
"0x0204": {
"attribute_name": "extended_status",
"value": 0
},
"0x0207": {
"attribute_name": "iambient_consumption_indicator",
"value": 2
},
"0x0300": {
"attribute_name": "unit_of_measure",
"value": 0
},
"0x0301": {
"attribute_name": "multiplier",
"value": 1
},
"0x0302": {
"attribute_name": "divisor",
"value": 1000
},
"0x0303": {
"attribute_name": "summation_formatting",
"value": 75
},
"0x0306": {
"attribute_name": "metering_device_type",
"value": 0
},
"0x0400": {
"attribute_name": "instantaneous_demand",
"value": 755113
}
},
"unsupported_attributes": {
"0x0304": {
"attribute_name": "demand_formatting"
},
"0x0020": {
"attribute_name": "active_register_tier_delivered"
}
}
},
"0x0708": {
"endpoint_attribute": "smartenergy_device_management",
"attributes": {},
"unsupported_attributes": {}
},
"0x0b04": {
"endpoint_attribute": "electrical_measurement",
"attributes": {
"0x0000": {
"attribute_name": "measurement_type",
"value": 8
},
"0x0505": {
"attribute_name": "rms_voltage",
"value": 235
},
"0x0508": {
"attribute_name": "rms_current",
"value": 3269
},
"0x0602": {
"attribute_name": "ac_current_multiplier",
"value": 1
},
"0x0603": {
"attribute_name": "ac_current_divisor",
"value": 1000
}
},
"unsupported_attributes": {
"0x0300": {
"attribute_name": "ac_frequency"
},
"0x0601": {
"attribute_name": "ac_voltage_divisor"
},
"0x0302": {
"attribute_name": "ac_frequency_max"
},
"0x0600": {
"attribute_name": "ac_voltage_multiplier"
},
"0x0604": {
"attribute_name": "ac_power_multiplier"
},
"0x0605": {
"attribute_name": "ac_power_divisor"
},
"0x0507": {
"attribute_name": "rms_voltage_max"
},
"0x0401": {
"attribute_name": "ac_frequency_divisor"
},
"0x0400": {
"attribute_name": "ac_frequency_multiplier"
},
"0x050a": {
"attribute_name": "rms_current_max"
},
"0x050b": {
"attribute_name": "active_power"
},
"0x0403": {
"attribute_name": "power_divisor"
},
"0x050d": {
"attribute_name": "active_power_max"
},
"0x050f": {
"attribute_name": "apparent_power"
},
"0x0a0d": {
"attribute_name": "active_power_max_ph_c"
},
"0x0402": {
"attribute_name": "power_multiplier"
}
}
},
"0x0b05": {
"endpoint_attribute": "diagnostic",
"attributes": {},
"unsupported_attributes": {}
},
"0xfc04": {
"endpoint_attribute": "manufacturer_specific",
"attributes": {},
"unsupported_attributes": {}
}
},
"out_clusters": {
"0x0019": {
"endpoint_attribute": "ota",
"attributes": {},
"unsupported_attributes": {}
}
}
},
"242": {
"device_type": {
"name": "unknown",
"id": 97
},
"profile_id": 41440,
"in_clusters": {},
"out_clusters": {
"0x0021": {
"endpoint_attribute": "green_power",
"attributes": {},
"unsupported_attributes": {}
}
}
}
}
}
}Please, edit your comment and put the diagnostics inside ``` marks like:
All the diagnostics here
So is the device doing it’s own conversion to watts on the instantaneous demand attribute?
javicalle
commented
1 year ago If I have read the specification correctly, the xxxxx_formating values only affect how the information is presented and not the values/units.
And if I have also interpreted correctly how the multiplier and divisor values act, they affect all the values provided by the cluster.
I am going to base my comments on those assumptions and from the following information:
This would lead to the values: Summation delivered = 6931*1/1000 kWh = 6,931 kWh (formmating appart) Instantaneous demmand = 872121*1/1000 ¿kW? = 872,121 kW = 872121 W
That is what the screenshoot show to us (so it seems that the aritmetics are fine in ZHA), but Peter believe that that 872,121kW is incorrect and that there is a problem (or maybe a quirk is needed?).
krlssn
commented
1 year ago @dmulcahey I don't know, but Current value is correct and fair, these stuff is new to me, the problem is "Instantaneous demmand" is not correct, should be divided with 1000. Earlier in the thread someone tested to change something, then the kWh values in Summation became incorrect instead. Excuse my english, I think I got the code above correct after a few attempts😊
javicalle
commented
1 year ago Looking at the ZHA part:
at the smartenergy channel, the formatter multiplied/divided the value: https://github.com/home-assistant/core/blob/bc146a09dba6df6eaec429039f6e1efcfbd1123f/homeassistant/components/zha/core/channels/smartenergy.py#L217
and then in the ZHA sensor part there are 2 behaviors:
SmartEnergyMetering the value is just formatted:
https://github.com/home-assistant/core/blob/bc146a09dba6df6eaec429039f6e1efcfbd1123f/homeassistant/components/zha/sensor.py#L448-L450SmartEnergySummation (if self._channel.unit_of_measurement == 0) Sorry if I'm making unrelated/unnecessary noise.
krlssn
commented
1 year ago I'm happy with all help I can get, for me this coding stuff is totally new, feels like the only problem is this sensor is showing the correct value except it is somewhere multiplied with 1000. You cant draw 767 189 W from a normal outlet but 767,189 is no problem. In a perfect world the sensor have given me 767W. If I test the same sensor in for example zigbee2mqtt could it possibly make any diffenerce, or is this device info picked from the same place regardless which integration I use? I guess you understand now that I'm new to Home assistant 😉
javicalle
commented
1 year ago Ummmm, the formatter is the same for both measurements: https://github.com/home-assistant/core/blob/bc146a09dba6df6eaec429039f6e1efcfbd1123f/homeassistant/components/zha/core/channels/smartenergy.py#L230-L231
And the formatter does the kW (from Zigbee standar) to W (the uom that HA uses) here: https://github.com/home-assistant/core/blob/bc146a09dba6df6eaec429039f6e1efcfbd1123f/homeassistant/components/zha/core/channels/smartenergy.py#L218-L220
Then in the sensors part, the unit_of_measure_map uses:
0x00: POWER_WATT for the SmartEnergyMetering0x00: ENERGY_KILO_WATT_HOUR for the SmartEnergySummationOr I missing something or that can't be fine because the formatter makes the kW --> W conversion always that uom == 0, and that is true in both cases.
If the conversion is done always, the UI oum must be in W (or W per hour), isn't it?
dmulcahey
commented
1 year ago Ummmm, the formatter is the same for both measurements: https://github.com/home-assistant/core/blob/bc146a09dba6df6eaec429039f6e1efcfbd1123f/homeassistant/components/zha/core/channels/smartenergy.py#L230-L231
And the formatter does the kW (from Zigbee standar) to W (the uom that HA uses) here: https://github.com/home-assistant/core/blob/bc146a09dba6df6eaec429039f6e1efcfbd1123f/homeassistant/components/zha/core/channels/smartenergy.py#L218-L220
Then in the sensors part, the
unit_of_measure_mapuses:
0x00: POWER_WATTfor theSmartEnergyMetering0x00: ENERGY_KILO_WATT_HOURfor theSmartEnergySummationOr I missing something or that can't be fine because the formatter makes the kW --> W conversion always that
uom == 0, and that is true in both cases. If the conversion is done always, the UI oum must be in W (or W per hour), isn't it?
Summation only uses the formatted if the UOM is NOT 0: https://github.com/home-assistant/core/blob/bc146a09dba6df6eaec429039f6e1efcfbd1123f/homeassistant/components/zha/sensor.py#L498
and I have non quirked devices that this is working correctly for…
javicalle
commented
1 year ago Summation only uses the formatted if the UOM is NOT 0
🤦🏻♂️, right
David, do you mind share the diagnostic from your device?
I am out of ideas. Maybe the device need to quirk the value?
ptrrkssn
commented
1 year ago Hmm.. Looking at the diagnostic output there is a n interesting difference between summation and demand:
"0x0702": {
"endpoint_attribute": "smartenergy_metering",
"attributes": {
"0x0000": {
"attribute_name": "current_summ_delivered",
"value": 6931
},
...
"0x0303": {
"attribute_name": "summation_formatting",
"value": 75
},
...
"0x0400": {
"attribute_name": "instantaneous_demand",
"value": 872121
}
},
"unsupported_attributes": {
"0x0304": {
"attribute_name": "demand_formatting"
}
}Notice that "demand_formatting" is listed under "unsupported_attributes" from the Schneider devices (both). Is that handled as if it has the value 0?
We tried setting that attribute via a quirk to 75, but it made no difference - but I wonder if it is ignored since it's listed under "unsupported_attributes". Hmm..
In the Sengled bulbs - what does they report for "demand_formatting"?
dmulcahey
commented
1 year ago {
"home_assistant": {
"installation_type": "Home Assistant Core",
"version": "2022.12.0.dev0",
"dev": true,
"hassio": false,
"virtualenv": true,
"python_version": "3.10.2",
"docker": false,
"arch": "x86_64",
"timezone": "UTC",
"os_name": "Darwin",
"os_version": "12.6.1",
"run_as_root": false
},
"custom_components": {},
"integration_manifest": {
"domain": "zha",
"name": "Zigbee Home Automation",
"config_flow": true,
"documentation": "https://www.home-assistant.io/integrations/zha",
"requirements": [
"bellows==0.34.2",
"pyserial==3.5",
"pyserial-asyncio==0.6",
"zha-quirks==0.0.86",
"zigpy-deconz==0.19.0",
"zigpy==0.51.5",
"zigpy-xbee==0.16.2",
"zigpy-zigate==0.10.3",
"zigpy-znp==0.9.1"
],
"usb": [
{
"vid": "10C4",
"pid": "EA60",
"description": "*2652*",
"known_devices": [
"slae.sh cc2652rb stick"
]
},
{
"vid": "1A86",
"pid": "55D4",
"description": "*sonoff*plus*",
"known_devices": [
"sonoff zigbee dongle plus v2"
]
},
{
"vid": "10C4",
"pid": "EA60",
"description": "*sonoff*plus*",
"known_devices": [
"sonoff zigbee dongle plus"
]
},
{
"vid": "10C4",
"pid": "EA60",
"description": "*tubeszb*",
"known_devices": [
"TubesZB Coordinator"
]
},
{
"vid": "1A86",
"pid": "7523",
"description": "*tubeszb*",
"known_devices": [
"TubesZB Coordinator"
]
},
{
"vid": "1A86",
"pid": "7523",
"description": "*zigstar*",
"known_devices": [
"ZigStar Coordinators"
]
},
{
"vid": "1CF1",
"pid": "0030",
"description": "*conbee*",
"known_devices": [
"Conbee II"
]
},
{
"vid": "10C4",
"pid": "8A2A",
"description": "*zigbee*",
"known_devices": [
"Nortek HUSBZB-1"
]
},
{
"vid": "0403",
"pid": "6015",
"description": "*zigate*",
"known_devices": [
"ZiGate+"
]
},
{
"vid": "10C4",
"pid": "EA60",
"description": "*zigate*",
"known_devices": [
"ZiGate"
]
},
{
"vid": "10C4",
"pid": "8B34",
"description": "*bv 2010/10*",
"known_devices": [
"Bitron Video AV2010/10"
]
}
],
"codeowners": [
"@dmulcahey",
"@adminiuga",
"@puddly"
],
"zeroconf": [
{
"type": "_esphomelib._tcp.local.",
"name": "tube*"
},
{
"type": "_zigate-zigbee-gateway._tcp.local.",
"name": "*zigate*"
},
{
"type": "_zigstar_gw._tcp.local.",
"name": "*zigstar*"
}
],
"dependencies": [
"file_upload"
],
"after_dependencies": [
"onboarding",
"usb",
"zeroconf"
],
"iot_class": "local_polling",
"loggers": [
"aiosqlite",
"bellows",
"crccheck",
"pure_pcapy3",
"zhaquirks",
"zigpy",
"zigpy_deconz",
"zigpy_xbee",
"zigpy_zigate",
"zigpy_znp"
],
"is_built_in": true
},
"data": {
"ieee": "**REDACTED**",
"nwk": 11288,
"manufacturer": "sengled",
"model": "E12-N14",
"name": "sengled E12-N14",
"quirk_applied": false,
"quirk_class": "zigpy.device.Device",
"manufacturer_code": 4448,
"power_source": "Mains",
"lqi": null,
"rssi": null,
"last_seen": "2022-11-16T10:37:50",
"available": false,
"device_type": "EndDevice",
"signature": {
"node_descriptor": "NodeDescriptor(logical_type=<LogicalType.EndDevice: 2>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress|RxOnWhenIdle|MainsPowered: 140>, manufacturer_code=4448, maximum_buffer_size=82, maximum_incoming_transfer_size=82, server_mask=0, maximum_outgoing_transfer_size=82, descriptor_capability_field=<DescriptorCapability.NONE: 0>, *allocate_address=True, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=True, *is_full_function_device=False, *is_mains_powered=True, *is_receiver_on_when_idle=True, *is_router=False, *is_security_capable=False)",
"endpoints": {
"1": {
"profile_id": 260,
"device_type": "0x0101",
"in_clusters": [
"0x0000",
"0x0003",
"0x0004",
"0x0005",
"0x0006",
"0x0008",
"0x0702",
"0x0b05"
],
"out_clusters": [
"0x0019"
]
}
}
},
"active_coordinator": false,
"entities": [
{
"entity_id": "sensor.sengled_e12_n14_smartenergymetering",
"name": "sengled E12-N14"
},
{
"entity_id": "sensor.sengled_e12_n14_smartenergysummation",
"name": "sengled E12-N14"
},
{
"entity_id": "number.sengled_e12_n14_onlevelconfiguration",
"name": "sengled E12-N14"
},
{
"entity_id": "button.sengled_e12_n14_identifybutton",
"name": "sengled E12-N14"
},
{
"entity_id": "light.sengled_e12_n14_light",
"name": "sengled E12-N14"
}
],
"neighbors": [],
"endpoint_names": [
{
"name": "DIMMABLE_LIGHT"
}
],
"user_given_name": null,
"device_reg_id": "9dcf6fc3078f4aca2d9dad42c1d43339",
"area_id": null,
"cluster_details": {
"1": {
"device_type": {
"name": "DIMMABLE_LIGHT",
"id": 257
},
"profile_id": 260,
"in_clusters": {
"0x0000": {
"endpoint_attribute": "basic",
"attributes": {
"0x0004": {
"attribute_name": "manufacturer",
"value": "sengled"
},
"0x0005": {
"attribute_name": "model",
"value": "E12-N14"
}
},
"unsupported_attributes": {}
},
"0x0003": {
"endpoint_attribute": "identify",
"attributes": {},
"unsupported_attributes": {}
},
"0x0004": {
"endpoint_attribute": "groups",
"attributes": {},
"unsupported_attributes": {}
},
"0x0005": {
"endpoint_attribute": "scenes",
"attributes": {},
"unsupported_attributes": {}
},
"0x0006": {
"endpoint_attribute": "on_off",
"attributes": {
"0x0000": {
"attribute_name": "on_off",
"value": 0
}
},
"unsupported_attributes": {
"0x4003": {
"attribute_name": "start_up_on_off"
}
}
},
"0x0008": {
"endpoint_attribute": "level",
"attributes": {
"0x0000": {
"attribute_name": "current_level",
"value": 74
},
"0x0011": {
"attribute_name": "on_level",
"value": 255
}
},
"unsupported_attributes": {
"0x4000": {
"attribute_name": "start_up_current_level"
},
"0x0010": {
"attribute_name": "on_off_transition_time"
},
"0x0012": {
"attribute_name": "on_transition_time"
},
"0x0014": {
"attribute_name": "default_move_rate"
},
"0x0013": {
"attribute_name": "off_transition_time"
}
}
},
"0x0702": {
"endpoint_attribute": "smartenergy_metering",
"attributes": {
"0x0000": {
"attribute_name": "current_summ_delivered",
"value": 712
},
"0x0200": {
"attribute_name": "status",
"value": 0
},
"0x0300": {
"attribute_name": "unit_of_measure",
"value": 0
},
"0x0301": {
"attribute_name": "multiplier",
"value": 1
},
"0x0302": {
"attribute_name": "divisor",
"value": 10000
},
"0x0303": {
"attribute_name": "summation_formatting",
"value": 33
},
"0x0304": {
"attribute_name": "demand_formatting",
"value": 33
},
"0x0306": {
"attribute_name": "metering_device_type",
"value": 0
},
"0x0400": {
"attribute_name": "instantaneous_demand",
"value": 31
}
},
"unsupported_attributes": {}
},
"0x0b05": {
"endpoint_attribute": "diagnostic",
"attributes": {},
"unsupported_attributes": {}
}
},
"out_clusters": {
"0x0019": {
"endpoint_attribute": "ota",
"attributes": {},
"unsupported_attributes": {}
}
}
}
}
}
}Hmm.. Looking at the diagnostic output there is a n interesting difference between summation and demand:
"0x0702": { "endpoint_attribute": "smartenergy_metering", "attributes": { "0x0000": { "attribute_name": "current_summ_delivered", "value": 6931 }, ... "0x0303": { "attribute_name": "summation_formatting", "value": 75 }, ... "0x0400": { "attribute_name": "instantaneous_demand", "value": 872121 } }, "unsupported_attributes": { "0x0304": { "attribute_name": "demand_formatting" } }Notice that "demand_formatting" is listed under "unsupported_attributes" from the Schneider devices (both). Is that handled as if it has the value 0?
In the Sengled bulbs - what does they report for "demand_formatting"?
See above… 33
krlssn
commented
1 year ago Tried to compare the code with my zero experience so I dont know what it changes, but: My current is correct value in sensor. When I read the code it seems for me that it reports 3269 (mA), then 0x0603 divides it with 1000 to 3,269A which is the value I get in HA (3,3A). Then I look at row "0x0400" and it reports 755113 (mW?), but under there multiplier and divisor lines is missing compared to these lines in current section. Power multiplier and power divisor is listed under unsupported attributes. Could it be that easy that if this lines were like in the current section everything would be ok? Like power multiplier=1 and power divisor=1000. I dont know if i can test this by myself by changing something in the
"attribute_name": "rms_current",
"value": 3269
},
"0x0602": {
"attribute_name": "ac_current_multiplier",
"value": 1
},
"0x0603": {
"attribute_name": "ac_current_divisor",
"value": 1000
} },
"0x0400": {
"attribute_name": "instantaneous_demand",
"value": 755113
} },
"unsupported_attributes": {
"0x0403": {
"attribute_name": "power_divisor"
},
"0x0402": {
"attribute_name": "power_multiplier"
}
}I found this, don't know if I can change (destroy) anything here or what happens if I try to send something? When I click read attribute i get "None" as in the picture.
krlssn
commented
1 year ago Compared with current divisor I get "1000".
ptrrkssn
commented
1 year ago I've now tried various values for "demand_formatting" in the quirk. So far I've not found any value that seems to make any difference what so ever... Tried 75, 0 & 33 so far.
class MeteringCluster(CustomCluster, Metering):
"""Fix the Metering divisor."""
INSTANTANEOUS_DEMAND = 0x0400
DEMAND_FORMATTING = 0x0304
_CONSTANT_ATTRIBUTES = { DEMAND_FORMATTING: 33 }
def _update_attribute(self, attrid, value):
if attrid == self.INSTANTANEOUS_DEMAND:
value = value / 1000.0
super()._update_attribute(attrid, value)
Also include the full quirk code (that works for me) for reference. (And yes, I've deleted the pycache, restarted HA and removed and re-pair:ed the device again every time. For it to work with the other type of outlet it probably needs to be adjusted to include it's signature or something...
krlssn
commented
1 year ago @ptrrkssn Do you know what happens if I try to write value "1000" for "power_divisor" in my pic above? Is that read only and impossible to change? If I can do it, does it write to the outlet or somewhere in "HA software"? Is it restorable from backup? Any thoughts about it? I want to think that it is that easy when I compare current and power, but maybe that's what ypu tried earlier with wrong kWh (summary) readings as result...?
javicalle
commented
1 year ago The multiplier/divisor attributes are read only and couldn't be changed from UI. Usually the values you change, you can restore... if you now the previous value. I appreciate the efforts, but we have the necessary info from the diagnostics.
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
```yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 { "node_descriptor": "NodeDescriptor(logical_type=Diagnostic information
```yaml { "home_assistant": { "installation_type": "Home Assistant OS", "version": "2022.11.1", "dev": false, "hassio": true, "virtualenv": false, "python_version": "3.10.7", "docker": true, "arch": "x86_64", "timezone": "Europe/Stockholm", "os_name": "Linux", "os_version": "5.15.74", "supervisor": "2022.10.2", "host_os": "Home Assistant OS 9.3", "docker_version": "20.10.18", "chassis": "embedded", "run_as_root": true }, "custom_components": { "nordpool": { "version": "0.0.7", "requirements": [ "nordpool>=0.2" ] }, "programmable_thermostat": { "version": "8.1", "requirements": [] }, "scheduler": { "version": "v0.0.0", "requirements": [] }, "hacs": { "version": "1.28.2", "requirements": [ "aiogithubapi>=22.2.4" ] } }, "integration_manifest": { "domain": "zha", "name": "Zigbee Home Automation", "config_flow": true, "documentation": "https://www.home-assistant.io/integrations/zha", "requirements": [ "bellows==0.34.2", "pyserial==3.5", "pyserial-asyncio==0.6", "zha-quirks==0.0.84", "zigpy-deconz==0.19.0", "zigpy==0.51.5", "zigpy-xbee==0.16.2", "zigpy-zigate==0.10.3", "zigpy-znp==0.9.1" ], "usb": [ { "vid": "10C4", "pid": "EA60", "description": "*2652*", "known_devices": [ "slae.sh cc2652rb stick" ] }, { "vid": "1A86", "pid": "55D4", "description": "*sonoff*plus*", "known_devices": [ "sonoff zigbee dongle plus v2" ] }, { "vid": "10C4", "pid": "EA60", "description": "*sonoff*plus*", "known_devices": [ "sonoff zigbee dongle plus" ] }, { "vid": "10C4", "pid": "EA60", "description": "*tubeszb*", "known_devices": [ "TubesZB Coordinator" ] }, { "vid": "1A86", "pid": "7523", "description": "*tubeszb*", "known_devices": [ "TubesZB Coordinator" ] }, { "vid": "1A86", "pid": "7523", "description": "*zigstar*", "known_devices": [ "ZigStar Coordinators" ] }, { "vid": "1CF1", "pid": "0030", "description": "*conbee*", "known_devices": [ "Conbee II" ] }, { "vid": "10C4", "pid": "8A2A", "description": "*zigbee*", "known_devices": [ "Nortek HUSBZB-1" ] }, { "vid": "0403", "pid": "6015", "description": "*zigate*", "known_devices": [ "ZiGate+" ] }, { "vid": "10C4", "pid": "EA60", "description": "*zigate*", "known_devices": [ "ZiGate" ] }, { "vid": "10C4", "pid": "8B34", "description": "*bv 2010/10*", "known_devices": [ "Bitron Video AV2010/10" ] } ], "codeowners": [ "@dmulcahey", "@adminiuga", "@puddly" ], "zeroconf": [ { "type": "_esphomelib._tcp.local.", "name": "tube*" }, { "type": "_zigate-zigbee-gateway._tcp.local.", "name": "*zigate*" }, { "type": "_zigstar_gw._tcp.local.", "name": "*zigstar*" } ], "dependencies": [ "file_upload" ], "after_dependencies": [ "onboarding", "usb", "zeroconf" ], "iot_class": "local_polling", "loggers": [ "aiosqlite", "bellows", "crccheck", "pure_pcapy3", "zhaquirks", "zigpy", "zigpy_deconz", "zigpy_xbee", "zigpy_zigate", "zigpy_znp" ], "is_built_in": true }, "data": { "ieee": "**REDACTED**", "nwk": 32853, "manufacturer": "Schneider Electric", "model": "SOCKET/OUTLET/2", "name": "Schneider Electric SOCKET/OUTLET/2", "quirk_applied": false, "quirk_class": "zigpy.device.Device", "manufacturer_code": 4190, "power_source": "Mains", "lqi": 255, "rssi": -56, "last_seen": "2022-11-04T19:57:25", "available": true, "device_type": "Router", "signature": { "node_descriptor": "NodeDescriptor(logical_type=Additional logs
``` Paste any additional debug logs here. Don't remove the extra line breaks outside the ``` marks. ```Additional context Add any other context about the problem here.