Last year I purchased a ticket to a Broadway show in NYC. I refused to use their digital ticketing nonsense, and when I showed up at the box office just before showtime and said my phone wasn't working (for my own definition of "working") they just handed me paper tickets. So I have to believe every one of these companies must have a way of issuing tickets when people's phones "don't work."
It moves the app one notch back from mandatory, but that's still enough to be a real problem. That method is going to have very low capacity and if you lie about your phone being dead or elsewhere that might screw you over.
You have to learn to manage up as much as down. In other words convince your boss that what you're doing is the right thing to do. Might not work in all situations of course but if they respect you and you had time to show your value, they might surprise you by going your way.
> Even if your hardware doesn't support local APIs, there's a good chance someone has made an HA integration to talk to their cloud API.
And if they haven’t, you can pretty trivially write your own and distribute it through HACS (I’ve got three integrations in HACS and one in mainline now)
I love it! But my setup has a lot of sharp edges. It's a combo of things where the "standards compatible" way to connect to HA lacks things like camera control, by dastardly vendors like Chamberlain who basically killed HA support for spite, and finally, by having to use Google or Amazon for voice assistants.
My #1 wish would be for someone to build a HA-native voice assistant speaker. I'd pay $100 each for a smart speaker of the physical quality of the $30 Google Home Mini but which integrated directly with HA and used a modern LLM to decide what the user's intent was, instead of the Google Assistant or Siri nonsense which is like playing a text adventure whose preferred syntax changes hourly. I'd pay that plus a monthly fee to have that exist and just work.
Chamberlain can't change MyQ to get around the fact that HA can operate the switch in your garage with a simple controller attached to it. It is very annoying that they are anti-hacker though.
This M5 Stack ASR unit costs $7.50, and has a vocab of about 40-70 words. That's enough to turn on/off lights and timers. You might need to come up with your own command language, but all of the ASR is extremely local
That is probably a great and fun way to solve the problem for those with even a little free time.
Sadly for family reasons I sadly can't take on projects that require more than a few minutes, so I'm holding out hope for someone to bridge the gap between the "project boards that require writing a bunch of code to interface with Home Assistant and define all of its possible abilities and commands" and "dumb as a post Google thing that you just plug in" with a hardware device that is easy to connect to HA and starts out doing what the Google thing can do, but smart instead of stupid like the legacy voice assistants are.
For some reason the VibeVoice model from Microsoft (which is also able to clone voices and is also very good) has been deleted from GitHub 10 days ago even tough it was released under a MIT license. But this post shows that the cat is out of the bag for some time already now (post is from 2021) and we have to live with this technology.
there are many easy extant ways to do voice coding. many models are released without a “voice embedding” model but they are easy to recreate by passing the gradients through the soft prompt
Cloning the repo (running git clone on your computer) is enough because it makes a local copy. Forking merely makes a copy under your account on GitHub though which is not going to survive if they go on a deleting spree.
It generalizes to the formula r = -(n - 2)/2, so if we want a clock which is right every second, we could have a clock going backwards 43,199 the normal speed...
Another possibility with this idea is to have a normal clock but with the 3 and the 9 numbers inversed (going backwards at normal speed). Such a clock will be right 4 times per day.
They would ban the developer, or its key or whatever and ask him to register again and not do this again. They won't allow any workaround like this to exist because then the whole system has no purpose, they need to have control.
I think banning developers just for giving users freedom would be bad for PR. Google would have to admit that they are fighting their own users, not fighting malware.
It wouldn't be any worse PR than the current one. They'd use the same argument to ban that guy's app as they use now to ban sideloading. That it's not secure and it's a protection of users to ban it.
This is "one weird trick" thinking, but there's no tech-based counter if the device manufacturer is determined enough.
reply