Mayby try to change power reports to higher value?
1 Like
Maybe you have a problem like this:
1 Like
Mayby try to change power reports to higher value?
I thought of this too, and I did spend a lot of time disabled all my devices power reporting, just to find out that it didn’t effect my problem at all.
So in my case, it must be something else. Lights do turn on and off quickly one a the time, it’s when I use flows with multiple lights that everything works extremely unwell. As you can see above I’ve proof (logs) that flows send multiple duplicate commands for every device within in short timespan (e.g. the Homey doesn’t even wait for timeouts, it just bombards with new commands).
Someone has yet to explain why this should happen and why it would be reasonable.
Maybe you have a problem like this
Interesting!
The only wireless devices I’ve on the ZWave frequency are four motion sensors from Neo Coolcam. All reports temperatures and so one regularly. They often tend to send a lot of false motion alarms when run out of battery.
Anyway, I cannot think of anything else that I have that communicates on the same frequency.
It would be interesting to measure the frequency band (868-869 MHz) using a RF Spectrum Analyzer. Maybe there’s something causing interference, that I cannot think of.
Still think it’s strange that flows would bombard with multiple duplicate commands because of this.
When a message is sent to a device and the sender does not receive an answer, then the message is retransmitted.
Maybe you can try to use the Z-Wave Log at Homey Developer Tools to see what happens in the communication.
Maybe I was unclear about what I meant, so I’ll try again.
If you look at my previous posts you can see that I’ve been using the ZWave log all along.
But, please take a closer look. It feels very stupid of the Homey to only wait for some milliseconds and then send the same command again. And again, and again.
If you use the Developer tools and send the “Test” command to an unresponsive devices, it’ll timeout after maybe 10 seconds not 50 milliseconds.
This is what I find so strange. Sure, if commands where sent, and then a timeout occurs and it is sent again - fine!
But sending 20 duplicate commands within a second or two - makes no sense.
There’s nothing in the log hinting about timeouts, but there are many duplicate commands. And again, to be very clear, it only happens when running flows.
We don’t know unfortunately if it’s due to the Silicon Labs SDK or Athom developers issues.
Unless one of them would like to cause DDoS attacks. 
Let me repeat for everyone, all those findings must be shared with Athom via Support. I keep sharing my findings via internal channels as well (eg. exactly this issue I shared with all the logs maybe 6 months ago…) but usually getting back kind of “I’m the only one reporting issues”… by more people reporting issues, not only that it increase priority but provides also more data to troubleshoot the issue. It also helps to sort and queue all the issues for later processing.
1 Like
No you were absolutely not unclear, it was me, not looking back far enough, sorry for that.
Hope that Athom can find the problem, succes.
1 Like
No problem, thanks for trying to help me out. 
1 Like
For those of you experiencing the same issues, I’ve been in contact with Athom-support for quite a while helping them to provide information about the issue.
This is the final answer I got from an Athom General:
I’ve contacted the development team about the ongoing Z-wave issues and whether they want an extra debug session. They mention that they have already made a long-term roadmap for improving Z-wave stability since they also found issues regarding this. So this is definitely being looked at, so in the coming period of time there will be changes made to Z-wave. They don’t have a definitive timeline when exactly this is going to be happening but it will be worked on and improved!
So hopefully, this will be solved in the future. 
2 Likes
