Home Assistant 0.41.0 Update | Battery Values are Gone

So I thought I did due diligence and with reading over the notes on the 0.41.0 update and saw nothing that would affect my setup, I especially saw nothing that indicated that would affect the reporting of battery levels. Yet, after upgrading, I have nothing. Every battery powered sensor had battery levels being reported, for example:

sensor.aeotec_zw100_multisensor_6_battery_level_25_0

Now, that’s all gone after the update to 0.41.0. Another ‘breaking’ change? I can’t even get it with a template:

{{ states.sensor.zooz_zse40_4in1_sensor_sourcenodeid_79_2.attributes }}
{{ states.binary_sensor.aeotec_zw100_multisensor_6_sensor_25_0.attributes }}

And I could do that, at least use a template, but battery level is not even listed in the attributes now.

1 Like

I started OZWCP and I can still see the battery values there.

Can confirm, none of my battery powered Z-Wave devices report a battery level any more.

I’d suggest you raise an issue, then post a link here so others who’re also seeing it can add to it.

Ah, it looks like the battery level is now reported under a new entity. If you had sensor.aeotec_zw100_multisensor_6_battery_level_25_0 then you’ll likely now find a zwave.aeotec_zw100_multisensor_6_25_0, which includes all the relevant Z-Wave information, including battery level.

It does look to be the intended result of this change.

I’m not a fan of this change. If I could figure out how to move the Zwave card with all my devices to a separate tab I’d be happy. I figured out how to hide the card but now I can’t check my battery levels.

This zwave update #6690 really threw me for a loop. At first I got an unwanted “group or state card” on my main page with all my zwave devices. That screen is too busy already. Then I found out how to hide the entities and then I read this post and realized the battery sensors were missing. Aye, yi yi.

So I downgraded back to 0.40.2 and don’t like being left behind so I did something I should have learned how to do ages ago.

default_view:

Never did like all those sensor circles on my main page anyway.

Made a page for automations, sensors, and finally the zwave stuff. I can now see the battery state by clicking on the associated sensor. That’s fine by me.

WTF Guys?!
With 0.40 (IIRC) a “standalone” battery_level entity was introduced for each zwave device and I changed all my battery level monitoring and graphing (InfluxDB/Grafana) to this new entity - which, regarding Grafana, included losing all the history data since the measurement names in InfluxDB got a new name too.
And now this got dropped again?! Not cool…

Sebastian

1 Like

So, now, instead of the battery levels being in plain view and easy to set up where I could simply grab sensor.aeotec_zw100_multisensor_6_battery_level_25_0 and add it to a card now I have to set up templates to extract it from the attributes?

I don’t understand the logic in this kind of upgrade. How many users are going to want to get that involved in setting up a system? Or is HA not targeting the typical home automation user? Help me out here. I am just trying to understand. I thought the battery entity was a beautiful thing, easy to set up. Now I have to create a template sensor for each sensor battery level I want to keep an eye on and then set that up in HA. It just doesn’t make sense to make something that was so easy, more complicated.

Anyway, on top of that, it does not appear any of my sunrise automation’s ran either. When I try to manually turn off the devices, it does not seem like the zwave messages are getting through.

1 Like

Okay, that explains why the start-up times are absolutely horrendous now. If you restart HA it is considerably longer before the system is ready for anything. Reading it, I can kind of get a sense for why they were doing it, though, again, it’s not something the typical home automation user is going to go look for, read/investigate. And the developers do not seem keen on giving any info before hand about what will be in the next update so that the people do understand the technical side a fraction, can make changes and adjust. And while I now know about the pull requests, how many normal/typical home automation users do you think will want to mess with all that? They just want a system they can set up and get going.

I mean, I get it, HA is a beautiful system and good Lord it is hard to conceive of a home automation device that won’t work in HA because so many are supported and it (was) fast and responsive (prior to this update) but it comes at the expense of being willing to spend potentially hours in front of your PC either trying to understand the technical details, pull requests, etc. and reconfiguring your particular set up. And to me, that just seems counter intuitive to why one would use home automation in the first place. One uses such systems to make their life a bit easier, more convenient, not less so.

I’m seeing overall startup times about the same as 0.40. The GUI is available within a few seconds now, and full startup follows in under a minute.

