Software-update: Home Assistant Core 2023.1.0

Home Assistant logo (75 pix) Versie 2023.1.0 van Home Assistant Core is uitgebracht. Home Assistant Core is een opensourceplatform voor home-automation gemaakt in 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 over Home Assistant verwijzen we naar deze pagina en ons eigen Forum. De volledige releasenotes voor deze uitgave zijn hier te vinden; dit is de aankondiging daaruit:

2023.1: Happy New Year of the voice!

2023: What an exciting year this will be; The year of the voice! And not just that, many exciting things are expected this year. More spoilers can be found in the State of the Open Home 2022 recording on YouTube. Starting this amazing year with: Home Assistant Core 2023.1! A fairly small release, as we all enjoyed our Holidays. Yet, the first traces of the voice project are already visible: support for entity aliases!

Still, this release contains over 800 changes, most of which are quality improvements, bug and stability fixes, and other minor improvements. The perfect release to start the year with, an easy upgrade worth doing. Enjoy the release!

Home Assistant

Versienummer 2023.1.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

05-01-2023 • 05:03

76

Submitter: Frenck

Bron: Home Assistant

Reacties (76)

76
76
65
1
0
3
Wijzig sortering
Een hele vette nieuwe feature in deze release is trouwens de Google Assistant SDK. Deze werkt de andere kant op als voorheen al kon tussen HA en je Google Assistant. Je kan nu dus een tekstcommando, wat je normaal zelf zou uitspreken, virtueel zeggen tegen een Google Assistant apparaat.

Ik heb het zelf nog niet geintegreerd, maar ik kan me voorstellen dat dit een aatal zaken stukken makkelijker maakt. Bijvoorbeeld broadcasten door je huis dat er iemand voor de deur staat (i.t.t. TTS afspelen wat huidige media dat speelt afbreekt)
Ik heb deze sdk geïnstalleerd. Lampen aan en uitzetten werk bij mij. Berichten omroepen werkt echter niet. Dat is wel jammer want bijvoorbeeld als Spotify muziek aan het afspelen is op een Google speaker en ik roep nu een bericht om via text to speech op Home Assistant dan gaat Spotify daarna niet verder met spelen. Via de sdk zou dit wel moeten gaan.
Hoe heb je het uitzetten van lampen aan de praat gekregen? bij mij werkt het juist omgekeerd, ik kan omroepen (wel niet in het nederlands) maar niets bedienen. geen idee wat er mis is, enkel de instructies op de integrations pagina gevold. het omroepen via de sdk gaat niet via tts maar via "Send a notification with google_assistant_sdk", hier wel in het engels.

[Reactie gewijzigd door davy_vdw op 22 juli 2024 22:00]

Geen idee. Ik heb de credentials van de Assistant integratie gebruikt voor de sdk Assistant integratie.
Dat is zeker interessant.

TTS kun je trouwens ook als announcement afspelen. Dan breekt ie de muziek niet af maar pauzeert ie het alleen om het bericht f te spelen. Daarna gaat je muziek of film gewoon weer door..
Hoe heb je die announcement voor elkaar gekregen? Ik heb gezocht maar nergens er iets over kunnen vinden...
Dit scheelt best wat werk. Ik heb aantal Google Devices en dit vereiste een DEV-account. Ik heb dit uiteindelijk niet ingezet, maar dit was om Google Nest 2 te voorzien van Dashboards en stemcommando's.
Is dit de juiste plek om te vragen naar wat op dit moment de ‘beste’ manier is om zaken te automatiseren in HA? Via de ingebouwde UI, Node-RED, AppDaemon, andere opties wellicht? Ik heb nu een stuk of wat via optie 1 maar vrees dat dit lastiger onderhoudbaar wordt naarmate het aantal groeit. Ik hoor graag jullie reacties en bevindingen.
Als het simpele triggers zijn doe ik het in de UI van Home Assistant. Bijvoorbeeld het licht in de trapkast aan als de deur open gaat. Om het licht weer uit te doen heb ik dan de automation gedupliceerd en aangepast zodat ie uit gaat. Zelfs dat vind ik al niet ideaal.

