Software-update: Home Assistant Core 0.113.0

Versie 0.113 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 Nest-thermostaten, 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 Forum. De aankondiging voor deze uitgave is hieronder te vinden.

0.113: Automations & Scripts, and even more performance!

Another special, themed, release inbound! It seems like @bdraco is unstoppable; he just keeps going on improving the performance of the Core. I truly admire him for the work he has been delivering the past months, however, that is not the point of this release. Sorry, @bdraco! This release is about: Automations & Scripts! Yes!!!

A long, long time bug with automation triggering has been resolved, but not only that, @pnbruckner went all-in by extending the automation/script engine even more. Adding repeat, a chooser and running modes (with cool down possibilities as a side-effect).

I’ve been playing with these features on my home already and I’ve changed/improved quite a few things. For real, @pnbruckner, thank you!

Ludeeus joins Nabu Casa

Today we’re happy to announce that @ludeeus is joining Nabu Casa to work full-time on Home Assistant!

Ludeeus has been a core contributor for a long time working on the Supervisor panel and different bits of the frontend. He is, however, mainly known as the creator of the Home Assistant Community Store (HACS).

We’re looking forward to seeing what he can do now that he is able to focus full-time on Home Assistant. Welcome @ludeeus!

Automations & Scripts

This release brings changes to our automations and scripts. Before we start with this all, please note, that the action part of an automation is a script sequence.

So, all discussed below, apply to both scripts and automations.

Before diving in: All automation and script changes, have been driven by @pnbruckner! It is awesome! Thanks!

Automations & Scripts: Bug fix

There has been an issue with our automations for a long time already, which you actually might have never noticed. It is kinda hard to explain, so this needs an example.

Consider the following automation:

automation:
  - alias: "Example"
    description: "On button press, turn on the light bulb for 10 seconds."
    trigger:
      - platform: state
        entity_id: binary_sensor.button
        to: "on"
    action:
      - service: light.turn_on
        entity_id: light.bulb
      - delay:
          seconds: 10
      - service: light.turn_off
        entity_id: light.bulb

This automation turns on a light bulb when the button is pressed, and after 10 seconds, it turns off the light bulb again. A fairly basic automation, which does exactly what one would expect, except when a button is pressed twice.

So it takes 10 seconds for the bulb to turn off, what if you press the button again after 5 seconds?

Please, think about this for a moment…

What actually happened before 0.113, is that the light bulb would turn off immediately! Chances are, you didn’t expect that.

Let’s explain this: So the first button push, turns on the light, and the delay is active for 10 seconds. The second button push, done after 5 seconds, is actually not handled, however, it does cause the delay of the first run to cancel itself and continues to run the rest of the actions/sequence, causing the light to turn off immediately!

That bug, has been fixed. As of this release, the second button press wouldn’t do anything and the light will now turn off after 10 seconds, which the first button push has triggered.

Automations & Scripts: Running modes

With the above-mentioned bug fix, it now becomes possible to introduce new running modes for both scripts and automations. It allows you to control what happens if actions of a previous trigger are still running.

Considering the light bulb example in the bug fix paraph above, it shows the default mode: single, which means: Do not run and ignore the trigger if a previous action of the same automation is still running.

Besides the default single mode, the following modes are now available:

Mode	Description
single	Do not start a new run, if running already.
restart	Start a new run, after stopping the previous run.
queued	Start a new run after all previous runs complete.
parallel	Start a new, independent, run in parallel with previous runs.

For the queued and parallel modes, an additional parameter max is available to control the maximum number of runs that are awaiting each other. When omitting this setting, it would default to 10.

To clarify a little more, remember the first example in the bug fix paragraph where the light bulb would turn on for 10 seconds after a button press?

This would make every button press within the 10 seconds, restart the countdown again:

automation:
  - trigger:
      - ...
    mode: restart
    action:
      - ...

And this example, would turn on/off the light, for 10 seconds twice, if the button was pressed after 5 seconds.

automation:
  - trigger:
      - ...
    mode: queue
    action:
      - ...

The modes are also available for automations and scripts in the frontend UI:

This is a powerful feature, which allows you to control how automations and scripts are run in ways you could not do before.

More information about the running mode can be found in the automations and scripts documentation.

Automations & Scripts: Repeats

A brand new action is made to allow for repeating (also called loops) part of your automations or scripts.

The new repeat feature can be used in three different ways:

• Counted repeat: Control how many times to repeat a sequence.
• While loop: Keep repeating as long the condition(s) is/are met.
• Repeat until: Runs at least once, and decides after that to repeat until the condition(s) is/are met.

For example, this would spam your phone with the same message 10 times:

- alias: Send notification spam to phone
  repeat:
    count: 10
    sequence:
      - service: notify.frenck
        data:
          message: Ding dong! Someone is at the door!

More information about repeats can be found in the documentation.

Automations & Scripts: Chooser

Got multiple automations for that single light to turn it on/off? Or multiple automations/scripts to handle the different buttons on some remote?

You can now combine them using a chooser. The chooser is able to pick the first sequence that matches a condition, or if none match, run a default sequence.

This means each individual sequence in the chooser is paired with its own set of conditions.