I do get your point though, HA is currently very visibly going through “growing pains” right now (or at least, it’s visible if you’re running it, or taken the time to read the forum). Each fortnightly update brings the probability that something will break. Most of those are documented, but some are only hinted at in the pulls, and some neither. I expect that the closer it gets to 1.0 the less that’ll happen though.

Apparently, you cannot downgrade to reverse the action. Downgrading back to .39 causes ALL kinds of errors and HA won’t start. Downgrading to 40.2 still, reports the ZWave entities as with .41.

At first glance, it would seem that upgrading to 0.41.0 makes a change that cannot be undone with a downgrade.

Put me in the camp of “Don’t like this change as it relates to Z-wave” but as I posted earlier I just made tabs for everything. I wish I could see battery info at a glance but I can still access it. The other option would be to not upgrade and stay at 0.40.2.

You can (or: have to) create template sensors for each device:

platform: template
sensors:
  bat_livingroom:
    value_template: '{% if states.zwave.danfoss_z_thermostat_014g0013_heating_1_4 %}
      {{ states.zwave.danfoss_z_thermostat_014g0013_heating_1_4.attributes.battery_level }}
    {% else %}
      n/a
    {% endif %}'
    friendly_name: 'Thermostat Living Room'
    unit_of_measurement: '%'
    entity_id: zwave.danfoss_z_thermostat_014g0013_heating_1_4

and then create a group/card that includes all the battery template sensors you made.
So it was before 0.40 and apparently is now again.

Sebastian

1 Like

I don’t know how in the world it happened, but somehow my network key got wiped out in the python open zwave directory when I upgraded. In fact, it looked like it had been replaced as the network key section was commented out. That would explain the sluggishness and lack of responsiveness. Fortunately, after being bitten by all the breaking changes, I backed up the network key and was able to put it back in.

However, now I can’t get the stick to initialize.

$ cd /opt/open-zwave-control-panel/ && ./ozwcp -p 8890
Could Not Open OZW Log File.
2017-03-26 13:26:12.265 Always, OpenZwave Version 1.4.2434 Starting Up
webserver starting port 8890
post: key=dev data=/dev/ttyACM0 size=12
post: key=fn data=open size=4
post: key=usb data=false size=5
2017-03-26 13:26:28.151 Info, Setting Up Provided Network Key for Secure Communications
2017-03-26 13:26:28.152 Info, mgr,     Added driver for controller /dev/ttyACM0
2017-03-26 13:26:28.152 Info,   Opening controller /dev/ttyACM0
2017-03-26 13:26:28.152 Info, Trying to open serial port /dev/ttyACM0 (attempt 1)
2017-03-26 13:26:28.152 Error, ERROR: Cannot open serial port /dev/ttyACM0. Error code 13
2017-03-26 13:26:28.152 Error, ERROR: Failed to open serial port /dev/ttyACM0

Is something else, like HA, using the Z-Wave stick?

No sir. I thought that too, that perhaps something went south in that regard. The only thing that runs on this server is Home Assistant, FTP server and Samba.

Okay, it seems I cannot initialize the stick from the OZWCP. I can start HA and, though it takes forever (several minutes) for the system to be fully started and able to run commands such as turning on/off switches, etc.

The question now, is there any way to test and isolate the cause? Could I delete they python openzwave directory and rebuild it without messing up the rest of the system? Or is there some way to check the configuration, dependencies, etc.

Everything was fine until the 0.41.0 upgrade, so whatever happened in that process or in the process of trying to downgrade, my python openzwave directory, specifically the options.xml, got all kinds of jacked up.

No matter what I do, I cannot get the ZStick to initialize in OZWCP:

