0.104: Sentry, Signal Messenger, IntesisHome, Sure Petcare, KEF

I’m not the one comparing those incorrectly.

There is literally a button in the entity registry page that says something like “show disabled entities”…

So HA is allowing disabled entities to be “hidden” which is in a completely different context than being “hidden” in regard to being hidden from the frontend.

And that’s perfectly OK. That’s what I want to have happen. that’s the way it worked in the last version.

But what you are missing is what if the situation is “we don’t know this device so we don’t yet know if we want it”?

I don’t expect the computer to know that. The way it is right now I don’t have enough control over my computer to tell it what I want it to do with the entity.

Do the guidelines say we aren’t ever allowed to delete automatically created entities? If not then I should have the ability to delete an entity based on my own needs even if the end result is that the entity might get re-created again the future. That should be for me to decide how I want to handle the entities in my system.

@frenck i think you dont understand the problem really.

its like this:

you get guests, lets say 10 a day.
they all create a new entity.
because most guests are 1 timers you disable most off them at the end of the day.
every day there are 10 more added, and the list grows.
after 2 weeks you realise that 1 of the guests will be a regular and it doesnt need to be disabled
but the list is already at 140 disabled entities, so you have a hard time looking through them to find the right 1.
after 4 weeks its almost impossible to find the right 1.

when there is an option to delete the entities, then the list of disabled entities stays short.
the entities deleted at the end of the day from guests that never show up anymore, stay away forever.
the entities from the guests that return, will show up again. and thats good, because at the end of that day you can reevaluate if it will be a regular guest, which gets an entity to stay or if you delete it again.

allthough i dont have that problem, i can relate to it very well. because i also get lots of guests that are added to my HA automaticly.

3 Likes

I do understand the problem, adding is the same as removing, the integration can decide to not create the entity because of (age, last time seen device, no longer available) and remove it from the registry.

You are right, since this integration leveraged the registry, my bad.

The UniFi integration creates items from the active clients list from UniFi and if an entity exists in the registry also from the known but not available clients list. I don’t remember if it is a 1-2 day limit before active unavailable clients are moved to the known but unavailable clients list. So the thing would be to remove the entity registry entry when the client is in the latter list, then it would not pop up again until the client is near your network again.

Probably with the rewrite of UniFi integration to use push notifications, these lists would only be reloaded when the integration starts up so should be even simpler than previously where all relevant entities where recreated on every poll.

Has anyone had any issues with their zwave network not starting. I think I’ve narrowed it down to a timeout issue but I can’t figure out what changed to cause this. I have zwave working for several years now. I have HASS installed in Docker on a Synology DS1515+. The WAF is starting to decrease…

2020-01-24 06:11:36.968 Always, OpenZwave Version 1.4.3452 Starting Up
2020-01-24 06:13:24.284 Info, Setting Up Provided Network Key for Secure Communications
2020-01-24 06:13:24.284 Warning, Failed - Network Key Not Set
2020-01-24 06:13:24.284 Info, mgr,     Added driver for controller /dev/ttyACM0
2020-01-24 06:13:24.286 Info,   Opening controller /dev/ttyACM0
2020-01-24 06:13:24.286 Info, Trying to open serial port /dev/ttyACM0 (attempt 1)
2020-01-24 06:13:34.289 Info, Serial port /dev/ttyACM0 opened (attempt 1)
2020-01-24 06:13:34.289 Detail, contrlr, Queuing (Command) FUNC_ID_ZW_GET_VERSION: 0x01, 0x03, 0x00, 0x15, 0xe9
2020-01-24 06:13:34.289 Detail, contrlr, Queuing (Command) FUNC_ID_ZW_MEMORY_GET_ID: 0x01, 0x03, 0x00, 0x20, 0xdc
2020-01-24 06:13:34.290 Detail, contrlr, Queuing (Command) FUNC_ID_ZW_GET_CONTROLLER_CAPABILITIES: 0x01, 0x03, 0x00, 0x05, 0xf9
2020-01-24 06:13:34.290 Detail, contrlr, Queuing (Command) FUNC_ID_SERIAL_API_GET_CAPABILITIES: 0x01, 0x03, 0x00, 0x07, 0xfb
2020-01-24 06:13:34.290 Detail, contrlr, Queuing (Command) FUNC_ID_ZW_GET_SUC_NODE_ID: 0x01, 0x03, 0x00, 0x56, 0xaa
2020-01-24 06:13:34.291 Detail, 
2020-01-24 06:13:34.291 Info, contrlr, Sending (Command) message (Callback ID=0x00, Expected Reply=0x15) - FUNC_ID_ZW_GET_VERSION: 0x01, 0x03, 0x00, 0x15, 0xe9
2020-01-24 06:13:35.294 Error, contrlr, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-01-24 06:13:35.295 Detail, contrlr, Removing current message
2020-01-24 06:13:35.295 Detail, contrlr, Notification: Notification - TimeOut
2020-01-24 06:13:35.296 Detail, 
2020-01-24 06:13:35.296 Info, contrlr, Sending (Command) message (Callback ID=0x00, Expected Reply=0x20) - FUNC_ID_ZW_MEMORY_GET_ID: 0x01, 0x03, 0x00, 0x20, 0xdc
2020-01-24 06:13:36.296 Error, contrlr, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-01-24 06:13:36.296 Detail, contrlr, Removing current message
2020-01-24 06:13:36.296 Detail, contrlr, Notification: Notification - TimeOut
2020-01-24 06:13:36.297 Detail, 
2020-01-24 06:13:36.297 Info, contrlr, Sending (Command) message (Callback ID=0x00, Expected Reply=0x05) - FUNC_ID_ZW_GET_CONTROLLER_CAPABILITIES: 0x01, 0x03, 0x00, 0x05, 0xf9
2020-01-24 06:13:37.297 Error, contrlr, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-01-24 06:13:37.297 Detail, contrlr, Removing current message
2020-01-24 06:13:37.297 Detail, contrlr, Notification: Notification - TimeOut
2020-01-24 06:13:37.298 Detail, 
2020-01-24 06:13:37.298 Info, contrlr, Sending (Command) message (Callback ID=0x00, Expected Reply=0x07) - FUNC_ID_SERIAL_API_GET_CAPABILITIES: 0x01, 0x03, 0x00, 0x07, 0xfb
2020-01-24 06:13:38.298 Error, contrlr, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-01-24 06:13:38.299 Detail, contrlr, Removing current message
2020-01-24 06:13:38.299 Detail, contrlr, Notification: Notification - TimeOut
2020-01-24 06:13:38.299 Detail, 
2020-01-24 06:13:38.299 Info, contrlr, Sending (Command) message (Callback ID=0x00, Expected Reply=0x56) - FUNC_ID_ZW_GET_SUC_NODE_ID: 0x01, 0x03, 0x00, 0x56, 0xaa
2020-01-24 06:13:39.299 Error, contrlr, ERROR: Dropping command, expected response not received after 1 attempt(s)
2020-01-24 06:13:39.300 Detail, contrlr, Removing current message
2020-01-24 06:13:39.300 Detail, contrlr, Notification: Notification - TimeOut