automation:
  - alias: "Example"
    description: "On button press, turn on the light bulb for 10 seconds."
    trigger:
      - platform: state
        entity_id:
          - binary_sensor.button1
          - binary_sensor.button2
          - binary_sensor.button3
    action:
      - choose:
        - conditions:
            - condition: state
              entity_id: binary_sensor.button1
              state: "on"
          sequence:
            - service: light.turn_on
              entity_id: light.bulb
        - conditions:
            - condition: state
              entity_id: binary_sensor.button2
              state: "on"
          sequence:
            - service: light.turn_off
              entity_id: light.bulb
        default:
          - service: notify.frenck
            data:
              message: Some other unknown button was pressed!

In the above example, pushing button1, turns on the bulb; while button2 turns it off again. The third button isn’t handled by any of the conditions in the chooser and the (optional) default is run instead.

The chooser can be used as an if/else statement, where the default acts as the else. Or even as if/else if/else statement as shown in the YAML example above.

More information about the chooser can be found in the documentation.

Automations & Scripts: Sub-second precision

Thanks to a bunch of optimizations done this release, which is discussed later in this blog post, we now have sub-second precision available to our delays.

This precision is helpful in case you want a delay that is less than a second, for example, 500 milliseconds.

An example script that toggles the light every 500 milliseconds 10 times.

script:
  blink_light:
    sequence:
      repeat:
        count: 10
        sequence:
        - service: light.toggle
          entity_id: light.bulb
        - delay:
            milliseconds: 500

Automations & Scripts: Bonus! Cool down

An often requested feature is to allow for a cool down time on an automation. What that entails is setting a limit on the run of an automation or script to a certain time frame.

While this is not a feature specifically added or build, it can be achieved now using the new run modes.

automation:
  - alias: "Doorbell cool down"
    description: "Prevent multiple message being send when spamming the doorbell."
    mode: single # Which is the default
    trigger:
      - platform: state
        state: binary_sensor.doorbell
        to: "on"
    action:
      - service: notify.frenck
        data:
          message: Ding dong! Someone is at the door!
      - delay:
          seconds: 10

The single run mode of this automation, combined with the last delay of 10 seconds, prevents this automation from being ran more often than only once every 10 seconds. This is ideal for things like a doorbell.

MDI icons updated

It has taken some time for us to upgrade to the newest version of Material Design Icons, 5.3.45, there was a reason for that, version 5.0.45 contains a lot of breaking changes.

We wanted to handle these well, so it took some time.

A lot of icons are renamed, and some are removed. In this release, we included all new, and all removed icons and we made sure the new and the old name work.

If you use an icon that is renamed or removed we will show a warning in the log, in version 0.115, this conversion path will be removed and removed icons and old names will no longer work.

So make sure to check your logs if you need to adjust any of your used MDI icons.

Most of the removed MDI icons can be found in Simple icons, which is available as a custom integration.

Please note: It is possible that custom integrations (also known as custom components) use deprecated icons. These can throw warnings that need to be addressed in the custom integration.

Script and Scene editor updates

The UI to edit or create a script has been updated, besides support for the new running mode, you can now give your scripts a custom icon and ID from the UI.

Especially the ID is helpful, you no longer have to search your states for a long numeric entity id that matches your script.

The support for setting a custom icon, is also added to the scenes editor.

More speed optimizations

After, the well-received, speed optimization done in the 0.111 & 0.112 releases, the saga towards improving resource usage and responsiveness of the platform continues.

This time we have both @bdraco and @pvizeli to thank for some great optimizations that will reduce the CPU usage of Home Assistant.

First of all, if you are running a Home Assistant OS, Container or Supervised installation, this your Home Assistant instance will run on Python 3.8. No action from your end is needed for this.

It is not just a normal Python version, but @pvizeli has worked on a highly optimized Python version for Home Assistant, hitting performance improvements that can reach up to 40%! He wrote a more technical article about this on our developers blog.

Then @bdraco did his part on adding some improvements to the Core. He changed a lot of handling around event & state listeners, in such a way less things trigger unneeded, which reduces processing when states change.

This lowers CPU usage and improves response speed when you have many state changes happening in a short time span, or when having a lot of automations.

Also, all time listeners now have microsecond precision as they are scheduled on the internal event loop, instead of the previous situation when it relied on the internal clock that triggered every second.

This release should drastically lower the CPU usage of Home Assistant for most installations.

Other noteworthy changes

• Philips Hue groups can now be turned on/off in the integration options via the UI.
• The OpenZWave (beta) got 3 new services. Two of those are for setting user codes on locks. The other allows for setting device-specific configuration parameters.
• After a moment of absence, @yosilevy is back! He has been the one fixing all kinds of RTL issues we had in Home Assistant, with his return, this release is full of RTL tweaks again!

New Integrations

Three new integration added this release:

• PoolSense, added by @haemishkyd
• Dexcom, added by @gagebenne
• Bond hub, added by @prystupa

New Platforms

The following integration got support for a new platform:

• OpenZWave has now support for window covers, added by @Michsior14

Integrations now available to set up from the UI

The following integrations are now available via the Home Assistant UI:

• Syncthru, done by @scop
• SmartHab, done by @outadoc

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

Reacties (66)

Ik sluit mij aan bij de eerdere lofzang. HomeAssistant werkt top, steeds beter en heeft een goede community. Destijds heb ik een Fibaro Homecenter 2 aangeschaft voor een pittige prijs, als deze updates ontvangt zoals bij HomeAssistant was hij zijn prijs meer dan waard maar nu fungeert de HC als z-wave controller voor HomeAssistant. HomeKit en Google Home ondersteuning etc. Laat dit een advies zijn voor mensen die een dure z-wave gateway overwegen. Doe het niet! Ga voor HomeAssistant met een z-wave stick!

