Home Assistant: Open source Python3 home automation - deel 3

[water_escape]

Ik heb in mijn overkapping Hue gu10 lampen gedaan.

Als ik nu via ZHA scan voor nieuw devices komen de lampen niet naar voren toe, er wordt niks gevonden.
Wanneer ik in de HUE app zoek naar lampen komen ze wel naar voren.

Hoe zorg ik dat deze door ZHA gevonden kunnen worden? Sensoren en switches is wel gelukt daarmee. Mis ik iets mbt lampen?

[JBS]

Onderstaande template geeft in developer tools netjes 'false' terug.

YAML:

{{ states('input_number.solaredge_pv_dagrecord_waarde') > 
states('input_number.solaredge_pv_dagrecord_allertijden') }}

Maar wanneer ik deze template als een conditie gebruik voor een automation, wordt deze automation toch afgetrapt.

YAML:

  condition:
  - condition: template
    value_template: '{{ states(''input_number.solaredge_pv_dagrecord_waarde'') > states(''input_number.solaredge_pv_dagrecord_allertijden'') }}'

Zie ik hierbij iets over het hoofd waarom deze conditie genegeerd wordt?

\\Edit: Stom, denk ik. Bij het handmatig uitvoeren van een automation wordt de conditie genegeerd....

[ Voor 7% gewijzigd door JBS op 24-02-2021 14:23 ]

[feenstn]

Ik heb een sensor gemaakt om het verbruik van een losse hete lucht verwarming te monitorren.
De power plug die ik ertussen heb zitten laat enkel het totaal zien en ik wil graag per dag bekijken hoelang deze heeft aangestaan en wat het verbruik is geweest.

Iedere nacht kopieer ik de staat van betreffende sensor (sensor.consumption_18) = waarde in kWh naar een hulpveld (input_number.verbruik_verwarming_hulp), zodat ik de beginstand weet en dus kan bepalen wat het verbruik die dag is geweest.

Ik heb onderstaande sensor gemaakt, die op zich prima functioneert (dwz uitkomst is logisch):

code:

      verbruik_verwarming_aan_vandaag:
        value_template: >-
          {% set laatste_verbruik = states('sensor.consumption_18') | round(3) %}
          {% set verbruik_gisteren = states('input_number.verbruik_verwarming_hulp') | round(3) %}
          {% set verbruik_vandaag = (laatste_verbruik - verbruik_gisteren) | round(3) %}
          {{ verbruik_vandaag | round(1) }}
        unit_of_measurement: 'kWh'
        friendly_name: "Verbruik verwarming"

Ik heb de "round(3)" toegevoegd om er waardes van te maken.

Echter ik zie af en toe (niet structureel!) een foutmelding in de HA logs waarvan ik vermoed dat dit van deze sensor komt. Het is in ieder geval begonnen toen ik deze sensor heb gemaakt:



Kan iemand beetje advies geven of de sensor en template ok is, of ergens verbeterd kan worden?
Is er een andere manier om er waardes van te maken?

Ik dacht zelf met "INT", maar dan worden het hele getallen en zou wel graag de cijfers achter de komma blijven behouden.

[TheFes]

feenstn schreef op woensdag 24 februari 2021 @ 14:39:
Ik heb een sensor gemaakt om het verbruik van een losse hete lucht verwarming te monitorren.
De power plug die ik ertussen heb zitten laat enkel het totaal zien en ik wil graag per dag bekijken hoelang deze heeft aangestaan en wat het verbruik is geweest.

Iedere nacht kopieer ik de staat van betreffende sensor (sensor.consumption_18) = waarde in kWh naar een hulpveld (input_number.verbruik_verwarming_hulp), zodat ik de beginstand weet en dus kan bepalen wat het verbruik die dag is geweest.

Ik heb onderstaande sensor gemaakt, die op zich prima functioneert (dwz uitkomst is logisch):

code:

      verbruik_verwarming_aan_vandaag:
        value_template: >-
          {% set laatste_verbruik = states('sensor.consumption_18') | round(3) %}
          {% set verbruik_gisteren = states('input_number.verbruik_verwarming_hulp') | round(3) %}
          {% set verbruik_vandaag = (laatste_verbruik - verbruik_gisteren) | round(3) %}
          {{ verbruik_vandaag | round(1) }}
        unit_of_measurement: 'kWh'
        friendly_name: "Verbruik verwarming"

Ik heb de "round(3)" toegevoegd om er waardes van te maken.

Echter ik zie af en toe (niet structureel!) een foutmelding in de HA logs waarvan ik vermoed dat dit van deze sensor komt. Het is in ieder geval begonnen toen ik deze sensor heb gemaakt:

[Afbeelding]

Kan iemand beetje advies geven of de sensor en template ok is, of ergens verbeterd kan worden?
Is er een andere manier om er waardes van te maken?

Ik dacht zelf met "INT", maar dan worden het hele getallen en zou wel graag de cijfers achter de komma blijven behouden.

In plaats van "| int" kun je "| float" gebruiken om het om te zetten naar een getal met decimalen.
states zijn altijd strings, dus die moet je inderdaad eerst omzetten naar een float. Attributes kunnen wel al een getal zijn.

[feenstn]

JBS schreef op woensdag 24 februari 2021 @ 14:08:

\\Edit: Stom, denk ik. Bij het handmatig uitvoeren van een automation wordt de conditie genegeerd....

Volgens mij ook, maar je kan bij "developer tools" -> "states" de waarde van je entiteit tijdelijk aanpassen. Dan zal de automation wel of niet moeten triggeren obv de conditie.

[feenstn]

TheFes schreef op woensdag 24 februari 2021 @ 14:43:
[...]


In plaats van "| int" kun je "| float" gebruiken om het om te zetten naar een getal met decimalen.
states zijn altijd strings, dus die moet je inderdaad eerst omzetten naar een float. Attributes kunnen wel al een getal zijn.

Thanks, ga ik dat proberen. Hoop dat de foutmelding ook wegblijft dan.
In de template editor werkt dit iig.

[KingKoning]

Tusk schreef op woensdag 24 februari 2021 @ 11:39:
@sjorsjuhmaniac @habbekrats @barrymossel
Ja, normaal backup ik altijd voordat ik update. Net die keer dat ik t niet doe, crasht ie. Die auto backup naar NAS ga ik zeker fixen als alles weer draait. Ik heb nu een 2 weken oude backup en de meest recente config file. Dus daar kom ik een heel eind mee.

ik gebruik zelf een add-on voor auto back-up naar Google Drive. Die zorgt ook netjes voor verwijderen van backups na # (instelbaar) aantal keer etc.

Dit soort crashes lijken op RPI wel vaker voor te komen. Ik ga toch is kijken of ik mijn database of zelfs de hele installatie, op een SSD kan zetten

[JayOne]

sjorsjuhmaniac schreef op woensdag 24 februari 2021 @ 13:38:
[...]


Tuurlijk!
Gebruik een 'helper' in de vorm van een boolean met de naam: temp_manual_override

na:
* wacht 15 minuten (misschien zijn we maar heel even weg),
zet je de temp_manual_override naar false

na:
* handmatig temp instellen als we weg zijn
zet je de temp_manual_override naar true

bij:
* zet dan de snapshot temperatuur weer terug.
gebruik je de conditie: temp_manual_override == false
(dus als hij true is, zet je snapshot temp niet terug)

@lverlaek Of je neemt bovenstaande een stapje verder en gaat werken met verschillende stadia van presence detection.

[Tusk]

KingKoning schreef op woensdag 24 februari 2021 @ 14:57:
Ik ga toch is kijken of ik mijn database of zelfs de hele installatie, op een SSD kan zetten

Septillion schreef op woensdag 3 februari 2021 @ 19:39:
@Tusk Standaard, met HA OS, niet. En nu moest ik ook hard zoeken, maar met datactl moet je de hele boel kunnen overzetten.

Is mij even een brug te ver op dit moment. Wellicht in de toekomst.

[Ora et Labora]

crimby schreef op maandag 22 februari 2021 @ 11:16:
Apex charts werkt nu wel, maar echt mega traag om alles te laden.

code:

type: custom:apexcharts-card
header:
  show: true
  title: Gas & Energie
series: 
  - entity: sensor.power_consumption
  - entity: sensor.hourly_gas_consumption
update_interval: 10min
graph_span: 7d
cache: true

Is er verder nog iets te verbeteren hierin qua performance?

Ik had dat probleem ook dat het supertraag was, vandaag overgegaan naar MariaDB als database en het is nu supersnel.
Standaard addon onder supervisor. Let wel op dat je je history kwijt bent, dat schijnt ook wel overgezet te kunnen worden maar dat was in mijn geval niet belangrijk.

[alex3305]

Iets waar ik gister achter kwam en mij toch onaangenaam heeft verrast was nadat ik de Home Assistant Android companion app opnieuw had geïnstalleerd de gegenereerde sensoren van deze app spontaan Nederlandse entity_id's kregen. Bijvoorbeeld sensor.gm1913_batterij_laadstatus waar dit eerder sensor.gm1913_battery_state was.

Ik was benieuwd hoe jullie hiermee omgaan? Aangezien de Android app zo'n vijftigtal sensoren kan aanmaken is het handmatig hernoemen uiteraard redelijk matig. Maar Nederlandse en Engelse entity_id's mixen vind ik ook geen nette oplossing. Ik had op GitHub ook al een bugreport aangemaakt, maar deze is helaas meteen afgeschoten .

[denuz]

alex3305 schreef op woensdag 24 februari 2021 @ 16:20:
Iets waar ik gister achter kwam en mij toch onaangenaam heeft verrast was nadat ik de Home Assistant Android companion app opnieuw had geïnstalleerd de gegenereerde sensoren van deze app spontaan Nederlandse entity_id's kregen. Bijvoorbeeld sensor.gm1913_batterij_laadstatus waar dit eerder sensor.gm1913_battery_state was.

Ik was benieuwd hoe jullie hiermee omgaan? Aangezien de Android app zo'n vijftigtal sensoren kan aanmaken is het handmatig hernoemen uiteraard redelijk matig. Maar Nederlandse en Engelse entity_id's mixen vind ik ook geen nette oplossing. Ik had op GitHub ook al een bugreport aangemaakt, maar deze is helaas meteen afgeschoten .

Tsjah... ze hebben de app geupdate.. Vervelend maar dit soort dingen gebeuren nou eenmaal met producten die veel updates krijgen. Wat mij betreft is de opmerking in je bugreport duidelijk. Je kan op alle telefoons die stappen uitvoeren. Dan zijn al je sensoren in het NL en is alles weer gelijk. Dit is voornamelijk voor je automations/lovelace entities?

[crimby]

Ora et Labora schreef op woensdag 24 februari 2021 @ 16:18:
[...]

Ik had dat probleem ook dat het supertraag was, vandaag overgegaan naar MariaDB als database en het is nu supersnel.
Standaard addon onder supervisor. Let wel op dat je je history kwijt bent, dat schijnt ook wel overgezet te kunnen worden maar dat was in mijn geval niet belangrijk.

Ik gebruik zowel maria db als influxdb. Zal eens wat testen. Bedankt voor de tip!

[CyberHarm]

CyberHarm schreef op zaterdag 20 februari 2021 @ 16:28:
Ik probeer de SwitchBot Curtain toe te voegen aan HA met aansturing via de SwitchBot Hub Mini. Het toevoegen via de officiële integratie lijkt te lukken, alleen het lukt mij niet om de gordijnen te bedienen via deze integratie. Ik heb ook al de onofficiële integratie geprobeerd, maar mijn Pi staat te ver weg om een goede bluetooth verbinding te krijgen.

