inovelliusa / hubitat

Location for Inovelli Hubitat Drivers and Apps

Hubitat

Location for Inovelli Hubitat Drivers and Apps

hubitat's Issues

Add Push & Hold button commands to all scene capable switches

Currently, we cannot access scenes set up via mechanical button Push and Hold events in Hubitat's RM, etc. Can we add these commands to the drivers of all scene capable switches?

lzw31-sn componentOn() does not work for dimmer's LED

dev:38612020-05-15 06:35:17.144 pm errorjava.lang.ArrayIndexOutOfBoundsException: -1 on line 1238 (componentOn)
dev:38612020-05-15 06:35:17.107 pm infoOffice Light Switch: childSetLevel(45-ep103, 99)
dev:38612020-05-15 06:35:17.097 pm infoOffice Light Switch: childOn(45-ep103)
dev:38612020-05-15 06:35:17.095 pm infoOffice Light Switch: componentOn(Office Light Switch (LED Color))

The child device for the LED bar is created as ep103 (channel 103), but the code only supports channels 9, 10, 101, & 102

Homebridge/Hubitat Integration with LZW42

I'm having some issues getting the LZW42 to work correctly with combination of Hubitat <> Maker API <> Homebridge.

In Hubitat, all the functions work correctly sans the hue and saturation "buttons".

When using HomeKit/Homebridge the color temperature, dimming, and on/off work. However, when I try change the RGB settings the color does not change and the screen snaps back to the color temperature selection screen. If I try to adjust color temperature, it does change temperature but HomeKit UI doesn't retain the value.

I tried having a look at the driver code but I'm not too familiar with the ZWave specification or Groovy. I see a parse error for command 3304 when setting color in Hubitat but it does succeed. It looks like HomeKit is setting hue and saturation which in turn call setColor. While Hubitat is calling setColor directly with both hue and saturation. Not sure if that's the issue but it's only connection I could see.

Here's the debug log when trying to change RGB via HomeKit -> Homebridge -> Maker API -> Hubitat

app:422019-12-26 11:22:51.247 pm debugdeviceItem called
app:422019-12-26 11:22:51.242 pm debugdeviceItem called
app:422019-12-26 11:22:51.237 pm debugdeviceItem called
app:422019-12-26 11:22:51.232 pm debugdeviceItem called
app:422019-12-26 11:22:51.227 pm debugdeviceItem called
app:422019-12-26 11:22:51.222 pm debugdeviceItem called
app:422019-12-26 11:22:51.217 pm debugdeviceItem called
app:422019-12-26 11:22:51.212 pm debugdeviceItem called
app:422019-12-26 11:22:51.207 pm debugdeviceItem called
app:422019-12-26 11:22:51.202 pm debugdeviceItem called
app:422019-12-26 11:22:51.197 pm debuglistDevices called
dev:712019-12-26 11:22:50.137 pm debugsetColor([saturation:74])
dev:712019-12-26 11:22:50.134 pm debugsetColor([hue:59])
app:422019-12-26 11:22:50.131 pm debug[NUMBER]
app:422019-12-26 11:22:50.128 pm debug[NUMBER]
app:422019-12-26 11:22:50.125 pm debug[configure, off, on, ping, refresh, setColor, setColorTemperature, setHue, setLevel, setSaturation]
app:422019-12-26 11:22:50.122 pm debug[configure, off, on, ping, refresh, setColor, setColorTemperature, setHue, setLevel, setSaturation]
app:422019-12-26 11:22:50.118 pm debug[74]
app:422019-12-26 11:22:50.115 pm debugsetSaturation
app:422019-12-26 11:22:50.111 pm debug[59]
app:422019-12-26 11:22:50.108 pm debugsetHue
app:422019-12-26 11:22:50.105 pm debugfindDevice called
app:422019-12-26 11:22:50.101 pm debugsendDeviceCommandSecondary called
app:422019-12-26 11:22:50.098 pm debugfindDevice called
app:422019-12-26 11:22:50.095 pm debugsendDeviceCommandSecondary called
dev:712019-12-26 11:22:49.424 pm debugsetColor([saturation:74])
dev:712019-12-26 11:22:49.420 pm debugsetColor([hue:59])
app:422019-12-26 11:22:49.417 pm debug[NUMBER]
app:422019-12-26 11:22:49.414 pm debug[NUMBER]
app:422019-12-26 11:22:49.411 pm debug[configure, off, on, ping, refresh, setColor, setColorTemperature, setHue, setLevel, setSaturation]
app:422019-12-26 11:22:49.408 pm debug[configure, off, on, ping, refresh, setColor, setColorTemperature, setHue, setLevel, setSaturation]
app:422019-12-26 11:22:49.404 pm debug[74]
app:422019-12-26 11:22:49.401 pm debugsetSaturation
app:422019-12-26 11:22:49.398 pm debug[59]
app:422019-12-26 11:22:49.387 pm debugfindDevice called
app:422019-12-26 11:22:49.384 pm debugsetHue
app:422019-12-26 11:22:49.381 pm debugsendDeviceCommandSecondary called
app:422019-12-26 11:22:49.377 pm debugfindDevice called
app:422019-12-26 11:22:49.374 pm debugsendDeviceCommandSecondary called

