Home Assistant 0.41.0 Update | Battery Values are Gone

Configuration Z-Wave
21

Looking at the OZW log file when starting HA, it appears that it is able to communicate with the Zwave stick:

2017-03-26 16:12:44.496 Always, OpenZwave Version 1.4.2434 Starting Up
2017-03-26 16:13:11.480 Info, Setting Up Provided Network Key for Secure Communications
2017-03-26 16:13:11.480 Info, mgr,     Added driver for controller /dev/ZStick
2017-03-26 16:13:11.480 Info,   Opening controller /dev/ZStick
2017-03-26 16:13:11.480 Info, Trying to open serial port /dev/ZStick (attempt 1)
2017-03-26 16:13:11.481 Info, Serial port /dev/ZStick opened (attempt 1)
2017-03-26 16:13:11.481 Detail, contrlr, Queuing (Command) FUNC_ID_ZW_GET_VERSION: 0x01, 0x03, 0x00, 0x15, 0xe9
2017-03-26 16:13:11.481 Detail, contrlr, Queuing (Command) FUNC_ID_ZW_MEMORY_GET_ID: 0x01, 0x03, 0x00, 0x20, 0xdc
2017-03-26 16:13:11.481 Detail, contrlr, Queuing (Command) FUNC_ID_ZW_GET_CONTROLLER_CAPABILITIES: 0x01, 0x03, 0x00, 0x05, 0xf9
2017-03-26 16:13:11.481 Detail, contrlr, Queuing (Command) FUNC_ID_SERIAL_API_GET_CAPABILITIES: 0x01, 0x03, 0x00, 0x07, 0xfb
2017-03-26 16:13:11.481 Detail, contrlr, Queuing (Command) FUNC_ID_ZW_GET_SUC_NODE_ID: 0x01, 0x03, 0x00, 0x56, 0xaa

I deleted the zwcfg_*.xml file out of the HA config directory just to see what it would do. It started, but obviously, several things were missing, but it started and I can see it is communicating with the zwave stick for, what I assume, is discovery of some of the devices.

22

No change in the start up time for HA. It appears to still be going through some process that takes several minutes (5+ it seems) to finish. My automation’s did not work this morning, I am not hopeful they will this evening so without further help/input to isolate the issue I guess I am going to have to chalk it up to being poked in the hiney again by another upgrade and possibly have to rebuild my HA install. Not sure what the test and acceptance procedures are, but they aren’t working. Or new features/code are being added and it’s just chalked up as being a good thing without any understanding of the effects it may have.

It’s absolutely awesome the work being done on this project, it’s absolutely awesome there are so many products that work with HA and it’s absolutely awesome that so many new features are being added. It all means squat, however, when you try to take advantage of those new things and your system gets broke because all that stuff was added just because it seemed cool to do.

Of all the HA developers do, of all the time and hard work they invest in this project, I wish they would invest some of that time and work into understanding how these changes will affect current users, particularly new users that are not interested in writing code, reading pull request or trying to decipher the broken information.

23

I think it’s important to realise that if you are like me and upgrade as soon as you see it’s available you are in a way a beta tester. There is no auto upgrade so it’s a choice we make. After getting bitten by unforeseen errors such as these I consider waiting a week or two before upgrading but I never do as it always gets fixed quickly. There doesn’t seem to be many people with z-wave issues so far so perhaps it’s a fairly narrow problem.

Just rebooted my Pi and have z-wave back but everything renamed. No time to fix it until next weekend now and I’ll have to live without a few automations for the week but it’s not the first time and wont be the last.

1 Like
24

I agree with you on that. We are, for better or worse, the beta testers. However, I have participated in many beta tests of software and the like and this is the first one in which there was little to no test an acceptance. In other words, beta testers typically serve as the final check to catch those one-off situations before production or stable use.

I have never seen a beta test with so many breaking things. Now that is not necessarily a good or a bad thing, but it is when you are trying to set up a home automation system as a new user. When you go to the Home Assistant website it does not say this is under development/beta testing, use at your own risk or may require technical know-how. The current version listed does not say Beta Current version or anything that would lead you to believe this is still being tested with heavy development.

