Energy Monitoring with GE Zigbee Dimmer (45852GE)

[jl.quema]

I'm on C5 2.2.4.158.

So we basically use the same dimmers, with the same drivers and same platform (2.2.x.y) but you have the power meter and I don't... argh!

[Ranchitat]

@jl.quema

same platform

Mines a different firmware/platform but Mike probably used the same version you're using when he tested the functionality on his sample unit.

@mike.maxwell

I just included a sample unit and tested it, it is reporting as expected.

Here's a pic of the back of mine, maybe it's a different version?

Model: ZB3101

[jl.quema]

Regarding the platform, I was in 2.2.3.148 and had the issue already (which is why I said "same")
I recently updated to 2.2.4.158 but it didn't change anything.

As you can see, I also have the ZB3101

Picture

[jl.quema]

Does it help to look at the debug log when sending the configure command?
Is it the correct approach to focus on clusterId 0702?

Configure Log

[dev:297] 2021-01-06 08:53:53.440 am debug			descMap:[raw:E7470107020E00042A000000, 	dni:E747, endpoint:01, cluster:0702, size:0E, attrId:0400, encoding:2A, command:01, value:000000, clusterInt:1794, attrInt:1024]
[dev:297] 2021-01-06 08:53:53.274 am debug			descMap:[raw:E7470100080A0000207F, 		dni:E747, endpoint:01, cluster:0008, size:0A, attrId:0000, encoding:20, command:01, value:7F, 	  clusterInt:8, 	 attrInt:0]
[dev:297] 2021-01-06 08:53:53.150 am debug			descMap:[raw:E7470100060A00001000, 		dni:E747, endpoint:01, cluster:0006, size:0A, attrId:0000, encoding:10, command:01, value:00, 	  clusterInt:6, 	 attrInt:0]
[dev:297] 2021-01-06 08:53:53.144 am trace	skipped descMap:[raw:catchall: 0104 0702 01 01 0040 00 E747 00 00 0000 07 01 00, 	profileId:0104, clusterId:0702, clusterInt:1794, 	sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:E747, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:07, direction:01, data:[00]]
[dev:297] 2021-01-06 08:53:53.123 am debug			descMap:[raw:catchall: 0104 0702 01 01 0040 00 E747 00 00 0000 07 01 00, 	profileId:0104, clusterId:0702, clusterInt:1794, 	sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:E747, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:07, direction:01, data:[00]]
[dev:297] 2021-01-06 08:53:53.074 am trace	skipped descMap:[raw:catchall: 0000 8021 00 00 0040 00 E747 00 00 0000 00 00 0D00, 	profileId:0000, clusterId:8021, clusterInt:32801, 	sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:E747, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[0D, 00]]
[dev:297] 2021-01-06 08:53:53.069 am debug			descMap:[raw:catchall: 0000 8021 00 00 0040 00 E747 00 00 0000 00 00 0D00, 	profileId:0000, clusterId:8021, clusterInt:32801, 	sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:E747, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[0D, 00]]
[dev:297] 2021-01-06 08:53:52.864 am trace	skipped descMap:[raw:catchall: 0104 0006 01 01 0040 00 E747 00 00 0000 07 01 00, 	profileId:0104, clusterId:0006, clusterInt:6, 		sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:E747, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:07, direction:01, data:[00]]
[dev:297] 2021-01-06 08:53:52.833 am debug			descMap:[raw:catchall: 0104 0006 01 01 0040 00 E747 00 00 0000 07 01 00, 	profileId:0104, clusterId:0006, clusterInt:6, 		sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:E747, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:07, direction:01, data:[00]]
[dev:297] 2021-01-06 08:53:52.615 am trace	skipped descMap:[raw:catchall: 0000 8021 00 00 0040 00 E747 00 00 0000 00 00 0B00, 	profileId:0000, clusterId:8021, clusterInt:32801, 	sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:E747, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[0B, 00]]
[dev:297] 2021-01-06 08:53:52.610 am debug			descMap:[raw:catchall: 0000 8021 00 00 0040 00 E747 00 00 0000 00 00 0B00, 	profileId:0000, clusterId:8021, clusterInt:32801, 	sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:E747, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[0B, 00]]
[dev:297] 2021-01-06 08:53:52.421 am trace	skipped descMap:[raw:catchall: 0104 0008 01 01 0040 00 E747 00 00 0000 07 01 00, 	profileId:0104, clusterId:0008, clusterInt:8, 		sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:E747, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:07, direction:01, data:[00]]
[dev:297] 2021-01-06 08:53:52.417 am debug			descMap:[raw:catchall: 0104 0008 01 01 0040 00 E747 00 00 0000 07 01 00, 	profileId:0104, clusterId:0008, clusterInt:8, 		sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:E747, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:07, direction:01, data:[00]]
[dev:297] 2021-01-06 08:53:52.241 am trace	skipped descMap:[raw:catchall: 0000 8021 00 00 0040 00 E747 00 00 0000 00 00 0900, 	profileId:0000, clusterId:8021, clusterInt:32801, 	sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:E747, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[09, 00]]
[dev:297] 2021-01-06 08:53:52.237 am debug			descMap:[raw:catchall: 0000 8021 00 00 0040 00 E747 00 00 0000 00 00 0900, 	profileId:0000, clusterId:8021, clusterInt:32801, 	sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:E747, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[09, 00]]
[dev:297] 2021-01-06 08:53:52.040 am warn	configure...

