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
I have a water cop valve that has started doing this within the last year. I did file a ticket with SmartThings but it got nowhere. Mine would go offline before this issue, but it would still close if a sensor detected water. I have a zigbee switch to power cycle it, but I do still have the incorrect state. Mine changes state about every 2 hours. I am running the stock edge driver. I came here looking for suggestions also.