Here is the logs when using the set color button in Hubitat:

dev:712019-12-26 11:34:20.993 pm debugCouldn't zwave.parse 'zw device: 03, command: 3304, payload: 04 FF , isMulticast: false'
dev:712019-12-26 11:34:20.918 pm debugCouldn't zwave.parse 'zw device: 03, command: 3304, payload: 03 B2 , isMulticast: false'
dev:712019-12-26 11:34:20.886 pm debugCouldn't zwave.parse 'zw device: 03, command: 3304, payload: 03 B2 , isMulticast: false'
dev:712019-12-26 11:34:20.810 pm debugCouldn't zwave.parse 'zw device: 03, command: 3304, payload: 02 00 , isMulticast: false'
dev:712019-12-26 11:34:20.746 pm debugCouldn't zwave.parse 'zw device: 03, command: 3304, payload: 01 00 , isMulticast: false'
dev:712019-12-26 11:34:20.693 pm debugCouldn't zwave.parse 'zw device: 03, command: 3304, payload: 00 00 , isMulticast: false'
dev:712019-12-26 11:34:20.515 pm debugsetColor([saturation:100, hue:55, level:100])

Any help with the driver would be greatly appreciated!

Hide component action commands from parent device

The LZW31 (for example) has buttons that are non-functional in the GUI as they pertain to the component child devices. Please remove the commands for the component child devices from the device metadata definition.

Ex:

        command "componentOn"
        command "componentOff"
        command "componentSetLevel"
        command "componentRefresh"
        command "componentSetColor"

these commands should be removed from the definition section to clean up the clutter and because the are non-functional in the web interface.

Need to use "getIsStateChange()" for power and energy event handling in virtual device sync app

Just a quick tweak to match the behavior you ported for physical event handling to power and energy event handling. Hubitat doesn't have an isStateChange() function.

LZW-36 - "Switch" shows incorrect value.

deleted this issue as it seemed to be resolved by an updated firmware to Hubitat.

LZW30-SN Driver (commands commented out)

For the latest LZW30-SN Hubitat driver, the button press commands are commented out.

Amazon Echo says LZW31-SN switch "is not responding" for "on" or "percent" events (though events are successful)

I'm using Hubitat version: 2.1.8.117 and have an Inovelli Dimmer Red Series LZW31-SN configured using the latest Inovelli Dimmer Red Series LZW31-SN driver (2020-01-28) and named "Dining Room Switch". I also have the Hubitat Amazon Echo Skill installed and configured and working fine with my Amazon Echo.

If I ask Alexa to "turn off Dining Room Switch", she does this reliably and knows it was completed successfully. But, if I ask her to "turn on Dining Room Switch" or "set Dining Room Switch 50%", she does this reliably as well, but then flashes her lights a few seconds afterwards and says "Sorry, Dining Room Switch is not responding."