[jl.quema]

I'm reading the following: https://www.nxp.com/docs/en/user-guide/JN-UG-3115.pdf
Chapter 42 describes cluster 0702 ("Simple Metering Cluster").

Obviously, way more complex than I expected but I found out that attrId=0400 I see in the log is for E_CLD_SM_ATTR_ID_INSTANTANEOUS_DEMAND

I have now to understand the other parameters in:

descMap:[raw:E7470107020E00042A000000, dni:E747, endpoint:01, cluster:0702, size:0E, attrId:0400, encoding:2A, command:01, value:000000, clusterInt:1794, attrInt:1024]

Obviously, the value:000000, while a 40W incandescent bulb is ON, is incorrect.

@Ranchitat, @mike.maxwell, would you mind sharing your logs so I can compare what you have?
@Navat604, as you have the switch and not the plug-in dimmer, I guess your logs are different but it might be helpful too if using the same cluster.

Please forgive the non-sense (if any), as I'm far to be an expert in this area.

[Navat604]

raw:48410107020E00042A000000
dni:4841, endpoint:01, cluster:0702,
size:0E, attrId:0400, encoding:2A,
command:01, value:000000,
clusterInt:1794, attrInt:1024]

Have you looked at this post?

[RELEASE] GE/Jasco Power Monitoring Zigbee Smart Switch (45853, 45856)

So I figured I might as well drop this here, even though Mike has said 2.1.6 will contain support for these devices built-in. Since those drivers source aren't open source and I could not find any other Simple Metering (0702) drivers out there, this could be helpful for others. Caveat: This driver is a bit fresh, I've been using it for a few days, so it's presumably far from perfect. This driver supports I both plugin and in-wall versions thanks for @aruffell. Features: On/Off Switch cont…

[jl.quema]

@Navat604
I think you just found the root cause of my issue: it seems the "GE Zigbee dimmer" driver doesn't implement the Simple Metering (Cluster 0702)

As soon as I switched to the GE/Jasco Smart Switch driver from the other post, I was able to read the power.

Current States

• power : 36.9
• switch : on

Now, the problem is that this new driver only supports on/off but no dimmer function.

@mike.maxwell, do you confirm the above? that "power metering" is not supported by the "GE zigbee dimmer"driver?

I guess I could combine this driver (the on/off + power metering) with another one (dimming feature) but not sue if it is the wise thing to do...

Edit/Additional info:
I reverted to the GE Zigbee dimmer driver and now have a new behavior.
The power is not zero anymore but fluctuate between two values: 6 and 37 every 5s (which is my reporting interval).
My interpretation is that the GE/Jasco driver somehow enabled the power reporting feature and the GE Zigbee Dimmer driver can read it but not configure it properly.

[mike.maxwell]

Power reporting is supported with the built in ge zigbee switch and dimmer drivers.

[jl.quema]

Thanks for the feedback, although I'm confused:

