Home Assistant - Open source Python3 home automation

[DeadMetal]

Imperial Guard schreef op maandag 26 augustus 2019 @ 17:17:
[...]
Whoa welke wekker heb je? Werkt het ook andersom wanneer je een tijd op je wekker instelt dat je die waarde zou kunnen gebruiken in HomeAssistant?

De Logitech Squeezebox Radio. Ik kan hem overigens niet aanbeleven, veel ellende mee gehad. En het nieuwste probleem is dat de wekker uberhaupt niet meer afgaat, ook niet meer als ik hem op het apparaat zelf instel. M'n nieuwe idee is daarom om een Denon Heos speaker die ik nog heb op de slaapkamer te zetten en hem via HA op het gewenste tijdstip aan te laten gaan (hoe laat het is kan ik dan wel op m'n telefoon zien) om een playlist af te spelen. Nog even op HA 0.98 wachten die een noodzakelijke bugfix gaat bevatten.

Met je telefoon zijn er ook wekkermogelijkheden, ik gebruik Android. Wat ik al heb is dat mijn telefoon op een vast tijdstip aan HA vraagt hoe laat de wekker morgen moet gaan, en dat hij die dan instelt op de telefoon. Dit m.b.v. Tasker die een HTTP-call uitvoert. Wel met de legacy api-key helaas, ik heb het nooit werkend gekregen met de nieuwere access tokens.

Andersom kan Tasker ook uitlezen wat de eerstvolgende ingestelde wekkertijd is en die aan HA doorgeven, met de Clocktask plugin. De Android HA app Ariela kan dit misschien ook.

@lolgast bedankt voor je code voorbeeld, zal het eens gaan bekijken binnenkort. Ik heb het overigens nu al werkend in Node-Red, maar omdat ik vermoed dat een bepaalde module die ik daarbij gebruik voor problemen zorgt, wil ik kijken of ik HA op het specifieke tijdstip iets kan laten afvuren. De vervolg logica komt dan wel weer in NR.

[martinvdm]

@DeadMetal misschien ff out of the box gedacht maar je kan met de nieuwe IOS app ‘critical notifications’ doen met een eigen sound. Wellicht je kun dan hiermee gewoon je smartphone gebruiken en het centraal vanuit HA regelen.
https://companion.home-as...xt/notifications/critical

[ANdrode]

lubbertkramer schreef op maandag 26 augustus 2019 @ 20:31:
[...]


Precies daarom zit er geen watchtower op kritieke containers maar wil ik hierbij zelf in control zijn naar welke versie ik ga. Dat is inderdaad wel een foutje want het is echt een dev release

Ze zijn bezig met de tags en met de base image (het gaat naar de hass, alpine gebaseerde, base image toe vanaf debian).

Ik wacht hem rustig af. Ik weet dat ik bepaalde software niet draaiend krijg in een alpine container door musl libc. Hoop dat er bij mensen door deze switch niet teveel omvalt.

[sterremos]

Balen, vandaag bezig geweest met mi plant care in Hassio, daarvoor was een reboot nodig, en nu geen verbinding meer, krijg het startscherm niet meer te zien, paar keer gestart maar niets. kan wel pingen naar de PI. ook in het IP overzicht zie ik Hassio staan.

was lekker bezig, moet ik weer alles opnieuw gaan instellen? ik kan wel via SSh een link leggen maar kan niet inloggen.

wat kan ik nog doen in deze?

Ron

[GENETX]

@DeadMetal
Ja, of je gaat lekker aan de slag met AppDaemon. Heerlijk scripten met Python en alle ruimte om lokaal variabelen bij te houden. Ik heb ongeveer hetzelfde. Een "wekker" element in mijn agenda. Vanaf dat moment gaat mijn lamp als een soort Philips WakeUp Light langzaam aan in 20 minuten tijd. Halverwege wordt mijn Google Home Mini voorzien van een radiozender om wakker te worden

Python:

import appdaemon.plugins.hass.hassapi as hass
import time
import datetime as dt

class WekkerApp(hass.Hass):
    def initialize(self):
        self.brightness = 0
        
        self.listen_state(self.wekker_sleeping, "input_boolean.phone_charging", old="off", new="on")
        self.listen_state(self.wekker_wakingup, "input_boolean.phone_charging", old="on", new="off")
        self.listen_state(self.agenda_changed, "calendar.wekker", old="off", new="on")
        
    def agenda_changed(self, entity, attribute, old, new, kwargs):
        scene = self.get_state("input_select.scene")
        if self.get_state("calendar.wekker") == "on" and scene == "Slapen":
            self.turn_on("light.slaapkamer_dim", brightness=1)
            self.run_in(self.delay_sleep, 30)
            self.run_in(self.delay_radio, 605) # Turn on radio in 10 mins
        
    def wekker_sleeping(self, entity, attribute, old, new, kwargs):
        scene = self.get_state("input_select.scene")
        hour = dt.datetime.now().hour
        
        if scene != "Weg" and scene != "Slapen" and (hour >= 22 or hour < 6):
            self.select_option("input_select.scene", "Slapen")
            self.brightness = 0.0
            self.turn_off("media_player.slaapkamer")
        
    def wekker_wakingup(self, entity, attribute, old, new, kwargs):
        scene = self.get_state("input_select.scene")
        hour = dt.datetime.now().hour
        
        if scene == "Slapen" and (hour >= 6 or hour < 22):
            self.select_option("input_select.scene", "Thuis")
            self.turn_on("light.slaapkamer_dim", brightness=255.0) # add delay

    def delay_sleep(self, kwargs):
        self.brightness += 26.0
        if self.brightness < 255.0:
            self.turn_on("light.slaapkamer_dim", brightness=self.brightness) # add delay
            self.run_in(self.delay_sleep, 120)
        else:
            self.turn_on("light.slaapkamer_dim", brightness=255.0)

    def delay_radio(self, kwargs):
        # Play 538 :)
        self.turn_on("media_player.slaapkamer")
        self.call_service("media_player/play_media", entity_id = "media_player.slaapkamer", media_content_id="http://playerservices.streamtheworld.com/api/livestream-redirect/RADIO538.mp3 ", media_content_type = "audio/mp3")

Let wel op dat ik ook eht een en ander aan mijn "telefoonroutine" heb gekoppeld. Na 10 uur 's avonds aan de lader -> slaap modus actief in huis. Er wordt meer getriggered bij mij op de "scene", wat een soort van Linux Runlevel voor mijn huis is . De brightness += 26 is een stapgrootte die bij de crappy MiLight in de slaapkamer goed werkt voor mij na wat trial and error.

[RevellNL]

Verwijderd schreef op maandag 26 augustus 2019 @ 17:48:
[...]


Ik heb een willekeurige andere port open gezet / geforward naar HASS. Kans dat er een exploit is die alle poorten gaat scannen schat ik als nihil...

Volgens mij zijn random portscans juist een van de dingen die aan de orde van de dag zijn en die je zo ontzettend makkelijk even aanslingert..

[Verwijderd]

RevellNL schreef op dinsdag 27 augustus 2019 @ 08:56:
[...]

Volgens mij zijn random portscans juist een van de dingen die aan de orde van de dag zijn en die je zo ontzettend makkelijk even aanslingert..

Portscans wel. Vulnerability scans ook. Zag er honderden per dag op m'n unix-firewall. Maar altijd ssh op poort 22, httpd op poort 80 etc. Alle 64.000 poorten scannen om te kijken of er ergens een kwetsbare versie van HASS draait lijkt me érg onwaarschijnlijk. Tenzij het een gerichte aanval is natuurlijk.

[RevellNL]

Verwijderd schreef op dinsdag 27 augustus 2019 @ 09:05:
[...]


Portscans wel. Vulnerability scans ook. Zag er honderden per dag op m'n unix-firewall. Maar altijd ssh op poort 22, httpd op poort 80 etc. Alle 64.000 poorten scannen om te kijken of er ergens een kwetsbare versie van HASS draait lijkt me érg onwaarschijnlijk. Tenzij het een gerichte aanval is natuurlijk.

Het zou een goede kandidaat kunnen zijn om iets van een botnet te creëren, scans uitvoeren om slecht beveiligde HASS instanties te vinden en daar dan b.v. verschillende scrape automations op instellen o.i.d.

Ik zou i.i.g. niet willen zeggen dat je ervan uit kunt gaan dat het veranderen van de standaard poort in een random poort iets van security toevoegt.

[ Voor 10% gewijzigd door RevellNL op 27-08-2019 09:13 ]

[Verwijderd]

RevellNL schreef op dinsdag 27 augustus 2019 @ 09:12:
[...]
Het zou een goede kandidaat kunnen zijn om iets van een botnet te creëren, scans uitvoeren om slecht beveiligde HASS instanties te vinden en daar dan b.v. verschillende scrape automations op instellen o.i.d.

Ik zou i.i.g. niet willen zeggen dat je ervan uit kunt gaan dat het veranderen van de standaard poort in een random poort iets van security toevoegt.

Ik zou gaan voor kwetsbare WordPress installaties, zijn er miljoenen van

Draaide jaren Apache op mijn ontwikkelmachine die open stond zodat klanten dev-versies konden testen. Op poort 80 continu rare requests. Op poort 8080 een stuk minder. Op een willekeurige poort geen. Echt veiliger wellicht niet, de gelegenheids Bot / Worm leidt het wel om de tuin blijkbaar.

Standaard portscans zijn overigens eenvoudig te detecteren. Zit volgens mij in veel routers ingebakken. Als je dat combineert met een willekeurige poort zit je veilig. Krijg zelf ook een alert als de server load te hoog is. Dus lomp geschreven malware valt vrij snel op.

[ Voor 13% gewijzigd door Verwijderd op 27-08-2019 09:36 ]

[GENETX]

Of je gooit Traefik er tussen met een niet te raden subdomein: https://docs.traefik.io/ . Al weet ik niet hoe dat samen gaat met HASS. Ik heb HA in een eigen Docker container draaien en Traefik daar naast.

[ Voor 45% gewijzigd door GENETX op 27-08-2019 09:37 ]

[Hmmbob]

Traefik + HA beiden in een docker hier - werkt prima, met Traefik weer open op een random (maar mij bekende) poort.

In HA 2FA op de user accounts, en failed login ban op heel laag ingesteld (kan via VPN namelijk bij de Pi via SSH als ik mezelf moet unlocken).

[ Voor 66% gewijzigd door Hmmbob op 27-08-2019 09:46 ]

[GeleFles]

De poort maakt niet zoveel uit, er zijn genoeg scanners die zoeken op de http response:
https://www.shodan.io/search?query=Home+Assistant

