Home Assistant kan als standaard assistent in Android worden ingesteld

Home Assistant-gebruikers kunnen de nieuwe spraakassistent van de app instellen als de standaard Android-assistent. Ook zit de spraakassistent in de app zelf en komt er native ondersteuning voor Wear OS.

Gebruikers van het smartphoneplatform kunnen Assist, zoals de assistent heet, als de standaard digitale assistent van Android instellen, schrijven de makers. Dat is vergelijkbaar met hoe nu Google Assistant of Amazons Alexa kunnen worden opgeroepen. De functie kan daarmee worden opgeroepen via het vergrendelscherm of vanuit het thuisscherm door de powerknop ingedrukt te houden.

Om Assist te kunnen instellen, moeten gebruikers de officiële Home Assistant-app hebben geïnstalleerd. Die app krijgt ook een update waarmee het mogelijk is Assist overal vanuit de app op te roepen.

Home Assistant kondigde Assist eerder dit jaar aan, in wat het bedrijf 'het jaar van de stem' heeft genoemd. Home Assistant wil in 2023 meer aandacht besteden aan spraakbesturing. Eerder dit jaar bracht het daarvoor al een chatfunctie uit waarmee gebruikers hun verbonden apparaten met commando's konden bedienen. In april volgde al een eigen spraakassistent genaamd Assist en die is nu in Android te gebruiken.

Er zijn ook verbeteringen doorgevoerd in de bestaande assistent. Gebruikers kunnen nu via een UI-menu hun eigen triggers bewerken. Zo kunnen gebruikers bepalen welke spraakcommando's welke actie moeten uitvoeren. Dat was eerder al wel mogelijk, maar alleen via een yaml-bestand. Ook heeft de stemassistent nu volwaardige ondersteuning voor smartwatchplatform Wear OS.

Assist kan nog steeds in verschillende talen worden gedraaid, waaronder Nederlands. Er is voorlopig nog geen wake word, maar dat wordt volgens de ontwikkelaars de volgende stap.

Door Tijs Hofmans

Nieuwscoördinator

24-07-2023 • 07:59

79

Reacties (79)

79
79
38
10
0
35
Wijzig sortering
Zijn er tweakers met ervaring met de volledig lokale ondersteuning voor speech-to-text en text-to-speech? Hoe goed werkt dat?
Ik heb afgelopen weekend speech-to-text opgezet met behulp van de daarvoor beschikbare docker container:
https://hub.docker.com/r/rhasspy/wyoming-whisper
docs: https://github.com/home-a...ob/master/whisper/DOCS.md

Dit werkt best leuk, maar wat mij betreft nog niet snel genoeg (respons duurt 5 tot 15 sec). Ik moet wel zeggen dat dit te tweaken is door voor een ander model en/of andere taal te kiezen; hier zit zeker verschil in.
Ik draai het op een Synology DS220+, maar een lang verhaal kort: als je dit voor dagelijks gebruik zou willen inzetten zou ik aanraden om krachtigere hardware in te zetten. Desalniettemin is het absoluut de moeite waard om uit te proberen. Let er ook even op dat je de juiste entiteiten beschikbaar maakt voor de 'assist' functie, anders kun je deze niet aansturen... hoe hard je ook schreeuwt.

Voor text-to-speech gebruik ik nu de standaard Google TTS. Deze is als standaard beschikbaar, en er is geen ingewikkelde config nodig. In plaats van Google TTS wil ik op termijn nog wel de Piper add-on/docker container gaan uitproberen, maar ik wacht nog even tot de eerstvolgende release:
The upcoming release of the Piper add-on for Home Assistant 2023.8 will support 23 languages and over 70 different voices.
https://www.home-assistan...3/#piper-community-voices

[Reactie gewijzigd door JoostTheHost op 22 juli 2024 17:48]

Het werkt. Maar De spraak moet vertaald worden naar tekst. en die tekst moet 100% matchen. Als er achtergrond geluid is zoals muziek komen er fouten in de tekst en wordt het niet meer gematched.

