Wow that was quick ! Honestly, having that would help a ton. It may somewhat of a niche feature, but this would make a lot of users of my card happy, as it would make certain awkward workarounds (especially around wildcards and dynamic history list population) a thing of the past. Gonna try this asap.
Edit: I tested it and it works great. I commented my rationale about why I think this should be merged into Core on the PR. Thanks so much for drafting this, I’ve been waiting for such an API call for a long time.
It’s an advanced history panel basically. It presents users with an interactive way to create their history layout, and in order to do this, users are given a list of entities that are recorded in the database (and only those). While the hass object obviously gives a list of all entities in the state machine, there is no way to query if an entity is actively being recorded in the database (ie. not excluded by the user), as far as I’m aware.
Not quick and easy necessarily, but free. You can create your own self-signed certificates, with the caveat that you then need to install the signatures to both the supervisor and core as trusted sites. HA has started reporting these changes as manual modifications, thus breaking official support. Also, it’s a pain because EVERY upgrade of either supervisor or core requires re-installation of said signatures.
I’ve lobbied for a text field in settings (advanced) allowing one to place signatures there, which HA would import to trusted – no luck so far. I’ll probably try to bring it up again during the next “why the hell…?” event.
wth rarely leads to anything anyway. Big fuss about nothing.
So you are saying that this Self-signed certificate for SSL/TLS - Home Assistant 中文网 does not work? Looks like a permanent and update safe approach. Wanted to try it
tomorrow but will not bother if i have to redo after updates.
Same experience here: after the update google assistant exposed entities are no longer what they were before. Next to that the list of exposed entities is lost after the update, I’ve encountered 2 more issues:
1 - aliases do not seem to be exposed any more to the google assistant: asking my google home to switch on a light by using the light’s alias results in “Ik begrijp het niet”, whereas if I ask it to switch on the same light using the entity’s name, the light is switched on.
2 - i used to have a helper (input_boolean) exposed to the google assistant, after the update I no longer find this helper in the list of items I can expose. Is this no longer supported?
Yes, that should work just fine for accessing home assistant (in fact, my configuration uses that). Disregard my comments, those were for getting HA to trust self-signed certs so HA-sourced traffic can use ssl locally. If you’re targeting commercial devices with their own certs, those should already be trusted.
It sounds like performance of the internal DB has really improved since ‘back in the day’ when I moved to MariaDB in a Docker container. I would love to use a unitary backup solution that would include the DB primarily for situations where bugs in new releases have me downgrading.
There is a post below which says an input_boolean helper is not exposed either, probably set in YAML.
I’ve looked at the ffmpeg integration and that also does not offer a unique_id option, and probably many more…
I do use a camera with ffmpeg to access the feed on a Google Nest Hub. If I will roll to 2023.5.X I will loose probably that camera on the Nest Hub.
It is a bit controversial adding the devices this way to any voice assistant, if it has unique_id or not. First all the HA integration should support the unique_id option, by default, being yaml or not.
Does anybody know how I can list all my entities which hasn’t got a unique_id?
You can try the expose entity button in bottom right and manually add the entity and then expose it. I picked this up in the beta with my limitless led lights which all disappeared from google but they fixed it and they are all working again now.
Thanks for this, they need to make it an actual card now maybe cuz kind of annoying you have to refresh the page to make it show up, I got kiosk mode enabled so on mobile there really is no way but this to use the assist mic button.
Love the idea of this new update, localized voice recognition. Has been a long time coming, however the biggest issue I had with this update is noticing that none of my Alexa integrations were enabled and had to re-enable each device manually. Perhaps an ‘add all option button’ and make re-integration possible. The only thing that really saved my ass in all of this is i had a Hubitat running alongside my HA and all devices were tied to it. Alexa is also tied through Hubitat, so I never lost integration really. I did however plug them all back into HA, kind of a pain the ass really. That’s expected with ground breaking updates though.
Phew - glad someone else has this, because I have not one single clue as to what to do about it. Downgraded HA back to prior version and all good again.
My LocalTuya is broken since the 2023.5 update. I see a couple of others having issue with LocalTuya also but no addressing of the issue as far as I could find.
Any news on a fix or workaround for localTuya? Thanks in advance?
Tried to install Whisper add-on on latest 2023.5.2 but after changing language to sk (with default tiny-int8 model) the add-on started reporting “This add-on has no configuration” and I can’t modify config anymore or start the add-on.
Add-on uninstall and re-install did not helped…
Add-on log seems fine:
s6-rc: info: service s6rc-oneshot-runner: starting
s6-rc: info: service s6rc-oneshot-runner successfully started
s6-rc: info: service fix-attrs: starting
s6-rc: info: service fix-attrs successfully started
s6-rc: info: service legacy-cont-init: starting
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service whisper: starting
s6-rc: info: service whisper successfully started
s6-rc: info: service discovery: starting
INFO:__main__:Downloading FasterWhisperModel.TINY_INT8 to /data
INFO:__main__:Ready
[07:17:31] INFO: Successfully send discovery information to Home Assistant.
s6-rc: info: service discovery successfully started
s6-rc: info: service legacy-services: starting
s6-rc: info: service legacy-services successfully started
P.S. After host reboot and removing OpenAI pipeline the add-on has started and config is working.
But now in the HA Pipeline I can only choose English language instead of Slovak which was configured before Whisper add-on installation.
Seems that even Whisper config now uses Slovak Base model the HA Pipeline refuses to select other languages except English (my languge in HA general settings).
Would it be possible to use my ESP32 based “AtomU ESP32 Development Kit with USB-A” device with a microphone but without any speaker for local Voice Assistant? Already have an MPD speaker in the same room for playback of Google TTS messages so I hope it could be combined, but not sure how to assign audio devices to the pipeline stages…