Een niet standaard poort gebruiken zal best wat hits schelen, maar nog steeds niet optimaal.
failed login ban is in ieder geval een hele goede om te gebruiken, maar let op dat als er een vulnerability bekend word waarbij het inlogformulier niet gebruikt word, je alsnog de sjaak bent.

Nabucasa ziet er uit als een goede oplossing; nog steeds niet risicovrij, maar ik denk dat ik die route liever kies boven het zelf openzetten van poorten.

[RevellNL]

@Verwijderd @GENETX @Hmmbob Ik zeg niet dat je het helemaal niet moet doen, ik probeer alleen te zeggen dat je het niet moet zien als security maatregel waarbij je verder niets extra's zou hoeven doen. Vaak lees je dit soort dingen als "oplossing" en als je dan verder niet veel kennis hebt over hoe de boel werkt en je pakt dit als oplossing dan kun je voor nare verrassingen komen te staan.

Als je je installatie open zet naar het WWW, pak er dan zoveel mogelijk andere security maatregelen bij, zoals de genoemde 2FA, fail2ban, vooraf ingestelde IP-ranges met toegang, etc.

[Hmmbob]

RevellNL schreef op dinsdag 27 augustus 2019 @ 10:09:
@Verwijderd @GENETX @Hmmbob Ik zeg niet dat je het helemaal niet moet doen, ik probeer alleen te zeggen dat je het niet moet zien als security maatregel waarbij je verder niets extra's zou hoeven doen. Vaak lees je dit soort dingen als "oplossing" en als je dan verder niet veel kennis hebt over hoe de boel werkt en je pakt dit als oplossing dan kun je voor nare verrassingen komen te staan.

Als je je installatie open zet naar het WWW, pak er dan zoveel mogelijk andere security maatregelen bij, zoals de genoemde 2FA, fail2ban, vooraf ingestelde IP-ranges met toegang, etc.

Defense in Depth

[renedis]

Over de poort discussie.. Ik heb ook Fail2Ban geinstalleerd voor de zekerheid. Alles verloopt bij mij via HTTPS met een SSL certificaat en een HTTP-->HTTPS verwijzing. Maar toch Fail2Ban er bij voor de portscans op meerdere poorten.

[lolgast]

Wat @Hmmbob zegt + IP whitelisting voor poort 22 op de Unifi firewall.

Door Traefik te gebruiken kom je via poort 80/443 niet uit bij HA, maar bij Traefik. Traefik (of elke andere goed geconfigureerde reverse proxyserver) stuurt je alleen door als je de juiste URL invoert.

---

Móchten ze in mijn HA komen, dan is dat natuurlijk vervelend voor mij en gebeuren er misschien vreemde dingen met mijn verlichting, maar ik heb precies om die reden geen slimme sloten of andere zaken die via HA toegang tot mijn huis zouden kunnen vereenvoudigen. Toegang tot een huis behoort in mijn ogen alleen analoog te zijn. Die methode is al kwetsbaar genoeg, als je daar nog een manier aan toevoegt wordt het in mijn ogen niet veiliger.

[Hmmbob]

^^^ precies dat.

Bij eventuele toegang tot HA kan het een disco van de verlichting of warme temperatuur worden bij mij thuis - verder wordt er niets aangestuurd.

[GeleFles]

Let wel op dat HA een mooie pivot kan zijn je thuis netwerk in.
Het is op de achtergrond gewoon een linux machine, via die weg zou een hacker je lokale netwerk ook onder de loep kunnen nemen.
Kans is klein omdat het dan een hoop meer werk kost voor de hacker, maar wel iets om in je achterhoofd te houden. (En daarom je interne netwerk ook altijd goed beveiligen)

[Jelte]

Ik zoek een tutorial voor Traefik en hassio, maar kan er niet eentje vinden die daar op is toegespitst. Weet iemand er één of is deze goed genoeg:
https://blog.linuxserver....everse-proxy-with-docker/

(ja ik hassio draaien op een ubuntu server met docker erbij)

Of werkt dit ook, ook al lijkt de code al een hele tijd niet geüpdatet: https://github.com/MrRaph...tree/master/traefik-proxy

[ Voor 19% gewijzigd door Jelte op 27-08-2019 13:02 ]

[lolgast]

@Jelte Dit voldoende?
lolgast in "Home Assistant - Open source Python3 home automation"

[GENETX]

Dit zou moeten werken gok ik:
https://community.home-as...assio-and-traefik/58250/5

Normaliter kun je de config in je docker compose file zetten. Maar ik neem aan dat je home-assistant niet in een docker container draait als je hassio gebruikt, dus moet je de Traefik config dus handmatig doen. Hier zit ook het verschil met de config van lolgast.

[ Voor 58% gewijzigd door GENETX op 27-08-2019 13:06 ]

[dicespark]

Oeh interessant. Ik ben ook aan het kijken geweest naar Traefik, maar vraag me af of ik dat 'nodig' heb als ik Hass in Docker in Synology draai, omdat die een eigen reverse-proxy kan zijn (toch?).

[Jelte]

dicespark schreef op dinsdag 27 augustus 2019 @ 13:15:
Oeh interessant. Ik ben ook aan het kijken geweest naar Traefik, maar vraag me af of ik dat 'nodig' heb als ik Hass in Docker in Synology draai, omdat die een eigen reverse-proxy kan zijn (toch?).

Ja die kan dat zeker, heb ik een tijdje zo gedaan.
Maar Traefik is aardig automatisch, dus ben benieuwd of dat voor me zou kunnen werken. Dus wilde het proberen, maar een goede tutorial vinden was wat lastig.

Ik ga hem proberen @lolgast

[lolgast]

Traefik op Synology heeft een extra uitdaging: Synology services binden poort 80 en 443. Daardoor kan de Traefik container niet gestart worden

[Jelte]

@lolgast Ik zie dat je HA in docker hebt draaien. Dat is met hassio iets anders. Daar heb je geen docker-compose voor de verschillende containers. Hoe is dat op te pakken? Heb je een idee? Of is daar die addon waar jij (@GENETX )mee komt genoeg voor?
Natuurlijk met de rules, maar dan kan ik net zo goed bij nginx blijven.

[ Voor 10% gewijzigd door Jelte op 27-08-2019 13:33 ]

[GENETX]

Zie mijn post hierboven. Traefik in een container draaien en dan zelf de config aanmaken ipv deze door traefik te laten genereren op basis van de docker compose labels.

Edit: Ik zie nu dat het laaatste stukje van lolgast hier ook grotendeels op ingaat overigens.

[ Voor 22% gewijzigd door GENETX op 27-08-2019 13:39 ]

[schumi2004]

Ik zit met het volgende.
Ik draai nu HA via Hassio icm zigbee2mqtt en dat werkt als een zonnetje.
Al mijn devices netjes automatisch toegevoegd, niets meer aan doen zou je zeggen.
Ik heb echter 2 Ziaomi Wall Sockets welke ik graag in de light group wil hebben ipv de switch group maar hoe ziet zo'n config hiervoor uit?

Als ik weet hoe de switch config van ee ndevice wat automatisch toegevoegd is eruit ziet kan ik het wel ombouwen maar ik kan dat nergens terug vinden.

Iemand tips of een voorbeeld hoe een zigbee device van switch naar light te krijgen?

[Morphix]

lolgast schreef op dinsdag 27 augustus 2019 @ 13:27:
Traefik op Synology heeft een extra uitdaging: Synology services binden poort 80 en 443. Daardoor kan de Traefik container niet gestart worden

Je kunt in docker-compose andere poorten mappen naar 80 en 443 voor traefik. In Synology kun je die (zelf gekozen) poorten vervolgens wel open zetten. Vervolgens kun je je router zo instellen dat 443 doorgeleid wordt naar je synology poort.

Je maakt een rare omweg, maar het werkt. Ik kreeg zelf de authenticatie daarna helaas niet aan de praat.

[lolgast]

@schumi2004 Je kunt alleen van binary_sensors de deviceclass aanpassen. Jouw vraag kan volgens mij zo beantwoord worden: https://www.home-assistant.io/components/light.switch/

@Jelte Zie het onderste deel van mijn post, zoals ook @GENETX aangaf.

@Morphix Je hebt daarmee ook geen automatische certificaat aanvraag meer, want daarvoor moet Traefik bereikbaar zijn op poort 80 en/of 443. Traefik is voor mij uiteindelijk van doorslaggevende factor geweest om te stoppen met Xpenology en het allemaal zelf te doen

[Jelte]

GENETX schreef op dinsdag 27 augustus 2019 @ 13:36:
Zie mijn post hierboven. Traefik in een container draaien en dan zelf de config aanmaken ipv deze door traefik te laten genereren op basis van de docker compose labels.

Edit: Ik zie nu dat het laaatste stukje van lolgast hier ook grotendeels op ingaat overigens.

Maar dan ben je dus nog aan het configureren in text bestandjes ipv via een GUI, toch? Kan ik beter bij Nginx blijven.
En alles wordt automatisch opengesteld. Dat heb ik liever niet. Jammer dat dat niet in de add-on zit.

Volgens mij blijf ik bij nginx...

[schumi2004]

lolgast schreef op dinsdag 27 augustus 2019 @ 13:44:
@schumi2004 Je kunt alleen van binary_sensors de deviceclass aanpassen. Jouw vraag kan volgens mij zo beantwoord worden: https://www.home-assistant.io/components/light.switch/

<knip>

Dat gaat wel heel eenvoudig, thanks.
* schumi2004 slaat zich tegen het hoofd en vraagt zich af waarom hij dat niet heeft gevonden

[GENETX]

Jelte schreef op dinsdag 27 augustus 2019 @ 13:45:
[...]

Maar dan ben je dus nog aan het configureren in text bestandjes ipv via een GUI, toch? Kan ik beter bij Nginx blijven.
En alles wordt automatisch opengesteld. Dat heb ik liever niet. Jammer dat dat niet in de add-on zit.

Volgens mij blijf ik bij nginx...

Daar heb ik dan weer geen ervaring mee, maar lijkt wel dezelfde functionaliteit te geven inderdaad.

[Jelte]

@GENETX Het is vooral een GUI. Doe liever dingen via een GUI, dan op de server in code duiken die niet heel makkelijk beschikbaar is.

[Troetelbeer]

Ik heb hier thuis een ventilatiesysteem van Renson met een Healthbox 3. Deze is aan te sturen via Wifi en de app. Daarbij heb ik van de fabrikant een "3rd party local API" document gekregen met informatie over hoe het eventueel te integreren is in je domotica systeem.

Ik vind nergens hoe ik in HA een local API kan toevoegen? Iemand anders wel?

[UTMachine]

Troetelbeer schreef op dinsdag 27 augustus 2019 @ 14:12:
Ik heb hier thuis een ventilatiesysteem van Renson met een Healthbox 3. Deze is aan te sturen via Wifi en de app. Daarbij heb ik van de fabrikant een "3rd party local API" document gekregen met informatie over hoe het eventueel te integreren is in je domotica systeem.

