Hi there, I’m new to HA, come from Z-Wave.me.
Successfully installed HA on a Py4 with a Razberry addon card, and zwave_js. Works fine!
Have started integrating devices and automations.
I also tried HACS to add a better looking multi entities for switch and lights.
For custom automation, I need to send specific values to dimm the light as wanted.
I’m struggling with a (multilevel?) switch: Everspring AD147 (dimmable light switch).
I checked on the forum: There are some posts with Everspring AD147, but doesn’t match my problem.
The device is perfectly recognized by HA => I’m able to play with it in dashboard with the standard “light card” => on/off + slider.
The standard automation propose to send value, but the slider is sticked to 255.
I tried with YAML, same.
I tried by using “service” rather than the GUI embedded actions => z-wave.set_config_parameter, z-wave.set_value, etc.
Each time, the log says it’s not possible to send other value than 255???
Error while executing automation …: Node(node_id=31) - InvalidNewValue: Must provide a value within the target range (Min: 255, Max: 255)
Documentation from the manufacturer says it’s possible to send values from 0x00 to 0x63 (dimming) AND 0xFF (full light straigth), but not just 0xFF.
When I change dimming through the standard light card, Zwave API is able to send these values:
Node 031 REQ SendData
transmit options: 0x25
callback id: 173
MultilevelSwitchCCSet
target value: 59
duration: default
You typically control lights with the light integration services, which is what the light card is doing, e.g. light.turn_on with brightness or brightness_pct attributes. There’s no need to use low-level Z-Wave services (like zwave_js.set_value), unless there’s something non-standard with the device, or a feature not supported natively by HA.
You typically control lights with the light integration services … There’s no need to use low-level Z-Wave services
That’s what I thought I was doing! And that’s why I specified: The standard automation propose to send value, but the slider is sticked to 255
But for the newbie that I am, it’s also a little bit counterintuitive to use “service” for lighting!
I thought the most direct route for “action” was “device”, not “service”.
Now than I understand that there are “standard” services with a lot of functionalities, that superseed the options of the device itself, it’s pretty obvious!
I tried service light.turn_on : works like a charm!
Thanx a lot.
Thanks for the screenshot, always better with an image!
Again: Now that you show me that, make sense!
Mmh… Think I got a programmer bias here!
I wouldn’t have thought to use “turn on” to set brightness!
I would send “turn on” or “turn off” for obvious actions and, separately, I would send the value for brightness.
With your previous response, I managed to set a progressive dim lighting based on sun elevation.
I will check the behavior with the “turn on + brightness” action!
Thanks a lot for clarifying the paths we can take to achieve an action!
Regards
May be I’m doing something wrong (again!), but when using action device turn.on brightness, it doesn’t allow to place a formula:
action:
- type: turn_on
device_id: 491d02d14fe063cd53419de52385974e
entity_id: light.swdimmer01
domain: light
# brightness_pct: OK 44.44
# brightness_pct: KO "{{ (300-50*state_attr('sun.sun', 'elevation')/9)|round(1) }}"
# brightness_pct: KO "{{ state_attr('sun.sun', 'elevation') }}"
Gives an error message: Message malformed: expected float for dictionary value @ data[‘brightness_pct’]
Even with casting the formula with |float, it’s considered an error.
And that’s why I specified: The standard automation propose to send value, but the slider is sticked to 255