Je kan wel additionele woorden (met veel voor komende fouten) aan identiteiten koppelen. Maar al met al heeft het nog niet de kwaliteit als bv. google.
Niet geweldig. Hij verstaat je vaker niet dan wel bij mij, maar ik ga er wel vanuit dat het ooit echt wel goed gaat worden.
Mijn eigen ervaringen uit het verleden (toen ik de google assistent op een orange-pi installeerde) was dat het toen niet zozeer aan de software lag maar vooral de hardware. In vergelijking met de google/nest producten had ik een degelijke microfoon maar geen microphone array en zat er erg veel ruis op (wat ik ontdekte bij het terugluisteren van een wav bestand via mijn laptop)

Nu weet ik jouw test-case en heb ik geen ervaring met die van Home Assistant maar de assistent presteert natuurlijk een stuk minder als de input niet van redelijke kwaliteit is.
Ik heb het met de ingebouwde microfoon van mijn telefoon en mijn laptop geprobeerd.
Dan lijkt me dat een minder groot probleem :). Thanks voor de toelichting
@WoutF vertelde laatst in de podcast dat hij er mee aan het knutselen is. Ook op het forum vind je tweakers die hiermee bezig zijn. Lokale s2t en t2s werkt in HA volgens mij via de Whisper en Piper addons. Voor een vlotte verwerking heb je wel wat meer rekenkracht nodig dan een raspberry pi.
TTS werkt prima, STT heb ik heel beperkt geprobeerd maar werkte m.i. niet beter of slechter dan die van Google, en Google is in Nederland al niet zo heel sterk
na wat?
na update? na betaling? na volgend jaar dinsdag?

[Reactie gewijzigd door dirk161 op 22 juli 2024 17:48]

Is een update op de app: https://play.google.com/s...sistant.companion.android
Change log: https://github.com/home-a...oid/releases/tag/2023.7.5

De feature waarover dit gaat:
https://github.com/home-assistant/android/pull/3589

Nog niet getest, maar lijkt me dus meteen te gebruiken, mits je via de app natuurlijk Home Assistant kan benaderen. Kan je doen via VPN, Cloudflare tunnel of abo nemen op Nabu Casa.

[Reactie gewijzigd door SMGGM op 22 juli 2024 17:48]

Belangrijkste is gewoon dat je de home assistant node kan benaderen over HTTPS met een geldig certificaat. Dus VPN of Cloudflare of abonnement zijn niet de enige opties. Handig om te weten voor de mensen die in willen stappen.
Precies, in mijn geval DuckDNS icm LetsEncrypt en een port forward. Was in een handomdraai geregeld, kost niets en online prima stappenplannen te vinden.
Precies dit heb ik ook, was mbv het stappenplan prima in te stellen. Wel krijg ik het idee dat deze oplossing door veel mensen als de "asjemenou-wat-doe-je-nou" oplossing gezien wordt - werkt wel maar totaal onveilig(?). Ik zie die mening vaak terugkomen, maar heb nooit een bevredigende verklaring kunnen vinden voor waarom dat zo zou zijn. Iemand een idee?

Edit: Dank iedereen, is mooi leesvoer zo geworden, ik ga er eens naar kijken!

[Reactie gewijzigd door svenvbins op 22 juli 2024 17:48]

Als er een keer een exploit is op home assistant die authentication bypassed (is er al eerder geweest) is het relatief eenvoudig om home assistant instances te vinden via bijv Shodan. Beter is om bijvoorbeeld iets met Cloudflare tunnel in te stellen, waarbij je je eigen IP tenminste niet exposed en heel makkelijk een Web Application Firewall in kunt stellen, en bijvoorbeeld heel de wereld behalve NL blockt. Dat scheelt al 90%+ attack vectors (al wordt er best veel scanning uit NL gedaan). Alleen niet vergeten voor je op vakantie gaat ook je vakantieland toe te voegen aan de allow list.

Er zijn nog meer opties om het nog beter te beveiligen, maar die zijn allemaal wel moeilijker. Daarnaast sowieso natuurlijk 2FA op je accounts in stellen, maar dat spreekt hopelijk voor zich
Op dezelfde machine die HA draait gewoon een wireguard VPN server opzetten (heel niet moeilijk met pi VPN of docker bijvoorbeeld) en je hebt al er al een probleem minder bij.
Heb je hierbij ook een geldig SSL geregeld? Ik gebruik het nu ook via een VPN maar die stap is me (nog) niet helemaal duidelijk..
even een domein regelen, lets encrypt DNS verificatie gebruiken ipv domein doorwijzing, dan kan poortje 80 gewoon dicht blijven en ben je voor 5 euro per jaar met lets encrypt (ivm domein) beveiligd. En je kunt het domein ook als hostnaam gebruiken voor alle eventuele servers onder hun subdomein. En als laatste ook eigen mail ipv een groot tech bedrijf mocht je dat wensen.

