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
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.
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
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/ttyACM0Is 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:
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.
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.
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.
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.
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?
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.
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.