Software-update: Home Assistant Core 2022.3.0

Home Assistant logo (75 pix) Versie 2022.3 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 over Home Assistant we naar deze pagina en ons eigen Forum. De volledige releasenotes voor deze uitgave zijn hier te vinden; dit is de aankondiging daaruit:

2022.3: Select and play media

Did you know that today - March 2nd - in 1949, the first automatic street light was lit in New Milford, Connecticut, USA? Seventy-three years later, we automate our entire homes. Home Assistant Core 2022.3! And this release has a different and fresh “tune” to it! Yes, pun intended as this release brings tons of improvements involving media.

And what is so cool about it? It is not just about browsing media, it is even more about using it! Using media allows us to make the automations in our home more “personal”. For example, having our favorite radio station playing when we get home or broadcasting announcements and sound bites to our speakers to notify us of stuff happening in and around our home. (I really need to install that camera at the front door now.)

Home Assistant

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

Door Bart van Klaveren

Downloads en Best Buy Guide

03-03-2022 • 04:41

25

Submitter: Frenck

Bron: Home Assistant

Reacties (25)

25
25
15
0
0
8
Wijzig sortering
Even een heads up: als je de ShellyForHass integratie (via bv. HACS) gebruikt, deze werkt niet meer na de update (github ticket). Vooralsnog geen oplossing beschikbaar.

Dit is dus niet de officiële integratie.

Edit: laatste update ShellyForHass lost dit op.

[Reactie gewijzigd door DrPoncho op 25 juli 2024 01:38]

Er wordt nauwelijks getest en dus kun je voorzichtig aan een upgrade denken als er .7 achter het versienummer staat.
De vorige keer was het helemaal bont. Zonder het te melden was de state_class van energy ineens gewijzigd waardoor bij veel mensen het geheel niet meer werkte.

Kortom, wacht minimaal een week, maak een back-up en draai snel terug bij twijfel.
Volgens mij is het niet de taak van de HA developers om de werking van third-party integrations die vanuit HACS geïnstalleerd zijn te testen ;) De developers hebben een maand de tijd om hun code op de dev-builds te testen. Ik doe dat met mijn integration ook niet, maar die wordt toch door bijna niemand gebruikt :P
Het is niet alleen HACS, het is een algemeen probleem. Ze flikkeren het gewoon over de schutting zonder dat er bij verteld wordt wat er gewijzigd is. Het voorbeeld wat ik gaf is geen HACS maar gewoon een standaard onderdeel, namelijk Energy.

Maar goed, ik kan er mee leven zolang je maar wacht tot het versienummer op x.x..7 of hoger staat. En gezien de enorme hoeveelheid bugfixes is dat meestal binnen een week.
Ik weet niet waar jij problemen mee gehad hebt. Ik gebruik het nu ruim twee jaar en ik heb nog nooit wat voor probleem dan ook gehad door een update van HA.
Ook niet van een x.0 update
Ik ga al zeker een half jaar bij beta 0 over naar de nieuwe versie, en heb slecht één keer was issues gehad met mijn database, die overigens bij beta 1 al weer verholpen waren. Soms werkt er een custom component niet, maar dat is meestal vrij snel gefixed.

Buiten die ene keer heb ik geen issues gehad. Wel is het zaak om goed de breaking changes te lezen, en aanpassingen te maken mochten die nodig zijn.

De change die jij aangeeft was wellicht wat onhandig, maar speelde eigenlijk alleen als je zelf wijzigingen aan je sensoren had gedaan, en niet gewacht had tot de integratie zelf gewijzigd was.

Maar goed, met het goed lezen van de breaking changes moet je echt wel eerder dan een .7 release over kunnen.
Je blijft dat maar roepen maar zo werken die releases helemaal niet. Dat is je al meerdere malen uitgelegd maar je blijft dat hier herhalen. De subreleases na de .0 zijn bugfixes en versieupdates van componenten. Die worden niet gereleased om versie .0 te repareren. Als je de release notes zou lezen zou je zien dat de inhoud van een .1, .2, .3 etc. om veel oudere github issue's gaat dan wat er in .0 aanwezig is.
En ja, als er iets omvalt wordt dat in een subrelease gefixt. Jij doet echter alsof er zoveel subreleases nodig zijn om de .0 te repareren. Dat is gewoon niet zo. Lees gewoon eens door wat de release policies van HA zijn.
Tuurlijk, praat het maar goed. Het wordt gewoon niet getest en over de muur geflikkerd.
Het feit is dat de .0 meteen na release een enorme hoeveelheid shit geeft in de Github logs.
Er valt niets goed te praten. Hun proces loopt gewoon prima. Er wordt uitgebreid getest.
Je blijft maar volhouden dat de subreleases fixes zijn omdat de .0 release niet in orde zou zijn. Dat klopt gewoon niet. Wat jij "shit" op Github noemt zijn veelal zaken van mensen die niet hebben gezien dat een onderdeel deprecated is of een breaking change. De meeste items worden snel alweer gesloten.
Lees je nu eerst eens in in het release-proces en probeer daarna eens zinnig commentaar te leveren.
Cognitieve dissonantie, dat is het.
Ik denk eerder eigenwijsheid aangezien je ook na de vorige keren niet één keer de moeite hebt genomen om te kijken hoe het releaseproces in zijn werk gaat. Dan zou je namelijk gewoon weten dat het per definitie niet klopt wat je hier steeds roept.
En terecht dat ik dat roep, want zo is het in de praktijk. Na elke grote update is er altijd meteen een instabiele situatie. Dat de intentie misschien anders was, doet daar niets aan af.
Het is een op zichzelf goed systeem en ik ben er ook blij mee, maar je moet er rekening mee houden dat het niet getest over de schutting wordt gesmeten.

