Same driver. The configs allows you to configure both automatic reporting and polling. If either is activated, you'll see traffic.
When i disable both, my ZigBee logs show no communication. Not sure what we are doing different.
Oh wait... Went back home and checked again after the firmware update. I'm not sure if it's the update or if I checked wrong the first time, but it is constantly reporting, no matter what driver or settings I use.
Sorry for the confusion.
I did a factory reset on one of mine today with the latest firmware. Then I queried it for the out-of-the-box reporting configuration for all the attributes to see what the defaults are.
The only reporting configured according to the factory reset device is for ON/OFF (set for 0 minimum and 240 maximum seconds). No other attributes are configured for reporting out of the box.
In theory, it should be silent except for on/off changes. However, as is no surprise at this point, the device is sending updates for all cluster attributes every 30 seconds and when there are changes. It seems to do this even when the device is "OFF" when there should be nothing to report.
I then set the ON/OFF reporting to a minimum of 60 seconds (from 0). It has no impact to the behavior. I tried setting it to 0xFFFF which should disable reporting but no change either. I tried setting all the attributes that it sends to larger values or 0xFFFF and no change in behaviour.
My conclusion is that it does not use the values in the reporting configuration at all (which I had suspected) and is hard coded to 30 second updates and some kind of delta change updates.
Therefore, the best I can do given this is in my driver is ignore updates below a configurable threshold to reduce the number of events sent (but not received) for devices with lots of variability if this would help.
Otherwise, I love this device. It is well priced, it has been completely stable on my network, and appears to have decent amperage rating and is properly certified.
@ThirdReality PLEASE fix your firmware to follow the Zigbee 3.0 reporting configuration standards and do not hardcode updates (especially not every 30 seconds even when the socket is off).
8 Likes
Once this is fixed, I’ll be buying a bunch of these. Thank you!
2 Likes
I purchased 8 of these, hopefully they can be calmed down a little as I am liking the plug. I also purchased them to strengthen my mesh, as I have seen some good reports on the 3R outlets being repeaters, but now I wonder if that was the first gen without power reporting. I currently have two installed and no repeating to be seen, few days into it now. Anyone seeing these plugs repeat?
1 Like
These are repeating very nicely in my environment.
I have 4 of the 1st gen and love them. Great form factor and solid repeaters. But those aren’t available anymore and I don’t want chatty energy repeating plugs. That’s why im hoping for a firmware fix so I can get this generation of plugs.
1 Like
The last time I checked, both Gen 1 and Gen 2 were available, but you are correct that only the Gen 2 seem to be in stock. I am glad I have 8 of the Gen 1 plugs and 4 of the Gen 2 plugs. I try not to use power monitoring plugs unless I need the power monitoring.
Not that it has anything to do with this zigbee plug, but Zooz just came out with a firmware upgrade for its Z-Wave Zen04 plug (same form factor as the 3R). I upgraded the 8 that I have in service and they can now be made to be very quiet. The only reports they now make for me is when energy incremental use goes over 1 KWh.
I've noticed that when using the stock Generic Zigbee Outlet driver, I'm getting far less % of Total (CPU utilization??). While it obviously couldn't be reducing the Zigbee traffic, potentially it is easier for the hub to process the data with that driver? Anyway, while still high, the stats are less concerning over the past ~24 hours since I made the switch than they were before:
While this won't change the Zigbee traffic, I've released an updated version for anyone using my driver where since we can't change the device to be less chatty I've added the optional capability to at least make the driver less chatty based on configurable thresholds to reduce the quantity of events. In addition, this version is now using the energy (kwh) reporting from the plug.
7 Likes
@mike.maxwell Hi Mike, just checking in to see if any further updates from @ThirdReality on this chatty plug. I see earlier you requested a plug from them. Would be nice to be able to turn off that reporting or change the timing. FYI, while using the generic zigbee driver it reports back some null's on a couple attributes during configure and this driver keeps reporting 0W of power in the logs all the time. Interestingly using the Hubitat built in thrid reality switch driver gets rid of those extra lines in the log and doesn't give the null when configure is pressed for what appears to be the same attributes. Maybe a clue to what those actually are doing?
With generic zigbee driver, configure
With third reality switch driver, configure
And here it is during "normal" communications with the third reality switch driver. Nothing plugged into it. pretty chatty.
since it refuses configuration commands theres a few choices:
- third reality updates the firmware to accept config changes, doesn't seem likely at this point since few if any of their devices support this.
- I can write up a dedicated driver for this device that binds/unbinds cluster 0702 to enable/disable power reporting.
1 Like
Thanks Mike, my vote is for a dedicated HE Driver. Having the option to disable or enable reporting I think is what most of us need. If we use it as a power monitoring plug, then yes we expect some traffic, but when we are not, flip a switch and the traffic remains low, like it should. Got 8 of these plugs to install but I haven't yet, bit cautious putting them in my system with all that reporting going on. If you need a tester, let me know.
Saw same thing on there multisensor ..reporting every 10 secs or so. And ignoring parameters to configure it. Contacted 3rd reality and they basically said go pound sand. Crappy support... sent back to amazon. Will no longer buy there products. Shame as you said as the large batteries are nice.
Even if you unbind the cluster to stop reporting isn't the device still spamming the airwaves unnecessarily? And wont having multiple of these devices still cause major issues?
1 Like
If you unbind the device it shouldn't send that clusters data to the hub
2 Likes
Unless I'm doing it wrong, it still sends even unbound. Even a brand new reset plug without any configuration (i.e. no reporting, no binding commands sent) will spam which is why I wasn't completely surprised this didn't work either.
zdo unbind unicast 0x268D {282C02BFFFEB3EEB} 0x01 0xb04 {000D6F00161EB946} 0x01
zdo unbind unicast 0x268D {282C02BFFFEB3EEB} 0x01 0x702 {000D6F00161EB946} 0x01
Which comes from:
cmds.addAll(
// zdo unbind unicast DEVICE_NETWORK_ID {DEVICE_ZIGBEE_ID} DEVICE_ENDPOINT CLUSTER_ID {HUB_EUI} HUB_ENDPOINT
"zdo unbind unicast 0x${device.deviceNetworkId} {${device.zigbeeId}} 0x${device.endpointId} 0x${Integer.toHexString(zigbee.ELECTRICAL_MEASUREMENT_CLUSTER)} {${location.hub.zigbeeId}} 0x01",
"zdo unbind unicast 0x${device.deviceNetworkId} {${device.zigbeeId}} 0x${device.endpointId} 0x${Integer.toHexString(zigbee.METERING_CLUSTER)} {${location.hub.zigbeeId}} 0x01",
)
Anything wrong that you can see?
try this:
return "zdo unbind 0x${device.deviceNetworkId} 0x${device.endpointId} 0x01 0x0B04 {${device.zigbeeId}} {}"
if that doesn't work then these devices are really non compliant...
1 Like
This is what I got:
sent: zdo unbind 0x268D 0x01 0x01 0x0B04 {282C02BFFFEB3EEB} {}
received Unbind Response error "Read Only":
[raw:catchall: 0000 8022 00 00 0040 00 268D 00 00 0000 00 00 DA88, profileId:0000, clusterId:8022, clusterInt:32802, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:268D, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[DA, 88]]