• when using only the "GE Zigbee dimmer", I have no power reporting at all.
• when using in combination:
  • first the GE/Jasco driver, it "enables" the power reporting and it is stable (value doesn't change constantly)
  • second the "GE Zigbee dimmer", the power reporting remains enabled but the value changes all the time (switching between 2 values, in my example 6W and 37W). Changes in the threshold and reporting interval seem to be ignored as well

When using your sample, could it be that it was previously setup with another driver that would have enabled the power reporting feature?

[mike.maxwell]

please post a screen shot of the data section of the driver details for the device thats got the spastic power reporting, thanks.

[jl.quema]

Here it is:

• endpointId: 01
• application: 12
• manufacturer: Jasco Products
• model: 45852
• endpointId: 01
• profileId: 0104
• inClusters: 0000,0003,0004,0005,0006,0008,0B05,0702
• outClusters: 000A,0019

[jl.quema]

Hello again,

Was the information (data section) helpful?
Any idea what causes the power reporting to be spastic?

[jl.quema]

Hi again

I updated the hub to 2.2.5.131 and was pleased to see the power management fix in the changelog:

• Generic Zigbee Outlet: fix power reporting configuration bug.

but.... still some issue unfortunately. As described before, I have two "GE Dimmer outlet" with the exact same appliance behind (a 40W edison bulb) and here is what I did/observe:

• Plug 1 ("East"):

  • following the upgrade to 2.2.5, I sent a "configure" to the device (since the change log says it was a configuration bug)
  • The power is reported but still spastic. As an example, at 25%dimmed, it reports 14W, then 465W, then 14 , 465, 14, etc.

• Plug 2 ("West"):

  • following the upgrade to 2.2.5 I did NOT send a "configure"
  • The power is reported correctly, with no erratic change. At 25%, it reports 14W and the value remains.

I wish I didn't send the "configure" to Plug 1 - any idea what to do so that it behaves correctly?

If of any use:
fingerprint model:"45852", manufacturer:"Jasco Products", profileId:"0104", endpointId:"01", inClusters:"0000,0003,0004,0005,0006,0008,0B05,0702", outClusters:"000A,0019", application:"12"

[jl.quema]

Additional information (from the log) that shows the changing value

[dev:298](http://192.168.86.174/logs#dev298)2021-02-25 03:57:26.871 pm [info](http://192.168.86.174/device/edit/298)Study East power is 467W

[dev:298](http://192.168.86.174/logs#dev298)2021-02-25 03:57:26.866 pm [debug](http://192.168.86.174/device/edit/298)descMap:[raw:CDC401070212000025401200000000, dni:CDC4, endpoint:01, cluster:0702, size:12, attrId:0000, encoding:25, command:0A, value:000000001240, clusterInt:1794, attrInt:0]

[dev:298](http://192.168.86.174/logs#dev298)2021-02-25 03:57:22.074 pm [info](http://192.168.86.174/device/edit/298)Study East power is 15W

[dev:298](http://192.168.86.174/logs#dev298)2021-02-25 03:57:22.069 pm [debug](http://192.168.86.174/device/edit/298)descMap:[raw:CDC40107020E00042A9A0000, dni:CDC4, endpoint:01, cluster:0702, size:0E, attrId:0400, encoding:2A, command:01, value:00009A, clusterInt:1794, attrInt:1024]

[mike.maxwell]

I see what's going on, should be an easy fix.

[jl.quema]

Good that you see what's going on

Am I right to assume this is due to the cluster/attribute 0702/0000 being sent?
On the other plug, only the 0702/0400 is sent.

Noob's question: do the clusterID and attrID use different endianness?

[mike.maxwell]

@jl.quema

do the clusterID and attrID use different endianness

no
and yes, this device is sending attribute responses for attribute 0000, though we never asked for them...

[jl.quema]

Thanks!
That's what I thought (about attribute 0000 being unwanted here)

My question regarding endianess:
I see the raw data as CDC4 01 0702 0E 0004 2A 9A0000

If I read it naively:

• dev_id: CDC4
• endpoint: 01
• cluster_id: 0702
• size: 0E
• attrId: 0004
  (but it should be 0400... so I assume little endian but then, the cluster should be 0207...)

Would you have a good documentation to recommend to better understand the different data fields?

[mike.maxwell]

almost all zigbee data on the wire is little endian, there's a few data types that aren't, but not many.