Home Assistant: Open source Python3 home automation - deel 5

[Septillion]

@oZe NL Lijkt me door het plaatje aan de error te zien. Via welke integratie moet dat plaatje er komen? Die al gecontroleerd?

[new_guy]

Staat er bewust geen file extension achter het bestand?

[ Voor 9% gewijzigd door new_guy op 23-04-2025 18:53 ]

[Toppe]

Iemand enig idee?? Ik ben bezig met een blueprint maar hij blijft een notificatie weergeven:

YAML:

blueprint:
  name: Filter Reminder
  description: Create an notification to clean the filter
  domain: automation

  input:
    trigger_time:
      name: Time
      description: Set the time to run the automation.
      selector:
        time:
    target_entity:
      name: Entity
      description: Entity thats need to be controlled.
      selector:
        entity:
          filter:
            - domain: input_datetime
    last_cleaned:
      name: Days
      description: Days between cleaning notification.

variables:
  sensor_to_check: !input target_entity
  days_between: !input last_cleaned

triggers:
  - trigger: time
    at: !input trigger_time
conditions:
  - condition: template
    value_template: |-
      condition: template
      value_template: >
        {% set last_cleaned = states(sensor_to_check) | as_datetime | as_local %}
        {% set nows = now() %}
        {{ (nows - last_cleaned).days > days_between }}
actions:
  - action: notify.persistent_notification
    metadata: {}
    data:
      message: >
        {{ state_attr(sensor_to_check,  'friendly_name') }} is meer dan {{ days_between }} dagen geleden voor het laatst gereinigd!
      title: Filter
mode: single

Vul ik hem handmatig in:

YAML:

{% set last_cleaned = states('input_datetime.airco_filter_gereinigd') | as_datetime | as_local %}
{% set nows = now() %}
{{ (nows - last_cleaned).days > 1 }}

Dan krijg ik netjes true en als ik "1" verhoog naar bijvoorbeeld 10000 dan schiet hij netjes naar false. Kijk er ongetwijfeld overheen maar ik zie hem even niet?

[oZe NL]

new_guy schreef op woensdag 23 april 2025 @ 18:52:
Staat er bewust geen file extension achter het bestand?

Yep, dat is ook hoe de ontwikkelaar van de plugin het beschreven heeft: https://github.com/fuatakgun/eufy_security

Septillion schreef op woensdag 23 april 2025 @ 18:27:
@oZe NL Lijkt me door het plaatje aan de error te zien. Via welke integratie moet dat plaatje er komen? Die al gecontroleerd?

Eufy Security (HACS variant). Afbeelding via de browser is wel direct te benaderen.

[Septillion]

@Toppe In de value_template wil je alleen de waarde renderen, nu heb je daar weer de keys.

Of als dat een error is, je datetime heeft wel werkelijk een date?

[Toppe]

Septillion schreef op woensdag 23 april 2025 @ 20:36:
@Toppe In de value_template wil je alleen de waarde renderen, nu heb je daar weer de keys.

Of als dat een error is, je datetime heeft wel werkelijk een date?

Hij geeft geen error, ik wil daar true/false hebben en zodra het verschil in dagen onder days_between zit dan moet hij géén notificatie geven

[Septillion]

@Toppe Zie je wat je hier dubbel hebt:

YAML:

  - condition: template
    value_template: |-
      condition: template
      value_template: >
        {% set last_cleaned = states(sensor_to_check) | as_datetime | as_local %}
        {% set nows = now() %}
        {{ (nows - last_cleaned).days > days_between }}

Daarnaast is denk ik de input ook altijd eens string dus moet je de dagen nog even omzetten. Zou ik er ook nog beveiliging in zetten dat hij niet leeg mag zijn. En na opruimen van namen kom ik dan (ongetest ) op

YAML:

blueprint:
  name: Filter Reminder
  description: Create an notification to clean the filter
  domain: automation

  input:
    trigger_time:
      name: Time
      description: Set the time to run the automation.
      selector:
        time:
    target_entity:
      name: Entity
      description: Entity thats need to be controlled.
      selector:
        entity:
          filter:
            - domain: input_datetime
    days_between:
      name: Days
      description: Days between cleaning notification.
      selector:
        number:
          min: 0
          max: 99999999999999
          step: 1
          unit_of_measurement: days
          mode: box

variables:
  target_entity: !input target_entity
  days_between: !input days_between

triggers:
  - trigger: time
    at: !input trigger_time
conditions:
  - condition: "{{ has_value(target_entity) and is_number(days_between) }}"
  - condition: template
    value_template: >-
      {% set last_cleaned = states(target_entity) | as_datetime | as_local %}
      {% set nows = now() %}
      {{ (nows - last_cleaned).days > days_between|int(0) }}
actions:
  - action: notify.persistent_notification
    metadata: {}
    data:
      message: >
        {{ state_attr(target_entity,  'friendly_name') }} is meer dan {{ days_between }} dagen geleden voor het laatst gereinigd!
      title: Filter
mode: single

[TheFes]

Septillion schreef op woensdag 23 april 2025 @ 21:20:
@Toppe Zie je wat je hier dubbel hebt:

YAML:

  - condition: template
    value_template: |-
      condition: template
      value_template: >
        {% set last_cleaned = states(sensor_to_check) | as_datetime | as_local %}
        {% set nows = now() %}
        {{ (nows - last_cleaned).days > days_between }}

Daarnaast is denk ik de input ook altijd eens string dus moet je de dagen nog even omzetten. Zou ik er ook nog beveiliging in zetten dat hij niet leeg mag zijn. En na opruimen van namen kom ik dan (ongetest ) op

YAML:

blueprint:
  name: Filter Reminder
  description: Create an notification to clean the filter
  domain: automation

  input:
    trigger_time:
      name: Time
      description: Set the time to run the automation.
      selector:
        time:
    target_entity:
      name: Entity
      description: Entity thats need to be controlled.
      selector:
        entity:
          filter:
            - domain: input_datetime
    days_between:
      name: Days
      description: Days between cleaning notification.
      selector:
        number:
          min: 0
          max: 99999999999999
          step: 1
          unit_of_measurement: days
          mode: box

variables:
  target_entity: !input target_entity
  days_between: !input days_between

triggers:
  - trigger: time
    at: !input trigger_time
conditions:
  - condition: "{{ has_value(target_entity) and is_number(days_between) }}"
  - condition: template
    value_template: >-
      {% set last_cleaned = states(target_entity) | as_datetime | as_local %}
      {% set nows = now() %}
      {{ (nows - last_cleaned).days > days_between|int(0) }}
actions:
  - action: notify.persistent_notification
    metadata: {}
    data:
      message: >
        {{ state_attr(target_entity,  'friendly_name') }} is meer dan {{ days_between }} dagen geleden voor het laatst gereinigd!
      title: Filter
mode: single

Een number input geeft al wel een numerieke waarde terug, die hoef je niet naar int te casten

[hemertje]

hemertje schreef op dinsdag 22 april 2025 @ 18:25:
aangepast naar

YAML:

alias: Afvalmelding
description: Melding dag voor afval
triggers:
  - at: "18:00:00"
    trigger: time
conditions:
  - condition: not
    conditions:
      - condition: state
        entity_id: sensor.afvalinfo_home_trash_type_tomorrow
        state: Geen
actions:
  - data:
      message: "Afval morgen: {{states(\"sensor.afvalinfo_home_trash_type_tomorrow\") }}"
      title: Afval morgen
    action: notify.notify
mode: single

@TheFes

vanavond toch weer een melding op de iPhone "Afval morgen: geen"

[verjager]

hemertje schreef op woensdag 23 april 2025 @ 22:38:
[...]

vanavond toch weer een melding op de iPhone "Afval morgen: geen"

Om 18:00 uur? Toen was je automation denk ik nog niet aangepast, dus was de melding al eerder getriggerd?

Of anders de tracering bekijken?
https://www.home-assistan...n/troubleshooting/#traces

[Septillion]

@hemertje Probeer dan ook eens state: geen (kleine letter).

Als er nu ook geen afval is voor morgen dan kan je ook de conditie testen. Klik op de 3-dots van de state condition => Test. Dan zal je nu ook al "Condition passes" moeten zien. Of als je de not-condition test zou je "condition did not pass" zien.

[TheFes]

hemertje schreef op woensdag 23 april 2025 @ 22:38:
[...]


@TheFes

vanavond toch weer een melding op de iPhone "Afval morgen: geen"

Als dat de melding is, dan is de state geen in plaats van Geen

[djiedjee]

Sinds vandaag heb ik een probleem met het verbinden via duckdns. Met lokaal ip-adres kom ik wel in HA.

Via de browser naar de duckdns, weinig info: Unable to connect to Home Assistant.

Via de companion-app op de telefoon:
De datum van het Home Assistant cetrificaat is ongeldig.

Ik heb de duckdns addon al herstart, dat maakt geen verschil.
Wat kan ik nog meer proberen?

[TheFes]

djiedjee schreef op donderdag 24 april 2025 @ 10:05:
Sinds vandaag heb ik een probleem met het verbinden via duckdns. Met lokaal ip-adres kom ik wel in HA.

Via de browser naar de duckdns, weinig info: Unable to connect to Home Assistant.

Via de companion-app op de telefoon:
De datum van het Home Assistant cetrificaat is ongeldig.

Ik heb de duckdns addon al herstart, dat maakt geen verschil.
Wat kan ik nog meer proberen?

Je ssl certificaat vernieuwen? Hoe heb je DuckDNS ingesteld?

[Ora et Labora]

hemertje schreef op woensdag 23 april 2025 @ 22:38:
[...]


@TheFes

vanavond toch weer een melding op de iPhone "Afval morgen: geen"

Ik heb hem andersom gemaakt, dus de state.

YAML:

alias: Afval-send-notification
description: ""
triggers:
  - at: "20:00:00"
    trigger: time
conditions:
  - condition: or
    conditions:
      - condition: state
        entity_id: sensor.afvalwijzer_tomorrow_3
        state: gft
      - condition: state
        entity_id: sensor.afvalwijzer_tomorrow_3
        state: restafval
      - condition: state
        entity_id: sensor.afvalwijzer_tomorrow_3
        state: pmd
      - condition: state
        entity_id: sensor.afvalwijzer_tomorrow_3
        state: papier
  - condition: state
    entity_id: input_boolean.vakantie
    state: "off"
actions:
  - data: {}
    action: script.afval
