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.
1 Like
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?
3 Likes
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.
I am also interested.
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.
That’s my motivation for wanting to move back and I’m okay if it has to be a clean database. I will have to give this another read sometime soon: Migrating from MySQL (mariaDB) back to sqlite - #8 by mneuron
2 Likes
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?
1 Like
My routines didn’t break. They all still work after all the entities came back
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.
3 Likes
Thanks for that! I will give it a go once updated.
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.
Your other option is to wait or build an ESP based microphone and speaker or VoIP device. Http access is going to be added to the app see:
1 Like
Likewise, Alexa lost all access to existing devices after the upgrade. I restored from backup to previous version as a short term fix.
1 Like
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…
But if you’d read the thread you wouldn’t have needed to downgrade.
Isn’t Local Tuya a custom component? If so, this isn’t the place to ask for support.
Not sure if this thread is right place to ask, but I have been wondering for a long time about this HA Voice thing that promised “you can control HA using your own language!”. So, my native language is Finnish, and I have both Alexa and Google speakers that understand english but not finnish (Google text-to-speech speaks quite fluent finnish though). So, I was wondering if it was possible to use my existing smart speakers (Alexa or Google Nest Hub or both) with HA (which has Finnish language support) so that instead of activating Alexa or Google, I could speak Finnish to either of those speakers and then HA would handle the rest?