You need to use the 1.4 branch of OZW. What you’ve downloaded here is the 1.6 version, and the config files are not compatible with HA. This might cause problems adding devices later.
I agree with fresh, BUT I would say WILL rather than might
Wait till ozw 1.6 (then wait a bit for the experts to iron out the kinks) and then full steam ahead.
I’ve been informed that though ozw 1.6 will run in its own docker there will be a transition path so that it should be virtually seemless, though we ‘may’ have to adopt a slightly different instruction format (I dunno but wait and see)
I think the built in Zwave code which is based on/forked OZW is pretty solid. It’s been a couple of years since I needed to tweak any of the xml definition files outside of what was delivered from HA.
Outside of getting devices added, I wouldn’t worry about devices sleeping. If you have network stability issues, then make sure you have some powered devices as a part of the zwave mesh. There is some a zwave graph2 using java script that one of the forum users posted that I think is helpful. )( Z-Wave graph (without the python))
So what is the concensus then? Switch to open z-wave 1.4 or remove the config_path variable completely from zwave under configuration.yaml? I noticed that the zw122 device was updated a year ago with 1.4 and six months ago with 1.6. Not sure what HA has internally. Just saw some videos that said it’s usually a bit behind on newer devices.
If I do go back to 1.4 or remove it completely what is the recommendation? Revert my VM? Remove and add the device again? Things should just keep working no matter what I change?
By the way, my graph just shows the below with no linkages to the stick.
My 2 cents worth of feedback…I started a couple of years ago with HA’s ZWave, and concluded that device support was adequate, but would not be as good as a commercial device. So I jumped onto SmartThings, and am happy with its device support. However have found that the “bridge” (whether MQTT or HA’s ST Integration) to communicate with HA is somewhat of an issue: Motion detection fires to turn on a light takes way too many seconds going to the cloud and back…a physical device with multiple instances doesn’t get exposed across the “bridge”. So recently I moved over to ZWave2MQTT and use OpenZWave version 1.6. Its a bit of work to get going (in my case, but Hassio has easy add on capability), but device support is much better than it was a couple of years ago, and I feel a bit more in control with its GUI, and logging/MQTT messaging.
I hope to try out the Aeotec water sensors in the not too distance future, so thanks for your feedback on this.
Review line 1 of your OZW_Log.txt it will likely say: OpenZwave Version 1.4.3440 Starting Up
No
No
You should be fine as is currently, you can however remove the config_path entry in your config.
I do see that in my OZW_Log.txt. Does that mean I’m not using what I setup since I was told I downloaded 1.6 which I would think is true? I know if I put a bad path to the config folder things error. Just wondering if your comment that I can just remove the config from my setup would elude to that I’m not using it anyway.
Thanks.
JR
Correct.
Home Assistant uses python-openzwave which uses Openzwave C++ libraries, but it’s using 1.4 not the 1.6 version since python-openzwave is still working on updating to 1.6
Couple things. So what is me pointing to that folder doing just ignoring it? The logs don’t complain.
Also some weirdness.
I setup the WZ122 and stuck one of the leads in water.
Started beaping and got
:23 PM
[Basement Water Sensor – Flood Water Heater changed to 2
[Basement Water Sensor – Flood Water Heater Source Node changed to 0
[Basement Water Sensor – Flood Water Heater Alarm Level changed to 0
[Basement Water Sensor – Flood Water Heater Alarm Type changed to 0
Here’s the thing though. When I dried out the lead and looked at the logbook the SAME entry the 2 had changed to 0. It didn’t create a new entry, changed the existing one.
Also after I started renaming my entities name and IDs the buzzer stopped going off. It does still flash and report in, but no sound.
ALSO, both of the sensors report on the same above and putting both sensors into the water at the same time still report against the one sensor. The other two sensors never do anything.
Now if I have to somehow programatically tell each sensor where to report to or something not sure.
EDIT: Note this is something I got from Aeotec, just not sure how to execute it:
1. Assign Node 1 (your controller) to Group #3 and Group #4 which Group 3 will report Leak Probe 1 and group 4 will report Leak Probe 2.
Alternatively, you can tie 2 switches instead, one to Group #3 and one to Group #4 which will turn on and off depending on the state of Probe 1 and Probe 2.
2. Use Parameter 136 value to determine which probes are triggered and which are not. These would be the values
Parameter 136 (1 Byte) - GET only command
Value = 0 - no probes wet
Value = 1 - Probe 1 wet
Value = 2 - Probe 2 wet
Value = 3 - Probe 1 + 2 wet
These are 2 of the methods you can make use of the 2 external sensors
.
JR
Yes it’s silently failing it.
I never look at the logbook, I look at the states tab in the developer tools.
They want you to change this in your settings to add group 3 and 4.
Select your device from the node list then scroll down to this:
Thanks. I’ll try setting this. In my case guessing this is accurate:
Besides trying to figure out how to get the buzzer to use different flood sensors for each lead, trying to figure out if parameter 10 is maybe cause for the buzzer not going physically off when wet.
The field is otherwise known as “Alarm time for the buzzer” and has a default value of 1968650 whatever that is. Trying to understand what these settings mean and how to configure it.
What does the node config options say for parameter 10 in Home Assistant?
It says: 1968650. Got up this morning and still no sound when I dip a sensor in water. The one sensor does still change to 2. Only saw it go off once.
Also not sure what those groupings Aeotec said to set did. I do not see any difference in the way it triggers or that it ever uses the other two flood sensors. They say you can use parameter 136 to see which sensor is wet but not sure how you manually access get parameters in sensors or actions.
2. Use Parameter 136 value to determine which probes are triggered and which are not. These would be the values
Parameter 136 (1 Byte) - GET only command
Value = 0 - no probes wet
Value = 1 - Probe 1 wet
Value = 2 - Probe 2 wet
Value = 3 - Probe 1 + 2 wet
That’s the default: 0x001E0A0A (1968650) converted to decimal.
So based on what the defaults are, 10 cycles for "Repeated cycle of buzzer alarm, 10 cycles "the time of buzzer keeping on state, and 30 (seconds?) of the time of buzzer keeping off state.
Breaking that down is:
0x001E0A0A Repeated cycle of buzzer
0x001E0A0A time of buzzer keeping on
0x001E0A0A the time of buzzer keeping off state
Might want to as Aeotec about what the descriptions actually mean.
Thanks for the translation I get it now so appreciated. I also posted additional comments on my last response at the same time so not sure if it got flagged to people as new/updated. I will ask Aeotec for more details when they are working Monday but I’m starting to question if this unit isn’t broke as what you posted doesn’t seem to elude to any extended time it wouldn’t buzz. Not sure how much the response of the device is tied to HA, but wouldn’t think renaming the entity ID would cause this.
ya that wouldn’t freak out the sensor and cause issues.
HA doesn’t monitor the parameters like that, as far as I know, I’m thinking maybe the alarm type and such might changed based on triggered status.
Best I’ve been able to do is the “main” sensor for Flood goes from a 254 to a 2 when in water. Then when I dry it off it goes to 0 and eventually becomes 254 again. Either of the two water sensors attached report to the same entity in HA. Not sure if this means anything as I’ve only added this device one time
So it has a 2 and 3.
if I click on the (2) I get:
Which is interesting because not all the sensors are the _2 sensors.
And if I click on (3)
it’s a mix of _2 and _3 sensors.
What’s also odd the SourceModeID, Alarm Level, and Alarm Type are all already set to 0 across the board and when you trigger just the one shows it triggers but still says triggered to 0 which is weird.
And here is what triggers when both are in the water. Keep in mind the 0’s were already 0’s.
You could try going into the entity and either delete or disable it. 
Hard to say could also be an issue with openzwave 1.4 not liking multi-level devices like this currently too.
They are working on a better way to get HA integrated with OpenZwave 1.6 but we’re a bit off on that for now.
So here’s a question. Is there any solid way to identify what entities are available for any given device? Should all home automation solutions see the same entities? So is there actually three flood sensor entities for the Aeotec device for example? I just sent a summary of all our conversations this weekend to Aeotec. Chris there seems pretty smart but the answers are never specific to Home Assistant. Like their comment to use parameter 136 to tell what is triggering but apparently we can’t use it directly.
EDIT: Also if you delete it will it come back automatically either on it’s own or when doing a heal command?
Hard to say this device doesn’t work like their other sensors where you can set the reporting to a binary on/off like their Multisensor’s motion sensor.
Maybe @Fishwaldo (the openzwave guru) can help out?