cd /opt/open-zwave-control-panel/ && ./ozwcp -p 8890
Could Not Open OZW Log File.
2017-03-26 15:46:25.804 Always, OpenZwave Version 1.4.2434 Starting Up
webserver starting port 8890
post: key=dev data=/dev/ttyACM0 size=12
post: key=fn data=open size=4
post: key=usb data=false size=5
2017-03-26 15:46:34.421 Info, Setting Up Provided Network Key for Secure Communications
2017-03-26 15:46:34.421 Info, mgr,     Added driver for controller /dev/ttyACM0
2017-03-26 15:46:34.421 Info,   Opening controller /dev/ttyACM0
2017-03-26 15:46:34.421 Info, Trying to open serial port /dev/ttyACM0 (attempt 1)
2017-03-26 15:46:34.421 Error, ERROR: Cannot open serial port /dev/ttyACM0. Error code 13
2017-03-26 15:46:34.421 Error, ERROR: Failed to open serial port /dev/ttyACM0
2017-03-26 15:46:34.421 Warning, WARNING: Failed to init the controller (attempt 0)
2017-03-26 15:46:39.421 Info,   Opening controller /dev/ttyACM0
2017-03-26 15:46:39.421 Info, Trying to open serial port /dev/ttyACM0 (attempt 1)
2017-03-26 15:46:39.421 Error, ERROR: Cannot open serial port /dev/ttyACM0. Error code 13
2017-03-26 15:46:39.421 Error, ERROR: Failed to open serial port /dev/ttyACM0
2017-03-26 15:46:39.421 Warning, WARNING: Failed to init the controller (attempt 1)
2017-03-26 15:46:44.421 Info,   Opening controller /dev/ttyACM0
2017-03-26 15:46:44.421 Info, Trying to open serial port /dev/ttyACM0 (attempt 1)
2017-03-26 15:46:44.421 Error, ERROR: Cannot open serial port /dev/ttyACM0. Error code 13
2017-03-26 15:46:44.421 Error, ERROR: Failed to open serial port /dev/ttyACM0
2017-03-26 15:46:44.421 Warning, WARNING: Failed to init the controller (attempt 2)
2017-03-26 15:46:49.421 Info,   Opening controller /dev/ttyACM0
2017-03-26 15:46:49.421 Info, Trying to open serial port /dev/ttyACM0 (attempt 1)
2017-03-26 15:46:49.421 Error, ERROR: Cannot open serial port /dev/ttyACM0. Error code 13
2017-03-26 15:46:49.421 Error, ERROR: Failed to open serial port /dev/ttyACM0
2017-03-26 15:46:49.422 Warning, WARNING: Failed to init the controller (attempt 3)
2017-03-26 15:46:54.422 Info,   Opening controller /dev/ttyACM0
2017-03-26 15:46:54.422 Info, Trying to open serial port /dev/ttyACM0 (attempt 1)
2017-03-26 15:46:54.422 Error, ERROR: Cannot open serial port /dev/ttyACM0. Error code 13
2017-03-26 15:46:54.422 Error, ERROR: Failed to open serial port /dev/ttyACM0
2017-03-26 15:46:54.422 Warning, WARNING: Failed to init the controller (attempt 4)
2017-03-26 15:46:54.422 Detail, contrlr, Notification: DriverFailed
2017-03-26 15:46:54.422 Info, Notification: Driver Failed, homeId 00000000

I can only assume it is based on the first line stating that it is because it cannot open the log file, which is there. I have a symlink from the OZWCP directory to the Home Assistant config directory:

ln -s /opt/open-zwave-control-panel/zwcfg_*.xml /opt/homeassistant/.

Two questions on that:

  1. How dow I remove that symlink
  2. Or should I also symlink from Home Assistant back to OZWCP directory?

At this point, that is all I am left with. I don’t know what else it could be.

Just chipping in to say I’ve lost all my Zwave stuff in the upgrade too. I had assumed it was my SD card as I think it’s on the way out but perhaps not if @StormStrikes seems to have the same problem.

I did get some zwave devices and the USB stick back after four or five reboots but all entities had changed names and it disappeared on the next reboot and hasn’t come back.

I am no expert on this, but my assumption is that HA will boot up and does its auto discovery thing which is why it takes forever for everything to become operational. Or its reading from the zwcfg_*.xml file in the HA config directory and using that to set everything back up. Not sure, as I mentioned, I am no expert on this.

I used diagnostic software from Aeotec to confirm the ZWave Stick appears to still be good, all the nodes are there and I can see it communicating with a couple nodes. The breakdown seems to be with the OZWCP communicating with the ZStick and/or reading the config xml file. Unfortunately, I am at a loss as to how to fix that.