Configuration Update for Aeon Stick

Hi All,
After doing a fresh install of Home Assistant, I am encountering problems all along the way compared to my first attempt.

I am attempting to update the configuration.yaml file for zwave but after restarting HA and even restarting the OS, the HA states page shows I have an invalid configuration for zwave.

I found the usb path via the following page Z-Wave - Home Assistant and using the information for Raspberry PI:

$ ls /dev/ttyUSB*

I also ran the below command too as noted in the instructions:

$ sudo usermod -a -G dialout homeassistant

As a result I updated my YAML file with the following lines:
zwave:
usb_path: /dev/ttyACM0

I checked the syntax of my YAML update via YAMLlint which indicated it was valid.

In addition to the above, I opened up the ZWave Control Panel. I was able to view all the sensors that are connected the the stick using the usb path of /dev/ttyACM0.

I’m at a loss for what the issue is at this point. Anyone have any good ideas on where I screwed things up?

Thanks in advance.

Setup specific information:

Operating System = Raspbian Full OS
Home Assistant Version = All in One Installer for Raspberry Pi
ZWave Stick = Aeon Labs Aeotec Z-Wave Z-Stick, Gen5 (ZW090)

Can you post your whole Zwave section in configuration.yaml so that we can get a better idea of what may be missing or going on? When you post that section, select it in the post editor and press the preformatted text button shown below so that the formatting is preserved.

homeassistant:
 # Name of the location where Home Assistant is running
 name: Home
 # Location required to calculate the time the sun rises and sets
 latitude: 33.7708
 longitude: -84.2931
 # Impacts weather/sunrise data (altitude above sea level in meters)
 elevation: 313
 # metric for Metric, imperial for Imperial
 unit_system: imperial
 # Pick yours from here: http://en.wikipedia.org/wiki/List_of_tz_database_time_zones
 time_zone: America/New_York

# Show links to resources in log and frontend
introduction:

# Enables the frontend
frontend:

http:
 # Uncomment this to add a password (recommended!)
 # api_password: PASSWORD
 # Uncomment this if you are using SSL or running in Docker etc
 # base_url: example.duckdns.org:8123

# Checks for available updates
updater:

# Discover some devices automatically
discovery:

# Allows you to issue voice commands from the frontend in enabled browsers
conversation:

# Enables support for tracking state changes over time.
history:

# View all events in a logbook
logbook:

# Track the sun
sun:

# Weather Prediction
sensor:
 platform: yr

# Text to speech
tts:
 platform: google


mqtt:
  broker: 127.0.0.1
  port: 1883
  client_id: home-assistant-1
  username: pi
  password: raspberry

zwave:
  usb_path: /dev/ttyACM0

Thanks again for all the help!

The config path is listed as optional in the docs, but I’m wondering if in your installation it has to be specified? Maybe it’s not in the default location that HA expects it to be? I thought this was a required value and always put it in.

config_path (Optional): The path to the Python OpenZWave configuration files. Defaults to the folder config in your Python OpenZWave install directory.

For example, this is how mine looks (AIO install pre-December 2016):

#
# ZWave Configs
#
zwave:
  usb_path: /dev/ttyACM0
  config_path: /srv/hass/hass_venv/lib/python3.4/site-packages/libopenzwave-0.3.1-py3.4-linux-armv7l.egg/config
  polling_interval: 60000
  customize:
    binary_sensor.aeotec_multisensor_6_sensor_7_0:
        polling_intensity: 1
    binary_sensor.aeotec_multisensor_6_sensor_8_0:
        polling_intensity: 1

Thanks for all the help, but that didn’t help. Thinking it was something else besides the configuration file edits that was causing the issue, I did an install from scratch (AIO).

After making one update to the configuration file, that didn’t work.

zwave:
  usb_path: /dev/ttyACM0
  config_path: /srv/homeassistant/homeassistant_venv/lib/python3.4/site-packages/libopenzwave-0.3.2-py3.4-linux-armv7l.egg/config

Now this is showing up “Config Validating”

Maybe I am using the wrong location of the Python OpenZWave configuration file.

This seemed to be alot easier to work with back in November/December timeframe.

Thanks again!

