It is a big mess not only that, as people come and go to my place and connect to wifi that list gets bigger. I had 10 my devices already identified and tracked and disable track new devices. This is definatley a clutter.
3 Likes
We are working on a solution to not track extra devices. You can follow progress here: https://github.com/home-assistant/home-assistant/pull/25926#issuecomment-521188651
6 Likes
I’m now randomly having an issue with simplisafe. It worked after the most recent update to 0.97.2 but I had to reboot recently and now it’s not working. In the logs I’m seeing this after the reboot.
simplisafe: Error on device update!
ValueError: 12 is not a valid SensorTypes
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 291, in _async_add_entity
await entity.async_device_update(warning=False)
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 417, in async_device_update
await self.async_update()
File "/usr/src/homeassistant/homeassistant/components/simplisafe/alarm_control_panel.py", line 198, in async_update
ATTR_LAST_EVENT_SENSOR_TYPE: SensorTypes(last_event["sensorType"]).name,
File "/usr/local/lib/python3.7/enum.py", line 310, in __call__
return cls.__new__(cls, value)
File "/usr/local/lib/python3.7/enum.py", line 564, in __new__
raise exc
File "/usr/local/lib/python3.7/enum.py", line 548, in __new__
result = cls._missing_(value)
File "/usr/local/lib/python3.7/enum.py", line 577, in _missing_
raise ValueError("%r is not a valid %s" % (value, cls.__name__))
ValueError: 12 is not a valid SensorTypes
Found the bug report for the simplisafe issue. https://github.com/home-assistant/home-assistant/issues/25872. looks like a fix is in the works.
Same here. Most (but not all) zwave devices have reverted to generated device names and lost all descriptions. The node names seem to stick but after a massive renaming session yesterday I woke up to the house not working again as all zwave devices had had their names reset again.
Renaming the entities is a massive pain as the entity register has no concept of relationship and I have to copy long generated names from the z-wave panel to the entity panel. There is no way to automate this from my end either which is just hopeless.
I’ve tried to jump back to 0.96.5 and we’ll see if that helps…
The switch to Alpine is really going to screw me over.
At the moment after each HASS update I run this script
sudo docker exec -it home-assistant pip3 install alexapy
sudo docker exec -it home-assistant pip3 install pymssql
sudo docker exec -it home-assistant pip3 install tensorflow
sudo docker exec -it home-assistant chmod 777 /config/tensorflow_setup.sh
sudo docker exec -it home-assistant apt-get update
sudo docker exec -it home-assistant apt-get install --assume-yes golang-go
sudo docker exec -it home-assistant apt-get install --assume-yes git
sudo docker exec -it home-assistant /bin/bash -c "export GOPATH=/root/go/ && go get github.com/ericchiang/pup"
sudo docker exec -it home-assistant apt-get install --assume-yes jq
sudo docker exec -it home-assistant sh /config/tensorflow_setup.sh
This allows me to run tensorflow, this allows me to connect HA to my MSSQL db for the recorder, allows me to run alexa media player, and installs some dependencies for a command line script I run in HA - most of these packages don’t seem to be available for alpine, so what am I supposed to do?!
option 1, don’t use hassos
Option 2, run them in separate docker instancee.
Like other have said there is something very wrong with zwave entity names after upgrading from 0.95.4 to 0.97.2. The entity IDs have changed a bit, breaking groups and automations.
For example, old name:
light.ge_14294_inwall_smart_dimmer_level_2
Became new name with an extra “_”:
light.ge_14294_in_wall_smart_dimmer_level_2
At least I think that’s the old-new mapping based on a single character difference. I can’t be sure.
Same with dozens more similar examples, breaking all kinds of automation.
Can someone explain what’s going on here? Or better how to recover to old names so I don’t have to spend many hours trying to figure out what old names map to what new names, and then looking for those names in various pieces of config and retesting my entire setup?
Don’t work tuya and smartlife on home assistant
Just go into the entity registry section of the configuration sidebar menu and edit the entity_id names there to the old names.
Yes, it’s a PITA but it’s better than going thru all of your automations and frontend config and changing them there.
Thanks I’ve reverted to prior version, but I’ll try upgrading again and giving that a shot later.
I’m pretty good about reading breaking changes though and didn’t see this one? Was it announced? I’m looking for some pattern to make sure I get the old-new name mapping right (appears like someone decided to change treatment of some character, like hyphen or underscore). And to understand cause / that this won’t keep happening with upgrades.
I’m not sure when things changed but there was some change having to do with “slugify” changing some invalid characters to underscores instead of just removing them.
It sounds like that’s what caught you.
I have added the latest dev version of the filter sensor as a custom component and it is working again.
How do I run them in a separate docker instance but still enable HASS to use that stuff?
I don’t know, which particular package? You install quite a few.