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
Thanks @khaimong!
Good to know about the batteries.
Out of curiosity have you updated the firmware for the sensor?
I see the new firmware version mentions the battery.
Changes from V1.00 to V1.01
Fix battery bug (rapidly draining)
– is this package required? If so, I’m really surprised my Z-wave stuff is working so well without it.