really?
what’s the point of this thread then? do the developers just want people saying “yay good job” in this thread? if the threads are meant for discussing issues with this new build then they might as well lock the thread.
most users are not going to check multiple places to figure out why they are experiencing an issue and what they can do about it. and most users aren’t going to want to create a github account just to report issues, especially since github is another intimidating platform to learn/understand for many users who don’t come from programming backgrounds.
also i find it really hard to believe that the developers aren’t looking at this thread.
There is a place for discussion and there is a place for reporting issues. The reason why the issue tracker is important is because most people miss out on giving important details and the template helps both users and developers. A blog comments is not the place for those discussions. You may have a small quick fix and forums can help for that but if you have traceback errors you should file a bug. If you want your stuff fixed you will file a bug. If you find it such a big inconvenience to file a bug then is the issue hurting you that bad? If you want something fixed don’t you want to follow the right path to get it fixed? Most users do file bugs in the issue tracker, I think you should do the same. We are all here to help each other and learn, if your part to help is to create bugs then please do so. Help the people trying to help you instead of complaining.
For the problem I’m seeing is related to Audio device volume being set. Which is generating entity_id warning.
In addition, to specifically call out a single Sonos device to change the volume, within the automation tool, there is not entry to select, say, Sonos-Living-Room device.
Also to add. If the developers are implementing this change, all end users will need to update their code. The problem is, Developers need to look at the broader scope. Maybe implement new “service” identities.
I think you’re getting two separate things confused:
The first issue is replacing ‘illegal’ characters with underscores is replacing things like ‘.’ with underscores so they make legal entity names. So like the example, if you had a file-size sensor looking at your database, you specify it in the configuration file as:
I had one of these and that’s exactly what happened.
The second, completely separate thing, is they had to change the beginning of the names of entities created by the 17Track component so that they could be used in in Jinja templates (this is explained if you visit the bug link next to the block you just quoted). You can’t have a name that begins with a number in a template
Setup failed for zwave: Could not install all requirements.
11:33 AM setup.py (ERROR)
Not initializing zwave because could not install requirement homeassistant-pyozw==0.1.2
11:33 AM requirements.py (ERROR)
Unable to install package homeassistant-pyozw==0.1.2: Failed building wheel for homeassistant-pyozw
Command "/srv/homeassistant/bin/python3 -u -c "import setuptools, tokenize;__file__='/tmp/pip-install-fjn3hvc4/homeassistant-pyozw/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record /tmp/pip-record-kw3zevtp/install-record.txt --single-version-externally-managed --compile --install-headers /srv/homeassistant/include/site/python3.5/homeassistant-pyozw" failed with error code 1 in /tmp/pip-install-fjn3hvc4/homeassistant-pyozw/
I’m new to homeassistant and this blog, so please excuse any unintentional deviations from standard protocols. Does anyone have a solution to what appears to be a fairly common problem with zwave with this upgrade? I like to keep my software current, but this upgrade cause a big problem. Thanks in advance for any assistance/guidance.
I pressed that Restart button and the issue remains. Here is the error log:
2019-01-11 12:10:15 ERROR (MainThread) [homeassistant.components.device_tracker] Unable to load /home/homeassistant/.homeassistant/known_devices.yaml: Config file not found: /home/homeassistant/.homeassistant/known_devices.yaml
2019-01-11 12:15:26 ERROR (Thread-5) [homeassistant.util.package] Unable to install package homeassistant-pyozw==0.1.2: Failed building wheel for homeassistant-pyozw Command "/srv/homeassistant/bin/python3 -u -c "import setuptools, tokenize;__file__='/tmp/pip-install-ipywk_vi/homeassistant-pyozw/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record /tmp/pip-record-0kk5lilm/install-record.txt --single-version-externally-managed --compile --install-headers /srv/homeassistant/include/site/python3.5/homeassistant-pyozw" failed with error code 1 in /tmp/pip-install-ipywk_vi/homeassistant-pyozw/
2019-01-11 12:15:26 ERROR (MainThread) [homeassistant.requirements] Not initializing zwave because could not install requirement homeassistant-pyozw==0.1.2
2019-01-11 12:15:26 ERROR (MainThread) [homeassistant.setup] Setup failed for zwave: Could not install all requirements.
I wish that the old way wasn’t deprecated. I tried the new way, but it takes all json attributes from mqtt payload arrinving to json_attributes_topic as sensor attributes. Old way allowed one to cherrypick some fields from state payload. One cannot migrate to new style with existing mqtt payloads - and it isn’t always possible the change them. What I’m trying to say that there is still an use case for old style too.
Ok i’m in the boat. Upgraded from 0.84.6
Z-Wave behaves erroneously. Sometimes it works. Sometimes it doesn’t. Can’t switch on or off from the frontend in 80%
All you z-wave people with issues, have you logged or seen if your issue has been raised on GitHub? i saw one raised but it could be different for you. https://github.com/home-assistant/home-assistant/issues/19903
So i would suggest adding your problem if it’s the same or create a new one.
It says so under reporting issues paragraph to use the issue tracker, so yes really.
The devs may look at the thread, but github tracks the issue so that it can be resolved. How many posts do you see saying, “mine broke to.” how are they supposed to work on the issue from that information.
Asking people to log a problem on github is really as small ask of us especially when those people who fix the issue do it in their spare time and software is free.
Too true, if users don’t want to be part of the community, they have solutions from vendors who really don’t give a shit about users, so you don’t get to have issues addressed.