Je kunt blijven roepen dat het releaseproces anders werkt, maar daar heb je als eindgebruiker geen zak aan. Het feit is dat je gewoon moet wachten op .7 of zo. We zitten nu op .2, dus we hebben nog een paar dagen te gaan.
Er is ook weinig reden om niet te wachten, de meeste toevoegingen zijn sowieso kul of verplaatsingen van zaken waardoor je moet zoeken waar de instellingen gebleven zijn.
Het is zelden een instabiele situatie. Dat is je ook al meermaals door verschillende mensen verteld.
Je begrijpt blijkbaar nog steeds niet hoe .1 t/m .7 (of .8 of...) werkt. Waarschijnlijk kom je dan de volgende keer weer met dezelfde onzin.
Zoals gezegd, cognitieve dissonantie.
Ik begrijp het prima, maar jij blijft volhouden dat er niets aan de hand is. Je ziet het gewoon niet. Een roze bril is wel een handicap, maar geeft verder niets hoor.
Verstandige mensen wachten met installeren tot de fixes gedaan zijn en jij mag best een beetje aanmodderen.
Nee, je laat iedere keer weer zien dat je het niet begrijpt.
Niet zo aanmatigend hè. Jij hebt een roze bril en we gaan niet tot elkaar komen. Laten we het daar op houden.
Even nieuwsgierig, waarom zou je deze gebruiken in plaats van de officiële integratie?
ShellyForHass heeft een betere manier van communiceren met de Shelly's als ik mij niet vergis, waardoor deze sneller reageren. Iets met push vs. polling.
Het belangrijkste verschil is volgens mij dat officiële integration 'Local push' gebruikt (dus alles lokaal in je eigen netwerk), en de ShellyForHass via de cloud of via mqtt communiceert.

Ik ben persoonlijk een groot voorstander om zo min mogelijk afhankelijk te zijn van cloud-diensten of dat het per se via mqtt moet. In elk geval voor zaken in m'n eigen huis.

Nou zou het prima kunnen dat deze HACS-module meer functionaliteit biedt dan de officiële integration. Dat zou ik niet weten.

Anekdotisch:
Ik heb een paar Dyson luchtreinigers in huis. De officiële app gaat via 'de cloud'. Ik heb een HACS-module die volledig lokaal communiceert. Ik heb nu dus m'n Dysons in een apart vlan gezet zodat ze het internet niet meer op kunnen en bedien zo lokaal via HA.
https://github.com/StyraHem/ShellyForHASS
Using CoAP and REST for communication (not MQTT)
Using events so very fast response (no polling)


Ze gebruiken beide CoAP en dat is lokaal.
Uiteraard kun je alles ook via de cloud laten lopen of zelfs via IP als je op een ander subnet zit:
Add Shelly devices by IP-address if on different LAN or mDns and CoAP not working for discovery

Er zat vroeger mogelijk verschil tussen de integraties maar (blijkbaar) tegenwoordig niet meer. Maar het is ook niet erg om meerdere oplossingen te hebben.
Verwijderd @Demo3 maart 2022 11:02
Ik ben de rabbithole maar even ingegaan om het uit te zoeken maar het is erg onduidelijk.
De officiële integratie gebruikt CoIoT (wat weer CoAP is). Die gebruikt dus (tegenwoordig) gewoon push.
Dat wordt bevestigt op de HA pagina (linksboven):
https://www.home-assistant.io/integrations/shelly/
The Shelly integration was introduced in Home Assistant 0.115, and it's used by 11.1% of the active installations. Its IoT class is Local Push.

ShellyForHass gebruikt ook gewoon CoAP wat natuurlijk fantastisch is maar niet anders dan de officiële integratie. Mogelijk dat dit vroeger anders was. Ik herinner mij ook dat ik deze integratie via HACS moest installeren omdat er geen officiële integratie was.
Er lopen discussies over het verschil maar niemand lijkt het echt te weten. Wat ik zie is dat men voornamelijk vanuit historie de S4H integratie heeft draaien of omdat men netwerk problemen heeft met het een of het ander en daarom voor de een of de ander kiest.
Ik denk dat dit de beste conclusie is:
I would be really helpful if Shelly For Hass would just come out and say at the top of its home page that its an alternative integration to the native one.
Dus gewoon een alternatief, niets meer of minder. En dat is uiteindelijk ook prima.
Voor mij was 't simpelweg dat deze er eerder was dan de officiële, dus had m'n systeem er al op ingericht. En geen reden gehad om te switchen.
Die had ik ook hoor, tot ik switchte naar docker en besloten had om de boel opnieuw in te richten.

Ik kwam er pas heel laat achter dat ik voorheen de ShellyForHass integratie had geïnstalleerd. Gezien de Shelly's bij de nieuwe installatie gewoon direct naar voren kwamen, had ik deze bij de nieuwe installatie niet meer gebruikt. Vandaar dat ik ook vroeg waarom men de ShellyForHass gebruikte.

Verder nooit problemen gehad met zowel ShellyForHass als de core integratie. Shelly's zijn echt top.
Ik heb mijn vier Shelly's van ESPHome voorzien; o.a. om dit soort issues te voorkomen.

Ik probeer sowieso mijn HASS zo standaard mogelijk te houden. Ik heb dan ook nog nooit problemen met een update gehad, op de Afvalwijzer via HACS na.
Hassio installatie met MSSQL (remote) db stuk sinds 3.0 : (

Blijkt aangekondigd maar zelf de meldingen niet gezien.

https://github.com/home-assistant/core/issues/67500
https://github.com/home-a...18-supported-databases.md

[Reactie gewijzigd door Mirabis op 25 juli 2024 01:38]

Op dit item kan niet meer gereageerd worden.