I have a WaterCop valve which uses the same driver and migrated to an Edge driver last week. Looking at the history now, I can see that it has shown alternating open / closed status at various times, supposedly cycling open each day around 3:10am and then closing around 1-6 hours later. The water certainly hasn’t been shut off for 18-23 hours each day during that time so that reporting is definitely false.
This device has problems with dropping off the Z-wave network, so I have it plugged into a mechanical timer to power cycle it daily. It’s possible that’s what’s triggering the first state change at 3am (reconnecting to the network and showing the true open state, which later reverts to an incorrect closed state?); I’m traveling this week so can’t check at the moment what time that’s scheduled for. I also have a series of routines set up to exercise the valve weekly, and that does show up correctly in the history for last week. It’s scheduled to do it again tonight, so I’ll check whether that’s also logged as expected.
Thanks for the info. Very helpful. As far as I know the state change is not being triggered by the device dropping off the network as I do not see that reported anywhere.
Just to add to the above, I am running driver 2022-11-29T21:19:40. I suppose the drivers gets updated automatically, so we are running the same driver. Please let me know. Is there even a mechanism to manually update or rollback an edge driver? Is there a way to know when a driver was updated?
I usually have the valve closed and that is when I have seen the problem. However, I currently have it open and after several hours I have not seen the problem.
Barring new info, I think I will watch it for the next few days and if I still see the problem will report the issue to Smartthings.
Can confirm, same driver. No option to roll back a driver. When an update is released it will automatically be applied to your hub (usually within about 12 hours) but you can also force it to update by attempting to uninstall the driver. It won’t be removed if there is a device using it, but that should prompt the new version to be downloaded.
I don’t think the network disconnect is related; but that’s the reason I have it power cycling. When it comes back online, it reports in with the correct status, and some time after that it erroneously shows closed.
I tried changing to a different driver and back and it now reports open; since I’m not home, I don’t want to mess with it too much and cut off the water on my family (this valve is the main shutoff for the house). I’ll play with it more this weekend. A Z-wave switch driver should work fine for this device, so you could try swapping this for the stock Z-wave switch or one from Mariano C or Phil H to see if that settles the issues down.
I’m curious about this, too. I have noticed the same thing–it will be “open”, but show “closed”…and it seems to change state (valve hasn’t physically changed) randomly.
I also have had the same problem occurring since the Edge driver was installed. My question would be…what entity is creating these new Edge Drivers, and is there some mechanism by which we can report such problems and (hopefully) have someone looking into modifying the driver appropriately?
ST developers are creating the built-in drivers. Best way to address it is to file a bug report and be prepared to provide logs, etc. to demonstrate the issue. I haven’t done it for this issue yet as I was traveling and haven’t had a chance to dig into it.
I have a Fortrezz water valve connected to Smartthings, and I am having the same problem. Once or twice a day the Smartthings app indicates that the valve has closed, but physically it has not closed. When I “open” the valve with the app, the valve remains physically open and the app then indicates it is open. Fortunately my routines that close the valve still close it when the app indicates that it is already closed. Anyone have any more ideas on solutions?
I am having the same issue and am also using the same driver. This just started a couple months ago for me. If there are any updates from the group, would love to hear them.
I opened a ticket and “tried” to send logs to them…I don’t know why, but when it said they were sent, ST support said it was essentially empty. And I don’t have access to system files on my Pixel to retrieve them like they suggested.
So, I’m still waiting for them to get back to me. Last contact was 2/24. I’ll follow up later this week if I haven’t heard back.
Since 2018 my WaterCop Valve consistently showed “offline”. I tried excluding and reinstalling a few times but it would only show online for a few hours / days. Despite indicating offline, the device still worked every time using routines or virtual switch so I left it alone (vacation home). Today I noticed on Tues 3/7 the valve indicated “open” on it’s own. I arrived today and activated the routine “home”, within a few min the valve closed. This occurred 4 more times in the matter of a few hours. Watercop and FortrezZ Valve look to be similar in design.
Maybe this is related. But after years of trouble, free, operation my Fibaro FGFS-101 ZW3 Flood Sensors reported a nonexistent leak. They control a “Leak Gopher” Water Control Valve.
This morning, one of my sensors reported a leak, and promptly closed my main water valve. Upon investigating, I found there was no leak. Using the SmartThings iPhone app, I was able to open my water valve with no fuss. The problem is, the Fibaro sensor is continuing to report “Wet” when it is very dry. I checked the battery, it is good.
I believe the sensor is communicating with my SmartThings V2 Hub because if I move the sensor, it immediately reports “Tampered” on my iPhone.
I placed another identical Fibaro FGFS-101 ZW3 Flood Sensor on a damp washcloth as a test. It immediately reported the leak and closed my valve. This other sensor is now thoroughly dry, yet, It is still reporting “wet”. I have performed this test successfully many times in the past when changing the batteries. But now, when the sensor reports a wet condition, it stays STUCK on WET.
I have taken the batteries out of the unit to reboot the sensor. I have also rebooted the, SmartThings V2 Hub, and my iPhone. None of these things helped.
So, I’ve had two sensors “fail” on the same day. This makes me suspect some kind of a bug with SmartThings.
This sounds similar to issues observed with z wave contact sensors using the stock Z Wave Sensor driver. Try switching it to Philh30’s ZWave Masquerade driver (and set the sensor type to leak sensor) and see if that helps.
MarkTr, I do very much appreciate you trying to help me, but your suggestions are way over my head. I have absolutely no idea how to change any drivers. When I got these sensors several years ago, I simply followed the directions for having them communicate with my water valve. Everything has been working PERFECTLY until a couple of days ago. I’ve made NO changes. (Although, SmartThings makes changes to the hub, whether I want them or not.) The sensor is communicating with my SmartThings hub. These go into power saving mode. But if you pick it up, there’s a tamper sensor that instantly reports this back to my iPhone.
I’m working with them on a ticket on the Nortek GoControl and they have been quite responsive but have been up-front with me that they do not have the devices they are trying to write for and they need our help providing logs and doing testing. I can tell by the communications that they’re working on a lot of things at the same time. As with any company, they’re limited by what resources they have at hand. I will say that if people don’t provide the help they need, they’re going to move onto the things that they can do. Someone else opened the ticket on the Nortek and then found an alternative driver (Masquerade) that would do what they needed so ST support was not given the logs they asked for.
I sort of made a mess of it by adding yet another thread about the same device, tried to fix that, and then some well-meaning folks complicated it a bit further. Once it gets resolved I hope to follow up on each of those threads with the resolution so they don’t turn into ghost threads that never have a solution.
My Opinion is this:
I’m completely aware that I have ST spending resources on a device that is discontinued and no longer supported by the company that built it. They are spending as many resources as they can on these devices. I think they realize that the change in architecture to API from Groovy is on them, though necessary to remain secure and viable. They are dedicating resources to fix it as best they can and it is probably a lot harder than anyone realized. I’ve followed the tutorials to access CLI, dug back into VSCODE (which I haven’t touched in years) and made an attempt, but I don’t think it’s something I can figure out. All I can do is weigh my options: rely on those who can do it and help where I’m able, or throw the devices away and buy some that are compatible.
I posted this question on Amazon and I did receive a helpful answer. I will repeat it here in case someone else comes across a similar problem. The below did solve my immediate problems, but it does not explain why one sensor is going into power-save, and the other one is not. Anyway, my immediate crises is over because of the information below. Sadly, as part of Amazon’s continued downgrading it is no longer possible to have a two-way conversation with someone trying to help you.
(The location of the TMP button is shown in the Fibaro manual)
Remove the cover and press and hold the TMP button
The device’s light will walk through different colors. Wait for the device to indicate desired position with a color:
• WHITE - confirmation of entering the menu
• GREEN - cancel alarm for associated devices and the controller
(only if the device is no longer flooded)
• VIOLET - Z-Wave network’s range test
• YELLOW - full reset
Just stumbled across this one. I have the Fortrezz valve (2 actually) which has, from day 1 had trouble staying on the network (or at least reporting as connected). To work around this I purchased a zwave plug and and a few times a day cycle it on and off. In the groovy days, this seemed to solve the issue for a few hours at least. Post groovy/edge, it seems to reset my valves only briefly… When performing any operation with the valves I now cycle them on and off first and then actuate them. Interestingly once they drop connection, they both seem to report the opposite state as what they are. Ie the one that is almost always off reports as on while the one that is almost always on reports as off