Home Assistant: Open source Python3 home automation - deel 5

[Marsman83]

D4NG3R schreef op donderdag 29 augustus 2024 @ 10:28:
Even een andere vraag; Ik overweeg om m'n verlichting wat verder te automatiseren a.d.h.v. de lichtsterkte buiten, maar ik wil graag voorkomen dat m'n automation daarvoor gaat klooien met een lamp indien deze handmatig hoger/lager/uit/aan is gezet.

Hoe lossen jullie dit op? Momenteel overweeg ik om een boolean sensor bij te gaan houden per device, maar ik ben er bang voor dat dat nogal snel de spuigaten uit gaat lopen.

Ik heb dit opgelost met een input boolean genaamd "Daglicht".
Een automation zet die op aan indien de gemeten lichtsterkte hoger is dan x en uit zodra lager dan x.
In mijn automation voor verlichting neem ik die als condition mee dat licht alleen aan gaat als daglicht uit is.

Overigens meet ik de lichtsterkte binnen en niet buiten, mochten we de gordijnen/rolluiken nog dicht hebben is het soms wel handig dat het licht wel aan gaat (ook al is het licht buiten).
Ook heb ik een condition ingesteld dat hij alleen triggert als er geen lampen aan staan, zo verzet hij nooit de verlichting als deze handmatig aangepast is (bijvoorbeeld gedimd bij film kijken en er komt iemand de kamer binnen).

Mocht je accurate lichtsterkte willen meten kan ik de Aquara FP2 sterk aanbevelen, deze meet vrijwel direct veranderingen in lichtsterkte. Primair heb ik deze voor de aanwezigheid te detecteren.

[D4NG3R]

@Dutchess_Nicole het gaat hier ook niet om verbruik, ik schakel momenteel al handmatig tussen een drietal scenes wanneer het buiten donker of juist lichter word. De verlichting staat uiteraard gewoon uit wanneer er niemand in een ruimte is.

@Septillion
Ik denk dat ik het plan om echt per individuele lamp uitzonderingen te maken in de automation(s) maar laat varen en ook zoiets doe.

Een extra modi toevoegen waar het systeem automatisch naar toe schakelt (en op blijft staan) wanneer er met een van de lampen is gespeeld is in ieder geval geen achteruitgang.

@Marsman83 Ik heb zelf een aantal Aqara T1 lichtsensoren liggen, zowel op plekken waar natuurlicht ongehinderd op valt en er weinig tot geen kunstlicht bij kan, als op plekken waar dit niet het geval is. De verlichting in een ruimte zal uiteraard geschakeld worden op sensoren in diezelfde ruimte. Alleen de buitenverlichting en de verlichting in de hal schakelt (reeds) op hoe licht het buiten is.

[ Voor 16% gewijzigd door D4NG3R op 29-08-2024 12:32 ]

[HuismAndré]

Septillion schreef op donderdag 29 augustus 2024 @ 11:26:
@HuismAndré Maar waar haal je fan.percentage vandaan?

Was een foutje (zojuist aangepast). Automatisering werkte wel maar de waarde (33/67/100) werd niet getoond in de fan (dus monitoren was niet mogelijk). Zag ik later pas omdat ik in het dashboard de stand bereken op basis van het verbruik van de WTW.

Een ander (klein) nadeel is dat de template reset bij een reboot (en ik reboot elke nacht om 4:00). Ik heb dat nu afgedekt door de WTW automatisering na het opstarten uit te laten voeren (maar moet nog op zoek naar een mogelijkheid om het percentage persistent na een reboot te krijgen).

[ Voor 34% gewijzigd door HuismAndré op 29-08-2024 12:32 ]

[Toppe]

Is er hier iemand die zelf zijn gong slim heeft gemaakt? Ik wil deze namelijk tussen bepaalde tijden uit kunnen zetten zonder dat de slimme deurbel uit gaat.

[Marsman83]

Toppe schreef op donderdag 29 augustus 2024 @ 12:35:
Is er hier iemand die zelf zijn gong slim heeft gemaakt? Ik wil deze namelijk tussen bepaalde tijden uit kunnen zetten zonder dat de slimme deurbel uit gaat.

Licht eraan welke deurbel/gong je gebruikt.
Ik heb de Eufy deurbel en base.

De base melding zelf heb ik altijd uit staan. Ik speel een bericht af op mijn google home devices in alle vertrekken als de bel overdag gaat.
In de avond speel ik deze enkel af in de woonkamer zodat de kinderen niet wakker worden.
Overigens kan de Eufy integratie de base melding eventueel ook aan/uitzetten dus dat zou je ook aan een time trigger kunnen hangen.

[Septillion]

@HuismAndré Daar zou je nog een input_number voor kunnen pakken of je zou percentage terug kunnen rekenen aan de hand van de switches.

Iets als

YAML:

fan:
  - platform: template
    fans:
      wtw:
        unique_id: wtw
        friendly_name: "Test WTW"
        value_template: "{{ states('switch.wtw') }}"
        turn_on:
          - action: switch.turn_on
            target:
              entity_id: switch.wtw
        turn_off:
          - action: switch.turn_off
            target:
              entity_id: switch.wtw
        speed_count: 3
        percentage_template: >-
          {% if states('switch.wtw') == 'off' %}
            0
          {% elif states('switch.wtw_stand3') == 'on' %}
            100
          {% elif states('switch.wtw_stand2') == 'on' %}
            66
          {% else %}
            33
          {% endif %}
        set_percentage:
          - action: switch.turn_{{ 'on' if percentage > 0 else 'off' }}
            target:
              entity_id: switch.wtw
          - action: switch.turn_{{ 'on' if percentage > 40 and percentage < 75 else 'off' }}
            target:
              entity_id: switch.wtw_stand2
          - action: switch.turn_{{ 'on' if percentage > 75 else 'off' }}
            target:
              entity_id: switch.wtw_stand3

[Toppe]

Marsman83 schreef op donderdag 29 augustus 2024 @ 12:56:
[...]


Licht eraan welke deurbel/gong je gebruikt.
Ik heb de Eufy deurbel en base.

De base melding zelf heb ik altijd uit staan. Ik speel een bericht af op mijn google home devices in alle vertrekken als de bel overdag gaat.
In de avond speel ik deze enkel af in de woonkamer zodat de kinderen niet wakker worden.
Overigens kan de Eufy integratie de base melding eventueel ook aan/uitzetten dus dat zou je ook aan een time trigger kunnen hangen.

Heb een Netatmo en die ondersteund geen enkele vorm van uitschakelen

[ Voor 4% gewijzigd door Toppe op 29-08-2024 13:03 ]

[lolgast]

Toppe schreef op donderdag 29 augustus 2024 @ 13:02:
[...]


Heb een Netatmo en die ondersteund geen enkele vorm van uitschakelen

Trafo via een tussenstekker aansluiten waarbij je de tussenstekker op vaste tijdstippen uitzet?

Ik heb een domme deurbel en simpelweg de draden van de deurbel aan een ESP gehangen. Deurbelknop ingedrukt -> relais wordt gesloten waardoor de deurbel aangaat + een bericht op de telefoons, mits diegene thuis is.
Liggen de kinderen op bed gaat het relais niet dicht maar krijgen we wel een bericht op de telefoon ("critical", dus maakt ook geluid als telefoon op stil staat)

[HuismAndré]

Septillion schreef op donderdag 29 augustus 2024 @ 12:57:
@HuismAndré Daar zou je nog een input_number voor kunnen pakken of je zou percentage terug kunnen rekenen aan de hand van de switches.
..

Gelukt. Bedankt. Ik heb het tevens in de eerdere bijdrage verwerkt.

[ Voor 8% gewijzigd door HuismAndré op 29-08-2024 13:19 ]

[skank]

Marsman83 schreef op donderdag 29 augustus 2024 @ 12:56:
[...]


Licht eraan welke deurbel/gong je gebruikt.
Ik heb de Eufy deurbel en base.

De base melding zelf heb ik altijd uit staan. Ik speel een bericht af op mijn google home devices in alle vertrekken als de bel overdag gaat.
In de avond speel ik deze enkel af in de woonkamer zodat de kinderen niet wakker worden.
Overigens kan de Eufy integratie de base melding eventueel ook aan/uitzetten dus dat zou je ook aan een time trigger kunnen hangen.

Loopt die goed bij jou?
Trigger je ook de beelden?

[Septillion]

@Toppe Als ik het zo goed zie mag de Netatmo ook gewoon direct aan een voeding hangen. Dus als je de gong uit wilt schakelen zou dat moeten kunnen door simpelweg de gong te overbruggen met een relais (bijvoorbeeld met een Shelly 1).

[Septillion]

@HuismAndré Alleen je laatste action nog even weghalen

[HuismAndré]

Septillion schreef op donderdag 29 augustus 2024 @ 13:24:
@HuismAndré Alleen je laatste action nog even weghalen

Kan het zijn dat je naar de verkeerde keek. De laatste bijdrage is deze: HuismAndré in "Home Assistant: Open source Python3 home automation - deel 5"

[Septillion]

@HuismAndré Kijk naar de goede, je fan.set_percentage mag er nog uit

[HuismAndré]

Septillion schreef op donderdag 29 augustus 2024 @ 13:31:
@HuismAndré Kijk naar de goede, je fan.set_percentage mag er nog uit

Daar twijfelde ik al aan (vanwege de template) maar elke keer als ik dat voorheen deed werd het percentage niet meer getoond in de fan. Net getest en inderdaad, hij kan eruit. ;-)

[Toppe]

Septillion schreef op donderdag 29 augustus 2024 @ 13:21:
@Toppe Als ik het zo goed zie mag de Netatmo ook gewoon direct aan een voeding hangen. Dus als je de gong uit wilt schakelen zou dat moeten kunnen door simpelweg de gong te overbruggen met een relais (bijvoorbeeld met een Shelly 1).

Hm, dat is dan nog een optie inderdaad. Niet aan gedacht

[HuismAndré]

Toppe schreef op donderdag 29 augustus 2024 @ 13:45:
[...]


Hm, dat is dan nog een optie inderdaad. Niet aan gedacht

Overigens is het wel aan te raden de deurbel actief te laten als dit de enige mogelijkheid zou zijn waarmee buitenstaanders je in het geval van brand zouden kunnen wekken.

[Septillion]

Cyrus The Virus schreef op donderdag 29 augustus 2024 @ 11:18:
[...]


Ja dat is hele gekke keuze, dus wat ik nu wil doen is beide waardes optellen zodat er netto waarde uitkomt die stijgt of daalt. En die weer opsplitsen in een import en export waarde voor het Energy dashboard. Dus als de netto waarde stijgt dan moet import met zelfde hoeveelheid stijgen. En als de netto waarde daalt moet export met zelfde hoeveelheid stijgen ( stijgen omdat het export waarde is en energy dashboard verwacht alleen positieve waardes).

Berekening stond in stukje voorbeeld maar ik heb dus geen flauw idee hoe ik dat in een sensor template zet.

Denk dat het met de volgende template sensor wel kan:

YAML:

template:
  - trigger:
      - platform: state
        entity_id:
          - sensor.hw_netto
        to: null
    sensor:
      - name: "Grid import"
        state: >-
          {% set d = trigger.to_state.state|float(0) - trigger.from_state.state|float(0) %}
          {% if trigger.to_state.state|is_number 
            and trigger.from_state.state|is_number
            and this.state|is_number 
            and d > 0
          %}
            {{ this.state|float + d }}
          {% else %}
            {{ this.state }}
          {% endif %}
        unit_of_measurement: "kWh"
        device_class: energy
        state_class: total_increasing
      - name: "Grid export"
        state: >-
          {% set d = trigger.to_state.state|float(0) - trigger.from_state.state|float(0) %}
          {% if trigger.to_state.state|is_number 
            and trigger.from_state.state|is_number
            and this.state|is_number 
            and d < 0
          %}
            {{ this.state|float - d }}
          {% else %}
            {{ this.state }}
          {% endif %}
        unit_of_measurement: "kWh"
        device_class: energy
        state_class: total_increasing