Ik vind nergens hoe ik in HA een local API kan toevoegen? Iemand anders wel?

Normaliter zal je hier een custom_component voor moeten schrijven in Python, want elke API is weer uniek.

[Troetelbeer]

UTMachine schreef op dinsdag 27 augustus 2019 @ 14:17:
[...]


Normaliter zal je hier een custom_component voor moeten schrijven in Python, want elke API is weer uniek.

Hmm, dat gaat mijn kennis iets te boven.

In het document staat wel in json hoe ik dingen kan aanroepen, ik hoef alleen het lokale ip adres te veranderen denk ik. Maar weet dus niet hoe ik dat in HA krijg

[RudolfR]

@Troetelbeer

Zoiets:
https://www.home-assistant.io/components/rest_command/

Volgens de docs is het een REST API
http://all-vac.be/allvac%...n_fiche_Healthbox_3-0.pdf

[UTMachine]

Troetelbeer schreef op dinsdag 27 augustus 2019 @ 14:19:
[...]
Hmm, dat gaat mijn kennis iets te boven.

In het document staat wel in json hoe ik dingen kan aanroepen, ik hoef alleen het lokale ip adres te veranderen denk ik. Maar weet dus niet hoe ik dat in HA krijg

Als het 'simpele' JSON calls zijn, zonder sessionid e.d., zou je het kunnen proberen met een REST call (bv https://www.home-assistant.io/components/rest_command/ of rest.switch).

[RobertMe]

lolgast schreef op dinsdag 27 augustus 2019 @ 13:44:
@Morphix Je hebt daarmee ook geen automatische certificaat aanvraag meer, want daarvoor moet Traefik bereikbaar zijn op poort 80 en/of 443. Traefik is voor mij uiteindelijk van doorslaggevende factor geweest om te stoppen met Xpenology en het allemaal zelf te doen

Als je in de router poort 443 forward naar de custom port op de Synology kan het waarschijnlijk toch werken? En als alternatief kun je Traefik ook gebruiken met DNS verification. Dan moet Traefik toegang hebben dat je DNS provider en zet daar de tokens voor authenticatie in. Dan hoef je helemaal geen poorten open te zetten, want dan hoeft Let's encrypt voor de "bevestiging" geen aanroep naar jou Traefik te doen maar controleert die het bestaan van die DNS records.

[Saturnus]

martinvdm schreef op maandag 26 augustus 2019 @ 20:15:
[...]

Ik denk het niet. De nieuwe iOS heeft wel wat meer sensoren maar volgens is die er ook niet daarin.

Jammer. Ik heb het idee dat HA aan de onderkant en bovenkant steeds uitgebreid wordt, maar daar tussen in begint het behoorlijk achter te lopen.

[lolgast]

RobertMe schreef op dinsdag 27 augustus 2019 @ 14:49:
[...]

Als je in de router poort 443 forward naar de custom port op de Synology kan het waarschijnlijk toch werken? En als alternatief kun je Traefik ook gebruiken met DNS verification. Dan moet Traefik toegang hebben dat je DNS provider en zet daar de tokens voor authenticatie in. Dan hoef je helemaal geen poorten open te zetten, want dan hoeft Let's encrypt voor de "bevestiging" geen aanroep naar jou Traefik te doen maar controleert die het bestaan van die DNS records.

Dat is een oplossing voor verkeer vanuit buiten, maar dan kan ik intern mijn services niet via dezelfde url benaderen zonder via mijn router te gaan. Ik heb een eigen DNS server draaien waarmee ik de url naar mijn interne adressen routeer. Als ik jouw oplossing zou toepassen zou ik intern de aangepaste poort van Traefik achter elke url moeten plakken.

[hasseroderman]

Saturnus schreef op dinsdag 27 augustus 2019 @ 14:55:
[...]

Jammer. Ik heb het idee dat HA aan de onderkant en bovenkant steeds uitgebreid wordt, maar daar tussen in begint het behoorlijk achter te lopen.

Huh? Wat bedoel je met onderkant,bovenkant en daar tussen?

[renedis]

hasseroderman schreef op dinsdag 27 augustus 2019 @ 15:40:
[...]


Huh? Wat bedoel je met onderkant,bovenkant en daar tussen?

Hij bedoelt dat er in de GUI (bovenkant) features bijkomen en in de onderkant (code) feautures bijkomen.
Maar daar tussen (huidige GUI/code) er vrij weinig veranderd.

[GENETX]

Wat zou daar dan tussen moeten zitten? Lucht? Ik heb dat idee totaal niet. Het enige waar ik van baal is dat HA by default een in mijn ogen domme ontwerpkeuze heeft gemaakt: De sterke koppeling tussen een apparaat en diens variabelen/triggers...

Dat heeft men bij OpenHAB toch wat beter gedaan vanaf de grond zodat je items, zoals een waarde, switch, selectie, etc. kan koppelen aan een apparaat (thing). Mocht je ooit een lamp of thermostaat vervangen, dan hoef je je rules en automations nie taan te passen. Sterker nog, je logging kan gewoon doorgaan.

Dat in tegenstelling tot Hass waar ik bij de laatste update een vernieuwde Honeywell integration kreeg met automagische naam die ik niet kan overrulen... Fijn, ineens een naamswijziging in de database met historische meetdata, en een search+replace in al mijn automations om ook dat te fixen . Beter zouden ze dat eens oplossen zodat breaking changes iig alleen effect op de integration zelf hebben en NIET OOK op je automations en dataverzameling. Een goed idee zou zijn om op zijn minst bij alles de optie geven om de naam te kunnen overrulen

/rant

[ Voor 4% gewijzigd door GENETX op 27-08-2019 16:16 ]

[Mars Warrior]

GENETX schreef op dinsdag 27 augustus 2019 @ 16:15:
Wat zou daar dan tussen moeten zitten? Lucht? Ik heb dat idee totaal niet. Het enige waar ik van baal is dat HA by default een in mijn ogen domme ontwerpkeuze heeft gemaakt: De sterke koppeling tussen een apparaat en diens variabelen/triggers...

Dat heeft men bij OpenHAB toch wat beter gedaan vanaf de grond zodat je items, zoals een waarde, switch, selectie, etc. kan koppelen aan een apparaat (thing). Mocht je ooit een lamp of thermostaat vervangen, dan hoef je je rules en automations nie taan te passen. Sterker nog, je logging kan gewoon doorgaan.

Hoe herkenbaar. Gebruikte hiervoor ook OpenHAB. Kai heeft over sommige zaken inderdaad erg goed nagedacht, maar was in veel gevallen ook weer meer Koning Kai of Keizer Kai die op geen enkele manier zich iets aantrok van wat anderen vonden

Dat in tegenstelling tot Hass waar ik bij de laatste update een vernieuwde Honeywell integration kreeg met automagische naam die ik niet kan overrulen... Fijn, ineens een naamswijziging in de database met historische meetdata, en een search+replace in al mijn automations om ook dat te fixen . Beter zouden ze dat eens oplossen zodat breaking changes iig alleen effect op de integration zelf hebben en NIET OOK op je automations en dataverzameling. Een goed idee zou zijn om op zijn minst bij alles de optie geven om de naam te kunnen overrulen

Ik heb al vaker wat commentaar geleverd - ook hier in dit topic - over de breaking changes die ontwikkelaars blijkbaar heel normaal vinden en te pas en te onpas gebruiken, zonder - zo lijkt het - ook maar 1 seconde zich druk te maken over de gevolgen voor de gebruikers.

Ik heb dat ook een keer - onder een ander Github pseudoniem - in een architectuur discussie gemeld, maar de reacties zijn in beide gevallen niet echt positief: het is nodig, ik weet niet waar ik het over heb en we werken hard, etc...

Als architect en jarenlang ontwikkelaar van de TV Engine v2 van MediaPortal heb ik natuurlijk ook helemaal geen ervaring in open source teams, en al helemaal geen verstand van het voorkomen van breaking changes die bij een "TV kijk" functie natuurlijk ook helemaal niet relevant zijn

Ik heb die discussie maar opgegeven, immers men is verdomd hard bezig om tot v1 te komen, en dan zijn breaking changes natuurlijk verleden tijd lijkt me Of, als ze er wel zijn zit er bij de upgrade natuurlijk een stukje migratie software die de pijn volledig teniet doet bij de gebruiker

Dus ik bouw en leer lekker verder met alle mogelijkheden van hass, want die zijn enorm groot en blijven ook maar uitgebouwd worden ipv me druk te maken over de keuzes die het team maakt. MQTT voorkomt al een hoop breaking changes, en de voor de rest neem ik ze maar voor lief, doe maar af en toe een update, en ga gewoon lekker verder

[Saturnus]

hasseroderman schreef op dinsdag 27 augustus 2019 @ 15:40:
[...]


Huh? Wat bedoel je met onderkant,bovenkant en daar tussen?

renedis schreef op dinsdag 27 augustus 2019 @ 15:43:
[...]


Hij bedoelt dat er in de GUI (bovenkant) features bijkomen en in de onderkant (code) feautures bijkomen.
Maar daar tussen (huidige GUI/code) er vrij weinig veranderd.

Inderdaad.
https://github.com/home-assistant/architecture/issues/230 als voorbeeld. Hoe gewild het nou is of niet, het is een belachelijk ontwerp. En zo zijn er vele dingen. Zeer vaak moet je een 'hulp' sensor aanmaken om data te kunnen gebruiken of manipuleren. In lovelace bijv. kan je niet states.weather.dark_sky.attributes.temperature gebruiken, nee daarvoor moet je een hulpsensor aanmaken. Dus HA is flexibel, maar niet...flexibel. Misschien lukt het met custom cards of ligt NodeRed daar een niveau boven? Custom cards leuk enz, maar zou vooral visueel gericht moeten zijn, niet te diep bemoeien met de code want dan 'breakt' het met de huidige gang van zaken ook continue, dat hoort al in orde te zijn. NodeRed had ik geen zin in maar met de recente trieste ontwikkelingen begint het misschien een must te worden.

Het zou mij niet verbazen als er met de botte houding van die projectleider nog een keer een flinke ruzie komt en een groep gaat forken.

Voordat we versie 1 zien die de versie 1 tag verdient zullen we eerst 0.99.137 gehad moeten hebben. Ga maar na, wat zijn sinds ~0.88/0.91 nou echt updates geweest waarvan je denkt "wow!" Het is vreemd want aan de ene kant hebben ze die robuuste visie, maar aan de andere kant zitten er fundamentele wanontwerpen in die niet aangepakt worden. Maar van problemen ga je dus weinig last hebben als je aan de GUI-kant blijft zitten en/of het niet te complex maakt, óf zelf met Python aan de gang gaat.

Disclaimer: deze post bevat een mening

[martinvdm]

Yukkie schreef op maandag 26 augustus 2019 @ 20:20:
[...]


Nou...
[Afbeelding]

Ik gebruik de latest image en Watchtower heeft vanmiddag deze release geïnstalleerd. Maar ik denk dat er een foutje is gemaakt bij het taggen van een dev image.

Edit: alles werkt nog overigens, zonder foutmeldingen

Komt een fix aan:
https://github.com/home-assistant/home-assistant/pull/26232

[lolgast]

Mijn manier om hier omheen te werken:

Ik gebruik HA om services met elkaar te laten communiceren met een in mijn ogen minimale frontend. Lampen schakelen, status van de planten en een overzicht van het klimaat in alle kamers. Alle andere informatie is eigenlijk niet nodig voor ons en dus zit het niet in de views voor de telefoons.

Ik automatiseer alles via Node-RED. Zoveel mogelijk buiten HA sensoren om. Het hele idee van home-automation is natuurlijk ook niet om continu met je telefoon bezig te moeten zijn. Het moet automatisch gaan

[hasseroderman]

renedis schreef op dinsdag 27 augustus 2019 @ 15:43:
[...]


Hij bedoelt dat er in de GUI (bovenkant) features bijkomen en in de onderkant (code) feautures bijkomen.
Maar daar tussen (huidige GUI/code) er vrij weinig veranderd.

Ah, bij developers beter bekend als voorkant en achterkant

[Turk]

Ik moet nogsteeds mijn Python versie upgraden voordat ik Home Assistant weer kan updaten.

Alleen zit ik in een virtual enviroment, dus zal even kijken wat nou eigenlijk de beste manier is voor op een RPi3b+.

Moet er binnenkort toch maar echt aan geloven. Overdag maar doen, anders daalt de WAF factor naar een kritieke grens ben ik bang

[martinvdm]

Turk schreef op dinsdag 27 augustus 2019 @ 22:48:
Ik moet nogsteeds mijn Python versie upgraden voordat ik Home Assistant weer kan updaten.

Alleen zit ik in een virtual enviroment, dus zal even kijken wat nou eigenlijk de beste manier is voor op een RPi3b+.

Moet er binnenkort toch maar echt aan geloven. Overdag maar doen, anders daalt de WAF factor naar een kritieke grens ben ik bang

Volgens mij backup maken van je config, je venv verwijderen, python upgrade, nieuwe venv aanmaken, restore config.
Maar ik zou zeker kijken om gelijk naar docker over te stappen, alhoewel en pi3 wellicht wat aan de lichte kant is.

[Verwijderd]

Ik heb van het weekend een nieuwe installatie gemaakt. Laatste versie Raspbian (Buster) Daar zit Python 3.7 standaard in. Config van oude installatie overgezet en, afgezien van wat kleine dingen, draaide alles. 1,5 - 2 uur boek lezen en wat klikken / typen.

Draait op een Pi 2. Oude installatie was de server load erg hoog (1m continue tusssen 2-4, 15m regelmatig boven 3) Draait nu soepel (1m sporadisch boven de 1)

Weet niet of het de Raspbian versie is, de nieuwe Python versie of de update van HASS. Maar goede investering om een nieuwe installatie te maken

[barrymossel]

Verwijderd schreef op dinsdag 27 augustus 2019 @ 23:19:

Draait op een Pi 2. Oude installatie was de server load erg hoog (1m continue tusssen 2-4, 15m regelmatig boven 3) Draait nu soepel (1m sporadisch boven de 1)

Schijnbaar ben ik geen echte Tweaker. Wat bedoel je met dat stukje??

[Verwijderd]

barrymossel schreef op woensdag 28 augustus 2019 @ 00:38:
[...]

Schijnbaar ben ik geen echte Tweaker. Wat bedoel je met dat stukje??

Definieer 'echte tweaker'

Unix houdt de belasting van het systeem bij. Op te vragen via commando 'top' of 'w'. Dit geeft drie getallen. De 'load' in de laatste minuut (1m), laatste vijf minuten (5m) en laatste kwartier (15m)

Een soepel draaiend systeem zou onder de 1 moeten zitten (zo heb ik gelezen) Gaat de 'load' richting 3-4 dan merk je dat inloggen via SSH of commando's uitvoeren in de shell traag gaat. Ik krijg dan ook foutmeldingen over slechte verbindingen met ESP8266 devices en gedropte waarden naar influxdb. Overbelasting van het systeem dus.

Bij mijn oude installatie zat die 'load' / belasting dus continu ruim boven de 1. Zelfs zo hoog en lang dat de gemiddelde waarde over 15 minuten boven 3 uit kwam. Nieuwe installatie komt niet boven de 0.5.

Server load is een combinatie van processor gebruik en io (disk / sd kaart) en nog wat technische dingen waar ik ook het fijne niet van weet.

- Unix-guru's mogen bovenstaande lek schieten / verduidelijken

[barrymossel]

Verwijderd schreef op woensdag 28 augustus 2019 @ 00:54:
[...]


Definieer 'echte tweaker'

Unix houdt de belasting van het systeem bij. Op te vragen via commando 'top' of 'w'. Dit geeft drie getallen. De 'load' in de laatste minuut (1m), laatste vijf minuten (5m) en laatste kwartier (15m)

Een soepel draaiend systeem zou onder de 1 moeten zitten (zo heb ik gelezen) Gaat de 'load' richting 3-4 dan merk je dat inloggen via SSH of commando's uitvoeren in de shell traag gaat. Ik krijg dan ook foutmeldingen over slechte verbindingen met ESP8266 devices en gedropte waarden naar influxdb. Overbelasting van het systeem dus.

Bij mijn oude installatie zat die 'load' / belasting dus continu ruim boven de 1. Zelfs zo hoog en lang dat de gemiddelde waarde over 15 minuten boven 3 uit kwam. Nieuwe installatie komt niet boven de 0.5.

Server load is een combinatie van processor gebruik en io (disk / sd kaart) en nog wat technische dingen waar ik ook het fijne niet van weet.

- Unix-guru's mogen bovenstaande lek schieten / verduidelijken

Lang verhaal kort: nerd

Dank je. Weer wat geleerd!

[GekkePrutser]

Verwijderd schreef op woensdag 28 augustus 2019 @ 00:54:
[...]
Een soepel draaiend systeem zou onder de 1 moeten zitten (zo heb ik gelezen).

Niet helemaal. Het is per core, dus op een 4-core systeem is het niet zo erg als je richting de 4 gaat.

Een raspberry pi 2 is maar 1 core dus daar is het inderdaad zo. Maar op nieuwere niet. Zie hier wat uigebreidere info.

Overigens gebruik ik zelf liever htop. Dat geeft een veel beter idee van wat er op een bepaald moment echt gebeurt, zowel met CPU als met geheugen. gotop is ook mooi, die maakt zelfs een soort grafiekjes. Al geeft de 'load' weer wel een goed overzicht van de overbelasting, bij htop zie je alleen 100%, terwijl je aan de load kan zien hoe veel hij daarboven zit.

[ Voor 10% gewijzigd door GekkePrutser op 28-08-2019 02:29 ]

[Hmmbob]

Turk schreef op dinsdag 27 augustus 2019 @ 22:48:
Ik moet nogsteeds mijn Python versie upgraden voordat ik Home Assistant weer kan updaten.

Alleen zit ik in een virtual enviroment, dus zal even kijken wat nou eigenlijk de beste manier is voor op een RPi3b+.

Moet er binnenkort toch maar echt aan geloven. Overdag maar doen, anders daalt de WAF factor naar een kritieke grens ben ik bang

Ik zou eerlijk gezegd je home assistant config backuppen en je Pi geheel opnieuw inrichten (dus opnieuw image downloaden en op je SD zetten), zodat je een verse start hebt.

En zoals eerder aangegeven, meteen overstappen naar een Docker omgeving

martinvdm schreef op dinsdag 27 augustus 2019 @ 22:54:
Maar ik zou zeker kijken om gelijk naar docker over te stappen, alhoewel en pi3 wellicht wat aan de lichte kant is.

Nee hoor, geen enkel probleem. Draait als een zonnetje.

[Verwijderd]

@barrymossel graag gedaan. En (t)ja, vanaf m'n 12e achter een computer (35 jaar lang nu) dus alle spannende dingen (oa introductie Linux en Internet) meegemaakt

@GekkePrutser dank voor de aanvulling! De pi 2b is quad core. Het wonderlijke is dat bij een load van rond de 3-4 het systeem dus al redelijk plat gaat. Misschien veel io wat m'n sd-kaart niet trekt?!

Ik heb de load overigens in HASS gezet. Krijg ik ook mooie grafiekjes. En als de load 15m boven de 3 komt een push notificaties op m'n iPhone dat ik een pi 4 moet bestellen

[ Voor 19% gewijzigd door Verwijderd op 28-08-2019 09:14 ]

[ANdrode]

Mars Warrior schreef op dinsdag 27 augustus 2019 @ 17:04:
[...]
Ik heb al vaker wat commentaar geleverd - ook hier in dit topic - over de breaking changes die ontwikkelaars blijkbaar heel normaal vinden en te pas en te onpas gebruiken, zonder - zo lijkt het - ook maar 1 seconde zich druk te maken over de gevolgen voor de gebruikers.

Hier zit een verstopte variabele in. Core ontwikkelaars doen de reviews en niemand houdt in de gaten wat de user impact is voor wijzigingen die advanced users raken.

Ik heb dat ook een keer - onder een ander Github pseudoniem - in een architectuur discussie gemeld, maar de reacties zijn in beide gevallen niet echt positief: het is nodig, ik weet niet waar ik het over heb en we werken hard, etc...

Er zitten flink wat onderkoningen in het project… Dat is bij zo'n project ook essentieel – je hebt de mankracht niet om alles zelf in de gaten te houden en veel mensen hebben hier geen zin in.

De administrator van het project is pragmatisch. Van de andere hass.io dev en een aantal van de mensen die prominent aanwezig zijn in de issue tracker zie ik deze kwaliteit minder.

Saturnus schreef op dinsdag 27 augustus 2019 @ 21:43:
[...]
Inderdaad.
https://github.com/home-assistant/architecture/issues/230 als voorbeeld. Hoe gewild het nou is of niet, het is een belachelijk ontwerp. En zo zijn er vele dingen. Zeer vaak moet je een 'hulp' sensor aanmaken om data te kunnen gebruiken of manipuleren. In lovelace bijv. kan je niet

Sub-attributes met een hulpsensor is voor mij echt een anti-patroon. De inherente ontwerpfout is dat er geen relatie (lijkt?) te zijn tussen instanties van componenten en de gemeten waarden die in de state machine zitten.

Wat nog wel eens werk in de discussies daar is óf refereren naar toegankelijke computer science theorie (het is niet genormaliseerd datamodel, dat is redundantie).

Of dat het een ontwerpfout is: RestoreEntity is misschien voor bepaalde entities die afwijken nodig, maar states restoren is een zinvolle default/shared concern.

Soms werkt dat ook tegen discussies: met last_changed zou je ook updates die later binnen komen alsnog kunnen observeren, maar men lijkt zowel een last_changed als een last_updated te willen hebben die monotoon oplopen (over alle componenten heen).
Wederom, redundantie in datamodel

Voordat we versie 1 zien die de versie 1 tag verdient zullen we eerst 0.99.137 gehad moeten hebben. Ga maar na, wat zijn sinds ~0.88/0.91 nou echt updates geweest waarvan je denkt "wow!" Het is vreemd want aan de ene kant hebben ze die robuuste visie, maar aan de andere kant zitten er fundamentele wanontwerpen in die niet aangepakt worden. Maar van problemen ga je dus weinig last hebben als je aan de GUI-kant blijft zitten en/of het niet te complex maakt, óf zelf met Python aan de gang gaat.

Prioriteiten. Stabiel krijgen en wegnemen van issues met user impact lijkt de prioriteit over features op het moment. Als dit er voor zorgt dat er binnenkort minder componenten breken is dat ontzettend goed.

offtopic:
Overigens zie ik het groeiende gebruik van HACS, wat niet door het project zelf aangeraden wordt, terwijl men wel focust op 'gebruik maar custom components' als een soort van fork.

En over die 'gebruik maar custom components' houding: Dat is een non sequitur/maakt de gevallen waar in je het wel accepteert dat iets in een core component zit special pleading, maar dat ziet men niet.

Daarnaast wordt er veel development tijd in een bizar deployment mechanisme gestoken. Hass.io met binary wheels geeft mij nul waarde als docker gebruiker terwijl er ontzettend veel tijd in gaat.

[daxy]

Hmmbob schreef op woensdag 28 augustus 2019 @ 08:11:
[...]

Ik zou eerlijk gezegd je home assistant config backuppen en je Pi geheel opnieuw inrichten (dus opnieuw image downloaden en op je SD zetten), zodat je een verse start hebt.

En zoals eerder aangegeven, meteen overstappen naar een Docker omgeving

[...]
Nee hoor, geen enkel probleem. Draait als een zonnetje.

Hier ook een Pi3 met docker waarmee ik Home-assistant, mosquitto, zigbee2mqtt, smokeping en portainer draai. Daarnaast nog DSMR-reader (en dus PostgreSQL) niet via docker (beetje getuned zodat hij niet elke seconde maar elke 30sec een update doet). Gemiddelde load is nog steeds rond de 0.20
Ik zit nog te bedenken wat ik er nog meer bij kan doen

[GENETX]

Zijn er overigens ook mensen die de TwenteMilieu integratie gebruiken en last hebben dat er een afvalbak op Unknown blijft staan? Bij mij werkt de papierbak niet (de overige 3 wel). Het lijkt dieper te zitten, want "rauw" in python3 krijg ik ook None terug met https://pypi.org/project/twentemilieu/

De integratie bij met een melding 's ochtends werkt ook bijna, ware het neit dat ik de oude datum ergens moet opslaan helaas... Op de ophaal dag zelf is de datum namelijk alweer geupdate naar het volgende ophaalmoment. Mogelijk dat dat wel te fixen is in het component zelf, maar daar heb ik nog niet naar gekeken.

[sterremos]

Daar mijn Hassio niet meer opstart een nieuwe installatie gemaakt, en ik kom er niet meer uit in het volgende.
heb een mqtt broker geinstalleerd en zie dat de sonoffs gekoppeld zijn.

1566981319: New connection from 192.168.1.25 on port 1883.
1566981319: New client connected from 192.168.1.25 as DVES_67D6CA (p2, c1, k10, u'Ron').
1566981319: New connection from 192.168.1.24 on port 1883.
1566981319: New client connected from 192.168.1.24 as DVES_24B875 (p2, c1, k10, u'Ron').
1566981319: New connection from 192.168.1.47 on port 1883.
1566981319: New client connected from 192.168.1.47 as DVES_25093C (p2, c1, k10, u'Ron'

heb het config.yaml aangevuld met
mqtt:
broker: 192.168.1.12
port: 1883
username: Ron
password:
discovery: true

volgens mij zou dit moeten werken om de sonoff in het overzicht te krijgen? maar helaas komen ze niet naar boven. kan iemand aangeven waar de fout zit?

ron

[The_Admin]

daxy schreef op woensdag 28 augustus 2019 @ 10:04:
[...]


Hier ook een Pi3 met docker waarmee ik Home-assistant, mosquitto, zigbee2mqtt, smokeping en portainer draai. Daarnaast nog DSMR-reader (en dus PostgreSQL) niet via docker (beetje getuned zodat hij niet elke seconde maar elke 30sec een update doet). Gemiddelde load is nog steeds rond de 0.20
Ik zit nog te bedenken wat ik er nog meer bij kan doen

...en toen ging je SD-kaartje kapot.

[daxy]

The_Admin schreef op woensdag 28 augustus 2019 @ 10:56:
[...]


...en toen ging je SD-kaartje kapot.

Oh ja, hij draait op een SSD

[Hmmbob]

The_Admin schreef op woensdag 28 augustus 2019 @ 10:56:
[...]


...en toen ging je SD-kaartje kapot.

Dagelijkse duplicati naar de cloud

[Hmmbob]

sterremos schreef op woensdag 28 augustus 2019 @ 10:46:
Daar mijn Hassio niet meer opstart een nieuwe installatie gemaakt, en ik kom er niet meer uit in het volgende.
heb een mqtt broker geinstalleerd en zie dat de sonoffs gekoppeld zijn.

1566981319: New connection from 192.168.1.25 on port 1883.
1566981319: New client connected from 192.168.1.25 as DVES_67D6CA (p2, c1, k10, u'Ron').
1566981319: New connection from 192.168.1.24 on port 1883.
1566981319: New client connected from 192.168.1.24 as DVES_24B875 (p2, c1, k10, u'Ron').
1566981319: New connection from 192.168.1.47 on port 1883.
1566981319: New client connected from 192.168.1.47 as DVES_25093C (p2, c1, k10, u'Ron'

heb het config.yaml aangevuld met
mqtt:
broker: 192.168.1.12
port: 1883
username: Ron
password: --knip--
discovery: true

volgens mij zou dit moeten werken om de sonoff in het overzicht te krijgen? maar helaas komen ze niet naar boven. kan iemand aangeven waar de fout zit?

ron

Ik hoop dat je dit wachtwoord niet op meer plekken gebruikt? Pas je post ook even aan anders....

Dan de mogelijke oplossing: heb je Discovery ook aangezet in Tasmota?

https://community.home-as...ery-tasmota-sonoff/105949

[ Voor 6% gewijzigd door Hmmbob op 28-08-2019 11:02 ]

[sterremos]

Hmmbob schreef op woensdag 28 augustus 2019 @ 11:01:
[...]

Ik hoop dat je dit wachtwoord niet op meer plekken gebruikt? Pas je post ook even aan anders....

Dan de mogelijke oplossing: heb je Discovery ook aangezet in Tasmota?

https://community.home-as...ery-tasmota-sonoff/105949

Nee is gewoon maar een bedenksel, maar wel verwijderd, ook de optie 19 is ingesteld.
de sonofs maken wel contact in mqtt maar niet in HA

[Thoit]

daxy schreef op woensdag 28 augustus 2019 @ 10:04:
[...]


Hier ook een Pi3 met docker waarmee ik Home-assistant, mosquitto, zigbee2mqtt, smokeping en portainer draai. Daarnaast nog DSMR-reader (en dus PostgreSQL) niet via docker (beetje getuned zodat hij niet elke seconde maar elke 30sec een update doet). Gemiddelde load is nog steeds rond de 0.20
Ik zit nog te bedenken wat ik er nog meer bij kan doen

En met welk OS draai je dat nu? Met Raspbian? Ik heb momenteel een Pi2 draaien met Hassio en dat draait opzicht goed.

Wil echter afstappen van de SD kaart omdat die een keer kapot zal gaan

Liefste draai ik het in Docker, met ben er nog niet uit of ik Hassio in Docker wil draaien of Home Assistant. Vervolgens ben ik er niet uit of ik het Docker commando ga gebruiken of Docker compose. Keuzes, keuzes

[daxy]

Thoit schreef op woensdag 28 augustus 2019 @ 11:41:
[...]


En met welk OS draai je dat nu? Met Raspbian? Ik heb momenteel een Pi2 draaien met Hassio en dat draait opzicht goed.

Wil echter afstappen van de SD kaart omdat die een keer kapot zal gaan

Liefste draai ik het in Docker, met ben er nog niet uit of ik Hassio in Docker wil draaien of Home Assistant. Vervolgens ben ik er niet uit of ik het Docker commando ga gebruiken of Docker compose. Keuzes, keuzes

Ik draai Raspbian en heb hem dus op een 250GB SSD disk geïnstalleerd. De SD wordt dus niet gebruikt.
Ik draai gewoon Home-Assistant vanuit docker en gebruik docker commands. Ik houd een txt file bij met het gebruikte commando en gebruik dit continue. Upgraden/downgraden is nu super simpel en super snel.

Voorbeeld: Upgraden naar nieuwe versie gaat als volgt:

$ docker stop ha-prod
$ docker update --restart no ha-prod
$ docker run -d --restart always --name="ha-dev" -v /root/docker-data/homeassistant:/config -v /etc/letsencrypt:/config/letsencrypt:ro -v /etc/localtime:/etc/localtime:ro --net=host homeassistant/raspberrypi3-homeassistant:0.97.2

Als er vervolgens iets niet werkt, dan kan ik gewoon ha-dev stoppen en ha-prod starten.. klaar.

Als het goed werkt, dan "upgrade" ik ha-dev naar ha-prod: docker rename ha-dev ha-prod
Dit doe ik eigenlijk voor alle docker containers die ik heb.

[Mars Warrior]

ANdrode schreef op woensdag 28 augustus 2019 @ 10:04:
[...]
Hier zit een verstopte variabele in. Core ontwikkelaars doen de reviews en niemand houdt in de gaten wat de user impact is voor wijzigingen die advanced users raken.

Daarvoor hoef je geen advanced user te zijn: als een integratie plotseling andere entities levert, dan gaat je hele MMI, automations en andere dingen zoals historie in Grafana kapot. En dat is gewoon kut.

Er zitten flink wat onderkoningen in het project… Dat is bij zo'n project ook essentieel – je hebt de mankracht niet om alles zelf in de gaten te houden en veel mensen hebben hier geen zin in.

De administrator van het project is pragmatisch. Van de andere hass.io dev en een aantal van de mensen die prominent aanwezig zijn in de issue tracker zie ik deze kwaliteit minder.

Je kunt best als eis stellen dat entitty namen niet gewijzigd mogen worden door verbeteringen in de software. Zo moeilijk is dat niet om te laten afvinken en evt. dus terug te kunnen rollen.

[ot]Overigens zie ik het groeiende gebruik van HACS, wat niet door het project zelf aangeraden wordt, terwijl men wel focust op 'gebruik maar custom components' als een soort van fork.

Ja leuk hè. HACS biedt zoveel doordat je je versie van een component kunt kiezen tov het door de strot duwen van versies bij een hass release waar je niet op zit te wachten.
Nog ff en HACS moet worden uitgebreid met filters en categorieen omdat je anders door de bomen het bos niet meer ziet.

En over die 'gebruik maar custom components' houding: Dat is een non sequitur/maakt de gevallen waar in je het wel accepteert dat iets in een core component zit special pleading, maar dat ziet men niet.[/ot]

Ik had even een teveel moeilijke woorden wegtrekkertje, maar dit plaatje maakte weer veel goed:

Daarnaast wordt er veel development tijd in een bizar deployment mechanisme gestoken. Hass.io met binary wheels geeft mij nul waarde als docker gebruiker terwijl er ontzettend veel tijd in gaat.

De stap naar Azure DevOps en één enkel docker image voor zowel hass als hass.io is dan weer goed en gaat de devs tijd opleveren.

Het nut van python wheels, zoals hier is gemeld icm Docker ontgaat me ook volledig.
Neem dan een base image inclusief Python zoals deze. Ben je ook klaar...

Normaal zou ik al snel denken: de beste stuurlui staan aan wal, maar er zijn voor hass iets te veel voorbeelden die je ook met een paar ritjes in een roeiboot kunt duiden.

---

Ik ben benieuwd wat men op de verjaardag van hass in september gaat doen. Groots uitpakken? v1.0 uitbrengen? Andere leuke verassingen zoals geen breaking changes meer? We gaan het zien

[stefanroelofs]

Toen ik voor de 3e keer vandaag checkte of de nieuwe versie al online stond was ik het zat

Hier een automation die je een notificatie stuurt wanneer er een nieuwe versie (hass.io) klaarstaat.

YAML:

sensor:
  - platform       : rest
    resource       : https://s3.amazonaws.com/hassio-version/stable.json
    name           : "Latest Version"
    value_template : "{{ value_json.homeassistant.raspberrypi3 }}"
    scan_interval  : 1800

automation:
  - alias          : 'New version notification'
    initial_state  : true
    trigger:
      platform     : state
      entity_id    : sensor.latest_version
    action:
      - service    : notify.chrome_notifier
        data_template:
          title    : "New Home Assistant Version"
          message  : "Version {{ trigger.to_state.state }} is available!"
          data:
            tag    : newversion_alert
            icon   : "https://xxxxxxxx.duckdns.org/local/icons/homeassistant.png"
  

Gekopieerd van hier.

[Verwijderd]

GENETX schreef op maandag 26 augustus 2019 @ 21:26:
@DeadMetal
Ja, of je gaat lekker aan de slag met AppDaemon.

Leuk! Die optie had ik nog niet ontdekt in HASS.Dank.

@stefanroelofs verveel je je Zou aardig zijn als zoiets generiek voor git-repos beschikbaar was.

-- is er op gathering trouwens een optie om individuele posts te taggen / bookmarken? Zie vaker posts voorbij komen waarvan ik denk 'daar ga ik later eens induiken' en zoek me vervolgens het laplazerus om ze terug te vinden.

[ Voor 10% gewijzigd door Verwijderd op 28-08-2019 18:19 ]

[GENETX]

Ja, er is gewoon een bookmark functie voor posts. Op de mobiele pagina is het een dropdown, op de desktop weet ik t zo niet eens

[Lifelogger]

Fraggar schreef op dinsdag 20 augustus 2019 @ 10:40:
[...]
Ik heb mijn hele huis voorzien van de Fibaro dimmer 2 modules. Dit werkt uitstekend zolang je de juiste led-lampen kiest. Het ene merk werkt goed waar het andere merk problemen heeft als je gaat dimmen. Ik gebruik geen bypass modules.

Mag ik vragen welke lampen je gebruikt? Ik ben toevallig vandaag bezig geweest met de dimmers. Heb er al 1 in huis en wilde de boven verdieping ook voorzien van dimmers. Echter, in geen van de kamers werken ze. Heb (nog) geen bypass. In heb Philips led lampen die dimbaar moeten zijn, maar krijg ze niet aan de praat. De lampen geven 1 flits en gaan weer uit. Niet te dimmen. Als ik 1 lamp er uit draai, flikkert de tweede iets. Meer niet.

Kortom, zoek dus een goed merk lampen. :-) Mocht je tips hebben, hoor ik het graag!

[PTish]

stefanroelofs schreef op woensdag 28 augustus 2019 @ 17:08:
Toen ik voor de 3e keer vandaag checkte of de nieuwe versie al online stond was ik het zat

Hier een automation die je een notificatie stuurt wanneer er een nieuwe versie (hass.io) klaarstaat.

YAML:

sensor:
  - platform       : rest
    resource       : https://s3.amazonaws.com/hassio-version/stable.json
    name           : "Latest Version"
    value_template : "{{ value_json.homeassistant.raspberrypi3 }}"
    scan_interval  : 1800

automation:
  - alias          : 'New version notification'
    initial_state  : true
    trigger:
      platform     : state
      entity_id    : sensor.latest_version
    action:
      - service    : notify.chrome_notifier
        data_template:
          title    : "New Home Assistant Version"
          message  : "Version {{ trigger.to_state.state }} is available!"
          data:
            tag    : newversion_alert
            icon   : "https://xxxxxxxx.duckdns.org/local/icons/homeassistant.png"
  

Gekopieerd van hier.

Op de officiele home assistant website staat nog een andere methode;
https://www.home-assistan...otify_if__new_ha_release/

Of is deze niet Hass.io compatible?

[stefanroelofs]

PTish schreef op woensdag 28 augustus 2019 @ 21:12:
[...]
Of is deze niet Hass.io compatible?

Die zag ik ook idd. Die automation gebruikt het updater component. Op die pagina staat: "As Hass.io has its own schedule for release it doesn’t make sense to use this integration on Hass.io."
Daarom had ik wat anders opgezocht.

Maar nou ik er wat langer over nadenk, misschien is die documentatie niet up-to-date meer. Hadden ze een maand ofzo geleden niet iets doorgevoerd waardoor de Hass.io builds bijna tegelijk klaar waren met de homeassistant build?

[martinvdm]

stefanroelofs schreef op woensdag 28 augustus 2019 @ 17:08:
Toen ik voor de 3e keer vandaag checkte of de nieuwe versie al online stond was ik het zat

Hier een automation die je een notificatie stuurt wanneer er een nieuwe versie (hass.io) klaarstaat.

YAML:

sensor:
  - platform       : rest
    resource       : https://s3.amazonaws.com/hassio-version/stable.json
    name           : "Latest Version"
    value_template : "{{ value_json.homeassistant.raspberrypi3 }}"
    scan_interval  : 1800

automation:
  - alias          : 'New version notification'
    initial_state  : true
    trigger:
      platform     : state
      entity_id    : sensor.latest_version
    action:
      - service    : notify.chrome_notifier
        data_template:
          title    : "New Home Assistant Version"
          message  : "Version {{ trigger.to_state.state }} is available!"
          data:
            tag    : newversion_alert
            icon   : "https://xxxxxxxx.duckdns.org/local/icons/homeassistant.png"
  

Gekopieerd van hier.

Ik gebruik hem zo incl custom breaking changes component.

YAML:

- alias: 'Notify HA Update Available'
    initial_: on
    trigger:
      platform: state
      entity_id: updater.updater
    action:
      service: notify.ios_iphone
      data:
        message: "Home Assistant {{ states('updater.updater') }} is beschikbaar. Er zijn {{ states('sensor.potential_breaking_changes') }} potentiele breaking changes."

[Fraggar]

Lifelogger schreef op woensdag 28 augustus 2019 @ 20:15:
Kortom, zoek dus een goed merk lampen. :-) Mocht je tips hebben, hoor ik het graag!

Het is inderdaad moeilijk om de juiste lampen te vinden die goed samenwerken met de Fibaro dimmer. Maar dit geldt volgensmij alleen wanneer je lampen zoekt met een laag wattage.

Zelf heb ik vooral GU10-spotjes van Philips warmglow, E14-lampen van Philips warmglow en nog een enkele E27.

Omdat de E14-lampen niet lekker gedimd werden heb ik Qubino-dimmers geprobeerd, daarmee werkte het prima. Toen heb ik de fout gemaakt om overal Qubino-dimmers te kiezen. Na 6 maanden gebruik begonnen deze dimmers te sneuvelen bij alle GU10-spots. Ik ben daarom weer teruggegaan naar Fibaro.

Mijn ervaring is dat je beter kan zoeken naar een werkende lamp dan te kiezen voor Qubino of Aeotec. De firmware van de Fibaro modules is volwassener en kent meer functionaliteit. Ook zijn de Fibaro-modules sneller.

Ik moet eerlijk toegeven dat ik nog een paar Qubino-dimmers in gebruik heb bij de E14-lampen. Een overzicht van welke lamp goed werkt met welke dimmer is voor mij ook welkom. Wanneer je eenmaal een goede match gevonden hebt is het een mooie oplossing om je lichten te dimmen.

[Schonhose]

Gisteren de overstap van domoticz naar Home Assistant gemaakt via de Hass.io route. Viel me allemaal niet tegen, een groot gedeelte kreeg ik zo aan de praat.

Het enige wat niet werkt is de RF Link. In de log-file krijg ik de volgende meldingen:

code:

2019-08-28 23:14:07 INFO (MainThread) [homeassistant.components.rflink] Initiating Rflink connection 2019-08-28 23:14:07 INFO (MainThread) [homeassistant.components.rflink] Connected to Rflink 
2019-08-28 23:14:07 DEBUG (MainThread) [rflink.protocol] connected 
2019-08-28 23:15:21 DEBUG (MainThread) [rflink.protocol] received data: nH 
2019-08-28 23:15:21 WARNING (MainThread) [rflink.protocol] Error during decode of data, invalid data: �

Er is een connectie, maar de data geeft een error bij het decoden. Ik heb gisteren lang gezocht, wel deze github issue gevonden (waar ik ook op gereageerd heb). Zijn er meer mensen die hier last van hebben?

[Lifelogger]

Fraggar schreef op donderdag 29 augustus 2019 @ 00:50:
[...]


Het is inderdaad moeilijk om de juiste lampen te vinden die goed samenwerken met de Fibaro dimmer. Maar dit geldt volgensmij alleen wanneer je lampen zoekt met een laag wattage.

Zelf heb ik vooral GU10-spotjes van Philips warmglow, E14-lampen van Philips warmglow en nog een enkele E27.

Omdat de E14-lampen niet lekker gedimd werden heb ik Qubino-dimmers geprobeerd, daarmee werkte het prima. Toen heb ik de fout gemaakt om overal Qubino-dimmers te kiezen. Na 6 maanden gebruik begonnen deze dimmers te sneuvelen bij alle GU10-spots. Ik ben daarom weer teruggegaan naar Fibaro.

Mijn ervaring is dat je beter kan zoeken naar een werkende lamp dan te kiezen voor Qubino of Aeotec. De firmware van de Fibaro modules is volwassener en kent meer functionaliteit. Ook zijn de Fibaro-modules sneller.

Ik moet eerlijk toegeven dat ik nog een paar Qubino-dimmers in gebruik heb bij de E14-lampen. Een overzicht van welke lamp goed werkt met welke dimmer is voor mij ook welkom. Wanneer je eenmaal een goede match gevonden hebt is het een mooie oplossing om je lichten te dimmen.

Heb hier alleen Fibaro dimmers. Heb wel gekeken naar de Qubino dimmers, maar de gok toch maar niet genomen. :-)