En een Conbee Ii stick voor alle Zigbee (Philips Hue/Xiaomi/Osram/etc) spullen.
Werkt veel betrouwbaarder dan de originele Philips Hue Bridge en is los zelfs goedkoper dan de Bridge.

Mochten mensen interesse hebben voor paar euro heb ik een simpele USB zigbee stick met koenk zigbee firmware erop gebruik het zelf in mijn Synology Nas Al meer dan een jaar en doet het perfect

Nadeel alleen is -en dat is de reden waarom ik van de Hue Bridges (ja, meerdere) ben afgestapt- dat de USB Zigbee stick maar 55 devices ondersteund, de Hue Bridge heeft diezelfde limiet.
De Conbee II kan tot 200 devices aan waardoor ik dus 3 Hue Bridges kon vervangen.

Voor ieder apparaat rechtstreeks naar de USB is dit correct, maar zodra je er 'routers' zoals lampen of Ikea repeaters tussen hangt schaalt dit enorm op en ben je niet gelimiteerd aan 55 devices.

Naar mijn ervaring werkt die CC2531 stick toch niet helemaal lekker. Veel crashes, als ik 10 Philips Hue lampen tegelijk aanzet dan crasht de stick en moet ik, of mijn server rebooten en de stick re-pluggen, of zelfs de stick reflashen om het weer werkend te krijgen.

Ik heb zelf zo'n 26 lampen, zowel Philips Hue als Ikea tradfari. Daarnaast ook nog 15+ sensoren voor beweging, licht, temperatuur, deuren open, etc.

Aangezien elke lamp zich ook weer voordoet als router heb ik de Ikea repeaters nog in de kast liggen. Ik heb dit allemaal op een enkele CC2531 stick draaien met zigbee2mqtt.

Op wat voor server heb je het draaien? Misschien mis je gewoon wat performance...

Ik draai het op dit ding: pricewatch: Alfawise X5 Niet de snelste server..
Merkte dat het stabieler werkte op mijn main laptop, al nog niet vlekkeloos.

Ik heb 10 Philips Hue lampen vrij dicht bij elkaar hangen, 4 Tradfri spots, 1 Tradfri LED strip en een Tradfri remote. Het is me één keer gelukt om alles tegelijk gepaired te hebben met de CC2531 stick. Maar toen ik de stroom van de Hue lampen af haalde, en weer er op zette werkte niks meer

Binnenkort nog maar eens proberen op mijn laptop, misschien is het echt een performance of hardware compatibility issue.. Het geeft me wel hoop dat het bij jou goed werkt

Vergeleken met andere gebruikers heb ik nog maar een klein netwerkje.

Er zitten slimme mensen op het Discord channel die je ook kunnen helpen, zowel met hardware als software.

https://discord.gg/NyseBeK

Zeer zeker niet. In het voorbeeld dat je zelf aanhaalt staat al dat er per router 21 devices extra kunnen worden aangesloten (mits de fysieke plaatsing het toelaat). Elk zigbee apparaat wat permanent aan voeding hangt gedraagt zich als router in een zigbee netwerk. Lampen dus wel bijvoorbeeld, maar battery powered devices niet. Overigens is er inmiddels alternatieve hardware welke meer devices ondersteund. https://www.zigbee2mqtt.i...n/supported_adapters.html

Ok, dat is nieuw voor me, ik had altijd begrepen dat die USB sticks en Bridges een max van 55 hadden.
Van de Hue Bridge weet ik het zeker, dat was ook duidelijk te zien in de Hue App, maar van een USB stick dus blijkbaar niet.

Maar even een simpele berekening, de stick kan 20 apparaten direct aan, even ervan uitgaande dat al die apparaten ook als router fungeren zou je dus 20x21=420 devices kunnen koppelen?
Of kan een router ACHTER een router ook weer 21 devices aan (wat het aantal devices dus oneindig zou maken als alles ook routers zouden zijn), wat me ook weer zeer sterk zou lijken gezien de maximale bandbreedte van en naar de stick en het dataverkeer in z'n totaliteit.

Lijkt sterk, maar technisch gezien kun je 15 miljoen devices kwijt. Je komt dan gewoon tegen een technisch limiet aan.

In Zigbee the "node address" is the physical device (the radio). Each physical device can contain up to 240 "logical" devices (endpoints). Endpoints consist of clusters, which provide device behavior. When you create a bindings, you are tell one "logical" device how to communicate with another "logical" device.

So technically you can have roughly 15 million (2^16 * 240) "logical" devices on a network.

Bron

Bedankt voor de uitleg.
En de 15 miljoen devices zal ik niet zo snel halen

https://github.com/Koenkk...e/tree/master/coordinator ligt er aan welke firmware versie en welke hardware je het draait natuurlijk, je kan maximaal 400 apparaten aansturen op 1 stick, betaal je wel wat meer. Je kan natuurlijk ook meerder CC2531 aan elkaar knopen wireless om zo meer routes te maken en meer te ondersteunen

Daarnaast reageert een z-wave stick ook sneller doordat hij rechtstreeks wordt aangestuurd door de machine waarop hij is aangeloten. communicatie met een z-wave hub verloopt altijd via het netwerk waardoor er altijd een vertraging is.

