where is a long lived access token I generated and this is my automation
alias: Shark IQ - Upstairs
description: Restarts the Shark IQ Integration if the Upstairs Shark Is Unresponsive
trigger:
- platform: state
entity_id:
- vacuum.r5_d_floor
to: unavailable
for:
hours: 0
minutes: 5
seconds: 0
condition: []
action:
- service: shell_command.shark_restart
data: {}
mode: single
Then when I run the automation I see the following in the logs:
Logger: homeassistant.components.http.ban
Source: components/http/ban.py:125
Integration: HTTP (documentation, issues)
First occurred: 8:35:20 AM (3 occurrences)
Last logged: 8:44:25 AM
Login attempt or request with invalid authentication from localhost (127.0.0.1). (curl/7.79.1)
It seems like it does not like my token for some reason but I did create it so I’m not sure what’s going on. Maybe there’s something obvious the group can see that I cannot?
EDIT: Now that I’ve played with this a bit more… the trigger doesn’t appear to be working for some reason. This automation seems to work fine if I manually run it, but the trigger doesn’t appear to fire… so something is a bit off.
You shouldn’t need an access token. If you just use the reload config command from HA, it works by specifying the associated devices/entities.
Here’s what I just got working for my Shark vacuum based on input from others above.
id: '1659564071500'
alias: Reload Shark Integration If Unavailable
description: ''
trigger:
- platform: state
entity_id:
- vacuum.sharkbait
to: Unavailable
for:
hours: 0
minutes: 5
seconds: 0
condition: []
action:
- service: homeassistant.reload_config_entry
data: {}
target:
device_id: 3f155d4bd130b7d171b9545ac98205a0
mode: single
Note, I created this through the UI in HA, so it just looked up the device ID for me.
Thanks, I wondered about that too, but it’s odd to me that the front end shows it as “Unavailable”. I updated the casing to lowercase. I’ll watch it and see how it performs now.
It really is odd that it’s uppercase on the front-end but lowercase on the back-end.
It’s called separation of concerns: internal state and display should be handled separately. Simple case: The internal state for a weather condition could be sunny, but if you set your language to some non-English language, you’d want that translated. Same for unavailable. In fact, an internal state doesn’t even need to be text. Could well be that it’s just a number or ID. So, in the end, a state trigger works by using the internal state, and not how it’s displayed.
No. For integrations that are purely in YAML and do not create a config entry on startup this service does nothing.
It also won’t work for integrations that are configured in YAML but create a config entry (at least not hte way you want it to). There are some integrations that do this. But when they do that they use your YAML config to define the config entry on startup. So like if you set a url field in the YAML then there’s probably a corresponding url field in the config entry.
For integrations like this when you call homeassistant.reload_config_entry it sets up the integration all over again starting from the config entry. But it won’t do the extra step it does at startup where it reads in your YAML and uses that to define the config entry. It doesn’t look at your YAML at all.
When it comes to YAML configuration, the things listed on Developer Tools → YAML are the only things that support reloading your YAML without a restart. For everything else you must restart HA.
Thanks for that. It’s a pity, but at least I can stop my playing and trying around.
Technically, I don’t understand, why the yaml could not be reloaded and partially re-parsed for such integrations, but most probably only, because no one has implemented it.
No problem, there is now actually an easier way to reload integration, you can just call a service with one of the entities that the integration is using. For example
That I need to do an automation with a script, the problem is that since 2022.8 the Switchbot bot doesn’t work without reload the bluetooth integration in my RPi4, but the bluetooth integration doesn’t have any entity in there…so I have to reload with the older one method below?
config/.storage/core.config_entries no longer seems to exist, but you can get the url by opening your browser development tools and watching the network tab while manually performing the reload you want. If there’s a “proper” way, I couldn’t find it, and this way is pretty easy.