Als het wat ingewikkelder wordt gebruik ik daarom Node-red. Programmeren in YAML is me te snel onduidelijk, aangezien een simpele if-else is al nauwelijks te doen is.
Dan zou ik je aanraden toch eens opnieuw naar de automation editor te kijken in de huidige vorm. Er zijn enorm veel opties bij gekomen, waardoor je enorm veel logica in een automation kwijt kunt. Een if-then-else is gewoon een standaard optie in de user interface tegenwoordig. Ook is de tracing van je automations enorm fijn het in het debuggen en kun je (als je dit wil) snel even een fix doen via je mobiel als er een automation niet lekker loopt.
Ook kun je obv trigger ID's je IF structuren dynamisch automations opzetten obv meerdere triggers met verschillende (kruisende) paden. Ook kun je tegenwoordig van alle stappen een alias/rename geven waardoor je hele flow in je UI enorm leesbaar wordt. De laatste maand enorm veel nieuwe automations gemaakt, maar geen YAML aan hoeven raken hiervoor.

Kort samengevat er zijn enorm veel opties bij gekomen, waardoor ik geen toegevoegde waarde meer zie van andere tools zoals een Node-Red. De documentatie van de opties moet nog flink bijgewerkt worden, maar de mogelijkheden zijn echt al goed aanwezig!
Interessant dit @Havocnl !
Heb je suggesties voor documentatie en of video’s die laten zien hoe eea werkt?
Het wijst zich eigenlijk vanzelf tegenwoordig. Als je een nieuwe automation via de gui gaat toevoegen kun je bijna alle opties gewoon uit een selectlist kiezen.
Cool, goed om te horen. Ik zal eens kijken of ik m'n huidige (dubbele) automations wat kan versimpelen en eventueel uit node-red kan halen :)
Het beste is iets dat ingebouwd zit (geen onderhoud en koppeling problemen) dus gewoon in HA.
Zoals velen ben ik begonnen met Node-Red wat erg mooi is maar de ontwikkelingen binnen HA hebben mij ertoe bewogen om alles naar HA te verplaatsen. Zeker in combinatie met bepaalde blueprints is het prima.

Maar vrees dat dit lastiger onderhoudbaar wordt naarmate het aantal groeit.
Ja, velen delen die zorgen en het is een veelgevraagde feature (grouping van automations). Ik heb er zelf geen last van doordat ik redelijke naamconventie gebruik (Presence-, Switches-, Routines-, etc) maar ik verwacht daar dit jaar nog wel verbetering in vanuit HA zelf.

Maar kort door de bocht, begin gewoon lekker in HA. Als je echt vastloopt kan je altijd nog over.
Je huis (automatisering) is toch nooit af :Y)
Folder structuur in Automations zou een prettige verbetering zijn.
Een van de meest gevraagde features, zie ook deze video over voorspellingen van Everything Smart Home: https://www.youtube.com/watch?v=BGXet18X4o8

Wellicht dit jaar!
Ik ben vroeger begonnen in Node-Red. Daar zie je alles visueel en krijg je ook alles wel voor elkaar. Zeker als je een beetje basis kennis hebt van programmeren. Toch is het ook weer lastig om bijvoorbeeld meerdere variabele in te lezen en die te vergelijken ofzo. Dan is de huidige automation in home assistant daar weer beter in vind ik.

Ik ben inmiddels overgestapt naar de automations van Home Assistant. Om niet meer afhankelijk te zijn van te veel plugins.

Ik gebruik node-red nu alleen nog om heel veel eigen sensors te initialiseren zodat ze via de MQTT auto discovery in home assisant terug komen.
Eigen sensors gebouwd met ESPHome oid?
Nee hoor. Van de Opentherm gateway die ik via LAN poort uitlees en niet heb geintegreerd in home assistant. En ook mijn Duco ventilatie lees ik wat van uit met ontwikkelde hardware van iemand. Eigenlijk ook de DSMR reader die je kan integreren in Home Assistant doe ik nog op deze manier. Ik kan dan via auto discovery gelijk de namen goed zetten hoe ik ze wil. Ohja en van mijn solar edge omvormer kan ik alle panelen apart inlezen via de protobuf bug die er in zat. Die lees ik eerst in Node-red in en verwerk de data en maak er een mqtt topic van.

[Reactie gewijzigd door Mich op 22 juli 2024 22:00]

Kijk eens op het forum zou ik zeggen (forum: Smarthome)

