This looks like how i described as flood being probe 1 (or both together) flood_2 being probe 2, and flood_3 being both (or probe 1).
Likely _3 is for both based on what you posted from SmartThings.
This looks like how i described as flood being probe 1 (or both together) flood_2 being probe 2, and flood_3 being both (or probe 1).
Likely _3 is for both based on what you posted from SmartThings.
I’m not a Z-Wave expert (there are plenty here so hopefully they chime in) but I had an issue very similar to this when I was first setting up Z-Wave. I had tried to add a couple z-wave devices in more than once and I ended up with duplicate entities like you have here.
This issue was there was already entry (or two or three) in the zwave config xml file for that device so HA just added the “_2” and “_3” to the entity names every time I tried to add the device again. BTW there was no problem with the zwave, I was just dumb.
I ended up being able to resolve the issue by going back and carefully removing all the related entries in the xml file, restarting HA, the re-adding the device. The duplicate “_2”, “_3” entities were not created. I’ve seen it noted that you’re not supposed to manually edit the XML file but it worked for me so there’s that. If you’ve only got the one device set up maybe it would be better to just restart with a fresh zwave config and make sure the device is only added once.
I think you could verify if this is your issue by checking the XML file and seeing if your “duplicate” sensors all have the same nodeID. If they do then this is probably not your issue.
Thanks Jason. Probably not my situation here but guess could be. I say that because I am running HA on a virtual machine. When I had the issues, I reset the Aeotec stick and the Aeotec water sensor. Also reverted my virtual to pre Z-Wave setup and started over. Readded the stick and the xml had like 10 lines in it related to the stick. Then I linked the water sensor. That’s what came up. So thinking in the end based on conversations here, that’s probably what should be there. Though to be honest last time I added it there was 1 of some of these sensors and some had 2 and then others with 1 became 2.
Also just noticed this sensor as well binary_sensor.aeon_labs_zw122_water_sensor_6_sensor. Wondering if this is a general status of the device or what. Right now reports OFF. Not sure what “OFF” signifies.
JR
That is kinda weird. Well FWIW my z-wave is rock solid now so don’t give up! Hopefully once HA is using Open Z-Wave a lot of the z-wave issues will be resolved.
Thanks so would I be considered using Open Z-Wave?
On this second try with setting up Z-Wave on HA I created a openzwave_config folder and in it ran
git clone --depth=1 https://github.com/OpenZWave/open-zwave.git
Then in my configuration.yaml added a config_path pointer to the config folder that the above git created.
That is probably the actual water sensor! On = Wet, Off = Dry
I have an Aeotec multi sensor that has a numerical “alarm_value” sensor that report a value with motion but I use the associated binary sensor is actually used for the motion events in HA. If I recall correctly I had to go into the z wave configuration and enable the binary sensor reporting. Maybe your device has something similar? Here’s a recent thread about it.
I’ve never used anything but the internal Z-Wave implementation. Home Assistant is going to be replacing its internal ZWave integration with OpenZWave sometime in the near future. I don’t think you’re going to have to install it separately.
What I’ve come up with so far:
Open up the sensor.aeon_labs_zw122_water_sensor_6_burgular and rename:
Name: Basement Water Sensor – Tamper
Entity ID: sensor.water_sensor_basement_tamper
Open up the sensor.aeon_labs_zw122_water_sensor_6_battery_level and rename:
Name: Basement Water Sensor – Battery Level
Entity ID: sensor.water_sensor_basement_battery_level
Open up the sensor.aeon_labs_zw122_water_sensor_6_temperature and rename:
Name: Basement Water Sensor – Temp
Entity ID: sensor.water_sensor_basement_temp
Open up the sensor.aeon_labs_zw122_water_sensor_6_flood and rename:
Name: Basement Water Sensor – Flood Sub Pump
Entity ID: sensor.water_sensor_basement_flood_sub_pump
Open up the sensor.aeon_labs_zw122_water_sensor_6_flood_2 and rename:
Name: Basement Water Sensor – Flood Water Heater
Entity ID: sensor.water_sensor_basement_flood_water_heater
Open up the sensor.aeon_labs_zw122_water_sensor_6_flood_3 and rename:
Name: Basement Water Sensor – Flood All
Entity ID: sensor.water_sensor_basement_flood_all
Open up the sensor.aeon_labs_zw122_water_sensor_6_heat and rename:
Name: Basement Water Sensor – Over Heat
Entity ID: sensor.water_sensor_basement_over_heat
Assuming those are right. Tomorrow when I have a few minutes will run some tests to check. Still have:
binary_sensor: Will see what it does when I test. Right now showing like it’s an update sensor.
sourcenodid’s: I am going to ignore these unless testing shows something gets triggered on them. Wish I could hide these but the hide entity checkbox doesn’t seem to do anything.
alarm_type: 3 of them. Not sure what they are visually signifying or what to name each at this point.
alarm_level: 3 of them again. Same question as alarm_type
Of course in the end I think my unit is the quiet type as I am yet to be able to get the alarm to sound and “buzzer” is set to Enabled on the device.
JR
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?