You come to their website and everything suggests this is another home automation platform that is ready to use. I am not knocking the developers and the effort and time they have and are investing, I am simply trying to start a dialogue on involving the people that aren’t interested in reading the pull requests or working out how to use templates or sort through some of the broken examples and/or documentation. The foundation laid now, is only going to be amplified when a stable release is reached. If you are seeing breaking changes, surprise breaking changes, etc. now, it’s only going to be amplified when you reach stable releases. My assertion is only this; spend some time on seeing how things will affect new/newer users. See if your documentation is understandable by them, if your examples are understandable by them, etc. Then when you get ready to release an update, invest at least a couple days prior to that trying to get the word out as to what is changing and how it will affect things. Or just slow down the release schedule a little and do the same. Something along those lines.

Home Assistant is certainly software I would pay for to either buy or use. But I would not do so for long after the breaking changes of the last few releases.

You may own a Ferrari, but what value or fun is that if everytime you take it out on the road, it breaks in some manner?

25

After working with this most of the day, my HA startup is still way, way sluggish. It takes every bit of 5 - 10 minutes before the system is responsive to commands/events, etc. As best I can tell, it looks like it is going through every time and rediscovering everything, that’s how it seems, it may be something else.

I downloaded another home automation system and set it up and it had no problems discovering all the devices on the Aeotec ZStick in no time, so it does not appear to be an issue with the ZWave transceiver.

I tried to downgrade to 0.40.2 and ran into ALL KINDS of mess. That appears to be a result of the dependencies not downloading and it shows all in the error log.

If you look in the python dist-packages folder for 0.41.0 you will see:

homeassistant
homeassistant-0.41.0.dist-info

And there are no dependency issues there. If you downgrade to 0.40.0 you will see:

homeassistant
homeassistant-0.40.0.egg-info

And it has massive issues with dependencies.

So I tried downgrading to 0.39. series and found:

homeassistant
homeassistant-0.39.3.dist-info

I don’t know what the difference is in egg-info and dist-info, all I know is the egg-info simply would not start because of many, many dependency issues.

All that, however, does not address the sluggishness of HA. I can only assume there is some update that is persistent across versions now with the upgrade to 0.41.0 that is not reversed when you downgrade.

Once HA does all its discovery thing and the system is fully on line, everything seems normal other than I cannot initialize the ZStick from the OZWCP. I hope someone can help but, absent that, it would seem my only alternative is to rebuild my HA setup. What I have now is just not acceptable. I don’t want to have to go fix dinner or run errands everytime I restart HA due to the time it takes to get fully back on line.

26

Id say its more of an alpha really at this point since there is breaking changes every week. It is what is though, they want to make everything as good as possible now so they don’t have to make so many breaking changes in the future when it affects more people.

27

Okay, so there is definitely some kind of issue with HA downloading dependencies on 0.40.2. I wiped out everything and started from scratch so I could see what was going on. I initially install HA 0.40.0:

pip3 install homeassistant==0.40.0

thinking it would go ahead and download 0.40.2 as it has done in the past. Download 0.39.0 and it will download the 0.39.3 and install that. However, it did not do that in this instance. I went ahead and started HA so I could see it rebuild the config directory and everything went as it should and I was able to log into the frontend. After that, I decided let’s go ahead and get the latest in that series so I wiped everything out again, including the python dist-packages and used the above command to install 0.40.2.

This time, however, when I started HA it only downloaded the deps folder, nothing else. I waited several minutes too just to be sure. I shut it down then sometime later I restarted and it downloaded everything as normal and set up the config directory as it usually does.

I tried exactly this when I downgraded from 0.41.0 and it made no difference, I still got all the dependency errors, but it appears wiping everything out and starting over has at least let the 0.40.2 series get set up correctly. Now, if only the rest of the install will go smoothly and run correctly.

28

I got everything rebuilt and I can once again initialize and read from the Z-Stick with OZWCP. I am not sure how the upgrade wiped out my network key, more specifically, the options.xml file or if it was some sort of horrible timing with something else going on, but I can at least use OZWCP again.

However, the start-ups for HA are still horribly sluggish whereas prior to the 0.41 upgrade I was able to use HA within a minute or two of the frontend being available. I am currently on 0.40.2 and have my battery levels again. If I could figure out why things are so sluggish I’d be back to where I started before the upgrade. For now, it will have to do until another option can be found.

29

Maybe this will be useful for the future. But from your log files you look like you’re trying to open two different files, /dev/ttyACM0 and /dev/ZStick, the later is probably a udev rule that points at the proper serial device. In Linux you’re never guaranteed that the USB serial port will end up at ACM0. If the device resets and ACM0 is still open it’ll get named ACM1, etc. Long story short, when using ozcp in the future give it the name /dev/ZStick and hopefully it’ll you’ll have better luck. (btw, if you run dmesg from the console you see what device it was assigned)