Gaat er dus wel vanuit dat je al een template sensor hebt die gewoon al import - export is (= sensor.hw_netto). En denk dat je na het aanmaken beide sensoren nog even handmatig op 0 moet zetten via Dev tools => States => Set state.

[Septillion]

@HuismAndré Er blijft altijd nog gewoon bonken over. Lijkt me überhaupt effectiever. Bij een deurbel zou ik nog een keer hebben "stik erin" of in ieder geval kleding aanschieten. Maar als iemand op me deur zou bonken sta ik beneden voor hij daarmee klaar is

[-Casper]

D4NG3R schreef op donderdag 29 augustus 2024 @ 10:28:
Even een andere vraag; Ik overweeg om m'n verlichting wat verder te automatiseren a.d.h.v. de lichtsterkte buiten, maar ik wil graag voorkomen dat m'n automation daarvoor gaat klooien met een lamp indien deze handmatig hoger/lager/uit/aan is gezet.

Hoe lossen jullie dit op? Momenteel overweeg ik om een boolean sensor bij te gaan houden per device, maar ik ben er bang voor dat dat nogal snel de spuigaten uit gaat lopen.

Ieder zijn eigen mening hierover maar ik heb het zoals hieronder gedaan. Alleen wanneer het licht heel erg wisselt door bewolking oid kan dit problemen geven maar vooralsnog niet echt problemen mee gehad.

YAML:

alias: "Verlichting woonkamer "
description: ""
trigger:
  - alias: Inschakelen
    platform: numeric_state
    entity_id:
      - sensor.licht_sensor_illuminance_lux
    for:
      hours: 0
      minutes: 10
      seconds: 0
    below: input_number.lux_lampen_schakelen
    id: Aan
    enabled: true
  - platform: numeric_state
    entity_id:
      - sensor.licht_sensor_illuminance_lux
    for:
      hours: 0
      minutes: 10
      seconds: 0
    above: input_number.lux_lampen_schakelen
    alias: Uitschakelen
    id: Uit
  - platform: time
    at: "23:00:00"
    id: afwezig
    alias: Niemand thuis - automatisch uitschakelen
condition: []
action:
  - alias: Schakel verlichting
    choose:
      - conditions:
          - condition: trigger
            id:
              - Aan
        sequence:
          - metadata: {}
            data: {}
            target:
              entity_id: light.stalamp_zwart
            alias: Woonkamer aan
            action: light.turn_on
      - conditions:
          - condition: trigger
            id:
              - Uit
        sequence:
          - metadata: {}
            data: {}
            target:
              entity_id: light.stalamp_zwart
            alias: Woonkamer uit
            action: light.turn_off
      - conditions:
          - condition: trigger
            id:
              - afwezig
          - condition: state
            entity_id: group.thuis
            state: not_home
          - condition: state
            entity_id: input_boolean.gast_modus
            state: "off"
        sequence:
          - metadata: {}
            data: {}
            target:
              entity_id: light.woonkamer
            action: light.turn_off
        alias: Niemand thuis
mode: single

[mr.DJ95]

Nu begin ik best wel content te raken met mijn mobiele dashboard. Wat ik alleen afschuwelijk vind is dat witte vlak aan de bovenkant. De meeste Google hits komen uit op header background maar dat is het niet.

Iemand een tip?

[marnie]

Toppe schreef op donderdag 29 augustus 2024 @ 12:35:
Is er hier iemand die zelf zijn gong slim heeft gemaakt? Ik wil deze namelijk tussen bepaalde tijden uit kunnen zetten zonder dat de slimme deurbel uit gaat.

Ik gebruik al twee jaar de smart doorbell van Marcel Zuidewijk: https://www.zuidwijk.com/product/smart-doorbell/
Heel handig, als er iemand thuis is en er wordt aangebeld gaat het buitenlicht aan en verschijnt er een melding op mijn telefoon.

[alex3305]

@Septillion Ik heb de automation die ik afgelopen week deelde eens herzien. Ben benieuwd of je de steiger nu wat rechter ziet staan

YAML:

- id: climate_thermostat_office_set_temperature
  alias: Klimaat - Thermostaat kantoor stel temperatuur in
  mode: restart
  variables:
    climate_entity: climate.office
    mode_entity: input_select.thermostat_mode_office
    setpoint: >-
      {% if   is_state(mode_entity, 'Comfort') %}
        20.0
      {% elif is_state(mode_entity, 'Eco') %}
        19.0
      {% elif is_state(mode_entity, 'Thuis') %}
        17.5
      {% elif is_state(mode_entity, 'Nacht') %}
        17.0
      {% elif is_state(mode_entity, 'Afwezig') %}
        14.0
      {% else %}
        4.0
      {% endif %}
  trigger:
    - platform: state
      entity_id: input_select.thermostat_mode_office
    - platform: state
      entity_id: input_select.house_state
      for:
        minutes: 5
    - platform: homeassistant
      event: start
  action:
    repeat:
      sequence:
        - action: climate.set_temperature
          target:
            entity_id: "{{ climate_entity }}"
          data:
            temperature: "{{ setpoint | float(0) }}"
        - wait_template: "{{ is_state_attr(climate_entity, 'temperature', setpoint) }}"
          timeout:
            minutes: 5
      while: "{{ not is_state_attr(climate_entity, 'temperature', setpoint) }}"

[Toppe]

marnie schreef op donderdag 29 augustus 2024 @ 14:21:
[...]

Ik gebruik al twee jaar de smart doorbell van Marcel Zuidewijk: https://www.zuidwijk.com/product/smart-doorbell/
Heel handig, als er iemand thuis is en er wordt aangebeld gaat het buitenlicht aan en verschijnt er een melding op mijn telefoon.

Ik heb een slimme deurbel, ik wil alleen de ging tijdelijk kunnen uitzetten als de kleine slaapt

[Septillion]

@alex3305 Toch nog drie scheve schroefjes

De tweede trigger lijkt mij niet direct zin te hebben. Enige is dat je dan expliciet wilt dat een eventuele handmatige override weer ongedaan gemaakt wordt.

Zou zelf het iets sneller nogmaals proberen, eerder 30 seconden ofzo.

En ik zou nog max aantal retries inbakken. In de while zou je toe kunnen voegen and repeat.index < 10. Eventueel met een notificatie als het dan nog steeds niet gelukt is ofzo.

[Septillion]

@mr.DJ95 Misschien theme op dark zetten?

[Cyrus The Virus]

Septillion schreef op donderdag 29 augustus 2024 @ 13:56:
[...]

Denk dat het met de volgende template sensor wel kan:

YAML:

template:
  - trigger:
      - platform: state
        entity_id:
          - sensor.hw_netto
        to: null
    sensor:
      - name: "Grid import"
        state: >-
          {% set d = trigger.to_state.state|float(0) - trigger.from_state.state|float(0) %}
          {% if trigger.to_state.state|is_number 
            and trigger.to_state.state|is_number
            and this.state|is_number 
            and d > 0
          %}
            this.state|float + d
          {% else %}
            this.state
          {% endif %}
        unit_of_measurement: "kWh"
        device_class: energy
        state_class: total_increasing
      - name: "Grid export"
        state: >-
          {% set d = trigger.to_state.state|float(0) - trigger.from_state.state|float(0) %}
          {% if trigger.to_state.state|is_number 
            and trigger.to_state.state|is_number
            and this.state|is_number 
            and d < 0
          %}
            this.state|float - d
          {% else %}
            this.state
          {% endif %}
        unit_of_measurement: "kWh"
        device_class: energy
        state_class: total_increasing

Gaat er dus wel vanuit dat je al een template sensor hebt die gewoon al import - export is (= sensor.hw_netto). En denk dat je na het aanmaken beide sensoren nog even handmatig op 0 moet zetten via Dev tools => States => Set state.

Geweldig de sensor hw_netto had ik inderdaad al. Ik zie nu de 2 sensors in states en heb die op 0 gezet maar ze veranderen niet terwijl hw_netto wel veranderd. Als ik de code ook in template plak (develop tools) geeft hij aan 'trigger' is undefined.

[Rouwette]

Toppe schreef op donderdag 29 augustus 2024 @ 14:24:
[...]


Ik heb een slimme deurbel, ik wil alleen de ging tijdelijk kunnen uitzetten als de kleine slaapt

Ik heb de gong ergens aan een plug hangen, gongt niet hard en wordt boven niet gehoord door de kids.

Verspreid door het huis en kantoor liggen Google Nest speakers (zonder Google) en daar wordt op bepaalde tijden wel of niet een bandje afgespeeld als er iemand op de bel druk.
Een dame zegt dan. "Er staat iemand aan de deur"

Wil nog proberen om het beeld op de Nest hub te krijgen maar heb daar nog niet veel tijd aan besteed eigenlijk

[D4NG3R]

-Casper schreef op donderdag 29 augustus 2024 @ 13:59:
[...]

Ieder zijn eigen mening hierover maar ik heb het zoals hieronder gedaan. Alleen wanneer het licht heel erg wisselt door bewolking oid kan dit problemen geven maar vooralsnog niet echt problemen mee gehad.

https://www.home-assistant.io/integrations/threshold/

Hysterese haalt een hele hoop ellende uit dit soort situaties, maar uitzonderingen als een flinke onweersbui midden op een verder zonnige dag houd je natuurlijk altijd.

[JME]

Ik stuur vanuit HA een Tapo smart plug aan (Tapo Controller custom integration) om een ventilator te bedienen. Afhankelijk van bepaalde omstandigheden staat de fan dan een poosje aan (duur verschilt) en daarna stuurt HA weer een uit-commando. Dat basisprincipe heb ik werkend.
Nu viel mij van de week op dat de fan wel erg lang aan stond. In de history zie ik terug dat op het moment van het uit-commando de smart plug tijdelijk unavailable was (wifidekking, glitch, whatever). Kan gebeuren, maar hoe werk ik daar omheen? Is er een manier om een automation iedere zoveel seconden een commando te laten herhalen, net zolang totdat er bevestiging vanuit de smart plug is dat deze op de gewenste stand staat?

[alex3305]

Septillion schreef op donderdag 29 augustus 2024 @ 14:32:
De tweede trigger lijkt mij niet direct zin te hebben. Enige is dat je dan expliciet wilt dat een eventuele handmatige override weer ongedaan gemaakt wordt.

Ik snap wat je bedoelt, maar dat is het niet. Die thermostaatknoppen willen zelf *rollende ogen* heel af en toe naar een setpoint gaan die niet ingesteld is. Ik kan blijkbaar geen langdurige statistieken inzien van climate.* devices of mijn input_select.thermostat_mode_* maar een paar weken geleden stond deze op 21 graden ingesteld. Alleen weet ik 1000% zeker dat ik de temperatuur niet aan had gepast. Sterker nog, dit stond ook nergens in het logboek. 21 graden is ook een default temperatuur na een reset. Dus ik denk dat die knop ergens een keer gereboot is.

Daarnaast staan mijn thermostaatmodus in de zomer (zoals nu) op 'Uit'. Al maanden. Er worden dus geen aanpassingen gemaakt aan die entiteiten. Dus ik wil dan wel graag ergens een reguliere trigger hebben. Misschien kan wel die for... weg.

