New/Current Hubitat users and our switches !PLEASE READ!

anon64478871 · January 30, 2020, 12:39am

New/Current HE users here that are installing our switches. Please be aware that when you include our switches Hubitat seems to be enforcing to use their versions of the drivers which is fine for most cases but not if you are setting up 3-way. The HE versions of the drivers do not support this. You need to install our versions of the drivers to complete your 3-way setup.

This also applies to non-neutral setups. You MUST use our drivers to support this.

You can find our Hubitat drivers at Hubitat/Drivers at master · InovelliUSA/Hubitat · GitHub

~~If you want to use the BLACK/RED series LED notifications you will need to install our child switch also.~~ You no longer need this as we use the Generic Component Switch that HE already has.

anon64478871 · January 30, 2020, 12:40am

Almulder · January 30, 2020, 10:31pm

Would be nice if you could label the child device driver better,

Instead of
name: “Switch Child Device”

This:
name: “Inovelli Child Switch Device”

Instead of
name: “Switch Level Child Device”

This:
name: “Inovelli Child Switch Level Device”

I know how I can update the drivers both to reflect the change, but others might not. And I have seen people complain. Especially when they need to update a driver and everyone likes to use the generic name child device naming. Its minor but might be worth updating the code. IMO

Also for the Hubitat version, you still reference Smartthings within it. And unable to delete child devices without removing switch and re adding. (Please fix)

anon64478871 · January 30, 2020, 11:18pm

@EricM_Inovelli needs to make these changes and I know exactly what you mean… it is confusing.

EricM_Inovelli · January 31, 2020, 5:50am

Hi @Almulder, thanks for the suggestions. I will definitely look into this going forward, but I am curious why the namespace isn’t a good enough indicator as to which driver is which. For example, the namespace is InovelliUSA so in a sense the driver is InovelliUSA:Switch Child Device. By default the drivers should look for their child device in the same namespace. So our InovelliUSA drivers will install the InovelliUSA child driver.

As for not being able to delete the child devices, I can definitely update that. It has to do with how they are created and I’m honestly not sure why Hubitat doesn’t allow you to delete them. There is a trick to be able to delete them even when they are in this state though.

anon64478871 · February 10, 2020, 5:45am

Thanks Eric – this was driving me insane. Hope you come out with a fix for this.

EricM_Inovelli · February 10, 2020, 11:27pm

The fix for deleting the child devices is in the latest drivers. The bad thing is that the child devices need to be recreated with the new driver in order to be deleted. So it will work on new devices you add, but the old child devices you will have to delete them first with the method above (which kind of defeats the purpose of the change but oh well).

BertABCD1234 · February 17, 2020, 8:08pm

Hubitat doesn’t show you the namespace in the driver dropdown, so if you have multiple manufacturers’ drivers that use the same name, it’s hard to tell when actually selecting the driver. But this isn’t really something users need to do for the Inovelli devices (they’re created automatically), so perhaps there’s another manufacturer or situation where this is needed that this user is thinking of. I’m not sure otherwise.

In any case, for Hubitat, Inovelli really doesn’t need to provide child switch or switch level drivers. Hubitat has them built into the platform. Here’s their Generic Component Dimmer driver (basically switch level; technically also includes the ChangeLevel capability–new to Hubitat compared to ST–but I can think of workarounds you can use to not really care about those functions), which is built into the platform:

github.com

hubitat/HubitatPublic/blob/master/examples/drivers/genericComponentDimmer.groovy