Ik gebruik zelf cloudflare DNS omdat de api hiervan makkelijk te gebruiken is. Bij de registrar verwijs je dus voor de nameservers naar Cloudflare, en daarna in lets encrypt dus de DNS challenge. Poort 80 kan dan als het goed is dicht blijven (in mijn geval staat ie open ivm web service die ik aanbied)

Alternatief is gewoon een cloudflare tunnel gebruiken voor je domein en die dus naar je eigen IP laten verwijzen. (zo simpel als bij DNS instellingen gewoon proxy aanzetten voor de A record) en dan bij cloudflare instellingen "force HTTPS" aanzetten zodat zij zelf de redirect al oppakken ipv bij jou thuis. Dan in je router een whitelist maken voor poort 80 (cloudflare -> host is nog http tenzij je een certificaat instelt maar is lastiger) op de cloudflare IP lijst en dan kan dus alleen materiaal via de cloudflare proxy door je firewall heen.

Vimexx is bijvoorbeeld best netjes qua prijs voor domein/jaar.

Als laatste voor je vpn handig (ook cloudflare) een DDNS script draaien die dus via de cloudflare api je IP aanpast mocht dit wijzigen. Zo staat in mijn vpn dus gewoon mijn persoonlijke domein en past het ip op de achtergrond binnen max 6min (elke minuut draait script, en indien ip overeen komt met de resolve van cloudflare geen aanpassing doorsturen, anders dus ip wijzigen voor de zone en TTL op 5 minuten).

een eigen domein naam kost letterlijk minder dan 2 biertjes per jaar, maar kan je erg veel nuttige dingen brengen :) (SSL TLS certificaat voor wireguard is niet nodig toch?)

Ik heb zelf een reverse proxy draaien binnen het DMZ. en in de (DHCP) LAN DNS server dus een "catch all" voor het domein inclusief alle vormen van subdomeinen naar deze ngnix reverse proxy op zijn interne IP. Dit zorgt ervoor dat zodra de wireguard verbonden is dus de interne ip's gebruikt worden. En wanneer niet verbonden er dus gebruik gemaakt word van de "publieke" DNS die ingesteld is op telefoon en zo dus het externe IP voor alle subdomeinen tevoorschijn komt. Ook heb je op de reverse proxy de opties om dus regels te maken wie wat mag benaderen als extra laag van beveiliging. Hier kun je dus een subnet (van je vpn bijvoorbeeld) opgeven welke site X mag benaderen. Zelfs bezoekers op je LAN (wifi...) kunnen dan niet bij je persoonlijke zaken komen terwijl ze misschien wel in het zelfde wifi zitten als je eigen telefoon/tablet/tv/vaatwasser/strijkbout.

Maar het is net hoe "veilig"/complex je het maken wilt. Hoe meer deuren hoe beter, maar als ze allemaal dezelfde sleutel hebben heeft het nog geen effect natuurlijk ;)
thanks voor de uitgebreide en zeer informatieve reactie!

Eigen domein e.d. Icm cloudflare en proxy heb ik allemaal al ingesteld gelukkig. En ook een vast IP O-)

Ik vind het belangrijk dat ik m’n services met een cert kan benaderen en het liefst ook via een tunnel. (Aantal dingen werken gewoon niet, zoals text-to-speak bij HA)
Zeker, VPN is een hele goede oplossing. Alleen moet je dan ook wel altijd een VPN actief hebben op je telefoon als je de companion app wilt kunnen tracken/optimaal gebruiken. Dat is de belanrgijkste reden waarom ik geopteerd heb voor cloudflare tunnel > vpn. Maar als je toch al die VPN draait of dat niet erg vind, of geen live tracking doet van de companion app... Idd!
Op mijn Android kan ik gewoon een icoontje maken voor wireguard in het 'pull down' menu waar ook je vliegtuigstand, rotatie etc zit en zo is ie in fractie van seconde aan gezet