Zou zelf het iets sneller nogmaals proberen, eerder 30 seconden ofzo.

Ik snap het. Misschien is 1 minuut nog interessant. Maar eigenlijk heeft dat geen zin. Deze Z-Wave thermostaatknoppen hebben een Wake up interval van 5 minuten. Dus als de trein gemist is, heeft het geen zin om het perron vol te zetten met nog meer berichten. Ik had dat ooit nog dynamisch gemaakt, maar dat kostte voornamelijk batterij.

En ik zou nog max aantal retries inbakken. In de while zou je toe kunnen voegen and repeat.index < 10. Eventueel met een notificatie als het dan nog steeds niet gelukt is ofzo.

Dat is nog wel een goede... Daar zat ik zelf ook nog aan te denken. Maar zoiets denk ik dan:

YAML:

  action:
    repeat:
      while: "{{ not is_state_attr(climate_entity, 'temperature', setpoint) and repeat.index <= 6 }}"
      sequence:
        - action: climate.set_temperature
          target:
            entity_id: "{{ climate_entity }}"
          data:
            temperature: "{{ setpoint | float(0) }}"
        - wait_template: "{{ is_state_attr(climate_entity, 'temperature', setpoint) }}"
          timeout:
            minutes: 5
        - if:
            - "{{ not wait.completed and repeat.index > 5 }}"
          then:
            action: notify.phones
            data:
              title: "Probleem met {{ state_attr(climate_entity, 'friendly_name') }}"
              message: "Temperatuur {{ setpoint }} kon niet ingesteld worden."
              data:
                ttl: 0
                priority: high

Hierbij probeert de automatisering het dus 6 keer (6x5 = 30 minuten). Dat lijkt mij ruim voldoende. Misschien nog een expliciete logmelding toevoegen na de 2e poging voor debuggen.

Kleine edit; Dan moet ik er natuurlijk wel mode: single van maken zodat ik ervoor zorg dat de lus uitvoering beperkt blijft.

[HuismAndré]

Septillion schreef op donderdag 29 augustus 2024 @ 13:59:
@HuismAndré Er blijft altijd nog gewoon bonken over. Lijkt me überhaupt effectiever. Bij een deurbel zou ik nog een keer hebben "stik erin" of in ieder geval kleding aanschieten. Maar als iemand op me deur zou bonken sta ik beneden voor hij daarmee klaar is

Zoals ik al zei "als het vanaf buiten op een andere manier niet kan". Bijvoorbeeld bij een portiekwoning waarbij je op de bovenste verdieping woont.

Maar in dit geval blijkt het te gaan om een situatie waarbij de kleine slaapt (en we dus aan kunnen nemen dat de ouder(s) niet slapen).

[ Voor 11% gewijzigd door HuismAndré op 29-08-2024 15:08 ]

[marnie]

HuismAndré schreef op donderdag 29 augustus 2024 @ 15:06:
[...]

Zoals ik al zei "als het vanaf buiten op een andere manier niet kan". Bijvoorbeeld bij een portiekwoning waarbij je op de bovenste verdieping woont.

Maar in dit geval blijkt het te gaan om een situatie waarbij de kleine slaapt (en we dus aan kunnen nemen dat de ouder(s) niet slapen).

Volgens mij is dit met een simpele zwave (of welk netwerk ook) switch en wat HA yaml code zo te realiseren.
Baby slaapt: contact (spanning) naar gong onderbreken en melding naar telefoon.
Baby slaap niet: alleen melding naar telefoon.

[TheFes]

Septillion schreef op donderdag 29 augustus 2024 @ 13:56:
[...]

Denk dat het met de volgende template sensor wel kan:

YAML:

template:
  - trigger:
      - platform: state
        entity_id:
          - sensor.hw_netto
        to: null
    sensor:
      - name: "Grid import"
        state: >-
          {% set d = trigger.to_state.state|float(0) - trigger.from_state.state|float(0) %}
          {% if trigger.to_state.state|is_number 
            and trigger.to_state.state|is_number
            and this.state|is_number 
            and d > 0
          %}
            this.state|float + d
          {% else %}
            this.state
          {% endif %}
        unit_of_measurement: "kWh"
        device_class: energy
        state_class: total_increasing
      - name: "Grid export"
        state: >-
          {% set d = trigger.to_state.state|float(0) - trigger.from_state.state|float(0) %}
          {% if trigger.to_state.state|is_number 
            and trigger.to_state.state|is_number
            and this.state|is_number 
            and d < 0
          %}
            this.state|float - d
          {% else %}
            this.state
          {% endif %}
        unit_of_measurement: "kWh"
        device_class: energy
        state_class: total_increasing

Gaat er dus wel vanuit dat je al een template sensor hebt die gewoon al import - export is (= sensor.hw_netto). En denk dat je na het aanmaken beide sensoren nog even handmatig op 0 moet zetten via Dev tools => States => Set state.

Uhm, dit geeft de string this.state|float - d. Je moet het wel even tussen dubbele accolades zetten.

@Cyrus The Virus
Dat je sensor niet werkt komt dus hierdoor.
Je moet {{ this.state|float + d }} gebruikten ipv this.state|float + d (en dat dus overal waar nu alleen maar iets met this.state staat.

Aangezien je nu een string als uitkomst hebt bij een sensor die een numerieke state verwacht, werkt de senosr niet.

Dat het niet in devtools > templates werkt, komt omdat er gebruik gemaakt wordt van trigger variables, die in die omgeving niet bestaan. En ook het this object bestaat daar niet.

[ Voor 13% gewijzigd door TheFes op 29-08-2024 15:20 ]

[Septillion]

Oeps Thanks @TheFes!

@Cyrus The Virus Originele post ook aangepast

[BiG-GuY]

Brynnie schreef op woensdag 28 augustus 2024 @ 13:49:
[...]


Als ik in Home Assistant via Media naar UniFi Protect ga, kan ik daar wel video’s bekijken. Die url’s werken ook als je ze in een afzonderlijk browser venster opent. De url heeft dan dezelfde vorm als vermeld in de integratie webpagina:
http://ip_adres:poortnummer/api/unifiprotect/video/{nvr_id}/{camera_id}/{start}/{end}
Met als enig verschil dat er nog een parameter AuthSig achter volgt met een hele lange string.
Bvb
http://ip_adres:poortnummer/api/unifiprotect/video/{nvr_id}/{camera_id}/{start}/{end}?AuthSig=blablabla.nogeenlangestring

Die AuthSig is per video uniek en wordt vermoedelijk berekend adhv de video en installatie parameters.

Dit is interessant omdat die url wel gebruikt kan worden als url bestemming bij het klikken op een notificatie.

Weet iemand hoe die AuthSig berekend wordt?

Heb de native implementatie nooit snel gekregen met betrekking tot video pop-ups. Binnen HA zelf zit er altijd 1-3sec vertraging in. Gebruik zelf deze methode:
https://community.home-as...cations-with-pipup/537084

Met go2rtc voor de videostream, zodat de delay <1s is.

Snapshot kan via de originele Unifi implementatie met de snapshot functie van HA. Dat is ook snel, maar dus enkel een snapshot.

[Septillion]

@alex3305 Duidelijk

Zou ik er overigens mode: restart van maken. Anders ben je vervolgens voor 30 minuten niet in staat de temperatuur aan te passen.

[Cyrus The Virus]

Septillion schreef op donderdag 29 augustus 2024 @ 15:45:
Oeps Thanks @TheFes!

@Cyrus The Virus Originele post ook aangepast

Helden nu eens kijken of de kWh wel klopt met wat ik zou verwachten.

Alleen reboot van HA zorgt voor problemen mijn grid_import ging van 0 naar 81k (waarde van de meterstand/input). En bij elke reboot verdubbeld de waarde.

En lijkt erop dat YAML reload de waarde wist.

[ Voor 26% gewijzigd door Cyrus The Virus op 29-08-2024 16:40 ]

[Toppe]

HuismAndré schreef op donderdag 29 augustus 2024 @ 15:06:
[...]

Zoals ik al zei "als het vanaf buiten op een andere manier niet kan". Bijvoorbeeld bij een portiekwoning waarbij je op de bovenste verdieping woont.

Maar in dit geval blijkt het te gaan om een situatie waarbij de kleine slaapt (en we dus aan kunnen nemen dat de ouder(s) niet slapen).

Klopt, het gaat er specifiek om dat als de kleinste slaapt en onze dochter buiten speelt dat er nu continu op de bel word gedrukt. Daar werken we aan, maar het zijn niet onze kinderen dus dat is al wat ingewikkelder.

We hebben hier gelukkig 9 rookmelders en 5 brandblussers in huis.

[Septillion]

@Cyrus The Virus Trigger base template sensoren blijven lastig te dubuggen...

Maar voor verdubbelen, klinkt bijna alsof de sensor.hw_netto tijdens een start even 0 is... Hoe heb je die gemaakt?

Voor tweede heb ik even geen idee, jij nog @TheFes?

[Cyrus The Virus]

Septillion schreef op donderdag 29 augustus 2024 @ 16:55:
@Cyrus The Virus Trigger base template sensoren blijven lastig te dubuggen...

Maar voor verdubbelen, klinkt bijna alsof de sensor.hw_netto tijdens een start even 0 is... Hoe heb je die gemaakt?

Voor tweede heb ik even geen idee, jij nog @TheFes?

Het is ook alleen import die fout gaat export niet. Hw_netto is sensor met daarin de waardes die huis de home wizard sensor bij elkaar geteld plus een offset van de analoge meter.

YAML:

  - sensor:
      - name: "Mains Meterstand"
        state_class: total_increasing
        unit_of_measurement: kWh
        device_class: energy
        state: "{{ (states('sensor.mains_total_power_import')|float 
                  - states('sensor.mains_total_power_export')|float 
                  +81522) }}"

[ Voor 23% gewijzigd door Cyrus The Virus op 29-08-2024 17:05 ]

[TheFes]

@Septillion
Je hebt een foutje in je if statement gemaakt
Je checkt 2x op trigger.to_state.state (of deze numeriek is) en niet of trigger.from_state.state

Na een herstart gaat hij van unavailable naar een numerieke state, en dat zorgt dus voor een hele hoge d.
Door eerder genoemd foutje, wordt daar dus mee gerekend in plaats van de huidige this.state terug te geven.

Ik zou naar this.state verwijzen als de to en from state niet beide numeriek zijn.

Ik snap trouwens niet helemaal waarom deze sensor niet op unknown is blijven hangen bij @Cyrus The Virus
Aangezien je in je if statement checkt of this.state numeriek is, en een trigger based template sensor altijd begint als unknown zou ik verwachten dat hij daar dus op blijft hangen.
Ik zou daar niet op checken en this.state naar 0 defaulten in die berekening waar je er de delta bij optelt.
(ik gok dat dit per ongeluk gewerkt heeft omdat het al een bestaande sensor was, en dus al een waarde had)

[ Voor 5% gewijzigd door TheFes op 29-08-2024 17:48 ]

[Septillion]

@TheFes Pff, niet zo scherp meer. Waren natuurlijk ook copy past van elkaar maar vergeten aan te passen Weer aangepast @Cyrus The Virus!

En blijft niet op 0 omdat ik gezegd had dat hij ze na het aanmaken zelf even op 0 moest zetten via dev tools

@Cyrus The Virus Ik zou bij die optelling nog wel even een availability toevoegen. Anders krijg je errors of als nog dat de bron even 0 wordt.

YAML:

  - sensor:
      - name: "Mains Meterstand"
        state_class: total_increasing
        unit_of_measurement: kWh
        device_class: energy
        state: "{{ (states('sensor.mains_total_power_import')|float 
                  - states('sensor.mains_total_power_export')|float 
                  +81522) }}"
        availability: >-
          {{ states('sensor.mains_total_power_import') |is_number
            and states('sensor.mains_total_power_export') |is_number 
          }}