Also, Error code 13 is Permission Denied. Make sure the user that’s running ozcp has permission to open the device.

Oh and always keep a copy of you zwcfg_*xml around, HA will occasionally wipe it out, which can be very annoying.

HTH.

30

That was me just trying it both ways as I did have a udev rule in place. I forgot about using dmesg though, I should have tried that.

The permissions issue was the other issue, one that did not exist before the upgrade and I could not figure out why it was an issue. I do keep a copy of the zwcfg_*.xml around which is how I knew the network key had been wiped out. It’s no biggie now as I got it all working again but I do thank you for the input.

I am not trying to get used to using templates since that is apparently what I will need in order to retain the battery values and upgrade to the latest version. I wish they would have kept some backwards compatibility there, but I am not on the development side and have no clue what all the considerations were. It just makes it a pain when have to fix all the broken stuff, particularly when it’s not clear it’s going to be broken.

31

I had the same problem last night, upgraded and then downgraded due to the battery levels and I had errors all over the shop and nothing worked. Back to 0.41.0 but not keen at all, but I will get used to more templates for battery levels I guess :frowning:

32

I had the same issues with z-wave devices and levels all disappearing. After a few restarts i have my devices back, but the names have changed and will have to update a bunch of stuff. I thought battery levels would be cool to look at, but instead i just have notifications for when the battery level falls under 15%, i thought no point in looking at it all the time when the battery lasts years in a zwave device.

33

Stumbled upon this whilst looking how to view my battery levels. I have Aeotec multisensors, where on earth can i find their battery levels? There are no entities with battery details that i can see…

I’m having issues with the sensors always reporting 100% in OZWCP, so i wanted to check if homeassistant shows the same, also it would be far easier to monitor it with HA.

34

Take a look at the first few posts in this thread. Battery levels are now reported in a zwave.NAME entity. So if your device is sensor.kitchen_multi_sourcenodeid_14_2 then your battery level, and related information will be in zwave.kitchen_multi_14

Edit: Of course, it helps all of us if you only ask your question in one thread, not in multiple places.

35

Hmmmm, my Fibaro FGMS001 motion sensor shows 0% battery level in state under dev tools but in OZWCP it shows as 100% also I get quite a few weird other sensors showing up that the FGMS001 does not have (direction, velocity, 2xgeneral, relative humidity and power which all show 0). Anyway using a template won’t fix the battery level showing as 0%. Has anyone else with a FGMS001 got the same problem?

36

I’ve got one of those, it shows the expected battery level (100% currently), and nothing unexpected. Now, from the documentation it does have sensors for direction and velocity, for the tamper detection, but they’re supposedly not exposed and I don’t see them.

37

Mine is V1.01 and it only has tamper (which is not reported), temp/lux/motion (that are reported) and earthquake (which is not reported - i think, but we don’t have many quakes in the UK :smiley: ). The battery state used to be reported but now it seems that HA can’t read it.

38

Hello Sebastian,

I’m getting all sorts of errors setting up the template for 2 fgms001 sensors.
When restarting HA my whole group layout is messed up.
I am getting a value from the template.
Do you know what is wrong with:

  batterij_sensor_hal:
    friendly_name: 'Batterij Sensor Hal'
    value_template: '{{ states.zwave.hal_3.attributes.battery_level }}'
    unit_of_measurement: '%'
    entity_id: zwave.hal_3

  batterij_sensor_achterkantgoot:
    friendly_name: 'Batterij Sensor Achterkant Goot'
    value_template: '{{ states.zwave.achterkant_goot_5.attributes.battery_level }}'
    unit_of_measurement: '%'
    entity_id: zwave.achterkant_goot_5

My group config:

  Batterijen:
    - batterij_sensor_hal
    - batterij_sensor_achterkantgoot

log:

17-04-24 21:10:18 WARNING (MainThread) [homeassistant.components.sensor.template] Could not render template Batterij Sensor Hal, the state is unknown.
17-04-24 21:10:18 WARNING (MainThread) [homeassistant.components.sensor.template] Could not render template Batterij Sensor Achterkant Goot, the state is unknown.

Thanks, Alex.

39

I think you’d need to prepend “sensor.” in the group config:

  Batterijen:
    - sensor.batterij_sensor_hal
    - sensor.batterij_sensor_achterkantgoot

Sebastian

40

Thanks. How could I have missed that…