Powered devices are more stable than battery powered and since they don’t go to sleep, they are easier to get connected. To start inclusion, use the HA zwave menus to add devices (either regular or secure-add). Don’t remove the zwave stick and use its button to do the inclusion.
dap35, thanks that’s what I was doing. So in addition to what I mentioned take the Aeotec Water Sensor 6. Have some other unanswered threads on this so won’t get into it to much, but it’s in a dock and usb wired to the wall. That said it’s still sleeping all the time. And even though the documentation says to press the action button for 3 seconds and it will be active for 10 minutes, that’s not the case. I can tell this because when thru the GUI I try to change settings they do not take. I have to keep hitting the active button as I apply the settings and eventually it takes. Lot of retries.
Then some devices like this one again I see it trigger with water but buzzer never works. And I have about 12 different entities at this point though backed out of my install with a backup to start over.
Then this device has groups and other things but no way to understand how any of it really works.
EDIT: This time around I added custom_config and downloaded OpenZWave from github and pointed to it’s config folder to make sure to get the latest definitions.
I suspect that even though the water sensor is usb powered, it acts like a battery powered device (or a cat) and sleeps a lot. Also I don’t believe it will act as a zwave repeater.
Before I moved to Hassio, I had a couple of GE devices where I replaced the relevant xml files prior to adding more devices. For existing devices, I backed up the zwcfg file and carefully modified the entries for the few existing devices which were missing some of the options. This was on a much earlier version, so I don’t know if that would work anymore.
Yeah they kind of do. Actually really responsive but their responses are cryptic and not always super helpful. I think they would say you need to get support from the smart hub you are using rather than them. Like in HA for Aeotec. There is an entity and over time numerous entities called sourcenodeid. From my research it only shows up in HA. Aeotec says it’s not anything they are familiar with. Looking at OpenHAB and SmartThings they do not get this entity but within HA it’s there but no one really ever identifies what it is.
EDIT: So here is a fresh wipe and redo of Z-Wave for the Aeotec Water Sensor 6. This is what I get for entities:
I endorse what dap35 said.
I have (according to my template sensor) 33 z-wave nodes
And yes some of them disappear, mainly sleep or caching or dead as the last are configured but not finally installed yet. (edit: Dead ones can be resurrected if locally switched (not remotely) close to the hub)
Be VERY patient with battery devices, they will talk when they have something to say, doing things to them sometimes screws them up and at best wastes battery.
But as dap35 said the powered ones act a repeaters widening and strengthening the mesh network they form (but you probably know all this, so I’m also writing it for the next guy with similar issues) but they will only make 4 hops, they will preferentially talk to the hub rather than another node (so nodes on the periphery of the hub) sometimes get the shi77y end of the stick in that they refuse to talk to a ‘good’ intermediary. (I’ve sometimes had to bend the antenna in half and wrap in tin foil to ‘make’ it talk to a neighbour (not generally recommended) oh by the way secure mode takes 4 message blocks per instruction rather than 1 for non secure (don’t use secure unless you must, my network will soon be rebuilt with no secure inclusions (it really slows your network down)) locks require secure but I don’t like the idea of electronic locks.
Adding a node is always an anxious time and yes it sometimes goes wrong. If so exclude reset and reinclude it. It will skip a number but as long as the node is declared dead you can ‘remove’ it after a few weeks, the manager gets to the end of the number range (233 or 254 I can never remember) it loops back looking for empty slots
Each node always seems to load baggage the SourceNodeID is a classic, but there are others, I have switches with two voltage readings, one called heat the other called management (go figure) I generally just name these (uniquely) after the node and then stick a "Null " at the beginning of the friendly name, then just don’t display it.
Z-wave is far more reliable and predictable than some others eg tradfri
Home automation is supposed to be fun and interesting, if it isn’t for you, then rip it out.
Good luck with whatever you do
Burglar is the tamper (vibration) sensor in the unit.
The alarm levels and alarm types are part of the burglar sensor, the different types and level combos tell you what’s going on, if you don’t care about this suite of sensors, ignore them.
Ignore the sourcenodid stuff, the heat sensor from the tech docs says it’s an overheat/underheat alarm for the device.
firstof9, thanks for those details. Any thoughts on why I have three of everything? Should I assume each alarm type and level tie to either burglar, flood, or heat but have to figure out which is which by triggering them? Also that link you sent went to some xml that showed denied or expired.
Thanks. That’s what my brain was starting to conclude with the three sensors for each. Oddly the first two times I linked this device it didn’t have three of them but what you gonna do.
For Mutt, appreciate your thoughts. I want this to be fun. Have the stupid challenges of family and fitting this in during the half hour a week you can find to do it and family constantly bothering you while you are working on it. So sometimes hope others have a few to share their knowledge. Ugh!!! I know I’m documenting everything I’m doing with my home setup so hope to share the details soon.
By the way, was looking at some custom code from smartthings. Is that wrong?
if (cmd.scaledConfigurationValue == 1) {
event << createEvent(name: "probe", value: "1", displayed: true, isStateChange: true, descriptionText: "${device.displayName} detected water on probe 1.");
} else if (cmd.scaledConfigurationValue == 2) {
event << createEvent(name: "probe", value: "2", displayed: true, isStateChange: true, descriptionText: "${device.displayName} detected water on probe 2.");
} else if (cmd.scaledConfigurationValue == 3) {
event << createEvent(name: "probe", value: "3", displayed: true, isStateChange: true, descriptionText: "${device.displayName} detected water on both probes.");
This looks like the first sensor would be one of the leads, the second the second lead, and if they both go off the third will trigger. I was originally thinking the first was the unit itself and 2 and 3 were the external leads from the dock.
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.
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.
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.
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.
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)