Ben zelf eind vorig jaar begonnen met Node-RED en het is echt een aanrader, De Automations interface van Home Assistant is erg verbeterd de afgelopen jaren maar het blijft moeilijk om het overzichtelijk te houden. In NR is dat veel eenvoudiger.
De UI in z’n huidige vorm is gewoon goed. Cosmetisch beperkt, maar functioneel goed. Node-RED vind ik zelf nodeloos complex en gedoe. Puur mijn mening natuurlijk. Node-RED is superkrachtig. Er draaien letterlijk hele fabrieken op. Het is eigenlijk (bijna?) programmeren met weinig code.
Appdaemon zie ik zelf met als een mechanisme om pseudo-applicaties op te draaien, zoals een softwarematige thermostaat ofzo. Je kan het in automations doen, maar dat is serieus veel gedoe.
Werkt super mooi, nu een jaartje op een Nuc pc
J4125 8gb ram en 128gb Samsung 830
(mlc) SSD .... verbruik totaal 4 Watt
Nooit een probleem gehad.
Overweeg nu om het in docker te zetten op Synology DS918+

Na de reacties, is mij weer duidelijk waarom ik destijds voor een Nuc had gekozen en niet voor docker dus ik blijf doorgaan op mijn Nuc

[Reactie gewijzigd door wim1928 op 22 juli 2024 22:00]

Dit lijken mij ook prima specificaties om HA op te draaien. M'n 920+ heeft dezelfde CPU en heeft HASSIO in een VM draaien die op een NVME-volume staat. Hoewel de 918+ een iets langzamere CPU heeft, moet dit alsnog ruim voldoende zijn. Een volume aanmaken op NVMe is dan wel niet officieel gesupport, tot nu toe werkt het wel als een zonnetje. Ook dat moet op de 918+ geen probleem zijn.

Mogelijk had Flapperbol zijn installatie niet op NVMe staan, of had hij z'n HA dusdanig zwaar uitgerust met allerlei devices, add-ons en integraties dat een zwaardere CPU van zijn NUC het beter deed.
Is het aan te raden HA op SSD’s te draaien?
HA is niet echt IO intensief, dus daar is echt geen noodzaak voor. Als je het op een RPI draait zou ik wel kijken voor een kwalitatieve SD kaart overigens, dat lijkt me als enige belangrijk te vermelden voor IO. En dan zou ik de DB toch extern draaien, of de recorder wat terug schroeven zodat er weinig weg geschreven wordt.
Je zou zeggen dat DB extern, recorder terugschroeven en kwalitatieve SD-kaart afdoende zou moeten zijn. Helaas bleek afgelopen week bij ons (1 dag na de geboorte van onze kleine, 8)7 ) dat ook dit geen garantie is. SD-kaart corrupt en je bent alles kwijt. Geen tekenen van tevoren dat dit zou gaan gebeuren overigens.

Al met al viel de schade mee: recente back-up en reserve SD-kaartje nog in huis, dus een uurtje werk en alles liep weer. Maar het was wel echt onhandig. Inmiddels volgt de installatie op een SSD.
Een SD kaart blijft inderdaad wel een (iets groter) risico, daarom draai ik het zelf ook op een NUC. Ten minste snel zat, niks terug schroeven en alles naar influx op dezelfde VM.
Gelukkig had je een (externe?) backup, dat maakt het inderdaad een stuk makkelijker te recoveren. Vroeger had ik alle config nog op github staan, maar tegenwoordig is dat niet meer echt een optimale oplossing.
Heb hem op een RPi4 in een Docker-container draaien en de RPi4 start op vanaf een 128GB-SSD. Heb een zooi docker-containers en dit werkt het handigste. Eerst een aantal dingen los op de RPi maar dat gaf allerhande conflicten (in mijn situatie) dus toen maar over op docker. Gegevens gaan naar een influx-database waar ik dan ook weer grafiekjes uithaal. Of het zinnig is of nuttig is een 2e. Maar is leuk om mee te stoeien. :-)
Wellicht zit hem het verschil draaien via een VM of via Docker. Flapperbol had het over Docker.
Ik heb hem hier ook al een tijdje in Docker draaien op een Synology NAS. Werkt best goed, maar ik zie ook wel wat beperkingen.
Ik merk ook nu ik bij DS218 geüpgraded heb naar 2 SSD's dat hij vele malen sneller is dan voorheen. Ik draai plex, Synology photos, camera en HA en dat werkt nu een heel stuk rapper.
Ik draai Home Assistant als vitual machine op een Synology DS718 met 16 Gb intern.
Darnaast ook Synology Photos en Surveillance System.
Voorheen Zwave en Zigbee via USB, maar recentelijk alle Zwave apparaten vervangen door Zigbee (ZHA).
CPU gebruik komt meestal niet boven de 6% uit. 4Gb gereserveerd voor HA.