Of gewoon altijd aan optie aanvinken bij de instellingen
Wanneer je een reverse proxy voor home assistant hebt staan die host matching doet, en je je home assistant domein niet publiek ergens neerzet, dan zal shodan het nooit vinden. Als je inderdaad puur en alleen een port forward doet, dan wel, maar dat is nooit handig om te doen met web applicaties. Altijd zorgen voor host name matching en dan zit je wel goed.
Zeker, zulke trucjes helpen al een hoop. Als ik echter op shodan zoek naar de http.title:"home assistant" vind ik 141,738 instances. Ik denk niet dat iedereen het zo begrepen heeft :)
Dat is overigens inclusief de DDNS domain, home assistant version, python version, etc. Precies wat je wilt hebben als er weer een keer een exploit is.
Wat ik bedoel is dat shodan aan zijn data komt door te scrapen. En dit scrapen doet shodan eigenlijk op dezelfde manier zoals Google, en natuurlijk op IP adressen en porten voor bepaalde applicaties.

Wanneer Shodan mijn IP zou scannen op mijn Home Assistant port, dan krijgt Shodan gewoon een 404 terug. Shodan zou nooit mijn Home Assistant URL kunnen weten, dus kan ook niet met de juiste host header verbinden met mijn IP. Uiteindelijk staat mijn Home Assistant open voor het internet, maar je moet dan wel mijn specifieke URL weten welke nergens op internet staat en enkel in mijn apps geconfigureerd zijn. Certificaten zijn gewoon wild cards, dus ook daar zie je geen common names voorbij komen.
Dat soort trucjes helpen wel wat maar daar heb je bijvoorbeeld weer dirbuster voor (of dirb op de commandline)

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 17:48]

Precies, dat is dus ook de reden dat ik alles via VPN doe. Niks naar buiten open, ook niet op HTTPS. Dat voorkomt alleen sniffing maar geen misbruik van exploits in de code.
ik heb net mijn certbot commando gesplitst. dat elk certificaat 1 website bevat.

Je kon aan mijn https (die ook bij https://ipaddress gegeven werd) alle reverse proxies terug vinden.
Dat is inderdaad een veelgemaakte fout die ik zelf in het verleden ook heb gemaakt. Je exposed meteen je alle applicaties die je hebt draaien. Een uniek certificaat per host of een wildcard is de beste manier ipv 1 cert en dan 50 common names er in :P
Issue in de supervisor waar je naar refereert was je in ieder geval ook vatbaar voor via Nabu Casa en eigenlijk elke andere vorm van internet facing toegang waar niet een VPN tussen zit.

Er kleven vanzelfsprekend altijd risico's aan iets aan internet hangen, maar die allergie specifiek naar port forwards heb ik nog nooit deftig onderlegd gezien.
Je kan geografisch iets in je firewall doen maar kwaadwillenden kunnen allicht ook gewoon overweg met NordVPN.
En als je zelf weg gaat vergeet je geheid dat je een jaar geleden een georestrictie op je home assistant hebt gezet.

Je moet (ook voor je gemoedsrust) ook niet vergeten dat je domotica voor verreweg de meeste mensen helemaal geen interessant target is...
Er zijn naar mijn weten ook helemaal geen praktijk voorbeelden van die eerder genoemde exploit die actief misbruikt is.

[Reactie gewijzigd door Polderviking op 22 juli 2024 17:48]

Het gaat er vooral om dat als je port forward, je gevonden gaat worden. Zie mn reactie hierboven: zomaar even 141k home assistant instances gevonden via shodan. Als je dan tenminste enkel matched op name, of niet je eigen port forward maar achter cloudflare gaat hangen, is de kans veel groter dat je niet gevonden wordt (mijn instance staat *niet* op shodan). Zeker als je die restricties ook nog in stelt in cloudflare/lokale firewall.

En via cloudflare kun je heel makkelijk via je account alsnog een extra land toevoegen, vanuit dat andere land. Het gebeurt mij elke keer weer namelijk :+
Oké.
Maar dat Shodan weet wat ik service vanuit huis dat zie ik niet onmiddelijk als een probleem.

En dat weet het ook weer niet heel precies als ik even mijn IP erbij haal, zal wel komen omdat er een proxy webserver tussen zit. (ook geen security keuze, ik wil gewoon alles wat ik service beschikbaar hebben op 80 en 443 maar heb maar één IP)

[Reactie gewijzigd door Polderviking op 22 juli 2024 17:48]

Zodra er een RCE (remote code execution) gevonden wordt in home assistant of een van de python libraries die home assistant gebruikt (let wel: de algemene aanname is dat de vraag niet is OF die er in zitten, maar *wanneer* die gevonden worden), dan wil je beslist voorkomen dat jouw instance op die manier makkelijk gevonden wordt voordat je je secrets kwijt bent of onderdeel wordt van een botnet. Een goed beveiligde reverse proxy kan al een hoop oplossen, maar bij een goede RCE gaat je dat ook niet helpen. Niet makkelijk gevonden worden is natuurlijk maar een klein deel van de security maatregelen die je helpen :)

