WWSTCERT-8360 Inovelli VZW32-SN: Adding support for this device for the WWST program #2371
Conversation
…mware update process during certification
|
Duplicate profile check: Passed - no duplicate profiles detected. |
|
Channel deleted. |
Test Results 71 files 475 suites 0s ⏱️ Results for commit 8732870. ♻️ This comment has been updated with latest results. |
|
Minimum allowed coverage is Generated by 🐒 cobertura-action against 8732870 |
greens
changed the title
| - id: colorTemperature | ||
| version: 1 | ||
| config: | ||
| values: | ||
| - key: "colorTemperature.value" | ||
| range: [ 2700, 6500 ] |
There was a problem hiding this comment.
You can now simply define the range your bulb supports in code using the colorTemperatureRange attribute.
There was a problem hiding this comment.
@greens
Should I do something like this during device initialization then?
device:emit_event(capabilities.colorTemperature.colorTemperatureRange({ value = {minimum = 2700, maximum = 6500} }))
device:emit_event(capabilities.colorTemperature.colorTemperature(6500))
Then, should I change the profile to rgbw-bulb.yml and take out the config section?
| - id: firmwareUpdate | ||
| version: 1 |
There was a problem hiding this comment.
Since you're not emitting any events using this capability, please omit it.
If we do add OTA support for z-wave in the future, we will handle adding it to device profiles as necessary.
There was a problem hiding this comment.
Please remove this capability.
drivers/SmartThings/zwave-switch/src/inovelli-vzw32-sn/init.lua
Outdated
Show resolved
Hide resolved
drivers/SmartThings/zwave-switch/src/inovelli-vzw32-sn/init.lua
Outdated
Show resolved
Hide resolved
drivers/SmartThings/zwave-switch/src/inovelli-vzw32-sn/init.lua
Outdated
Show resolved
Hide resolved
drivers/SmartThings/zwave-switch/src/inovelli-vzw32-sn/init.lua
Outdated
Show resolved
Hide resolved
| local device_init = function(self, device) | ||
| if device.network_type ~= st_device.NETWORK_TYPE_CHILD then | ||
| device:set_component_to_endpoint_fn(component_to_endpoint) | ||
| device:set_endpoint_to_component_fn(endpoint_to_component) | ||
| --initialize(device) | ||
| end | ||
| end |
There was a problem hiding this comment.
you should no longer need to override the base driver's init function now (or the endpoint/component mapping functions)
|
I just noticed my motion sensor isn't initializing for the main device. I thought "refresh" would catch it, but I can add it explicitly on Monday. |
|
@InovelliUSA our defaults for motion sensor rely on the |
We are using the NOTIFICATION command class. |
|
@InovelliUSA Then I would suggest overwriting the refresh handler with a new function that first calls |
Something strange is happening when I do this. The process is working fine on the Zigbee driver, but the Z-wave driver becomes unresponsive when I use "refresh". I have tested a few different variants. Even this one causes the driver to stop responding: local function refresh_handler(driver, device) I will sometimes this in the logs after some time of hitting the refresh button: 2025-10-29T21:10:35.357313398Z TRACE Z-Wave Switch Found CapabilityCommandDispatcher handler in zwave_switch -> inovelli vzw32-sn handler |
|
@InovelliUSA that was my mistake. Z-Wave and Zigbee handle The fix is to use Also I noticed the same thing with the z-wave version of the vzw-31 that we saw with zigbee, so I'd ask you to consolidate here as well. Good news is that there is already a parent driver: https://github.com/SmartThingsCommunity/SmartThingsEdgeDrivers/tree/main/drivers/SmartThings/zwave-switch/src/inovelli-LED |
|
@greens I've combined the Inovelli drivers. I had to make some tweaks to ensure backwards compatibility with our last gen switches (which is what the other drivers were written for). I've got things setup so I should be able to add the vzw31 and vzw30 with minimal code added. I'll work on the certification of those devices soon. |
| ["button1"] = {"pushed","held","down_hold","pushed_2x","pushed_3x","pushed_4x","pushed_5x"}, | ||
| ["button2"] = {"pushed","held","down_hold","pushed_2x","pushed_3x","pushed_4x","pushed_5x"}, |
There was a problem hiding this comment.
The issue with this change is that added will not be called for already-installed devices. Devices that were installed with the previous version of the driver will not issue this updated supported button event, and your driver will cause issues when it tries to generate a "held" event for these devices.
You may want to add a check in the scene handler to make sure that the supportedButtonValues attribute is correct before generating a held or down_hold event.
There was a problem hiding this comment.
Ok, I am working on this. I currently have it implemented to send the supportedButtonValues in the scene handler if the value doesn't exist. This means that a button will need to be pressed on the switch to make this fire off. Is there a way to just have it fire off when an update to the driver is pushed out? Like once the hub gets the updated driver it runs "init" or something else and does the check at that point?
There was a problem hiding this comment.
@InovelliUSA unfortunately not. Updating it in the Scene Handler if the value is not what you expect it to be is probably the correct way to handle it. I'd leave a comment indicating that the code can be removed at some point in the future.
There was a problem hiding this comment.
Is the VZM32-SN driver live or is there a link I can use to install it? I am trying to test the process going from that version to my new one and trying to find a quick way to do that.
There was a problem hiding this comment.
We've got this fingerprint, which is the one I'm concerned about:
- id: "Inovelli/Dimmer/Power/Energy"
deviceLabel: Inovelli Dimmer Switch
manufacturerId: 0x031E
productType: 0x0001
productId: 0x0001
deviceProfileName: inovelli-dimmer-power-energy
That's in the production default driver. You could try driver-switching, but I think the added event gets fired in the event of a driver switch, so the best way to test is to probably first create a custom channel with the current top-of-tree version of z-wave switch, add and install it to your hub, and join the device with the above fingerprint. After it's installed, you can update the driver to the code you have here, and install it again on the hub to update. You should be able to verify that the version has changed in the app and then you should be able to verify what the behavior will be like when we update the driver via deploy.
There was a problem hiding this comment.
I've made the changes for backwards compatibility but now it looks like there are some conflicts from changes that have been happening while the PR has been open. I will have to look into how to resolve them.
There was a problem hiding this comment.
@greens The conflicts have been taken care of and it looks like the driver is passing.
…likely be removed in the future
| if device.network_type ~= st_device.NETWORK_TYPE_CHILD then | ||
| device:send(Association:Set({grouping_identifier = 1, node_ids = {driver.environment_info.hub_zwave_id}})) | ||
| for _, component in pairs(device.profile.components) do | ||
| if component.id ~= "main" and component.id ~= LED_BAR_COMPONENT_NAME then | ||
| device:emit_component_event( | ||
| component, | ||
| capabilities.button.supportedButtonValues( | ||
| supported_button_values[component.id], | ||
| { visibility = { displayed = false } } | ||
| ) | ||
| ) | ||
| device:emit_component_event( | ||
| component, | ||
| capabilities.button.numberOfButtons({value = 1}, { visibility = { displayed = false } }) | ||
| ) | ||
| end | ||
| end | ||
| refresh_handler(driver, device) | ||
| local ledBarComponent = device.profile.components[LED_BAR_COMPONENT_NAME] | ||
| if ledBarComponent ~= nil then | ||
| device:emit_component_event(ledBarComponent, capabilities.colorControl.hue(1)) | ||
| device:emit_component_event(ledBarComponent, capabilities.colorControl.saturation(1)) | ||
| end | ||
| else | ||
| device:emit_event(capabilities.colorControl.hue(1)) | ||
| device:emit_event(capabilities.colorControl.saturation(1)) | ||
| device:emit_event(capabilities.colorTemperature.colorTemperatureRange({ value = {minimum = 2700, maximum = 6500} })) | ||
| device:emit_event(capabilities.switchLevel.level(100)) | ||
| device:emit_event(capabilities.switch.switch("off")) | ||
| end |
There was a problem hiding this comment.
Should I make these changes even though the PR is approved, or should I make them in a different PR?
There was a problem hiding this comment.
Could you make them now? I'll merge after.
| -- Copyright 2025 SmartThings | ||
| -- | ||
| -- Licensed under the Apache License, Version 2.0 (the "License"); | ||
| -- you may not use this file except in compliance with the License. | ||
| -- You may obtain a copy of the License at | ||
| -- | ||
| -- http://www.apache.org/licenses/LICENSE-2.0 | ||
| -- | ||
| -- Unless required by applicable law or agreed to in writing, software | ||
| -- distributed under the License is distributed on an "AS IS" BASIS, | ||
| -- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | ||
| -- See the License for the specific language governing permissions and | ||
| -- limitations under the License. |
greens
changed the title
2 participants
Check all that apply
Type of Change
Checklist
Description of Change
Summary of Completed Tests