Interesting, so I guess those API-calls are just fetching the cached calendar on my HA Yellow. Wonder why it’s so slow, but I guess there’s not much to do about that then. :(
Interesting, so I guess those API-calls are just fetching the cached calendar on my HA Yellow. Wonder why it’s so slow, but I guess there’s not much to do about that then. :(
Not exactly. My main use-case here is for my girlfriend and me to see each both of our calendars in one place, and HA had support for it and is a web portal we both have access to. To do automations on them is secondary.
Currently, whenever I look at the calendar control panel it will load for a bit while pulling all the calendars, and sometimes timeout and not show anything. I believe this to be because it’s pulling from Fastmail / iCloud everytime and might be rate limited or just have a poor connection, this wouldn’t be an issue if the calendars were stored on the instance itself because then it would only miss the latest entries.
The idea that maybe I can self-host an app that does it is that if HA can’t do the caching, then maybe this self-hosted app can and it wouldn’t matter that HA fetches it remotely each time since the remote is on the same local network. Having them as separate calendars is still desirable since that gives some additional information.
They already have something kinda like this. All public wifis require that you sign in with phone number and SMS-verification. It might not be as air-tight as whatever the article is about (like a chad I only read headlines), but in practice it seems pretty darn tight IMO.
This is so cool, first MQTT-based sensor I’ve set up. Already had a broker set up with HA, but how can HA automatically discover which topic to listen to, know the vendor name and how to interpret all the data?