Remove the device, factory reset it, reboot the hub, and then add it again.
Have live logging open while adding the device so you can see if any errors occur.
Thanks again Kevin.
Went through those steps, removed valve, factory reset valve, reboot hub.
After I re-add the shut off, still associates with generic z-wave shut off (although pops up as Dome Water Shut Off on discovery screen).
If I force it over to your device handler in the IDE, still end up with all gray screen and status of the valve is not there.
Attaching the live log of the add process…
exactly same issue as mr brown.
in my case it associate itself with a proper device, but still does not show the status.
All automatons have to be made as it was a switch not a valve.
It does not work when defined as valve action open or close.
My DTH looks like the screenshot below so if you’re not seeing 3 tiles then you’re not using my DTH.
Are you using GitHub integration or manually copying and pasting the code from my GitHub account?
Go to the devices screen and manually create a new device with my DTH and post a screenshot. It won’t be a functional device, but the UI should load properly
I stumbled on the DOME Z-wave Valve in Amazon, looking for a ST solution to a water theft problem - my neighbor doesn’t have a hose on my side of their house, so they like to use my water for watering their lawn / flowers on that side of their house. I installed a Nest camera on that side of the house, and caught them using my water / hose numerous times while I was at work during the day. I asked them about it - and they denied doing it. I showed them the camera was there, and showed them video of them doing it - they continued to keep using my hose / water afterwards - even spraying my Nest camera with my own hose / water a couple of times! I eventually installed a lock on the spigot, but that’s a PITA having to remember to take the key with me every time I want to use the water.
I was thinking about installing one of these DOME shut off valves on the ball valve in the basement that controls water to my spigots and lawn irrigation system. Since my iPhone is always on me - it would be easier to turn on the water from ST, then have it automatically shut off when the garage door closes.
It seems like everyone is using these valves to shut off mains in case of a leak. I would have to setup a schedule to turn on DOME valve from 3am - 6am to water lawn 3 days per week, then would also be turning it on/off frequently to water landscaping, wash cars, etc. Should I be concerned about using this valve 3 - 6 times per day? Is it intended for this kind of use? Or just as a safety precaution for a leak / flooding?
I originally connected my devices before I added the device handler (note I have 2 dome valve devices and both had same issue). It was working fine with the default ZWave Water Valve on Smartthings, but I found I wasn’t able to connect it to Alexa. I went through the instructions to remove the device, reset the device, and added it back, but it was still connected as a ZWaver water valve instead of the new Dome Device handler I installed. I manually used the Smartthings IDE to switch it to the new device handler. However, I found while I was able to open/close the valve, it never reported the status back to Smart Things. In the debug window I found the below error:
078d86ae-6b42-40f9-a55c-21aa9c362302 9:14:49 AM: error java.lang.NullPointerException: Cannot get property ‘ID’ on null object @line 331 (convertToLocalTimeString)
078d86ae-6b42-40f9-a55c-21aa9c362302 9:14:49 AM: debug Device Checked In
I don’t know why the code is giving me a Null Pointer Exception, but I proceeded to make the following code change on line 331 and now the device is working as expected and Alexa is also able to discover the device:
/*return dt.format("MM/dd/yyyy hh:mm:ss a", TimeZone.getTimeZone(location.timeZone.ID))*/
return dt.format("MM/dd/yyyy hh:mm:ss a", TimeZone.getTimeZone("EST5EDT"))
Note that I hard coded my timezone. If you are in a different timezone, then you will need to hard-code for your location.
You’ll get that error if your time zone isn’t explicitly set in your location settings so if you fix your time zone that error should stop.
Is there a version of this device handler that gives all the functionality in the new smartthings app?
This device doesn’t have any settings so what can’t you do with it using the built-in handler?
1 Like
It’s on.
And
Off.
Nothing else to it.
1 Like
If the Automations app supports the open and close commands then the switch functionality shouldn’t be needed for most use cases…
My apologies guys!! I’m just getting rolling with SmartApps and Device Handlers. I guess I confused this with another device that has more options when used with a custom DH.
So, I know this isn’t exactly the place for this question but… How can I tell if I’m using the default/built-in DH vs. or a custom one that I setup/publish within my own repository?
If I said to check the device in the ide does that make sense? Or no?
I can see all my devices on the ST Groovy IDE site. There are a few that supposedly have a custom or updated DH that provide more features.
For example, I have a few GE (Enlighten) Z-wave smart dimmers. I understand that there are more capabilities with that particular dimmer (Fade control, double tap - Depending on the Rev.) when using a custom DH.
I guess my question is, and again I apologize if this isn’t the right place, will I be able to tell if I’m using the Default DH or the custom one I setup on the IDE. Does creating / saving / publishing automatically make my ST use the new DH?
Thanks Tangus!!!
If you open the device in the IDE the “Type” field shows the handler that’s assigned to it and if you click edit you can change it to a different handler.
Devices have identifiers that are specified as fingerprints in the handlers so when you join a device ST assigns the handler based on the closest matching fingerprint. It checks the custom handlers you have installed before checking the built-in handlers so if you have a custom handler with an exact match then that’s the handler that will be assigned to it.
If you install the handler after the device is joined then you’ll need to manually change the devices type field.
The generic built-in handlers have a lot of fingerprints so if you don’t have a custom handler installed when you join this device it might display the correct device name, but if you check that Type field it will probably be something like “Z-Wave Water Valve”.
Thanks so much Kevin!!! That’s a huge help and it makes sense. I found the custom GE/Jasco Dimmer at the bottom of the list.
I changed 2 of my GE Dimmers. Interesting though… The dining room dimmer shows this under Route:
This Device (02) ↔ Kitchen Light (0B)↔ Kitchen Light (0B) ↔ SmartThings Hub
The Kitchen shows this:
This Device (0B) ↔ SmartThings Hub
Am I correct in assuming that the dining room should have the same route as the Kitchen… Device ↔ Hub? Or is the Kitchen Dimmer acting as a repeater/extender? Can Routes be modified?.. Should they be? The Dining Room and the kitchen are in different groups. The Kitchen Dimmer is physically located between the Dining Room dimmer and the Hub.
I also noticed when I changed the dimmers to “GE/Jasco Z-Wave Plus Dimmer Switch” the excution location changed to Cloud. This appears to be the same for the all the devices I changed the types for.
In messing around earlier I did change the Version to “Self Published”. Should it be Self Published or Published?
Do I need to do anything with the ST App or Hub after making modifications to my devices? Do I need to reboot the hub?
Except for a few rare exceptions, every non-battery z-wave device acts as a repeater and every z-wave device should know multiple routes to the hub.
If the route it took last time fails then it will try a different route and I think z-wave plus devices continue using the last successful route, but I’m not sure if the route speed makes a difference so I’m tagging @JDRoberts.
Running a z-wave repair from the hub utilities should optimize the route, but how often to do that is debatable.
The grouping in SmartThings has no impact on routing and the physical location doesn’t really matter when you have several devices that can reach the hub directly.
My hub is in the center of the middle floor and I noticed a plug that was 3’ from the hub was routing through a plug directly above it on the 2nd floor and to an LED bulb directly below it in my basement before going to the hub…
All custom handlers execute in the cloud and only some of the built-in handlers execute locally, but devices like a simple dimmer will often work with a handler that executes locally so after changing the settings you can change the type to the generic handler.
I think Smart Lighting still executes locally, but I’m not sure about Automations or Smart Home Monitor so if the app or any of the devices being used by the app don’t execute locally then the automation executes in the cloud.
I’ve always used published.
no.
I add and remove a lot devices while writing handlers and I’ll occasionally run into an issue where the hub stops populating the fingerprint information during inclusion, but I think that’s the only reason I’ve ever had to manually reboot the hub…
1 Like
Smartlighting is now the only code eligible to run locally. But not all smartlighting Automations will run locally, it depends on the specific devices, DTHs, and actions that are included. For example, you can’t change the mode locally. 
1 Like
For Z wave plus, it’s complicated. There can be multiple “preferred“ routes,“ and that can have to do with a lot of different factors, for example whether the devices support S2 encryption. The hub will notify the end devices of these preferred routes from time to time, and it will drop routes with a device which is being reported unavailable too many times.
It’s likely that a recently used route will be preferred, but if there’s been a new hub recommendation that might change.
1 Like
I knew z-wave meshes healed themselves, but I had no idea it was that complex so I’m glad I asked and thank you for the detailed explanation.
On a completely different note, if a physical switch supports Group 2 Associations for Basic Set, should it send the Basic Set message for physical and digital control or is that up to the manufacturer?
If it’s up to the manufacturer then what’s the most common implementation?