Not sure what is going on here. I have tried replacing the zwave configuration update with nest (which I had down previously before the upgrade.

Pretty simple config update using my login credentials that I use to login into nest’s website:

nest:
  client_id: username
  client_secret: password

But I get invalid config error message as well…

I think you might be pointing to the wrong place for your config, On my R-pi, the zwave config location is:

/srv/homeassistant/src/python-openzwave/openzwave/config

Take a look there and see if there aren’t a bunch of directories of z-wave devices (there should be).
If there are, try pointing your configuration to that directory.

Thanks for the suggestion @n0dyjeff, but that didn’t work either. It came back with the error message of Invalid Config.

Both the path I used and the one you provided had similar folders included in the directory.

What’s in HA’s error logs once got the nest error message?

Your formatting looks correct, but that has been my mistake in the past.

Try /srv/homeassistant/lib/python3.4/site-packages/libopenzwave-0.3.2-py3.4-linux-armv7l.egg/config

I installed using a Hassbian image and that is the location of the configuration files.

Just going to throw this out there as an unlikely but possible issue. When I first started using HA it seemed like every time i made a change to the config HA would fail, seriously every time. I was using notepad++ and every thing would look correct but after turning on show whitespace i was surprised by the amount of tabs instead of spaces there were. Also I had issues where to the eye things looked lined up but I would have either too many or not enough spaces. Copy and pasting was a big culprit for me.

Another place to look…what do you get when you check the config with
hass --script check_config --files

Do you get an script error showing up with that command? If so, maybe the output
will provide a clue…

There are only two items which don’t look like they point to a root cause, but I’m not very knowledgeable yet with HA.

17-02-20 14:26:23 WARNING (Thread-11) [homeassistant.components.recorder] Ended unfinished session (id=2 from 2017-02-20 19:26:15.686977)
17-02-20 14:26:23 WARNING (Thread-11) [homeassistant.components.recorder] Found unfinished sessions

Unfortunately, that isn’t a possiblity since the lib folder does not exist inside /srv/homesassistant/. Thanks for the suggestion though.

Unfortunately, that command didn’t work. I believe in the recent version, hass isn’t used as it came back with:

bash: hass: command not found.

try thie:
sudo su -s /bin/bash homeassistant
source /srv/homeassistant/homeassistant_venv/bin/activate
hass --script check_config --files

Thanks for your help @n0dyjeff! Below is the output of what those commands resulted in:

INFO:homeassistant.util.package:Attempting install of colorlog>2.1,<3
Exception:
Traceback (most recent call last):
File “/srv/homeassistant/homeassistant_venv/lib/python3.4/shutil.py”, line 522, in move
os.rename(src, real_dst)
PermissionError: [Errno 13] Permission denied: ‘/tmp/tmpp3hjl_ht/lib/python/colorlog-2.10.0.dist-info’ -> ‘/home/homeassistant/.homeassistant/deps/colorlog-2.10.0.dist-info’

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File “/srv/homeassistant/homeassistant_venv/lib/python3.4/site-packages/pip/basecommand.py”, line 215, in main
status = self.run(options, args)
File “/srv/homeassistant/homeassistant_venv/lib/python3.4/site-packages/pip/commands/install.py”, line 429, in run
target_item_dir
File “/srv/homeassistant/homeassistant_venv/lib/python3.4/shutil.py”, line 531, in move
copytree(src, real_dst, symlinks=True)
File “/srv/homeassistant/homeassistant_venv/lib/python3.4/shutil.py”, line 302, in copytree
os.makedirs(dst)
File “/srv/homeassistant/homeassistant_venv/lib/python3.4/os.py”, line 237, in makedirs
mkdir(name, mode)
PermissionError: [Errno 13] Permission denied: ‘/home/homeassistant/.homeassistant/deps/colorlog-2.10.0.dist-info’
Aborting scipt, could not install dependency colorlog>2.1,<3

Hmm. That response looks more like some difficulties installing some code needed to display the command output than what is really causing your config problem. But if there are file permission errors, perhaps they’re affecting your configuration as well.

What do the permissions on your /home/homeassistant/.homeassistant directory look like? Is is owned by homeassistant user? Do you have a directory /home/homeassistant/.homeassistant/deps/colorlog? Are the permissions and ownership of it appropriate?

What do the permissions on your /home/homeassistant/.homeassistant directory look like?

Do you have a directory /home/homeassistant/.homeassistant/deps/colorlog?
No, there isn’t a directory for colorlog under deps.

One thing to note… I have reinstalled the OS and HA several times now and each time I need to run the following command to allow me to make edit and save those changes:

sudo chown -R pi:pi /home/homeassistant/.homeassistant

Not sure if executing the above command is having an impact…

We might be getting somewhere…

I believe HA runs under the homeassistant user account. So if the pi account owns all the files in the .homeassistant directory, when homeassistant attempts to make changes, it won’t have the necessary permissions.

When you edit your configuration files, you should do so as the homeassistant user, not as the pi user. Or at least, change the ownership back to homeassistant after making the changes.

You shouldn’t need to chown the files to pi if you’re in the homeassistant account. If you start your configuration editing sessions by changing to the homeassistant virtual environment, things should work. You do this with the same commands that allowed the hass command to work earlier -

sudo su -s /bin/bash homeassistant
source /srv/homeassistant/homeassistant_venv/bin/activate

You might try chowning back to the homeassistant user and group, and see if that makes a difference.