Ik ben ooit begonnen met een Vera Z-wave controller die na een jaar ook geen updates meer kreeg. Daardoor waren nieuwere Z-wave modules allemaal niet compatibel. Koop inderdaad nooit een zo'n kant en klare gateway want het is weggegooid geld. Ik durf ook te beweren dat ze onveiliger zijn omdat ze na een bepaalde tijd geen updates meer krijgen waardoor eventuele beveiligingslekken nooit gedicht worden.

Ben nu ongeveer twee maanden langzaam begonnen met Home Assistent. Erg lastig als je nog maar weinig Linux kennis hebt.

Momenteel op een RPi2 (niet het snelste, weet het) geïnstalleerd, manual. Dus niet supervised, en dat is balen. Want dan kun je nagenoeg niets met de plugins, of allemaal handmatig in config files, dus sta met de rug tegen de muur.

Wat is de makkelijkste manier om 'm supervised te krijgen (zonder alles op te geven), er geen goede manier meer met Docker? Of zonder de hele Pi te flashen met hassio? (Draait op PiHole op). Thanks!

[Reactie gewijzigd door KoalaBear84 op 22 juli 2020 23:32]

Exporteer je pihole configuratie en stel je config map van je huidige home assistant ergens veilig. Belangrijkste is je configuration.yaml maar pak alles mee wat je daar vindt.