mode: single

De state lees ik uiteraard uit bij Developper tools.

[hemertje]

verjager schreef op woensdag 23 april 2025 @ 22:43:
[...]

Om 18:00 uur? Toen was je automation denk ik nog niet aangepast, dus was de melding al eerder getriggerd?

Of anders de tracering bekijken?
https://www.home-assistan...n/troubleshooting/#traces

had de aanpassing een dag eerder gedaan

insdag 22 april 2025 18:25

[hemertje]

TheFes schreef op donderdag 24 april 2025 @ 08:59:
[...]


Als dat de melding is, dan is de state geen in plaats van Geen

aangepast naar "geen"

[hemertje]

Septillion schreef op woensdag 23 april 2025 @ 22:47:
@hemertje Probeer dan ook eens state: geen (kleine letter).

Als er nu ook geen afval is voor morgen dan kan je ook de conditie testen. Klik op de 3-dots van de state condition => Test. Dan zal je nu ook al "Condition passes" moeten zien. Of als je de not-condition test zou je "condition did not pass" zien.

bij het "And if (optional)" gedeelte van de Afvalmelding kan ik via de 3 dots testen

ik krijg dan "Condition did not pass"

[Septillion]

@hemertje De eerste optie eronder is de not-condition. Dus als die "Condition did not pass" is en morgen is er geen afval dan klopt het nu

[hemertje]

Septillion schreef op donderdag 24 april 2025 @ 12:27:
@hemertje De eerste optie eronder is de not-condition. Dus als die "Condition did not pass" is en morgen is er geen afval dan klopt het nu

we gaan het meemaken

ik begrijp dat de wijze van @Ora et Labora hetzelfde doet maar dan specifiek per regel uitgeschreven?

[TheFes]

hemertje schreef op donderdag 24 april 2025 @ 13:18:
[...]


we gaan het meemaken

ik begrijp dat de wijze van @Ora et Labora hetzelfde doet maar dan specifiek per regel uitgeschreven?

Jij heb nu een condition dat je de notificatie wil sturen als de state NIET gelijk aan geen is.
@Ora et Labora heeft een condition dat de state gelijk aan papier OF restagval OF pmd OF papier moet zijn.

Uiteindelijk komt het beide op hetzelfde neer.

[hemertje]

TheFes schreef op donderdag 24 april 2025 @ 13:44:
[...]


Jij heb nu een condition dat je de notificatie wil sturen als de state NIET gelijk aan geen is.
@Ora et Labora heeft een condition dat de state gelijk aan papier OF restagval OF pmd OF papier moet zijn.

Uiteindelijk komt het beide op hetzelfde neer.

thx voor de bevestiging, zo had ik het inderdaad ook gelezen

[djiedjee]

Vernieuwen zou automatisch moeten gaan dacht ik.
"The number of seconds to wait before updating DuckDNS subdomains and renewing Let's Encrypt certificates" staat op 300 seconden.

Kan ik dat handmatig ergens doen?


Edit:

ik heb een aantal weken geleden een HA backup teruggezet. Kan het zijn dat ik daarmee de refresh om zeep help geholpen en dat hij nu (na een maand of zo) verlopen is?


Edit2:
details van het certificaat gevonden.
Verleend op vrijdag 24 januari 2025 om 05:54:58
Verloopt op donderdag 24 april 2025 om 06:54:57

Inderdaad verlopen dus.

TheFes schreef op donderdag 24 april 2025 @ 10:56:
[...]


Je ssl certificaat vernieuwen? Hoe heb je DuckDNS ingesteld?

[ Voor 30% gewijzigd door djiedjee op 24-04-2025 16:05 ]

[boefje79]

Hey all,

Newbie ogv HA hier.

Heb keurig de data voor vermogen en water in HA gekregen met als bron homewizards p1-meter.

Bij gas echter komt er alleen een totaalachtig getal en kan ik alleen de entiteit gasmeter vinden die daarmee komt.

Enig idee hoe ik actueel verbruik en geschiedenis van verbruik in ha kan krijgen obv de P1?

(Bij vermogen heb ik bv totaal actueel en per fase maar voor gas 1 optie)

[ Voor 10% gewijzigd door boefje79 op 24-04-2025 15:42 ]

[Dutchess_Nicole]

boefje79 schreef op donderdag 24 april 2025 @ 15:39:
Hey all,

Newbie ogv HA hier.

Heb keurig de data voor vermogen en water in HA gekregen met als bron homewizards p1-meter.

Bij gas echter komt er alleen een totaalachtig getal en kan ik alleen de entiteit gasmeter vinden die daarmee komt.

Enig idee hoe ik actueel verbruik en geschiedenis van verbruik in ha kan krijgen obv de P1?

(Bij vermogen heb ik bv totaal actueel en per fase maar voor gas 1 optie)

Vermogen is niet echt nuttig voor HA. Iig niet als je dat in het Energy Dashboard wilt hebben. Daarvoor wil je namelijk energie entities hebben. Het liefst degenen die altijd optellen.

Gas is hierbij dus juist goed, want dat is de entity die je al hebt. Als je voor water en stroom ook de altijd optellenden entities kan vinden kan je die toevoegen bij het Energy Dashboard en dan zou het verder prima moeten werken.

[boefje79]

Dutchess_Nicole schreef op donderdag 24 april 2025 @ 15:46:
[...]


Vermogen is niet echt nuttig voor HA. Iig niet als je dat in het Energy Dashboard wilt hebben. Daarvoor wil je namelijk energie entities hebben. Het liefst degenen die altijd optellen.

Gas is hierbij dus juist goed, want dat is de entity die je al hebt. Als je voor water en stroom ook de altijd optellenden entities kan vinden kan je die toevoegen bij het Energy Dashboard en dan zou het verder prima moeten werken.

Ik heb wat grillen in afname van gas. Dat zie ik goed terug in homewizard maar in bv tado tbv de cv-aansturing zie ik geen oorzaal voor die afname.

Ik kreeg de tip om dmv meer inzicht vanuit HA op onderzoek uit te geen wat die grillen in afname gas kan veroorzaken.

Dus vandaar dat ik voor bv 24-uur/afgelopen week inzage wil in gas/water/energie zodat ik die over andere getallen heen kan leggen om op zoek te gaan naar de oorzaak

[Gizz]

boefje79 schreef op donderdag 24 april 2025 @ 15:39:
Bij gas echter komt er alleen een totaalachtig getal en kan ik alleen de entiteit gasmeter vinden die daarmee komt.

Dat is de enige meetwaarde voor gas die je via P1 uit je meter krijgt. Je mist dus niets

Enig idee hoe ik actueel verbruik

Niet. Of in ieder geval niet accuraat. Bij een DSMR5.0 meter wordt de gasstand 1x per 5 minuten doorgegeven.

Dat zou je in HA kunnen omrekenen naar een soort gemiddeld aantal liter gas per seconde tijdens de laatste meetinterval van 5 minuten (berekening: (nieuwe meterstand - vorige meterstand)/300 * 1000), maar ik vraag me af wat je daar in de praktijk aan hebt?

en geschiedenis van verbruik in ha kan krijgen obv de P1?

Dat gaat vanzelf nu HA je data binnenkrijgt. Verder terugkijken in het verleden, voordat HA data kreeg, kan natuurlijk niet.

Het is handig om het ingebouwde energy dashboard te gebruiken binnen HA voor mooie overzichten.

[HuismAndré]

boefje79 schreef op donderdag 24 april 2025 @ 16:00:
[...]


Ik heb wat grillen in afname van gas. Dat zie ik goed terug in homewizard maar in bv tado tbv de cv-aansturing zie ik geen oorzaal voor die afname.

Ik kreeg de tip om dmv meer inzicht vanuit HA op onderzoek uit te geen wat die grillen in afname gas kan veroorzaken.

Een veel voorkomende oorzaak is het pendelen van je CV ketel. Als je de branderstatus uit kunt lezen (zoals bij Intergas ketels) dan kun je daar wel zien of de ketel wel of niet pendelt. Ook aan de temperatuur van het CV-Water kun je zien of de ketel pendelt. Overigens is pendelen geen ramp (maar het is niet verkeerd om te werken richting een minimalisatie ervan). Zie ook de CV Tuning topics.

[djiedjee]

@TheFes
Ik ben verder aan het pielen geweest. Duckdns en nginx verwijderd en herinstalled.

log van duckdns geeft een melding:

code:

s6-rc: info: service s6rc-oneshot-runner: starting
s6-rc: info: service s6rc-oneshot-runner successfully started
s6-rc: info: service fix-attrs: starting
s6-rc: info: service fix-attrs successfully started
s6-rc: info: service legacy-cont-init: starting
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service duckdns: starting
s6-rc: info: service duckdns successfully started
s6-rc: info: service legacy-services: starting
s6-rc: info: service legacy-services successfully started
# INFO: Using main config file /data/workdir/config
+ Account already registered!
[16:36:12] INFO: Starting DuckDNS...
[16:36:12] INFO: Renew certificate for domains: XXXXXX.duckdns.org and aliases: 
# INFO: Using main config file /data/workdir/config
Processing XXXXXX.duckdns.org
 + Signing domains...
 + Generating private key...
 + Generating signing request...
 + Requesting new certificate order from CA...
 + Received 1 authorizations URLs from the CA
 + Handling authorization for XXXXXX.duckdns.org
 + 1 pending challenge(s)
 + Deploying challenge tokens...
Terminated
ERROR: deploy_challenge hook returned with non-zero exit code

NGINX geeft:

code:

2025/04/24 16:44:03 [error] 128#128: *19 upstream prematurely closed connection while reading response header from upstream

Ik mis echt wat kennis op dit gebied!

[boefje79]

HuismAndré schreef op donderdag 24 april 2025 @ 16:24:
[...]

Een veel voorkomende oorzaak is het pendelen van je CV ketel. Als je de branderstatus uit kunt lezen (zoals bij Intergas ketels) dan kun je daar wel zien of de ketel wel of niet pendelt. Ook aan de temperatuur van het CV-Water kun je zien of de ketel pendelt. Overigens is pendelen geen ramp (maar het is niet verkeerd om te werken richting een minimalisatie ervan). Zie ook de CV Tuning topics.

Thanks! Op dagen dat dit gedrag er is is er tussen 02:00 en 06:00 uur al €3,50 doorheen dus dat telt aardig op…wel fijn om te weten dat de ketel er op zich wel tegen kan.

