Are you certain that your LEDs support dimming?
yes, they have been working on a clipsal rotary dimmer. Thats why i thought maybe a config issue, but im not sure what to change.
I am having problems with my Hassio installation after upgrading so can’t see my configuration, but there is a parameter you can adjust in the z wave settings regarding minimum and maximum dimming. If they are set to be equal your LED will not dim. As I recall it is parameter 131 and 132 or something in that range.
I seem to be having the same problem. I’ve installed a Z-Stick Gen5 + Aeotec ZW111 Nano Dimmer.
It turns on and off, but the dimmer doesn’t seem to work. Just using the dimmer slider.
Hi,
I also try to achieve dimming with Aeotec Nano Dimmer. I suppose that it’s not correct to use brightness for light.aeotec_zw111_nano_dimmer_level object since it looks like it does not have such attribute. In my case I see the following information:
value_instance: 1
power_consumption: 0
friendly_name: Aeotec ZW111 Nano Dimmer Level
node_id: 5
value_id: 72057594126630913
value_index: 0
supported_features: 33
The light.aeotec_zw111_nano_dimmer_level object has off/on states that are shown in GUI.
Thus, I really guess what other objects can be used for dimming. Perhaps we should change somehow the 0x84(132) parameter - Max brightness, before switching on.
Any examples are appreciated (may be from alternative platforms like OpenHub, MySensors, etc).
I’m going to play with approach described in alternative message of community :
- alias: Set Doorbell Volume to 1
trigger:
- platform: state
entity_id: input_select.doorbell_volume
to: '1 - Quietest'
action:
service: zwave.set_config_parameter
data_template: {
"node_id": 20,
"parameter": 8,
"value": 1
}
- alias: Set Doorbell Volume to 2
trigger:
- platform: state
entity_id: input_select.doorbell_volume
to: '2'
action:
service: zwave.set_config_parameter
data_template: {
"node_id": 20,
"parameter": 8,
"value": 2
}FYI, since you’re not actually using a template you can use data instead of data_template. Also, you can just use normal (well, more typical) YAML syntax. (I use this service in some of my scripts, but to change the on/off ramp times for dimmers.)
service: zwave.set_config_parameter
data:
node_id: 20
parameter: 8
value: 1
Unfortunately I do use data_template since I planned to use the value of input_number (as one of possible scenarios).
input_number:
corridor_brightness:
name: Brightness
initial: 20
min: 0
max: 99
step: 1
icon: mdi:brightness-6
But I don’t understand yet how to transfer the value of brightness within JSON parameters.
My test automation rule generates error.
- alias: Corridor - Adjust Brightness
trigger:
platform: state
entity_id: input_number.corridor_brightness
action:
- service: zwave.set_config_parameter
data_template: {
"node_id": 5,
"parameter": 132,
"value": states.input_number.corridor_brightness.state|int
}
The error I’ve got is - ValueError: invalid literal for int() with base 10: ‘states.input_number.corridor_brightness.state|int’
I guess what syntax should be used. Perhaps different approach will do the trick?
I saw in one post that particular value can be saved in predefined file and changed programmatically while automation rule just read that value.
- service: zwave.set_config_parameter
data_template:
node_id: 5
parameter: 132
value: "{{ states('input_number.corridor_brightness') }}"
If that doesn’t work, not sure.
@hellad, I checked the code (components/zwave/__init__.py), and this should work because a number, even as a string (which the output of templates always are), will work because the string number will get converted to an integer for value:.
The syntax you suggested generates following error log in my system:
Aug 06 21:59:43 hassbian hass[2004]: 2018-08-06 21:59:43 INFO (MainThread) [homeassistant.helpers.script] Script Corridor - Adjust Brightness: Running script
Aug 06 21:59:43 hassbian hass[2004]: 2018-08-06 21:59:43 INFO (MainThread) [homeassistant.helpers.script] Script Corridor - Adjust Brightness: Executing step call service
Aug 06 21:59:43 hassbian hass[2004]: 2018-08-06 21:59:43 ERROR (MainThread) [homeassistant.core] Error executing service
Aug 06 21:59:43 hassbian hass[2004]: Traceback (most recent call last):
Aug 06 21:59:43 hassbian hass[2004]: File “/srv/homeassistant/lib/python3.5/site-packages/homeassistant/core.py”, line 1046, in _event_to_service_call
Aug 06 21:59:43 hassbian hass[2004]: await self._hass.async_add_job(execute_service)
Aug 06 21:59:43 hassbian hass[2004]: File “/usr/lib/python3.5/asyncio/futures.py”, line 380, in iter
Aug 06 21:59:43 hassbian hass[2004]: yield self # This tells Task to wait for completion.
Aug 06 21:59:43 hassbian hass[2004]: File “/usr/lib/python3.5/asyncio/tasks.py”, line 304, in _wakeup
Aug 06 21:59:43 hassbian hass[2004]: future.result()
Aug 06 21:59:43 hassbian hass[2004]: File “/usr/lib/python3.5/asyncio/futures.py”, line 293, in result
Aug 06 21:59:43 hassbian hass[2004]: raise self._exception
Aug 06 21:59:43 hassbian hass[2004]: File “/usr/lib/python3.5/concurrent/futures/thread.py”, line 55, in run
Aug 06 21:59:43 hassbian hass[2004]: result = self.fn(*self.args, **self.kwargs)
Aug 06 21:59:43 hassbian hass[2004]: File “/srv/homeassistant/lib/python3.5/site-packages/homeassistant/core.py”, line 1043, in execute_service
Aug 06 21:59:43 hassbian hass[2004]: service_handler.func(service_call)
Aug 06 21:59:43 hassbian hass[2004]: File “/srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/zwave/init.py”, line 485, in set_config_parameter
Aug 06 21:59:43 hassbian hass[2004]: value.data = int(selection)
Aug 06 21:59:43 hassbian hass[2004]: ValueError: invalid literal for int() with base 10: ‘37.0’
Aug 06 21:59:53 hassbian hass[2004]: 2018-08-06 21:59:53 INFO (MainThread) [homeassistant.helpers.script] Script Corridor - Adjust Brightness: Executing step call service
Aug 06 21:59:53 hassbian hass[2004]: 2018-08-06 21:59:53 INFO (MainThread) [homeassistant.helpers.script] Script Corridor - Adjust Brightness: Executing step call service
Aug 06 21:59:53 hassbian hass[2004]: 2018-08-06 21:59:53 ERROR (MainThread) [homeassistant.helpers.service] Error rendering data template: UndefinedError: ‘input_number’ is undefined
It looks like string value with .0 at the end is not converted (or interpreted) to integer and syntax must be changed.
By the way thank you for your time and assistance.
I've changed automation rule as follow:
- alias: Corridor - Adjust Brightness
trigger:
platform: state
entity_id: input_number.corridor_brightness
action:
- service: zwave.set_config_parameter
data_template:
node_id: 5
parameter: 132 #### set maximum brightness to selected value.(0-99)
value: "{{ states('input_number.corridor_brightness') | int }}"
and it started to work from GUI!
But I don’t realized yet why error message remains in log:
Aug 06 22:07:36 hassbian hass[30908]: 2018-08-06 22:07:36 INFO (MainThread) [homeassistant.helpers.script] Script Corridor - Adjust Brightness: Running script
Aug 06 22:07:36 hassbian hass[30908]: 2018-08-06 22:07:36 INFO (MainThread) [homeassistant.helpers.script] Script Corridor - Adjust Brightness: Executing step call service
Aug 06 22:07:36 hassbian hass[30908]: 2018-08-06 22:07:36 INFO (Thread-12) [homeassistant.components.zwave] Setting config parameter 132 on Node 5 with selection 16
Aug 06 22:07:36 hassbian hass[30908]: 2018-08-06 22:07:36 INFO (MainThread) [homeassistant.helpers.script] Script Corridor - Adjust Brightness: Executing step call service
Aug 06 22:07:36 hassbian hass[30908]: 2018-08-06 22:07:36 INFO (MainThread) [homeassistant.helpers.script] Script Corridor - Adjust Brightness: Executing step call service
Aug 06 22:07:36 hassbian hass[30908]: 2018-08-06 22:07:36 ERROR (MainThread) [homeassistant.helpers.service] Error rendering data template: UndefinedError: ‘input_number’ is undefined
Yes, as you found, you have to add the filter to convert to an int. Apparently the Jinja int filter first converts to float and then converts to int, whereas Python doesn’t do that. What’s happening is, the schema for the value parameter first attempts to coerce to an int. But ‘37.0’ can’t be directly converted to an int. The schema then also allows a string for this parameter, so it stays a string. Then, when it gets to the zwave code, it tries to convert to an int, and that fails. Long story, but yes, you do need the int filter in the template, as you found. Sorry, I probably should have realized that earlier.
This is indeed strange. What I also find strange is the log seems to imply the “script” “Corridor - Adjust Brightness” has multiple service calls, yet in the code you showed, there’s only one service call. Is there more to this automation than you’re showing?
If you look more closely at the log, the first service call - which results in the zwave component setting the config parameter - seems to work. So is it some other service call that is failing?
BTW, I say “script”, because basically the action part of an automation is effectively a script, so it’s executed by the same code that runs a “real” script. (At least I’ve concluded that based on observation.)
@hellad have you tried sending a lower number manually to parameter 132 to see if it actually does dim the lights, to verify if this method will be effective or not?
I will try that myself when I get home later today.
cheers
Dumb question, the native gui on Home Assistant where there’s a slider for the dimmer is not enough to set the dimmer/brightness of the device, I need to add extra code/customization?
Not a dumb question… Any way you can actually get the lights to dim, please let me know. That was actually the original point of the post, got lost a little along the way…
I might test it on an install of Axial Control that I have just to ensure all is working with the hardware. I have a VM with passthrough using Aeotec Z-Stick S2 and Aeotec Dual Switch. I have been running this for many years and have never had any issues.
I wanted to consolidate so I thought I’d refresh to Z-Stick Gen5 and as I’ve never had a dimmer I thought I’d buy one to test with Hass. Sets up fine, turning on using Hass is quick. Switching off is delayed by a few seconds from turning it off from Hass gui to the light actually switching off and dimmer functionality isn’t working. If all is good with Axial Control maybe I’ll use that as a dedicated Z-wave controller than using Hass/OpenZwave and maybe bridge them somehow.
I wouldn’t be surprised if it worked, I have a similar issue with an aoetec climate aircon it controller, won’t turn the aircon off using hass, but I tested it on a Vera and it worked perfectly. Tried asking the forum for help on that one and got nothing.
I’m guessing will be the same with this dimmer.
I’m starting to think it might be the z-stick…
The problem is almost certainly with the Z-Wave library, OpenZWave, not supporting the device correctly. In theory any standards compliant Z-Wave Plus device will “just work”, but it’s entirely possible that there’s a bug in OZW, or support for this type of device isn’t complete.