That’s going to be Synology cutting off access to the USB adapter.

Hmmm…I’ve never had any issues prior with the zwave dongle. I did have to reboot the NAS I wonder if that did something to remove the drivers?

Not sure I don’t use Synology, prefer to keep HA running on a separate system from my NAS.

It probably got renamed to /dev/ttyACM1

I tried that last night and again during my lunch break. When I change it the ttyACM0 to ttyACM0 I get errors messages in the logs. When I change it back to ttyACM0 it seems to load and I can see the nodes in my HASS instance. It’s just not showing the friendly names or the status. I pasted a screen shot of the frontend.

edit: I aslo tried to load the drivers for the zwave and zha dongles and I get the same result.

image

What drivers are you trying to install? And where?

It’s a package that you install manually. I had to use it when adding zigbee when I migrated from Wink.

Documentation: https://khaz.me/using-a-z-wave-or-zigbee-stick-on-synology-dsm-for-use-with-homeassistant-and-docker/
Packagae: http://www.jadahl.com/drivers_6.2/

Interesting.

I don’t think I’m following you here…

you seem to be saying that there is the ability to actually delete entities from the entity registry that have been automatically created by the unifi integration (or any integration that does the same thing).

But everybody’s experiences as related in this and other threads seems to be that you don’t have the ability to ever delete those entities from the entities page.

Which way is it supposed to be?

And to add another layer to this onion…

I just went back to the entities page and realized that the switch I mentioned above that toggles between showing and hiding entities from the entities list is now gone.

With the toggle now gone how are we supposed to be able to show the disabled entities later on if we wanted to re-enable them which is supposedly the solution to the problem?

nevermind…I found it.

it’s hidden in the little “filter” icon on the far right of the search bar.

The new path was based on the ZHA\Zwave combo controller. I moved the Zwave controller to a new usb slot and everything came back up…I guess that usb slot isn’t working properly.

Looks like the device path has changed which caused the xml to change. Now I’m working on getting the new xml to be able to read the old xml’s information so I don’t have pair all my zwave devices back.

zwave:
  # usb_path:  /dev/ttyACM0
  # usb_path:  /dev/ttyACM1
  # new_entity_ids: true
  usb_path:  /dev/ttyUSB0

So I updated hassio fron 0.104.2 to 0.104.3 and now I have a problem with my Hue
I get the error: Unable to reach bridge. All entities are unavailable.
Have restart several times but still the same. Want can I do?

I opened an issue a while back, no pick ups for it yet. https://github.com/home-assistant/home-assistant-polymer/issues/4235

Is it just my impression or configuration check got way faster and better? Also I noticed that now, before a restart you check the configuration and does not restart if it is invalid, is that correct?

Correct, it gets some improvements along the way. But there is a failsafe built in. When the config is bad, you wont be able to do a soft restart/reset from the GUI until those are fixed.

2 Likes