Maar zou het graag achterhalen en voorkomen, want vreemd verschijnsel

[JanHenk]

djiedjee schreef op donderdag 24 april 2025 @ 16:48:

ERROR: deploy_challenge hook returned with non-zero exit code

Een korte google zoekopdracht op deze melding, geeft aan dat je DuckDNS token niet goed hebt gekopieerd. Let op eventuele spaties aan de voor- of achterkant die meekomen met dubbelklik (selecteren).

[djiedjee]

jij bent ook van alle markten thuis! Laadpalen en HA. Geen toeval misschien

Ik ga het eens proberen. Ik had hem via de tekst editor gekopieerd, dacht ik....


Edit: dit maakt inderdaad geen verschil. Ik had het in eerste instantie ook niet gewijzigd, en tot gisteren werkte dat.


Edit:

in YAML-mode zie je vreemde karakters blijkbaar niet.
In de GUI even een fake token ingevuld en gesaved, daarna weer opnieuw gekopieerd vanuit de tekst editor. Nou gaat hij verder.

Thanks!!

JanHenk schreef op donderdag 24 april 2025 @ 16:53:
[...]


Een korte google zoekopdracht op deze melding, geeft aan dat je DuckDNS token niet goed hebt gekopieerd. Let op eventuele spaties aan de voor- of achterkant die meekomen met dubbelklik (selecteren).

[ Voor 40% gewijzigd door djiedjee op 24-04-2025 17:38 ]

[HuismAndré]

boefje79 schreef op donderdag 24 april 2025 @ 16:49:
[...]


Thanks! Op dagen dat dit gedrag er is is er tussen 02:00 en 06:00 uur al €3,50 doorheen dus dat telt aardig op…wel fijn om te weten dat de ketel er op zich wel tegen kan.

Maar zou het graag achterhalen en voorkomen, want vreemd verschijnsel

Niks vreemds aan. Het gros van de CV ketels is véél te groot voor het huis dat het moet verwarmen (maar vaak wordt dat zo gekozen vanwege het warmwatercomfort). Zelf heb ik een paar jaar geleden gekozen voor een Intergas Xtreme 30 (die terug kan regelen tot 3.6kW). En zelfs dat is teveel als alleen de vloerverwarming boven wordt aangesproken (3kW). Veel CV ketels kunnen echter niet verder terugregelen dan 6-7kW (en dan zit je in een modern huis dus absoluut te pendelen zonder dat je daar wat aan kan doen).

Overigens is 3,5 euro (uitgaand van 1,3 euro per m3) in 4 uur tijd (midden in de nacht) ook weer niet zo idioot veel. Dat komt neer op 0,67 kuub (of ca. 6.7kWh) per uur. Als je huis suboptimaal geïsoleerd is (jaren 90 huis of ouder, zonder WTW) is het zelfs heel normaal.

[Toppe]

Septillion schreef op woensdag 23 april 2025 @ 21:20:
@Toppe Zie je wat je hier dubbel hebt:

YAML:

  - condition: template
    value_template: |-
      condition: template
      value_template: >
        {% set last_cleaned = states(sensor_to_check) | as_datetime | as_local %}
        {% set nows = now() %}
        {{ (nows - last_cleaned).days > days_between }}

Daarnaast is denk ik de input ook altijd eens string dus moet je de dagen nog even omzetten. Zou ik er ook nog beveiliging in zetten dat hij niet leeg mag zijn. En na opruimen van namen kom ik dan (ongetest ) op

YAML:

blueprint:
  name: Filter Reminder
  description: Create an notification to clean the filter
  domain: automation

  input:
    trigger_time:
      name: Time
      description: Set the time to run the automation.
      selector:
        time:
    target_entity:
      name: Entity
      description: Entity thats need to be controlled.
      selector:
        entity:
          filter:
            - domain: input_datetime
    days_between:
      name: Days
      description: Days between cleaning notification.
      selector:
        number:
          min: 0
          max: 99999999999999
          step: 1
          unit_of_measurement: days
          mode: box

variables:
  target_entity: !input target_entity
  days_between: !input days_between

triggers:
  - trigger: time
    at: !input trigger_time
conditions:
  - condition: "{{ has_value(target_entity) and is_number(days_between) }}"
  - condition: template
    value_template: >-
      {% set last_cleaned = states(target_entity) | as_datetime | as_local %}
      {% set nows = now() %}
      {{ (nows - last_cleaned).days > days_between|int(0) }}
actions:
  - action: notify.persistent_notification
    metadata: {}
    data:
      message: >
        {{ state_attr(target_entity,  'friendly_name') }} is meer dan {{ days_between }} dagen geleden voor het laatst gereinigd!
      title: Filter
mode: single

Dit werkt niet:

YAML:

Message malformed: Unexpected value for condition: '{{ has_value(target_entity) and is_number(days_between) }}'. Expected and, device, not, numeric_state, or, state, sun, template, time, trigger, zone @ data['conditions'][0]

Onderstaand toevoegen werkt:

YAML:

  - condition: template
    value_template: >-
      {{ has_value(target_entity) and is_number(days_between) }}

Maar dan blijft hij bij 1 alsook bij 10000 een melding geven

[Septillion]

@Toppe Mijn fout, nooit echt opgevallen maar de shorthand is dus conditions :+Dus:

YAML:

conditions: '{{ has_value(target_entity) and is_number(days_between) }}'

Maar wat bedoel je met 1 en 10000 melding? Of eigenlijk, wat zijn de waardes die je nu gebruikt?

[Toppe]

Septillion schreef op donderdag 24 april 2025 @ 19:22:
@Toppe Mijn fout, nooit echt opgevallen maar de shorthand is dus conditions :+Dus:

YAML:

conditions: '{{ has_value(target_entity) and is_number(days_between) }}'

Maar wat bedoel je met 1 en 10000 melding? Of eigenlijk, wat zijn de waardes die je nu gebruikt?

Of "Days" nu 1 of 100 is, de melding blijft komen:

code:

Filter
Airco filter is meer dan 100 dagen geleden voor het laatst gereinigd!

1 seconde geleden

Datum van de sensor is 28-2-2025, dat is 55 dagen geleden dus bij 100 zou hij geen melding mogen geven

[Septillion]

@Toppe Wat is het totaalplaatje nu waarmee je test?

[Toppe]

Septillion schreef op donderdag 24 april 2025 @ 19:25:
@Toppe Wat is het totaalplaatje nu waarmee je test?

YAML:

blueprint:
  name: Filter Reminder
  description: Create an notification to clean the filter
  domain: automation

  input:
    trigger_time:
      name: Time
      description: Set the time to run the automation.
      selector:
        time:
    target_entity:
      name: Entity
      description: Entity thats need to be controlled.
      selector:
        entity:
          filter:
            - domain: input_datetime
    days_between:
      name: Days between
      description: Days between cleaning notification.
      selector:
        number:
          min: 0
          max: 99999999999999
          step: 1
          unit_of_measurement: days
          mode: box

variables:
  target_entity: !input target_entity
  days_between: !input days_between

triggers:
  - trigger: time
    at: !input trigger_time
conditions:
  - condition: template
    value_template: >-
      {{ has_value(target_entity) and is_number(days_between) }}
  - condition: template
    value_template: >-
      {% set last_cleaned = states(target_entity) | as_datetime | as_local %}
      {% set nows = now() %}
      {{ (nows - last_cleaned).days > days_between|int(0) }}
actions:
  - action: notify.persistent_notification
    metadata: {}
    data:
      message: >
        {{ state_attr(target_entity,  'friendly_name') }} is meer dan {{ days_between }} dagen geleden voor het laatst gereinigd!
      title: Filter
mode: single

Het maakt niet uit of ik op regel die int(0) weghaal of niet



Dit is false

YAML:

      {% set last_cleaned = states('input_datetime.airco_filter_gereinigd') | as_datetime | as_local %}
      {% set nows = now() %}
      {{ (nows - last_cleaned).days > 100|int(0) }}

Dit is true

YAML:

      {% set last_cleaned = states('input_datetime.airco_filter_gereinigd') | as_datetime | as_local %}
      {% set nows = now() %}
      {{ (nows - last_cleaned).days > 10|int(0) }}

Dit even bij ontwikkelaarshulpmiddelen geprobeerd:

Resultaat true/true:

YAML:

{% set target_entity = 'input_datetime.airco_filter_gereinigd' %}
{% set days_between = '10' %}
{{ has_value(target_entity) and is_number(days_between) }}
{% set last_cleaned = states(target_entity) | as_datetime | as_local %}
{% set nows = now() %}
{{ (nows - last_cleaned).days > days_between|int(0) }}

Resultaat true/false:

YAML:

{% set target_entity = 'input_datetime.airco_filter_gereinigd' %}
{% set days_between = '100' %}
{{ has_value(target_entity) and is_number(days_between) }}
{% set last_cleaned = states(target_entity) | as_datetime | as_local %}
{% set nows = now() %}
{{ (nows - last_cleaned).days > days_between|int(0) }}

Regel 37 t/m 45 aangepast voor dit:

YAML:

conditions:
  condition: and
  conditions:
    - condition: template
      value_template: "{{ has_value(target_entity) and is_number(days_between) }}"
    - condition: template
      value_template: |-
        {% set last_cleaned = states(target_entity) | as_datetime | as_local %}
        {% set nows = now() %}
        {{ (nows - last_cleaned).days > days_between|int(0) }}

Werkt ook niet

[ Voor 36% gewijzigd door Toppe op 24-04-2025 19:41 ]

[Septillion]

@Toppe Je weet heeeeel zeker dat je in de blueprint automation ook airco_filter_gereinigd gebruikt? Anders even de yaml daarvan posten.

En welke waarde staat er in airco_filter_gereinigd?

Namelijk hier even een aangepaste versie gedraaid en die werkt perfec.

Blueprint:

YAML:

blueprint:
  name: Toppe Filter Reminder
  description: Create an notification to clean the filter
  domain: automation

  input:
    trigger_time:
      name: Time
      description: Set the time to run the automation.
      selector:
        time:
    target_entity:
      name: Entity
      description: Entity thats need to be controlled.
      selector:
        entity:
          filter:
            - domain: input_datetime
    days_between:
      name: Days between
      description: Days between cleaning notification.
      selector:
        number:
          min: 0
          max: 99999999999999
          step: 1
          unit_of_measurement: days
          mode: box

variables:
  target_entity: !input target_entity
  days_between: !input days_between