Google Home (through the Hubitat Google Home skill) has no issue with the same commands and knows it completed successfully.

Is there something I need to configure to help Alexa understand that the Inovelli switch responded and executed the requested action successfully?

LZW36 - Extra Child Devices

When I add the LZW36 to Hubitat, it is initally installed with the "Inovelli Fan/Light Switch Driver" with two child devices "Fan" and "light".

When I then change to the custom driver from this github forum, I end up with 4 child devices as shown below. Only the new ones "Inovelli Fan/Light Switch (Fan)" and ""Inovelli Fan/Light Switch (Light)" are functional. It appears that when switching drivers, the new driver adds it's child devices, but "forgets" to remove any existing ones. Please fix this!

Hub version: 2.2.3.119
Firmware: Happens on both 1.31 and the beta 1.36.

See image below:

Hubitat child device turns off when device turns off

When using the new drivers that use the built in Hubitat child device. If the device is turned off locally or remotely the child device turns off. Thus clearing any notification.

Renaming switch doesn't rename already created child devices

When I add a child device, it populates the name as "{parentName} (LED Color)" or similar, using the current name of the parent device. If I rename the parent device, the original name remains unchanged.

I would expect that renaming the parent device would trigger a rename of all active child devices.

This is especially problematic because the current version of the driver seems to create an LED Color child device by default when including the dimmer, but at that point the name of the device is "Inovelli Dimmer Red Series LZW31-SN". As a result, even if I enter an appropriate name right away, I'm left with all of my dimmers having child devices named only based on the model number. This is not a good experience.

I have experienced this with the red series dimmer, red series switch, and black series switch. I haven't tested any other devices. It may also affect other drivers as well.

My current workaround is to

1. Name the parent device what I want
2. Remove all the child devices
3. Add back the ones I want

But this is cumbersome and would be difficult if I already had child devices included in automations.

Removing nodes from association group will add them if none exist

I was reading through the code to try to learn more about how association groups work, and I found what appears to be a bug in the 4-in-1 sensor driver. I didn't look to see if the same bug is present in other drivers as well.

Hubitat/Drivers/inovelli-4-in-1-sensor.src/inovelli-4-in-1-sensor.groovy

Line 704 in 1b6a550

state."desiredAssociation${group}" = nodes

If state."desiredAssociation${group}" is null, the condition at the beginning of the function which seems designed to avoid a null pointer exception is assuming that the method was called with an attempt to add nodes, not remove them. That's probably true, but not necessarily; you can never fully predict what the user will try to do. As a consumer of the code, I find this behavior counter to what I'd expect. I'd expect an attempt to remove nodes from a null list to either be a no-op or an error.

I think it would be really easy to fix this to be a no-op, using the groovy "elvis" operator ?:. Just replace the entire method body with this:

        switch (action) {
            case 0:
                state."desiredAssociation${group}" = state."desiredAssociation${group}" ?: [] - nodes
            break
            case 1:
                state."desiredAssociation${group}" = state."desiredAssociation${group}" ?: [] + nodes
            break
        }

Note: I haven't tested this.

Group association function does not work on Hubitat

The node (if only one is provide) is not a list. Adding group 23, adds groups 02 and 03. to work around the issue, had to add modify the function to force "nodes" variable to an array []. Then had to add two nodes, and then remove one node.

VZM35-SN driver not available in Hubitat Package Manager

I have Hubitat Package Manager managing VZM31-SN driver updates but the VM35-SN driver is not yet available.

It would be great to have it automatically updated as well.

LZW42 Set Color Temperature not working

Hubitat built in driver is working fine against firmware 2.30, but pushing the Set Color Temperature command from this driver does not result in any activity.

Please remove tiles sections

Hubitat does not use the tiles section of the code. Please remove tiles from HE code to keep code waste to a minimum. Thanks!

LZW31-SN Shows as outlet instead of dimmer in HomeKit