Heb nu een bypass besteld om te kijken of dat het probleem met het flikkeren van de kampen tegen gaat. Heb Philips lampen die gedimd zouden moeten kunnen worden, maar helaas niet werkt. We testen nog even door. :-)

[robbinonline]

Pimmetje651 schreef op zaterdag 24 augustus 2019 @ 14:39:
[...]


Thnx ,dit kan ik idd eens proberen .
Ben eigenlijk iemand die er niet tegen kan als er iets is en het werkt niet ....grrr
Wil het dan zo graag gewoon werkende hebben

Weet niet of je het al opgelost hebt, maar bij mij werkt het op deze manier:

- platform: uvc
nvr: 10.*.*.*
key: *
password: *

[ANdrode]

Mars Warrior schreef op woensdag 28 augustus 2019 @ 14:25:
[...]
Daarvoor hoef je geen advanced user te zijn: als een integratie plotseling andere entities levert, dan gaat je hele MMI, automations en andere dingen zoals historie in Grafana kapot. En dat is gewoon kut.
[...]
Je kunt best als eis stellen dat entitty namen niet gewijzigd mogen worden door verbeteringen in de software. Zo moeilijk is dat niet om te laten afvinken en evt. dus terug te kunnen rollen.

Ik weet niet of ze dat al advanced users vinden. Maar dat het de user interface breekt is inderdaad al not done.