Het gaat wel erg off topic nu voor het originele nieuwsbericht overigens, maar op oudere nieuwsberichten wordt gelukkig niet teveel gedownvote ;)
Beter is om bijvoorbeeld iets met Cloudflare tunnel in te stellen, waarbij je je eigen IP tenminste niet exposed en heel makkelijk een Web Application Firewall in kunt stellen, en bijvoorbeeld heel de wereld behalve NL blockt.
Dit is interessant. Als je nu van mijn-HA.mijndomein.nl -> mijnIP gaat, en je wilt zo'n tunnel maar je kent Cloudflare niet, waar moet je dan rekening mee houden? Domein verhuizen naar Cloudflare? DNS via Cloudflare? Kosten voor tunnel?
Ik ben niet heel actief op het forum, maar ik denk dat er voldoende over te vinden is in de home assistant thread :) Ik zal vast niet de enige zijn namelijk

Idd, je domain moet naar cloudflare (tenminste, je moet de cloudflare DNS instellen in je domain, dan kun je hem houden bij je huidige registrar), maar de tunnel functionaliteit is gratis. Voor alle niet home assistant dingen gebruik ik ook nog cloudflare access, waarbij je oauth via google kunt doen bijv. Voor home assistant werkt dit nog niet echt lekker, dus daar staat het voor uit.

Maar like I said, dit is de betere plek hiervoor: https://gathering.tweaker...er_keywords%5D=cloudflare

[Reactie gewijzigd door Loen op 22 juli 2024 17:48]

Kort samengevat: Bij je registrar verwijs je de nameservers naar die van cloudflare. In cloudflare regel je dan je DNS. Daar maak je een paar DNS records aan die naar jou homeassistant wijzen en zet je dat DNS record op 'proxied' en klaar is gratis kees.
Begrijp ik het goed dat al het verkeer dan door de tunnel van Cloudflare gaat? Sommige HA-dashboards hebben complete live-feeds van beveiligingscamera's. Dat is best wat bandbreedte om gratis aan de wereldbevolking aan te bieden!

Volgens mij mist er overigens wel nog wat belangrijks. Een stuk configuratie om het ip-adres af te schermen van verkeer buiten de 'proxied' tunnel om. Anders komt hij alsnog in crawlers als Shodan terecht en kan Mr. Robot met tools als Metasploit en een DNS-spoof module een request aan de server doen dat van het domein lijkt te komen alsof de proxy uitstaat.

Type het IP-adres van je thuisserver maar eens in shodan.io, als poort 80 of 443 openstaat, dan is er volgens mij sprake van schijnveiligheid.
Niet alle cloud integraties gaan dan werken.
Die vraag had ik ook en heb ik hier gesteld.

Heel veel antwoorden, maar werd mij uiteindelijk wel duidelijk.
Omdat je poorten beter niet kunt open zetten vanaf het internet naar je thuisnetwerk.. je router wordt dan zichtbaar en heeft een poort open staan voor mensen met slechte bedoelingen?
Wel krijg ik het idee dat deze oplossing door veel mensen als [onveilig] gezien wordt - (..) Iemand een idee [waarom]?
Op een gegeven moment komt je IP-adres in een IoT-zoekmachine als Shodan, plus dat je HA draait en welke versie.

Dan zie je eerst een paar, dan tientallen, en dan honderden verschillende ip-adressen per dag in je logs van mensen die in proberen te breken met brute force of gekke exploits die niet (meer) werken. Er komt een dag waarop er een zero day of een exploit in Home Assistant zit, en dan komen die honderden mensen snel terug om je computer te infecteren voordat je de update hebt kunnen installeren.

