Software-update: Home Assistant Core 2021.3.0

Versie 2021.3.0 van Home Assistant Core is uitgebracht. Home Assistant Core is een opensourceplatform voor home-automation dat draait onder Python 3. Het draait via Hassbian op een Raspberry Pi 3 of een Linux-, macOS- of Windows-computer. Het ondersteunt het detecteren van apparaten, zoals Philips Hue, Belkin WeMo-schakelaars, Mr. Coffee-koffiezetapparaten, de slimme schakelaars van IKEA en het mqtt-protocol. Daarnaast kan het waar mogelijk deze apparaten aansturen en automatisering toepassen. Voor meer informatie verwijzen we naar deze pagina en ons eigen Forum. Deze uitgave bevat onder meer een nieuwe Z-Wave-integratie, er is ondersteuning voor Python 3.9 toegevoegd en de applicatie is beter geworden in het herkennen van apparaten op het netwerk. De volledige release notes zijn hier te vinden, dit is de aankondiging voor deze uitgave:

2021.3: My Oh My

Home Assistant Core 2021.3! And my oh My Home Assistant! I’m super excited for this release! 13 Brand new integrations! Z-Wave JS is moving forward with an almost insane development speed; thank you all for jumping into it as well!

For me, this release is about two things. My Home Assistant and some super slick new UI features for everything related to service calls. What it is; is explained down below, but both are just a leap forward in: making things easier.

Versienummer	2021.3.0
Releasestatus	Final
Besturingssystemen	Scripttaal
Website	Home Assistant
Download	https://home-assistant.io/getting-started/
Licentietype	GPL

Reacties (44)

Mijn wachtwoord voor mqtt was "1234" .
Ik kreeg nu gelukkig een melding dat mijn wachtwoord wat ik ooit had ingevoerd om te testen nog steeds gebruikt werd.
Alle webinterfaces van mijn sonoffs , shelly's en dsmr reader opengegooid. Wachtwoord aangepast en in 5 minuutjes alles weer draaiend met een veilig wachtwoord. Ik ben blij dat de heren van Home Assistant security serieus nemen.

Het gezeur om niet veilige wachtwoorden (HaveIbeenPwnd Check) mogen ze meteen uitzetten of een optie geven om het uit te zetten. Ik begrijp wat ze hiermee willen zeggen maar als ik op mijn intern netwerk, wat extern niet te benaderen is, een easy wachtwoord gebruik dan is dat mijn keuze.

Dan hoef ik geen reminder elke x uur.

[Reactie gewijzigd door Raven__NL op 4 maart 2021 19:26]

De makkelijkste manier om van de meldingen af te komen is goede wachtwoorden te gebruiken.

Ik zie nu op meer plaatsen mensen klagen hier over, maar het verbaasd me dat mensen die bezig zijn met zaken als Home Assistant überhaupt gekraakte wachtwoorden willen gebruiken. Ik vind het een hele goede toevoeging aan het systeem. Het forceert bewustwording van het gebruik van slechte wachtwoorden.

Je hoeft overigens echt niet zo’n ‘headbash’-wachtwoord te gebruiken. “Wortel9630!” is waarschijnlijk al goed. (Disclaimer: heb mijn voorbeeld niet gecontroleerd)

Het feit dat je HA niet vanaf het internet bereikbaar is, wil niet zeggen dat een willekeurig stuk malware in je netwerk er niet bij kan of misschien een gehackte ‘slimme’ koelkast/wasmachine/thermostaat/deurbel/hue bridge/enz.

Ik ben persoonlijk van mening dat al je wachtwoorden gewoon minimaal ‘best sterk’ moeten zijn.

Ben ik niet echt met je eens. Er zijn genoeg mensen die isolatie hebben op netwerk niveau. Mijn internet facing apps zitten in ander vlan, en er is geen connectie mogelijk naar mijn LAN. Dus waarom een sterk wachtwoord voor mijn HA, waar ik mijn lampjes en sensors kan uitlezen en besturen.