[ Voor 56% gewijzigd door Septillion op 29-08-2024 17:15 ]

[Michaelg]

Hoop dat iemand mij hier kan helpen.

Ik zou graag het volgende willen bereiken:
S'avonds geef ik in HA aan hoe laat ik de volgende dag moet opstaan.
Vervolgens wil ik dat een half uur na die tijd, er een notificatie moet worden gestuurd met een melding. In die melding wil ik dat de gebruiker een input Ja of Nee aan kan geven.
Aan de hand van die input wordt het vervolg bepaald.
Bij Nee, moet de notificatie 5 minuten later opnieuw verzonden worden. Bij Ja, is de actie compleet.

De wachten op notifcatie kan ik realiseren met een wait_for_trigger. Maar hoe ik dan het vervolg kan regelen is mij niet helemaal duidelijk.

Iemand die mij op weg kan helpen?

[Cyrus The Virus]

Het werkt helemaal top scheelt weer nieuwe meter kopen die het wel goed weer geeft.

[ Voor 210% gewijzigd door Cyrus The Virus op 29-08-2024 17:26 ]

[TheFes]

Septillion schreef op donderdag 29 augustus 2024 @ 17:11:
@TheFes Pff, niet zo scherp meer. Waren natuurlijk ook copy past van elkaar maar vergeten aan te passen Weer aangepast @Cyrus The Virus!

En blijft niet op 0 omdat ik gezegd had dat hij ze na het aanmaken zelf even op 0 moest zetten via dev tools

@Cyrus The Virus Ik zou bij die optelling nog wel even een availability toevoegen. Anders krijg je errors of als nog dat de bron even 0 wordt.

YAML:

  - sensor:
      - name: "Mains Meterstand"
        state_class: total_increasing
        unit_of_measurement: kWh
        device_class: energy
        state: "{{ (states('sensor.mains_total_power_import')|float 
                  - states('sensor.mains_total_power_export')|float 
                  +81522) }}"
        availability: >-
          {{ states('sensor.mains_total_power_import') |is_number
            and states('sensor.mains_total_power_export') |is_number 
          }}

Ah, dat verklaart waarom hij werkt.
Maar mocht de sensor onverhoopt toch unavailable of unknown worden heb je daarna alsnog het probleem dat hij er nooit meer vanaf komt.
Aangezien het een total increasing sensor is, is in ieder geval voor de statistics een reset geen ramp. Ik zou die check op een numerieke huidige state er dus uit halen en die naar 0 laten defaulten.

[Septillion]

@TheFes Mja, zou wat dat betreft geen kwaad kunnen nee. Zou ook nooit iets anders mogen worden maar mja

[JME]

JME schreef op donderdag 29 augustus 2024 @ 14:52:
Ik stuur vanuit HA een Tapo smart plug aan (Tapo Controller custom integration) om een ventilator te bedienen. Afhankelijk van bepaalde omstandigheden staat de fan dan een poosje aan (duur verschilt) en daarna stuurt HA weer een uit-commando. Dat basisprincipe heb ik werkend.
Nu viel mij van de week op dat de fan wel erg lang aan stond. In de history zie ik terug dat op het moment van het uit-commando de smart plug tijdelijk unavailable was (wifidekking, glitch, whatever). Kan gebeuren, maar hoe werk ik daar omheen? Is er een manier om een automation iedere zoveel seconden een commando te laten herhalen, net zolang totdat er bevestiging vanuit de smart plug is dat deze op de gewenste stand staat?

Opgelost met een “repeat until” constructie. Schakelaar aanzetten (of uit) en 35 seconden wachten, en dat net zolang herhalen totdat de uitgelezen waarde van de stekker daadwerkelijk aan (of uit) is. Maximum van 25x toegevoegd om te voorkomen dat er een oneindige loop ontstaat mocht de stekker ooit worden losgekoppeld. Die 35 seconden tussen 2 pogingen is omdat dat net iets meer is dan de 30 seconden refresh rate van de stekker in het netwerk. Works like a charm!

[Brynnie]

BiG-GuY schreef op donderdag 29 augustus 2024 @ 15:47:
[...]

Heb de native implementatie nooit snel gekregen met betrekking tot video pop-ups. Binnen HA zelf zit er altijd 1-3sec vertraging in. Gebruik zelf deze methode:
https://community.home-as...cations-with-pipup/537084

Met go2rtc voor de videostream, zodat de delay <1s is.

Snapshot kan via de originele Unifi implementatie met de snapshot functie van HA. Dat is ook snel, maar dus enkel een snapshot.

Over de snelheid heb ik niet te klagen. Bijna instant. Zeker snel genoeg om bruikbaar te zijn. Ik vraag me echter af of ik zelf die autosuggestie kan genereren om zo een klikbare url op te bouwen. Online vind ik daar weinig (niks) over.

[ApfelScha]

Voor wie er net als ik bezig zijn met een voice assistant die niet Google heet... Paulus Schoutsen heeft laten weten ze bezig zijn met een eigen 'voicebox' (bron: YouTube: De OPRICHTER van HOME ASSISTANT is te gast!). Iemand die weet wanneer deze verwacht wordt? Ik was me al zelf in hardware aan het verdiepen, maar als dit er aan enigszins tijdig aan komt dan wacht ik nog even.

[TheFes]

ApfelScha schreef op donderdag 29 augustus 2024 @ 22:21:
Voor wie er net als ik bezig zijn met een voice assistant die niet Google heet... Paulus Schoutsen heeft laten weten ze bezig zijn met een eigen 'voicebox' (bron: YouTube: De OPRICHTER van HOME ASSISTANT is te gast!). Iemand die weet wanneer deze verwacht wordt? Ik was me al zelf in hardware aan het verdiepen, maar als dit er aan enigszins tijdig aan komt dan wacht ik nog even.

Dat was ook al aangekondigd tijdens de state of the open home. Voor zover ik weet is er al een versie naar de content creators gestuurd zodat zij dit kunnen reviewen voor hun blogs/vlogs/YouTube videos/etc.
Maar wellicht is dat nog een vroege test versie.

Paulus heeft wel gezegd dat hij hoopt dat die nog dit jaar uit komt.

[Pejdref]

Quote uit het RPiNut in "Eigen verbruik zelf opgewekte electra verhogen (autonomie?)" topic. Leek me gepaster om hier te reageren.

RPiNut schreef op vrijdag 30 augustus 2024 @ 08:06:
[...]


Zou je willen delen hoe je dit voor elkaar hebt gekregen? Ik zit zelf aan het zelfde te denken. +/- 1 dag, tov elke vrijdag. De solcast integratie heb ik al geinstalleerd en werkt verbazingwekkend goed!

Ik gebruik deze integratie zelf, om mijzelf een melding te geven wanneer het beste moment is, voor de volgende dag om de vaatwasser aan te zetten. Een virtuele schakelaar kan ik 's avonds aan zetten voor de melding, die mij verteld hoeveel uitgestelde tijd ik de vaatwasser moet zetten als ik de volgende ochtend beneden kom.

De solcast integratie geeft sensoren voor de verwachte opbrengst voor de komende 7 dagen. Ik heb een automatisering die op donderdagochtend de komende 3 dagen vergelijkt (today, tomorrow, day_3 sensoren = do, vr, za). En aan de hand daarvan de beste dag kiest. (Je kunt er ook voor kiezen om de automatisering op woensdag te draaien, dan moet je de sensoren tomorrow, day_3 en day_4 gebruiken.) Het vergelijken doe ik met een if then else actie. De datum van die dag sla ik op in een helper, ik vond hier in de GUI geen methode voor dus heb dit met een stukje YAML code gedaan:

YAML:

# slaat de datum van morgen op in de helper 'datumhelper'
action: input_datetime.set_datetime
metadata: {}
data:
  date: "{{ (now()+timedelta(days=1)).date() }}"
target:
  entity_id: input_datetime.datumhelper

Verder heb ik een automatisering die getriggerd wordt op de peaktijd van de opbrengst die dag met als voorwaarde dat de datum vandaag gelijk is aan de opgeslagen datum, deze automatisering zet in mijn geval dan de warmtepomp aan.

In jouw geval zou je een die 2de automatisering kunnen vervangen door een automatisering die draait op het tijdstip dat je de melding wil ontvangen met als voorwaarde dat vandaag gelijk is aan de opgeslagen datum. Of je maakt een automatisering die de virtuele schakelaar op het juiste moment omschakelt, mocht je die schakelaar willen behouden omdat je die ook nog handmatig wil kunnen schakelen.

Als je meer detail nodig hebt vraag het gerust.

[Oon]

Ik gebruik op dit moment deze Apex Chart voor een pie chart met daarin ons huidige verbruik:

YAML:

type: custom:apexcharts-card
header:
  show: true
  title: Verbruik
  show_states: false
all_series_config:
  show:
    legend_value: false
apex_config:
  chart:
    height: 150px
  legend:
    show: false
chart_type: pie
series:
  - entity: sensor.untracked_power
    name: Untracked
    color: pink
  - entity: sensor.current_export
    name: Export
  - entity: sensor.tuya_tv_current_consumption
...
  - entity: sensor.wasmachine_active_power
  - entity: sensor.bureau_nogame_active_power
    name: Bureau

Nou zou ik graag willen dat dit een bar chart wordt, maar dat lijkt Apex niet te ondersteunen?
Als ik een van de andere types gebruik of het type helemaal weg laat krijg ik geen data. Ik denk dus dat ik de X-as dan zal moeten genereren obv een index en custom generators, heeft iemand hier toevallig een voorbeeld van? Ik wil dus gewoon verticale balkjes langs elkaar, die hoger worden als een sensorwaarde hoger is, en lager als de sensorwaarde lager is.

[Septillion]

@Oon Apex kan wel bars. Maar standaard wil Apex dit uitzetten over tijd, is dat ook wat jij wilt?

Maar dan zal je wel aan moeten geven hoe je wilt dat de data samengenomen wordt. Ofwel in hoe grote tijd-bucks verdeeld wordt en welke waarde uit de buckt gebruikt moet worden (min, max, mean, diff etc).

Maar jij wilt in dit geval alleen maar een enkel balkje per sensor met de laatste waarde?

[RPiNut]

Pejdref schreef op vrijdag 30 augustus 2024 @ 09:13:
Quote uit het RPiNut in "Eigen verbruik zelf opgewekte electra verhogen (autonomie?)" topic. Leek me gepaster om hier te reageren.


[...]


De solcast integratie geeft sensoren voor de verwachte opbrengst voor de komende 7 dagen. Ik heb een automatisering die op donderdagochtend de komende 3 dagen vergelijkt (today, tomorrow, day_3 sensoren = do, vr, za). En aan de hand daarvan de beste dag kiest. (Je kunt er ook voor kiezen om de automatisering op woensdag te draaien, dan moet je de sensoren tomorrow, day_3 en day_4 gebruiken.) Het vergelijken doe ik met een if then else actie. De datum van die dag sla ik op in een helper, ik vond hier in de GUI geen methode voor dus heb dit met een stukje YAML code gedaan:

YAML:

# slaat de datum van morgen op in de helper 'datumhelper'
action: input_datetime.set_datetime
metadata: {}
data:
  date: "{{ (now()+timedelta(days=1)).date() }}"
target:
  entity_id: input_datetime.datumhelper

Verder heb ik een automatisering die getriggerd wordt op de peaktijd van de opbrengst die dag met als voorwaarde dat de datum vandaag gelijk is aan de opgeslagen datum, deze automatisering zet in mijn geval dan de warmtepomp aan.

