What brand/model of device is it?
In my further search I recogned it was strange that Zigbee2Mqtt could be seen by Homey a source of the action, since the device is activated by a flow or directly as device in the homey app.
So what I did was : activate the device via the flow, directly as device in homey, and the on/off switch on the device. And looked at the log.
The result : via script shows actition homeyscript.
direct device shows activation via Web
on-off switch shows activation Zigbee2Mqtt
See screenshot.
So perhaps my device is faulty.
It is a TS0121 Tuya.
Some devices are susceptible to other devices (remotes) that send commands to particular Zigbee groups (and/or broadcast messages), even when those other devices aren’t even in the same Zigbee network.
Perhaps the socket is receiving a command from such a device and turns itself on.
Have you tried pairing the device again? With z2m you can turn on “Permit join” then put the device in pairing mode, and it will be added again with the same name.
I’ll try that.
Also created a map, and I see 2 unknown Zigbee devices, (the ones shown in red) one of them has a connection to the smart power plug. So have to find out what device that is.
It might also be the IKEA 5-button remote that’s connected through it, might be worthwhile to see if you can turn the socket on/off using it (provided that you don’t have actual flows that will perform that action).
Tried re-pairing. Issue is solved for now, so seems to be a solution.
v2.4.1 is ready for testing: Zigbee2MQTT | Homey
- Added L3 and L4 switch support.
- Added backlight_mode support.
- Improved naming of switch flow cards.
@Joel_Larsson This should add support for L3 and L4 of your 4 channel device Please let me/us know if it works.
@Gruijter Hi Robin,
I have 3 issues but two of them could be related just solved all of them
- one is that according to the z2m bridge device in my homey my z2m bridge is offline, and restarting the homey app, z2m or mqtt doesn’t fix that, but the weird thing is that everything else works as expected I can even enable pairing from homey from the bridge device
solution: this apparently was a configuration issue on my side, I had to setdvanced.legacy_availability_payload
tofalse
source: MQTT Topics and Messages | Zigbee2MQTT - the number of joined devices is incorrect in the Homey Bridge device it says 40 while in z2m its 38, or could this be 38 devices, 1 group and 1 bridge?
solution: also a issue on my side, my z2m configuration contained devices that weren’t there - when I restart MQTT all z2m homey devices go in error mode and the only way to fix that is to restart the z2m homey app
solution: this one now also seems to be fixed now that the bridge state updates automatically
While debugging this I also exposed the number of groups to your bridge, not a very exciting PR but it’s something
v2.4.2 is ready for testing: Zigbee2MQTT | Homey
- Added joined groups capability for bridge. (Thx @Sre !)
new version 2.4.3 is released.
- Fix status bridge for legacy_availability_payload.
This should fix the online/offline status of the bridge when legacy_availability_payload
is set to true.
Hi, since this update the app keeps crashing
Please be specific… Are you on 2.4.5?
Athom had a bug in their release software. That got fixed now. Version 2.4.5 should work
(That cost me a precious hour that I wanted to spend on the beach )
Yes it’s working again! But my bridge is still saying status offline.
Also tried restarting everything, including Zigbee2mqtt and the MQTT broker
Any ideas?
And enjoy the beach!
Pfff, my apologies sir Heesbeen, I was just trying to help.
Why tf do you assume I’m nagging you?
Let me try to explain why I asked what I asked:
The last post about a version was v2.4.3
But,
in the meantime the changelog in the app store mentioned two newer versions with bugfixes already:
Hence my question about which version you meant with “this update” you had issues with →
If it was v2.4.3, I would have recommended you to install v2.4.5, and see if this would solve your issue.
But nevermind
@Sharkys can you check if this helps?
@Gruijter another issue that I have is that whenever I try to add a new device in the homey z2m app my cpu rises and (apparently) the app crashes at 2% cpu usage
Thank you for the tip Robin, indeed, adding :
advanced:
legacy_availability_payload: false
into the configuration.yaml helped.