I recently purchased an Aeotec Door/Window Sensor 7 (model# ZWA008) and added it to my Z-Wave network. After experimenting with it a bit and running into some issues, I have a question I probably should have checked before I bought it – is this sensor (which is relatively new) compatible with the current version of Home Assistant?
I’m currently running HA version 0.97.1 on a dedicated Linux server. I can see the new device, but it has the name zwave.aeotec_limited_unknown_type_0102_id_0007. I can also see several sensors, including the sensor.aeotec_limited_unknown_type_0102_id_0007_access_control entity. The value of this sensor changes when I open and close the door the sensor is attached to (the value changes between 22 and 23 as described in posts regarding the older Aeotec Door/Window Sensor 6 model).
There is also a binary sensor called binary_sensor.aeotec_limited_unknown_type_0102_id_0007_sensor available, but its state is “off” no matter what the position of the physical sensor is. I assume I could create a template using the access_control entity above that would properly mimic the state of the door (open vs. closed) but I found the presence of this binary sensor a bit odd (previous posts for the Sensor 6 don’t ever seem to mention this).
I thought I might need to change the configuration of the device, as other posts talk about changing the “report type” to a binary report. This is where I discovered the biggest problem: there are no configuration options in the Z-Wave Config Options menu for this device. I can select it as a node, but when I click the dropdown menu under Node Config Options, nothing appears. I read in another post that in order to make changes a device needs to be awake, but when I press the wakeup button it only stays awake for 1 second before going back to sleep (per my OZW log).
The fact that HA has labeled my device as aeotec_limited_unknown_type_0102_id_0007 and that there are no configuration options leads me to question whether or not it is currently compatible with HA. Perhaps it’s too new and not yet in the homeassistant-pyozw package? This is starting to get out of my depth, but I note that there is a zwa008.xml config file in the original OpenZWave library (https://github.com/OpenZWave/open-zwave/tree/master/config/aeotec) but there does not yet appear to be one in the HA fork (https://github.com/home-assistant/open-zwave/tree/hass/config/aeotec). Perhaps this is the issue?
Any help or thoughts would be much appreciated! Thanks!
Unknown means OZW does not have the device in its database, which isn’t surprising since this is a new device and OZW 1.4 development has stopped long ago. The naming is not really important though. Besides that, most of the functionality does not require a config file and will work as-is.
In order to set configuration options and use association groups, you’ll need a config file. HA uses OZW 1.4 which is not accepting any device config files, which is why it isn’t being detected. You can create your own though and use it in your own installation. Starting from an existing file is easiest.
HA provides the service call zwave.set_config_parameter. I think it still requires values from the config file, but I could be wrong there, you’ll have to try it. The config parameters are described in the manual.
According to the manual, the sensor seems to have the ability send central scene commands. You’ll have to hand-edit the zwcfg*.xml file in order to use that.
For basic door open/closed operation, you don’t need anything else. The access_control entity is used for that. As you mentioned, you’ll need to create a binary template sensor to represent it as open/closed. This is standard for most door sensors.
The manual says the binary sensor is for tilt detection.
I’m still a bit of a novice with this, so I have a few questions that are probably super simple but I can’t seem to find any clarification:
I’m assuming that the zwcfg_*.xml is the file located in my <installation>/.homeassistant directory, correct?
The Adding Devices page from the OZW wiki mentions a few files that one should modify to add new devices, like the manufacturer_specific.xml file and device configuration xml files that are supposed to be placed in a config directory. I cannot seem to find these files or directories in my local installation. Where are they located?
I’m not sure if that file will work or not, it kind of looks like the beginning of a format for OZW 1.6. There is already a OZW 1.4 file though. This means something is wrong with your installation because the device should have been detected (the type and id are listed here). What OS are you using? Did you ever install any openzwave packages?
My server is running CentOS 7.6.1810. I am using Python 3.6, and I have HA installed in a Python virtual environment as noted in the HA install docs here and here and here. Although note that I am not using a Raspberry Pi.
I assumed only Python packages would be needed; for example, I definitely have the homeassistant-pyozw package installed in my HA virtual environment (version 0.1.4). Are other packages required (Python or otherwise)? With the exception of the weirdness with this one new device, the rest of my Z-Wave devices work well.
UPDATE: One thing of note – after some googling, I see that there is a python-openzwave package; interestingly, I do not appear to have this currently installed in my HA virtual environment. Stupid question – is this package required? If so, I’m really surprised my Z-wave stuff is working so well without it.
homeassistant-pyozw is the correct package, it replaces python-openzwave. You can find the location of the default config path where the manufacturer_specific.xml file lives it. In my virtualenv that’s /home/homeassistant/.pyenv/versions/3.6.3/envs/homeassistant-3.6.3/lib/python3.6/site-packages/python_openzwave/ozw_config/manufacturer_specific.xml. Check your file and see if it contains the line:
<Product type="0102" id="0007" name="ZWA008 Door Window Sensor 7" config="aeotec/zwa008.xml"/>
which matches your device. If it doesn’t, then you have outdated config files.
Based on @freshcoast’s suggestions, I dug around and I finally found a directory in my venv at <installation>/homeassistant/lib/python3.6/site-packages/python_openzwave/ozw_config/. This appears to be where the various device xml files are stashed. Hooray!
The zwa008.xml device file appears to be missing from my .../ozw_config/aeotec directory. Similarly, there does not appear to be a corresponding entry in my manufacturer_specific.xml file. So this is presumably what’s causing my problems
I assume I can simply copy the OZW 1.4 zwa008.xml file into this directory (and update the manufacturer_specific.xml file as well)?
Of course, that doesn’t explain why it’s missing in the first place. My homeassistant-pyozw package is supposedly up to date:
(homeassistant) [homeassistant@localhost ~]$ pip3 install --upgrade homeassistant-pyozw
Requirement already up-to-date: homeassistant-pyozw in <installation>/homeassistant/lib/python3.6/site-packages (0.1.4)
Requirement already satisfied, skipping upgrade: PyDispatcher>=2.0.5 in <installation>/homeassistant/lib/python3.6/site-packages (from homeassistant-pyozw) (2.0.5)
Requirement already satisfied, skipping upgrade: six in <installation>/homeassistant/lib/python3.6/site-packages (from homeassistant-pyozw) (1.12.0)
I assume there may be other files that are missing or outdated. Is there some way to update the config files automatically?
I think when you install homeassistant-pyozw (or python-openzwave), it downloads the latest XML files. The zwa008.xml file is relatively new, dated April 7th. The 1.4 release of homeassistant-pyozw was created on April 6th. So in theory, if you (or HA to be exact) installed the ha-pyozw 1.4 module prior to the XML existing, it would never have been downloaded (because it didn’t exist yet). Since the module version has not changed since, there’s been no reason toupgrade the module, which would download new files.
You have a few choices.
Like you said, you could just download the latest and copy them over into your virtualenv.
You could uninstall the module (making sure every file is purged) and reinstall it, and that would likely download the latest config files.
Or you could download the config files as in #1 into a new directory and use the zwave config_path setting.
Assuming you do one of those, after restarting HA you’ll either want to 1) Remove and Re-Add the device, or 2) Click on “Refresh Node” in the control panel and then click on the inclusion button (or some series of button presses) to send a node update, which will refresh it.
I should mention there is a zwave.update_config HA service, which in theory would have updated your config files, but it doesn’t actually work. It will place the new config files into a config subdirectory, so you could do that and move the files up one directory.
You’d start with .../ozw_config and it would create a .../ozw_config/config directory with the new files.
Actually you don’t want to do any of that. Even though it’s broken, it does download the 1.6 config files, which are incompatible.
Sorry for the delay – got a little busy, and then while trying to troubleshoot this I figured out that the battery in the sensor had died so I needed to get a new one. Anyway…
I copied the updated manufacturer_specific.xml file and the new zwa008.xml into the relevant directories in my virtual environment (and restarted HA). I didn’t want to overwrite all of the various device files right now out of paranoia (everything else in my setup currently works properly). I’m disappointed that updating the package does not bring down the new devices files, but I suppose I can add in new files when needed.
I wanted to avoid removing the device if possible, so I went with option 2 first. I clicked “Refresh Node” in the ZWave control panel and then woke up the sensor (in this case, by single-tapping the tamper switch)…and it worked! It is now correctly identified as a “Aeotec Limited ZWA008 Door Window Sensor 7” sensor, and the Node Config Options are available in the ZWave control panel (note that the entity name is still aeotec_limited_unknown_type_0102_id_0007_sensor but I can give it a more friendly name).
Using the info in this post, I created a sensor template for the door it’s attached to, and I was able to successfully create some automations triggered by the sensor! Thanks so much!
Is the AeoTec Sensor 7 reporting the binary_sensor correctly for you now? I have the same sensor with HA 98.4 and I am finding out that I dont always get the notification from the binary_sensor. Some of the times it reports, and sometimes it misses — confirmed in the log file. It always sends the access_control event correctly, so I ended up using it.
I’m currently running HA 97.2. My binary sensor always reads as “off” but I think that’s because it’s not a binary sensor in the way you’re thinking – I don’t think it’s meant to indicate if the Sensor 7 is open or closed (on my system this entity is called binary_sensor.aeotec_limited_unknown_type_0102_id_0007_sensor). I ended up creating a binary_sensor template using the info in one of the links above to create my own binary sensor that tracks the behavior of the access_control entity, probably similar to what you did:
You can use that sensor in a lovelace card by referencing the new binary_sensor.mysecretdoor entity created by the template. This looks much friendlier as it displays as a door icon and has states of ‘open’ and ‘closed.’ I was able to create some automatons based on the state of this sensor that work well.
You could do this with some of the other entities as well; for example, the burglar entity is a tamper sensor that indicates when the cover of the Sensor 7 has been removed. You could create another binary_sensor template that presents this in a more friendly way as well.
OK, good to know that you are seeing the same issue on the “binary sensor” as reported and discovered from the device. Thanks for the hint on how to convert the access to a binary value. I am less than a week into both Zwave and HA. It’s been fun, sorta.
@ngrusz1 FYI: After about ten days of having the Aeotec sensor 7 on line, I am finding that sometimes the access_control flips to a state of 254. It doesn’t seem to be the sensor itself that is sending the 254 code, but rather the state being set to asleep somewhere in HA. Doesn’t happen too often. Seen only two times. Someone was reporting the same issue on the Fibaro sensors too. I think I can just put an automation to flip it back to the state it came from as suggested somewhere.
where <installation> is the root directory for your Home Assistant instance. Note that I installed my Home Assistant instance onto a linux server running CentOS 7. If you’re using Debian or hassio, I’m not sure what your exact directory structure would look like.
@khaimong I’m finding the same issue where the access_control flips to a state of 254.
Did you ever end up solving this, if so would you mind sharing your automation?
Thanks
I used an input_boolean to shadow the state of the sensor. See below. The “garage_side_door_latch” is the renamed “access_control”
I never figured out if it is OZW or HA or device that is setting the state to 254, since the code below worked good enough. Since then, I have noticed that the default wakeup interval for this particular device is 24 hours. Maybe you should try shortening it to four or six hours through the zwave configuration for the device.
Also note that good batteries for this sensor are hard to find. I got a pack of four and all of them ran out of juice within a day. Open circuit testing shows rated voltage, but fails under load. I was starting to suspect that it was the device that failed, but the next battery I tried worked for at least eight months.
#########################################################################
# Garage side door hack. This is to get around the problem of
# the device state going to 254 or something when it goes to deep sleep.
- alias: 'Side Door Open'
trigger:
platform: state
entity_id: sensor.garage_side_door_latch
to: '23'
action:
service: input_boolean.turn_on
data:
entity_id: input_boolean.garage_side_door
- alias: 'Side Door Close'
trigger:
platform: state
entity_id: sensor.garage_side_door_latch
to: '22'
action:
service: input_boolean.turn_off
data:
entity_id: input_boolean.garage_side_door
– is this package required? If so, I’m really surprised my Z-wave stuff is working so well without it.