In jouw geval zou je een die 2de automatisering kunnen vervangen door een automatisering die draait op het tijdstip dat je de melding wil ontvangen met als voorwaarde dat vandaag gelijk is aan de opgeslagen datum. Of je maakt een automatisering die de virtuele schakelaar op het juiste moment omschakelt, mocht je die schakelaar willen behouden omdat je die ook nog handmatig wil kunnen schakelen.

Als je meer detail nodig hebt vraag het gerust.

Heel erg bedankt voor de uitleg. Ik ga hier eens in duiken en laat wel weten of het gelukt is. Zo leer je er toch weer iets van! Zal mogelijk een keer een weekend project worden.

[Lauwie007]

@Eriko , ik pak het even op in dit forum, lijkt mij meer on topic.

Eriko schreef op vrijdag 30 augustus 2024 @ 09:31:
[...]


Een variable daily_energy_totalconsumed is niet duidelijk en kan nergens vinden in jouw code hoe het aangemaakt is. Bedoel je soms daily_energy_total_untracked?

Excuus voor de onduidelijkheid, had er inderdaad een beetje een gek voorbeeld van gemaakt. Mijn daily_energy_totalconsumed heb ik zelf gemaakt o.b.v.

code:

      - name: energy_total_Consumed
        unit_of_measurement: "kWh"
        device_class: energy
        state_class: total_increasing
        state: "{{ states('sensor.electricity_meter_energy_consumption_tarif_1') | float + states('sensor.electricity_meter_energy_consumption_tarif_2') | float }}"

Maar wat ik meer bedoelde was het stuk er onder. Van utility meters.
Als je van elke sensor die je wilt een utilitymeter maakt, dan zorg home assistent er zelf voor. Dat wanneer de waarde reset; dat niet fout gaat in de grafieken zoals in jouw afbeelding.

Zo heb ik voor elke sensor 'daily_energy_*' een utility meter gemaakt. En dan krijg je dus zoiets als dit:



Als je wilt kan ik je wel helpen met config maken? Of kom je er zo uit?

[Oon]

Septillion schreef op vrijdag 30 augustus 2024 @ 09:56:
@Oon Apex kan wel bars. Maar standaard wil Apex dit uitzetten over tijd, is dat ook wat jij wilt?

Maar dan zal je wel aan moeten geven hoe je wilt dat de data samengenomen wordt. Ofwel in hoe grote tijd-bucks verdeeld wordt en welke waarde uit de buckt gebruikt moet worden (min, max, mean, diff etc).

Maar jij wilt in dit geval alleen maar een enkel balkje per sensor met de laatste waarde?

Ik wil een realtime weergave, dus inderdaad dat laatste. Met een pie chart kan dat prima, maar een bar chart is daar natuurlijk eigenlijk niet voor bedoeld.
Toch wil ik het wel graag, want een pie chart verspringt helemaal als er een waarde verandert. Ik wil gewoon alle sensoren op een rij, ook als ze op 0 staan, zodat er alleen verschil in hoogte zit.

Edit: Eigenlijk dus zoals de grafiek in de Energy weergave voor individuele apparaten, maar dan met de meest recente waarde ipv totaal, en naast elkaar ipv onder elkaar

[ Voor 8% gewijzigd door Oon op 30-08-2024 10:15 ]

[Septillion]

@Oon Voorbeeldje om enkele bar per item weer te geven:

YAML:

type: custom:apexcharts-card
header:
  show: true
  show_states: false
  colorize_states: true
apex_config:
  xaxis:
    axisTicks:
      show: false
    labels:
      show: false
graph_span: 5m
all_series_config:
  type: column
  group_by:
    func: last
    duration: 250sec
series:
  - entity: sensor.power_produced_phase_1
  - entity: sensor.power_produced_phase_2
  - entity: sensor.power_produced_phase_3
  - entity: sensor.power_consumed_phase_1
  - entity: sensor.power_consumed_phase_2
  - entity: sensor.power_consumed_phase_3

Als graph_span en duration exact even lang zijn wil het alleen niets weergeven. Laatste moet gewoon net iets kleiner zijn.

[ Voor 10% gewijzigd door Septillion op 30-08-2024 10:17 ]

[AWEF]

Oon schreef op vrijdag 30 augustus 2024 @ 10:14:
[...]

Ik wil een realtime weergave, dus inderdaad dat laatste. Met een pie chart kan dat prima, maar een bar chart is daar natuurlijk eigenlijk niet voor bedoeld.
Toch wil ik het wel graag, want een pie chart verspringt helemaal als er een waarde verandert. Ik wil gewoon alle sensoren op een rij, ook als ze op 0 staan, zodat er alleen verschil in hoogte zit.

Edit: Eigenlijk dus zoals de grafiek in de Energy weergave voor individuele apparaten, maar dan met de meest recente waarde ipv totaal, en naast elkaar ipv onder elkaar

Je zou eens kunnen kijken naar https://github.com/custom-cards/bignumber-card. Hiermee heb ik m'n zonnepanelen in kaart gebracht.

[HuismAndré]

Septillion schreef op donderdag 29 augustus 2024 @ 12:57:
@HuismAndré Daar zou je nog een input_number voor kunnen pakken of je zou percentage terug kunnen rekenen aan de hand van de switches.

Iets als

YAML:

fan:
  - platform: template
    fans:
      wtw:
        unique_id: wtw
        friendly_name: "Test WTW"
        value_template: "{{ states('switch.wtw') }}"
        turn_on:
          - action: switch.turn_on
            target:
              entity_id: switch.wtw
        turn_off:
          - action: switch.turn_off
            target:
              entity_id: switch.wtw
        speed_count: 3
        percentage_template: >-
          {% if states('switch.wtw') == 'off' %}
            0
          {% elif states('switch.wtw_stand3') == 'on' %}
            100
          {% elif states('switch.wtw_stand2') == 'on' %}
            66
          {% else %}
            33
          {% endif %}
        set_percentage:
          - action: switch.turn_{{ 'on' if percentage > 0 else 'off' }}
            target:
              entity_id: switch.wtw
          - action: switch.turn_{{ 'on' if percentage > 40 and percentage < 75 else 'off' }}
            target:
              entity_id: switch.wtw_stand2
          - action: switch.turn_{{ 'on' if percentage > 75 else 'off' }}
            target:
              entity_id: switch.wtw_stand3

Dit ging toch niet goed doordat bij een herstart de switches (via Z2M) de eerste 20 seconden niet beschikbaar zijn. Hierdoor kreeg ik rare opstartwaarden. Ook gebeurde het dat de template ongewenst op 1 bleef staan bij een overgang van 2 naar 0 (wellicht een race conditie). Ik heb het teruggezet naar de oude optie en heb een availability template toegevoegd. In de Automatisering heb ik daarna een trigger toegevoegd die afvuurt als de fan.wtw_stand van unavailable naar iets anders gaat. Template is nu dus:

YAML:

fan:
  - platform: template
    fans:
      wtw_stand:
        unique_id: wtw_sturing
        friendly_name: "WTW Sturing"
        value_template: "{{ states('switch.wtw') }}"
        turn_on:
          - action: switch.turn_on
            target:
              entity_id: switch.wtw
        turn_off:
          - action: switch.turn_off
            target:
              entity_id: switch.wtw
        speed_count: 3
        percentage_template: "{{ state_attr('fan.wtw_stand','percentage') if is_state('switch.wtw','on') else 0 }}"
        availability_template: "{{ 'False' if is_state('switch.wtw','unavailable') else 'True' }}"
        set_percentage:
          - action: switch.turn_{{ 'on' if percentage > 75 else 'off' }}
            target:
              entity_id: switch.wtw_stand3
          - action: switch.turn_{{ 'on' if 40 < percentage < 75 else 'off' }}
            target:
              entity_id: switch.wtw_stand2
          - action: switch.turn_{{ 'on' if percentage > 0 else 'off' }}
            target:
              entity_id: switch.wtw

[Oon]

Septillion schreef op vrijdag 30 augustus 2024 @ 10:16:
@Oon Voorbeeldje om enkele bar per item weer te geven:

YAML:

type: custom:apexcharts-card
header:
  show: true
  show_states: false
  colorize_states: true
apex_config:
  xaxis:
    axisTicks:
      show: false
    labels:
      show: false
graph_span: 5m
all_series_config:
  type: column
  group_by:
    func: last
    duration: 250sec
series:
  - entity: sensor.power_produced_phase_1
  - entity: sensor.power_produced_phase_2
  - entity: sensor.power_produced_phase_3
  - entity: sensor.power_consumed_phase_1
  - entity: sensor.power_consumed_phase_2
  - entity: sensor.power_consumed_phase_3

Supervet, dit is echt exact wat ik zoek. Bedankt!

AWEF schreef op vrijdag 30 augustus 2024 @ 10:16:
[...]


Je zou eens kunnen kijken naar https://github.com/custom-cards/bignumber-card. Hiermee heb ik m'n zonnepanelen in kaart gebracht.

[Afbeelding]

Ga ik ook zeker eens naar kijken, dat is niet de weergave die ik hier nu zoek maar voor een andere weergave die ik heb wel heel nuttig

[TheFes]

Lauwie007 schreef op vrijdag 30 augustus 2024 @ 10:08:
@Eriko , ik pak het even op in dit forum, lijkt mij meer on topic.


[...]


Excuus voor de onduidelijkheid, had er inderdaad een beetje een gek voorbeeld van gemaakt. Mijn daily_energy_totalconsumed heb ik zelf gemaakt o.b.v.

code:

      - name: energy_total_Consumed
        unit_of_measurement: "kWh"
        device_class: energy
        state_class: total_increasing
        state: "{{ states('sensor.electricity_meter_energy_consumption_tarif_1') | float + states('sensor.electricity_meter_energy_consumption_tarif_2') | float }}"

Maar wat ik meer bedoelde was het stuk er onder. Van utility meters.
Als je van elke sensor die je wilt een utilitymeter maakt, dan zorg home assistent er zelf voor. Dat wanneer de waarde reset; dat niet fout gaat in de grafieken zoals in jouw afbeelding.

Zo heb ik voor elke sensor 'daily_energy_*' een utility meter gemaakt. En dan krijg je dus zoiets als dit:
[Afbeelding]


Als je wilt kan ik je wel helpen met config maken? Of kom je er zo uit?

Heb je die untracked zelf gemaakt? Vanaf 2024.9 zit die er namelijk standaard in.

[Septillion]

@HuismAndré Eerste issue is gewoon op te lossen door de fan gewoon van een availability te voorzien. Misschien dat een unavailable ook voor het gekke van 2 naar 0 zorgt. Want heb juist speed 0 als eerste check erin zitten.

Want snap weer niet waar je opeens fan.wtw_stand vandaan tovert

[Eriko]

Geef ons een voorbeeld over nieuwe standaard? Enige link?

[Tom2828]

Ik heb een vraag rondom vreemd gedrag van 2 lampen:

's Avonds als ik wil gaan slapen druk ik op een smart button naast mijn bed. Deze triggert een automation die het huis in 'nacht' modus zet en bepaalde lampen uit.

Het gekke is dat de 'light.zigbee_slaapkamer_spots' eerst helemaal naar 100% aan gaat en vervolgens dimt naar 0%. Ook als ze daarvoor al uit stonden. Dat gebeurt dus met 'action: light.turn_off'.

'light.zigbee_slaapkamer_spots' is een ZHA groep van 2 spots (TRADFRI bulb GU10 WS 345lm)

Heeft iemand dit wel eens meegemaakt en wat zou dit kunnen veroorzaken?

