I understand that Zigbee device occasionally go "off the grid".
But does that happen to z-wave plus devices?
(It happened that my zwave plus water shut off valve, stopped responding to commands.)
Should I put on polling to make sure that it doesn't happen again?
What about a "device health" program, to check if that device has a heartbeat?
My WaterCop, not a plus, is sleepy and loses connection when I restart my hub or apply an update. Is this the case with yours? Have you applied a firmware update or restarted hub since the last time you tried to use valve?
I solved this with a smart switch and triggered rule on hub system start that will turn off power of valve for 60 seconds on startup and then back on.
Hello.
I have a simple Dome water shut off that actually moves the ball valve to the off position.
However, in answer to your questions, yes, I have restarted my hub a number of times (every time I want to pair to a new device, and I feel that there may be no NWI{network Wide Inclusion}, I take the hub to the pairing device). Also, I have recently upgraded the firmware on the hub to the latest value.
I think that's an excellent suggestion to cycle a number of my devices after a systemStart. Thanks for the suggestion!
I have the same problem, just noticed that my water valve has been unresponsive since I applied the last update and now since I'm afar, my home, which has quite a lot of water devices, is unprotected in case anything happens!
Hubitat is great and so much more stable than Smartthings but it has flaws like this one that in themsevles totally beat the purpose of a smart home. It is not just frustrating here, it is a real liability: One cannot offer automations that, AS A RULE, will stop working as soon as you restart your hub!
I hope someone from Hubitat will read this post. There are other weird things such as the long noticed inability of this hub to connect with Kwikset smart locks and very hectic behavior at pairing several devices or even its incompatibility with some brands of common Zigbee devices such as leak sensor about which I have posted some comments a couple days ago. Overall, it's a great hub and system, but there's really a lot of work ahead and I hope their developers are aware that they must not forget that some bugs are plainly and simply NOT ACCEPTABLE. I don't mean to be rude, but this one, losing connection to a water valve as a systemic issue is big deal. Now, seeing that these posts date from February 2019, I'm concerned that it hasn't been even addressed nor that, it seems, answered by someone from their team.
I am stranded 300 miles away from my home, hoping there will be no leak whatsoever around my devices involving water management...
My Dome water valve works great in Hubitat. It was pretty flaky on Wink, I had to re-pair it constantly. With Hubitat I haven't had to do anything to it in the months since I added it. I just tested it and by the time I pressed the button on the dashboard and set the phone down, the valve had closed.
If you are having Z-wave issues, many times it can be fixed by having more repeaters. My Z-wave response time and reliability has only got better by adding more powered devices like light switches and outlets.
I have the dome water valve. I had trouble with it going offline until I added a ZW117 by Aeotec. Since then not a single drop. The repeater is located about half way between the valve and the hub.
Never ever I had to reconnect it when it was working with SmartThings. This is not per se a sleepy valve it’s a serious flaw in the buildup of this hub. I had those types of problems with SmartThings too, but never with this device. Having to use another smart device to reset a smart device is temporary at best and for now can’t solve my problem. But thanks for the advice which I had lndeed read about in this thread. This is even what made me want to react as, guys, it’s kind of you to figure it out like this but I think it sends the wrong message. Some flaws are acceptable and not urgent to fix. This one is a huge potential liability for me now that I’m far from my home...
Everyone is entitled to their own opinion. So I don't fault you that.
But when there is a very easy workaround that makes it reliable it is no longer an "A" priority to fix, as by definition it had a workaround that makes it work reliably.
I understand your position, I am just providing a counter one in why it is not actually an unacceptable bug - it has a workaround.
And just because you didn't have to in ST still doesn't mean it isn't a device issue. ST has MANY device specific workarounds built into the code base at this point. Maybe they already baked the workaround for the poorly performing device in their code.
Hubitat has a very small fraction of the engineers ST does - don't expect them to bake in device specific workarounds except for very popular/often used devices. Which this device is not.
Again, I'm not saying your opinion is right or wrong, but I do think you need to temper your expectations.
And lastly, these are forums - not official support. If getting this fixed is critical to.you, you need to open a case with support - not just post in forums. If you have already done that, then good!
to: @elfege, I would like to add a critical point to @JasonJoel 's excellent summary.
Although this is an anecdotal story, it is nonetheless, based on my personal experience, so I believe it carries some weight.
I started the previous thread because I have a zwave plus dome water shutoff valve that kept on losing connection. It was approximately 15-20 feet away from the hub, with a zwave plus light switch along the way. Why did it keep on losing connection?
At around the same time that @ritchierich very kindly shared his RM that kept his WaterCop on, I had an unusual opportunity, which I seized upon. I actually had the opportunity to put in a WaterCop at another spot in my basement. Again, this WaterCop was approximately 20-25 feet from the hub. (WaterCop is a zwave non-plus device). I installed it in April-May of last year.) This WaterCop is approximately the same distance from the hub that the dome shut off valve is.
Lo and behold - since the date of installation the WaterCop has never lost connection! (I've never had to use the RM rule on my WaterCop!)
Why is it that the WaterCop never lost connection and the Dome water shutoff valve did?
To be frank, I never figured out why!
However, the point of my story is that, in my humble opinion, Home Automation equipment (in general), is not completely reliable (especially in the six sigma sense of that word!) That's why it's primarily a scene for the home enthusiast, the do-it-yourself individual who has the technical skills to make it happen. I know - I've installed many systems for clients, and I hate being called back because something has stopped working.
I apologise if I've ranted somewhat in this note - but expecting 99% reliability in this field is a pipe dream at present. If it isn't the mesh, it's the device. If it isn't the device, it's the environment. If it isn't the environment it's the software. If it isn't the software it's the hub.... etc.
I am sure that many very experienced individuals on this forum will completely agree with me.
@jtmpush18, well they who one day will, like Apple did, be bold enough to provide a service that defies your fatalism, will master the market. Stating it’s impossible never led any ambitious project. At best, you get a startup like ST, which get bought by Samsung, which extends it and messes it up completely for remaining obstinate about their way to do it (cloud). I think Hubitat was created in reaction to this nonsense. It’d be smart to not vouch for more nonsense of the sameness type, in my humble opinion.
But don’t get me wrong, Hubitat is awesome in comparison! Especially for what I intend to do soon, which is extend further what I have already built as an A.I. Thermostat manager that learns from people’s habits and given environmental inputs such as humidity and outside temp. ST would not allow dB bigger than 100kB... hard to build some basic machine learning on that! Haha!