The ‘max’ is part of the fan speed capability. ST set up the capability to have 4 speeds (there’s no way to change it), but the general consensus is that Jascos only have 3. So… one of the 4 speeds is going to be nonfunctional no matter what. I debated making 100% map to max but it wouldn’t actually make the fan go faster.
I think 3x up then 3x down does factory reset. That’s actually kinda dangerous with multi-tap being more of a thing on switches these days.
My indicator changes are pretty quick. Usually instant, but there’s always the chance that the message is delayed a few seconds. It shouldn’t take too long. Honestly, if it’s not parameter 3 then I’d be willing to bet that it’s not supported. Jasco has been very consistent about using that parameter, even if they’ve sometimes changed which setting is which. If you can get live logging going (instructions below) then we can at least see whether the switches are getting/accepting the parameter changes.
My fan switch is also a 14287, and the indicator change works. Jasco has multiple firmware options within each model though, so it’s possible that ours are different.
Open a Command Prompt window and navigate to the directory where the CLI was downloaded.
The first time you use the CLI, you will be prompted to log into your SmartThings account. Run a list of your devices by typing:
smartthings devices
After authenticating the CLI, find the Driver ID for this driver by running:
smartthings edge:drivers:installed
Now start live logging by running the command below, entering the Driver ID found above and the IP address of your ST Hub in place of <DriverID> and <HubIP>:
Wrong profile then - I’ve switched it to the correct one. The 14318 will need the hub (should be node 1) in association group 3 for double tap to work. I’m not sure if the change in profile will push through to your switch since it’s already using the driver though, and I think fingerprinting to a profile only happens when the device is onboarded into the driver. An exclude/include will be the cleanest approach - it will definitely get it to the correct profile, and the driver will take care of the association group assignment on a fresh install. Alternatively, if you install the zwave-switch driver from the ST beta channel you should be able to switch to that driver and then back to pick up the right profile, though I don’t think the association group assignment will happen automatically if you go this route (going into settings and editing in that association group 3 - even adding something invalid like a period - will trigger it though).
Since you have the CLI installed now, you can push the new version to your hub immediately with smartthings edge:drivers:install.
Would it break anything if you were to rename ge-dimmer-assoc to something where the ‘dimmer’ is not isolated by delimiters? I suspect that Google Home gets that string and forces the device type to light.
I may have multiple lights in a room, but I typically only want Google to turn on particular devices when I say ‘light on’. Under the old model, there are 2 fields-- Name and Label. I know Google looks at both aggressively searching for anything that would signal a ‘light’. I have to use names like Ljght and Djmmer. The ge-motiondimmer-assoc is seen as a switch-- probably because the words run together.
It may not be obvious, but the proper way to specify ‘switch’ or ‘light’ or ‘fan’ is by changing the icon in SmartThings. However, even if I change the icon to ‘switch’, Google still treats the dimmer as a light.
Ideally, the ‘Name’ field would be the brand/model with no further description.
If this change is too user-specific, I can create a fork.
Answering this first from a mechanical perspective… yes it would break things. When a driver update is packaged, an error is thrown if any existing profile names are absent from the update. Changing a profile name would require packaging the driver under a new package key, and then existing devices would need to be manually moved from the old driver to the new.
To add to the difficulty… the name field is currently set based on the name of the profile that the device first joins to. It never gets updated if you switch drivers or profiles, and I have yet to find any way to update it as a user or through code. I’m expecting that we’ll have a name change option in the future, but as of now changing that name requires an exclude/include.
Maybe. I have a switch that shows as a lightbulb in Google that has a label of “Foyer Switch” and a name of “ge-switch”. Meanwhile, the device with a label of “Living Room Switch” and a name of “ge-switch” shows as a switch.
My best guess would be that Google is pulling from one of the metadata fields in the profile. There are at least 4 different metadata fields to identify device type though, and I haven’t seen documentation on which is controlling. I’ve updated the driver to add the ones I hadn’t previously included - I initially had the bare minimum of those fields in these profiles based on what I’ve seen in the ST drivers. But… I’m not seeing any impact with that change, even after excluding/including a dimmer.
I can confirm that Google is using the ‘dimmer’ in the device name to force the device to ‘Light’.
I went back to the IDE, clicked on edit, changed the name and filled in the missing information to avoid an error.
After that things get kinda fuzzy. I had to wiggle SmartThings/Google Home to get the change to propagate. Google now sees the dimmer as a switch. I also ended up hosing the device on the SmartThings side. A few driver swaps and reboots and things seem back to normal. I actually only have the 1 Jasco dimmer, so I’m good for now.
Played around a bit with two devices that I excluded/included fresh and I think there are a couple things going on. I think the metadata was necessary, and your wiggling around somehow got that to push to Google Home. The two fresh includes can show a switch in Google Home while others are stuck on light.
I’m not sure whether the name has an impact, as I didn’t bother trying to change it. I would guess it’s either not being passed to Google or it behaves the same as the label. I’m now satisfied that ‘dimmer’ in the name doesn’t limit the device type choices though.
The label definitely matters. On the two devices that definitely have the updated metadata pushed to Google, having ‘light’ in the label results in the device type being stuck on light. Having ‘dimmer’ or ‘switch’ seems to let the metadata control, with the option to change the device type showing up on the device settings page in the Home app.
I didn’t realize the device type could (sometimes) be changed within Google Home. That’s a valid workaround when ‘dimmer’ appears in the ST name or label. As you’ve noted, including the word ‘light’ or changing the ST icon to a light will lock things down to ‘light’ within Google.
Howdy all
Went to install your edge driver for a 46201 Jasco switch and am getting the following error.
“… Request failed with status code 400 occured” First I’ve seen this, then I’m a noob so I’ll wait & try again tomorrow.
Looking forward to using your drivers, thanks for your efforts.
R George
A couple of developers have reported that they’re getting the same error message (see the topic below), so I’d say it’s a platform issue and not anything that you’re doing wrong.