/*
	Generic Component Dimmer
	Copyright 2016 -> 2020 Hubitat Inc. All Rights Reserved
	2020-04-16 2.2.0 maxwell
		-add missing log method
	2019-09-07 2.1.5 maxwell
        -refactor declarations
	2018-12-15 maxwell
	    -initial pub

*/
metadata {
    definition(name: "Generic Component Dimmer", namespace: "hubitat", author: "mike maxwell", component: true) {
        capability "Light"
        capability "Switch"
        capability "Switch Level"
        capability "ChangeLevel"
        capability "Refresh"
        capability "Actuator"
    }

This file has been truncated. show original

There is a similar driver for generic component switches. It’s actually pretty similar to what Inovelli does with their own child drivers aside from passing the device vs. device DNI up to the parent. Here’s an example of how a parent device can handle this child (this is a demo only and not included in the platform, not that it would do much if it were):

github.com

hubitat/HubitatPublic/blob/master/examples/drivers/genericComponentParentDemo.groovy

/*
    Generic Component Parent Demo
    Copyright 2019 Hubitat Inc.  All Rights Reserved
    2019-09-07 (public repo only) maxwell
        -initial pub

*/

metadata {
    definition (name: "Generic Component Parent Demo", namespace: "hubitat", author: "Mike Maxwell") {
        capability "Configuration"
        
        //demo commands, these will create the appropriate component device if it doesn't already exist...
        command "childSwitchOn"
        command "childSwitchOff"
        command "childDimmerOn"
        command "childDimmerOff"
        command "childDimmerSetLevel", ["number"]
        command "setTemperature", ["number"]

This file has been truncated. show original

So…with a few minor changes, you could probably spare Hubitat users from even needing to install the child drivers, or at least the switch ones (again, switch level is a bit more, but you could just document that startLevelChange/stopLevelChange either don’t work or go immediatlely to 100 or 0 or something to that effect).

EricM_Inovelli · February 25, 2020, 10:30pm

Ok, yeah, that makes sense.

That is a good idea to use the Hubitat built in child drivers. I’m trying to think of a way to preserve backwards compatibility though. It looks like it will mostly work except the Hubitat child drivers use componentOn & componentOff instead of childOn & childOff. I think if I add those additional methods to the parent though it should work.

geekdaddy · March 5, 2020, 12:48pm

I’ve been using the github code in my hubitat driver code (vs std drivers) for my Inovelli switches. However, I was recently made aware that you’ve updated the github code for red and black dimmers (my driver code was from last Nov/Dec). I’ve updated to the latest driver code but have a dumb question: How do I ensure the switches USE the new driver code in hubitat?

I went into my Inovelli devices within hubitat, selected a different driver, and then the updated driver and hit save. Am I OK?

harjms · March 5, 2020, 2:24pm

@geekdaddy - I believe they only switched to Hubitats code for the child switch, not the device driver. I recommend switching back to githubs code dated 25Feb20.

Terk · March 5, 2020, 4:45pm

All you should need to do is update the driver code. The switch should automatically use that code as long as that is the driver type selected for the switch. Any newly paired switch will likely automatically select the built in driver so you may have to change new switches to the user code if you want the extra features provided by that code.

anon64478871 · March 10, 2020, 1:55am

@geekdaddy yes

The child device change will not be affected by the new code.

Absolute · March 10, 2020, 6:37pm

Thanks for the post - I had gone through the original install directions, and only now realized that my first (test) LZW30-SN was using the native Hubitat drivers!

Edit: For some reason I was focused on the hub config; I didn’t look at the config button cheat codes to disable the internal relay.

One suggestion; the PDP for the LZW30-SN links to the LZW31-SN device code under the “Installation Instructions” for Hubitat, even though the next tab of Device Code has the proper link to the LZW30-SN code.

anon64478871 · March 10, 2020, 8:47pm

Yup we know about that typo New website will have all this corrected.

Ma2J · March 10, 2020, 9:18pm

? New Website?..

harjms · March 11, 2020, 6:19pm

@Scott_Inovelli - Great…Let’s continue beating around the bush and keeping this published so that it continues to be brought up in topics as an issue. Why not fix it or take it down? @EricM_Inovelli @Eric_Inovelli @Brianna_Inovelli

harjms · March 11, 2020, 6:47pm

@anon64478871 - Thus is why I tagged them. I don’t feel I need to PM the owner or community rep when it’s already document multiple times here. I also feel it was incorrect of you to delete my post. I’ve contributed a lot of off time to helping members of this community as well as to Eric getting things tested when the products initially launched while continuing to help others. Thus lessening the burden on the employees of Inovelli. My suggestion would be to put it back up. @Eric_Inovelli @Brianna_Inovelli

Eric_Inovelli · March 11, 2020, 7:02pm

Hey sorry about that! Just updated the link

Eric_Inovelli · March 11, 2020, 7:05pm

Agree with you 100% James – sorry. We’ve put the post back up and I’ve fixed the link. Thank you for all your contributions. You’ve sincerely helped us out a ton and continue to serve.

It’s hard to balance the community and other day to day business projects, so I definitely appreciate your help and also sincerely hope I can get back in here more often. I was alerted to this post and wanted to promptly fix it.

Now back to Excel… ugh.