Draait vlekkeloos, snelle responstijd.
Heb nog niet gekeken naar het stroom gebruik verschil met of zonder VM.
Waarom wil je overstappen van je nuc naar de nas?
De meest optimale uitkomst kan zijn dat het net zo goed draait als nu.
Om de doodsimpele reden dat een NAS het gros van de dag helemaal niets staat te doen en je nu een extra apparaat in de meterkast hebt hangen wat stroom verbruikt?

Ik heb het hier ook gesplitst momenteel maar in de nieuwe woning gaat alles gewoon op de NAS. Heb een DS720 waar al een poosje een docker instance als test op draait en dat gaat prima. Verbruik is overigens rond de 18W (dus wel fors meer dan een NUC) maar dan heb ik wel straks alles op 1 apparaat... al kan dat ook wel weer een nadeel zijn.

[Reactie gewijzigd door R2D2 op 22 juli 2024 22:00]

Ik snap je overweging denk ik, maar ben het er niet mee eens.

Het nadeel van alles op 1 nas is dat als je de DSM updated, je voor vervelende verassingen kan komen.
Zo heeft bijv de upgrade van DSM6 naar 7 usb integratie naar docker stuk gemaakt, geen idee of dat inmiddels gemaakt is.
En dat kan natuurlijk op veel meer punten gebeuren.

Met meer installaties op 1 nas, wordt de compatibliteit complexer.
Om de doodsimpele reden dat een NAS het gros van de dag helemaal niets staat te doen en je nu een extra apparaat in de meterkast hebt hangen wat stroom verbruikt?
Hou er rekening mee dat een Synology NAS zijn schijven kan laten rusten tijdens idle, maar door er docker op te gebruiken zijn die nooit idle dus zullen die altijd blijven draaien, wat héél wat energie kan schelen. Een low-power NUC met flashgeheugen zal dus veel zuiniger zijn dan je NAS docker laten gebruiken en de schijven zo te verhinderen in spindown te gaan.
Ik draai het op mijn qnap 253a in virtualization Station. Werkt perfect. Heb voor mijn unifi controller ook de add-on binnen de ha VM geïnstalleerd. Samen draait het uitstekend.
Ik ben juist geswitched van het draaien in docker op een 918+ naar een Nuc, dat draait veel beter
Oke bedankt, kan je mij uitleggen waarom het beter draait op je Nuc dan op je DS918+
De Docker versie heeft niet alle functionaliteit die de volledige Home Assistant OS heeft.
Zo kan je bijvoorbeeld add-ons niet gemakkelijk installeren en heb je geen supervisor.

Zie hier de verschillen:
https://www.home-assistan...pare-installation-methods
Je kunt gewoon de Supervised-versie in Docker installeren. Zo draai ik het ook.
Dat is zo. Maar is niet echt de officiële weg, of wel?
Als je het op een NAS installeert, zou ik kiezen voor VM. En als het goed is kan die DS918+ dat wel aan.
Officieel is een lastig concept in home assistant land. Als je je weg weet rond linux (zoals ze hier beschrijven: https://github.com/home-assistant/supervised-installer) kun je het prima doen. Draait als een zonnetje
Maar moet je dat dan iedere keer uitvoeren als je je docker image update?
Nee: zodra het draait draait het en kan je op de reguliere manier updaten
Nog simpeler is draaien in een Vm op een synology.
Als je een Synology hebt wel ja, maar anders is een VM veel meer overhead dan Docker op Debian.
Ik zit ff te zoeken, maar maak je dan een kale Docker-container met Debian en installeer je vervolgens daarin de hele HA Supervised en maak dan een nieuw image daarvan?
De zoekresultaten geven voor zover ik na kan gaan alleen installatie op OS aan.
Loen heeft hierboven de link naar de installer geplaatst. De hoeveelheid waarschuwingen daar vond ik wel een beetje overdreven, maar het is inderdaad net wat lastiger te installeren dan een volledig OS.
Het was mij even ontschoten waarom ik destijds voor een Nuc had gekozen, maar het is mij weer duidelijk, ik blijf gewoon zo doorgaan met me Nuc.. bedankt
In ieder geval een jaar of anderhalf geleden was de support voor Docker op Synology matig, volgens mij had het iets te maken met PHP of Python versies die niet meer geupdate konden worden of iets dergelijks. Ook waren er problemen met USB drivers die bij DSM 7 niet meer correct werkte met Z-wave/Zigbee stickjes

Het kan zijn dat er nu verbetering in is hoor, maar mijn zorgen waren voorbij toen ik naar de Nuc overging :)