In het beste geval ben je dan onderdeel van een botnet zonder dat je het doorhebt. In het slechtste geval wordt je data gestolen of gegijzeld met ransomware. Vanaf daar kunnen ook andere computers in je netwerk makkelijker gehacked worden.
Port forwards naar je HA installatie zijn alleen onveilig, nu kan iedereen er bij.
Daarom kan je in HA ook MFA doen (TOTP of notify).
En als je er nog een hardend nginx voor zet zou ik niet weten wat hier onveilig zou zijn.
Daarom kan je in HA ook MFA doen (TOTP of notify).
Dat heb ik, maar als er een lek zit in HA (zoals de supervisor bug van x maanden geleden) dan kunnen ze er alsnog bij want je bent gewoon toegangelijk.
En als je er nog een hardend nginx voor zet zou ik niet weten wat hier onveilig zou zijn.
Daar ga ik niet aan beginnen voor een thuisnetwerk
Nginx proxy manager is gewoon een add-on in Home Assistant en dus simpel te installeren en configureren
Die nginx server heb je met een uurtje werk opgezet. Als dat je al teveel moeite is in ruil voor meer veiligheid, dan moet je niet raar opkijken als je ooit een keer gehackt wordt.
Dat past helemaal niet in hoe HA zichzelf nu positioneert in de markt, namelijk als een systeem voor iedereen. Opzetten van Nginx is misschien niet zoveel werk maar het creëert wel nieuwe interoperabiliteits problemen.
Inderdaad. Zo draai ik Home Assistant al jaren en werkt perfect 👌.
Persoonlijk heb ik een tunnel voor mijn apparaten via Wireguard en PiVPN. Port forwarding voor Wireguard, die alleen apparaten toelaat die bij mij geregistreerd staan via zelf gegenereerde QR codes. Alle apparaten die op deze manier verbonden zijn kunnen ook bij mijn Home Assistant, dus niet eens een HTTPS certificaat nodig en Home Assistant staat verder niet geforward naar buiten mijn lokale netwerk :D
Het liefst zou ik een abbo nemen bij Nabu Casa, maar 75 per jaar vind ik vrij flink voor wat je krijgt. HA is gratis, dus dan vind ik 75 per jaar om hem via internet te kunnen benaderen erg veel. Natuurlijk is een deel van het bedrag ook sponsoring van het project, maar zelfs een commercieel alternatief als Homey kost maar 3 euro per maand voor een all-in service.
Anoniem: 1322 @Ruuddie24 juli 2023 09:07
Je krijgt bij het abonnement ook eenvoudige 'google Assistant' koppeling en hun eigen Text-to-Speech:
https://www.nabucasa.com/config/tts/

HA is verder natuurlijk niet gratis en dit is inderdaad eerder een manier om het project te sponsoren.
Text-to-speech is leuk, maar ook best prima lokaal te draaien. Ik zou het juist onwijs interessant vinden om het meer resource-intensieve speech-to-text uit te besteden aan de Nabu Casa cloud.

Daar zou ik zonder twijfel voor willen betalen, en ik vermoed dat veel mensen er zo over denken. Dat zou wel eens voor een stormloop om de Nabu Casa dienst kunnen zorgen.
STT en TTS zitten allebei bij het abonnement inbegrepen. 130 talen en dialecten.
Hi Paulus/Balloob. Oh & wauw?! Dat is nieuws voor mij. In dat geval ben ik direct om. _/-\o_

Op jullie website zie ik hierover niets staan*? Of doel je met STT via Nabu Casa op de koppeling met Alexa/Google Assistant?


* als ik een suggestie mag doen: als eindgebruiker mis ik een beetje het volledige 'dit bieden we allemaal' plaatje op de Nabu Casa website. Er staan wel zaken opgesomd, maar echt helder vindt ik het nog niet. Misschien is het een idee om dit nog duidelijker op te sommen?
Precies dit, ik sponsor op deze manier het project.
Gewoon een portforward en zelf een certificaat installeren (Lets Encrypt of betaald) is ook niks op tegen hoor.

Dingen als extern hooks aanroepen werkt niet als je HA instace alleen lokaal (hetzij via vpn) te benaderen is.