YAML:

if:
  - condition: state
    entity_id: input_select.huis_modus
    state: Thuis
then:
  - target:
      entity_id: input_select.huis_modus
    data:
      option: Nacht
    action: input_select.select_option
  - metadata: {}
    data:
      transition: 2
    action: light.turn_off
    target:
      entity_id:
        - light.zigbee_slaapkamer_spots
        - light.zigbee_slaapkamer_play_bars
  - stop: ""

[TheFes]

Eriko schreef op vrijdag 30 augustus 2024 @ 10:21:
Geef ons een voorbeeld over nieuwe standaard? Enige link?

Bedoel je die untracked energy?
Er staat een voorbeeld in de beta release notes
https://rc.home-assistant...ing-your-untracked-energy

[Ora et Labora]

Tom2828 schreef op vrijdag 30 augustus 2024 @ 10:23:
Ik heb een vraag rondom vreemd gedrag van 2 lampen:

's Avonds als ik wil gaan slapen druk ik op een smart button naast mijn bed. Deze triggert een automation die het huis in 'nacht' modus zet en bepaalde lampen uit.

Het gekke is dat de 'light.zigbee_slaapkamer_spots' eerst helemaal naar 100% aan gaat en vervolgens dimt naar 0%. Ook als ze daarvoor al uit stonden. Dat gebeurt dus met 'action: light.turn_off'.

'light.zigbee_slaapkamer_spots' is een ZHA groep van 2 spots (TRADFRI bulb GU10 WS 345lm)

Heeft iemand dit wel eens meegemaakt en wat zou dit kunnen veroorzaken?

YAML:

if:
  - condition: state
    entity_id: input_select.huis_modus
    state: Thuis
then:
  - target:
      entity_id: input_select.huis_modus
    data:
      option: Nacht
    action: input_select.select_option
  - metadata: {}
    data:
      transition: 2
    action: light.turn_off
    target:
      entity_id:
        - light.zigbee_slaapkamer_spots
        - light.zigbee_slaapkamer_play_bars
  - stop: ""

Zelf niet meegemaakt maar je zou een voorwaarde erin kunnen zetten dat deze lampen aan moeten staan voordat ze een turn_off opdracht krijgen.
En even individueel in de automatisering zetten, dus niet via een groep maar losse spots om te kijken of het dan nog steeds voorkomt, dan weet je waar je het moet zoeken.

[Lauwie007]

@Eriko
Ik weet niet precies wat je wilt doen, maar denk dat je config er (ongeveer) zo uit moet zien, of ter inspiratie:

YAML:

template:
  - trigger:
      - platform: time_pattern
        seconds: 00 ##Update once a minute
    sensor:
      - name: "daily_energy_consumption_dev"
        device_class: energy
        state_class: total
        unit_of_measurement: kWh
        state: >
          {{(states('sensor.electricity_meter_energy_consumption_tarif_1')|float +
             states('sensor.electricity_meter_energy_consumption_tarif_2')|float)
            |round(3)}}
      - name: "daily_energy_production_dev"
        device_class: energy
        state_class: total
        unit_of_measurement: kWh
        state: >
          {{(states('sensor.electricity_meter_energy_production_tarif_1')|float +
             states('sensor.electricity_meter_energy_production_tarif_2')|float)
            |round(3)}}
      - name: "daily_energy_grid_dev" 
        device_class: energy
        state_class: measurement
        unit_of_measurement: kWh
        state: > 
          {{((states('sensor.daily_energy_consumption_saved')|float) - 
             (states('sensor.daily_energy_production_saved')|float))
            |round(3)}}

      - name: "cost_price_energy"
        device_class: monetary
        state_class: measurement
        unit_of_measurement: EUR
        state: >
          {{((states('sensor.daily_energy_grid')|float) *
             states('sensor.uil_electricity_price')|float)
            |round(2)}}

utility_meter:
  #hourly
  hourly_energy_grid:
    source: sensor.daily_energy_grid_dev
    cycle: hourly
  hourly_energy_consumption:
    source: sensor.daily_energy_consumption_dev
    cycle: hourly
  hourly_energy_production:
    source: sensor.daily_energy_production_dev
    cycle: hourly
  #daily
  daily_energy_grid:
    source: sensor.daily_energy_grid_dev
    cycle: daily
  daily_energy_consumption:
    source: sensor.daily_energy_consumption_dev
    cycle: daily
  daily_energy_production:
    source: sensor.daily_energy_production_dev
    cycle: daily

@TheFes
Oh wauw, die functie ken ik niet. Die untracked had ik zelf gemaakt in mijn config. Kwam een beetje als ongelukkig voorbeeld naar Eriko.

[ Voor 0% gewijzigd door Septillion op 30-08-2024 10:32 . Reden: Denk aan de 'yaml' bij de code tags aub! Zie topic warning en hoe deze post is aangepast. ]

[Septillion]

@Tom2828 Klinkt mij als een issue met de transition.

Probeer maar eens een actie met en zonde transition op de lampen te runnen. Work around zou inderdaad zijn om eerst te checken of de lampen aan staan. maar echte fix zou dan in ZHA moeten komen...

[Eriko]

TheFes schreef op vrijdag 30 augustus 2024 @ 10:28:
[...]


Bedoel je die untracked energy?
Er staat een voorbeeld in de beta release notes
https://rc.home-assistant...ing-your-untracked-energy

Het wordt dan interessant!

Gezien dat ik geen gas aansluiting meer heb, vind ik wel jammer dat er geen bolletje 'warmtepomp' bestaat in de energy distribution. Komt het binnenkort? Of heb ik soms over mijn hoofd gezien?

[Tom2828]

Septillion schreef op vrijdag 30 augustus 2024 @ 10:32:
@Tom2828 Klinkt mij als een issue met de transition.

Probeer maar eens een actie met en zonde transition op de lampen te runnen. Work around zou inderdaad zijn om eerst te checken of de lampen aan staan. maar echte fix zou dan in ZHA moeten komen...

Ora et Labora schreef op vrijdag 30 augustus 2024 @ 10:31:
[...]

Zelf niet meegemaakt maar je zou een voorwaarde erin kunnen zetten dat deze lampen aan moeten staan voordat ze een turn_off opdracht krijgen.
En even individueel in de automatisering zetten, dus niet via een groep maar losse spots om te kijken of het dan nog steeds voorkomt, dan weet je waar je het moet zoeken.

Ik zal de transition eens weghalen en ze in losse actions zetten. Op één of andere manier kan ik het probleem nu niet reproduceren, maar het is elke avond wel zo als ik in bed lig. Zal wellicht aan nog een andere variabele liggen.

[Lauwie007]

@Eriko
Ik verwacht dat in mijn voorbeeld config de cost_price_energy wel fout gaat. Die wordt nu per dag gedaan, maar dat gaat natuurlijk fout. Daar kan je wel de hourly_energy_grid gebruiken.

[Eriko]

Lauwie007 schreef op vrijdag 30 augustus 2024 @ 10:31:
@Eriko
Ik weet niet precies wat je wilt doen, maar denk dat je config er (ongeveer) zo uit moet zien, of ter inspiratie:

[code=yaml]
template:
- trigger:
- platform: time_pattern
seconds: 00 ##Update once a minute
...
- name: "daily_energy_grid_dev"
device_class: energy
state_class: measurement
unit_of_measurement: kWh
state: >
{{((states('sensor.daily_energy_consumption_saved')|float) -
(states('sensor.daily_energy_production_saved')|float))
|round(3)}}
...

sensor.daily_energy_consumption_saved / sensor.daily_energy_production_saved komen niet voor ergens in deze script. Typo?

[Lauwie007]

Eriko schreef op vrijdag 30 augustus 2024 @ 10:48:
[...]


sensor.daily_energy_consumption_saved / sensor.daily_energy_production_saved komen niet voor ergens in deze script. Typo?

Ik dacht dat die sensoren dubbelop waren en dat ik ze kon vervangen met een utility meter?
Wat bedoel je met de '_saved' er achter?

[Eriko]

De _saved slaat de waarden op om 24:00 (enkele seconden ervoor). Dat was te zien in mijn huidige script. Deze moet ik dan vervangen door de utility_meter. Toch?

[Lauwie007]

Ah zo, dat had ik niet helemaal door.

Ja, dan werkt een utility_meter wel mooier. Die loopt gewoon op, en reset op welke cycle je zelf aangeeft. Dit gaat ook automatisch goed in de energie overzichten van home assistant.

[D4NG3R]

Weet iemand toevallig hoe je kan achterhalen of de status van bijvoorbeeld een lamp of de ventilatie is veranderd door iets anders dan een automation (welke een scene aanroept)?

Als een van de devices welke door de automation word aangestuurd handmatig word aangepast wil ik namelijk dat de gehele automation disabled word. Ik lees her en der wat omtrent de context van devices, maar haal hier in ieder geval in de template editor geen resultaat uit. De context is te allen tijde null.

[ Voor 20% gewijzigd door D4NG3R op 30-08-2024 10:59 ]

[HuismAndré]

Septillion schreef op vrijdag 30 augustus 2024 @ 10:21:
@HuismAndré Eerste issue is gewoon op te lossen door de fan gewoon van een availability te voorzien. Misschien dat een unavailable ook voor het gekke van 2 naar 0 zorgt. Want heb juist speed 0 als eerste check erin zitten.

Want snap weer niet waar je opeens fan.wtw_stand vandaan tovert

Die volgorde (van de schakelaars) was eerst andersom (die omkering was dus het eerste dat ik gedaan had). Daarna is die rare 2->0 (met als resultaat 1) situatie niet meer voorkomen.

