I am new to HA, using OZW(beta) on Hass.io RPi3+. Looking good so far.
One of my devices (Jasco dimmer 14xxx) works perfectly (liking HA!) but it has an undocumented parameter that I had set in Vera but got unset when I factory reset prior to inclusion through HA.
Now I want to set this single byte parameter #6 to 1. Since it is not in the XML, the service set_configuration_parameter seems unsuitable (though it would have worked in the non-beta OZW 1.4 version which does not use the XML for that).
Can I send a raw message from within HA? Can I send an MQTT message? Can I send a raw message outside of HA? Can I edit the XML without having to remove then include to make it take effect? Anything else?
I realize I COULD switch to non-beta zwave, set it then change back but if I can do that, one would assume I could shut down OZW beta, run some utility to do my write then start up OZW again to keep my HA system clean.
You’ll either have to edit the XML file and add the parameter, or use another software. The PC Controller software would be an alternative to using OZW 1.4.
If you edit the XML file you just need to refresh the node info, either in ozw-admin or via MQTT.
@freshcoast I could use a bit of help for the editing. Given that I am running a 114.4 RPi image (confusing names but I think it is called Home Assistant and used to be called HassOS with Hass.io?) and I have installed the official Terminal and SSH, where do I find the XML?
Once I edit the XML, I can easily refresh from ozw-admin. Not a clue how to do it from MQTT. At that point, I assume the new parameter will appear in ozw-admin?
Unfortunately with the addon it’s quite difficult to access and modify the config files. There is an open issue to help with that, but for now I don’t have any helpful advice as I’m not an addon user. The other alternative is to run the standalone container, using the Portainer addon, which would give you easy access to the files.
What dimmer do you have and what is this undocumented parameter? I have some 14294 dimmers and a 14292 switch.
Yes, I heard that. I figure it is not impossible and I would like to try to find it.
The switch is a 14294 and there are a few undocumented params that interest me.
Most importantly is parameter 6 (fw >=5.26) a single byte which enables ramp when switching between intermediate intensities (i.e. not switching off or on). When set to 1 (or with older firmware) it will ramp. When set to 0 (default) it will instantly change
Another interesting parameter is 16 (tested on fw5.26) a single byte which enables switch mode (as opposed to dimmer mode). When set to 1 it operates as an on/off switch. When set to 0 (default) it is a dimmer. Useful if you have some dimmers and some non-dimmers and you don’t want two different parts (which are the same price anyway!).
One more parameter is 20 (tested on fw5.26) size 1 byte I think which sets the minimum dim level (i.e. a low cutoff for dimming). Value is 0-99. Default is 99. Note I saw one posting that said that this parameter moved from 20 to 30 in some f/w. Parameter can be toggled manually by tapping the top 5 times followed by the bottom 5 times then the led will blink.
All the parameters you’ve listed are documented for the latest version of the 14294. In that case parameter 30 is the min dim threshold. Are you saying the older versions of these switches support the same parameters?
I have the 0x4944/0x3038 version with fw 5.26. I can try those parameters if you think they will work.
Hmm. Never thought to look at a newer z-wavealliance sheet. Note that the newer product is missing a lot of the parameters of the older product.
And that is the one I was referring to, including the fw. I know for a fact that option 6 works as I strongly prefer that. I’m almost certain option 16 works (though the only place it really matters is powering an outlet that isn’t a light (radio?) but I haven’t tried it in a couple of years. Option 20 I’ve only heard about. Never tried.
OK, I confirmed all parameters, 6, 16 and 20 worked on my 14294. I’ll update the XML.
I have to ask about parameter 6 though. There are also params 7 and 8, On/Off Command Dim Step and Dim Rate, which let you set the ramp rate for Z-Wave commands. Do those only apply to the On and Off commands, and not the intermediate levels? I did notice that with param 6 set to 0, if I set a brightness that was in-between 1 and 99 it was immediate, but I have always been thinking that the Dim Step/Rate parameter was influencing this.
Excellent. I will gladly take a copy of that XML 'cause that’s what started this thread! Hope it was of use to you.
Yeah. Jasco’s docs are really poorly worded. I found a longwinded explanation written by them that explains param 6 in great detail! Please look here. I’ve figured out parameters 6-12 inclusive. There is extensive misunderstanding of these but when you figure out their wording, they are correctly documented. Specifically 7, 9 and 11 are the step size and 8, 10 and 12 are the step period in tens of ms.
Specifically, when 6 is 0, it is always instant if set through z-wave. Note that as I recall, it is only when it is being set from non-zero to non-zero brightness, i.e. when adjusting brightness, not when turning on or off.
Excellent news. I figured out how to ssh into the environment that launches all the docker containers. Trick there is:
Use the community SSH & Web Terminal, not the official Terminal & SSH.
From the terminal shell, type docker ps -a to see all the dockers and make note of the containerID of the OZW container.
type docker exec -it /bin/bash
You’re now in an OZW shell. Type cd /data/ozw/config and you are in the directory that contains all the vendors’ folders each of which has their xml files!
Use vi to edit the files.
Warning, I would not count on the xml files surviving a reboot but I just need it briefly to change a parameter permanently right now.
Definitely far from plug’n play but I’m liking HA so far (3wks). Performance very good. Stability good. Many good features most of which are yet to be configured (presence, notifications etc.) but I already did Alexa WITHOUT cloud NOT on port 443 WITH send events! Lots to go …
I submitted a PR to update the XML file. When it’s eventually merged you should be able to trigger a download in ozwdaemon to get it, but that may be awhile, so you can just download it manually and put it in the config directory.
After downloading the new version, you will need to issue a refresh node info command, either in ozw-admin (right click on a node) or via MQTT, or use the 0.115 beta which has a minimal control panel in HA. After refreshing the node info the new config parameters will become available.
Be aware that dimmer switches in general have inconsistent behavior right now due this issue. If you want to disable the refresh value behavior that causes the trouble, you can modify this line and set VerifyChanged to false. In that case, you may need to manually refresh the value to keep HA’s state in sync.
Warning, I would not count on the xml files surviving a reboot but I just need it briefly to change a parameter permanently right now.
They should survive, the path is supposed to be a persistent volume.