[Reactie gewijzigd door Polderviking op 22 juli 2024 17:48]

Ja, laat maar. Jij hebt duidelijk de ninja-edit van de titel gemist.
na volgend jaar dinsdag?
Collega.
Nadat je je shift-toets gerepareerd hebt.

Maar serieus - moge deze beide posts snel naar -1 gemod worden, zodat niemand dit hoeft te lezen. :)
Is er ook een manier om deze op je Google Nest apparaten te gebruiken en daar de assistant van te vervangen of moet ik toch echt een ESP32 boxje gaan kopen? Als iemand hier iets voor weet hou ik me erg aanbevolen.
Het is niet iets dat je even aanzet, maar er zijn wel mensen die het voor elkaar hebben gekregen: https://hackaday.com/2023...ilt-to-run-custom-agents/
In mijn tienerjaren was ik hier zeker aan begonnen, maar met een baan en drukte wordt dat dus een ESP32 boxje :) Thanks!
Ik zou eventjes wachten tot er support is voor de esp32 devices met mic array ingebouwd. Duurt niet lang meer TM
Ik kan niet achterhalen of zijn PCB de microphone array en speaker van de Home Mini gebruikt of dat het losse elementen zijn.
Weet niet in hoeverre je andere apparatuur al draait die het kan, maar ik draai mijn HA in een Docker-container op mn NAS :)
Nu of na update? :)
Dit werkt nu al (net getest), maar bij mij werkt het anders dan op het filmpje: ik moet zelf eerst kiezen voor "speech-to-text" en ik moet op verzenden drukken. Mogelijk is dit een instelling die ik nog niet gevonden heb, maar op dit moment is het dus nog niet heel erg goed bruikbaar.
Voor iOS is het overigens mogelijk om "Hey Siri, Assist" de assistent op te roepen, als je een shortcut installeert (Waar de companion app je bij helpt, super eenvoudig) Hoe ik overigens de spraak assistent verder moet configureren ben ik nog niet uit :-D

Overigens gebruik ik gewoon de HomeKit bridge, waardoor siri native eigenlijk al je apparaten wel kent en ik eerlijk gezegd zelf nog geen nut voor Assist gehad heb.
Dat laatste werkt ook met Google Home, alle apparaten in Home Assistant zijn daarmee standaard beschikbaar. Werkt fijn met een Nest Hub waar je per ruimte de apparaten ziet, maar voor spraakbesturing is het wat rommelig omdat de standaardopzet ook de apparaten die uit Google Home komen weer vanuit Home Assistant maar Google Home stuurt..
Mooi dat dit kan, ik vind wel dat er makkelijk word gedaan over een port forward, natuurlijk is dit makkelijk in te stellen en zijn er de nodige stappenplannen te vinden op het internet. Ik vind dat de risicos niet goed worden overwegen.

laten we eerlijk zijn, in bijna 100% van de gevallen draait HA gewoon in hetzelfde vlan/subnet als de rest van de thuis apparaten.

Mocht je je HA installatie vanuit het internet beschikbaar maken, zou ik in ieder geval de volgende zaken overwegen:
  • Overweeg een "DMZ" netwerk met een reverse proxy, dit zorgt ervoor dat enige vorm van vulnerabilities in HA worden afgeschermd. Ook kun je met een portscan dan niet direct zien dat het om een HA installatie gaat. Voorkeur is een Apache, maar NGINX is ook een prima oplossing. Sommige routers hebben ingebouwde reverse proxies.
  • Bekijk of je alleen bepaalde IP adressen kunt toestaan op de reverse proxy, landen buiten europa bijvoorbeeld kun je afsluiten, in sommige gevallen zelfs beperken tot alleen Nederland + de IPs van de cloud providers zoals Google in dit geval.
  • Als extra beveiligingslaag zou je kunnen kijken naar certificate authenticatie, 1 certificaat per device zou voldoende moeten zijn.
  • uiteraard een geldig TLS cerificate zoals letsencrypt.
Even als toevoeging op bovenstaand, sommige Tweakers hier blijven hangen op een oude versie van HA vanwege compatibility issues. Zorg er in dat geval voor dat je geen port forward instelt.