Is er iemand dit weet hoe en of het mogelijk is de SwitchBot via de Hub in HA te bedienen?

Niemand die mijn hier mee kan helpen? Alle ideeën zijn welkom..

[alex3305]

denuz schreef op woensdag 24 februari 2021 @ 16:32:
[...]

Tsjah... ze hebben de app geupdate.. Vervelend maar dit soort dingen gebeuren nou eenmaal met producten die veel updates krijgen.

Oh, maar dat is het probleem ook niet. Ik juich de updates enorm toe. Fijn dat er zoveel mensen, enthousiast aan die mooie product en bijproducten werken.

Wat mij betreft is de opmerking in je bugreport duidelijk. Je kan op alle telefoons die stappen uitvoeren. Dan zijn al je sensoren in het NL en is alles weer gelijk.

Natuurlijk. Of ik kan in Home Assistant de sensoren weer vertalen naar het Engels. Dat is mijn inziens het ook probleem hier ook niet. Wat ik (erg) verwarrend vind is dat blijkbaar de entity_id gegenereerd wordt op basis van localization, terwijl er in de interface van de app ook gerefereerd wordt naar het unique_id van een dergelijke entity. Dit zou volgens de Developer documentatie daadwerkelijk anders zijn. Maar dat was mij tot gister niet duidelijk. En ik gebruik Home Assistant toch al een tijdje.

Dat dit blijkbaar in een oude versie anders was, vind ik ook redelijk ongelukkig. Ik verwacht namelijk met een herinstallatie hetzelfde gedrag als van voor de herinstallatie.

Buiten dit alles werkt het dus IMHO niet correct, aangezien ik nog steeds Nederlandse entity_id's krijg als de app in het Engels staat. Maar goed, dat heb ik vandaag ook toegevoegd.

Dit is voornamelijk voor je automations/lovelace entities?

Bijna. Ik gebruik dit vooral voor Template sensors. Aangezien een device id (gm1913 in mijn geval) niet altijd gelijk hoeft te zijn, heb ik dit geabstraheerd. Daarna wordt het inderdaad in automations toegepast. Bijvoorbeeld:

YAML:

- platform: template
  sensors:
    phone_alex_charging:
      friendly_name: Telefoon Alex opladen
      device_class: power
      delay_on:
        minutes: 1
      delay_off:
        minutes: 1
      value_template: "{{ (states('sensor.gm1913_battery_state') | lower) != 'discharging' }}"

    phone_alex_home_wifi:
      friendly_name: Telefoon Alex thuis wifi
      device_class: connectivity
      value_template: "{{ 'HomeFi' in states('sensor.gm1913_wifi_connection') }}"

Nogmaals het is voor mij geen grote ramp om dit aan te passen. Immers gebruik ik deze sensoren maar op een paar plekken. Maar het geeft onnodige rompslomp die ik niet had aan zien komen.

[sjorsjuhmaniac]

JBS schreef op woensdag 24 februari 2021 @ 14:08:
Onderstaande template geeft in developer tools netjes 'false' terug.

YAML:

{{ states('input_number.solaredge_pv_dagrecord_waarde') > 
states('input_number.solaredge_pv_dagrecord_allertijden') }}

Maar wanneer ik deze template als een conditie gebruik voor een automation, wordt deze automation toch afgetrapt.

YAML:

  condition:
  - condition: template
    value_template: '{{ states(''input_number.solaredge_pv_dagrecord_waarde'') > states(''input_number.solaredge_pv_dagrecord_allertijden'') }}'

Zie ik hierbij iets over het hoofd waarom deze conditie genegeerd wordt?

\\Edit: Stom, denk ik. Bij het handmatig uitvoeren van een automation wordt de conditie genegeerd....

ik zie twee enkele ' in je condition template en in de developer enkele '

[Fireball86]

Zoals beloofd zou ik nog even terugkomen op mijn probleem met de supervisor en addons. Die bleven een witte pagina houden. Wat bleek, ik had mijn Solax omvormer van de PV-panelen via WiFi rechtstreeks gekoppeld aan de NUC. Dit is maanden lang geen probleem geweest en ineens kwam dit probleem. Ik heb zoals eerder beschreven deze ontkoppeld en nu is het probleem weg. Dus gelukkig geen herinstallatie.

Daarnaast is er sindskort voor de Solax een REST api beschikbaar. Dus daar binnenkort maar eens mee stoeien. Bedankt allen voor het meedenken!

[sjorsjuhmaniac]

Valkyre schreef op woensdag 24 februari 2021 @ 14:02:
[...]


ow ja goed punt ik draai middels Z-Wave JS ik had de indruk dat momenteel het meest gangbaar is?

In de zwavejs webinterface kan je op je device klikken, 1x klik. dit is het gewone overzicht in tabelvorm, niet het mooi netwerk plaatje.

Nu je je device 'geselecteerd' hebt komt er onder op de pagina meer info. Je moet hiervoor naar onder scrollen (maar niets anders aanklikken!)
Op het tabje 'Nodes' zijn nu 3 regels erbij gekomen onder het kopje 'values':
- User
- Configuration
- System

als je deze regels openklapt zie je de instellingen van het device die je kan aanpassen.

[martinvdm]

Valkyre schreef op woensdag 24 februari 2021 @ 14:02:
[...]


ow ja goed punt ik draai middels Z-Wave JS ik had de indruk dat momenteel het meest gangbaar is?

Gangbaar zeker. Beter gezegd hetgeen nog actief ontwikkeld wordt en de toekomst is.
Voor het visualiseren van je zwave netwerk in zwavejs weet ik helaas niet. Ik gebruik het nog niet

[JBS]

sjorsjuhmaniac schreef op woensdag 24 februari 2021 @ 17:53:
[...]


ik zie twee enkele ' in je condition template en in de developer enkele '

Klopt. In de YAML worden twee quotes verwacht.

Dit wordt geaccepteerd door de config check:

YAML:

value_template: '{{ states(''input_number.solaredge_pv_dagrecord_waarde'') > states(''input_number.solaredge_pv_dagrecord_allertijden'') }}'

Dit niet:

YAML:

value_template: '{{ states('input_number.solaredge_pv_dagrecord_waarde') > states('input_number.solaredge_pv_dagrecord_allertijden') }}'

Gaf 't al aan in m'n edit: Maar ik zag het feit over het hoofd dat een conditie in een automation genegeerd wordt wanneer je de automation handmatig uitvoert.

[sjorsjuhmaniac]

CyberHarm schreef op woensdag 24 februari 2021 @ 17:36:
[...]


Niemand die mijn hier mee kan helpen? Alle ideeën zijn welkom..

Wat gaat er fout?
Heb je verbinding? Krijg je de huidige status door?
Staat er iets in je logs?

[witterholt]

Ik heb een automation gemaakt welke mijn gasverbruik elke dag upload naar mindergas.nl. Op zich werkt dat prima alleen als ik in de log kijk wordt de automation pas daadwerkelijk veel later uitgevoerd dan 23:55.
De eerste keer was dat namelijk 0:17 en de tweede keer zelfs 0:26. Ik vraag me af hoe dat kan want ik heb geen vertraging opgegeven.

Hieronder het script van de automation.

YAML:

alias: Mindergas Upload
trigger:
  platform: time
  at: '23:55:00'
action:
  data_template:
    date: '{{ (as_timestamp(now())) | timestamp_custom("%Y-%m-%d", True) }}'
    reading: '{{ states.sensor.gas_consumption.state }}'
  service: rest_command.mindergas_upload

... en het script voor het REST commando.

YAML:

mindergas_upload:
  url: 'https://www.mindergas.nl/api/meter_readings'
  method: POST
  headers
    content-type: application/json
    AUTH-TOKEN: !secret mindergas_api_token
  payload: '{ "date": "{{date}}", "reading": "{{reading}}" }'

[sjorsjuhmaniac]

witterholt schreef op woensdag 24 februari 2021 @ 20:46:
Ik heb een automation gemaakt welke mijn gasverbruik elke dag upload naar mindergas.nl. Op zich werkt dat prima alleen als ik in de log kijk wordt de automation pas daadwerkelijk veel later uitgevoerd dan 23:55.
De eerste keer was dat namelijk 0:17 en de tweede keer zelf 0:26. Ik vraag me af hoe dat kan want ik heb geen vertraging opgegeven.

Hieronder het script van de automation.

YAML:

alias: Mindergas Upload
trigger:
  platform: time
  at: '23:55:00'
action:
  data_template:
    date: '{{ (as_timestamp(now())) | timestamp_custom("%Y-%m-%d", True) }}'
    reading: '{{ states.sensor.gas_consumption.state }}'
  service: rest_command.mindergas_upload

... en het script voor het REST commando.

YAML:

mindergas_upload:
  url: 'https://www.mindergas.nl/api/meter_readings'
  method: POST
  headers
    content-type: application/json
    AUTH-TOKEN: !secret mindergas_api_token
  payload: '{ "date": "{{date}}", "reading": "{{reading}}" }'

Kun je de action eens veranderen in iets anders? bv een lamp of helper boolean schakelen? Ik heb zelf wel eens problemen met timeouts van andere systemen wat soortgelijk gedrag ooit wel eens veroorzaakt heeft.

[Valkyre]

sjorsjuhmaniac schreef op woensdag 24 februari 2021 @ 18:01:
[...]


In de zwavejs webinterface kan je op je device klikken, 1x klik. dit is het gewone overzicht in tabelvorm, niet het mooi netwerk plaatje.

Nu je je device 'geselecteerd' hebt komt er onder op de pagina meer info. Je moet hiervoor naar onder scrollen (maar niets anders aanklikken!)
Op het tabje 'Nodes' zijn nu 3 regels erbij gekomen onder het kopje 'values':
- User
- Configuration
- System

als je deze regels openklapt zie je de instellingen van het device die je kan aanpassen.