When using the new HomeKit beta app in HE, the Inovelli Drivers here show up as an outlet in the HomeKit app and on Apple Home, only allowing on/off activity, without dimming. I just ugpraded firmware to the latest beta firmware available in the switches, and the latest upgrade for HE that just came out today,

Gen2 Drivers fail to update using Hubitat Package Manager (C7 Latest Firmware and up to date on HPM)

Received a notice that I got an update for Innovelli Drivers this morning that will not update. Logs say "fatal error" and error message says to make sure the app/driver is not in use. I do have the innovelli drivers for my RED switches. But, I do not have the BLUE series installed. But, even if I did, what would be the point of automatic updates if I have to change all the drivers before I can run the updates. I do not think I can choose only the drivers I use out of the Series 2 drivers.

Logs appear to be generic even though I have all the debug options enabled. If I could get more information, I would.

Tried twice on phone app(chrome?) and once on computer (firefox).

Automatic Update?

Hi,

Is there any method for automatically updating this driver code from within the Hubitat interface?

2023-08-14 Red Series 2-1 device driver - error in processAssociations() breaks updated() and configure()

I just downloaded this latest Red 2-1 driver from 2023-08-14 and tried to use with a new dimmer switch in Hubitat. I'm unable to change any config options through the Hubitat device details dashboard due to an error on line 2103 in the processAssociations() method. Reverted to the 2023-07-03 driver and everything works again.

Hubitat log below. Updated works on first run, but fails on all subsequent runs.

dev:10832023-08-31 07:38:01.304 PM error java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 0 on line 2103 (method updated)
dev:10832023-08-31 07:38:01.271 PM info RedDimmer There are no association actions to complete for group 1
dev:10832023-08-31 07:38:01.230 PM info RedDimmer updated()

dev:10832023-08-31 07:37:44.325 PM info RedDimmer Associations for Group 6: []
dev:10832023-08-31 07:37:44.216 PM info RedDimmer Info Logging will be disabled in 20 minutes
dev:10832023-08-31 07:37:44.214 PM debug RedDimmer Debug logging Disabled
dev:10832023-08-31 07:37:44.211 PM trace RedDimmer Trace logging Disabled
dev:10832023-08-31 07:37:44.205 PM info RedDimmer Info logging Enabled
dev:10832023-08-31 07:37:44.198 PM info RedDimmer No DEVICE settings were changed
dev:10832023-08-31 07:37:44.129 PM info RedDimmer Association info not known for group 6. Requesting info from device.
dev:10832023-08-31 07:37:44.126 PM info RedDimmer There are no association actions to complete for group 1
dev:10832023-08-31 07:37:43.968 PM info RedDimmer updated()

Doubl/Triple tap and Release

The only actionable actions in the Button Controller app for the Red Switch (and I imagine some of the other Inovelli switches) are push and hold. Double and triple taps as well as well as release are not supported. Can you please update the driver so that these actions can be programmed in Button Controller and not just Rule Machine?

Convert to Hubitat Generic Component Child Devices

Any plans to convert from custom child devices to the Hubitat Generic Component Child Devices? Doing so reduces the number of custom device drivers to install on the HE. If willing, I am happy to begin the process for various devices one-at-a-time.

Releases?

Is there any chance you would consider using github's releases feature to create releases of the drivers? I would like to watch for releases and not necessarily get notified about all of the issues/updates. Thanks!

Errors on Hubitat 2.2.4.158

I'm getting the errors shown below when trying to use the Child Off / Child On / Component Off / Component On functions in Hubitat version 2.2.4.158.

LZW31-SN (Red Series) disable local (zwave) control not working

I have not looked into the code to see if it is implemented correctly or not. This is just a holder for now to identify that the disable local control setting does not do anything. This feature works find on the NZW31 and NZW30 devices. I have not tried it on the LZW-30. It definitely is problematic on the LZW31-SN though. I will try it on the LZW31 tomorrow if I get a chance to install that dimmer in my bathroom this weekend (as I will need it for that one).

Also, I did not confirm the firmware version yet.