I’m attempting to create a routine through smartthings to disable the motion sensor during the day and enable it during the evening. (I don’t need my lights to turn on automatically if it isn’t dark outside.) None of the exposed commands allow me to modify parameter 110 (Light On Presence Behavior) and I’m unable to find any good reference examples that explain how to create a rule in the Smartthings Advanced API to modify a device parameter and don’t even know if this is possible. I’m requesting a feature to provide access to modifying this parameter as a command, or to enable a feature that disables actions to turn on/off the lights when there is sufficient daylight. I’m also open to anyone correcting me toward a more appropriate path to implement this behavior.
Thanks for the suggestions!
That’s not how SmartThings handles this. The simplest approach is to create a routine that triggers when motion is detected, with either a time‑of‑day condition or—ideally—a condition based on ambient light level.
Once that routine is in place, you can disable the automatic‑on behavior by setting parameter 110 to off, since the new routine will take over that function. Everything will still run locally on your Hub.
I don’t want to use hub control for presence detection to then send a command to my lights from the hub. I want the device to directly control the load (non-smart bulb connected to the dimmer) as it is designed to do. Is there no way to dynamically configure paramaters from the hub (like parameter 110) from the hub based on specific conditions? Without this ability you are stuck with the lights turning on based on presence detection regardless of whether it is daytime or nighttime (or whatever conditions you may choose such as “away mode” or anything else). If I wanted to use the hub to control some smart lights based on presence detection I wouldn’t need an integrated dimmer module, just a mmwave presence detection device that notifies the hub which then turns on the lights based on specific conditions.
This doesn’t seem right–you should be able to ignore or disable presence detection at the device programatically (it is a configurable parameter of the device) and not be required to either use a hub or manually switching the sensing mode at sunset and sunrise on a daily basis.
I am only intending to use smartthings to dynamically enable/disable presence detection based on either ambient light conditions or time (or potentially other conditions) because there are no methods/features exposed for the device that allow you to do this.
If the real answer is, “you can’t modify paramaters programatically on the hub” then I’m requesting this feature to be added to the device as an exposed command. I’m surprised this isn’t more common of a concern. Perhaps everyone is using the switch with a hub to define conditions that determine whether the presence detection event turns the lights on, as you suggested. I’ll give this a shot and will see how this goes, but will keep an eye on reliability and responsiveness which are my main concerns….
You certainly can configure parameters dynamically. I do it all the time (changing the local protection value for flood lights to prevent them turning on during the day, or the default brightness when turned on locally depending on time of day). It’s not a matter of the device allowing it or not, it’s a matter of if your hub makes it available. I use Zigbee2MQTT with openHAB, and I can do anything that can be done in the Z2M UI and more from my rules. It sounds like perhaps SmartThings allows you to configure parameters in the UI, but possibly not in automations? I’m not familiar with SmartThings at all to know if that’s a deficiency in SmartThings in general, or in the specific device handler for SmartThings that Inovelli has influence over. But it’s definitely not the switch itself preventing it.
That said, a configuration parameter or two of max and maybe min light level for turning the light on (when presence otherwise detected) so that it can be done 100% on-device seems like a reasonable feature request to me to fill a lot of use cases. I personally have an automation that handles one more level - turn OFF the load when ambient light is VERY bright (sun shining in is much brighter than most indoor artificial light sources).
It is something that has to be changed for the smartthings device driver. I have some GE motion switches that I can change the parameter 110 on using routines but I cant on these. This is a hub specific thing that I too would love to see it available for smartthings. As for making a routine that runs locally that does this, it does work but the response time is noticeably slower than the built in motion load control of the switch.
I agree. Having some ranges for lux that gate the triggering on-device seems reasonable.
I’d honestly love to see more scenarios like this done on device, but I understand how complicated it can get and very quickly so.
Could occupancy be reported as a binding endpoint, allowing the OnOff cluster to be bound to a different Zigbee light?
Ramp up is rather slow at low brightness levels (5%), even with RampRateOffToOnRemote and RampRateOffToOnLocal both set to 0. It can take 2-3 seconds for the light to come on.
At a higher brightness, like 50%, the lights do turn on instantly as expected.
On v1.01 beta Firmware
I also have this problem. But im not sure if its the switch or my bulbs.
Adjust the quick start time parameters. Your bulbs seem to need a little jolt to get started.
Which parameter numbers are those? I can’t seem to find anything with a similar name in the docs.
The documentation seems to be missing… here’s the equivalent on red series: Red Series Dimmer Switch • Parameters | Inovelli Help Center
And the Z2M docs for it Inovelli VZM32-SN control via MQTT | Zigbee2MQTT
I believe param numbers are the same between red series and blue series.
Are parameters 23 and 24 available for the Blue Series? The hubitat driver from Inovelli doesn’t expose them (Inovelli mmWave Dimmer Blue Series VZM32-SN). It would be great if it did! 
We implemented them in Z2M and they appear to be working on one of my switches. Sounds like they may have been missed from Hubitat and the documentation… pinging @EricM_Inovelli
Thanks! And I can confirm that setting parameters 23 and 24 manually (Via the « Set Parameter » command) works on Hubitat. It is just not explicitely exposed on the driver as mentioned above.
I adjusted the QuickStartTime to 5. Was the lowest I could get it where the lights would come on faster, but not flash-bang everyone too badly.
I may still try and tweak more it to try and reduce the flash-bang effect, by playing with the level as well.
I tend to generally find that setting the quick start level to 50 reduces the flash bang effect significantly. Definitely play with the combination of settings.
They don’t appear to be available for ZHA either in the UI. Nor do they appear to be able to be read via zha-toolkit (though that may just go through the same code path and not be available unless it’s in the device handlers—I haven’t double checked how the toolkit reads attrs). They’re certainly missing in the current device-handlers: zhaquirks/inovelli/__init__.py#L1003.
action: zha_toolkit.attr_read
data:
ieee: light.bathroom_light
attribute: 23
endpoint: 1
manf: 4655
cluster: 64561
This results in KeyError: 23.
Full error log for KeyError
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/websocket_api/decorators.py", line 28, in _handle_async_response
await func(hass, connection, msg)
File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 1057, in handle_execute_script
script_result = await script_obj.async_run(
^^^^^^^^^^^^^^^^^^^^^^^^^^^
msg.get("variables"), context=context
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
)
^
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 1865, in async_run
return await asyncio.shield(create_eager_task(run.async_run()))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 467, in async_run
await self._async_step(log_exceptions=False)
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 533, in _async_step
self._handle_exception(
~~~~~~~~~~~~~~~~~~~~~~^
ex, continue_on_error, self._log_exceptions or log_exceptions
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
)
^
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 563, in _handle_exception
raise exception
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 531, in _async_step
await getattr(self, handler)()
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 1018, in _async_step_call_service
response_data = await self._async_run_long_action(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...<9 lines>...
)
^
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 631, in _async_run_long_action
return await long_task
^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/core.py", line 2817, in async_call
response_data = await coro
^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/core.py", line 2860, in _execute_service
return await target(service_call)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/zha_toolkit/__init__.py", line 819, in toolkit_service
raise handler_exception
File "/config/custom_components/zha_toolkit/__init__.py", line 771, in toolkit_service
handler_result = await handler(
^^^^^^^^^^^^^^
...<8 lines>...
)
^
File "/config/custom_components/zha_toolkit/__init__.py", line 906, in command_handler_default
return await default.default(
^^^^^^^^^^^^^^^^^^^^^^
app, listener, ieee, cmd, data, service, params, event_data
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
)
^
File "/config/custom_components/zha_toolkit/default.py", line 51, in default
await handler(app, listener, ieee, cmd, data, service, params, event_data)
File "/config/custom_components/zha_toolkit/zcl_attr.py", line 311, in attr_read
await attr_write(*args, **kwargs)
File "/config/custom_components/zha_toolkit/zcl_attr.py", line 371, in attr_write
result_read = await u.cluster_read_attributes(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...<4 lines>...
)
^
File "/config/custom_components/zha_toolkit/utils.py", line 1208, in cluster_read_attributes
return await cluster.read_attributes(attrs, manufacturer=manufacturer)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.14/site-packages/zigpy/zcl/__init__.py", line 1016, in read_attributes
attr_def = self.find_attribute(attribute, manufacturer_code=manufacturer)
File "/usr/local/lib/python3.14/site-packages/zigpy/zcl/__init__.py", line 548, in find_attribute
all_candidates = cls.find_attributes(
name_or_id, manufacturer_code=manufacturer_code
)
File "/usr/local/lib/python3.14/site-packages/zigpy/zcl/__init__.py", line 499, in find_attributes
candidates = cls._attributes_by_id[name_or_id]
~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^
KeyError: 23
Also of note—parameters 23 & 24 are not available in the list of ZHA entities (so maybe something’s not quite right in the device handlers) for the VZM31-SN, Blue Series Smart Dimmer, a.k.a. Blue 2-1. Perhaps this is a case where I need to remove & re-add the device to get all the entities appearing, but there have certainly been new entities that have appeared during the last firmware update I installed. Also, they are available in the Manage Zigbee Device section for the VZM31-SN while they’re not even present there for the mmWave switches.
ETA: It looks like the following places in the ZHA codebase may need changes to support these attributes:
- The
InovelliConfigEntityClusterHandlershould have these two added for the VZM31-SN and the VSM32-SN like the VZM35-SN. - The
InovelliQuickStartTimelikely needs the VZM31-SN and the VSM32-SN added to the set of models. - It appears that a
InovelliQuickStartLeveldoesn’t even exist.
Quick start time and level were features that were added to the VZM31 after it had already been released via a firmware update, so it’s not super surprising to see that it was missed in a bunch of places.
Aside, ZHA seems to be overhauling how quirks are written fairly frequently which seems to be leaving the Inovelli devices with semi broken features until they get fixed. Hopefully they stop doing that soon.