triggers:
  - trigger: time
    at: !input trigger_time
  - trigger: state
    entity_id:
      - input_button.toppe_run
    to: null
conditions:
  - condition: template
    value_template: >-
      {{ has_value(target_entity) and is_number(days_between) }}
  - condition: template
    value_template: >-
      {% set last_cleaned = states(target_entity) | as_datetime | as_local %}
      {% set nows = now() %}
      {{ (nows - last_cleaned).days > days_between|int(0) }}
actions:
  - action: notify.persistent_notification
    metadata: {}
    data:
      message: >
        {{ now() }}
      title: Triggered
  - action: notify.persistent_notification
    metadata: {}
    data:
      message: >
        {{ state_attr(target_entity,  'friendly_name') }} is meer dan {{ days_between }} dagen geleden voor het laatst gereinigd!
      title: Filter
mode: single

Automation

YAML:

alias: Toppe Filter Reminder
description: ""
use_blueprint:
  path: toppe/toppe_filter_reminder.yaml
  input:
    trigger_time: "17:00:00"
    target_entity: input_datetime.toppe_cleaned
    days_between: 10

Helper:

YAML:

has_date: true
has_time: false
editable: true
year: 2025
month: 4
day: 14
timestamp: 1744581600
friendly_name: Toppe Cleaned

[Toppe]

Septillion schreef op donderdag 24 april 2025 @ 20:32:
@Toppe Je weet heeeeel zeker dat je in de blueprint automation ook airco_filter_gereinigd gebruikt? Anders even de yaml daarvan posten.

En welke waarde staat er in airco_filter_gereinigd?

Namelijk hier even een aangepaste versie gedraaid en die werkt perfec.

Blueprint:

YAML:

blueprint:
  name: Toppe Filter Reminder
  description: Create an notification to clean the filter
  domain: automation

  input:
    trigger_time:
      name: Time
      description: Set the time to run the automation.
      selector:
        time:
    target_entity:
      name: Entity
      description: Entity thats need to be controlled.
      selector:
        entity:
          filter:
            - domain: input_datetime
    days_between:
      name: Days between
      description: Days between cleaning notification.
      selector:
        number:
          min: 0
          max: 99999999999999
          step: 1
          unit_of_measurement: days
          mode: box

variables:
  target_entity: !input target_entity
  days_between: !input days_between

triggers:
  - trigger: time
    at: !input trigger_time
  - trigger: state
    entity_id:
      - input_button.toppe_run
    to: null
conditions:
  - condition: template
    value_template: >-
      {{ has_value(target_entity) and is_number(days_between) }}
  - condition: template
    value_template: >-
      {% set last_cleaned = states(target_entity) | as_datetime | as_local %}
      {% set nows = now() %}
      {{ (nows - last_cleaned).days > days_between|int(0) }}
actions:
  - action: notify.persistent_notification
    metadata: {}
    data:
      message: >
        {{ now() }}
      title: Triggered
  - action: notify.persistent_notification
    metadata: {}
    data:
      message: >
        {{ state_attr(target_entity,  'friendly_name') }} is meer dan {{ days_between }} dagen geleden voor het laatst gereinigd!
      title: Filter
mode: single

Automation

YAML:

alias: Toppe Filter Reminder
description: ""
use_blueprint:
  path: toppe/toppe_filter_reminder.yaml
  input:
    trigger_time: "17:00:00"
    target_entity: input_datetime.toppe_cleaned
    days_between: 10

Helper:

YAML:

has_date: true
has_time: false
editable: true
year: 2025
month: 4
day: 14
timestamp: 1744581600
friendly_name: Toppe Cleaned

Ja gebruik die, zeker weten. Anders doet hij ook niet het juist aantal dagen weergeven

[Septillion]

Toppe schreef op donderdag 24 april 2025 @ 20:46:
[...]
Anders doet hij ook niet het juist aantal dagen weergeven

Jawel, want je geeft alleen "Days between" weer...

Dus ik zet mijn geld in op dat je tijdens het testen in Dev tools niet hetzelfde entiteit gebruikt als in de automation Stop de klok!

[Toppe]

Septillion schreef op donderdag 24 april 2025 @ 20:51:
[...]

Jawel, want je geeft alleen "Days between" weer...

Dus ik zet mijn geld in op dat je tijdens het testen in Dev tools niet hetzelfde entiteit gebruikt als in de automation Stop de klok!

[Septillion]

@Toppe yaml is makkelijker maar goed

Maar je datum is meer dan 10 dagen geleden, evalueert ook naar true in dev tools. Dus toch gewoon correct dat je de melding krijgt?

[Toppe]

Septillion schreef op donderdag 24 april 2025 @ 21:08:
@Toppe yaml is makkelijker maar goed

Maar je datum is meer dan 10 dagen geleden, evalueert ook naar true in dev tools. Dus toch gewoon correct dat je de melding krijgt?

Maar als ik hem op 100 zet dan wordt het true/false maar krijg ik toch een bericht.

Hier staat nog meer: Toppe in "Home Assistant: Open source Python3 home automation - deel 5"

[ Voor 14% gewijzigd door Toppe op 24-04-2025 21:19 ]

[Septillion]

@Toppe Ik kan het hier niet reproduceren. Net gedaan:

helper

YAML:

has_date: true
has_time: false
editable: true
year: 2025
month: 2
day: 28
timestamp: 1740697200
friendly_name: Toppe Cleaned

Automation:

YAML:

alias: Toppe Filter Reminder
description: ""
use_blueprint:
  path: toppe/toppe_filter_reminder.yaml
  input:
    trigger_time: "21:22:00"
    target_entity: input_datetime.toppe_cleaned
    days_between: 100

En zelfde blueprint

YAML:

blueprint:
  name: Toppe Filter Reminder
  description: Create an notification to clean the filter
  domain: automation

  input:
    trigger_time:
      name: Time
      description: Set the time to run the automation.
      selector:
        time:
    target_entity:
      name: Entity
      description: Entity thats need to be controlled.
      selector:
        entity:
          filter:
            - domain: input_datetime
    days_between:
      name: Days between
      description: Days between cleaning notification.
      selector:
        number:
          min: 0
          max: 99999999999999
          step: 1
          unit_of_measurement: days
          mode: box

variables:
  target_entity: !input target_entity
  days_between: !input days_between

triggers:
  - trigger: time
    at: !input trigger_time
  - trigger: state
    entity_id:
      - input_button.toppe_run
    to: null
conditions:
  - condition: template
    value_template: >-
      {{ has_value(target_entity) and is_number(days_between) }}
  - condition: template
    value_template: >-
      {% set last_cleaned = states(target_entity) | as_datetime | as_local %}
      {% set nows = now() %}
      {{ (nows - last_cleaned).days > days_between|int(0) }}
actions:
  - action: notify.persistent_notification
    metadata: {}
    data:
      message: >
        {{ now() }}
      title: Triggered
  - action: notify.persistent_notification
    metadata: {}
    data:
      message: >
        {{ state_attr(target_entity,  'friendly_name') }} is meer dan {{ days_between }} dagen geleden voor het laatst gereinigd!
      title: Filter
mode: single

En daar krijg ik geen notification.

Je hebt niet nog ergens een automation draaien van voor je er een blueprint van had gemaakt toch?

[Toppe]

Septillion schreef op donderdag 24 april 2025 @ 21:25:
@Toppe Ik kan het hier niet reproduceren. Net gedaan:

helper

YAML:

has_date: true
has_time: false
editable: true
year: 2025
month: 2
day: 28
timestamp: 1740697200
friendly_name: Toppe Cleaned

Automation:

YAML:

alias: Toppe Filter Reminder
description: ""
use_blueprint:
  path: toppe/toppe_filter_reminder.yaml
  input:
    trigger_time: "21:22:00"
    target_entity: input_datetime.toppe_cleaned
    days_between: 100

En zelfde blueprint

YAML:

blueprint:
  name: Toppe Filter Reminder
  description: Create an notification to clean the filter
  domain: automation

  input:
    trigger_time:
      name: Time
      description: Set the time to run the automation.
      selector:
        time:
    target_entity:
      name: Entity
      description: Entity thats need to be controlled.
      selector:
        entity:
          filter:
            - domain: input_datetime
    days_between:
      name: Days between
      description: Days between cleaning notification.
      selector:
        number:
          min: 0
          max: 99999999999999
          step: 1
          unit_of_measurement: days
          mode: box

variables:
  target_entity: !input target_entity
  days_between: !input days_between

triggers:
  - trigger: time
    at: !input trigger_time
  - trigger: state
    entity_id:
      - input_button.toppe_run
    to: null
conditions:
  - condition: template
    value_template: >-
      {{ has_value(target_entity) and is_number(days_between) }}
  - condition: template
    value_template: >-
      {% set last_cleaned = states(target_entity) | as_datetime | as_local %}
      {% set nows = now() %}
      {{ (nows - last_cleaned).days > days_between|int(0) }}
actions:
  - action: notify.persistent_notification
    metadata: {}
    data:
      message: >
        {{ now() }}
      title: Triggered
  - action: notify.persistent_notification
    metadata: {}
    data:
      message: >
        {{ state_attr(target_entity,  'friendly_name') }} is meer dan {{ days_between }} dagen geleden voor het laatst gereinigd!
      title: Filter
mode: single

En daar krijg ik geen notification.

Je hebt niet nog ergens een automation draaien van voor je er een blueprint van had gemaakt toch?

Nee en ik gebruik ook gewoon de knop ‘Actie uitvoeren’, slaat die mogelijk de condities over?

[Septillion]

@Toppe ja....... Net als in een reguliere automation..... Vandaar dat de knop "run actions" heet en niet "run automation"

Vandaar mijn alternatieve trigger in mijn test

[ Voor 28% gewijzigd door Septillion op 25-04-2025 19:49 ]

[new_guy]

hemertje schreef op donderdag 24 april 2025 @ 13:46:
[...]


thx voor de bevestiging, zo had ik het inderdaad ook gelezen

Iets om rekening mee te houden door het op deze wijze te doen, voor die 2x in het jaar dat je kerstboom opgehaald kan worden (zo werkt het hier in Utrecht bijvoorbeeld) krijg je nu dus geen melding.

[hemertje]

new_guy schreef op vrijdag 25 april 2025 @ 08:53:
[...]