Tevens kan je in docker alleen HA Core draaien, in tegenstelling tot HA OS op je Nuc. Technisch gezien kan je uiteindelijk hetzelfde met de twee, maar in HA OS is het minder instel werk naar mijn weten
@wim1928

Reactie ging verkeerd.

Ik ben overgestapt van mijn
ds918+, naar een nuc, ivm het stroom verbruik. Mijn nas staat niet deze hele dag aan, maar als deze aanstaat en Docker met Domoticz draait wel, er wordt dan ca. 70 Watt continue verbruikt. Ipv 6 Watt met mijn intel Celeron J1900, 4GB en ,64GB SSD. Dat vond ik genoeg reden om op een nuc over te stappen.

[Reactie gewijzigd door Jean luc Picard op 22 juli 2024 22:00]

Mag ik vragen welke nuc je gebruikt? Heb er ook oor naar, maar me nooit in verdiept tot deze thread.
Ik heb een Topton N5105 waar OpenWRT op draait en wat later ook een aantal Docker containers. Zonder Docker doet dat Topton dingetje 4-5W. Het is een volledig passief systeem zonder fans of HDD met bewegende onderdelen. Met Docker erbij doet dat ding 6-8W. Voordat je ‘t ding in gebruik neemt, moet je wel even controleren of de cpu goed contact maakt met het koperen blok en het koperen blok op zijn beurt met de behuizing. Soms zit er net te weinig koelpasta tussen.

Ik heb onlangs ook een gebruikte HP Prodesk 400 G5 mini gekocht met core i3-9100T. Dat ding heb ik enkel met Debian testing draaien nu. Verbruik zit rond de 2,7W gemiddeld in idle… Je moet wel wat tweaken om ‘m zover te krijgen maar daarvoor zijn we hier op de juiste plek :Y)
Nice! Ik heb een ProDesk G2 mini i5 die al 3 jaar uitstekend werkt. 512GB NVME, 16GB RAM en HDD voor opslag voor een VM. OS is Windows Server Core 2019 met Hyper-V waarop 3 (voorheen 5) virtuele machines draaien. Draait op zo’n 11W. Welke tweaks heb je gedaan om het verbruik te verlagen?
Ik heb enkel Debian Bookworm met sshd draaien, daar komen binnenkort wat Docker containers bij, waaronder Home Assistent en aanvullende containers zoals mosquitto, influxdb, Grafana, zigbee2mqtt enz. Daarmee zal het idle verbruik wel stijgen verwacht ik.

Ik heb in BIOS zoveel als mogelijk veranderd om een laag energieverbruik te realiseren, het idee is dat je je hardware met zoveel als mogelijk powersaving opties beschikbaar stelt aan het OS. En dan in het OS valt het eigenlijk wel mee. Er is een forum thread hier waar je (veel) informatie kunt vinden. Maar het verbruik wat je haalt met 3 VM’s op een host OS vind ik helemaal niet gek hoor.
Dank je, na bestudering heb ik ook een Topton besteld en ga ik eens rommelen met dit. Ben benieuwd of ik mijn Hue enzo kan spelen. Leuk projectje :)
Ik heb hier HA draaien op dezelfde specs als de HA blue versie:

ODROID-N2+ Amlogic S922X SBC with 4GB RAM
32GB eMMC Module for ODROID (no OS)
ODROID-N2 Case Black
Power Supply 12V 2A

zie: https://www.home-assistant.io/installation/odroid
Dit is een Alibaba apparaat dat ik heb gekregen van een kennis, ik heb hier in het verleden pfsense op gedraaid. Ik ben nu niet thuis zal vanavond even kijken.
Is deze dedicated voor HA of staan hier nog VM's op?
Ik heb nu namelijk een NUC met VirtualBox voor HA, maar ook nog een celeron J1900 met proxmox waar dingen als influx en grafana op gehost worden. Twijfel owv performatie en USB pass-through voor BLE en zigbee2mqtt HA ook op de celeron te zetten

[Reactie gewijzigd door Stray op 22 juli 2024 22:00]

In mijn geval draai ik alleen Domoticz rechtstreeks op Ubuntu 22.04 LTS. Zonder Docker. Deze staat headless in de meterkast.

Lukt dat proxmox op Celeron J1900 dual core 4G ?

[Reactie gewijzigd door Jean luc Picard op 22 juli 2024 22:00]