Availability had ik al toegevoegd (staat ook in m'n vorige bericht).

fan.wtw_stand is afkomstig van de fan template met aangemaakte entity wtw_stand. Wat zou ik anders moeten gebruiken?

[ Voor 3% gewijzigd door HuismAndré op 30-08-2024 11:10 ]

[RPiNut]

D4NG3R schreef op vrijdag 30 augustus 2024 @ 10:58:
Weet iemand toevallig hoe je kan achterhalen of de status van bijvoorbeeld een lamp of de ventilatie is veranderd door iets anders dan een automation (welke een scene aanroept)?

Als een van de devices welke door de automation word aangestuurd handmatig word aangepast wil ik namelijk dat de gehele automation disabled word. Ik lees her en der wat omtrent de context van devices, maar haal hier in ieder geval in de template editor geen resultaat uit. De context is te allen tijde null.

Als je het apparaat aan klikt en dan naar Logboek gaat. Ik kan daarmee zien of ik, mijn vriendin of een automatisering de lampen heeft aan of uit gezet. Ik weet alleen niet of je hier op kunt triggeren in een nieuwe automatisering. Mogelijk dat dit via de Eventbus gaat, ik ben hier inderdaad ook wel benieuwd naar. Als ik de lampen uit zet dat de automatisering voor 3 uur gepauzeerd wordt.

[Ora et Labora]

D4NG3R schreef op vrijdag 30 augustus 2024 @ 10:58:
Weet iemand toevallig hoe je kan achterhalen of de status van bijvoorbeeld een lamp of de ventilatie is veranderd door iets anders dan een automation (welke een scene aanroept)?

Als een van de devices welke door de automation word aangestuurd handmatig word aangepast wil ik namelijk dat de gehele automation disabled word. Ik lees her en der wat omtrent de context van devices, maar haal hier in ieder geval in de template editor geen resultaat uit. De context is te allen tijde null.

Je kunt een helper aanmaken, genaamd handmatig bijvoorbeeld.
Deze aan laten zetten wanneer er een handmatige actie wordt gedetecteerd, ik weet niet of dat via een schakelaar oid gaat, maar de state van het device is dan iets anders dan normaliter vanuit de automatisering wordt weergegeven.
Deze helper moet dan uitstaan als voorwaarde voor de automatisering.
Eventueel om 00:00 weer uitzetten oid en eventueel het device dan ook uitzetten.

Voorbeeld gegenereer door AI:

YAML:

# Input Boolean Helper
input_boolean:
  manual_override:
    name: Manual Override
    initial: off

# Main Automation Example (with condition to check the Manual Override)
automation:
  - alias: "Turn On Lights Automatically"
    trigger:
      - platform: time
        at: "18:00:00"  # Example trigger
    condition:
      - condition: state
        entity_id: input_boolean.manual_override
        state: "off"  # Only run if Manual Override is off
    action:
      - service: light.turn_on
        target:
          entity_id: light.living_room

# Automation to Enable Manual Override
  - alias: "Manual Light Change Detected"
    trigger:
      - platform: state
        entity_id: light.living_room
        to: "on"  # Example of detecting a manual change
    condition:
      - condition: template
        value_template: "{{ trigger.to_state.context.user_id is not none }}" # Check if change is manual
    action:
      - service: input_boolean.turn_on
        target:
          entity_id: input_boolean.manual_override

# Automation to Reset Manual Override After Some Time
  - alias: "Reset Manual Override"
    trigger:
      - platform: time
        at: "23:00:00"  # Example of when you want to reset
    action:
      - service: input_boolean.turn_off
        target:
          entity_id: input_boolean.manual_override

[ Voor 40% gewijzigd door Ora et Labora op 30-08-2024 11:10 ]

[Septillion]

HuismAndré schreef op vrijdag 30 augustus 2024 @ 11:04:
[...]

Die volgorde (van de schakelaars) was eerst andersom (die omkering was dus het eerste dat ik gedaan had). Daarna is die rare 2->0 (met als resultaat 1) situatie niet meer voorkomen.

Availability had ik al toegevoegd (staat ook in m'n vorige bericht).

fan.wtw_stand is afkomstig van de fan template met aangemaakte entity wtw_stand. Wat zou ik anders moeten gebruiken?
[Afbeelding]

Gewoon percentage op basis van de standen van de schakelaar Een template fan voor een template fan is beetje dubbelop.

[RPiNut]

Ora et Labora schreef op vrijdag 30 augustus 2024 @ 11:07:
[...]

Je kunt een helper aanmaken, genaamd handmatig bijvoorbeeld.
Deze aan laten zetten wanneer er een handmatige actie wordt gedetecteerd, ik weet niet of dat via een schakelaar oid gaat, maar de state van het device is dan iets anders dan normaliter vanuit de automatisering wordt weergegeven.
Deze helper moet dan uitstaan als voorwaarde voor de automatisering.
Eventueel om 00:00 weer uitzetten oid en eventueel het device dan ook uitzetten.

Voorbeeld gegenereer door AI:

YAML:

# Input Boolean Helper
input_boolean:
  manual_override:
    name: Manual Override
    initial: off

# Main Automation Example (with condition to check the Manual Override)
automation:
  - alias: "Turn On Lights Automatically"
    trigger:
      - platform: time
        at: "18:00:00"  # Example trigger
    condition:
      - condition: state
        entity_id: input_boolean.manual_override
        state: "off"  # Only run if Manual Override is off
    action:
      - service: light.turn_on
        target:
          entity_id: light.living_room

# Automation to Enable Manual Override
  - alias: "Manual Light Change Detected"
    trigger:
      - platform: state
        entity_id: light.living_room
        to: "on"  # Example of detecting a manual change
    condition:
      - condition: template
        value_template: "{{ trigger.to_state.context.user_id is not none }}" # Check if change is manual
    action:
      - service: input_boolean.turn_on
        target:
          entity_id: input_boolean.manual_override

# Automation to Reset Manual Override After Some Time
  - alias: "Reset Manual Override"
    trigger:
      - platform: time
        at: "23:00:00"  # Example of when you want to reset
    action:
      - service: input_boolean.turn_off
        target:
          entity_id: input_boolean.manual_override

Ik heb het ook een AI gevraagd, die zegt dat je de conditie kunt invullen op basis van een template condition: {{ trigger.to_state.context.user_id is not none }}

Ik ga hier eens in duiken, want ik snap aan de ene kant hoe dit werkt. Ik zal dit moeten testen.

[TheFes]

Eriko schreef op vrijdag 30 augustus 2024 @ 10:33:
[...]


Het wordt dan interessant!

Gezien dat ik geen gas aansluiting meer heb, vind ik wel jammer dat er geen bolletje 'warmtepomp' bestaat in de energy distribution. Komt het binnenkort? Of heb ik soms over mijn hoofd gezien?

Die verbruikt dan toch gewoon stroom? Dus staat hij bij Energy.
Waarom zou het een apart bolletje moeten zijn.

[D4NG3R]

Ora et Labora schreef op vrijdag 30 augustus 2024 @ 11:07:
[...]

Je kunt een helper aanmaken, genaamd handmatig bijvoorbeeld.
Deze aan laten zetten wanneer er een handmatige actie wordt gedetecteerd, ik weet niet of dat via een schakelaar oid gaat, maar de state van het device is dan iets anders dan normaliter vanuit de automatisering wordt weergegeven.

Ook daarvoor moet ik wel eerst weten of het een handmatige acties is geweest of niet, en juist dat is waar ik op vast loop. De trigger voor het aan/uitzetten zie ik bijvoorbeeld wel terug in het logboek (al zou ik niet weten hoe ik deze informatie vervolgens ergens anders kan gebruiken), maar een wijziging in de helderheid zie ik zelfs daar niet langs komen, laat staan wat die wijziging heeft aangeroepen.

Handmatig:


Script: (Welke een scene aanroept)

[TheFes]

Lauwie007 schreef op vrijdag 30 augustus 2024 @ 10:31:
@TheFes
Oh wauw, die functie ken ik niet. Die untracked had ik zelf gemaakt in mijn config. Kwam een beetje als ongelukkig voorbeeld naar Eriko.

Dit is dus nieuw in de beta voor 2024.9

[Ora et Labora]

D4NG3R schreef op vrijdag 30 augustus 2024 @ 11:17:
[...]

Ook daarvoor moet ik wel eerst weten of het een handmatige acties is geweest of niet, en juist dat is waar ik op vast loop. De trigger voor het aan/uitzetten zie ik bijvoorbeeld wel terug (al zou ik niet weten hoe ik deze informatie vervolgens ergens anders kan gebruiken), maar een wijziging in de helderheid zie ik zelfs daar niet langs komen, laat staan wat die wijziging heeft aangeroepen.

Handmatig:
[Afbeelding]

Script: (Welke een scene aanroept)
[Afbeelding]

De automatisering activeert bijvoorbeeld een scene, dan hebben je lampen een bepaalde staat, bijvoorbeeld helderheid of sterkte oid.
Als de lamp aan staat en de staat is anders dan die scene, betekent het dat er een handmatige actie is geweest wat je weer in een template kan gieten.

[RPiNut]

D4NG3R schreef op vrijdag 30 augustus 2024 @ 11:17:
[...]

Ook daarvoor moet ik wel eerst weten of het een handmatige acties is geweest of niet, en juist dat is waar ik op vast loop. De trigger voor het aan/uitzetten zie ik bijvoorbeeld wel terug in het logboek (al zou ik niet weten hoe ik deze informatie vervolgens ergens anders kan gebruiken), maar een wijziging in de helderheid zie ik zelfs daar niet langs komen, laat staan wat die wijziging heeft aangeroepen.

Handmatig:
[Afbeelding]

Script: (Welke een scene aanroept)
[Afbeelding]

Ik snap wat je bedoelt. Ik denk dat ik dit weekend eens ga kijken of ik er achter kan komen, hoe deze informatie word verstuurd. Hieronder kun je duidelijk het verschil zien, tussen verschillende triggers in een automatisering en of ik dit handmatig doe. Ik weet trouwens niet of er ook nog weer verschil word gemaakt tussen het in en uit schakelen met een soort Zigbee remote. Misschien is de tactiek met de helper van Ora et Labora wel een simpelere manier om dit te doen.

[D4NG3R]

Ora et Labora schreef op vrijdag 30 augustus 2024 @ 11:23:
[...]

De automatisering activeert bijvoorbeeld een scene, dan hebben je lampen een bepaalde staat, bijvoorbeeld helderheid of sterkte oid.
Als de lamp aan staat en de staat is anders dan die scene, betekent het dat er een handmatige actie is geweest wat je weer in een template kan gieten.

Dan zou ik bij elke lamp, voor elke wijziging moeten na gaan lopen welke scene voor het laatst is aangeroepen en/of de waarde(n) daar (nog) mee overeenkomen.

Dat klinkt vrij omslachtig, maar geeft in ieder geval het gewenste resultaat. In het weekend maar eens naar kijken, thanks.

[Ora et Labora]

D4NG3R schreef op vrijdag 30 augustus 2024 @ 11:29:
[...]

Dan zou ik bij elke lamp, voor elke wijziging moeten na gaan lopen welke scene voor het laatst is aangeroepen en/of de waarde(n) daar (nog) mee overeenkomen.

Dat klinkt vrij omslachtig, maar geeft in ieder geval het gewenste resultaat. In het weekend maar eens naar kijken, thanks.

Het is ook een beetje afhankelijk hoe die handmatige interactie plaatsvind.
Als dit via een schakelaar gaat, zou je dat event in je automatisering kunnen verwerken.
Als dit via een dashboard van HA gaat, zou je dat ook mee kunnen nemen door helpers op het dashboard te gebruiken in plaats van de lampen rechstreeks.

[D4NG3R]

Ora et Labora schreef op vrijdag 30 augustus 2024 @ 11:39:
[...]

Het is ook een beetje afhankelijk hoe die handmatige interactie plaatsvind.
Als dit via een schakelaar gaat, zou je dat event in je automatisering kunnen verwerken.
Als dit via een dashboard van HA gaat, zou je dat ook mee kunnen nemen door helpers op het dashboard te gebruiken in plaats van de lampen rechstreeks.

Het is een mix van beide, als ik languit op de bank lig en m'n telefoon of tablet niet bij de hand heb dim ik m'n verlichting nog regelmatig via fysieke (Zigbee) schakelaars, ook eventueel bezoek moet dat gewoon kunnen doen zonder het systeem verder te kennen.

Ik heb in ieder geval een plannetje door jouw suggesties, vanavond lekker mee klooien.

[Ronker32]

Inhakend op een aantal berichten check ik of een lamp handmatig is aangezet. Zo kan het zijn dat het aanzetten van de TV er voor zorgt dat de spotjes in de keuken gedimd worden, maar als mijn partner daar toevallig bezig is waar ze veel licht bij nodig heeft kan ze dat dus 'overriden'.

Ik doe dat met de volgende automation:

YAML:

- id: keukenspotjesboolean
  alias: Keukenspotjes boolean
  mode: restart
  trigger:
  - platform: state
    entity_id: light.keukenspotjes
    to: 'on'
    id: 'on'
  - platform: state
    entity_id: light.keukenspotjes
    to: 'off'
    id: 'off'
  condition:
  - condition: template
    value_template: "{{ trigger.to_state.context.user_id == none and trigger.to_state.context.parent_id == none }}"
  action:
  - service: "input_boolean.turn_{{ trigger.id }}"
    entity_id: input_boolean.keukenspotjeshandmatig

De magie wordt gedaan door de trigger.to_state.context.user_id en de trigger.to_state.context.parent_id. Ik heb dat getest door deze beide in een notificatie te plaatsen die werd verstuurd als een lamp aan ging. Dat is echt ideaal, je krijgt dan direct door wat het effect is van je actie. En... je wordt je ook bewust van de vele manieren waarop een lamp aan kan gaan: handmatig via de schakelaar, via een automation, via een toggle op je dashboard, et cetera.

Wellicht helpt bovenstaande iemand!

[dotcom87]

@Septillion Deel jij toevallig jouw HA configuratie ook op GitHub ofzo?

[RPiNut]

Ronker32 schreef op vrijdag 30 augustus 2024 @ 12:14:
Inhakend op een aantal berichten check ik of een lamp handmatig is aangezet. Zo kan het zijn dat het aanzetten van de TV er voor zorgt dat de spotjes in de keuken gedimd worden, maar als mijn partner daar toevallig bezig is waar ze veel licht bij nodig heeft kan ze dat dus 'overriden'.

Ik doe dat met de volgende automation:

YAML:

- id: keukenspotjesboolean
  alias: Keukenspotjes boolean
  mode: restart
  trigger:
  - platform: state
    entity_id: light.keukenspotjes
    to: 'on'
    id: 'on'
  - platform: state
    entity_id: light.keukenspotjes
    to: 'off'
    id: 'off'
  condition:
  - condition: template
    value_template: "{{ trigger.to_state.context.user_id == none and trigger.to_state.context.parent_id == none }}"
  action:
  - service: "input_boolean.turn_{{ trigger.id }}"
    entity_id: input_boolean.keukenspotjeshandmatig

De magie wordt gedaan door de trigger.to_state.context.user_id en de trigger.to_state.context.parent_id. Ik heb dat getest door deze beide in een notificatie te plaatsen die werd verstuurd als een lamp aan ging. Dat is echt ideaal, je krijgt dan direct door wat het effect is van je actie. En... je wordt je ook bewust van de vele manieren waarop een lamp aan kan gaan: handmatig via de schakelaar, via een automation, via een toggle op je dashboard, et cetera.

Wellicht helpt bovenstaande iemand!

Dit is wat ik bedoel en wat ik zoek! Bedankt voor je automatisering. Ik ga er ook dit weekend eens mee klooien! Het doel van mijn automatisering is dus als ik buiten zit, de verlichting binnen uit doe, wil ik niet eerder dat deze aan gaat na dat er beweging is gedetecteerd in het trapgat ivm de muggen. Een deur of raam sensor is bij ons helaas geen optie.

[TheFes]

RPiNut schreef op vrijdag 30 augustus 2024 @ 12:38:
[...]


Dit is wat ik bedoel en wat ik zoek! Bedankt voor je automatisering. Ik ga er ook dit weekend eens mee klooien! Het doel van mijn automatisering is dus als ik buiten zit, de verlichting binnen uit doe, wil ik niet eerder dat deze aan gaat na dat er beweging is gedetecteerd in het trapgat ivm de muggen. Een deur of raam sensor is bij ons helaas geen optie.

offtopic:
https://www.rivm.nl/muggen

Quote van die pagina:
Komen muggen op licht af?
Nee, muggen komen niet op licht af. Muggen komen vooral op geur af, zoals zweet. Ook komen ze af op uitgeademde lucht ( CO2 (carbon dioxide)) en op warmte.

Je ziet ze alleen beter in het licht, maar in het donker zijn ze net zo goed..

zie voor meer uitleg bijvoorbeeld: https://www.quest.nl/natu...komen-muggen-op-licht-af/

[ Voor 9% gewijzigd door TheFes op 30-08-2024 12:49 ]

[rkonings]

Ik heb een heel kleine stukje code van de afvalwijzer:

YAML:

type: vertical-stack
cards:
  - type: entities
    entities:
      - entity: sensor.afvalwijzer_papier
      - entity: sensor.afvalwijzer_gft
      - entity: sensor.afvalwijzer_restafval
    sort: null
    attribute: days_until_collection_date
    method: attribute
    numeric: true

maar ik kan met geen mogelijkheid op "save" klikken... blijft maar "ronddraaien", de data wordt netjes in een preview weergegeven...

[ Voor 2% gewijzigd door Septillion op 30-08-2024 15:13 . Reden: Denk aan de 'yaml' bij de code tags aub! Zie topic warning en hoe deze post is aangepast. ]

[D4NG3R]

@Ora et Labora @RPiNut met dank aan bovenstaande automation van @Ronker32

YAML:

- id: '1725013174699'
  alias: Verlichting woonkamer handmatig
  description: 'Check of een van de lampen van state is verandert door wat anders dan een automation'
  trigger:
  - platform: state
    entity_id:
    - light.0x1c34f1fffe7f7a0b
    - light.0x60b647fffec2ca08
    - light.0xb0c7defffe8c0135
    - light.0xb43522fffefca290
    - light.0x60b647fffec5abbb
    - light.0x60b647fffeb8c94e
  condition:
  - condition: state
    entity_id: input_boolean.verlichting_woonkamer_manual
    state: 'off'
  - condition: template
    value_template: '{{ trigger.to_state.context.parent_id == none }}'
  action:
  - action: input_boolean.turn_on
    metadata: {}
    data: {}
    target:
      entity_id: input_boolean.verlichting_woonkamer_manual
  mode: single

Nog niet daadwerkelijk met de fysieke knoppen getest aangezien ik niet thuis ben, maar de parent_id != none wanneer deze door een automation is aangeroepen, wel via een handeling in de UI.

Slingert een input_boolean aan waarop getest kan worden in de andere automation.

[ Voor 8% gewijzigd door D4NG3R op 30-08-2024 13:44 ]

[manusjevanalles]

Pejdref schreef op vrijdag 30 augustus 2024 @ 09:13:
Quote uit het RPiNut in "Eigen verbruik zelf opgewekte electra verhogen (autonomie?)" topic. Leek me gepaster om hier te reageren.


[...]


De solcast integratie geeft sensoren voor de verwachte opbrengst voor de komende 7 dagen. Ik heb een automatisering die op donderdagochtend de komende 3 dagen vergelijkt (today, tomorrow, day_3 sensoren = do, vr, za). En aan de hand daarvan de beste dag kiest. (Je kunt er ook voor kiezen om de automatisering op woensdag te draaien, dan moet je de sensoren tomorrow, day_3 en day_4 gebruiken.) Het vergelijken doe ik met een if then else actie. De datum van die dag sla ik op in een helper, ik vond hier in de GUI geen methode voor dus heb dit met een stukje YAML code gedaan:

YAML:

# slaat de datum van morgen op in de helper 'datumhelper'
action: input_datetime.set_datetime
metadata: {}
data:
  date: "{{ (now()+timedelta(days=1)).date() }}"
target:
  entity_id: input_datetime.datumhelper

Verder heb ik een automatisering die getriggerd wordt op de peaktijd van de opbrengst die dag met als voorwaarde dat de datum vandaag gelijk is aan de opgeslagen datum, deze automatisering zet in mijn geval dan de warmtepomp aan.

In jouw geval zou je een die 2de automatisering kunnen vervangen door een automatisering die draait op het tijdstip dat je de melding wil ontvangen met als voorwaarde dat vandaag gelijk is aan de opgeslagen datum. Of je maakt een automatisering die de virtuele schakelaar op het juiste moment omschakelt, mocht je die schakelaar willen behouden omdat je die ook nog handmatig wil kunnen schakelen.

Als je meer detail nodig hebt vraag het gerust.

Ik zou wel erg geinteresseerd zijn in de scripts/automatisering hoe je dit hebt ingeregeld. Zowel moment van aansturen boiler als plannen van legionellarun. Zou je de codes willen delen?

[RPiNut]

manusjevanalles schreef op vrijdag 30 augustus 2024 @ 14:28:
[...]


Ik zou wel erg geinteresseerd zijn in de scripts/automatisering hoe je dit hebt ingeregeld. Zowel moment van aansturen boiler als plannen van legionellarun. Zou je de codes willen delen?

De Legionella run doe ik nu nog met de hand, tenzei ik niks doe, dan regelt de warmtepomp dit zelf.

Het script dat ik stuur om het water te verwarmen (En dit ligt natuurlijk puur hoe je je boiler aan stuurt.);

Trigger:
- Actueel vermogen -600W of
- Specifieke tijd, bijv 15:00

Condition:
- Input boolean = on. (helper)

Action (Dit kan natuurlijk ook als script(s), dit heb ik voor mij zelf wel gedaan):
- Set number Stop temperatuur 54
- Delay 30 seconden
- Set number Start temperatuur 52
- Delay 30 seconden
- Set number Start temperatuur 42
- Wait for trigger - Compressor frequentie =< 15 Hz
- Send notification - Water verwarmen gestart
- Delay 120 seconden
- Wait for trigger - Compressor frequentie => 15 Hz
- Delay 30 seconden
- Set number Stop temperatuur 46
- Send notification - Water verwarmen compleet

Mijn acties om de Legionellarun te triggeren bij mijn warmtepomp is alsvolgt (Trigger meest gunstigste moment komt dus nog);

- Set number Periodic heat = 7
- Delay 60 seconden
- Set number Periodic heat = 9

Mijn warmtepomp heeft de mogelijkheid van modbus, waar ik hem op aanstuur, alleen niet een soort knop "Nu verwarmen" "Nu stoppen met verwarmen" of "Verwarm eenmalig tot 55 graden". Zelfs de virtuele knop in de Modbus controller "Compressor blokkeren" en "Verwarmings element blokkeren" werken niet.

[manusjevanalles]

RPiNut schreef op vrijdag 30 augustus 2024 @ 14:44:
[...]


De Legionella run doe ik nu nog met de hand, tenzei ik niks doe, dan regelt de warmtepomp dit zelf.

Het script dat ik stuur om het water te verwarmen (En dit ligt natuurlijk puur hoe je je boiler aan stuurt.);

Trigger:
- Actueel vermogen -600W of
- Specifieke tijd, bijv 15:00

Condition:
- Input boolean = on. (helper)

Action (Dit kan natuurlijk ook als script(s), dit heb ik voor mij zelf wel gedaan):
- Set number Stop temperatuur 54
- Delay 30 seconden
- Set number Start temperatuur 52
- Delay 30 seconden
- Set number Start temperatuur 42
- Wait for trigger - Compressor frequentie =< 15 Hz
- Send notification - Water verwarmen gestart
- Delay 120 seconden
- Wait for trigger - Compressor frequentie => 15 Hz
- Delay 30 seconden
- Set number Stop temperatuur 46
- Send notification - Water verwarmen compleet

Mijn acties om de Legionellarun te triggeren bij mijn warmtepomp is alsvolgt (Trigger meest gunstigste moment komt dus nog);

- Set number Periodic heat = 7
- Delay 60 seconden
- Set number Periodic heat = 9

Mijn warmtepomp heeft de mogelijkheid van modbus, waar ik hem op aanstuur, alleen niet een soort knop "Nu verwarmen" "Nu stoppen met verwarmen" of "Verwarm eenmalig tot 55 graden". Zelfs de virtuele knop in de Modbus controller "Compressor blokkeren" en "Verwarmings element blokkeren" werken niet.

Zo doe ik het nu ook ongeveer. Maar ik ben vooral geïnteresseerd naar de automations van @Pejdref

[Septillion]

dotcom87 schreef op vrijdag 30 augustus 2024 @ 12:25:
@Septillion Deel jij toevallig jouw HA configuratie ook op GitHub ofzo?

Nee, op dit moment niet. Zou ik eerst ook nog hele grote opruiming moeten houden En dan eens uitzoeken wat makkelijke manier is voor sanitizing daarvan.