Iets om rekening mee te houden door het op deze wijze te doen, voor die 2x in het jaar dat je kerstboom opgehaald kan worden (zo werkt het hier in Utrecht bijvoorbeeld) krijg je nu dus geen melding.

Idd, wat je niet opneemt krijg je ook geen melding van

[Rouwette]

DJ-Promo schreef op vrijdag 25 april 2025 @ 23:06:
Misschien niet helemaal een HA vraag maar ik wil in een bestaande lamp met 3x GU10 lampjes die ik kan dimmen. Een Shelly dimmer voor achter de schakelaar en 3 dimbare spotjes is een stuk duurder dan 3x een Shelly Duo GU10 spotje die je ook kan dimmen. Als ik er daar 3 van installeer kan ik die dan tegelijk dimmen. Anders is optie 1 wel een betere optie.

Vast wel, hier op de badkamer, iCasa zigbee dimmer met goedkope dimbare spotjes.

[Toppe]

Septillion schreef op donderdag 24 april 2025 @ 21:28:
@Toppe ja....... Net als in een reguliere automation..... Vandaar dat de knop "run actions" heet en niet "run automation"

Vandaar mijn alternatieve trigger in mijn test

Lol, inderdaad, werkt nu dikke prima. Even een button input toegevoegd zodat je hem ook handmatig kan uitvoeren

[ocmer]

Tibs schreef op vrijdag 22 maart 2024 @ 15:50:
[...]


Lap, mijn tuya account is expired...

Geprobeerd met de native Tuya integratie en de smart life app maar ik zie veel minder entiteiten in HA.

Ik probeer localtuya aan de praat te krijgen om mijn warmtepomp aan te sturen, maar het lukt me niet om de local_key te achterhalen; ik denk door hetzelfde probleem als hierboven.

De native Tuya integratie in HA krijg ik wel aan de praat via de QR-code; maar is maar heel beperkt. Localtuya kan meer maar vereist een local_key. Die local key is voor zover ik weet alleen op te halen als je een cloud abonnement hebt. Daarvoor kan je eenmalig een trail abonnement nemen; maar die is bij mij al verlopen. ("Failed to retrieve device list. Error 28841002: No permissions. Your subscription to cloud development plan has expired.")

Als ik de chatbot van Tuya vraag krijg ik zelfs "If you're unable to find the Local Key for your heat pump, it's likely because Tuya has paused providing Local Keys for personal use due to security concerns. This measure helps protect devices from potential hacking risks. Unfortunately, there are no direct alternatives provided by Tuya at the moment. It's recommended to keep an eye on Tuya's official resources for any updates or changes regarding this policy. "

Is er een andere manier om localtuya draaiend te krijgen zonder Tuya cloud abonnement?

[Cimpel]

ocmer schreef op zaterdag 26 april 2025 @ 08:40:
[...]

Is er een andere manier om localtuya draaiend te krijgen zonder Tuya cloud abonnement?

Probeer Tuya Local eens.

[hemertje]

Ik krijg de melding in HA dat er een Tuya device gevonden is maar heb de laatste maanden niets toegevoegd!?

Hoe kom ik erachter wat er gevonden is?

[ocmer]

Cimpel schreef op zaterdag 26 april 2025 @ 10:16:
[...]

Probeer Tuya Local eens.

Je bedoelt https://github.com/make-all/tuya-local neem ik aan? Het lukt me niet om die in HACS te vinden en via de link installeren lukt ook niet (HACS blijft leeg met een spinner)

Volgens de documentatie heeft ook Tuya-local de local_key nodig; dus daarmee zal het ook niet lukken.

[Stef012]

Goedemiddag,

Vanmorgen kwam ik erachter dat ik mijn geschiedenis van het enegy dashboard kwijt ben!
Ik heb mijn systeem sinds begin 2024 draaien en zie nu in de geschiedenis dat de data vóór 22 april weg is...

HA maakt netjes backups van de data dus ik zou een oudere backup terug kunnen zetten. In de logboek zie ik het onderstaande terug;
2025-04-22 04:15:14.837 ERROR (Recorder) [homeassistant.components.recorder.core] Unrecoverable sqlite3 database corruption detected: (sqlite3.DatabaseError) database disk image is malformed

Is er een manier om data van de afgelopen dagen met de geschiedenis samen te voegen?

[sus]

nav deze: nieuws: Google stopt verkoop Nest-thermostaten in Europa

Worden die inmiddels al ondersteund in HA? Toen ik hem destijds kocht niet en ook een paar jaar geleden kreeg ik hem niet aan de gang.

Ik kom wel her en der wat projectjes tegen, maar ik krijg nergens de bevestiging dat die oudere - origineel Nest, voor de overname - nu werken.

Ik heb deze unit:

[ Voor 29% gewijzigd door sus op 26-04-2025 13:52 ]

[hemertje]

@Stef012

Voor zover ik begrepen heb “onthoudt” HA enkel de gegevens van de laatste 7 dagen, dus dit kan kloppen met wat je aangeeft

Ik ben zelf ook op zoek naar een oplossing om dit langdurig in een database op te slaan

Ik denk dan aan Influx met Grafana om het ook weer zichtbaar te maken in een grafiek

Wie heeft er tips?

[Stef012]

hemertje schreef op zaterdag 26 april 2025 @ 13:49:
@Stef012

Voor zover ik begrepen heb “onthoudt” HA enkel de gegevens van de laatste 7 dagen, dus dit kan kloppen met wat je aangeeft

Ik ben zelf ook op zoek naar een oplossing om dit langdurig in een database op te slaan

Ik denk dan aan Influx met Grafana om het ook weer zichtbaar te maken in een grafiek

Wie heeft er tips?

Het gaat bij mij om mijn energiedashboard. Deze kon ik tot voor kort nog de gehele uptime terugzien, nu alleen de afgelopen dagen. Ik ben bang dat ik terug moet naar mijn laatste backup voordat dit foutging dan ben ik alleen de afgelopen dagen kwijt..

[RobertMe]

hemertje schreef op zaterdag 26 april 2025 @ 13:49:
@Stef012

Voor zover ik begrepen heb “onthoudt” HA enkel de gegevens van de laatste 7 dagen, dus dit kan kloppen met wat je aangeeft

Dit klopt niet. De recorder houdt alle gegevens bij en doet dit, ik meen, voor 10 dagen (maar kan ook 7 zijn), en dit is instelbaar.
Echter gebruikt het energy dashboard niet de recorder maar de long term statistics. En die long term statistics worden oneindig bewaard. Waarbij de long term statistics in dit geval (van verbruik) puur het verbruik per uur bevatten, dus hoeveel de meterstand tussen het begin en eind van het uur gewijzigd is. Dus 1 waarde per uur, terwijl als je bv DSMR5 gebruikt je in de recorder 3600 meetpunten voor elk uur hebt (immers geeft de DSMR5 meter elke sec de gegevens door).

Daarnaast is @Stef012 de gegevens sinds begin 22 april kwijt, en dat is nog niet eens 7 dagen geleden

[RobertMe]

Stef012 schreef op zaterdag 26 april 2025 @ 13:44:
Is er een manier om data van de afgelopen dagen met de geschiedenis samen te voegen?

Met wat (eigen) SQL kunde vast wel. Je zou dan de SQLite file uit de backup moeten halen, vervolgens voor de juiste (long term statistics) tabellen de SQL INSERT statements genereren en vervolgens die uitvoeren op de nieuwe database. (Of omgekeerd de data als INSERTs uit de huidige DB halen, vervolgens de backup terug zetten en dan daarop de INSERTs uitvoeren).

Edit:
Ik verwacht overigens dat hiervoor wel instructies te vinden zijn. Want ik heb alleen hier op Tweakers al zeldzaam over dit probleem gelezen. Dus op de totale HA userbase komt het vast (veel) vaker voor en iemand heeft dat herstel proces vast gedocumenteerd.

[ Voor 19% gewijzigd door RobertMe op 26-04-2025 14:19 ]

[synoniem]

hemertje schreef op zaterdag 26 april 2025 @ 13:14:
Ik krijg de melding in HA dat er een Tuya device gevonden is maar heb de laatste maanden niets toegevoegd!?

Hoe kom ik erachter wat er gevonden is?

[Afbeelding]

[Afbeelding]

Bij mij vond hij de Tuya devices van de buren ook. Ik heb zelf inmiddels geen Tuya devices meer en de integratie/addon niet meer draaien dus ik zie nu ook geen meldingen meer.

[Cimpel]

ocmer schreef op zaterdag 26 april 2025 @ 13:26:
[...]

Je bedoelt https://github.com/make-all/tuya-local neem ik aan? Het lukt me niet om die in HACS te vinden en via de link installeren lukt ook niet (HACS blijft leeg met een spinner)

Volgens de documentatie heeft ook Tuya-local de local_key nodig; dus daarmee zal het ook niet lukken.

De laatste is https://github.com/make-all/tuya-local/releases/tag/2025.4.0
Nadat hij in HACS is toegevoegd, dan HA herstarten en is TuyaLocal vervolgens onder de "Integratie toevoegen" te vinden.

Er is ook een Xtend Tuya die meer parameters en scenes uit SmartLife toevoegt.

[ Voor 6% gewijzigd door Cimpel op 26-04-2025 14:08 ]

[HuismAndré]

ocmer schreef op zaterdag 26 april 2025 @ 08:40:
[...]

Ik probeer localtuya aan de praat te krijgen om mijn warmtepomp aan te sturen, maar het lukt me niet om de local_key te achterhalen; ik denk door hetzelfde probleem als hierboven.

Zelfde probleem had ik ook. Vreemd genoeg kon ik met tuya local (dus niet localtuya) de key gewoon extracten zonder enig kunst en vliegwerk (waarna ik het in localtuya kon gebruiken).

[S-te-fan]

Heeft er iemand ervaring met MQTT berichten sturen vanuit HomeAssistant?

Ik heb de volgende situatie:

Vanuit developer tools wil ik een tijd versturen naar een klok. Stuur ik daar de payload sensor.time dan krijg ik netjes de tijd binnen.

Stuur ik volgens exact dezelfde configuratie een mqtt bericht vanuit een knop op mijn dashboard dan krijg ik "{{states('sensor.time')}}" binnen.

Iemand een idee wat ik verkeerd doe?

Links de code vanuit de dashboard editor, rechts de developer tools.

[Verwijderd]

Hoe los ik dit op?

In HA een SSL-certificaat op domeinnaam ingeregeld.
Werkt prima.