Hier nog een groot fan van Home Assistant.. werkt perfect met Tradfri & zigbee componenten. Iemand toevallig een tip voor een infrarood apparaat dat ik er ook mee zou willen aansturen? Ik zou graag iets hebben wat niet op het netwerk zit ivm onvertrouwde apparaten die callbacks doen, of iets waar ik Tasmota op zou kunnen zetten bijv (meer vertrouwd).
Je zou bijvoorbeeld een M5Stack Atom lite kunnen kopen. Die is ESP32 gebaseerd en kan je dus esphome op zetten en waarschijnlijk ook wel Tasmota. Voordeel van de M5stack productjes is dat ze direct in een mooi behuizingkje komen en met wat leuke ingebouwde accessoires. In het geval van de Atom lite een IR ledje (om je IR signalen te versturen), een knop (handig om manueel je IR commando te triggeren) en een RGB led (handig voor statusweergave).
Top, ens even onderzoeken.
Ik gebruik voor ir een RM mini 3 van Broadlink. Is wel een wifi device, hier geisoleerd op een apart vlan naar HA.
Ongelofelijk hoeveel HA doet. Geweldige applicatie die al mijn automatiseringen doet. Nuki, Hue, Tado, Xiaomi, Zigbee, Z-wave, SwitchBot, Ring, Dyson en nog meer, alles in een.

[Reactie gewijzigd door MoonRaven op 22 juli 2024 22:00]

Blijft een heel mooi stukje software. Het team erachter verzet echt veel werk.

Benieuwd hoe goed die Voice integratie aan gaat slaan. Rhasshy ziet er erg mooi uit alleen moeten er wel wat eenvoudige devices bijkomen. ESPHome devices als satelite zou erg welkom zijn.
Home Assistant is echt fantastisch. Jaren terug was het nog wel eens het bewerken en verdiepen van scripts, maar via de GUI kom ik al zover dat het echt zeer gebruiksvriendelijk is voor iedereen die een beetje interesse heeft in het digitaal knutselen, waarbij alles gewoon stabiel blijft draaien.

Om ze te supporten heb ik onlangs de Nabu Casa abonnement afgesloten, wat overigens ook de externe toegang zonder poespas instellingen verzorgt.
en ondertussen is de 2023.1.1 er ook al met de volgende wijzigingen
  • Limit calls in UniFi to write state (@Kane610 - #85248) (unifi docs)
  • Only subscribe to relevant IDs for state updates (@Kane610 - #85252) (unifi docs)
  • Bump pyeconet to 0.1.18 to fix energy usage (@w1ll1am23 - #85094) (econet docs)
  • Fix lacrosse_view fetching of latest data (@nijel - #85117) (lacrosse_view docs)
  • Bump bthome-ble to 2.4.1 (@Ernst79 - #85153) (bthome docs)
  • Bump hatasmota to 0.6.2 (@emontnemery - #85182) (tasmota docs)
  • Remove invalid AQI unit from Environment Canada (@frenck - #85183) (environment_canada docs)
  • Adjust valid energy units (@epenet - #85190) (energy docs)
  • Remove invalid device class for RSSI sensors (@epenet - #85191) (zha docs)
  • Fix device class for DSMR gas sensors providing energy readings (@frenck - #85202) (dsmr docs)
  • Improve error reporting when switchbot auth fails (@bdraco - #85244) (switchbot docs)
  • bump reolink-aio to 0.1.2 (@starkillerOG - #85247) (reolink docs)
  • Bump bimmer_connected to 0.12.0 (@rikroe - #85255) (bmw_connected_drive docs)
  • Reject the WiFI AP when considering to update a shelly config entry from zeroconf (@bdraco - #85265) (shelly docs)
  • Fix Fully Kiosk service call config entry handling (@cgarwood - #85275) (fully_kiosk docs)
Ben nog steeds op zoek naar een werkende manier om ook mijn ICS-2000 te integreren. Iemand tips?
ga ik checken. Werkt dit goed?
Moet daarvoor zie ik wel SSH in het systeem zelf, en niet via de SSH addon... correct?
ics-2000 is toch Klik-Aan-Klik-Uit?

Dat heeft bij mij jarenlang probleemloos gewerkt met een RFLink
Je kunt een RFLink gebruiken ter vervanging. Werkt hier al jaren perfect.
Dit zou ik graag ook nog een keer willen toevoegen

Op dit item kan niet meer gereageerd worden.