Ik ga er met bovenstaand even vanuit dat meer en deel hier geen WAF of WAP thuis heeft draaien, ideaal zou zijn om dit bovenop de reverse proxy te draaien.

Laat het duidelijk zijn, niks is 100% veilig, maar door een aantal simpele maatregelen te nemen kun je dit wel tot het minimale beperken.

[Reactie gewijzigd door sebasmac op 22 juli 2024 17:48]

Ja, ook mijn HA draait in hetzelfde laag 2 segment als de rest van mijn woning. So what?
Wat draait er in dat VLAN? Wat APs, een oven, vaatwasser, Roomba en aanverwante 'zooi', etc. Een paar telefoons, laptops en een verdwaalde desktop. Daar zit werkelijk niets spannends op.

Wat is daar nou boeiend aan? Waarom zou ik dat tot jouw niveau willen beveiligen?

- Telefoons hangen aan elk netwerk dat we maar tegen komen. Bij de kapper, de McDonalds, etc.
- Laptops idem.
- IoT rommel (Roomba, vaatwasser, etc) hebben geen bereikbare poorten. Doen alleen tunnelen naar de cloud.
Of je draait een VPN server (bv. OpenVPN) thuis en zet alleen een willekeurige poort open voor die traffic. Gebruik een goede encryptie met certificates en laat de devices via de tunnel bij HA komen. Je zou dan zelfs de HA + nodes/peripherals op een VLAN kunnen laten draaien die alleen via de tunnel beschikbaar is. Men kan doen wat ze willen op die poort maar de VPN server gaat geen kick geven zonder correcte credentials.

OT: Dit is heel interessant! Ik gebruik de Google assistant liever niet dus dit lokale alternatief zou echt heel interessant zijn. Bovendien is de integratie met alle integrations/automations dan native dus ik verwacht dan een soepele gebruikservaring. Eens zien hoe dit zich gaat ontwikkelen, zeker ook met de opkomst van krachtige LLM implementaties waarbij speech-to-text een stuk betrouwbaarder wordt.
Nu de vraag of dit ook vanuit AndroidAuto werkend te krijgen gaat zijn. Nu met de GoogleAssistant integratie doet de tekst "Garage Aan" de deur open of dicht. Dit zou natuurlijk mooier kunnen.
HA is al in AndroidAuto (als app).
Het gaat om Voice als standaard, niet de app. Liever zit ik niet uit mn Navi, naar home, naar homeassistant naar rolluiken, naar garage te navigeren tijdens het rijden door een woonwijk.
Iemand enig idee of dit ook met iOS kan of dat dit in de pijplijn zit?
Ik denk eigenlijk niet dat dit snel gaat komen. Je veranderd de 'default handler' voor een bepaalde actie, en het kunnen instellen van handlers voor bepaalde bestanden, URL-formaten, of events is een van die zaken die bij OS-en als Android, Windows, of MacOS vrij modulair zijn geregeld. Zelfs zaken als de "embedded browser handler" (stel je hebt een login prompt in een app) zijn vervangbaar, dit was bij Windows een van die dingen waar IE nog "vast" zat maar in o.a. Win11 is dat vervangen. De systemwebview is nu vervangbaar.

Apple heeft een meer gesloten manier van dingen doen. Bepaalde zaken als files kan opzich wel, maar er zijn defaults waar je Apple niet in kan omzeilen (weet niet of het nog zo is, maar URL's in mails opende voor eeuwig in safari ondanks dat je eigenlijk safari niet/niet wou gebruiken). Zelfde voor encoded URL: een tel:// URL opent in de system dialer, en kan je niet in bijvoorbeeld Teams gebruiken zelfs al heeft je organisatie bellen-via-teams als beleid.

Zo geld het ook voor de voice assistant. Dat is een event. Vrij simpel in Windows, Android, en zelfs mogelijk in MacOS, maar in iOS? Als Apple niet wil dat het kan, dan kan het niet.
Yeeeees, mooi man.

Nu nog speakers in een strak jasje à la echo dot/home mini/noem maar op.

Want met rapberry pi's klieren heb ik niet zo'n zin in (en het ziet er niet uit).
Kan deze assistent meer dan home assistant en automations bedienen? Bijvoorbeeld antwoorden hoe oud random acteur X is of hoe laat de bus gaat?

Op dit item kan niet meer gereageerd worden.