Extern is het adres via https://homeassistant.example.com te benaderen.
Intern wil ik (uiteraard) via het interne IP het e.a. kunnen benaderen. (is ook vlotter, getest).
In m'n interne DNS server derhalve 'homeassistant.example.com' adres naar 192.168.1.2 laten verwijzen.
Ook dat werkt prima.

Echter wordt intern https://homeassistant.example.com:8123 verwacht.
Dat is irritant.

Hoe kom ik van 8123 af? dat 't gewoon over 443 (https) naar 't interne IP loopt?

In configuration.yaml de poort al geprobeerd aan te passen:

code:

 http:
   server_port: 443

Maar dat ook na een reboot, geen effect.

[ Voor 11% gewijzigd door Verwijderd op 26-04-2025 21:37 ]

[TheFes]

S-te-fan schreef op zaterdag 26 april 2025 @ 20:29:
Heeft er iemand ervaring met MQTT berichten sturen vanuit HomeAssistant?

Ik heb de volgende situatie:

Vanuit developer tools wil ik een tijd versturen naar een klok. Stuur ik daar de payload sensor.time dan krijg ik netjes de tijd binnen.

Stuur ik volgens exact dezelfde configuratie een mqtt bericht vanuit een knop op mijn dashboard dan krijg ik "{{states('sensor.time')}}" binnen.

Iemand een idee wat ik verkeerd doe?

Links de code vanuit de dashboard editor, rechts de developer tools.[Afbeelding]

Tap actions ondersteunen geen templates. Maak een script aan met die action er in, en activeer het script in je tap action

[TheFes]

Verwijderd schreef op zaterdag 26 april 2025 @ 21:26:
Hoe los ik dit op?

In HA een SSL-certificaat op domeinnaam ingeregeld.
Werkt prima.

Extern is het adres via https://homeassistant.example.com te benaderen.
Intern wil ik (uiteraard) via het interne IP het e.a. kunnen benaderen. (is ook vlotter, getest).
In m'n interne DNS server derhalve 'homeassistant.example.com' adres naar 192.168.1.2 laten verwijzen.
Ook dat werkt prima.

Echter wordt intern https://homeassistant.example.com:8123 verwacht.
Dat is irritant.

Hoe kom ik van 8123 af? dat 't gewoon over 443 (https) naar 't interne IP loopt?

In configuration.yaml de poort al geprobeerd aan te passen:

code:

 http:
   server_port: 443

Maar dat ook na een reboot, geen effect.

Gebruik een reverse proxy. Ik gebruik zelf Nginx Proxy Manager

[Verwijderd]

TheFes schreef op zaterdag 26 april 2025 @ 22:36:
[...]


Gebruik een reverse proxy. Ik gebruik zelf Nginx Proxy Manager

Is dat de enige optie? Simpele poort change niet mogelijk?

[Andre_J]

Verwijderd schreef op zaterdag 26 april 2025 @ 23:35:
[...]

Is dat de enige optie? Simpele poort change niet mogelijk?

Cloudflare tunneltje

[bvw]

Verwijderd schreef op zaterdag 26 april 2025 @ 21:26:
Hoe los ik dit op?

In HA een SSL-certificaat op domeinnaam ingeregeld.
Werkt prima.

Extern is het adres via https://homeassistant.example.com te benaderen.
Intern wil ik (uiteraard) via het interne IP het e.a. kunnen benaderen. (is ook vlotter, getest).
In m'n interne DNS server derhalve 'homeassistant.example.com' adres naar 192.168.1.2 laten verwijzen.
Ook dat werkt prima.

Echter wordt intern https://homeassistant.example.com:8123 verwacht.
Dat is irritant.

Hoe kom ik van 8123 af? dat 't gewoon over 443 (https) naar 't interne IP loopt?

In configuration.yaml de poort al geprobeerd aan te passen:

code:

 http:
   server_port: 443

Maar dat ook na een reboot, geen effect.

Je hebt in je code quote hierboven een spatie teveel staan aan het begin van beide regels, dan doet ie het in ieder geval niet

Overigens, als je 'm draait in een docker dan moet je de poort wijzigen in je compose file.

[JeroenH]

Ik neig naar een dynamisch contract als ons vaste contract afloopt. Daarom al een tijd aan het experimenteren met verschuiven elektriciteitsverbruik, kijken wat dat doet met de gemiddelde kWh-prijs die ik daadwerkelijk betaal, enz. Vandaag tussen 12:00 en 15:00 is de all-in elektriciteitsprijs negatief (ik kijk voor nu bij Frank Energie), dus vandaag maar eens kijken of ik een werkende automation kan bouwen die de zonnepanelen (SolarEdge omvormer) terugregelt naar 0 als de kWh-prijs negatief is, en weer naar 100% bij een positieve prijs.

Het lukte me niet om dit in de grafische interface te doen, gek genoeg krijg ik bij actions met geen mogelijkheid de entiteit number.solaredge_local_active_power_limit te zien. Daarom de automation die Septillion een tijd terug voor me gemaakt heeft uitgeplozen, en er dit van gemaakt:

PV terugregelen naar 0% bij negatieve kWh-prijs

YAML:

alias: PV to 0% at negative kWh price
description: ""
triggers:
  - type: value
    device_id: e9310455c097c3d87d2348555304c6ee
    entity_id: 27c3ce7021e5ae815aabe4591cfe8819
    domain: sensor
    trigger: device
    below: 0
    for:
      hours: 0
      minutes: 0
      seconds: 1
conditions: []
actions:
  - metadata: {}
    data:
      value: 0
    target:
      entity_id: number.solaredge_local_active_power_limit
    action: number.set_value
mode: single

PV opregelen naar 100% bij positieve kWh-prijs

YAML:

alias: PV to 100% at positive kWh price
description: ""
triggers:
  - type: value
    device_id: e9310455c097c3d87d2348555304c6ee
    entity_id: 27c3ce7021e5ae815aabe4591cfe8819
    domain: sensor
    trigger: device
    for:
      hours: 0
      minutes: 0
      seconds: 1
    above: 0
conditions: []
actions:
  - metadata: {}
    data:
      value: 100
    target:
      entity_id: number.solaredge_local_active_power_limit
    action: number.set_value
mode: single

De automations handmatig activeren werkt, straks om 12:00 kijken of het ook echt automatisch werkt.

Paar dingen die ik niet snap:

• Waarom, bij het grafisch aanmaken van de automation, lijkt number.solaredge_local_active_power_limit niet vindbaar? De entiteit is er, werkt, en is aan te sturen, want met mijn yaml-geknutsel werkt het.
• Als trigger lees ik sensor.current_electricity_price_all_in uit. Dit gedeelte heb ik wel in de UI gemaakt. Maar als ik dus verder ga in yaml wordt dat veranderd in "device_id: e9310455c097c3d87d2348555304c6ee en entity_id: 27c3ce7021e5ae815aabe4591cfe8819". Als ik terug switch naar de UI staan daar wel de normale aanduidingen. Weet iemand waarom dat gebeurt?

[RobertMe]

JeroenH schreef op zondag 27 april 2025 @ 11:10:
Waarom, bij het grafisch aanmaken van de automation, lijkt number.solaredge_local_active_power_limit niet vindbaar? De entiteit is er, werkt, en is aan te sturen, want met mijn yaml-geknutsel werkt het.

Ik zie hem gewoon, zowel bij Developer tools => Actions als in de automation builder. Waarbij die via DevTools => Actions ook daadwerkelijk werkt.
Welke integration gebruik je? Wellicht dat daar iets niet lekker zit? Want bij mijn weten zijn er twee. Ik gebruik deze: https://github.com/binsentsu/home-assistant-solaredge-modbus

Als trigger lees ik sensor.current_electricity_price_all_in uit. Dit gedeelte heb ik wel in de UI gemaakt. Maar als ik dus verder ga in yaml wordt dat veranderd in "device_id: e9310455c097c3d87d2348555304c6ee en entity_id: 27c3ce7021e5ae815aabe4591cfe8819". Als ik terug switch naar de UI staan daar wel de normale aanduidingen. Weet iemand waarom dat gebeurt?

In de UI wordt een device trigger gebruikt. En ander triggee type betekent ook dat het (mogelijk) anders werkt en alles een andere betekenis heeft. Waar normaliter "entity_id" dus de zelf instelbare, leesbare, naam is lijkt dat bij de device trigger een automatisch gegenereerd id (uuid?) te zijn. Maar er staat dus nergens dat "entity_id" bij een device trigger dezelfde betekenis heeft als bij een state trigger. En nouja, in dit geval blijkt het een andere betekenis te hebben.
Wil je het alsnog zelf in YAML doen en leesbaar houden dan kun je dus gebruik maken van de "numeric_state" trigger. Daar geef je wel gewoon het leesbare entity id op.
Kanttekening is uiteraard wel dat je het leesbare entity id zelf kunt aanpassen, en automations stuk gaan als die dus de (oude) naam gebruiken. Terwijl die op basis van het id (/uuid?) vast blijven werken. Anderzijds kun je bij het vervangen van een apparaat dus weer de oude entity ids (/"namen") terug zetten en blijven de automations etc werken. Terwijl bij device based het id (/uuid) veranderd zal zijn en mogelijk dus alles geupdate moet worden om het nieuwe device te gebruiken.

[TheFes]

@RobertMe @JeroenH
Voorheen werd bij device triggers/conditions/actions gewoon het leesbare entity id gebruikt. Dat is echter een tijd geleden gewijzigd naar het entry_id. Het entity_id werkt ook nog gewoon en de key is niet gewijzigd om geen backwards incompatible change te creëren.

Deze wijziging is gedaan omdat je dan zonder je automation te slopen het entity_id kunt wijzigen. De verwijzing naar het entry_id blijft dan immers correct.

[Verwijderd]

bvw schreef op zondag 27 april 2025 @ 11:00:
[...]


Je hebt in je code quote hierboven een spatie teveel staan aan het begin van beide regels, dan doet ie het in ieder geval niet

Overigens, als je 'm draait in een docker dan moet je de poort wijzigen in je compose file.

Dank! Dat was em.
Draai HA OS in een VM.

[Septillion]

@Stef012 (en @RobertMe )

Septillion in "Home Assistant - Show je setup"

Helaas dat HA dit zelf niet kan.

[ Voor 14% gewijzigd door Septillion op 27-04-2025 22:43 ]

[TheFes]

