I’m trying to get my domotica a bit more stable. I’ve switches from KAKU devices to Fibaro dimmers based on Z-Wave, mainly because Z-Wave should be producing a mesh network and would be able to have bi directional communication, so Homey could query devices for their state.
I’m a bit disappointing and amazed that this still far from ideal. I have a flow “to bed” where al my living room lights dim, the hall light go bright and the bedroom lights go on as well and after 3 minutes all the lights in the living room and hall should go off. All Z-Wave dimmers, the living room all in the same room where Homey resides as well.
But it happens A LOT that not all of the living room lights turn off after 3 minutes. Some lights randomly just stay on. Or one of the bedroom lights that don’t turn on, etc.
Why is this and how can I improve this stability? Is there a parameter that I forgot to set where I can tell Homey to check the Z-Wave device if the state is indeed updated and if not, try again?
These flows change a lot of Z-Wave devices, it takes Homey quite some time to perform all the tasks so I think it is handling everything in sequential order and does not sent all the commands at the same time, or is it and should I use a delay between each of the commands?
I’ve already placed 3 fibaro wall plugs as additional routers to the floor, but that does not seem to change anything. I already tried pressing the “Heal” command on all plugged Z-Wave devices multiple times, I do notice that the route it takes is ridiculous in some cases (from homey, a floor up, to the attic, all the way down again to a device that is about 5m from homey) but if I understand correctly we cannot manually change / correct those routes?
Is there anything else we could do to improve this stability? I want to be able to rely on my flows and have Homey save some money by switching lights and devices off for me. If it “forgets” this a lot and/or I have to keep checking if it indeed did what it supposed to do that’s not so efficient.
Thank you for the quick responses! Below is an example of my “To bed” flow. It triggers by IFTTT from google assistant. I know it triggers correctly, cause lights start to turn of or dim, but in about 40% of all the times I start this flow one or more lights don’t seem to accept the commands (random lights):
How could I reduce the then part? I need all these lights to do something. Should I start a flow for each of the lights and have a single light perform an action within that single flow?
A check from Homey would probably be best, just have Homey check the status of all the lights after issueing the commands and try again if it failed (and yet again and again if it still did not work). Even if that takes longer or needs me to change some kind of parameter somewhere this would be preferable, it is one of the best things available within Z-Wave communication and it seems as if Homey is not utilizing it at all?
For me this is the main problem of many Smart Home devices and platforms. It isn’t very smart to send only one command without to proof the result.homey should remember the target status in an cache und should compare it with the actually status. If the status isn’t equal, homey must send the command again. After the one or other update I have the same problem. Sometimes a light is still on for the long night without any movement. Or we are away and some devices are still on for many hours. Very smart! I will save energy costs and not increasing it. It All depends on the homey firmware and app builds.
Maybe few things to try/look at:
In the THEN part have a delay (as @bvdbos suggested) for the second card, third card and so on, try a couple of seconds on each, first 0, second 2, 4 and so on.
Look at the z-wave mesh https://developer.athom.com/tools/zwave and try to heal the devices with many hops, one or two hops are fine, too many hops and so much data you transfer at one time it could be that it gets lost in between devices.
Before I fitted the external z-wave antennaI, had a bad instance when the fibaro dual relay did not stop my pop-up sprinkles. When a light does not turn on/off is annoying. But when the water keeps running is way beyond annoying. That relay was over 4 hops before the antenna, now it is direct connected to Homey.
As a double safe measure, I have now two THEN cards both supposed to turn off the fibaro relay first no delay and second after 1 minute, just in case the first one hasn’t done the job.
I don’t think all the commands are sent at the same time, for different protocols it seems so (if I have a flow turning both a Z-Wave and KAKU device on, it seems to be done at the same time), but if I change the state of 4 Z-Wave lights I can see them change in order, they do not respond at the same time. I do think that Homey has some kind of sequential handling queue in place per protocol. Is there someone who can confirm (or deny) this? I did change the delay on each of the items now to see if that has any effect, but I do doubt that it will.
Healing devices also seems to sometime work for a small amount of time. It is almost as if it messes up in time again and needs healing again. If so, why can’t homey auto-heal on daily basis? Why does this need to be a manual action?
Z-Wave is bi-directional. I think the biggest question is… why does Homey not utilize that at all? This could probably fix all of the issues and make it a lot more stable?
Why do you think Homey doesn’t? If you look at https://developer.athom.com/tools/zwave you can see it does… You are talking about a different networking-level…
I know it doesn’t. Even while running a test flow I can see that homey issued the command to turn a Z-Wave device off, when I can see that the light is in fact still on. Homey should be able to query the device afterwards and know that the command was not handled successfully so it could try again.
That’s the networking level part that makes sense to implement right?
From other devices to Homey would also be great though I doubt that’s up to Homey to implement, but I have this on motion sensors as well. My Fibaro motion detector often blinks as if it did see motion, but Homey did not receive the command cause nothing is happening. Would also be great if the sensor and/or Z-Wave protocol would try again in this case. It does not seem to do any of this.
If in https://developer.athom.com/tools/zwave you send a basis on command to a device and it reacts with
then you know the bidirectional is working. When issuing a testframe, the bidirectional is overridden so you get a different answer:
"
However, you seem to be hinting on a polling of a zwave-status?
Hi, yes, it would be great if Homey could benefit from the bi directional communication to check if the command was indeed successful. That is to me the best addition Z-Wave and Zigbee have compared to the 433mhz Kaku like protocols.
Nice that they have implemented a transfer ack/nack within homey developer, but I would like to see this implemented on flow commands as well. It should be possible for homey to check if the command indeed succeeded and retry if that is not the case.
Why? With Z-Wave you can sent a command to a device and also read the state of a device right? So my question is…, why doesn’t Homey check the device status after ordering it a command to see if it indeed followed up on that command? And if not, try the command again for a configurable amount of time? And if it still did not work after that, perhaps trigger something we can subscribe upon again for some kind of error handling / custom retry.
Because at this moment I don’t know how to get it all acceptable stable. I first tried switching from HomeWizard to Homey, after that switched from 433mhz KaKu devices to Z-Wave cause it would be more stable, but it still is not and I think Homey can make software improvements to get it a lot more stable. If not… please explain why not. And if they do this already, please explain why it is still so unreliable and what more we could do about this… or tell me that Homey will always be unreliable and I need to give up or learn to live with it.
Anyone with experience from for example the Fibaro base system? Did they get that to work stable and reliable with Fibaro devices or is wireless equal to unstable on every platform at the moment?
For what it’s worth: i have worked with Homey, Fibaro HCL2, Smartthings, Zipatile and Homeseer. Neither of them do what you are asking out of the box. Neither of them tell you after switching a light if it has accepted the command.
If you feel it is unreliable, you can check this yourself by checking the desired status of the device a few moments after the command is sent.
On https://developer.athom.com/tools/zwave you can open the tool LOG, Filter on the device ID you want to see, an there you can see what commands are sent and returned, after you have seen what goes wrong, please report to Athom what you have found, so they can make the desired changes.
Actually, the z-wave chip is already doing what you ask for, it tries for 3 times (you will not see this in any log as this is done by the z-wave chip itself and not homey)
If after those 3 attempts it still doesn’t receive the acknowledgment back it will give the state “send but no ack” back to homey, and won’t send anything to this devices for 30000-50000 ms (depending on if it happend more often/what has been configured).
It won’t do more cause battery devices sleep already again after about 10 seconds of waking up on it’s own, or 3 seconds after it only send out a signal, and also not to digest the frequentie with tries, making the stability worse with the amount of signals going around.
And yes there is something wrong with homey to and from secure devices, but Athom is having difficulty reproducing it as some people do have a lot of trouble with it, and some don’t.
As for the queue, yes there is a queue, as z-wave is a synchronized protocol, and can’t send multiple signals at the same time to different devices (unlike zigbee which can, though not used by homey yet, it needs the rewrite first), so it will have to send signals 1 after the other.
Stability now really depends on the size and stability of the entire mesh network you have in your house, and the amount of stray signals which are send around the same frequency.
Range for homey just isn’t big from the gecko so is really depending on an stable mesh network.
I have more or less the same problems with the stability of the Z-wave mesh network as mentioned in the start of this topic. I am thinking about expanding my flows with a routine that checks whether or not devices where switched on or off after execution of the flow. In that way I could at least see when and how the network malfunctioned.
This is indeed the most elegant way to have this feedback? I would expect an option to have Homey automatically report about “send but no ack” events, but I haven’t found it yet.
I don’t think you can do even that because I don’t think it is possible to read the device status?
It would be great to have a “Errorhandler” device that we could use in flows that could fire events like “CATEGORY”, “ERROR” where category could be “Z-WAVE” and “ERROR” something like “Did not receive an acknowledgement from device X”. Perhaps also a device ID and the sent command so we could perhaps even have the flow set the command again after some time.
@Cuflee do you experience the same problems when you started this topic? Curious if it is solved and if so, what did do the trick for you. For me the 2-seconds delay in the THEN part solved many problems. Secondly adding some powered devices. Just curious.