Heel misschien gaat entity registry hierin helpen? Vind het wel een fair punt voor een architecture issue.

Ja leuk hè. HACS biedt zoveel doordat je je versie van een component kunt kiezen tov het door de strot duwen van versies bij een hass release waar je niet op zit te wachten.
Nog ff en HACS moet worden uitgebreid met filters en categorieen omdat je anders door de bomen het bos niet meer ziet.

HACS heeft een heel dependency management systeem nodig (wat het niet helemaal heeft) en inderdaad een betere UX. Als ze HACS bewust gebruiken om het wiel niet zelf uit te vinden vind ik het een goede keuze.
Zie ik Paulus wel doen

De aanpak van HACS (met github repo's clonen voor metadata) schaalt in ieder geval niet. Met DNF kan je iets beters bouwen.

De stap naar Azure DevOps en één enkel docker image voor zowel hass als hass.io is dan weer goed en gaat de devs tijd opleveren.

Het nut van python wheels, zoals hier is gemeld icm Docker ontgaat me ook volledig.
Neem dan een base image inclusief Python zoals deze. Ben je ook klaar...

Men is juist gemigreerd van de debian buster python image [zoals daar gesuggereerd] naar de alpine image omdat deze kleiner is. Terwijl men niet de docker/python image geoptimaliseerd heeft.

Maar dat hass.io de alpine image gebruikte was eigenlijk de basis van de keuze om voor de reguliere image ook naar alpine te gaan. Dat argument vind ik wel prima. Pascal schrijft dat alleen niet expliciet op en probeert de keuze te onderbouwen met de voordelen die hij heeft…

En wheels schelen bouwtijd… De implementatie van wheels kost echter development tijd. In mijn ogen een verkeerde trade-off.

offtopic:
Ik kon op mijn desktop overigens in een paar minuten een image bouwen toen ik een PyPy mirror had, maar dat is geen gekke cross-compile naar ARM.

[MrBarBarian]

Hebben er meer last van DNS-issues met hass.io sinds de update van 12 dagen geleden?

Hier wordt e.a. besproken, maar voor mij nog geen oplossing.

Veel DNS worden niet, of niet consistent geresolved. Beetje vreemd dat er zo makkelijk zo'n grote wijziging doorheen gezet wordt die gewoon slecht blijkt te werken

(nog los van dat de supervisor van hassio automatisch update en je daar geen controle over hebt)

^{@JBS sorry, iets scherper verwoord}

[ Voor 6% gewijzigd door MrBarBarian op 29-08-2019 09:58 ]

[JBS]

MrBarBarian schreef op donderdag 29 augustus 2019 @ 09:48:
Beetje vreemd dat er zo makkelijk zo'n grote wijziging doorheen gezet wordt die gewoon slecht blijkt te werken

(nog los van dat hassio automatisch update en je daar geen controle over hebt)

Hoe bedoel je dat? Hass.io update niet automatisch, het updaten moet je zelf starten. Je kunt echter niet via de GUI kiezen naar welke versie, dat gebeurt altijd naar de laatst beschikbare.

Buiten de GUI om kun je wel kiezen welke versie je wilt draaien, zie JBS in "Home Assistant - Open source Python3 home automation"

[ Voor 13% gewijzigd door JBS op 29-08-2019 09:56 ]

[redah]

OK, ook mijn HA configuratie loopt uit de klauwen Ik weet dat je verschillende bestanden kunt includen in de configuration.yaml zodat je niet 1 groot bestand hebt, maar is het mogelijk om bepaalde onderdelen in die bestanden te combineren?

Zo lees ik mijn P1 meter uit, heb ik daar templates en filters op, en exclude ik e.e.a uit de recorder. Maar dat betekent dat ik zowel vermeldingen van de P1 in de configuration.yaml heb staan (n sensor), in mijn eigen slimmemeter.yaml, en in recorder.yaml

Het liefst zou ik alles, zoals ook de recorder exclusions in 1 bestand hebben.

Maar dat gaat niet... Toch?

[stefanroelofs]

redah schreef op donderdag 29 augustus 2019 @ 10:41:
OK, ook mijn HA configuratie loopt uit de klauwen Ik weet dat je verschillende bestanden kunt includen in de configuration.yaml zodat je niet 1 groot bestand hebt, maar is het mogelijk om bepaalde onderdelen in die bestanden te combineren?

Zo lees ik mijn P1 meter uit, heb ik daar templates en filters op, en exclude ik e.e.a uit de recorder. Maar dat betekent dat ik zowel vermeldingen van de P1 in de configuration.yaml heb staan (n sensor), in mijn eigen slimmemeter.yaml, en in recorder.yaml

Het liefst zou ik alles, zoals ook de recorder exclusions in 1 bestand hebben.

Maar dat gaat niet... Toch?

Packages are your friend!
https://www.home-assistant.io/docs/configuration/packages/

Veel mensen hebben hun config op github staan. Kijk daar voor ideeën hoe het te gebruiken (bijvoorbeeld hier)

[barrymossel]

Krijg net een melding:

Home Assistant 0.98.0 is beschikbaar. Er zijn 4 potentiële breaking changes. Wil je updaten?

Kan ik vanavond dus weer aan de slag...

[PTish]

barrymossel schreef op donderdag 29 augustus 2019 @ 11:14:
Krijg net een melding:


[...]


Kan ik vanavond dus weer aan de slag...

Same. Al meld hij bij mij ook breaking changes op het `ruter` component en `edr_redy` component. Beide niet in gebruik.

[Mars Warrior]

barrymossel schreef op donderdag 29 augustus 2019 @ 11:14:
Krijg net een melding:
[...]
Kan ik vanavond dus weer aan de slag...

Hier nog geen problemen gezien. Alles lijkt het te doen. Geen last van de breaking changes dit keer omdat ik die componenten niet in mijn setup gebruik.

[GENETX]

barrymossel schreef op donderdag 29 augustus 2019 @ 11:14:
Krijg net een melding:


[...]


Kan ik vanavond dus weer aan de slag...

Omg, ik ook weer...

Kodi - Kodi services are now their own domain and the media_player.kodi_* services are now kodi.* - (@JeffLIrion - #25753) (kodi docs)

media_player.kodi_add_to_playlist is now kodi.add_to_playlist
media_player.kodi_call_method is now kodi.call_method

OMGWTFBBQ WHY!!!

Dit is dus exact waar ik het een paar posts hierboven al over had. Mij ontgaat het hele nut om dit te veranderen. Magik weer in al mijn rules een search en replace gaan uitvoeren

HASS zou er goed aan doen om een guideline voor entity names op te stellen en deze consistent toe passen...

We hebben nu dus:
dienst.random_naam
type.random_naam
type.dienst_random_naam_var
en nog meer...

Concrete voorbeelden die ik nu ga hebben
kodi.huiskamer -> een kodi (dienst) media_player met de naam huiskamer
media_player.huiskamer -> een media_player type met de naam huiskamer, wat een Google Home Mini is.
sensor.darksky_temperature -> een sensor type met de naam darksky en dan verder gespecificeerd de temperatuur

Hoe moeilijk is het om hier een fatsoenlijke structuur in aan te brengen:
type.naam, type.naam.variabele/atribuut welke eventueel een symlink zijn van type.dienst.naam(.x)

En dan vooral zonder de naam van de dienst (naam is een variabele die je zelf zou moeten kunnen instellen, of anders een soort symlink) zodat je metingen en automations ook blijven werken als je bv een Kodi vervangt voor AndroidTV of Philips Hue voor een Ikea Tradfri.

Het hele voordeel van klassen zoals een media_player of light is dat je juist onafhankelijk van het daadwerkelijke product min of meer dezelfde functionaliteit (en dus aan te roepen functies) mag verwachten. Zoals je met Object oriented programming verwacht: een mooie abstracte klasse die je vervolgens kan implementeren.

Zonder dit eerst eens goed in de basis op te lossen, eventueel met mooie migratiescripts, blijft dit probleem zicht gewoon herhalen. Vorige keer had ik dit dus al met mijn climate component.

/rant

[ Voor 15% gewijzigd door GENETX op 29-08-2019 12:06 ]

[JayOne]

GENETX schreef op donderdag 29 augustus 2019 @ 11:59:
[...]

Omg, ik ook weer...


[...]

OMGWTFBBQ WHY!!!

Dit is dus exact waar ik het een paar posts hierboven al over had. Mij ontgaat het hele nut om dit te veranderen. Magik weer in al mijn rules een search en replace gaan uitvoeren

HASS zou er goed aan doen om een guideline voor entity names op te stellen en deze consistent toe passen...

We hebben nu dus:
dienst.random_naam
type.random_naam
type.dienst_random_naam_var
en nog meer...

Concrete voorbeelden die ik nu ga hebben
kodi.huiskamer -> een kodi (dienst) media_player met de naam huiskamer
media_player.huiskamer -> een media_player type met de naam huiskamer, wat een Google Home Mini is.
sensor.darksky_temperature -> een sensor type met de naam darksky en dan verder gespecificeerd de temperatuur

Hoe moeilijk is het om hier een fatsoenlijke structuur in aan te brengen:
type.naam, type.naam.variabele/atribuut welke eventueel een symlink zijn van type.dienst.naam(.x)

En dan vooral zonder de naam van de dienst (naam is een variabele die je zelf zou moeten kunnen instellen, of anders een soort symlink) zodat je metingen en automations ook blijven werken als je bv een Kodi vervangt voor AndroidTV of Philips Hue voor een Ikea Tradfri.

Het hele voordeel van klassen zoals een media_player of light is dat je juist onafhankelijk van het daadwerkelijke product min of meer dezelfde functionaliteit (en dus aan te roepen functies) mag verwachten. Zoals je met Object oriented programming verwacht: een mooie abstracte klasse die je vervolgens kan implementeren.

Zonder dit eerst eens goed in de basis op te lossen, eventueel met mooie migratiescripts, blijft dit probleem zicht gewoon herhalen. Vorige keer had ik dit dus al met mijn climate component.

/rant

Volgens mij gaat de breaking change wat betreft Kodi alleen om het aanroepen van services en niet de entities zelf.

[ANdrode]

JayOne schreef op donderdag 29 augustus 2019 @ 12:09:
[...]

Volgens mij gaat de breaking change wat betreft Kodi alleen om het aanroepen van services en niet de entities zelf.

Bij kodi specifieke calls vind ik het een logische keuze. Dan krijg je weer frictie als de call deel van media_player lijkt maar dat niet is.

[PTish]

GENETX schreef op donderdag 29 augustus 2019 @ 11:59:
[...]

Omg, ik ook weer...


[...]

OMGWTFBBQ WHY!!!

Dit is dus exact waar ik het een paar posts hierboven al over had. Mij ontgaat het hele nut om dit te veranderen. Magik weer in al mijn rules een search en replace gaan uitvoeren

HASS zou er goed aan doen om een guideline voor entity names op te stellen en deze consistent toe passen...

We hebben nu dus:
dienst.random_naam
type.random_naam
type.dienst_random_naam_var
en nog meer...

Concrete voorbeelden die ik nu ga hebben
kodi.huiskamer -> een kodi (dienst) media_player met de naam huiskamer
media_player.huiskamer -> een media_player type met de naam huiskamer, wat een Google Home Mini is.
sensor.darksky_temperature -> een sensor type met de naam darksky en dan verder gespecificeerd de temperatuur

Hoe moeilijk is het om hier een fatsoenlijke structuur in aan te brengen:
type.naam, type.naam.variabele/atribuut welke eventueel een symlink zijn van type.dienst.naam(.x)

En dan vooral zonder de naam van de dienst (naam is een variabele die je zelf zou moeten kunnen instellen, of anders een soort symlink) zodat je metingen en automations ook blijven werken als je bv een Kodi vervangt voor AndroidTV of Philips Hue voor een Ikea Tradfri.

Het hele voordeel van klassen zoals een media_player of light is dat je juist onafhankelijk van het daadwerkelijke product min of meer dezelfde functionaliteit (en dus aan te roepen functies) mag verwachten. Zoals je met Object oriented programming verwacht: een mooie abstracte klasse die je vervolgens kan implementeren.

Zonder dit eerst eens goed in de basis op te lossen, eventueel met mooie migratiescripts, blijft dit probleem zicht gewoon herhalen. Vorige keer had ik dit dus al met mijn climate component.

/rant

Ik kan me enigzins voorstellen waar deze wijziging vandaan komt. Ik vermoed dat ze heel graag willen dat het mediaplayer component gewoon heel erg generiek is. vorige/volgende, volumen harder/zachter en niet voor iedere device die unieke features heeft, weer aparte functies maken.

Kijk maar eens in alle functies die mediaplayer heeft:
https://github.com/home-a...edia_player/services.yaml

Ik zie dingen specifiek voor een epson projector, iets voor blackbird, yamaha, bluesound, soundtouch etc.

Waar het in mijn ogen al mis is gegaan, is dat ze unieke opties gewoon toe hebben gelaten in het generieke component. Over 3 jaar heeft deze mediaplayer component 100den functies specifiek op bepaalde apparaten. Dat is niet te onderhouden. Ik denk dus dat het goed is dat de kodi onderdelen gewoon onder een kodi object vallen.

Ik ben het wel met je eens, als dit effect heeft op de namen van entiteiten, dat ze dit gewoon netjes moeten migreren zonder dat we daar last van hebben. Maar volgens mij zijn het inderdaad service calls.

[JayOne]

ANdrode schreef op donderdag 29 augustus 2019 @ 12:13:
[...]


Bij kodi specifieke calls vind ik het een logische keuze. Dan krijg je weer frictie als de call deel van media_player lijkt maar dat niet is.

Het lijkt idd om kodi specifieke calls te gaan.

[GENETX]

@JayOne Ja, en waar denk je dat al die services gebruikt worden? Juist ja. Die worden gebruikt in al mijn automations. Verspreid door diverse bestanden. Daanaast wijzigt de naam, waardoor ook weer de data anders in de database zal komen te staan en ook op dat vlak breekt. Dat zal ik vast kunnen oplossen door hem maar kodi.kodi_kamer te noemen.
Edit: Aah, dus alleen voor specifieke Kodi services. Dan heb ik de docs deze keer verkeerd begrepen. Dit is in principe wel een erg logische keuze gezien het design. Al blijft het bos van naamgeving binnen HASS voor mij soms wat lastig te volgen... Vandaar de verwarring die helemaal van mijn kant komt.

Verder ben ik het eens. Anderzijds, een klasse kan ook gewoon een klasse extenden met eigen functies. Mij is eigenlijk altijd al ontgaan waarom ik een bepaalde service zoals media_player.iets moet aanroepen. Ook dat zou men gewoon op kunnen lossen en voorlopig iets vna backward comapbility inbouwen.

Ik zou het vele logischer vinden om gewoon entity_name.actie() aan te kunnen roepen ipv service.actie(entity_name). Dan kom je daar ook niet mee in de knoei.

Goed, ik zit niet in de HASS development en klink nu misschien wat negatief. Niets meer dan lof voor de developers en de werk die ze er in steken. Er is een reden waarom ik van OpenHAB naar HASS ben overgegaan.

Maargoed, de situatie nu lijkt een beetje aanmodderen. Een beetje "zachte heelmesters maken stinkende wonden". Ik heb liever dat ze de boel dan nu maar even goed breken zodat er een blijvende oplossing is waar een goed ontwerp achter zit.

Edit: de soep is dus blijkbaar toch niet zo heet als dat deze wordt opgediend

[ Voor 16% gewijzigd door GENETX op 29-08-2019 12:31 ]

[JayOne]

GENETX schreef op donderdag 29 augustus 2019 @ 12:22:
@JayOne Ja, en waar denk je dat al die services gebruikt worden? Juist ja. Die worden gebruikt in al mijn automations. Verspreid door diverse bestanden. Daanaast wijzigt de naam, waardoor ook weer de data anders in de database zal komen te staan en ook op dat vlak breekt. Dat zal ik vast kunnen oplossen door hem maar kodi.kodi_kamer te noemen.

Je entiteit blijft gewoon media_player.kodi_nogwat heten, alleen je service call wijzigt. Snap niet echt het drama wat je hierover maakt.

[redah]

stefanroelofs schreef op donderdag 29 augustus 2019 @ 11:08:

Packages are your friend!
https://www.home-assistant.io/docs/configuration/packages/

Veel mensen hebben hun config op github staan. Kijk daar voor ideeën hoe het te gebruiken (bijvoorbeeld hier)

Dat was eigenlijk best makkelijk

Volgende vraag: Is er iemand bekend met een 'stacked bar' grafiek? Zodat ik 3 waarden op elkaar kan stapelen in 1 balk die even hoog is als het totaal van die 3 waarden?

[JayOne]

GENETX schreef op donderdag 29 augustus 2019 @ 12:22:
Ik zou het vele logischer vinden om gewoon entity_name.actie() aan te kunnen roepen ipv service.actie(entity_name). Dan kom je daar ook niet mee in de knoei.

De inrichting van services los van de entiteiten maakt het mogelijk om met één service call meerdere entiteiten aan te sturen. Wanneer je dit binnen de entiteit wil aansturen maakt het op dat vlak weer complexer, bewerkelijker.

In het geval van media_player entiteiten zou je bijvoorbeeld, op basis van een bepaalde trigger, alle media_players in de woonkamer willen muten, zonder hierbij een check te willen doen welke daadwerkelijk aan het afspelen zijn.

[stefanroelofs]

redah schreef op donderdag 29 augustus 2019 @ 13:20:
[...]


Dat was eigenlijk best makkelijk

Volgende vraag: Is er iemand bekend met een 'stacked bar' grafiek? Zodat ik 3 waarden op elkaar kan stapelen in 1 balk die even hoog is als het totaal van die 3 waarden?

Mini graph card word veel gebruikt voor grafieken dingetjes, maar kan geen stacked bar..
Als je dit echt wilt zul je je moeten verdiepen in Grafana.

[UTMachine]

De upgrade naar 0.98.0 was redelijk pijnloos en alles lijkt nog te werken

Alleen DeCONZ geeft nu 2 foutmeldingen, maar de functionaliteit lijkt te werken:

code:

2019-08-29 13:57:43 ERROR (MainThread) [pydeconz.websocket] Unexpected error 'NoneType' object is not subscriptable
2019-08-29 13:57:43 ERROR (MainThread) [pydeconz.websocket] Unexpected error 'NoneType' object is not subscriptable