Septillion schreef op zondag 27 april 2025 @ 22:42:
@Stef012 (en @RobertMe )

Septillion in "Home Assistant - Show je setup"

Helaas dat HA dit zelf niet kan.

Om wel een waarschuwing te kunnen krijgen, zou je de oudste datum uit de statistics tabel kunnen halen.
Ik heb met mijn beperkte SQL kennis het volgende bij elkaar gesprokkeld:

SQL:

SELECT start_ts
FROM statistics
WHERE
  start_ts = (
    SELECT
      MIN(start_ts)
    FROM
      statistics
  )

In de GUI kun je dan als volgt een SQL sensor aanmaken die de datum geeft van de oudste entry in de statistics tabel.



Ik heb geprobeerd om een device_class toe te voegen, maar dat geeft een error, daarom heb ik hem maar leeg gelaten. In mijn geval geeft dit als resultaat 2021-07-07 (niet geheel toevallig de dag waarop de stable 2021.7 release uit kwam, waarin de long term statistics geïntroduceerd zijn).

Je zou dan een automation kunnen aanmaken die je een waarschuwing stuurt als de state van die sensor ongelijk is aan die state.

Voorbeeld van trigger:

YAML:

trigger: template
value_template: >
  {{
    'sensor.oldest_statistics_date'  | has_value
    and states('sensor.oldest_statistics_date') != '2021-07-07'
  }}

[ Voor 6% gewijzigd door TheFes op 28-04-2025 09:29 ]

[Septillion]

@TheFes Dat is wel een goed idee als notificatie!

Je query is nu dubbel, je kan er gewoon van maken:

SQL:

SELECT
  MIN(start_ts) as ts
FROM
  statistics

En dan mag je de column 'ts' selecteren.

Wel raar dat de device class niet werkt, het is gewoon geldige ISO 8601... Dus zou dan betekenen dat de ISO 8601 check in HA niet correct is...

[TheFes]

Septillion schreef op maandag 28 april 2025 @ 09:59:
@TheFes Dat is wel een goed idee als notificatie!

Je query is nu dubbel, je kan er gewoon van maken:

SQL:

SELECT
  MIN(start_ts) as ts
FROM
  statistics

En dan mag je de column 'ts' selecteren.

Wel raar dat de device class niet werkt, het is gewoon geldige ISO 8601... Dus zou dan betekenen dat de ISO 8601 check in HA niet correct is...

Dat geeft The column `ts` is not returned by the query. Vandaar dat ik voor deze omweg gegaan was.

[Septillion]

@TheFes Goede copy-past gedaan? Namelijk letterlijk wat ik er net van gemaakt heb

[TheFes]

Septillion schreef op maandag 28 april 2025 @ 10:06:
@TheFes Goede copy-past gedaan? Namelijk letterlijk wat ik er net van gemaakt heb

Ah, die as ts had ik inderdaad gemist

Dit is overigens de error bij het kiezen van de device_class
ValueError: Invalid date: sensor.select_sql_query has date device class but provides state 2021-07-07:<class 'str'> resulting in ''str' object has no attribute 'isoformat''

[ Voor 33% gewijzigd door TheFes op 28-04-2025 10:19 ]

[Septillion]

@TheFes

Mm, verwacht het dan een HA attribute of Python attribute? Maar waar het ook naar kijkt, dat lijkt me een bug. De date moet gewoon uit de state geparst worden.

[edit]
Beetje verder zitten klooien en lijkt me een bug. Zo te zien probeert HA bij het zetten van device_class: date direct het Python attribute 'isoformat' op te vragen maar wordt er vergeten om de state, die altijd een string is, daarvoor eerst om te zetten in een datetime object.

[ Voor 46% gewijzigd door Septillion op 28-04-2025 11:14 ]

[ralpje]

Ik heb sinds vorige week een nieuw zonnescherm. Gemotoriseerd, op basis van Solar dus geen koppelin naar het stroomnet en bediend via een RF afstandsbediening. Er is inmiddels ook een Brel home hub onderweg om het vanaf telefoon te bedienen en gelijk te kunnen integreren in HA.
Ik zoek nog een oplossing om het scherm te kunnen sluiten bij teveel wind. Helaas zijn er voor dit type scherm geen 'native' oplossingen om windsterkte (of eigenlijk: beweging van het scherm) te kunnen meten, dus ik zoek iets externs.
Heeft er iemand tips voor óf een extern weerstation waar ik de windsnelheid / gusts uit zou kunnen halen, óf een bewegingssensor die ik aan het scherm kan bevestigen, die bij teveel beweging (en dus teveel wind) via HA het scherm zou kunnen sluiten?

[htca]

Ik probeer mijn omvormer uit te schakelen op basis van de zonneplan uur prijs. Het gaat even niet om de uur prijs, maar wel om het uitschakelen. De automation triggert correct op de prijs. Maar de powerlimit wordt op 0% maar binnen een aantal seconden terug gezet op 100%. Zie ik iets over het hoofd?

YAML:

alias: switch off zonnepanelen
description: ""
triggers:
  - trigger: numeric_state
    entity_id:
      - sensor.zonneplan_current_electricity_tariff
    below: 0
    id: "off"
  - trigger: numeric_state
    entity_id:
      - sensor.zonneplan_current_electricity_tariff
    id: "on"
    above: 0
conditions: []
actions:
  - if:
      - condition: trigger
        id:
          - "on"
    then:
      - action: number.set_value
        metadata: {}
        data:
          value: 100
        target:
          entity_id: number.solaredge_active_power_limit
      - action: telegram_bot.send_message
        metadata: {}
        data:
          message: Zonnepanelen zijn weer aangezet
          title: Zonnepanelen
  - if:
      - condition: trigger
        id:
          - "off"
    then:
      - action: number.set_value
        metadata: {}
        data:
          value: 0
        target:
          entity_id: number.solaredge_active_power_limit
      - action: telegram_bot.send_message
        metadata: {}
        data:
          title: Zonnepanelen
          message: Zonnepanelen zijn uitgezet vanwege negatieve prijs
mode: single

[Septillion]

@htca Dan even in de logbook van number.solaredge_active_power_limit waar die 100% dan vandaan komt.

[konehead]

ralpje schreef op maandag 28 april 2025 @ 11:40:
Ik heb sinds vorige week een nieuw zonnescherm. Gemotoriseerd, op basis van Solar dus geen koppelin naar het stroomnet en bediend via een RF afstandsbediening. Er is inmiddels ook een Brel home hub onderweg om het vanaf telefoon te bedienen en gelijk te kunnen integreren in HA.
Ik zoek nog een oplossing om het scherm te kunnen sluiten bij teveel wind. Helaas zijn er voor dit type scherm geen 'native' oplossingen om windsterkte (of eigenlijk: beweging van het scherm) te kunnen meten, dus ik zoek iets externs.
Heeft er iemand tips voor óf een extern weerstation waar ik de windsnelheid / gusts uit zou kunnen halen, óf een bewegingssensor die ik aan het scherm kan bevestigen, die bij teveel beweging (en dus teveel wind) via HA het scherm zou kunnen sluiten?

Ik heb een weerstation gekocht (Alecto WS-5500), zowel wind, regen als lichtsterkte. Mijn zonnescherm (en rolgordijnen) gaan naar beneden obv van zon stand, lichtsterkte en temperatuur. Mijn zonnescherm gaat omhoog bij x wind of regen OF als de zon niet meer schijnt.. Super simpel, voorkomt een hoop gedoe

[dotcom87]

Heeft er iemand automations gemaakt voor zijn robotmaaier? Ik zou wel wat inspiratie kunnen gebruiken om de robotmaaier zo efficient mogelijk te laten rijden.

[htca]

Septillion schreef op maandag 28 april 2025 @ 12:16:
@htca Dan even in de logbook van number.solaredge_active_power_limit waar die 100% dan vandaan komt.

Hmmm daar word ik niet veel wijzer van, behalve dat deze in een paar seconden weer terug gezet wordt, ik zie hier niet wat de power limit triggert om terug te gaan.


Ik heb de negatieve prijs optie (prijs optimalisatie) in de omvormer uitgezet trouwens (en de automatisering ook).

[RobertMe]

htca schreef op maandag 28 april 2025 @ 14:53:
[...]

Hmmm daar word ik niet veel wijzer van, behalve dat deze in een paar seconden weer terug gezet wordt, ik zie hier niet wat de power limit triggert om terug te gaan.
[Afbeelding]

Ik heb de negatieve prijs optie (prijs optimalisatie) in de omvormer uitgezet trouwens (en de automatisering ook).

Ik meen begrepen te hebben dat het een optie in de omvormer is om deze limieten, via modbus, aan te kunnen passen. Heb je deze optie dus aan staan? Anders kan HA wel vragen om naar 0% te gaan maar als de omvormer dat verzoek negeert zal bij de volgende poll van HA de status/waarde nog steeds 100 zijn.

[htca]

RobertMe schreef op maandag 28 april 2025 @ 14:55:
[...]

Ik meen begrepen te hebben dat het een optie in de omvormer is om deze limieten, via modbus, aan te kunnen passen. Heb je deze optie dus aan staan? Anders kan HA wel vragen om naar 0% te gaan maar als de omvormer dat verzoek negeert zal bij de volgende poll van HA de status/waarde nog steeds 100 zijn.

Dat zal het zijn idd, een even kijken waar die optie zit...

[Septillion]

@htca Als HA er geen reden bij zet (dus automation of user) dan gebeurd het buiten HA om. Klinkt dus plausibel wat @RobertMe zegt dat de omvormer er eigenlijk niets mee doet.

[Endy]

Ik ben sinds vorige week gestart met een home Assistant opstelling op een Raspberry Pi 4B.
Het doel was om zoveel mogelijk te automatiseren ;-)

Alles werkt prima, maar ik kom nu op het laatste stukje en dat is het aansturen van mijn SolarEdge 10K1 omvormer (via HA modbus) om de "limit" van de omvormer terug te zetten als ik teveel teruglever op de hoofdaansluiting.

Als ik het script gebruik wat ik in dit topic volg van vrijdag 31 mei 2024 10:49 (@Septillion ) dan loop ik tegen een paar problemen aan.

-Mijn P1 homewizard dongle is goed geïnstalleerd, maar heeft alleen een "sensor.p1_meter_power" die het actuele vermogen(ongeacht de richting) weergeeft. Ik heb dus niet de losse vermogens voor "leveren - en terugleveren totaal"als uitlezing. het is te zien aan het + of - teken.