Geef mij gewoon de keus om die melding te verwijderen.

Ongeacht of je je lokale netwerk hebt gesegmenteerd, en je firewall goed hebt ingesteld,?is het gebruik van wachtwoorden die ‘gehacked’ zijn gewoon geen goed idee.

Het feit dat je een goed tuinhek hebt, een doolhof hebt tot aan je voordeur, wil niet zeggen dat je die voordeur dan maar van een flutslot kan voorzien.

En let wel. We hebben het hier over een wachtwoord. Het verbaasd me op meerdere vlakken dat juist de mensen op dit forum zaken roepen als:

‘Het gaat maar om de bediening van een paar lampen’, ‘hij is niet vanaf het internet bereikbaar’, of ‘ik gebruik toegewijde vlans’, enz enz

Naar mijn mening is niks een valide reden om dan maar een wachtwoord te gebruiken dat op de ihavebeenpowner lijst staat.

Uiteraard mag iedereen z’n eigen visie hebben hierin, en uiteraard is de effectieve kwetsbaarheid erg verschillend per omgeving, maar het gebruiken van een acceptabel wachtwoord is nou niet echt veel moeite.

De recente beveiligings problemen in de plug-ins van HA hebben wel laten zien dat alles mogelijk is. Gewoon geen slechte wachtwoorden. Punt.

Ik begrijp het helemaal wat je zegt.
Maar laat die keuze aan de user zelf over.

Dan erbij de wachtwoorden worden plain text opgeslagen en zijn zichtbaar onder de addon settings.
Dus wat heeft dit voor een zin als ze al toegang to mijn intern netwerk hebben gekregen?

Nu forceren ze het ook elk uur of 2uur staan er weer een x aantal notificaties in je bar.

Dat stukje van de wachtwoorden worden plain tekst opgeslagen ligt toch ook weer echt aan jezelf .
Die kun je ook in secrets.yaml verbergen.

Klopt wat @Gimme aangeeft.

EN

De wachtwoorden staan in plain sight in je add-on configuratie box.

Mocht iemand toegang verkrijgen tot mijn intern netwerk dan heb ik andere zorgen dan dat iemand mijn influx/smb wachtwoord weet . Waarschuwen is goed maar blijven 'spammen' met die melding is een beetje overdreven. Dat ze maar een optie erin bouwen om het te negeren.

[Reactie gewijzigd door Raven__NL op 5 maart 2021 10:46]

Daar staan je wachtwoorden vervolgens ook gewoon in plain text in. Er waren wat encryptie methoden voor de secrets file, o.a. een keyring, maar die zijn sinds deze release niet meer mogelijk. Zou goed zijn als daar wat voor terugkomt, ook gelet op het security issue van een tijdje geleden waarbij alle HA bestanden, incl. secrets.yaml, in te zien waren.

'Wortel9630!'

Dit zijn van die wachtwoorden met verplichte hoofdletter en cijfer en speciale teken.

Dat houdt dus in dat je op minimaal 3 plekken in het wachtwoord minder keus aan tekens hebt (vanwege de verplichting).

Wat wiskundig gezien toch simpelweg minder variabelen opleverd en dus een grotere kans om via brute force geraden te worden.

Daar geloof ik niets van, ware het alleen al omdat je alphabet uitgebreider is.

Dat is nochtans simpel aan te tonen met een voorbeeld.

We stellen een wachtwoord samen met volgende regels:

• Max 5 tekens
• Letters: a-z (26) + A-Z (26)
• cijfers: 0-9 (10)
• Speciale karakters: !@#$%^&* (8 )

Het totaal aantal combinaties = ( 26 + 26 + 10 + 8 ) ^ 5 = 1.680.700.000‬.

Nu stellen we een wachtwoord samen met de verplichting om het 'veiliger' te maken:

• Max 5 tekens
• Letters: a-z (26) + A-Z (26)
• cijfers: 0-9 (10)
• Speciale karakters: !@#$%^&* (8 )
• Minstens 1 Hoofdletter.
• Minstens 1 cijfer.
• Minstens 1 speciaal teken.

Nu hebben we een totaal van combinaties = (( 26 + 26 + 10 + 8 ) ^ 2) * 26 * 10 * 8 = 10.192.000.

Waar in de eerste situatie elk van de 5 karakters gelijk wat kan zijn, weet ik dat in de tweede situatie 1 karakter beperkt is tot een hoofdletter, 1 karakter is beperkt tot een cijfer en 1 karakter is beperkt tot een speciaal teken.

[Reactie gewijzigd door .MaT op 5 maart 2021 11:09]

Dat komt vooral door de beperking van maximaal 5 tekens. Die beperking vind je bijna nergens.
Bij een vrij aantal tekens is het nauwelijks nog te berekenen aangezien je dan het gedrag van mensen moeten gaan meenemen. De speciale tekens zullen dan niet in plaats van een letter komen, maar achter of voor een gekozen woord. Door de eis te stellen maakt men dus het wachtwoord langer dan men aanvankelijk wilde doen.
Als iemand als ww Annelies1980 wilde kiezen en dan de melding krijgt dat er een bijzonder teken in moet zitten wordt het niet Annelies198! Maar eerder Annelies1980!
In de praktijk wordt het wachtwoord dus wel veiliger door die eisen te stellen. Als dat niet zo was zouden die eisen ook al lang vervallen zijn, maar dat is geen wetenschappelijke onderbouwing.

Alles hangt natuurlijk af van met wat je vergelijkt maar als je veronderstelt dat iemand anders enkel kleine letters zou gebruiken, dan ben je al vanaf 4 karakters beter af met de regel.

Als je daarentegen veronderstelt dat de persoon sowieso wel hoofdletters had gebruikt dan heb je minstens 15 karakters nodig om voordeel te doen met die extra beperking.

Ik zie bij genoeg mensen (werk in it, mensen willen allemaal tijdens middagpauze geholpen worden, vaak genoeg met een Post-it met hun wachtwoord op keyboard zodat zij kunnen eten, maar dat is een ander verhaal) dat het wachtwoord mee geëvolueerd is van een woord, naar woord met hoofdletter, met een cijfer (dat met 1 omhoog gaat bij wachtwoord verandering, vaak van 9 naar 0 en opnieuw beginnen) en een ! of - of =.

Heel zelden staat het cijfer of speciaal teken in het midden (soms vooraan).

Als je dit weet is het raden echt wel makkelijk: Naamvankind(maanden in dienst/reset tijd mod 9)! En je bent vaak binnen.

Ik heb nergens gesteld dat dit verplichte onderdelen zijn voor HA. Volgens mij heeft HA alleen de eis om minimaal zes karakters te gebruiken. (Heb het niet gecontroleerd)

Puur theoretisch klopt het uiteraard wat je schrijft.

aaa
Aaa
aAa
aAA
AaA
AAA

Bij de verplichting van zowel onderkast en kapitalen verlies je twee opties. Je forceert echter wel een significant grotere lijst (4 ipv 1) de verplichtingen op ‘sterke wachtwoorden’ komt natuurlijk voort uit het feit dat teveel mensen ‘feyenoord’ of ‘fikkie’ als wachtwoord namen waardoor het rendabel was om alleen de simpele wachtwoorden te testen in je brute-force. Nu moet je alle opties doen, of in elk geval meer (want je zal zien dat veel mensen alsnog Feyenoord01 of Fikkie01 gaan gebruiken)

Ik bedoel simpel gezegd, geef de mogelijkheid tot gebruik van grote,kleine letters, cijfers en speciale tekens. Helemaal goed. Maar verplicht dit niet.

Door dit te verplichten maak je het aantal mogelijke opties automatisch kleiner.