Eh als ik ga naar supervisor > addon > Z-wave JS dan kan ik via deze addon niet naar een webinterface. (nu weet ik wel tenminste waar ik nieuwe apparaten kan includen


Of bedoel je Configuration > Integrations > Z-wave JS (integration) configure ?


of zit ik nu helemaal verkeerd?

Edit:
ook dsmr reader ook aan de praat, dus de slimme meter is ook over maar ik wil graag ook die sensoren naar HA overbrengen ipv die eigen schil.

als ik het goed begrijp hoef ik dan alleen maar een sensor aan mijn configuration.yaml toe te voegen, echter heb ik de naam sensor al in gebruik (zie de duplicate key hieronder) dit is waarschijnlijk yaml 101 maar ik loop hier al even op stuk (rename naar sensor1 werkt niet)

[ Voor 21% gewijzigd door Valkyre op 24-02-2021 23:04 ]

[Rianata]

Valkyre schreef op woensdag 24 februari 2021 @ 22:34:
[...]

als ik het goed begrijp hoef ik dan alleen maar een sensor aan mijn configuration.yaml toe te voegen, echter heb ik de naam sensor al in gebruik (zie de duplicate key hieronder) dit is waarschijnlijk yaml 101 maar ik loop hier al even op stuk (rename naar sensor1 werkt niet)

[Afbeelding]

Je stelt het gewoon zo op in je configuration.yaml:

code:

sensor:
  - platform: buienalarm
    timeframe: 15
    ....

  - platform: dsmr_reader
    ...

Of je maakt een separate sensor.yaml file, waarin je alles als volgt opneemt en in configuration.yaml een !include naar dat bestand opneemt:

code:

- platform: buienalarm
    timeframe: 15
    ....

- platform: dsmr_reader
    ...

[ Voor 13% gewijzigd door Rianata op 25-02-2021 00:38 ]

[sjorsjuhmaniac]

Valkyre schreef op woensdag 24 februari 2021 @ 22:34:
[...]


Eh als ik ga naar supervisor > addon > Z-wave JS dan kan ik via deze addon niet naar een webinterface. (nu weet ik wel tenminste waar ik nieuwe apparaten kan includen
[Afbeelding]

Of bedoel je Configuration > Integrations > Z-wave JS (integration) configure ?
[Afbeelding]

of zit ik nu helemaal verkeerd?

Nee sorry, ik zat verkeerd ik dacht dat je zwavejs2mqtt add-on gebruikt maar je gebruikte zwavejs integration zie ik.

Ik heb daar geen ervaring mee Heb je de documentatie al bekeken? Zie bullet 2

Valkyre schreef op woensdag 24 februari 2021 @ 22:34:

Edit:
ook dsmr reader ook aan de praat, dus de slimme meter is ook over maar ik wil graag ook die sensoren naar HA overbrengen ipv die eigen schil.

als ik het goed begrijp hoef ik dan alleen maar een sensor aan mijn configuration.yaml toe te voegen, echter heb ik de naam sensor al in gebruik (zie de duplicate key hieronder) dit is waarschijnlijk yaml 101 maar ik loop hier al even op stuk (rename naar sensor1 werkt niet)

[Afbeelding]

En wat @Rianata zegt, je kan maar 1x 'sensor:' in je yaml hebben

[ Voor 25% gewijzigd door sjorsjuhmaniac op 25-02-2021 07:48 ]

[Septillion]

Rianata schreef op donderdag 25 februari 2021 @ 00:36:
Of je maakt een separate sensor.yaml file, waarin je alles als volgt opneemt en in configuration.yaml een !include naar dat bestand opneemt:

Moet je wel twee spaties bij alle lijnen weg halen

[-Casper]

Zijn hier nog mensen die automations hebben waarmee de temperatuur in huis wordt geregeld en rekening houden met het weer buiten? Kan natuurlijk zelf wat bedenken maar wel leuk om even te zien wat anderen hiervoor hebben staan.

Daarbij ook direct de oproep voor mensen die hun HA op github hebben staan om dat even te melden bij een topic starter. Ik zie alleen HmmBob zijn github staan, handig maar meer inspiratie is altijd welkom!

[Septillion]

water_escape schreef op woensdag 24 februari 2021 @ 14:07:
Ik heb in mijn overkapping Hue gu10 lampen gedaan.

Als ik nu via ZHA scan voor nieuw devices komen de lampen niet naar voren toe, er wordt niks gevonden.
Wanneer ik in de HUE app zoek naar lampen komen ze wel naar voren.

Hoe zorg ik dat deze door ZHA gevonden kunnen worden? Sensoren en switches is wel gelukt daarmee. Mis ik iets mbt lampen?

Aangezien ZHA geen link met Hue heeft heb je dus twee netwerken draaien. Ik zou dan denken dat je ZHA netwerk simpelweg niet tot de spotjes reikt (geen mesh tot daar vormt) en je Hue netwerk dat wel doet. Probeer eens zo'n GU10 in de buurt van je Zigbee stick te pairen.

[mAiden88]

-Casper schreef op donderdag 25 februari 2021 @ 08:20:
Zijn hier nog mensen die automations hebben waarmee de temperatuur in huis wordt geregeld en rekening houden met het weer buiten? Kan natuurlijk zelf wat bedenken maar wel leuk om even te zien wat anderen hiervoor hebben staan.

Daarbij ook direct de oproep voor mensen die hun HA op github hebben staan om dat even te melden bij een topic starter. Ik zie alleen HmmBob zijn github staan, handig maar meer inspiratie is altijd welkom!

Ik bepaal de comfort stand op basis van de buitentemperatuur. Als deze lager is dan 4 graden om 19uur, zet HA mij nest thermostaat naar 21gr.

Op basis van de buitentemperatuur zet HA Nest ook op ECO modus. Hoger dan 16 graden zal Nest naar ECO gaan. En visaversa weer als Nest aan moet maar dan lager.

Wil er nog meer mee, dus ben benieuwd wat jij of andere ermee doen.

[DaLass]

witterholt schreef op woensdag 24 februari 2021 @ 20:46:
Ik heb een automation gemaakt welke mijn gasverbruik elke dag upload naar mindergas.nl. Op zich werkt dat prima alleen als ik in de log kijk wordt de automation pas daadwerkelijk veel later uitgevoerd dan 23:55.
De eerste keer was dat namelijk 0:17 en de tweede keer zelfs 0:26. Ik vraag me af hoe dat kan want ik heb geen vertraging opgegeven.

Hieronder het script van de automation.

YAML:

alias: Mindergas Upload
trigger:
  platform: time
  at: '23:55:00'
action:
  data_template:
    date: '{{ (as_timestamp(now())) | timestamp_custom("%Y-%m-%d", True) }}'
    reading: '{{ states.sensor.gas_consumption.state }}'
  service: rest_command.mindergas_upload

... en het script voor het REST commando.

YAML:

mindergas_upload:
  url: 'https://www.mindergas.nl/api/meter_readings'
  method: POST
  headers
    content-type: application/json
    AUTH-TOKEN: !secret mindergas_api_token
  payload: '{ "date": "{{date}}", "reading": "{{reading}}" }'

Ik heb 2 uploads naar mindergas vanuit HA, eentje voor gasverbruik en eentje voor electriciteitsverbruik van mijn L/L warmtepomp, beide triggeren netjes op de ingestelde tijden. Mijn automations heb ik gebouwd vanuit de UI, maar als ik de YAML opvraag ziet deze er nagenoeg hetzelfde uit als die van jou:

code:

alias: '[ENERGY] - Mindergas m3 Upload'
description: Upload gas meterstand naar mindergas.nl
trigger:
  - platform: time
    at: '00:15'
condition: []
action:
  - data_template:
      date: >-
        {{ (as_timestamp(now()) - (24*3600)) | timestamp_custom("%Y-%m-%d",
        True)}}
      reading: '{{ states.sensor.toon_gas_used_cnt.state }}'
    service: rest_command.mindergas_m3_upload
mode: single

En mijn rest stukje:

code:

# Upload gas usage to mindergas.nl
# ---------------------------------
  mindergas_m3_upload:
    url: "https://www.mindergas.nl/api/meter_readings"
    method: POST
    headers:
      content-type: application/json
      AUTH-TOKEN: !secret mindergas_api_token_m3
    payload: '{ "date": "{{date}}", "reading": "{{reading}}" }'

Ik heb geen idee of de

code:

mode: single

er iets mee te maken kan hebben?

[Yukkie]

Slechts zijdelings een HA probleem, maar misschien scheelt dit iemand anders zoeken naar een oplossing:
Gisteravond heeft Watchtower mijn Influxdb container geupdate. Blijkbaar is het latest image nu gebaseerd op influxdb 2.x en is daarin iets veranderd met authenticatie (?), iig al mijn systemen die met influxdb communiceerden hadden 401 en/of 400 errors, zo ook Home-Assistant. Voor nu even opgelost met een nieuwe container obv een 1.8.4 image. Vanavond maar even verder in duiken.

Edit: deze link gevonden, later vandaag eens proberen: https://github.com/docker...custom-influxdb-1x-config

Edit2: Hmm ik denk dat ik het voorlopig op Influx 1.8 hou. Ook de hele Home-Assistant Influx configuratie moet anders omgegooid worden

[ Voor 28% gewijzigd door Yukkie op 25-02-2021 09:17 ]

[Septillion]

@alex3305 Inderdaad een irritante aanpassing Toevallig heeft mijn vriendin ook net een nieuwe telefoon in het Nederlands en zie opeens ook allemaal Nederlandse entities

Meeste integraties doen entity suffix gewoon in het Engels. En een 'light' (type) is in het Nederlands opeens ook niet een 'lamp'. Lekker Denglish entities krijg je dan ;/ Voor de friendly name kon ik er wel inkomen maar voor enities voelt dit wel als enorme stap achteruit

Vanmiddag maar haar telefoon weer eens vragen en alle HA opnieuw doen in het Engels...

[alex3305]

Septillion schreef op donderdag 25 februari 2021 @ 08:51:
Meeste integraties doen entity suffix gewoon in het Engels. En een 'light' (type) is in het Nederlands opeens ook niet een 'lamp'. Lekker Denglish entities krijg je dan ;/ Voor de friendly name kon ik er wel inkomen maar voor enities voelt dit wel als enorme stap achteruit

Het zou mij persoonlijk geen biet interesseren of entiteiten in het Engels of Nederlands zouden zijn, maar alsjeblieft niet door elkaar heen. Zoals jij op GitHub al zei, dit is pretty undesirable design, en daar sla je wat mij betreft de spijker op de kop. Ik wilde het niet zo hard stellen, maar uiteraard vind ik het fijn dat je mij hierin bijval geeft .

Vanmiddag maar haar telefoon weer eens vragen en alle HA opnieuw doen in het Engels...

Dat werkte bij mij dus niet . Geen idee of dat nu weer een nieuwe bug is of niet. Ik ben benieuwd of het bij jou wel werkt. Je kunt (voor nu) in de backend alle entity id's hernoemen, dat werkt in ieder geval ook. Dan hoeft zij in ieder geval niets aan te passen. Maar ik houd mijn hart vast voor nieuwe sensoren...

[habbekrats]

@Rianata
Ik had liever gezien dat ze dit vanaf eerste installatie hadden doorgezet
gewoon voor elke subgroep een yaml, mijn configuration was op een geven moment een ellenlang document.
Liever een yaml voor sensor, Switch,Light enz.

[Koffie]

habbekrats schreef op donderdag 25 februari 2021 @ 10:03:
@Rianata
Ik had liever gezien dat ze dit vanaf eerste installatie hadden doorgezet
gewoon voor elke subgroep een yaml, mijn configuration was op een geven moment een ellenlang document.
Liever een yaml voor sensor, Switch,Light enz.

Dat kan toch ook gewoon? Ik heb voor elke scheet een eigen yaml.

[habbekrats]

@Koffie Jazeker maar voor beginners had dit beeter standaard er in gebkakken kunnen zitten.

[Septillion]

@habbekrats Eens! Ook al ben ik ook groot voorstander van de UI die dan YAML maakt zoals automations. Nog steeds erg jammer dat dit voor de helpers niet zo gedaan wordt

[Koffie]

habbekrats schreef op donderdag 25 februari 2021 @ 10:07:
@Koffie Jazeker maar voor beginners had dit beeter standaard er in gebkakken kunnen zitten.

Ik snap dat er een giga drang vanuit HA is dat Truus van de tennisclub het ook moet kunnen installeren en gebruiken, maar die zal het aan haar tennisballen jeuken hoeveel yaml's er in de achtergrond bestaan
De enige manier om dat op te lossen is *alles* via de GUI te maken, en dan boeit het dus niet waar het staat.

Wil je het liever met de hand doen? Dat kan, en dan kun je net zoveel yaml's maken als je wil

Septillion schreef op donderdag 25 februari 2021 @ 10:13:
@habbekrats Eens! Ook al ben ik ook groot voorstander van de UI die dan YAML maakt zoals automations. Nog steeds erg jammer dat dit voor de helpers niet zo gedaan wordt

Voor mij dé reden om geen helpers aan te maken via de GUI, die verdwijnen in een zwart gat buiten mijn yaml om.

[ Voor 24% gewijzigd door Koffie op 25-02-2021 10:16 ]

[Septillion]

@Koffie Ik ben nog in limbo... Via de UI zijn ze wel weer makkelijk aan te passen maar weer lastig te kopiëren... En het hele parsen van een helper lijkt mij een stuk eenvoudiger dan een automation.

Op zich ben ik geen YAML fan maar werkelijk iets low level kunnen doen en kunnen knippen en plakken (en dus delen) maakt het wel erg fijn.

[Kenny73]

Zijn er meerdere Tweakers die de laatste dagen problemen hebben met de Garmin integratie?


edit: het lijkt erop dat Garmin de APi heeft aangepast.
Nu maar wachten op een fix.

[ Voor 12% gewijzigd door Kenny73 op 25-02-2021 13:26 ]

[CyberHarm]

sjorsjuhmaniac schreef op woensdag 24 februari 2021 @ 20:37:
[...]


Wat gaat er fout?
Heb je verbinding? Krijg je de huidige status door?
Staat er iets in je logs?

Ik heb de integratie van officiële SwitchBot gebruikt, maar krijg het idee dat dit niet werkt voor de SwitchBot curtains (maar alleen voor de SwitchBot Bot). Ik heb namelijk wel met succes een "switch.swichtbot" entiteit toegevoegd door onderstaand in mijn config toe te voegen, maar zou niet weten hoe ik hier verder mee moet.

YAML:

switch:
  - platform: switchbot
    mac: "MAC_ADDRESS"

Misschien dat ik mijn vraag niet helemaal goed gesteld heb, ik vraag mijn namelijk af of het mogelijk is vanuit HA een verbinding met de SwitchBot Hub Mini te maken en daarmee mijn gordijnen aan te sturen.

Ik heb het namelijk ook geprobeerd te doen via deze integratie: https://github.com/alextud/ha-switchbot-curtain

Maar die gebruikt de Hub niet en stuurt de SwichBot Curtains direct aan via bluetooth van de Pi, maar helaas staat mijn Pi4 met HA te ver weg om een stabiele verbinding te houden (heel soms maakt hij even verbinding).

Hoop eigenlijk dat er iemand is die een mooie oplossing voor mij heeft..

[water_escape]

Ik wil een automation maken dat alle lampen op een tijdstip uitgaan, mocht er nog iets aan staan. Op een paar lampen na (buiten).

De meeste lampen staan in groepen. Kan ik nu de groepen in 1 groep zetten en die aanroepen of moet ik alle losse lampen (enitities) aan een nieuwe groep "all lights" toevoegen?

[golles]

water_escape schreef op donderdag 25 februari 2021 @ 13:22:
Ik wil een automation maken dat alle lampen op een tijdstip uitgaan, mocht er nog iets aan staan. Op een paar lampen na (buiten).

De meeste lampen staan in groepen. Kan ik nu de groepen in 1 groep zetten en die aanroepen of moet ik alle losse lampen (enitities) aan een nieuwe groep "all lights" toevoegen?

Ik heb denk ik wel een pareltje voor je:

YAML:

script:
  everything_off:
    description: Turn everything off in the house
    mode: single
    fields:
      exclude_entity_ids:
        description: entity_ids to exclude
    sequence:
      - service: homeassistant.turn_off
        data:
          entity_id: >
            {{
              (
                expand(
                  states.light
                  | selectattr('state', 'eq', 'on')
                  | rejectattr('attributes.is_hue_group')
                ) +
                expand(
                  states.media_player
                  | rejectattr('state', 'in', ['off', 'unavailable'])
                )
              )
                | rejectattr('entity_id', 'in', exclude_entity_ids)
                | map(attribute='entity_id')
                | join(', ')
            }}

Dit script gebruik ik als master switch om alle lampen en media players uit te zetten, maar met de optie om bepaalde dingen aan te laten.
Ik exclude is_hue_group lampen, omdat hij anders dubbel dingen probeert uit te zetten.

Je kunt dit bijvoorbeeld zo aanroepen:

YAML:

- service: script.everything_off
  data:
    exclude_entity_ids: light.gekleurde_licht

[RudolfR]

@water_escape

De light.turn_off-service accepteert (denk ik) ook een lijst met groepen in de automation?

(Volgens mij was er ooit een automatische groep met alle lichten, maar die zie ik niet meer...
een groep 'all lights' waar niet alle lampen inzitten lijkt me verwarrend)

[ Voor 44% gewijzigd door RudolfR op 25-02-2021 13:51 ]

[water_escape]

oe hier moet ik even induiken. Klinkt goed iig, kijken of mij dat lukt alleen.

golles schreef op donderdag 25 februari 2021 @ 13:43:
[...]


Ik heb denk ik wel een pareltje voor je:

YAML:

script:
  everything_off:
    description: Turn everything off in the house
    mode: single
    fields:
      exclude_entity_ids:
        description: entity_ids to exclude
    sequence:
      - service: homeassistant.turn_off
        data:
          entity_id: >
            {{
              (
                expand(
                  states.light
                  | selectattr('state', 'eq', 'on')
                  | rejectattr('attributes.is_hue_group')
                ) +
                expand(
                  states.media_player
                  | rejectattr('state', 'in', ['off', 'unavailable'])
                )
              )
                | rejectattr('entity_id', 'in', exclude_entity_ids)
                | map(attribute='entity_id')
                | join(', ')
            }}

Dit script gebruik ik als master switch om alle lampen en media players uit te zetten, maar met de optie om bepaalde dingen aan te laten.
Ik exclude is_hue_group lampen, omdat hij anders dubbel dingen probeert uit te zetten.

Je kunt dit bijvoorbeeld zo aanroepen:

YAML:

- service: script.everything_off
  data:
    exclude_entity_ids: light.gekleurde_licht

[water_escape]

Heb je gelijk in. En is weer enorm veel werk om groepen te maken.
Maar de lijst met groepen toevoegen is ook erg veel omdat ik veel groepen hebben.

zoek dus iets om te zeggen " alle lampen, maakt iet uit welke uitzetten" behalve x en x .

RudolfR schreef op donderdag 25 februari 2021 @ 13:49:
@water_escape

De light.turn_off-service accepteert (denk ik) ook een lijst met groepen in de automation?

(Volgens mij was er ooit een automatische groep met alle lichten, maar die zie ik niet meer...
een groep 'all lights' waar niet alle lampen inzitten lijkt me verwarrend)

[sjorsjuhmaniac]

Yukkie schreef op donderdag 25 februari 2021 @ 08:51:
Slechts zijdelings een HA probleem, maar misschien scheelt dit iemand anders zoeken naar een oplossing:
Gisteravond heeft Watchtower mijn Influxdb container geupdate. Blijkbaar is het latest image nu gebaseerd op influxdb 2.x en is daarin iets veranderd met authenticatie (?), iig al mijn systemen die met influxdb communiceerden hadden 401 en/of 400 errors, zo ook Home-Assistant. Voor nu even opgelost met een nieuwe container obv een 1.8.4 image. Vanavond maar even verder in duiken.

Edit: deze link gevonden, later vandaag eens proberen: https://github.com/docker...custom-influxdb-1x-config

Edit2: Hmm ik denk dat ik het voorlopig op Influx 1.8 hou. Ook de hele Home-Assistant Influx configuratie moet anders omgegooid worden

Daarom moet men ook nooit :latest images draaien. Je bent zo maar de sigaar, zoals jij nu. Ik snap werkelijk niet waarom dit nooit duidelijk uitgelegd wordt.

Het nadeel is natuurlijk duidelijk: je moet handmatig iets updaten door je image tag te veranderen...

[JayOne]

sjorsjuhmaniac schreef op donderdag 25 februari 2021 @ 14:58:
[...]


Daarom moet men ook nooit :latest images draaien. Je bent zo maar de sigaar, zoals jij nu. Ik snap werkelijk niet waarom dit nooit duidelijk uitgelegd wordt.

Het nadeel is natuurlijk duidelijk: je moet handmatig iets updaten door je image tag te veranderen...

Daarom gebruik ik binnen Portainer twee stacks. Eén als productie met het versienummer van de image en een test met latest. Bij een nieuwe release stop ik de productie stack en start de test stack. Wanneer alles naar behoren werkt (voor bijvoorbeeld een dag) dan wijzig ik de productie stack en start deze. Bij problemen heb ik dan altijd de werkende stack nog achter de hand.

[Yukkie]

@sjorsjuhmaniac Nou ja moeten... je moet ademen, eten en poepen, de rest is optioneel.
Het gaat al 3 jaar goed. Vanmorgen even een puzzel momentje. Het was vrij snel opgelost en hopelijk kunnen er meer mensen snel weer verder nav mijn post.

Onlangs met die security issues was ik blij dat ik de latest-image van HA draaide. Ik had nergens een omkijken naar. Maar bij mijn ouders (die draaien een Pi met HaOS) moest ik telkens handmatig updaten.

[sjorsjuhmaniac]

Yukkie schreef op donderdag 25 februari 2021 @ 15:08:
@sjorsjuhmaniac Nou ja moeten... je moet ademen, eten en poepen, de rest is optioneel.
Het gaat al 3 jaar goed. Vanmorgen even een puzzel momentje. Het was vrij snel opgelost en hopelijk kunnen er meer mensen snel weer verder nav mijn post.

Begrijp me niet vekeerd: je post is top!

Onlangs met die security issues was ik blij dat ik de latest-image van HA draaide. Ik had nergens een omkijken naar. Maar bij mijn ouders (die draaien een Pi met HaOS) moest ik telkens handmatig updaten.

Ja dat is waar, maar je hebt de release notes niet gelezen voor je update. Anders had je het gezien. Mijn punt is dat weinig mensen dat doen, waaronder ikzelf. Ik draai daarom als bescherming nooit latest en kies altijd voor een handmatige update.

HA updates vind ik nog iets anders. Ik heb HA pas sinds kort en ken hun release schedule niet maar ik vermoed dat zij geen majors updates pushen met breaking changes. Dit gebeurt wel vaak met de latest image. Latest is vaak alleen maar de latest stable en kan verschillende major versies omvatten, is bijna zoiets als een stapje verder als Beta releases, maar dan stable: Gamma releases?

Veel goede maintainers bieden je ook een stable tag per major version aan, waaronder influxdb. als je bv :1.8 had gedraaid had alsnog 'standaard updates' maar was je wel binnen je bestaande major versie gebeleven.

Anyway, allemaal persoonlijk en afhankelijk van de tijd en moeite die je eraan kwijt wil zijn. Ikzelf wil er geen tijd aan besteden en zet alles vast op werkende versies. Ik update het wel met de hand als iets niet lekker werkt

[sjorsjuhmaniac]

JayOne schreef op donderdag 25 februari 2021 @ 15:05:
[...]

Daarom gebruik ik binnen Portainer twee stacks. Eén als productie met het versienummer van de image en een test met latest. Bij een nieuwe release stop ik de productie stack en start de test stack. Wanneer alles naar behoren werkt (voor bijvoorbeeld een dag) dan wijzig ik de productie stack en start deze. Bij problemen heb ik dan altijd de werkende stack nog achter de hand.

Hopelijk wel met andere binds anders ben je nog je database/config kwijt als ze die updaten of verprutsen.

[sjorsjuhmaniac]

CyberHarm schreef op donderdag 25 februari 2021 @ 13:16:
[...]


Ik heb de integratie van officiële SwitchBot gebruikt, maar krijg het idee dat dit niet werkt voor de SwitchBot curtains (maar alleen voor de SwitchBot Bot). Ik heb namelijk wel met succes een "switch.swichtbot" entiteit toegevoegd door onderstaand in mijn config toe te voegen, maar zou niet weten hoe ik hier verder mee moet.

YAML:

switch:
  - platform: switchbot
    mac: "MAC_ADDRESS"

De originele integratie ondersteund alleen maar bluetooth

Mogelijk kan je met hub mini via bleutooth connecten?

Misschien dat ik mijn vraag niet helemaal goed gesteld heb, ik vraag mijn namelijk af of het mogelijk is vanuit HA een verbinding met de SwitchBot Hub Mini te maken en daarmee mijn gordijnen aan te sturen.

Ik heb het namelijk ook geprobeerd te doen via deze integratie: https://github.com/alextud/ha-switchbot-curtain

Maar die gebruikt de Hub niet en stuurt de SwichBot Curtains direct aan via bluetooth van de Pi, maar helaas staat mijn Pi4 met HA te ver weg om een stabiele verbinding te houden (heel soms maakt hij even verbinding).

Hoop eigenlijk dat er iemand is die een mooie oplossing voor mij heeft..

gebruik je wel het bluetooth mac adress, en niet je wifi mac, van je mini? staat nergens duidelijk maar er is een kleine kans dat de 'bot' en 'hub' heel misschien nog hetzelfde praten.

De bot is echter een 'end device' zoals je curtain. De hub is dat duidelijk niet. Maar het is te proberen.


edit:
ik heb nog even verder gezocht en vond deze repo, lijkt zelfs van switchbot zelf te zijn:
https://github.com/OpenWo...ebridge-switchbot-openapi

Heeft niets met HA te maken maar laat wel zien dat het mogelijk is via de switchbot api. Hiervoor moet je dus helaas wel via de switchbot cloud.

[ Voor 8% gewijzigd door sjorsjuhmaniac op 25-02-2021 15:54 ]

[TheFes]

JBS schreef op woensdag 24 februari 2021 @ 18:59:
[...]
Klopt. In de YAML worden twee quotes verwacht.

Dit wordt geaccepteerd door de config check:

YAML:

value_template: '{{ states(''input_number.solaredge_pv_dagrecord_waarde'') > states(''input_number.solaredge_pv_dagrecord_allertijden'') }}'

Dit niet:

YAML:

value_template: '{{ states('input_number.solaredge_pv_dagrecord_waarde') > states('input_number.solaredge_pv_dagrecord_allertijden') }}'

Gaf 't al aan in m'n edit: Maar ik zag het feit over het hoofd dat een conditie in een automation genegeerd wordt wanneer je de automation handmatig uitvoert.

2 single quotes hoeft niet hoor, maar je dan moet je je hele template tussen enkele dubbel-quotes zetten.
Zo dus:

YAML:

value_template: "{{ states('input_number.solaredge_pv_dagrecord_waarde') > states('input_number.solaredge_pv_dagrecord_allertijden') }}"

Of andersom:

YAML:

value_template: '{{ states("input_number.solaredge_pv_dagrecord_waarde") > states("input_number.solaredge_pv_dagrecord_allertijden") }}'

[sjorsjuhmaniac]

JBS schreef op woensdag 24 februari 2021 @ 18:59:
[...]
Klopt. In de YAML worden twee quotes verwacht.

Dit wordt geaccepteerd door de config check:

YAML:

value_template: '{{ states(''input_number.solaredge_pv_dagrecord_waarde'') > states(''input_number.solaredge_pv_dagrecord_allertijden'') }}'

Dit niet:

YAML:

value_template: '{{ states('input_number.solaredge_pv_dagrecord_waarde') > states('input_number.solaredge_pv_dagrecord_allertijden') }}'

Gaf 't al aan in m'n edit: Maar ik zag het feit over het hoofd dat een conditie in een automation genegeerd wordt wanneer je de automation handmatig uitvoert.

Hmmm... heb ik nog nooit gezien. Ik heb de waarde altijd tussen dubbele quotes staan, dan je de info uit je template test gewoon kopieren/plakken.

edit: wat @TheFes zegt

[Robbie T]

drentsemoi schreef op dinsdag 23 februari 2021 @ 12:29:
[...]


Je kan in Home Assistant gebruik maken van "helpers" welke je kan vinden onder "configuration" (zo worden ze in het Engels genoemd iig). Dit zijn virtuele schakelaars die je danwel handmatig, danwel via een automation kan switchen.

Wat ik hierboven kan vinden, zou je dus een aantal input-booleans kunnen maken:

• iemand thuis
• oppas
• vakantie
• niemand thuis
• slapen

Deze danwel handmatig of via een automation aanpassen.

Ik moet zeggen dat ik het allemaal nog wel lastig vind hoor. Ik heb nu 4 schakelaars aangemaakt:
- Thuis
- Niemand thuis
- Nacht
- Vakantie

Wat ik nu wil, om te beginnen, is dat de schakelaar "thuis" op aan gaat als ik of mijn vriendin of beide thuis is en als dat niet het geval is deze schakelaar thuis op uit gaat.

Ik vind op internet allerlei voorbeelden die het allemaal net niet zijn en ook heb ik het idee dat lang niet alles up-to-date is.

Kan iemand mij helpen met een automation voorbeeld zodat ik vanaf daar hopelijk verder kan werken?

[TheFes]

Robbie T schreef op donderdag 25 februari 2021 @ 16:07:
[...]


Ik moet zeggen dat ik het allemaal nog wel lastig vind hoor. Ik heb nu 4 schakelaars aangemaakt:
- Thuis
- Niemand thuis
- Nacht
- Vakantie

Wat ik nu wil, om te beginnen, is dat de schakelaar "thuis" op aan gaat als ik of mijn vriendin of beide thuis is en als dat niet het geval is deze schakelaar thuis op uit gaat.

Ik vind op internet allerlei voorbeelden die het allemaal net niet zijn en ook heb ik het idee dat lang niet alles up-to-date is.

Kan iemand mij helpen met een automation voorbeeld zodat ik vanaf daar hopelijk verder kan werken?

Die eerste twee hoef je eigenlijk al niet met een input_boolean te doen, ik zou dat met een group doen.

Als het goed is heb je nu twee person entities, person.robbie_t en person.vriendin_robbie_t.
Je kunt deze in een group zetten: https://www.home-assistant.io/integrations/group/

Je krijgt dan dus een groep, bijvoorbeeld group.tortelduifjes

De state van group.tortelduifjes zal 'home' zijn wanneer minstens één van jullie thuis is, en 'not_home' als jullie beide niet thuis zijn.

Deze group kun je dan gebruiken om je input_boolean.vakantie te schakelen.

Maak in de UI een automation aan, met als trigger type state (of staat in NL).
Daar kies je dan je group.tortelduifjes
Als state to kies je not_home
En bij for vul je 24:00:00 in.

Bij action kies je voor type actie service aanroepen.
Dan als service input_boolean.turn_on
en als entiteit input_boolean.vakantie

Nu heb je een automation aangemaakt die die input_boolean aan zet als jullie beide 24 uur niet thuis zijn.

[Robbie T]

TheFes schreef op donderdag 25 februari 2021 @ 16:17:
[...]


Die eerste twee hoef je eigenlijk al niet met een input_boolean te doen, ik zou dat met een group doen.

Als het goed is heb je nu twee person entities, person.robbie_t en person.vriendin_robbie_t.
Je kunt deze in een group zetten: https://www.home-assistant.io/integrations/group/

Je krijgt dan dus een groep, bijvoorbeeld group.tortelduifjes

De state van group.tortelduifjes zal 'home' zijn wanneer minstens één van jullie thuis is, en 'not_home' als jullie beide niet thuis zijn.

Deze group kun je dan gebruiken om je input_boolean.vakantie te schakelen.

Maak in de UI een automation aan, met als trigger type state (of staat in NL).
Daar kies je dan je group.tortelduifjes
Als state to kies je not_home
En bij for vul je 24:00:00 in.

Bij action kies je voor type actie service aanroepen.
Dan als service input_boolean.turn_on
en als entiteit input_boolean.vakantie

Nu heb je een automation aangemaakt die die input_boolean aan zet als jullie beide 24 uur niet thuis zijn.

Dank voor de snelle reactie! Plaats ik deze group gewoon in configuration.yaml of ergens anders?

[TheFes]

Robbie T schreef op donderdag 25 februari 2021 @ 16:27:
[...]


Dank voor de snelle reactie! Plaats ik deze group gewoon in configuration.yaml of ergens anders?

Heb je op die link geklikt? Het voorbeeld begint gewoon met:

YAML:

# Example configuration.yaml entry

[Robbie T]

TheFes schreef op donderdag 25 februari 2021 @ 16:29:
[...]


Heb je op die link geklikt? Het voorbeeld begint gewoon met:

code:

# Example configuration.yaml entry

God ja..afgeleid door deze regel in configuration.yaml

code:

group: !include groups.yaml

[TheFes]

Robbie T schreef op donderdag 25 februari 2021 @ 16:30:
[...]


God ja..afgeleid door deze regel in configuration.yaml

code:

group: !include groups.yaml

Die moet je dan wel weghalen, je kunt niet twee keer group: hebben in je config.
Maar beter is om die group dan gewoon in groups.yaml te zetten.

Dan moet je wel group: weghalen uit het voorbeeld, en alles twee spaties naar voren zetten.

[sOid]

Yukkie schreef op donderdag 25 februari 2021 @ 08:51:
Slechts zijdelings een HA probleem, maar misschien scheelt dit iemand anders zoeken naar een oplossing:
Gisteravond heeft Watchtower mijn Influxdb container geupdate. Blijkbaar is het latest image nu gebaseerd op influxdb 2.x en is daarin iets veranderd met authenticatie (?), iig al mijn systemen die met influxdb communiceerden hadden 401 en/of 400 errors, zo ook Home-Assistant. Voor nu even opgelost met een nieuwe container obv een 1.8.4 image. Vanavond maar even verder in duiken.

Edit: deze link gevonden, later vandaag eens proberen: https://github.com/docker...custom-influxdb-1x-config

Edit2: Hmm ik denk dat ik het voorlopig op Influx 1.8 hou. Ook de hele Home-Assistant Influx configuratie moet anders omgegooid worden

Godgloeiende, had ik dit een half uurtje geleden maar gelezen

Nou ja, ik wou toch eigenlijk opnieuw beginnen met influxdb. Eerste keer niet helemaal lekker geconfigureerd.

[Robbie T]

TheFes schreef op donderdag 25 februari 2021 @ 16:32:
[...]


Die moet je dan wel weghalen, je kunt niet twee keer group: hebben in je config.
Maar beter is om die group dan gewoon in groups.yaml te zetten.

Dan moet je wel group: weghalen uit het voorbeeld, en alles twee spaties naar voren zetten.

Gelukt. Mijn groups.yaml ziet er nu zo uit:

YAML:

################################################
#Create a group for home or not
################################################  
group:
  name: Thuis    
    entities:
      - device_tracker.telefoon_rob
      - device_tracker.telefoon_marleen

Mijn group in de ui heeft nu als entity: group.group, hoe pas ik dat aan?
Als ik het voorbeeld aanhoud van de website

YAML:

################################################
#Create a group for home or not
################################################  
group:
  thuis:
    name: Thuis
    entities:
      - device_tracker.telefoon_rob
      - device_tracker.telefoon_marleen

Krijg ik namelijk de volgende error:

code:

Invalid config for [group]: [thuis] is an invalid option for [group]. Check: group->group->group->thuis. (See /config/configuration.yaml, line 95). Please check the docs at https://www.home-assistant.io/integrations/group

[TheFes]

Robbie T schreef op donderdag 25 februari 2021 @ 16:52:
[...]


Gelukt. Mijn groups.yaml ziet er nu zo uit:

YAML:

################################################
#Create a group for home or not
################################################  
group:
  name: Thuis    
    entities:
      - device_tracker.telefoon_rob
      - device_tracker.telefoon_marleen

Mijn group in de ui heeft nu als entity: group.group, hoe pas ik dat aan?
Als ik het voorbeeld aanhoud van de website

YAML:

################################################
#Create a group for home or not
################################################  
group:
  thuis:
    name: Thuis
    entities:
      - device_tracker.telefoon_rob
      - device_tracker.telefoon_marleen

Krijg ik namelijk de volgende error:

code:

Invalid config for [group]: [thuis] is an invalid option for [group]. Check: group->group->group->thuis. (See /config/configuration.yaml, line 95). Please check the docs at https://www.home-assistant.io/integrations/group

Door iets beter te lezen

TheFes schreef op donderdag 25 februari 2021 @ 16:32:
[...]
Dan moet je wel group: weghalen uit het voorbeeld, en alles twee spaties naar voren zetten.

YAML:

################################################
#Create a group for home or not
################################################  
thuis:
  name: Thuis
  entities:
    - device_tracker.telefoon_rob
    - device_tracker.telefoon_marleen

[ Voor 3% gewijzigd door TheFes op 25-02-2021 17:10 ]

[engibenchi]

Wil ik eindelijk mijn eerste automation gaan maken is heel dat tabblad weg
Het komt niet helemaal out of the blue, Heb gisteravond even op mijn telefoon zit proberen maar kwam niet verder omdat de automations niet werden opgeslagen en zelfs eentje die ik eerder al heb proberen te maken was verdwenen.
Vandaag in een poging het niet willen opslaan op te lossen een restart van HA gedaan. Nu is het tabblad verdwenen en siert een foutmelding mijn log file:

code:

2021-02-25 16:59:02 ERROR (MainThread) [homeassistant.setup] Error during setup of component automation
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/device_automation/__init__.py", line 81, in async_get_device_automation_platform
    integration = await async_get_integration_with_requirements(hass, domain)
  File "/usr/src/homeassistant/homeassistant/requirements.py", line 50, in async_get_integration_with_requirements
    integration = await async_get_integration(hass, domain)
  File "/usr/src/homeassistant/homeassistant/loader.py", line 542, in async_get_integration
    raise IntegrationNotFound(domain)
homeassistant.loader.IntegrationNotFound: Integration '' not found.

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/setup.py", line 213, in _async_setup_component
    result = await task
  File "/usr/src/homeassistant/homeassistant/components/automation/__init__.py", line 169, in async_setup
    if not await _async_process_config(hass, config, component):
  File "/usr/src/homeassistant/homeassistant/components/automation/__init__.py", line 518, in _async_process_config
    await async_validate_config_item(
  File "/usr/src/homeassistant/homeassistant/components/automation/config.py", line 74, in async_validate_config_item
    config[CONF_ACTION] = await script.async_validate_actions_config(
  File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 143, in async_validate_actions_config
    return await asyncio.gather(
  File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 182, in async_validate_action_config
    config[CONF_DEFAULT] = await async_validate_actions_config(
  File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 143, in async_validate_actions_config
    return await asyncio.gather(
  File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 158, in async_validate_action_config
    platform = await device_automation.async_get_device_automation_platform(
  File "/usr/src/homeassistant/homeassistant/components/device_automation/__init__.py", line 84, in async_get_device_automation_platform
    raise InvalidDeviceAutomationConfig(
homeassistant.components.device_automation.exceptions.InvalidDeviceAutomationConfig: Integration '' not found
2021-02-25 16:59:02 ERROR (MainThread) [homeassistant.setup] Unable to set up dependencies of default_config. Setup failed for dependencies: automation
2021-02-25 16:59:02 ERROR (MainThread) [homeassistant.setup] Setup failed for default_config: Could not set up all dependencies.

Heeft iemand een idee wat er misgegaan is en nog beter hoe ik het weer kan oplossen?
Het enige wat ik eerder gedaan heb (waar ik mij bewust van ben ) is een schakelaar aan deconz toegevoegd en ik heb HA daarna nog gereset zonder dat er meldingen te voorschijn kwamen. dus dat lijkt niet gerelateerd.

[Robbie T]

TheFes schreef op donderdag 25 februari 2021 @ 17:09:
[...]


Door iets beter te lezen

[...]

YAML:

################################################
#Create a group for home or not
################################################  
thuis:
  name: Thuis
  entities:
    - device_tracker.telefoon_rob
    - device_tracker.telefoon_marleen

Man man.. Ik ga in een hoekje zitten en me schamen.. Alhoewel, eerst eten. Dat helpt wellicht...

Sorry en Dankje!

Begrijp ik het goed dat ik twee automations moet maken om een lamp aan en uit te schakelen? Ik wil dat mijn lamp in de hal uit gaat zodra er voor x periode geen beweging is. Het in schakelen heb ik inmiddels geregeld.

[ Voor 16% gewijzigd door Robbie T op 25-02-2021 18:31 ]

[Mich]

sjorsjuhmaniac schreef op dinsdag 23 februari 2021 @ 23:08:
[...]


Waarom werkt het via de yaml niet? Kan je alleen entities toevoegen?

Nee. Als ik het toevoeg in mijn code komt hij niet bij integraties erbij ofzo.

code:

- platform: mqtt
  state_topic: "dsmr/meter-stats/voltage_sag_count_l1"
  name: "dsmr_stats_voltage_sag_count_l1"
  unique_id: "dsmr_stats_voltage_sag_count_l1"
  device: {"identifiers": ["DSMR"], "name": "DSMR Reader", "model": "DSMR5", "manufacturer": "Docker"}
  unit_of_measurement: ' '
  value_template: "{{ value_json }}"

Als ik met deze code een auto discovery doe dan maakt hij er wel een device van (met de naam DSMR reader).

[water_escape]

Zou dit dan mijn script worden die ik aanroep in een automation?

YAML:

alias: All lights off
description: Turn everything off in the house
mode: single
fields:
  exclude_entity_ids:
    description: entity_ids to exclude
sequence:
  - service: homeassistant.turn_off
    data:
      entity_id:       
      - light.hue_voordeur_1
      - light.hue_voordeur_2
      - light.hue_garage_1
      - light.hue_garage_2

of omdat het alleen lights betreft kan ik ook dit in een automation doen ipv een script?

YAML:

alias: Turn off all lights
description: ''
trigger:
  - platform: time
    at: '00:01'
condition: []
action:
  - service: light.turn_off
    data:
      exclude_entity_ids:
        - light.hue_voordeur_1
        - light.hue_voordeur_2
        - light.hue_garage_1
        - light.hue_garage_2
mode: single

of de groep zelf?

YAML:

alias: Turn off all lights
description: ''
trigger:
  - platform: time
    at: '00:01'
condition: []
action:
  - service: light.turn_off
    data:
      exclude_entity_ids: 
        - light.voortuin
mode: single

[ Voor 65% gewijzigd door water_escape op 25-02-2021 19:32 ]

[Septillion]

@Mich @sjorsjuhmaniac Is het correcte gedrag volgens de documentatie:

device
Information about the device this sensor is a part of to tie it into the device registry. Only works through MQTT discovery and when unique_id is set.

[Mich]

Septillion schreef op donderdag 25 februari 2021 @ 19:30:
@Mich @sjorsjuhmaniac Is het correcte gedrag volgens de documentatie:


[...]

Klopt ja.

Dat is juist het probleem. Het werkt alleen met discovery. Ik zou graag mqtt sensoren aan een device willen toevoegen zonder discovery Zo kan ik al mijn mqtt sensoren beter ordenen.

[ione]

Voor het monitoren van de wasmachine zag ik de Blitzwolf BW-SHP13. Deze heeft volgens mij een hoger vermogen waardoor het veilig is om te gebruiken bij de wasmachine.
Ik wil voor de Zigbee variant gaan. Kan ik deze dan zonder verder iets te moeten flashen in Home Assistant gebruiken? Ik heb een Conbee2 stick.

Op de site van BlitzWolf staan er links naar Banggood en Amazon. Die naar Amazon lijkt niet te werken. Maar als je het op Banggood koopt is dat dan de echte versie of is het dan mogelijk niet veilig (koop normaal gesproken geen 230v zaken via oa Ali). Hier is het 14 eur.
Ik kwam ook op deze site:
https://www.blitzwolfeuro...-ZigBee-WIFI-Smart-Socket
Hier kost ie 28 eur.

Hier is ie echter duurder dan de link naar Banggood via de mobiele Blitzwolf site.
Dus is die op Banggood exact hetzelfde product of voor de zekerheid toch die duurdere doen?

[Septillion]

@water_escape In de eerste maak je alleen een field 'exclude_entity_ids' aan waar je niets mee doet. In de tweede geef je de service call 'exclude_entity_ids' mee wat geen parameter is van 'light.turn_off'.

Je vergeet dus de hele template van @golles erin te zetten... Kan als script zoals hij heeft of direct. Eerste maakt hergebruiken makkelijker natuurlijk.

[Septillion]

@Mich Volgens mij kan dat simpelweg niet. Of je moet ze niet in je YAML zetten maar het zelf via MQTT (met retain) pushen.

[water_escape]

Septillion schreef op donderdag 25 februari 2021 @ 19:36:
@water_escape In de eerste maak je alleen een field 'exclude_entity_ids' aan waar je niets mee doet. In de tweede geef je de service call 'exclude_entity_ids' mee wat geen parameter is van 'light.turn_off'.

Je vergeet dus de hele template van @golles erin te zetten... Kan als script zoals hij heeft of direct. Eerste maakt hergebruiken makkelijker natuurlijk.

Ik denk dus dat ik geen script nodig heb. Omdat ik niet alles van home assistant uit wil zetten. Maar alle lampen.

In een automation kan ik turn lights off triggeren.

edit: ow... maar dan moet ik idd natuurlijk eerst alle lampgroepen aanwijzen die daarop moeten reageren....damn

[ Voor 7% gewijzigd door water_escape op 25-02-2021 19:39 ]

[Septillion]

@ione Ja, werkt prima. Alleen weet ik even niet tot hoe vaak per tijd Deconz de updates beperkt. Bij Zigbee2mQTT is dat standaard eens elke minuut om de belasting op je Zigbee netwerk binnen de perken te houden.

En Blitzwolf is zo goed als een huismerk van Banggood dus daar krijg je gewoon een echte Blitzwolf.

[Septillion]

@water_escape Dat kan, maar moet je gewoon zelf alle entities meegeven die je uit wilt hebben. Dus of alle light entities of een enkele (light) group met alle lampen of meerdere (light) groups als die samen alle lampen vormen.

Indien niet alles in het light domein valt (maar bijvoorbeeld ook switches tussen zitten) kan je alleen gebruik maken van (generieke, non-light) groups en dus van 'homeassistant.turn_off'.

Maar je hebt dan absoluut niets nada noppes van doen met 'exclude_entity_ids'. Dat bestaat alleen in het script van @golles.

[water_escape]

Septillion schreef op donderdag 25 februari 2021 @ 19:44:
@water_escape Dat kan, maar moet je gewoon zelf alle entities meegeven die je uit wilt hebben. Dus of alle light entities of een enkele (light) group met alle lampen of meerdere (light) groups als die samen alle lampen vormen.

Indien niet alles in het light domein valt (maar bijvoorbeeld ook switches tussen zitten) kan je alleen gebruik maken van (generieke, non-light) groups en dus van 'homeassistant.turn_off'.

Maar je hebt dan absoluut niets nada noppes van doen met 'exclude_entity_ids'. Dat bestaat alleen in het script van @golles.

Ok dank, ik heb de even wat meer uitleg nodig van de code in het script.

Als ik het script toevoeg:

YAML:

alias: All lights off
description: Turn everything off in the house
mode: single
fields:
  exclude_entity_ids:
    description: entity_ids to exclude
sequence:
  - service: homeassistant.turn_off
    data:
      entity_id: |
        {{
          (
            expand(
              states.light
              | selectattr('state', 'eq', 'on')
              | rejectattr('attributes.is_hue_group')
            ) +
            expand(
              states.media_player
              | rejectattr('state', 'in', ['off', 'unavailable'])
            )
          )
            | rejectattr('entity_id', 'in', exclude_entity_ids)
            | map(attribute='entity_id')
            | join(', ')
        }}

en deze trigger via een automation:

YAML:

alias: Turn off all lights
description: ''
trigger:
  - platform: time
    at: '00:01'
condition: []
action:
  - service: script.all_lights_off
    data:
      exclude_entity_ids: light.voortuin
mode: single

probeer ik de automation de voortuin groep te excluden. Maar dit gaan nu ook mee uit. aka met deze instelling gaat alles uit.

begrijp ik nu dat die light.voortuin in het script moet komen te staan? Alleen begrijp ik niet hoe ivm die expands.
De tweede expand is dat de mediaspelers niet uitgaan door die trigger, dat is goed. De derde begrijp ik helaas ook niet.

[Septillion]

@water_escape Het is weer mooie hogere graad van magie Jinja maar dat zou precies de taak van de exclude_entity_ids moeten zijn. Twee dingen: is het inderdaad 'light.voortuin' (aka, het is een light group en niet 'group.voortuin')? En misschien moet de inhoud van de exclude tussen quotes (maar daar twijfel ik over...)

[golles]

water_escape schreef op donderdag 25 februari 2021 @ 19:51:
[...]


Ok dank, ik heb de even wat meer uitleg nodig van de code in het script.

Als ik het script toevoeg:

YAML:

alias: All lights off
description: Turn everything off in the house
mode: single
fields:
  exclude_entity_ids:
    description: entity_ids to exclude
sequence:
  - service: homeassistant.turn_off
    data:
      entity_id: |
        {{
          (
            expand(
              states.light
              | selectattr('state', 'eq', 'on')
              | rejectattr('attributes.is_hue_group')
            ) +
            expand(
              states.media_player
              | rejectattr('state', 'in', ['off', 'unavailable'])
            )
          )
            | rejectattr('entity_id', 'in', exclude_entity_ids)
            | map(attribute='entity_id')
            | join(', ')
        }}

en deze trigger via een automation:

YAML:

alias: Turn off all lights
description: ''
trigger:
  - platform: time
    at: '00:01'
condition: []
action:
  - service: script.all_lights_off
    data:
      exclude_entity_ids: light.voortuin
mode: single

probeer ik de automation de voortuin groep te excluden. Maar dit gaan nu ook mee uit. aka met deze instelling gaat alles uit.

begrijp ik nu dat die light.voortuin in het script moet komen te staan? Alleen begrijp ik niet hoe ivm die expands.
De tweede expand is dat de mediaspelers niet uitgaan door die trigger, dat is goed. De derde begrijp ik helaas ook niet.

Dit script exclude alle light entities die een attribute is_hue_group hebben, gewone groepen niet. In jouw geval werkt het niet omdat die selector zowel je lamp als je light groep met lamp(en) vind. Je zou dan beide moeten excluden.

Wat je het beste kan doen, is deze template in je template editor te zetten, dan zie je precies welke entiy id's getriggered gaan worden.

[Yukkie]

sOid schreef op donderdag 25 februari 2021 @ 16:45:
[...]

Godgloeiende, had ik dit een half uurtje geleden maar gelezen

Nou ja, ik wou toch eigenlijk opnieuw beginnen met influxdb. Eerste keer niet helemaal lekker geconfigureerd.

Ik zal proberen het de volgende keer eerder te posten

Hoe ga je het inrichten? obv influxdb 2.x? of nog 1.x? Ik heb naast Home-Assistant ook nog wat scripts en Node-Red wat naar Influx weg schrijft en Grafana wat leest. Ik kijk er wel tegenop om dat om te moeten zetten naar 2.0. Zeker de eigen gemaakte scriptjes. Het zal misschien niet heel lastig zijn, maar is wel ff een klusje ben ik bang.

[golles]

Yukkie schreef op donderdag 25 februari 2021 @ 20:03:
[...]


Ik zal proberen het de volgende keer eerder te posten

Hoe ga je het inrichten? obv influxdb 2.x? of nog 1.x? Ik heb naast Home-Assistant ook nog wat scripts en Node-Red wat naar Influx weg schrijft en Grafana wat leest. Ik kijk er wel tegenop om dat om te moeten zetten naar 2.0. Zeker de eigen gemaakte scriptjes. Het zal misschien niet heel lastig zijn, maar is wel ff een klusje ben ik bang.

https://docs.influxdata.com/influxdb/v2.0/upgrade/v1-to-v2/
Docker gebruikers worder geacht nog even te wachten

[sOid]

Yukkie schreef op donderdag 25 februari 2021 @ 20:03:
[...]


Ik zal proberen het de volgende keer eerder te posten

Hoe ga je het inrichten? obv influxdb 2.x? of nog 1.x? Ik heb naast Home-Assistant ook nog wat scripts en Node-Red wat naar Influx weg schrijft en Grafana wat leest. Ik kijk er wel tegenop om dat om te moeten zetten naar 2.0. Zeker de eigen gemaakte scriptjes. Het zal misschien niet heel lastig zijn, maar is wel ff een klusje ben ik bang.

Meteen maar 2.x, anders kan je simpelweg niet meer updaten. Mijn config is wat eenvoudiger want alleen HA schrijft ernaar en alleen Grafana leest er data uit.

Maar ja, leuk is anders. Heb betere dingen te doen

[water_escape]

Septillion schreef op donderdag 25 februari 2021 @ 19:58:
@water_escape Het is weer mooie hogere graad van magie Jinja maar dat zou precies de taak van de exclude_entity_ids moeten zijn. Twee dingen: is het inderdaad 'light.voortuin' (aka, het is een light group en niet 'group.voortuin')? En misschien moet de inhoud van de exclude tussen quotes (maar daar twijfel ik over...)

zo heb ik hem als "group" gemaakt.

#light_groups
light:
- platform: group
name: Voortuin
entities:
- light.hue_voordeur_1
- light.hue_voordeur_2
- light.hue_garage_1
- light.hue_garage_2

[water_escape]

golles schreef op donderdag 25 februari 2021 @ 20:01:
[...]


Dit script exclude alle light entities die een attribute is_hue_group hebben, gewone groepen niet. In jouw geval werkt het niet omdat die selector zowel je lamp als je light groep met lamp(en) vind. Je zou dan beide moeten excluden.

Wat je het beste kan doen, is deze template in je template editor te zetten, dan zie je precies welke entiy id's getriggered gaan worden.

ow die editor kende ik nog niet . Nice om te zien. maaaaar, dat maakt het nog vreemder voor mij. De lampen die NIET uit moeten staan er ook niet tussen, maar nog veel maar lampen staan er ook niet tussen. Maar wel alles gaat uit.

wel zie ik hieronder idd light.x (group) en light.lampnaam beide voorkomen.

Domein: light
Domein: media_player
Entiteit: light.entree_spot_1
Entiteit: light.entree_spot_2
Entiteit: light.garderobe
Entiteit: light.hal
Entiteit: light.hal_color_wall_1
Entiteit: light.hal_color_wall_2
Entiteit: light.hue_ambiance_overloop
Entiteit: light.hue_color_lamp_1_4
Entiteit: light.hue_kast_spot_1
Entiteit: light.hue_kast_spot_2
Entiteit: light.hue_muur_spot_1
Entiteit: light.hue_muur_spot_2
Entiteit: light.hue_plafond_overloop
Entiteit: light.kledingkast
Entiteit: light.kledingkast_1
Entiteit: light.kledingkast_2
Entiteit: light.master
Entiteit: light.overloop
Entiteit: light.overloop_wall_1
Entiteit: light.overloop_wall_2
Entiteit: light.plafonniere_1
Entiteit: light.plafonniere_2
Entiteit: light.plafonniere_3
Entiteit: light.plafonniere_4
Entiteit: light.plafonniere_5
Entiteit: light.plafonniere_6
Entiteit: light.slaapkamer
Entiteit: light.slaapkamer_muur_1
Entiteit: light.slaapkamer_muur_2
Entiteit: light.tv_kamer_1
Entiteit: light.tv_kamer_10
Entiteit: light.tv_kamer_2
Entiteit: light.tv_kamer_3
Entiteit: light.tv_kamer_4
Entiteit: light.tv_kamer_5
Entiteit: light.tv_kamer_6
Entiteit: light.tv_kamer_7
Entiteit: light.tv_kamer_8
Entiteit: light.tv_kamer_9
Entiteit: light.woonkamer_houtkast
Entiteit: light.woonkamer_l_1
Entiteit: light.woonkamer_l_2
Entiteit: light.woonkamer_l_3
Entiteit: light.woonkamer_pui_1
Entiteit: light.woonkamer_pui_2
Entiteit: light.woonkamer_pui_3
Entiteit: light.woonkamer_pui_4
Entiteit: light.woonkamer_r_1
Entiteit: light.woonkamer_r_2
Entiteit: light.woonkamer_r_3
Entiteit: light.zitkamer
Entiteit: light.zitkamer_2
Entiteit: media_player.sonos_black
Entiteit: media_player.tuin

[Septillion]

@water_escape Code tags Maar dat is een light group ja. Als het goed is moet deze dus ook via dev tools -> states dus te zien zijn als light.voortuin.

Net even een testje gedaan en werkt hier perfect. Ik wilde niet al het licht uit zetten dus had ik er even van gemaakt:

YAML:

alias: TEST All lights
sequence:
  - service: persistent_notification.create
    data:
      notification_id: test
      message: >-
        {{ ( expand( states.light | selectattr('state', 'eq', 'on') |
        rejectattr('attributes.is_hue_group') ) + expand( states.media_player |
        rejectattr('state', 'in', ['off', 'unavailable']) ) ) |
        rejectattr('entity_id', 'in', exclude_entity_ids) |
        map(attribute='entity_id') | join(',\n ') }}
mode: single
fields:
  exclude_entity_ids:
    description: entity_ids to exclude

Hiermee kan je gewoon lekker spelen en zie je in je (persistent) notificaties een list van items. Als ik dat script aanroep (dev tools => service) als 'script.test_all_lights' met Service data 'exclude_entity_ids: light.study_bulb_ww, light.study_desk' mis ik die netjes in de lijst. Quotes om de key mag maar hoeft niet.

[golles]

water_escape schreef op donderdag 25 februari 2021 @ 20:05:
[...]


zo heb ik hem als "group" gemaakt.

#light_groups
light:
- platform: group
name: Voortuin
entities:
- light.hue_voordeur_1
- light.hue_voordeur_2
- light.hue_garage_1
- light.hue_garage_2

Dus fetitelijk heb je 5 light entities, die zou je in mijn script alle 5 moeten excluden. Als je geen gebruik maakt van hue groepen, dan moet je even kijken of een standaard light groep een attribute hebt waar je mee kan filteren.

[Septillion]

golles schreef op donderdag 25 februari 2021 @ 20:01:
[...]


Dit script exclude alle light entities die een attribute is_hue_group hebben, gewone groepen niet. In jouw geval werkt het niet omdat die selector zowel je lamp als je light groep met lamp(en) vind. Je zou dan beide moeten excluden.

Even gemist maar ow, verrek!

Een light group heeft als attribute 'entity_id' met daarin de entity id's van de lampen. Ik probeer even snel te bedenken hoe je die ook zou kunnen uitbreiden maar is wel lastig.... Nog een extra level, light groups in een light group...

[ Voor 23% gewijzigd door Septillion op 25-02-2021 20:19 ]

[water_escape]

@Septillion @golles dan begrijp ik even niet wat nu mijn groups zijn. Of ja , waarom hij ze niet laat zien in de test. Deze staan allemaal in mijn config.

Als ik nu en rejectattr('attributes.is_hue_group') en rejectattr('attributes.is_light_group') erin zet, krijg ik wel wat meer lampen in de lijst, maar ik mis er nog steeds een heleboel.


edit: Ik zie je edit nu. Moet ik mijn lampen anders sorteren? ipv de light groups?

[ Voor 11% gewijzigd door water_escape op 25-02-2021 20:26 ]

[Septillion]

@water_escape Nee, het probleem zit hem niet in sorteren. Maar @golles heeft hem nooit voor een light group gebruikt, alleen voor losse enitities. Dus als je in de exclude alleen de light group zet wordt deze als nog uitgezet doordat alle entities zelf ook nog los bestaan en niet weggefilterd worden.

Als je doet:

YAML:

alias: Turn off all lights
description: ''
trigger:
  - platform: time
    at: '00:01'
condition: []
action:
  - service: script.all_lights_off
    data:
      exclude_entity_ids: light.voortuin, light.hue_voordeur_1, light.hue_voordeur_2, light.hue_garage_1, light.hue_garage_2
mode: single

Zouden alle lampen in de tuin aan moeten blijven.

Ik probeer met mijn Jinja skills nog te bedenken hoe je hier nu echt groepen zou kunnen gebruiken.

[water_escape]

Septillion schreef op donderdag 25 februari 2021 @ 20:38:
@water_escape Nee, het probleem zit hem niet in sorteren. Maar @golles heeft hem nooit voor een light group gebruikt, alleen voor losse enitities. Dus als je in de exclude alleen de light group zet wordt deze als nog uitgezet doordat alle entities zelf ook nog los bestaan en niet weggefilterd worden.

Als je doet:

YAML:

alias: Turn off all lights
description: ''
trigger:
  - platform: time
    at: '00:01'
condition: []
action:
  - service: script.all_lights_off
    data:
      exclude_entity_ids: light.voortuin, light.hue_voordeur_1, light.hue_voordeur_2, light.hue_garage_1, light.hue_garage_2
mode: single

Zouden alle lampen in de tuin aan moeten blijven.

Ik probeer met mijn Jinja skills nog te bedenken hoe je hier nu echt groepen zou kunnen gebruiken.

moet ik dan nog iets aanpassen in het script? Want nu gaat nog steeds alles uit...

[Septillion]

@water_escape Ook als je dus zowel de light group als alle losse entities in de exclude_entity_ids zet?

[water_escape]

Septillion schreef op donderdag 25 februari 2021 @ 20:52:
@water_escape Ook als je dus zowel de light group als alle losse entities in de exclude_entity_ids zet?

voor de zekerheid:

Automation:

YAML:

alias: Turn off all lights
description: ''
trigger:
  - platform: time
    at: '00:01'
condition: []
action:
  - service: script.all_lights_off
    data:
      exclude_entity_ids: >-
        light.voortuin, light.hue_voordeur_1, light.hue_voordeur_2,
        light.hue_garage_1, light.hue_garage_2
mode: single

de >- zet hij er zelf in na opslaan...

Script:

YAML:

alias: All lights off
description: Turn everything off in the house
mode: single
fields:
  exclude_entity_ids:
    description: entity_ids to exclude
sequence:
  - service: homeassistant.turn_off
    data:
      entity_id: |
        {{
          (
            expand(
              states.light
              | selectattr('state', 'eq', 'on')
              | rejectattr('attributes.is_hue_group')
            ) +
            expand(
              states.light
              | selectattr('state', 'eq', 'on')
              | rejectattr('attributes.is_light_group')
            ) +
            expand(
              states.media_player
              | rejectattr('state', 'in', ['off', 'unavailable'])
            )
          )
            | rejectattr('entity_id', 'in', exclude_entity_ids)
            | map(attribute='entity_id')
            | join(', ')
        }}

[Septillion]

@water_escape Zitten deze lampen toevallig ook nog in een andere light group?

[golles]

water_escape schreef op donderdag 25 februari 2021 @ 20:55:
[...]


voor de zekerheid:

Automation:

YAML:

alias: Turn off all lights
description: ''
trigger:
  - platform: time
    at: '00:01'
condition: []
action:
  - service: script.all_lights_off
    data:
      exclude_entity_ids: >-
        light.voortuin, light.hue_voordeur_1, light.hue_voordeur_2,
        light.hue_garage_1, light.hue_garage_2
mode: single

de >- zet hij er zelf in na opslaan...

Script:

YAML:

alias: All lights off
description: Turn everything off in the house
mode: single
fields:
  exclude_entity_ids:
    description: entity_ids to exclude
sequence:
  - service: homeassistant.turn_off
    data:
      entity_id: |
        {{
          (
            expand(
              states.light
              | selectattr('state', 'eq', 'on')
              | rejectattr('attributes.is_hue_group')
            ) +
            expand(
              states.light
              | selectattr('state', 'eq', 'on')
              | rejectattr('attributes.is_light_group')
            ) +
            expand(
              states.media_player
              | rejectattr('state', 'in', ['off', 'unavailable'])
            )
          )
            | rejectattr('entity_id', 'in', exclude_entity_ids)
            | map(attribute='entity_id')
            | join(', ')
        }}

Zo moet je dat niet doen, dan zou het zo zijn:

YAML:

        {{
          (
            expand(
              states.light
              | selectattr('state', 'eq', 'on')
              | rejectattr('attributes.is_hue_group')
              | rejectattr('attributes.is_light_group')
            ) +
            expand(
              states.media_player
              | rejectattr('state', 'in', ['off', 'unavailable'])
            )
          )
            | rejectattr('entity_id', 'in', exclude_entity_ids)
            | map(attribute='entity_id')
            | join(', ')
        }}

Ik ga er van uit dat is_light_group wel een geldige attribute is, ik gebruik ze zelf niet, dus kan het niet controleren.

Edit: Oh, ik zie dat ik wel 1 light group heb, deze heeft helaas geen attributen die hem identificeren als een group

[water_escape]

Septillion schreef op donderdag 25 februari 2021 @ 21:13:
@water_escape Zitten deze lampen toevallig ook nog in een andere light group?

deze 4 niet. Andere wel.

[water_escape]

Klein stukje van de lijst, maar zo staan ze in de config:

YAML:

#light_groups
light:
  - platform: group
    name: Zolder
    entities:
      - light.lightstrip_zolder_R
      - light.lightstrip_zolder_l
      - light.hue_lightstrip_plus_1_2
  - platform: group
    name: Hal
    entities:
      - light.entree_spot_1
      - light.entree_spot_2
      - light.garderobe
      - light.hal_color_wall_1
      - light.hal_color_wall_2
      - light.overloop_wall_1
      - light.overloop_wall_2

golles schreef op donderdag 25 februari 2021 @ 21:16:
[...]

Zo moet je dat niet doen, dan zou het zo zijn:

YAML:

        {{
          (
            expand(
              states.light
              | selectattr('state', 'eq', 'on')
              | rejectattr('attributes.is_hue_group')
              | rejectattr('attributes.is_light_group')
            ) +
            expand(
              states.media_player
              | rejectattr('state', 'in', ['off', 'unavailable'])
            )
          )
            | rejectattr('entity_id', 'in', exclude_entity_ids)
            | map(attribute='entity_id')
            | join(', ')
        }}

Ik ga er van uit dat is_light_group wel een geldige attribute is, ik gebruik ze zelf niet, dus kan het niet controleren.

Edit: Oh, ik zie dat ik wel 1 light group heb, deze heeft helaas geen attributen die hem identificeren als een group

[water_escape]

ow verrek...dat was het

als ik het zo doe

YAML:

        {{
          (
            expand(
              states.light
              | selectattr('state', 'eq', 'on')
              | rejectattr('attributes.is_hue_group')
              | rejectattr('attributes.is_light_group')
            ) +
            expand(
              states.media_player
              | rejectattr('state', 'in', ['off', 'unavailable'])
            )
          )
            | rejectattr('entity_id', 'in', exclude_entity_ids)
            | map(attribute='entity_id')
            | join(', ')
        }}

dan blijven die lampen wel aan

[Septillion]

@water_escape Als je alleen nog maar losse enities wilt kunnen doen:

YAML:

{{
  (
    expand(
      states.light
      | selectattr('state', 'eq', 'on')
      | rejectattr('attributes.is_hue_group')
      | rejectattr('attributes.entity_id')
    ) +
    expand(
      states.media_player
      | rejectattr('state', 'in', ['off', 'unavailable'])
    )
  )
    | rejectattr('entity_id', 'in', exclude_entity_ids)
    | map(attribute='entity_id')
    | join(', ')
}}

Dan zouden groepen dus niet meer uit gezet moeten worden maar wel alle losse entities. In de exclude kan je dus ook nog alleen echte lights gebruiken en geen light groups.

[golles]

Septillion schreef op donderdag 25 februari 2021 @ 21:25:
@water_escape Als je alleen nog maar losse enities wilt kunnen doen:

code:

{{
  (
    expand(
      states.light
      | selectattr('state', 'eq', 'on')
      | rejectattr('attributes.is_hue_group')
      | rejectattr('attributes.entity_id')
    ) +
    expand(
      states.media_player
      | rejectattr('state', 'in', ['off', 'unavailable'])
    )
  )
    | rejectattr('entity_id', 'in', exclude_entity_ids)
    | map(attribute='entity_id')
    | join(', ')
}}

Dan zouden groepen dus niet meer uit gezet moeten worden maar wel alle losse entities. In de exclude kan je dus ook nog alleen echte lights gebruiken en geen light groups.

Aja, goeie want een light group heeft natuurlijk 1 of meerdere entity_id.
@water_escape deze oplossing is beter, ondanks dat het nu wel werkt.

Edit: Werkt top, ik ga hem er bij mij ook bijzetten, wel met een comment, anders ga ik vergeten waarom het erbij staat

[ Voor 6% gewijzigd door golles op 25-02-2021 21:33 ]

[Kraatsie]

@ione Vandaag 2 binnen gekregen, besteld via bangood. 2 Stuks voor €22. Snel geleverd en ze werkten meteen via ZHA icvm Sonoff zigbee bridge

[ Voor 9% gewijzigd door Kraatsie op 25-02-2021 21:37 . Reden: aanvulling ]