-Ik had bij het aanpassen van het YAML script de insteek om alleen de "Export" entity te gebruiken en de "import" entity weg te laten.

- In de YAML gebruik ik de sensor "number.solaredge_active_power_limit" om tussen 0-100 procent te kunnen instellen.

- De omvormer betreft een 10K1 in gebruik met 8400 Wp. Ik heb de limit in het script op 10.000w gezet.
Gemiddeld vermogenop de slimme meter richting het net is ca 3-3,5 kW vermogen met een zonnige dag als vandaag

Als ik dit allemaal meeneem in het script is dit de opzet;

YAML:

alias: 10006 Test - pas omvormer output aan 0-100 procent
description: 10006 Test - pas omvormer output aan 0-100 procent
triggers:
  - entity_id:
      - sensor.p1_meter_power
    from: null
    trigger: state
conditions: []
actions:
  - metadata: {}
    data:
      value: >-
        {% set p_max = 10.000 -%} 
        {% set p_ex = states('sensor.p1_meter_power')|float(default=p_max)  -%}
        {% set c =  states('number.solaredge_active_power_limit')|float(default=100) -%}
        {% set s = p_max / 100 -%}
        {% set c = c + (p_ex / s) -%}
        {{ max(min(c,100), 0)|round(0,'ceil') }}
    target:
      entity_id: number.solaredge_active_power_limit
    action: number.set_value
  - delay:
      hours: 0
      minutes: 0
      seconds: 10
      milliseconds: 0
mode: parallel
max_exceeded: silent

Als ik dit script uitvoer gaat de omvormer limiter naar 0 en neem ik dus energie af uit het net en dat is dan nu op dit moment ca 700 Watt, ik snap ook niet waarom het script niet goed werkt.
Nu heb ik veel zitten puzzelen en zie ik het volgende;

YAML:

[b]In DEVELOPER mode werkt onderstaand goed:[/b]
{% set p_max = 5000 -%}
{% set p_ex = states('sensor.p1_meter_power')|float(default=max)  -%}
{% set c = states('number.solaredge_active_power_limit')|float(default=100) -%}
C old: {{ c }}
P_ex: {{ p_ex }}
{% set s = p_max / 100 -%}
{% set c = c + (p_ex / s) -%}
C new: {{ max( min(c, 100), 0)|round(0, 'ceil') }}

Resultaten bij deze test:
C old: 100.0
P_ex: -3836.0
C new: 24

als ik het YAML script "10006 Test - pas omvormer output aan 0-100 procent" bekijk v.w.b 'trace" zie ik dit.

Stapdetails:
Uitgevoerd op: 28 april 2025 om 12:43:10
Resultaat:

params:
domain: number
service: set_value
service_data:
value: 0
entity_id:
- number.solaredge_active_power_limit
target:
entity_id:
- number.solaredge_active_power_limit
running_script: false

En bijbehorende metadata uit de log:

YAML:

metadata: {}
data:
  value: >-
    {% set p_max = 10.000 -%}  {% set p_ex =
    states('sensor.p1_meter_power')|float(default=p_max)  -%} {% set c =
    states('number.solaredge_active_power_limit')|float(default=100) -%} {% set
    s = p_max / 100 -%} {% set c = c + (p_ex / s) -%} {{ max(min(c,100),
    0)|round(0,'ceil') }}
target:
  entity_id: number.solaredge_active_power_limit
action: number.set_value

Ik kom hier niet verder mee, wat ik nog meer heb geprobeerd:

* in de condition (GUI bouwsteen) een voorwaarde voor de "'sensor.p1_meter_power" met above of below, en diverse waarden. Wat me opvalt is dat als ik "above 0" instel de correcte actuele teruglevering op de slimme meter zie die richting het net ga in de logging. (bv -3500 Watt), zet ik "below 0" aan, dan krijg ik vervolgens de waarde "700" en dit is de waarde die NA afschakelen omvormer naar 0 procent limit overblijft (dus energie betrekken vanaf het energienetwerk.)

*Gekeken of ik nog andere mogelijkheden heb met timings, ik dacht dat het een timing betreft, omdat het uitvoeren van het script neigt naar een verkeerd moment van uitlezen van de 'sensor.p1_meter_power'.
De slimme meter die ik heb (Sagemcom ESMR5) meet elke seconde

*Gekeken of de 'sensor.p1_meter_power" wel altijd de juiste notatie hanteert (dus is de waarde voorzien van een - teken bij negatief => terugleveren. Dat zie ik wel terug.

Mijn vragen zijn dan ook het volgende ;-)
1: Zien jullie hier al fouten in het YAML script?
2: En kan ik wel sturen met alleen het P1 actueel vermogen (+/- richting) icm de Solaredge limiter sensor
of of moet dit anders worden ingericht?

Ik ben in ieder geval lost na 2 dagen puzzelen.

[TheFes]

@Endy pas in ieder geval je code tags aan zodat ze daadwerkelijk werken. Zie ook de topic warning.

[Endy]

@TheFes ik probeer de juiste headers toe te passen maar hij pakt het helaas niet.
[code=yaml] is toch het begin en het sluiten is [/codel]

Ik weet echt niet wat ik fout doe

[D4NG3R]

@Endy
[/codel]
Code> l <

Die l hoort daar niet thuis.

[ Voor 25% gewijzigd door D4NG3R op 28-04-2025 16:06 ]

[Endy]

D4NG3R schreef op maandag 28 april 2025 @ 16:05:
@Endy
[/codel]
Code> l <

Die l hoort daar niet thuis.

Thanks, die had ik helemaal over het hoofd gezien

[Septillion]

@Endy Het "geklooi" met die automation is dat je wel moet kiezen wat de grootheid van de entiteiten is en zorgen dat je dus omrekent waar nodig. Dus {% set p_max = 10.000 -%} is dus alleen goed als al het andere ook in kW is want een punt is een decimaalteken.

[Endy]

@Septillion

Daar heb je helemaal gelijk in, en volgens mij zie ik al 1 fout 😎
In de developer mode heb ik "5000" ingevuld en dat werkte, maar dat was zonder de "."

In mijn script heb ik dat wel gehanteerd, ik weet dat de entities allemaal in Watt aanleveren, dus ik ga even kijken of dit al verschil maakt, en ja dit werkt nu.

Ik heb onderstaande code gebruikt en het werkt ;

YAML:

alias: 10006 Test - pas omvormer output aan 0-100 procent
description: 10006 Test - pas omvormer output aan 0-100 procent
triggers:
  - entity_id:
      - sensor.p1_meter_power
    from: null
    trigger: state
conditions: []
actions:
  - metadata: {}
    data:
      value: >-
        {% set p_max = 6000 -%}
        {% set p_ex = states('sensor.p1_meter_power')|float(default=p_max)  -%}
        {% set c = states('number.set_value')|float(default=100) -%}
        {% set s = p_max / 100 -%}
        {% set c = c + (p_ex / s) -%}
        {{ max(min(c,100), 0)|round(0,'ceil') }}
    target:
      entity_id: number.solaredge_active_power_limit
    action: number.set_value
  - delay:
      hours: 0
      minutes: 0
      seconds: 10
      milliseconds: 0
mode: parallel
max_exceeded: silent

Het mooie is dat ik nu zie dat de "number.solaredge_active_power_limit"met regelmaat wordt aangepast.
Helaas zie ik wel dat de waarde behoorlijk varieert waarbij deze soms naar 100 procent gaat en soms naar 0 waardoor de omvormer even inactief blijft.

Daarnaast is het met mijn omvormer (SolarEdge SE10K) ook wat lastiger v.w.b range van 0-100 procent ,omdat ik 8400 Wp panelen heb liggen en deze door de orientatie optimaal nooit meer dan 5 kW vermogen opwekken. De omvormer reageert dan ook pas met de limiet tussen de 0-40 procent.

Heb je een idee wat v.w.b een YAML script dan beter aansluit om dit wat beter te sturen binnen die 40 procent zonder al te grote schommelingen?

Hieronder zie je mijn dasboard waarbij de limit door het script op 60 procent staat maar de omvormer "niets" doet, omdat de opwek op de tijd van de dag (zojuist) wat minder is dan om bv 12:00 en de omvormer pas vanaf 40 procent impact heeft op het sturen van de opwek.



Ik moet wel zeggen dat ik niet echt bekend ben met het bouwen van deze scripts, maar ik begin het wel wat beter te begrijpen.

[ Voor 76% gewijzigd door Endy op 28-04-2025 18:50 ]

[Antonio di]

konehead schreef op maandag 28 april 2025 @ 12:17:
[...]


Ik heb een weerstation gekocht (Alecto WS-5500), zowel wind, regen als lichtsterkte. Mijn zonnescherm (en rolgordijnen) gaan naar beneden obv van zon stand, lichtsterkte en temperatuur. Mijn zonnescherm gaat omhoog bij x wind of regen OF als de zon niet meer schijnt.. Super simpel, voorkomt een hoop gedoe

@ralpje hier een aanvulling op:
Het is vaak te laat als je gaat pogen de beweging van je zonnescherm zelf te meten en hierop in Home Assistant (HA) een actie uit te voeren. Beter is een weerstation te nemen en op grond hiervan actie te ondernemen in HA. De Alectro WS-5500 is een re-brand van Ecowitt en er is een officiële goedwerkende integratie beschikbaar in HA hiervoor.
@konehead: jouw WS-5500 werkt toch goed met die HA Ecowitt integratie?

PS,
Voor meer info over weerstations e.d. van Ecowitt, zie:
Ecowitt GW2000 Gateway LAN/Wifi with Barometric, Temperature, Humidity review door Antonio di

[elebroek]

Ik heb een zonnepanelen omvormer van het merk SAJ eSolar, type SuntrioPlus (zonder modbus). Tot voor kort maakte ik gebruik van de HACS integratie SAJ eSolar van @djansen1987 om de gegevens in Home Assistant binnen te halen.
Vanaf 20-04-2025 werkt deze echter niet meer, ik heb begrepen dat dit komt doordat ze veranderen van portal. De oorspronkelijke ontwikkelaar heeft echter geen SAJ omvormer meer dus die maakt geen update meer.
Nu is mijn vraag: zijn er meer HA-gebruikers met een SAJ-omvormer en hoe hebben het wegvallen van de integratie opgelost? Ik kan de gegevens wel raadplegen in een app en op een website.