Dan kun je, om snel klaar te zijn, je hele Pi opnieuw flashen met OS naar keuze. Dan is alles terug naar de begin situatie. Dan installeer je de supervised installatie (https://community.home-as...stallation-methods/207703) en dan krijg je meteen docker daarbij en wordt er ook de handige superviser geinstalleerd. Eigenlijk is dat de meest comfortabele situatie. Eenvoudig te installeren en upgrades zijn echt super simpel. Omdat alles in docker draait krijg je ook alle voordelen die daar bij horen kado.
Dan installeer je Portainer in je docker installatie, dat is een GUI om docker heen en dan kun je bijvoorbeeld vanuit die GUI ook PiHole installeren als een extra container (https://hub.docker.com/r/pihole/pihole). Daar importeer je dan je configuratie weer in en je hebt alles weer zoals je begon.

Je eindigt dan dus met een supervised home-assistant installatie (die alle plugins e.d. ondersteunt) en je hebt je pihole weer terug.

Echter, je RPi2 is niet krachtig genoeg voor serieus werk. De officiele requirements zijn minimaal een RPi3 (https://www.home-assistant.io/docs/installation/) maar je zult merken en lezen dat veel mensen eigenlijk een raspberry afraden voor een echte installatie omdat er veel problemen zijn voor 24x7 intensief gebruik. Als je het toch wilt proberen op een RPi, zorg dat je een stevige oversized voeding hebt en een SD kaartje gebruikt van hoge kwaliteit. Misschien werkt het voor jou wel. Veel gangbaarder, maar ook wat duurder, is een goedkope NUC nemen met een goedkope SSD er in. Deze is bijvoorbeeld redelijk populair als thuisservertje: https://www.intel.com/con...ts/nuc/kits/nuc6cayh.html
Uiteraard kun je ook vergelijkbare systemen overwegen. Het hoeft echt geen Intel i5 processor te zijn, dus zoek het aan de onderkant van de specs wat wel zo vriendelijk is voor je bankrekening en je stroomverbruik.
Maar goed, test het vooral eerst even uit voordat je investeert.

Zo'n ding werkt echt sneller, maar is vooral ook stabieler. Als je straks je omgeving gaat uitbouwen met meer sensoren dan ga je ook de NodeRed plugin installeren voor je automation en een MQTT server om alles met alles te koppelen zoals goedkope Sonoff devices en dergelijk en dan groeit zo ongemerkt je systeem en ga je er ook meer afhankelijk van zijn. Dat gaat vanzelf, wacht maar af. Het is dan wel fijn als je niet op een ochtend wakker wordt en je SD kaart is dood en niks werkt meer.

[Reactie gewijzigd door Ballenbakz op 23 juli 2020 00:45]

Bedankt voor alle info. Dat de Pi2 te zwak is had ik wel door, erg trage grafieken, en in `dmesg` zag ik ook dat er geregeld undervolted kwam. Nogmaals bedankt 👍

Vaak wordt ook geadviseerd om van "usb mass storage" te booten i.p.v. een SD kaart. Deze schrijf je minder snel stuk. Dat kan gewoon een flinke USB stick zijn of, zoals in mijn geval, een USB m.2 sata hat https://www.conrad.nl/p/m...r-de-raspberry-pi-1487097 voor de raspberry pi.

Yes alleen wordt dat voor de Pi4 i.c.m hassos nog niet ondersteund

Sinds december vorig jaar wordt de Pi4 al ondersteund...

https://www.home-assistan...9/12/17/hassos-release-3/

Yes klopt maar bedoelde op een SSD...(sorry0

Ik draai het Home Assistant OS (dit is toch HASSOS?) op een SD kaart op dit moment maar SSD is hier nog niet op supported.

Sinds HassOS 4.5 wordt NVMe SSD ondersteund

Welke Tutorial kan ik daarvoor gebruiken? Ik zie namelijk verschillende halve tutorials...
En HASS.OS is de totale OS variant toch?

Ik houdt ze nooit uit elkaar.

HassOS is de volledige ja. Home Assistant Operation System. Op deze blog staan de verschillende installatiemethodes https://www.home-assistan...nd-community-guides-wiki/.
Wat ik van mijn broer heb begrepen is dat hij HassOS op een usb heeft geflasht. En daarna de usb stick naar de SSD heeft gekopieerd. Ik heb het zelf nog niet geprobeerd. Ik draai nog Supervised.

Zo'n ding werkt echt sneller, maar is vooral ook stabieler.

Ik heb het zelf tegenwoordig draaien op een pi4, en werkt prima snel (eerst een pi2, maar dit draaide inderdaad te traag). Maar wat versta je onder stabieler in deze context? Mijn installatie is nooit onderuit gegaan, en HA is nooit crashed bij mij.

Echt intensief gebruik zie ik ook niet. De load van de pi is ongeveer 0.24 (op 4 CPUs). Ik heb er zelf een 256GB SD-kaartje in zitten die dus (mits het kaartje goed is ontworpen door Sandisk) zelf aan wear leveling zou moeten doen zal het slijten van het kaartje in de praktijk wel loslopen.
De praktijkvoorbeelden waarin HA, SD-kaartjes heeft gesloopt, zie je veelal dat het om kleine kaartjes (of van Chinese meukkaartjes) ging. (Er zullen uiteraard ook uitzonderingen zijn met nieuwe grote a-merk kaarten)

Dat gezegd hebbende, heb ik ook een aanzienlijk deel van de logging uitgezet in m'n HA-installatie. Er zijn maar een paar dingen die ik interessant vindt om altijd bij de hand te hebben. De rest wordt naar een PostgreSQL servertje op een VPS gestuurt (middels een Wireguard-tunnel gekoppeld aan m'n eigen LAN)

Of hij echt veel 'sneller' in de praktijk zal zijn op een NUC als hij eenmaal gestart is durf ik te betwijfelen (ik kan me voorstellen dat tijdens de installatie/updaten dat het wel iets sneller is), maar of m'n lampen daar sneller mee aan of uit gaan of m'n radiatorknoppen sneller reageren kan ik me niet voorstellen.

Ter achtergrond: Ik heb ongeveer 15 Zigbee lampen, 5 zwave radiatorknoppen, 4 zwave rookmelders/COmelder, 5 zwave bewegingsensoren, 1 zigbee bewegingsensor, 8 zwave 'slimme stekkers', een zelfgemaakte Zwave-slimme deurbel, een aantal zwave-afstandsbedieningen (voor aan de muur) en verder nog wat IPverbonden-meuk (al dan niet in de cloud (tot mijn frustratie)). Ik kan niet echt inschatten of dit 'veel', 'weinig' of gemiddeld is, maar dit is wat ik op het moment (nodig) heb. Ik heb in elk geval geen moment het gevoel gehad dat m'n installatie het er zwaar mee heeft.

Je lampen gaan er niet sneller mee aan, want als het eenmaal draait dan is de load op het systeem niet hoog. Maar, wat jij ook al zegt, als je na een bepaalde configuratie wijziging HA moet herstarten dan merk je echt wel een groot verschil. Als je je hele machine herstart is het echt een levensgroot verschil. Zelfs die relatief trage NUC die ik linkte start de boel binnen 30 seconden weer op (inclusief zwave, nodered, mqtt, etc) terwijl toen ik nog een RPi gebruikte dat soms wel eens 5 minuten kon duren. Toegegeven, er gaan weken voorbij dat je dat niet nodig hebt. In de probeer fase als je net begint of bezig bent met een nieuwe integratie is dat echter iets waar je vrij snel knettergek van wordt.

Nou ja. Precies dat dan. Een pi4 volstaat dan prima. Die is in ongeveer een minuutje klaar met herstarten, inclusief zwave/nodered/enz. Op die pi2, geef ik direct toe dat het bijzonder vervelend was. En inderdaad: als je een aantal keer achter elkaar opnieuw moet opstarten, omdat je hebt zitten prutten in de config bestandjes is dat vervelend, maar zo vaak hoef je tegenwoordig niet meer opnieuw op te starten. Als je eenmaal een complete werkende installatie hebt, eigenlijk alleen maar als er een update voor een HACS-module is, of een update voor HA zelf (die al-dan-niet belangrijk is voor de betreffende installatie) en in die context vind ik het het extra bedrag niet waard. Maar dat is persoonlijk.

Als ik ook nog een ander doel voor een NUC zou hebben zou ik het zeker overwegen, maar die heb ik op dit moment niet

En nog een keer terug te komen. Wat versta je onder stabieler?

[Reactie gewijzigd door lenwar op 24 juli 2020 08:37]

Stabieler: die RPi hebben (hadden?) altijd problemen met dat ze soms uit het niets een reboot kregen of gewoon niks meer deden tot ze even stroomloos gemaakt werden. Nog steeds lees je dat op de fora voorbijkomen. Niet iedereen heeft het en het schijnt ook te helpen om een grotere of vooral betere voeding aan te sluiten dan die je er soms bij krijgt of die je nog had liggen van iets anders.
Een systeem wat soms opeens uit het niets stopt met werken noem ik niet stabiel. Ik bedoel dus niet dat er soms opeens een lamp wel of niet aangaat, dat zou raar zijn.

Maar goed, ik heb geen ervaring met de RPi3 en 4, ik was het al eerder zat en heb zo'n NUC gekocht met een SSD erin die ook mooi als NAS speelt voor mijn foto's (gewoon wat SMB shares). Nooit meer problemen gehad en in mijn ogen een goeie investering.

Ah, zo bedoelde je het. Het klopt inderdaad dat raspberry pis redelijk gevoelig zijn voor te zwakke (of 'gare') voedingen. Ik dacht te lezen dat HA zelf niet stabiel (of minder stabiel) was op een pi (in vergelijking met een NUC). De hardware heeft inderdaad een goede voeding nodig. Eigenlijk geldt dit voor elk stuk hardware. Alleen krijg je bij de meeste hardware er een (goed genoege) voeding bij en bij pi's moet je hem zelf erbij halen (over het algemeen). Dit is iets waar inderdaad veel mensen mee nat gaan.
De eerste versie van de pi 1 B had minimaal een 1.1A voeding nodig, maar de meeste mensen hadden 'slechts' een 1.0A voeding. Hij startte wel, maar als hij het te lang druk had werd hij inderdaad instabiel. (de Raspberry pi club adviseert op dit moment een 1.2A voeding)

Zelfde met de pi4. Daar wordt een 3A voeding voor geadviseerd.
https://www.raspberrypi.o...spberrypi/power/README.md

Maar goed. Ik snap dat als je ervaring is, dat je pi's steeds crashen, dat je ze snel zat bent Want juist iets als HA moet het 'gewoon doen'.

Wil nog even zeggen dat alles gelukt is! Had nog een oude laptop (2012) met zelfs een 128 GB SSD liggen. Ubuntu 20 desktop geinstalleerd, deze handleiding gevolgd: https://community.home-as...-on-ubuntu-18-04-4/200020

Enige wat niet hetzelfde als dat handleiding was is het `systemctl disable ModemManager` gedeelte, dat moest `systemctl disable ModemManager.service` zijn, althans, dat denk ik

Inmiddels ook de Neo Coolcam 16A toegevoegd https://i.imgur.com/khoNmGX.png

Generic Linux install!

Ja, die heb ik als het goed is nu al, maar die is niet supervised.

Dan heb je niet de juiste, ik draai um ook en is supervised.

OK, dan gaan we het nog eens bekijken 👍

Zou je toch aanraden hassio erop te installeren. Misschien eerst even een nieuw sd kaartje regelen dan kan je altijd weer terug naar pi hole. Maar zodra je hardop hebt kan je de pi hole add-on installeren (of beter nog de adguard).
Om niet kwijt te raken wat je al gedaan hebt is het makkelijkste een backup van je configuratie.yaml te maken en die na de nieuwe install terug te zetten

Het heet tegenwoordig geen hassio meer, maar goed, men begrijpt wel dan tenminste wat je bedoelt.
Ander belangrijk punt wat ik merkte toen ik nog vanaf een Pi draaide is dat een goede voeding erg belangrijk is. Als ik lees dat @KoalaBear84 ook undervoltage warnings heeft, dan kan dat ook instabiliteit veroorzaken.
Inmiddels draai ik Hass via een 2e hands-laptop in een virtual machine, nadat ik al meerdere keren problemen had met (volgens mij goede kwaliteit?) SD-kaartjes. Voordeel: meteen een ingebouwde UPS. Ik heb het niet zelf verzonnen, volgens mij draait een van de core developers (Frenck) het ook zo.

Wat @Ballenbakz omschrijft zou ik ook doen. Persoonlijk zou ik Pi-Hole laten vallen en voor AdGuard gaan, dit is een officiele addon die je kan installeren binnen home assistant, werkt net zo goed en is op deze manier makkelijk te beheren.

Ik heb HASS.io een paar jaar geleden geprobeerd (toen in Domoticz beu was) maar kwam er al snel achter dat al dat scipten mij te lang duurde (en wanneer je een typo maakt dat je dan uit moet gaan zoeken hoe je je setup kan recoveren.)
Is dit inmiddels verbeterd, hence is het al iets meer dummy proof?

Ik gebruik nu Homey met een hele bak aan flows en heel veel (al dan niet ingebouwde) devices (zigbee, zwave,...)

Home Assistant (zoals hass.io tegenwoordig heet (het is een beetje verwarrend, maar dat was de keus )) is tegenwoordig vrijwel volledig vanuit de web interface/app te configureren. Je hoeft bijna niks meer in de yaml bestanden te doen als je dat niet wilt. (je hebt wel de keus overigens om dit te doen en is voor een aantal zaken wel flexibeler)

Ik ben zelf een half jaar geleden van Homey afgestapt naar HA, en zie het wel echt als een verademing. Veel flexibeler in het gebruik. Waar ik bij Homey vele flows nodig had en moest tobben in een app of brakke web interface, doe ik hetzelfde in minder dan een kwart van de automations. Alles reageert ook sneller (als ik op een knop druk, gaat m'n lamp daadwerkelijk sneller aan/uit)

Toegegeven. De Homey hardware is natuurlijk ook alweer wat jaartjes oud, dus het snelheidsverschil kan daar in zitten.

Wat ik ook fijn vind, is dat ik op geen enkel vlak afhankelijk ben Cloud (waar je bij Homey nog altijd een internetverbinding nodig had voor bepaalde zaken), en het inconsistent is qua app/web interface gebruik. Voor sommige dingen moet je de app gebruiken, voor andere dingen moet je een web interface gebruiken die niet lekker op een telefoon werkt. Met HA, werkt alles gewoon op zowel de telefoon, tablet, desktop en zonder afhankelijkheid van Cloud/internet als je dat niet wilt.

Mocht je interessant vinden:
Dit is mijn 'afscheidspost' op het Homey forum, met de redenen waarom ik weg ben gegaan (en heb er dus geen seconde spijt van gehad)
https://community.athom.com/t/thanks-for-all-the-fish/28300

Ik gebruik NodeRed voor alle opzet van mijn scripts & automatisaties. Veel makkelijker dan the build-in via yaml code.

Het was al een mooi stukje software maar wordt steeds prachtiger.
En zit nog zoveel potentie in. Benieuwd hoe we er over 10 jaar aan toe zijn!

Absoluut, ben ook helemaal verslaafd eraan geworden.
Eerst begonnen met Domoticz maar die werd steeds instabieler door de hoeveelheid Zigbee en z-wave spullen, daarna gemigreerd naar Home Assistant.
Ondertussen is het hele huis hier -tot extreem aan toe- geautomatiseerd en nog steeds vind je dingen die beter/mooier/anders kunnen.

Net begonnen met HA op een oude NUC. Via MQTT al m'n Homey apparaten gekoppeld en nu bezig om er een mooi dashboard van te maken. Als ik de patchnotes lees moet ik me toch echt eens gaan verdiepen in de automation. Het ziet er mooi uit.

Ja, ideaal. Vanwege eerdere beperkingen (en er zijn er nog steeds wel een aantal) eerst heel veel in Node-RED geautomatiseerd, maar ondertussen weer helemaal terug naar HAS automations.
Zeker nu met auto mqtt discovery op mijn Tasmota devices begint Home Assistant nog meer de ideale all-round oplossing te worden.

Ik heb zelf m'n homey in z'n geheel vervangen met ha. Alles werkt een stuk vlotter. De reactiesnelheid is aanzienlijk beter. De automations zijn 100x flexibeler, en het feit dat je niet perse op een telefoon of functioneel halfbakken site hoeft te prutten is echt een verademing.

Heb je ook zigbee, zwave en 433mhz ondersteuning?

Ik heb Zigbee en Zwave spullen. Ik ben bewust van m'n 433-spul afgestapt (werkte te traag. Althans. Ik had spullen van KAKU) Ik heb m'n KAKU knoppen/schakelaars allemaal vervangen met zwave knoppen/schakelaars. (ik had dat al gedaan toen ik Homey nog gebruikte)

Dit is mijn afscheidsberichtje van Homey mocht je geïnteresseerd zijn
https://community.athom.com/t/thanks-for-all-the-fish/28300

Grappig, sinds dat Homey begonnen was tot ongeveer een jaartje geleden heb ik al meerdere keren BIJNA op de "koop" knop gedrukt om een Homey te kopen.
Maar iedere keer had ik m'n twijfels over de bediening, en las ook veel pro's en con's.
Uiteindelijk ben ik overgestapt van Domoticz naar Home Assitant en in het begin was het aardig wennen maar nu ben ik blij -en zeker nadat ik jouw afscheidsbrief gelezen heb- dat ik nooit aan de Homey begonnen ben.

Kaku zooi heb ik trouwens ook allemaal weggedaan (toevallig gisteren de laatste 433mhz plafondventilatoren omgebouwd naar iFan03's)
Naar mijn mening is KaKu gewoon zeer slecht voor een huisautomatisering gezien het geen ACK terug stuurt na het sturen van een commando, je weet nooit zeker of het commando wel goed ontvangen en uitgevoerd is.

Qua snelheid icm de Action/Tuya aansturing is het in de interface ook verbeterd
Waar er van de week nog 'getwijfeld' werd ( aan ? nee, ohw toch wel ) vertraging van soms een seconde

Gaat het nu vrijwel instant, lampen en smartplugs reageren direct op de HA insterface

Blijft de toggle ook goed staan als die weer uitgaat? voorheen was het probleem dat wanneer je iets aanzette het wel aanging echter bleef de toggle uit staan. Hier zat een vertraging in van minuten.
Op Github zijn hier een aantal topics voor geopend, ik heb dus om dit op te lossen via HACS een custom TUYA repository geinstalleerd en de officiciele verwijderd. De Tuya lampen gaan nu dus via deze repository zonder enige vertraging.

De switches blijven inderdaad nu wel staan

@riddick54
Ik heb er vorig jaar een paar geflashed, maar kreeg het via MQTT toch nét niet helemaal soepel werkend
( er is ook nog een WAF factor )

Dus het risico maar nemen dat de Chinezen mijn in en uitschakel gedrag analyseren.
( en binnenkort zullen ze ook nog weten wie en wanneer ze aan mijn deur staan, door de cam-bel )

Ik heb al mijn Tuya apparaten via Tuya-convert naar Tasmota geflashed, over-the-air, dus zonder apparaat te openen. Zo worden ze nu via MQTT rechtstreeks aangestuurd en gaat niks meer via de Tuya cloud.
Jammer genoeg lijkt dit niet meer te werken op recente Tuya apparaten.

[Reactie gewijzigd door GoBieN-Be op 23 juli 2020 16:07]

Klopt, en er schijnen nu ook nieuwe batches in de action te liggen.
Heb aantal weken aantal ongeopende lampen gehaald maar geen flash success...

Laat ze nu dus maar via Tuya cloud lopen, als ze de geest geven stap ik wel over naar Zigbee lampen.

De toestellen van LSC (Tuya) zijn makkelijk te flashen met MQTT. Dan moeten die niet meer over het internet connecteren met de api van tuya. Die lijkt vaak traag te werken zoals je hier zegt.

Het script om een alternatieve firmware te flashen (ietswat linux kennis is vereist)
https://github.com/ct-Open-Source/tuya-convert

Hier vind je templates om de ESP 8266 GPIO pins zelf te configureren
https://templates.blakadder.com/

Op deze manier heb je zelf controle over je devices, voor moest Tuya er ooit mee stoppen of hun api afsluiten voor de tweakers.

Dit werkt niet voor alle LSC Tuya apparaten aangezien ze niet allemaal 8266 chips bevatten en als dit wel het geval is moet je vaak gaan solderen aangzien de OTA exploit patched is bij de de meeste versies.
Heb een aantal laatst nieuw gehaald bij de action maar bij geen was het mogelijk om ze via OTA te flashen.

Deze methode werkt niet meer. Alleen als je nog een oude batch hebt werkt het nog.
Tuya heeft de firmware aangepast waardoor convert niet meer lukt.
Misschien zijn er handig tweakers die deze devs kunnen helpen

zie:
https://github.com/ct-Open-Source/tuya-convert/issues/483

Klopt, ik heb er ook een paar nieuwe LSC lampen gaan halen vorige week. Bij één lamp kon ik flashen via tuya convert, de ander moest ik solderen ...
Je kan het zien op de verpakking. Er staat in het klein naast de productcode V2 bij de nieuwe batch.

Ik heb proberen te sniffen op mijn netwerk maar kon ook die PSK key nog niet te pakken krijgen.

Even een kleine vraag, een paar maanden terug wilde ik opnieuw hassio installeren op docker(met Supervisor), hierdoor kon ik heel makkelijk addons installeren en beheren met portainer. Ineens ondersteunde home assistant, hassio op docker niet meer.

Weet iemand of dit wellicht veranderd is?

overigens: zelf ben ik geen linux fan, ik kan er gelukkig wel mee werken. Door de volgende oplossing toe te passen creëer je een stabiel systeem mee. Windows 10 pro installeren met wsl2.

Je moet je afvragen welke addons je daadwerkelijk gebruikt in home assistant?
Bij mij waren dat er eigenlijk geen één, alle addons kun je ook zelf installeren via docker .

Alleen de configurator addon mis ik, hiermee kan je via de browser config bestanden aanpassen.

Ik draai nu de kale docker installatie van home assistant, de supervised installatie gaf mij te veel problemen met updates die niet goed gingen.Tijdens het update vergat home assistant regelmatig om de supervisor te update, en dan werkt niks meer.

Met name wil ik de zigbee2mqtt addon gebruiken ( deze is makkelijk in docker te draaien), maar hier en daar zie ik addons staan die ik graag 'eenvoudig' zou willen testen.

heb net wel even gekeken. Het is mogelijk om hassio in docker te draaien, helaas zonder officiële support

Ik ben in maart begonnen met Domoticz+Zigbee.
Eerst onder Windows en toen naar Linux overgestapt om dat Windows slecht wordt ondersteund en je iedere instructie moet vertalen naar een Windows situatie.
Inmiddels draait het onder Unbunt (op Vmware ESXi) echt als de brandweer en echt stabiel.
Ik gebruik Blockly om snel scripts in elkaar te draaien, omdat ik niet de tijd kan vinden om een scripttaal te beheersen.

Na deze lange intro, waarom zou een overstap naar HA een verademing/beter zijn?
En kan je HA naast Domoticz draaien, zo dat je langzaam aan kan migreren (als het de moeite waard is ;-) ) ?

In mijn geval werd Domoticz instabiel (moest 'm minimaal 1x per week herstarten) door het grote aantal Z-Wave en Zigbee apparaten dat ik heb.
En ja, je kan migreren, alleen heb je (als je z-wave gebruikt) wel 2 z-wave sticks nodig, 1 voor Domoticz en 1 voor Home Assistant.
Als je Philips Hue gebruikt met de Bridge, die kan je gewoon aan Domoticz en aan Home Assitant samen koppelen.
Gebruik je een USB Zigbee stick, dan hetzelfde verhaal als de z-wave stick.
Op deze manier heb ik het ook gedaan, en ik bewaar nu de 2e z-wave stick als backup voor de 1e (ik heb ook een volledige backup gemaakt van de 1e en die op de 2e gezet)

En waarom HA een verademing is, sneller, stabieler, meer mogelijk, Node Red (soort Blockly maar dan véééél uitgebreider), het volledig kunnen indelen van de Interface, maar dan ook echt volledig naar eigen wens en ongetwijfeld dingen die ik nu vergeet omdat het al een aardige tijd geleden is dat ik met Domoticz heb gewerkt.

[Reactie gewijzigd door Goldwing1973 op 23 juli 2020 13:34]

Dank je wel, dit is informatie waar ik naar opzoek ben!!!!

Vooral de laatste maanden is home assistant echt volwassen aan het worden. Iedere update geeft nu meer snelheid en stabiliteit. Het herstarten van home assistant voor iedere wijziging is nu in ene keer niet meer zo vervelend omdat het nu erg snel herstart.

Nu nog alle integraties die je nu nog in het configuratie bestand moet toevoegen in de interface verwerken en dan is het redelijk gebruiksvriendelijk.
De meeste houden niet van commandline werk en zullen hierdoor een ander pakket kiezen.