so all my Tuya Zigbee Metering Plug Was Turned ON by itself how to investigate how that happened which device/app triggered it?
Have you experimented with any new Zigbee switches at this time?
I have experienced the same at least twice, when experimenting with an Aqara double rocker switch and Osram Lightify remote.
This should have been a Zigbee Group #0 broadcast sent by something. There is no way to log which device made the broadcast.
[physical] in the logs means, that the switch on operation was not initiated from the driver or from any app.
1 Like
YES exactly, I have got this new Aqara Cube T1 Pro and whenever I activate it (flip/check etc) it turns on/off all my Zigbee switches! very weird (and unsafe) I don't even have it paired to my HE (not able to initialize it) but after investigating here it seems it is interfering with my other Zigbee devices
1 Like
Leave the Aqara T1 Pro cube aside for now…
@jonathanb you have good experience with Zigbee Groups broadcasts - any ideas how to prevent this?
Is there a way to disable the acceptance of the OnOff cluster Group #0 broadcasts?
Seems like these are enabled by default in all Tuya plugs and bulbs, but I suspect it is not just Tuya, but a lot of other brands devices.
2 Likes
Have you got the cube paired to something? because if it did it when not paired to anything, it might just be something in the pairing process. If it's working normally within the relevant app or to a hub etc, I'd be more worried.
But I'd love to see if it still throws the same wobbly with the switches, if it's paired to the same Hubitat that your switches are paired to.
An interesting yet potentially nasty example of rf interference causing issues. Another one is people losing control of extremely expensive model planes because two people were using the same freq crystal in the remotes, rendering the aircrafts uncontrollable...
Isn't Aquara known to be a pain in the behind in general?
this is a good idea, i havn't thought of that, i'm gonna pair the Cube Pro to Aqara Hub to see what happen, ..
the security issue isn't Aqara imo, but Tuya plugs (and all other zigbees devices affected by this) those the one supposedly not to accept a command without proper authentication! even if Aqara fixed the cube still n manufacturers accidentally or intentionally can do, and a malicious actor somewhere can take control over my devices as simple as that, it drives me nuts!
What a remote secure setup then? if local/zigbee is not!! is it the actual devices of Tuya plugs the issue or at protocol level of zigbee!
what is the alternative (wifi; hostile to foreign server, RF/IR; easily compromise) is zwave then more secure on this regards!
In my opinion, this is not a security issue because turning all the plugs on/off may happen only after you have authorized the device (the cube, the Zigbee remote) to join your network - by explicitly enabling the 'join new Zigbee devices' function of your Zigbee coordinator (the HE hub) for a limited time.
If someone has a second HE hub that can be used for tests, I hope that there is an easy and universal solution to prevent this. What is needed for the tests is one or more Zigbee plugs or bulbs and a Zigbee remote, that can operate paired directly to the bulb or the plug. Such are Tuya, Ikea, Osram remotes, I just can't recall the name of a similar Zigbee remote brand that is popular in the US.
Update :
Innr remote : Discover what you can do with the Innr Remotes - Innr Lighting
Linkind remote : https://www.amazon.co.uk/Linkind-Dimmable-Required-Installation-Exclusive/dp/B084MCT7LG
These may be good candidates for the 'turn all zigbee devices on/off' tests as well.
1 Like
There really isn't anything that is SECURE secure. If a human can invent something or code something another human can hack it with enough effort.. A more secure system might be coded by AI but even then the AI is coded by humans so it might be near as easy to hack that..
Local control is just less easy to interfere with than anything else. And it doesn't spaff data everywhere, until you realise as lot of people use Alexa/Google and stuff like Tuya in association so...
I think in this case its just a coincidence, a manufacturer doing something that accidently triggers something else, but it'll need to be patched pretty quick because I'm betting the Aquara/Tuya combination is quite widespread and when they do fix it, the solution should be kept out of the general environment, because that sort of information floating about is just asking for an exploit to be made up...
Hope you managed to get everything sorted.
2 Likes
This issue is well known, and the workaround is well known, too - just put all the plugs, bulbs, and all other devices that are affected by these Group #0 broadcasts into a random Zigbee Group.
Hubitat "Groups and Scenes" app does exactly what is needed :
Update: the problem with all Zigbee plugs, bulbs, valves, etc... being turned on/off by an authorized, but misbehaving Zigbee device which broadcasts on/off/toggle commands can NOT be solved by adding the actuators in another Zibee group as I guessed initially.. 
Interesting thank you I will try that
1 Like
Any results? I'm waiting for a T1 Pro myself and I was wondering if this will patch this error up or I should just try to boot up some simple HA to add the cube there and somehow port it into HE.
Hi Simeon,
Aqara Cube T1 Pro will need a new driver for Hubitat. All the necessary information is already available from Zigbee2MQTT implementation, just waiting for a developer to make a driver for Hubitat (or modify Markus's driver for the old model).
Setting up a Home Assistant server may be faster, although I am not quite sure how the Cube specific actions can be ported into HE.
I have edited my previous posts above, where I assumed wrongly that there was an easy fix to prevent all Zigbee switches from turning on/off.
Hey Krasi,
Thanks for the update. I don't know if anyone started creating the HE driver, but I think I might make an attempt to modify the old driver using some help from chatgpt. It will be an interesting challenge as I've never touched groovy before, but I will need the cube to arrive first.
2 Likes
https://www.aqara.com/eu/product/cube-t1-pro
Update : Aqara Cube T1 Pro driver for Hubitat is now published here.
1 Like
Kkossev is it safe to say if a zigbee device has a driver from Zigbee2MQTT then it is very likely to work with HE (or can be ported to it) and when not then then probably it won't work?
I was looking at this zigbee Tuya plug but ppl saying in comments that it has no Zigbee2MQTT drive, this then very likely won't work with HE for now?
@Hus generally. seeing comments that a Zigbee device works with Zigbee2MQTT doesn’t mean that it will work with Hubitat. It depends on whether this device follows strictly the ZHA 1,2 specifications- in such cases HE inbuilt drivers should work.
If the device implements manufacturer-specific commands, then having it already supported in ZHA/Z2M/deConz/… etc.. means that there is enough information available to write a custom driver for Hubitat.
The opposite (comments that something is not working in Z2M) also does not mean that it will not work in HE!
Hubitat features the nice possibility to manually assign drivers (no matter inbuilt or custom) to any Zigbee/Z-wave device which pairs successfully to HE hub. So in many cases new devices support is just a matter of assigning the right driver. Note, that this is not possible in many other home automation systems, where it is required that the new device fingerprint is added into the system, or a new convertor/quirk/configuration file is added by the end user, which requires a high level of expertise.
So in your case with the new Tuya wall socket- there is a very good chance that this new device will work with Hubitat inbuilt drivers. If not - try a Tuya community driver which supports similar devices.
1 Like
On the Aqara Cube T1 Pro issue -the new custom driver solves the problem where all Zigbee devices in the network can be switched on/off.
1 Like