als het echt elk uur is, dan snap ik de frustratie. Zeker oudere gebruikers hebben veel moeite om "sterke" wachtwoorden te gebruiken. De ene keer moeten het 6 karakters zijn, de andere keer 8, met of zonder speciaal karakter, geen van de vorige gebruikte wachtwoorden, om de x aantal tijd verplicht veranderen, ...

De hash van een wachtwoord van 1 karakter is in principe even complex als die van een dat veel langer is. Microsoft heeft dit opgelost door een pincode te introduceren waarmee je een device kan ontgrendelen, net zoals gsm-fabrikanten dat al jaren doen, echter vanaf dat het niet meer om hardware-unlocks gaat, dan moet het plots complex zijn en liefst nog uniek. De slinger is voor velen wat teveel doorgeslagen en dan wordt er op velen onder ons beroep gedaan om het op te lossen. Zo "moet" ik voor minstens 2 andere mensen hun codes onthouden, terwijl ikzelf er al minstens 7 heb (enkel pincodes geteld, over wachtwoorden spreek ik nog niet eens.

Dat checken tegen Haveibeenpwned is leuk als er een username combinatie in zit maar puur alleen het ww is mijn inziens nutteloos. Zo'n database flans ik bij wij van spreken ook zelf wel in elkaar.
Er komt een tijd dat ook dat ww (jouw Wortel9630 bv) er ook in staat, kun je weer opnieuw beginnen.
Maar serieus, een simpel ww in een geïsoleerde omgeving boeit me echt geen ene reet op een publieke banking site daar in tegen wel.

Klopt is best vervelend sinds gister krijg ik ook regelmatig de melding hierover. Maar om een goed veilig wachtwoord aan te maken is nog beter natuurlijk. Ook al heb ik 2fa aan staan om op mijn HA te kunnen komen zelfs wanneer je via intern netwerk wilt komen op mijn HA. Dit kun je makkelijk en snel inschakelen binnen HA. Dus nog extra veiliger voor gebruik van HA.

Ik ben op dit moment aan het spelen met z-wave JS. Ziet er goed uit!

Had je hiervoor ook al z-wave via hassio? Ik deed de upgrade, en het werkte gelijk niet meer... dus weer terug naar m`n oude snapshot gegaan..

Jazeker, Z-Wave JS to MQTT als add-on installeren. De MQTT Gateway uitzetten, de WS server aanzetten en daarna de Zwave JS integratie installeren en verwijzen naar de WS server. Werkt als een speer.

Ik gebruik nu OpenZWAVE de builtin versie die hiervoor meegeleverd werd met Homeassistant. Dat werkt niet met MQTT, toch?
Ik zal eerdaags eens kijken hoe ik de upgrade ga uitvoeren.

Ondanks de naam Z-Wavejs2mqtt, werkt de Home-Assistant integratie met websockets (ws). Je kan in Z-Wave JS de MQTT uitzetten en Websockets aan.

Ik heb nu een etage in huis op de zwaveJS draaien met de nieuwe core.
Het verschil is echt groot. Waar ik vaak vertraging had met openzwave, reageert alles nu net zo snel als met mijn oude Fibaro.
Aankomend weekend de rest omzetten (ja, is even werk, zeker omdat ik ruim 40 devices totaal heb, elk raam, deur en lichtknopje en veel motion sensors en een paar rookmelders, dus hele weekend bijna mee bezig).
Maar deze vernieuwing is echt de moeite waard...automation kan ik wel copieren als alles included is.. en overgestapt van een (oude) NUC naar Pi4 met SSD..

[Reactie gewijzigd door badnews.nl op 4 maart 2021 22:54]

Staan goede migratie handleidingen online zodat je niet opnieuw je nodes hoeft te includen.
Alleen je batterij nodes even wakker maken en dan zou alles moeten werken.
Ben met 30+ nodes een goed uur bezig geweest.
Meeste werk was alle entiteiten hernoemen naar het origineel, zodat al je automations ook gewoon weer werken.

Ja, entiteiten renamen is het werk. Includen was inderdaad niet nodig. Merk wel dat ZwaveJS een stuk sneller is dan OZW. Alle Z-wave irritatie (en gedachten om dan toch maar alles te gaan vervangen) zijn verdwenen! Hier 56 Z-wave devices met 580 entities. Renamen ben ik nog niet helemaal klaar mee, moet nog even uitvogelen welke entities bij welke fase horen op mijn Quibino 3-fase meter.

Hier ook net omgezet van de oude Z-wave naar Z-Wave JS (met de standaard Z-wave JS server). Waren slechts 2 Forest elektrische gordijnen, dus renamen viel mee ;-)

Wat is het verschil met de oude (deprecated) z-wave integratie? (https://www.home-assistant.io/integrations/zwave)

Die gebruik ik nog... mis ik iets? Ik heb een Fibaro button liggen die ik nooit aan de gang heb gekregen, is dat het proberen waard met JS?

De oude z-wave draait onder de motorkap nog een oude OZW versie.
Had ook problemen met een scene button van Ali, had ik wel werkende door met de xml's te spelen.
Nu overgezet naar de JS versie, die pakte hem direct.
Zeker het proberen waard! En eerst snapshot maken, kan je altijd terug als er iets niet goed gaat.

Ik ben weer teruggegaan naar oude versie - een hoop properties van mijn zwave devices waren opeens weg...

Sowieso is de JS versie hier een stuk vlotter dan de oud OZW versie. Lampen reageren veel sneller en na opstarten van ZwaveJS zijn alle devices bijna direct bruikbaar!

De devs van ZwaveJS zijn ook zeer actief en responsive op feature requests en pull requests.

Voor OZW werd mij verteld dat ze geen feature requests aannamen en dat alleen bijdragen Okay waren.
Bijna een half jaar later is mijn pull request voor een driver uitbreiding nog steeds onder review terwijl de ZwaveJS jongens het al hadden ingebouwd omdat ze mij hadden gehoord op Discord...

Ik geloof dat OZW dus redelijk end of life is en gelukkig is er nu een alternatief wat zelfs binnen HA beheerd kan worden

Ziet er inderdaad goed uit. En snel bovendien.

Toch een hikje:
Mijn Hass configuratie is nog in opbouw, ik ben aan het overstappen vanaf Domoticz. Tot nu toe werkten de z-wave devices goed, maar sinds Z-Wave JS kan ik de thermostaatknop van de verwarming niet meer bedienen (Eurotronic Spirit). Ik zie het device nog wel, maar de entity voor het aan/uit zetten is verdwenen. De temperatuursensor werkt nog wel. Iemand dit ook tegengekomen?

Toch een hikje:
Mijn Hass configuratie is nog in opbouw, ik ben aan het overstappen vanaf Domoticz. Tot nu toe werkten de z-wave devices goed, maar sinds Z-Wave JS kan ik de thermostaatknop van de verwarming niet meer bedienen (Eurotronic Spirit). Ik zie het device nog wel, maar de entity voor het aan/uit zetten is verdwenen. De temperatuursensor werkt nog wel. Iemand dit ook tegengekomen?

Probleem heeft zichzelf opgelost met versie 2021.3.2

De nieuwe text editor is erg welkom!

Nieuwe texteditor? Die heb ik gemist geloof ik. :-)

Ja, met name voor mobiel sterk verbeterd

[Reactie gewijzigd door sjongenelen op 4 maart 2021 22:15]

Hij bedoelt waarschijnlijk de nieuwe editor voor een service call

supervisor-2021.03.4 is net uit :-)

wrong reply

[Reactie gewijzigd door Raven__NL op 4 maart 2021 20:04]

Tijd om de beschrijving te updaten.
HA gebruikt Raspian/Hassbian allang niet meer.