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!
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!
Mines a different firmware/platform but Mike probably used the same version you're using when he tested the functionality on his sample unit.
Here's a pic of the back of mine, maybe it's a different version?
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
Does it help to look at the debug log when sending the configure command?
Is it the correct approach to focus on clusterId 0702?
[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...
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.
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?
@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.
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.
Power reporting is supported with the built in ge zigbee switch and dimmer drivers.
Thanks for the feedback, although I'm confused:
When using your sample, could it be that it was previously setup with another driver that would have enabled the power reporting feature?
please post a screen shot of the data section of the driver details for the device thats got the spastic power reporting, thanks.
Here it is:
Hello again,
Was the information (data section) helpful?
Any idea what causes the power reporting to be spastic?
Hi again
I updated the hub to 2.2.5.131 and was pleased to see the power management fix in the changelog:
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"):
Plug 2 ("West"):
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"
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]
I see what's going on, should be an easy fix.
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?
no
and yes, this device is sending attribute responses for attribute 0000, though we never asked for them...
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:
Would you have a good documentation to recommend to better understand the different data fields?
almost all zigbee data on the wire is little endian, there's a few data types that aren't, but not many.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.