Home Assistant: Open source Python3 home automation - deel 5

[RobertMe]

Septillion schreef op zaterdag 10 mei 2025 @ 22:23:
@hemertje Gezien ik inverter size ook niet heb ingevuld en gewoon info heb lijkt het me dat die alleen gebruikt wordt als limiet / voor aftopping. Dus als je die toch groter zet dan Wp dan doet het niets.

De logica van inverter size zal vast zijn dat die nooit "daarboven" kan komen. Waarbij bij @hemertje de inverter size dus 8000 over het toaal moet zijn (want alle dakvlakken op 1 omvormer). Maar zoals het nu is ingesteld zou je inderdaad verwachten dat het weinig nut heeft. Wat je dus zou verwachten is dat je ook kunt opgeven welke dakvlakken op welke inverter zitten en vervolgens per inverter de grote / max output opgeven. Maar het is tegelijkertijd natuurlijk de vraag of bij de opstelling uberhaupt praktisch meer dan 8kW opgewekt kan worden. Of de orientatie van de panelen dusdanig is dat op een moment de combinatie die 8kW opwerkt. Waarbij alleen het platte dak echt zoden aan de dijk zet v.w.p Wp. Maar..., doordat ze plat liggen zullen ze minder efficient zijn (AFAIK). Waardoor er ook al 2 andere dakvlakken goed tegen de Wp moeten opwekken om richting de 8kW omvormer grote te gaan. En drie dakvlakken vol in de zon is... onwaarschijnlijk

---

@hemertje loopt de PV wel goed? Geen "klapperen" doordat die uitvalt op de 253V regel/wetgeving? Ik heb daar zelf last van, en om dat enigszins in toom te houden heb ik de omvormer ingesteld om minder op te wekken bij een (te) hoge netspanning.Maar gevolg daarvan is dus dat, met de panelen vol op zuid (~175 graden) die over de middag, als de zon juist vol op de panelen schijnt, het minst opwekt. Simpelweg doordat die dan en vaak uitvalt en bv maar maximaal 50% mag opwekken (omdat die anders nog vaker uitvalt, en 50% opwekken is nog steeds ruim voldoende voor "gewoon overdag" en resulteert dus nog steeds in teruglevering). En een PV die meer uit dan aan staat resulteert dus ook in een "foute voorspelling". Immers kan forecast.solar / solcast niet de netspanning bepalen en hoe vaak jouw PV naar verwachting uitvalt

[Sp33dFr34k]

Zijn er toevallig meer mensen waarbij Z2M random niet start?

[Faece]

ik wil bij het indrukken van de bel een bericht ontvangen op mijn gsm met een snapshot erbij.

YAML:

action: notify.mobile_app_gsmjo
data:
  title: Er wordt aangebeld
  message: "{{now().hour}}u:{{now().minute}}"
  data:
    attachment: "/local/tmp/gesloten.jpg"

 

ik krijg het bericht binnen, maar de attachment zit er niet bij.
gesloten.jpg zit onder de map www\tmp ...

[peterpijpelink]

Faece schreef op zondag 11 mei 2025 @ 10:40:
ik wil bij het indrukken van de bel een bericht ontvangen op mijn gsm met een snapshot erbij.

YAML:

action: notify.mobile_app_gsmjo
data:
  title: Er wordt aangebeld
  message: "{{now().hour}}u:{{now().minute}}"
  data:
    attachment: "/local/tmp/gesloten.jpg"

 

ik krijg het bericht binnen, maar de attachment zit er niet bij.
gesloten.jpg zit onder de map www\tmp ...

is je afbeelding niet te groot? (had ik namelijk) en kan je wel de afbeelding zien via je browser? op de deurbel heb ik meerdere formaten snapshot en andere (kleiner formaat gekozen) werkte wel.

ik gebruik deze:

YAML:

 alias: deurbel-notificatie
description: ""
triggers:
  - type: turned_on
    device_id: idnummer
    entity_id: deurbel identity
    domain: binary_sensor
    trigger: device
conditions: []
actions:
  - action: camera.snapshot
    metadata: {}
    data:
      filename: /config/www/camera_snapshots/reolink_deur.jpg
    target:
      device_id: id nummer
  - action: notify.mobile_app_iphone
    metadata: {}
    data:
      message: Iemand belt aan
      data:
        image: >-
          http://ip:8123/local/camera_snapshots/reolink_deur.jpg?{{as_timestamp(now())}}
        actions:
          - action: URI
        title: "Foto van bezoeker:"
        uri: http://ip:8123/dashboard-0/hal
        message: "Iemand bel thuis aan "
mode: single

[ Voor 0% gewijzigd door Septillion op 12-05-2025 11:28 . Reden: Denk aan de 'yaml' bij de code tags aub! Zie topic warning en hoe deze post is aangepast. ]

[peterpijpelink]

-

[ Voor 99% gewijzigd door peterpijpelink op 11-05-2025 11:05 ]

[Faece]

peterpijpelink schreef op zondag 11 mei 2025 @ 10:52:
[...]


is je afbeelding niet te groot? (had ik namelijk) en kan je wel de afbeelding zien via je browser? op de deurbel heb ik meerdere formaten snapshot en andere (kleiner formaat gekozen) werkte wel.

https://XXXXXXX.be:8123/local/tmp/gesloten.jpg werkt alvast niet ...

staat dus in /homeassistant/www/tmp/gesloten.jpg

[peterpijpelink]

Faece schreef op zondag 11 mei 2025 @ 11:11:
[...]


https://XXXXXXX.be:8123/local/tmp/gesloten.jpg werkt alvast niet ...

staat dus in /homeassistant/www/tmp/gesloten.jpg

ik heb een map www en hierin een map snapshot_images gemaakt om alles wat gescheiden te houden, vraag me af of je wel uit local/tmp mag lezen, dus probeer eens met www en hier een map waar je de images laat plaatsen. Het voorbeeld wat ik eerder plaatste werkt goed bij mij.

[Gizz]

Sp33dFr34k schreef op zondag 11 mei 2025 @ 00:09:
Zijn er toevallig meer mensen waarbij Z2M random niet start?

Dat herken ik niet. Maar omdat je vraag over Z2M gaat is dit een handiger topic: Zigbee2mqtt - open source zigbee bridge - Deel 2

[peterpijpelink]

Hallo, ik heb een automation die vreemd doet, of ik doe iets verkeerd, ik wil bij zon opkomst de rolluiken omhoog en een uur na zon ondergang, maar niet later dan 22:30 de rolluiken sluiten.
Kan iemand helpen en licht laten schijnen op dit gedrag? 


YAML:

alias: Rolluiken openen bij zonsopkomst
description: Open rolluiken 1 t/m 5 bij zonsopkomst
triggers:
  - event: sunrise
    trigger: sun
conditions: []
actions:
  - target:
      entity_id:
        - cover.rfy_020005_2
        - cover.rfy_020004_2
        - cover.rfy_020003_2
        - cover.rfy_020002_2
        - cover.rfy_020001_2
    action: cover.open_cover
    data: {}
mode: queued
max: 10

YAML:

alias: Rolluiken sluiten 1 uur na zonsondergang
description: Sluit rolluiken 1 t/m 5 één uur na zonsondergang
triggers:
  - event: sunset
    offset: "01:00:00"
    trigger: sun
  - trigger: time
    at: "22:30:00"
conditions: []
actions:
  - target:
      entity_id:
        - cover.rfy_020005_2
        - cover.rfy_020004_2
        - cover.rfy_020003_2
        - cover.rfy_020002_2
        - cover.rfy_020001_2
    action: cover.close_cover
    data: {}
mode: queued
max: 10

De rolluiken sluiten werkt alleen op tijd en de zon opkomst pas om 08:29, terwijl de entiteit sun.sun aangeeft in de log: opkomst 05:53:47 - 5 uur geleden

Tijden en tijdzones etc staan allemaal goed, iemand idee?

Log:

Rolluiken openen bij zonsopkomst sunrise 08:29:06 - 2 uur geleden

Rolluik3 geopend getriggerd door automatisering Rolluiken openen bij zonsopkomst sunrise
08:29:06 - 2 uur geleden

rolluik1 geopend getriggerd door automatisering Rolluiken openen bij zonsopkomst sunrise
08:29:06 - 2 uur geleden

Rolluik4 geopend getriggerd door automatisering Rolluiken openen bij zonsopkomst sunrise
08:29:06 - 2 uur geleden

Rolluik5 geopend getriggerd door automatisering Rolluiken openen bij zonsopkomst sunrise
08:29:06 - 2 uur geleden

Rolluik2 geopend getriggerd door automatisering Rolluiken openen bij zonsopkomst sunrise
08:29:06 - 2 uur geleden

Alle Rolluiken geopend getriggerd door automatisering Rolluiken openen bij zonsopkomst sunrise
08:29:06 - 2 uur geleden

[ Voor 0% gewijzigd door Septillion op 12-05-2025 11:28 . Reden: Denk aan de 'yaml' bij de code tags aub! Zie topic warning en hoe deze post is aangepast. ]

[Tha_T]

Oke, nu we toch zo lekker bezig zijn met Solcast heb ik even gekeken of het een beetje werkt en in het energy dashboard klopt het met de daadwerkelijke opwek. Dus so far so good.

Op mijn dashboard heb ik een Apex chart waarin ik de opwek van de afgelopen 24 uur plot. Hierin heb ik een poging gedaan om daar ook nog eens de voorspelling (van de afgelopen 24 uur dus) van Solcast overheen te plotten maar dat laatse wil niet lukken. Ik heb er onderstaande van gemaakt maar wat ik ook doe krijg ik vanuit Apexcharts constant de volgende error terug;
"/// apexcharts-card version 2.1.2 /// value.series[0] is not a ChartCardSeriesExternalConfig value.series[0].apex_config is extraneous value.series[0].apex_config is extraneous"

Maar ik zie die value.series überhaupt niet in mijn YAML code. Wat doe ik fout?

YAML:

 
type: custom:apexcharts-card
apex_config:
  chart:
    height: 350px
header:
  title: Opgewekte stroom vs. voorspelling (24 u)
  show: true
  standard_format: true
  show_states: false
  colorize_states: true
all_series_config:
  type: area
  opacity: 0.1
  stroke_width: 1
  unit: ' kWh'
  group_by:
    func: last
    duration: 5m
graph_span: 24h
now:
  show: true
  label: Nu
yaxis:
  - id: kwh
    min: 0
    apex_config:
      tickAmount: 5

series:
  # 1) Solcast forecast (only past hours)
  - entity: sensor.solcast_pv_forecast_forecast_today
    name: Voorspelling
    type: area
    color: orange
    stroke_width: 2
    # push dash and opacity into apex_config
    apex_config:
      stroke:
        dashArray: 4
      fill:
        opacity: 0.2
    data_generator: |
      const arr = entity.attributes.detailedForecast || [];
      const now = Date.now();
      return arr
        .map(iv => [
          new Date(iv.period_start).getTime(),
          iv.pv_estimate
        ])
        .filter(([ts]) => ts <= now);

  # 2) Inverter input power (actual)
  - entity: sensor.inverter_input_power
    yaxis_id: kwh
    name: Inverter Input
    color: lightgreen
    curve: smooth

  # 3) Inverter active power (actual)
  - entity: sensor.inverter_active_power
    yaxis_id: kwh
    name: Inverter Active
    color: blue
    curve: smooth

Mijn YAML-code was overigens;

YAML:

 
type: custom:apexcharts-card
now:
  show: true
  label: Nu
header:
  show: true
  title: Opgewekte stroom
  show_states: false
  colorize_states: true
all_series_config:
  type: area
  opacity: 0.1
  stroke_width: 1
  group_by:
    func: last
    duration: 5m
series:
  - entity: sensor.inverter_input_power
    color: lightgreen
    curve: smooth
  - entity: sensor.inverter_active_power
    color: blue
    curve: smooth

Maar ik heb hem voor Solcast een beetje herschreven.

[Faece]

peterpijpelink schreef op zondag 11 mei 2025 @ 11:14:
[...]

ik heb een map www en hierin een map snapshot_images gemaakt om alles wat gescheiden te houden, vraag me af of je wel uit local/tmp mag lezen, dus probeer eens met www en hier een map waar je de images laat plaatsen. Het voorbeeld wat ik eerder plaatste werkt goed bij mij.

moest

data:
image: /local/tmp/gesloten.jpg

zijn ipv

data:
attachement: /local/tmp/gesloten.jpg

[Faece]

iemand een idee of ik vanuit home assistant de akuvox smart app kan laten openen ? Dit lijkt me niet te werken

YAML:

action:
  service: notify.mobile_app_gsm
  data:
    title: "Er wordt aangebeld"
    message: "Klik om het gesprek te starten"
    data:
      push:
        actions:
          - action: URI_ANSWER
            title: "Open Akuvox App"
            uri: akuvoxsmartplus://open

 

[peterpijpelink]

@Faece tip: YouTube hier wordt e.e.a. uitgelegd.

[hemertje]

Septillion schreef op zaterdag 10 mei 2025 @ 22:23:
@hemertje Gezien ik inverter size ook niet heb ingevuld en gewoon info heb lijkt het me dat die alleen gebruikt wordt als limiet / voor aftopping. Dus als je die toch groter zet dan Wp dan doet het niets.

Vandaag lijkt de voorspelling beter te gaan
Vanmiddag de omvormer automatisch uitgezet ivm de negatieve dynamische prijzen

[ Voor 12% gewijzigd door hemertje op 11-05-2025 15:54 ]

[hemertje]

RobertMe schreef op zaterdag 10 mei 2025 @ 23:27:
[...]

De logica van inverter size zal vast zijn dat die nooit "daarboven" kan komen. Waarbij bij @hemertje de inverter size dus 8000 over het toaal moet zijn (want alle dakvlakken op 1 omvormer). Maar zoals het nu is ingesteld zou je inderdaad verwachten dat het weinig nut heeft. Wat je dus zou verwachten is dat je ook kunt opgeven welke dakvlakken op welke inverter zitten en vervolgens per inverter de grote / max output opgeven. Maar het is tegelijkertijd natuurlijk de vraag of bij de opstelling uberhaupt praktisch meer dan 8kW opgewekt kan worden. Of de orientatie van de panelen dusdanig is dat op een moment de combinatie die 8kW opwerkt. Waarbij alleen het platte dak echt zoden aan de dijk zet v.w.p Wp. Maar..., doordat ze plat liggen zullen ze minder efficient zijn (AFAIK). Waardoor er ook al 2 andere dakvlakken goed tegen de Wp moeten opwekken om richting de 8kW omvormer grote te gaan. En drie dakvlakken vol in de zon is... onwaarschijnlijk

---

@hemertje loopt de PV wel goed? Geen "klapperen" doordat die uitvalt op de 253V regel/wetgeving? Ik heb daar zelf last van, en om dat enigszins in toom te houden heb ik de omvormer ingesteld om minder op te wekken bij een (te) hoge netspanning.Maar gevolg daarvan is dus dat, met de panelen vol op zuid (~175 graden) die over de middag, als de zon juist vol op de panelen schijnt, het minst opwekt. Simpelweg doordat die dan en vaak uitvalt en bv maar maximaal 50% mag opwekken (omdat die anders nog vaker uitvalt, en 50% opwekken is nog steeds ruim voldoende voor "gewoon overdag" en resulteert dus nog steeds in teruglevering). En een PV die meer uit dan aan staat resulteert dus ook in een "foute voorspelling". Immers kan forecast.solar / solcast niet de netspanning bepalen en hoe vaak jouw PV naar verwachting uitvalt

Vorig jaar 2x uitval gehad meen ik ivm te hoge spanning maar vooralsnog niet



Ik verwacht niet boven de totaal vermogen van 8kW uit te komen uit de verschillende liggingen en hoeken

[Toppe]

Ik ben bezig met een blueprint voor het in/uit schakelen van de zwembad pomp bij voldoende zon. Het is nog lekker simpel en hij schakelt de pomp in zodra de zon na een aantal graden (Minimale zonnestand) en hoogte komt (Minimale zonnehoogte). De pomp moet uitschakelen zodra de maximale zonnestand is bereikt, dan is er geen (voldoende) zon meer op de plek waar de warmtemat ligt.

YAML:

blueprint:
  name: Schakelaar bedienen op basis van zonnestand en minimale zonnehoogte (zonder extra acties)
  description: Schakelt een apparaat in of uit op basis van de minimale en maximale zonnestand (azimut) en een minimale zonnehoogte. Extra acties bij in- en uitschakelen zijn verwijderd.
  domain: automation
  input:
    switch_to_control:
      name: Te bedienen schakelaar
      description: De schakelaar die je wilt aansturen.
      selector:
        entity:
          domain: switch
    minimum_azimuth:
      name: Minimale zonnestand (azimut)
      description: De minimale zonnestand (in graden) waarbij de actie actief wordt. (0-360, Noord=0, Oost=90, Zuid=180, West=270)
      selector:
        number:
          min: 0
          max: 360
          step: 1
    maximum_azimuth:
      name: Maximale zonnestand (azimut)
      description: De maximale zonnestand (in graden) waarbij de actie actief wordt. (0-360, Noord=0, Oost=90, Zuid=180, West=270)
      selector:
        number:
          min: 0
          max: 360
          step: 1
    minimum_altitude:
      name: Minimale zonnehoogte
      description: De minimale zonnehoogte (in graden) boven de horizon waarbij de actie actief wordt. (-90 tot 90, Horizon=0)
      selector:
        number:
          min: -90
          max: 90
          step: 1

trigger:
  - platform: state
    entity_id: sun.sun
condition:
  - condition: template
    value_template: >
      {% set azimuth = state_attr('sun.sun', 'azimuth') | float %}
      {% set altitude = state_attr('sun.sun', 'elevation') | float %}
      {% set min_az = float(minimum_azimuth) %}
      {% set max_az = float(maximum_azimuth) %}
      {% set min_alt = float(minimum_altitude) %}

      {% set azimuth_within_range = (min_az <= azimuth <= max_az) if min_az <= max_az else (azimuth >= min_az or azimuth <= max_az) %}
      {% set altitude_above_minimum = (altitude >= min_alt) %}

      {{ azimuth_within_range and altitude_above_minimum }}
action:
  - if:
      - condition: state
        entity_id: sun.sun
        state: above_horizon
      - condition: template
        value_template: >
          {% set azimuth = state_attr('sun.sun', 'azimuth') | float %}
          {% set altitude = state_attr('sun.sun', 'elevation') | float %}
          {% set min_az = float(minimum_azimuth) %}
          {% set max_az = float(maximum_azimuth) %}
          {% set min_alt = float(minimum_altitude) %}

          {% set azimuth_within_range = (min_az <= azimuth <= max_az) if min_az <= max_az else (azimuth >= min_az or azimuth <= max_az) %}
          {% set altitude_above_minimum = (altitude >= min_alt) %}

          {{ azimuth_within_range and altitude_above_minimum }}
    then:
      - service: switch.turn_on
        target:
          entity_id: !input switch_to_control
    else:
      - service: switch.turn_off
        target:
          entity_id: !input switch_to_control
mode: restart

[hemertje]

hemertje schreef op zondag 11 mei 2025 @ 15:53:
[...]


Vandaag lijkt de voorspelling beter te gaan
Vanmiddag de omvormer automatisch uitgezet ivm de negatieve dynamische prijzen

[Afbeelding]

@RobertMe @Septillion

de voorspelling en bijbehorende grafiek van vandaag

[hemertje]

voor het uitschakelen van de Solaredge omvormer bij negatieve dynamische prijzen gebruik ik de App instellingen - elektriciteitstarief

zoals je ziet duurt het terugdimmen naar 0% en het opdimmen naar 100% zo'n 30-45 minuten

heeft iemand een idee waarom ze bij Solaredge voor zo'n lange tijd kiezen?



is dit terug en op dimmen ook via HA mogelijk maar dan sneller?

[prekz]

Ik zie door de bomen het bos even niet meer.

Wat gebruiken jullie vooral voor sensoren (qua merken). Ik doel dan met name op beweging en deursensoren.

Ik lees heel veel issues rondom aqara devices, al vind ik de deur sensoren daar wel lekker klein van. Tevens heb ik wat ikea sensoren maar die zijn wel redelijk lomp (al hebben die wel weer een voordeel met de aaa batterijen).

Kortom wat zijn redelijk geprijsde sensoren voor deur/beweging?

[gazzzman61]

prekz schreef op zondag 11 mei 2025 @ 20:52:
Ik zie door de bomen het bos even niet meer.

Wat gebruiken jullie vooral voor sensoren (qua merken). Ik doel dan met name op beweging en deursensoren.

Ik lees heel veel issues rondom aqara devices, al vind ik de deur sensoren daar wel lekker klein van. Tevens heb ik wat ikea sensoren maar die zijn wel redelijk lomp (al hebben die wel weer een voordeel met de aaa batterijen).

Kortom wat zijn redelijk geprijsde sensoren voor deur/beweging?

Ik gebruik al zeven jaar de aqara sensoren. Idd mooi klein en batterijen van een jaar of twee mee bij mij.
Is wel een afwijkende maat. Geen 2032

[prekz]

gazzzman61 schreef op zondag 11 mei 2025 @ 21:05:
[...]


Ik gebruik al zeven jaar de aqara sensoren. Idd mooi klein en batterijen van een jaar of twee mee bij mij.
Is wel een afwijkende maat. Geen 2032

Ik gebruik ze dus zelf ook al een aantal jaar, alleen af en toe heb ik gekke issues waarbij ik ze opnieuw moet includen of dat ze extreem traag reageren. En dat schijnt een specifiek euvel van die aqara devices te zijn dus daarom wil ik eens met wat anders gaan testen.

[Verwijderd]

prekz schreef op zondag 11 mei 2025 @ 20:52:
Ik zie door de bomen het bos even niet meer.

Wat gebruiken jullie vooral voor sensoren (qua merken). Ik doel dan met name op beweging en deursensoren.

Ik lees heel veel issues rondom aqara devices, al vind ik de deur sensoren daar wel lekker klein van. Tevens heb ik wat ikea sensoren maar die zijn wel redelijk lomp (al hebben die wel weer een voordeel met de aaa batterijen).

Kortom wat zijn redelijk geprijsde sensoren voor deur/beweging?

Voor deuren en ramen heb ik gekeken naar de mogelijkheid voor het opladen van de batterij die erin moet.
Zo kwam ik uiteindelijk uit op de zigbee sensor van Ikea: Parasol.

Qua beweging heb ik zowel Sonoff als Hue (beide zigbee), waarbij de laatste toch mijn voorkeur heeft gezien de mogelijkheid tot op laden batterij en meerdere meet mogelijkheden.

Verder heb ik nog 1 Tuya multi sensor zigbee (van Ali express geplukt), die op 220v werkt (wel helaas via een USB adapter) en in het plafond zit zoals je normaal gesproken een inbouwspot plaatst.

Alles werkt naar behoren en behoefte.

[RobertMe]

Verwijderd schreef op zondag 11 mei 2025 @ 21:24:
[...]

Voor deuren en ramen heb ik gekeken naar de mogelijkheid voor het opladen van de batterij die erin moet.
Zo kwam ik uiteindelijk uit op de zigbee sensor van Ikea: Parasol.

Hoe vaak doe jij de ramen en deuren open? * RobertMe heeft al zeker 6 of 7 jaar Xiaomi & Aqara contact sensoren (stuk of 5, 6) en ik vorig jaar bij 2 er de batterijen moeten vervangen (en een daarvan zit een pressure mat aan gesoldeerd en zit "onder" bureaustoel, dus elke keer als ik op sta of ga zitten..., en de ander zat in de brievenbus dus buiten (en ook leeg in de winter)). Contact sensoren an zich verbruiken 0,0 stroom. En Zigbee verbruikt ook alleen stroom als er daadwerkelijk iets te communiceren is (i.t.t. wifi dat continu moet communiceren en dus stroom verbruikt). Dus een contact sensor zal letterlijk 23,5+ uur op een dag (van 24 uur ) in deep sleep staan en 0,0 stroom verbruiken. En hetzelfde geldt voor bv drukknoppen (heb ook een Xiaomi button, net zo lang, nog nooit de batterijen vervangen, zolang ik maar niet tientallen / honderden keren per dag er op ga drukken).

Batterijen in contact sensoren (en knoppen) is dus iets waar ik mij echt geen zorgen om maak. Die ene keer in de X jaar doe ik er wel gewoon een nieuw batterijtje in.

De Tado knoppen moet ik dan wel eens oplaadbare batterijen in gaan doen. Want die kunnen naar mijn idee elke winter 2x vervangen worden. Maar die zullen en meer communiceren en zit uiteraard een motortje in.

[Get!em]

RobertMe schreef op zondag 11 mei 2025 @ 22:12:
[...]

Hoe vaak doe jij de ramen en deuren open? * RobertMe heeft al zeker 6 of 7 jaar Xiaomi & Aqara contact sensoren (stuk of 5, 6) en ik vorig jaar bij 2 er de batterijen moeten vervangen (en een daarvan zit een pressure mat aan gesoldeerd en zit "onder" bureaustoel, dus elke keer als ik op sta of ga zitten..., en de ander zat in de brievenbus dus buiten (en ook leeg in de winter)). Contact sensoren an zich verbruiken 0,0 stroom. En Zigbee verbruikt ook alleen stroom als er daadwerkelijk iets te communiceren is (i.t.t. wifi dat continu moet communiceren en dus stroom verbruikt). Dus een contact sensor zal letterlijk 23,5+ uur op een dag (van 24 uur ) in deep sleep staan en 0,0 stroom verbruiken. En hetzelfde geldt voor bv drukknoppen (heb ook een Xiaomi button, net zo lang, nog nooit de batterijen vervangen, zolang ik maar niet tientallen / honderden keren per dag er op ga drukken).

Batterijen in contact sensoren (en knoppen) is dus iets waar ik mij echt geen zorgen om maak. Die ene keer in de X jaar doe ik er wel gewoon een nieuw batterijtje in.

De Tado knoppen moet ik dan wel eens oplaadbare batterijen in gaan doen. Want die kunnen naar mijn idee elke winter 2x vervangen worden. Maar die zullen en meer communiceren en zit uiteraard een motortje in.

Enige battery drain bij zigbee battery powered devices is een OTA update.
Had laatst toevallig dat uitgeprobeerd met een sonoff temperatuur/vochtigheid sensor. In 1,5uur ben je 50-60% lading van batterij kwijt.

[Verwijderd]

RobertMe schreef op zondag 11 mei 2025 @ 22:12:
[...]

Hoe vaak doe jij de ramen en deuren open?

Als ik niet thuis ben (of weg rij) en er gaat (of staat) een deur/raam open, vind ik het fijn als ik daarvan op de hoogte wordt gebracht.
Zie het als een soort inbraak alarm systeem ook.

Oh en er zit er ook eentje in de brievenbus/pakketbox. Scheelt weer checken of er wat in zit.

Werkt overigens ook als er een spin in de schuur voor de motion sensor gaat bungelen.

[ Voor 10% gewijzigd door Verwijderd op 11-05-2025 22:25 ]

[RobertMe]

Verwijderd schreef op zondag 11 mei 2025 @ 22:22:
[...]

Als ik niet thuis ben (of weg rij) en er gaat (of staat) een deur/raam open, vind ik het fijn als ik daarvan op de hoogte wordt gebracht.
Zie het als een soort inbraak alarm systeem ook.

Oh en er zit er ook eentje in de brievenbus/pakketbox. Scheelt weer checken of er wat in zit.

Werkt overigens ook als er een spin in de schuur voor de motion sensor gaat bungelen.

Ik vraag niet naar de use cases van contact sensoren

Maar om de batterijen van een Zigbee contact sensor leeg te krijgen tot het niveau dat batterijen wisselen irritant wordt / opvalt, moet je toch echt wel heel goed je best doen. Zoals in ik al uitweidde in mijn vorige post: de contact sensoren die ik intussen ~6, 7 misschien zelfs wel 8 jaar heb, heb ik nog maar een klein deel de batterij, 1x, van moeten vervangen. Waarbij eentje waarschijnlijk gewoon echt leeg is gegaan door gebruik (die wat intussen dus onder mijn bureaustoel zit, en dus tientallen keren per dag triggert), en de ander doordat die buiten in de brievenbus zit (en dus kou invloed op batterijduur etc heeft).
En dat zijn dan dus Xiaomi & Aqara contact sensoren, met een kleine knoopcel (geen CR2032 wat een beetje de standaard is, maar een kleinere variant, CR1632?, en dus vast ook kleinere capaciteit oftewel sneller leeg).

[zunrob]

Ik heb de SolarEdge Modbus werkend, bedankt @RobertMe! Ik zou het echter elegant vinden als ik de nieuwe 'total energy' toe kan voegen aan mijn energiedashboard, en hij de oude (van de eigen SolarEdge integratie) vervangt. Echter, als ik de oude eruit haal en de nieuwe erin zet ben ik (vanzelfsprekend) de oude geschiedenis meteen kwijt. Is hier iets aan te doen?

[DaRk PoIsOn]

RobertMe schreef op zondag 11 mei 2025 @ 22:33:
[...]

Ik vraag niet naar de use cases van contact sensoren

Maar om de batterijen van een Zigbee contact sensor leeg te krijgen tot het niveau dat batterijen wisselen irritant wordt / opvalt, moet je toch echt wel heel goed je best doen. Zoals in ik al uitweidde in mijn vorige post: de contact sensoren die ik intussen ~6, 7 misschien zelfs wel 8 jaar heb, heb ik nog maar een klein deel de batterij, 1x, van moeten vervangen. Waarbij eentje waarschijnlijk gewoon echt leeg is gegaan door gebruik (die wat intussen dus onder mijn bureaustoel zit, en dus tientallen keren per dag triggert), en de ander doordat die buiten in de brievenbus zit (en dus kou invloed op batterijduur etc heeft).
En dat zijn dan dus Xiaomi & Aqara contact sensoren, met een kleine knoopcel (geen CR2032 wat een beetje de standaard is, maar een kleinere variant, CR1632?, en dus vast ook kleinere capaciteit oftewel sneller leeg).

Volgens mij hebben ze een 2450.
Ik heb er 2 en die zijn in de 5 jaar nog nooit leeg gegaan.

[RudolfR]

@Tha_T

Ik heb de forecasts er zo in staan:

YAML:

type: custom:apexcharts-card
apex_config:
  chart:
    height: 350px
all_series_config:
  unit: " kWh"
header:
  title: Solar forecast
  show: true
  standard_format: true
  show_states: true
  colorize_states: true
graph_span: 2d
span:
  start: day
  offset: "-0h"
now:
  show: true
  label: Now
yaxis:
  - id: kwh
    min: 0
    apex_config:
      tickAmount: 5
  - id: header_only
    show: false
series:
  - entity: sensor.solcast_pv_forecast_forecast_today
    yaxis_id: kwh
    type: area
    name: Today
    color: orange
    data_generator: |
      var today = entity.attributes.detailedForecast.map((start, index) => {
        return [new Date(start["period_start"]).getTime(), entity.attributes.detailedForecast[index]["pv_estimate"]];
      });
      var data = today
      return data;
    show:
      legend_value: false
      in_header: false
    stroke_width: 3
    float_precision: 2
    extend_to: false
  - entity: sensor.solcast_pv_forecast_forecast_tomorrow
    yaxis_id: kwh
    type: area
    name: Tomorrow
    color: grey
    data_generator: |
      var today = entity.attributes.detailedForecast.map((start, index) => {
        return [new Date(start["period_start"]).getTime(), entity.attributes.detailedForecast[index]["pv_estimate"]];
      });
      var data = today
      return data;
    show:
      legend_value: false
      in_header: false
    stroke_width: 3
    float_precision: 2
    extend_to: false
  - entity: sensor.solcast_pv_forecast_forecast_today
    yaxis_id: header_only
    name: Today
    color: orange
    show:
      legend_value: true
      in_header: true
      in_chart: false
  - entity: sensor.solcast_pv_forecast_forecast_remaining_today
    yaxis_id: header_only
    name: Remaining
    color: orange
    show:
      legend_value: true
      in_header: true
      in_chart: false
  - entity: sensor.solcast_pv_forecast_forecast_tomorrow
    yaxis_id: header_only
    name: Tomorrow
    color: grey
    show:
      legend_value: true
      in_header: true
      in_chart: false

[JanHenk]

zunrob schreef op zondag 11 mei 2025 @ 22:42:
Ik heb de SolarEdge Modbus werkend, bedankt @RobertMe! Ik zou het echter elegant vinden als ik de nieuwe 'total energy' toe kan voegen aan mijn energiedashboard, en hij de oude (van de eigen SolarEdge integratie) vervangt. Echter, als ik de oude eruit haal en de nieuwe erin zet ben ik (vanzelfsprekend) de oude geschiedenis meteen kwijt. Is hier iets aan te doen?

De huidige/oude entiteit verwijderen (of de hele integratie) en de entity ID noteren van waar de historie in zit. Vervolgens geef je de nieuwe entiteit de Entity ID van de oude. De historie wordt bewaard en doorgeschreven door de nieuwe entiteit/integratie. Je kunt vervolgens de entity ID weer hernoemen naar wat je wil, de historie blijft dan wel gekoppeld.

[Gizz]

Iemand een tip voor een goed zigbee-ventiel op batterijen voor het beregenen van de tuin, geschikt voor buitengebruik (direct aan de kraan)?

Casus: Ik geef nu mijn achtertuin water d.m.v. een Rainbird-ventiel in een bak in de grond. Vanaf het ventiel gaan er tientallen meters ondergrondse druppelslang door de tuin.

Dat werkt prima, maar de laatste jaren zijn er veel planten in potten en een zelfgebouwd kruidenrek bijgekomen. Die heb ik nu aangesloten met druppelslangen op de rest van het circuit, maar dit is in de praktijk niet erg efficient; als ik alleen de potten water wil geven (wat veel vaker moet gebeuren dan het beregenen van planten in volle grond) krijgt ook de gehele tuin water

Het handigst lijkt het mij om de boel te splitsen. Een kraanverdeler op de buitenkraan; één uitgang voor de Rainbird en op de andere uitgang een zigbee-ventiel op batterijen voor alleen de potten en het kruidenrek. Dat lijkt me handiger dan een tweede Rainbird-ventiel ingraven, daar heb ik niet echt ruimte voor.

Veel reviews van zigbee-ventielen bestempelen die dingen als een beetje 'meh'. Het werkt wel, maar zit wat fragiel in elkaar of het is een vervelende klus om het lekvrij te installeren.

@Toppe ik zie in je review dat jij 3 jaar geleden best tevreden was met de Woox R7060. Is dat nog steeds zo?

[Toppe]

Gizz schreef op maandag 12 mei 2025 @ 08:58:
@Toppe ik zie in je review dat jij 3 jaar geleden best tevreden was met de Woox R7060. Is dat nog steeds zo?

Jawel al heb ik hem vervangen voor deze. Dat kwam vooral doordat hij op den duur begon te lekken. Deze heb ik nu 2 jaar en ik zou eerder voor deze dan voor die Woox gaan, helemaal omdat het bereik van deze ook beter is.

[avdwerf]

RobertMe schreef op maandag 5 mei 2025 @ 20:39:
[...]

Er staan, ik meen twee, integraties in HACS voor SolarEdge. Beiden werken op basis van modbus (over TCP) en lezen daarmee volledig lokaal de omvormer uit. En kunnen daarbij ook elke X seconden de gegevens ophalen. Dit i.t.t. de officiële SE integratie waarbij HA maar elke zoveel minuten kan/mag pollen van de SE servers. Met de modbus variant heb je dus near real-time data, terwijl je met de cloud integratie minimaal minuten als niet een half uur tot uur(en) achter loopt. Los van dat de aanlevering vanaf de omvormer naar SE ook niet altijd lekker werkt waardoor die met pollen van de cloud dus uren achter loopt, en de statistics dus ook hartstikke fout zullen zijn. En via modbus kan dus ook een "active power limit" worden ingesteld op de omvormer. Waarmee die dus nog maar een bepaalt percentage van het maximale vermogen zal leveren.,

Heb sinds gisteren eindelijk de HACS versie werkend. Ik had hem op 5 seconden gezet, en merk nog wel vaak dat ik nu een 'niet beschikbaar' melding krijg die na 5 seconden weg gaat. Zou 5 te snel zijn? Zag dat hij standaard op 30 sec. stond.

Verder werkt die power limit perfect. Gister tijdens de uren dat je geld kreeg om stroom af te nemen de power limit dichtgezet zodat ik niks terugleverde. Nu nog automatiseren :-)
Het is toch zo dat stroomprijs negatief -> powerlimit naar zo laag mogelijk om niet terug te leveren
Stroomprijs positief -> dan laat maar gaan op 100%.
Of mis ik dan nog scenario's?

[RobertMe]

avdwerf schreef op maandag 12 mei 2025 @ 09:09:
Het is toch zo dat stroomprijs negatief -> powerlimit naar zo laag mogelijk om niet terug te leveren
Stroomprijs positief -> dan laat maar gaan op 100%.
Of mis ik dan nog scenario's?

Terugleverboete? Mogelijk wellicht misschien dat je daar mee te maken hebt en je uberhaupt niet "te veel" terug wilt leveren. En dat is ook nog eens afhankelijk van energieleverancier. Sommige hebben een terugleverboete die lager is dan de terugleververgoeding en anderen een hogere boete dan vergoeding. Mogelijk dat je aan het eind van het jaar dus richting een netto 0kWh verbruik wilt gaan i.p.v. na saldering dus nog een "overschot" aan afname hebben waarvoor je de boete betaald en maar een paar cent per kWh vergoeding krijgt (terwijl je dubbeltjes aan boete betaald).

[JanHenk]

hemertje schreef op zondag 11 mei 2025 @ 20:44:
voor het uitschakelen van de Solaredge omvormer bij negatieve dynamische prijzen gebruik ik de App instellingen - elektriciteitstarief

zoals je ziet duurt het terugdimmen naar 0% en het opdimmen naar 100% zo'n 30-45 minuten

heeft iemand een idee waarom ze bij Solaredge voor zo'n lange tijd kiezen?

[Afbeelding]

is dit terug en op dimmen ook via HA mogelijk maar dan sneller?

Interessante constatering. Technisch, als je bijv. lokaal via HA en modbus aanstuurt, kan het een flink stuk sneller.

Mogelijk dat ze bij SolarEdge niet de verantwoordelijkheid willen dat een groot deel van hun merk omvormers op exact dezelfde tijd in heel korte tijd gaan uitschakelen. Dat kan best wat problemen veroorzaken op het net namelijk. Kan me daarom voorstellen dat ze er een (flinke) vertraging hebben ingebouwd.

Pré voor aansturing met Home Assistant dus.

En ja, dat kan zeker. De afgelopen paar pagina's gaan er haast uitsluitend over

[zunrob]

JanHenk schreef op maandag 12 mei 2025 @ 07:39:
[...]


De huidige/oude entiteit verwijderen (of de hele integratie) en de entity ID noteren van waar de historie in zit. Vervolgens geef je de nieuwe entiteit de Entity ID van de oude. De historie wordt bewaard en doorgeschreven door de nieuwe entiteit/integratie. Je kunt vervolgens de entity ID weer hernoemen naar wat je wil, de historie blijft dan wel gekoppeld.

Top, ik krijg de oude historie dan inderdaad ook te zien! Echter, als ik daarna de Entity ID van de nieuwe integratie (modbus dus) weer terug wijzig naar zijn originele naam dan verdwijnt dat stukje historie weer...

[avdwerf]

RobertMe schreef op maandag 12 mei 2025 @ 09:16:
[...]

Terugleverboete? Mogelijk wellicht misschien dat je daar mee te maken hebt en je uberhaupt niet "te veel" terug wilt leveren. En dat is ook nog eens afhankelijk van energieleverancier. Sommige hebben een terugleverboete die lager is dan de terugleververgoeding en anderen een hogere boete dan vergoeding. Mogelijk dat je aan het eind van het jaar dus richting een netto 0kWh verbruik wilt gaan i.p.v. na saldering dus nog een "overschot" aan afname hebben waarvoor je de boete betaald en maar een paar cent per kWh vergoeding krijgt (terwijl je dubbeltjes aan boete betaald).

Ja dat heb ik dus niet. Dynamisch contract zonneplan dus krijg zelfs nog een extraatje als ik teruglever. Dan ga ik hem zo eens proberen in te regelen en kijken of dat beetje blijft werken. Voorlopig bij elke handeling maar even een melding naar mn mobiel erbij zodat ik kan kijken of het goed gaat.

[JanHenk]

zunrob schreef op maandag 12 mei 2025 @ 10:10:
[...]


Top, ik krijg de oude historie dan inderdaad ook te zien! Echter, als ik daarna de Entity ID van de nieuwe integratie (modbus dus) weer terug wijzig naar zijn originele naam dan verdwijnt dat stukje historie weer...

Je kan de originele naam nu niet gebruiken, want die zit nu nog in de database qua history. Dan wordt eigenlijk die history weer gekoppeld aan jouw entiteit. Dus mijn statement 'in wat je wil' was ook niet helemaal waar

Ik zou gewoon die oude entity ID aanhouden

[avdwerf]

JanHenk schreef op maandag 12 mei 2025 @ 09:24:
[...]


Interessante constatering. Technisch, als je bijv. lokaal via HA en modbus aanstuurt, kan het een flink stuk sneller.

Mogelijk dat ze bij SolarEdge niet de verantwoordelijkheid willen dat een groot deel van hun merk omvormers op exact dezelfde tijd in heel korte tijd gaan uitschakelen. Dat kan best wat problemen veroorzaken op het net namelijk. Kan me daarom voorstellen dat ze er een (flinke) vertraging hebben ingebouwd.

Pré voor aansturing met Home Assistant dus.

En ja, dat kan zeker. De afgelopen paar pagina's gaan er haast uitsluitend over

Gister dus getest, zodra je de powerlimit aanzet past hij binnen een paar seconden het vermogen aan.

[zunrob]

JanHenk schreef op maandag 12 mei 2025 @ 10:15:
[...]


Je kan de originele naam nu niet gebruiken, want die zit nu nog in de database qua history. Dan wordt eigenlijk die history weer gekoppeld aan jouw entiteit. Dus mijn statement 'in wat je wil' was ook niet helemaal waar

Ik zou gewoon die oude entity ID aanhouden

Het enige lastige is dan dat als ik de modbus integratie opnieuw toevoeg, bijv. als ik iets in de configuratie wil wijzigen die je alleen bij het opnieuw toevoegen ziet (polling interval bijv.), dat ie dan weer de standaard naam van de integratie krijgt. Dan zou ik de nieuwe ID naam dus moeten onthouden. Is er echt geen andere optie om het wel te mergen?

Edit: Is er trouwens een reden dat ik de modbus niet elke seconde zou laten verversen? En is het mogelijk om de Enphase ook frequenter te laten verversen?

[ Voor 9% gewijzigd door zunrob op 12-05-2025 10:48 ]

[achterhoeker]

Ik gebruik ook de modbus multi integratie om de omvormer naar 0% te schakelen zodra via de tibber integratie de prijs onder de 0 zakt. Ik krijg via de home assistant een melding zodat ik evt nog andere stroomslurpers kan aanzetten. Tegelijkertijd gaat de smartevse laadpaal de instructie om op smart te gaan staan wanneer er een auto verbonden is om dat ook te maximaliseren. Werkt perfect en uit en inschakelen is praktisch zonder vertraging.

[PisPix]

Ik zit vast met een integratie (EV Smart Charging). Ik wil deze gebruiken voor 2 auto's. Nu heb ik e.e.a. opgelost met helpers die gezet worden zodra een bepaalde auto gedetecteerd wordt op de oprit (en koppelt aan laadpaal). Maar ik loop vast op de actuele status van de batterij. Die kan ik van beide auto's uitlezen, maar die zijn min of meer dynamisch. De laadpaal laadt namelijk alle overtollige stroom in de auto lopen (Zappi2 met ECO+ modus). Op basis hiervan moet de integratie steeds opnieuw berekenen wat het ideale geplande laadmoment is (Zappi2 > status Fast) op basis van uurtarieven. Mijn automation schrijft nu het batterij percentage van het moment van thuiskomen statisch weg in een helper waar de EVSC integratie naar kijkt. Maar eigenlijk zou ik de helper dynamisch willen linken aan de entity van de auto die op dat moment gekoppeld is. Ik weet alleen niet goed waarop ik moet zoeken qua termen en of dit kan.

[HuismAndré]

Verwijderd schreef op zondag 11 mei 2025 @ 21:24:
[...]

Voor deuren en ramen heb ik gekeken naar de mogelijkheid voor het opladen van de batterij die erin moet.
Zo kwam ik uiteindelijk uit op de zigbee sensor van Ikea: Parasol.

Qua beweging heb ik zowel Sonoff als Hue (beide zigbee), waarbij de laatste toch mijn voorkeur heeft gezien de mogelijkheid tot op laden batterij en meerdere meet mogelijkheden.

Hier ook een grote fan van de Hue bewegingssensoren maar die oplaadbare batterijen... Daar kan ik me niets bij voorstellen. De Hue bewegingssensor doet een jaar of 3-4 met 2 AAA penlites. Dan is het volgens mij niet echt rendabel om te kiezen voor oplaadbare batterijen. De zelfontlading van de NiMH batterijen begint dan het oplaadverhaal wel erg negatief te beïnvloeden volgens mij.

[JanHenk]

zunrob schreef op maandag 12 mei 2025 @ 10:24:
[...]


Het enige lastige is dan dat als ik de modbus integratie opnieuw toevoeg, bijv. als ik iets in de configuratie wil wijzigen die je alleen bij het opnieuw toevoegen ziet (polling interval bijv.), dat ie dan weer de standaard naam van de integratie krijgt. Dan zou ik de nieuwe ID naam dus moeten onthouden. Is er echt geen andere optie om het wel te mergen?

Ik snap je. Samenvoegen en verwijderen kan alleen in de database, is een optie maar wel gerommel en foutgevoelig.

Een alternatief kan zijn dat je de historie die je niet wil bewaren en die nu gekoppeld is aan [entity-id new] eerst wijzigt naar een [entity-id dummy]. Dan wordt die historie daadwerkelijk gemigreerd, omdat deze entity id nog niet bestaat. Daarna pas de oude integratie en entity id oppakken, daarna de naam wijzigen in wat je wil behalve de dummy.

Eigenlijk hetzelfde proces, met nog een stap ervoor. Drie keer een change van entity id dus

Edit: Is er trouwens een reden dat ik de modbus niet elke seconde zou laten verversen? En is het mogelijk om de Enphase ook frequenter te laten verversen?

Nee, staat hier ook op 1 seconde, werkt prima.

[Septillion]

@PisPix Je zou een template helper kunnen maken waarvan je dus de state ophaalt van een van de twee. Iets als

YAML:

template:
  - sensor:
      - name: "Connected car battery"
        unit_of_measurement: "%"
        state: >-
          {% if states('input_select.car_connected') == 'Car A' %}
            {{ states('sensor.car_a_battery') }}
          {% else %}
            {{ states('sensor.car_b_battery') }}
          {% endif %}
        availability: >-
          {% if states('input_select.car_connected') == 'Car A' %}
            {{ has_value('sensor.car_a_battery') }}
          {% else %}
            {{ has_value('sensor.car_b_battery') }}
          {% endif %}

Waar ik even uit ga van een input_select die de juiste auto aangeeft maar logica zou je er ook direct in kunnen doen, wat je wilt. device_class en unit_of_measurment gelijk zetten aan die van de auto's.

[Septillion]

peterpijpelink schreef op zondag 11 mei 2025 @ 11:24:
Hallo, ik heb een automation die vreemd doet, of ik doe iets verkeerd, ik wil bij zon opkomst de rolluiken omhoog en een uur na zon ondergang, maar niet later dan 22:30 de rolluiken sluiten.
Kan iemand helpen en licht laten schijnen op dit gedrag? 


YAML:

alias: Rolluiken openen bij zonsopkomst
description: Open rolluiken 1 t/m 5 bij zonsopkomst
triggers:
  - event: sunrise
    trigger: sun
conditions: []
actions:
  - target:
      entity_id:
        - cover.rfy_020005_2
        - cover.rfy_020004_2
        - cover.rfy_020003_2
        - cover.rfy_020002_2
        - cover.rfy_020001_2
    action: cover.open_cover
    data: {}
mode: queued
max: 10

YAML:

alias: Rolluiken sluiten 1 uur na zonsondergang
description: Sluit rolluiken 1 t/m 5 één uur na zonsondergang
triggers:
  - event: sunset
    offset: "01:00:00"
    trigger: sun
  - trigger: time
    at: "22:30:00"
conditions: []
actions:
  - target:
      entity_id:
        - cover.rfy_020005_2
        - cover.rfy_020004_2
        - cover.rfy_020003_2
        - cover.rfy_020002_2
        - cover.rfy_020001_2
    action: cover.close_cover
    data: {}
mode: queued
max: 10

De rolluiken sluiten werkt alleen op tijd en de zon opkomst pas om 08:29, terwijl de entiteit sun.sun aangeeft in de log: opkomst 05:53:47 - 5 uur geleden

Tijden en tijdzones etc staan allemaal goed, iemand idee?

Log:


[...]

Ik zie zo snel niets, hoe lang probeer je het al?

En wat is "Alle Rolluiken geopend", dat ook een derde automation?

[peterpijpelink]

Septillion schreef op maandag 12 mei 2025 @ 11:38:
[...]

Ik zie zo snel niets, hoe lang probeer je het al?

En wat is "Alle Rolluiken geopend", dat ook een derde automation?

Onbekend die melding van Alle Rolluiken geopend. Is geen automation, heb ze nu maar op tijd staan, maar gisteren kwam een andere melding ook pas uren later binnen. Kan niets vinden in docker of systeem qua tijd of tijdzones...

Wil uiteraard op basis van de zon opkomst en ondergang schakelen en niet tijden gaan aanpassen..

[Septillion]

@peterpijpelink Wat zie je in de log van een device zelf?

[zunrob]

JanHenk schreef op maandag 12 mei 2025 @ 11:19:
[...]


Ik snap je. Samenvoegen en verwijderen kan alleen in de database, is een optie maar wel gerommel en foutgevoelig.

Een alternatief kan zijn dat je de historie die je niet wil bewaren en die nu gekoppeld is aan [entity-id new] eerst wijzigt naar een [entity-id dummy]. Dan wordt die historie daadwerkelijk gemigreerd, omdat deze entity id nog niet bestaat. Daarna pas de oude integratie en entity id oppakken, daarna de naam wijzigen in wat je wil behalve de dummy.

Eigenlijk hetzelfde proces, met nog een stap ervoor. Drie keer een change van entity id dus


[...]


Nee, staat hier ook op 1 seconde, werkt prima.

Je antwoord brengt me op een idee, zou onderstaand niet kunnen werken?

Stel de oude entity heet SE_PV (standaard naam gegeven vanuit de SolarEdge integratie), en van de nieuwe integratie (SolardEdge modbus) is dat SEM_PV.
Als je SEM_PV hernoemt naar dummy1, zal SEM_PV leeg worden gemaakt als ik jou goed begrijp? Als je dan de modbus integratie verwijdert zal SEM_PV leeg zijn (neem ik aan).
Als je vervolgens SE_PV hernoemt naar SEM_PV, dan zal al je oude geschiedenis van de SolarEdge integratie dus overgaan naar SEM_PV. Als je dan de oude SolarEdge integratie verwijdert, en de modbus integratie opnieuw toevoegt zal SEM_PV (standaard naam van de integratie dus) alle geschiedenis bevatten én dus ook gewoon gevuld gaan worden?

Of gaat de vlieger niet op omdat SEM_PV toch al eens heeft bestaan?

[peterpijpelink]

Septillion schreef op maandag 12 mei 2025 @ 11:59:
@peterpijpelink Wat zie je in de log van een device zelf?

niet veel meer dan de log,

heb nu in geschiedenis gekeken:

[PisPix]

Septillion schreef op maandag 12 mei 2025 @ 11:27:
@PisPix Je zou een template helper kunnen maken waarvan je dus de state ophaalt van een van de twee. Iets als

YAML:

template:
  - sensor:
      - name: "Connected car battery"
        unit_of_measurement: "%"
        state: >-
          {% if states('input_select.car_connected') == 'Car A' %}
            {{ states('sensor.car_a_battery') }}
          {% else %}
            {{ states('sensor.car_b_battery') }}
          {% endif %}
        availalitity: >-
          {% if states('input_select.car_connected') == 'Car A' %}
            {{ has_value('sensor.car_a_battery') }}
          {% else %}
            {{ has_value('sensor.car_b_battery') }}
          {% endif %}

Waar ik even uit ga van een input_select die de juiste auto aangeeft maar logica zou je er ook direct in kunnen doen, wat je wilt. device_class en unit_of_measurment gelijk zetten aan die van de auto's.

Dit lukt t/m de template editor. Daar ziet het er goed uit qua waardes zodra ik mijn entiteiten invul. Ik heb van de template een .jinja bestand gemaakt en dit in de /homeassistant/custom_templates/ directory gezet. Daarna HA een restart gegeven maar ik mis even een stukje hoe ik de waarde uit deze template kan gebruiken in m'n integratie of dat ik eerst een tussenstap moet maken met een helper die naar deze template kijkt.

[Faece]

Bestaat er een integratie waarbij ik bv prijzen van een item op Bol, Amazon en aanverwanten kan zien ?

Zit met de idee om bv wanneer een bepaalde inktcartridge leeg is, een mail te sturen met daarin een link naar het item van de shop waar het goedkoopste is. Zo moet mijn vrouw enkel maar klikken en bestellen ....

[hemertje]

avdwerf schreef op maandag 12 mei 2025 @ 10:15:
[...]


Gister dus getest, zodra je de powerlimit aanzet past hij binnen een paar seconden het vermogen aan.

welke blueprint heb je hiervoor nu gebruikt?

[hemertje]

achterhoeker schreef op maandag 12 mei 2025 @ 10:26:
Ik gebruik ook de modbus multi integratie om de omvormer naar 0% te schakelen zodra via de tibber integratie de prijs onder de 0 zakt. Ik krijg via de home assistant een melding zodat ik evt nog andere stroomslurpers kan aanzetten. Tegelijkertijd gaat de smartevse laadpaal de instructie om op smart te gaan staan wanneer er een auto verbonden is om dat ook te maximaliseren. Werkt perfect en uit en inschakelen is praktisch zonder vertraging.

Hoi @achterhoeker

kan je deze veredelde gebruiker in jip en janneke taal uitleggen hoe je de modbus multi integratie om de omvormer naar 0% te schakelen via de tibber integratie hebt gerealiseerd?

[PisPix]

PisPix schreef op maandag 12 mei 2025 @ 13:01:
[...]


Dit lukt t/m de template editor. Daar ziet het er goed uit qua waardes zodra ik mijn entiteiten invul. Ik heb van de template een .jinja bestand gemaakt en dit in de /homeassistant/custom_templates/ directory gezet. Daarna HA een restart gegeven maar ik mis even een stukje hoe ik de waarde uit deze template kan gebruiken in m'n integratie of dat ik eerst een tussenstap moet maken met een helper die naar deze template kijkt.

Het is gelukt, de template moet in de configuration.yaml. Daarna HA een reload gegeven en de sensor.connected_car_battery werd beschikbaar. Deze in de EV Smart Charging integratie kunnen zetten en nu werkt het! Super bedankt, weer wat geleerd. Er zat alleen nog een tikfout in de code (availalitity <> availability) maar die was gauw gevonden door de notificatie van HA daarover. Dank @Septillion !

[achterhoeker]

hemertje schreef op maandag 12 mei 2025 @ 13:49:
[...]


Hoi @achterhoeker

kan je deze veredelde gebruiker in jip en janneke taal uitleggen hoe je de modbus multi integratie om de omvormer naar 0% te schakelen via de tibber integratie hebt gerealiseerd?

in de meest simpele vorm zo:
ik ben niet zo van de blueprints en optimaliseren. als het werkt het in m'n ratjetoe van homeassistant.
Ik heb geen enkele instelling in m'n solaredge gewijzigd. Namen van sensors e.d. kunnen bij jou natuurlijk anders zijn.

YAML:

alias: Zonnepanelen uit bij negatieve stroomprijs
description: ""
triggers:
  - trigger: numeric_state
    entity_id:
      - sensor.thuus_elektriciteitsprijs
    below: 0
conditions: []
actions:
  - action: number.set_value
    metadata: {}
    data:
      value: 0
    target:
      entity_id: number.solaredge_i1_active_power_limit
  - wait_for_trigger:
      - trigger: numeric_state
        entity_id:
          - sensor.thuus_elektriciteitsprijs
        above: 0
  - action: number.set_value
    metadata: {}
    data:
      value: 100
    target:
      entity_id: number.solaredge_i1_active_power_limit
mode: single

[zunrob]

Er is me iets niet helemaal duidelijk. Tot gisteravond gebruikte ik de officiële SolarEdge integratie, nu gebruik ik de modbus variant. In het energie dashboard heb ik de oude lifetime energy van de officiële integratie voor nu vervangen door die van de modbus, waarbij ik even geen ID's heb hernoemd. Dus er is geen geschiedenis overgezet.

Heb ik de oude lifetime energy nog in mijn dashboard staan dan zie ik voor gister:


Haal ik de lifetime energy van de originele integratie eruit, dan zie ik dit:


De hoeveelheid verbruikte energie staat dan opeens op 0. Dat snap ik eigenlijk niet. Die waardes heeft ie al een keer berekend, waarom verdwijnen die nu?

[TheFes]

zunrob schreef op maandag 12 mei 2025 @ 14:24:
Er is me iets niet helemaal duidelijk. Tot gisteravond gebruikte ik de officiële SolarEdge integratie, nu gebruik ik de modbus variant. In het energie dashboard heb ik de oude lifetime energy van de officiële integratie voor nu vervangen door die van de modbus, waarbij ik even geen ID's heb hernoemd. Dus er is geen geschiedenis overgezet.

Heb ik de oude lifetime energy nog in mijn dashboard staan dan zie ik voor gister:
[Afbeelding]

Haal ik de lifetime energy van de originele integratie eruit, dan zie ik dit:
[Afbeelding]

De hoeveelheid verbruikte energie staat dan opeens op 0. Dat snap ik eigenlijk niet. Die waardes heeft ie al een keer berekend, waarom verdwijnen die nu?

Welke periode is dit nu?
Want met 74kWh teruglevering en 20kWh solar opbrengst zit je op een negatief verbruik
De waardes worden dynamisch berekend, elke keer als je het dashboard opent en op basis van je selecteerde datum range, dus als je data weghaalt dan wordt het ook opnieuw berekend.

[ Voor 6% gewijzigd door TheFes op 12-05-2025 14:37 ]

[Jag]

RudolfR schreef op zaterdag 10 mei 2025 @ 12:23:
[...]


Misschien geeft dit wat inspiratie?

YAML:

- trigger:
    - platform: time_pattern
      hours: "/1"
    - platform: event
      event_type: event_template_reloaded
  action:
    - service: weather.get_forecasts
      data:
        type: hourly
      target:
        entity_id: weather.home
      response_variable: hourly
  sensor:
    - name: Weather Forecast Hourly
      unique_id: 02330e21-00eb-4951-9fc2-835d351a4fd2
      state: "{{ now().isoformat() }}"
      attributes:
        forecast: "{{ hourly['weather.home'].forecast }}"
    - name: "Forecast temperature hourly"
      unique_id: 0055c4eb-f8e3-4196-a7ec-67f6ea4b15b5
      state: "{{ hourly['weather.home'].forecast.0.temperature }}"
    - name: "Forecast daily temperature min"
      unique_id: 64808014-939f-44e2-9189-439eb0d03978
      state: >
        {% set fc = hourly['weather.home'].forecast %}
        {% set temperatures = fc|map(attribute='temperature')|list %}
        {{ temperatures | min }}
    - name: "Forecast daily temperature max"
      unique_id: fba4f0d4-433e-4f78-af22-d06622ab5184
      state: >
        {% set fc = hourly['weather.home'].forecast %}
        {% set temperatures = fc|map(attribute='temperature')|list %}
        {{ temperatures | max }}

Nou het is gelukt, met wat hulp van GoT en beetje chatgpt, Het oogt voor mij als chatgpt programmeur erg omslachtig om met twee tussenstappen / variabelen om in op te slaan uiteindelijk twee input nummers te maken. Maar ben al lang blij dat het werkt, best wat tijd op stukgeslagen

YAML:

  - id: ems_fetch_and_store_forecast_data
    alias: "EMS - Fetch and Store Forecast Data"
    trigger:
      - platform: time
        at: "08:00:00"
    mode: single
    action:
      - service: weather.get_forecasts
        target:
          entity_id: weather.forecast_thuis
        data:
          type: hourly
        response_variable: forecast_data

      - variables:
          forecast: "{{ forecast_data['weather.forecast_thuis'].forecast }}"
          avg_24h: >
            {% if forecast | length >= 24 %}
              {{ forecast[:24] | map(attribute='temperature') | average | round(1) }}
            {% else %}
              0
            {% endif %}
          night_low: >
            {% set night_hours = forecast[18:24] | map(attribute='temperature') | list %}
            {% if night_hours %}
              {{ night_hours | min }}
            {% else %}
              0
            {% endif %}

      - service: input_number.set_value
        data:
          entity_id: input_number.ems_avg_temperature_forecast_next_24_hours
          value: "{{ avg_24h }}"

      - service: input_number.set_value
        data:
          entity_id: input_number.ems_night_low_temp_next_night
          value: "{{ night_low }}"

Met ook dank aan @bvw @TheFes @ThinkPad



Dit ga ik nog uitbreiden met ook opwarmen van verwarmingsbuffer (200L vat en 500L vat) en EV laden. Dan komen er 6 mogelijke ladingen:

SWW run
SWW boost
Verwarmings buffer opladen
Verwarmings buffer boost
EV opladen
Accu opladen

Ik wil gaan werken met een prioriteits score op basis van buffer vulling en seizoenstype (die wordt nu dagelijks bepaald).

Bij PV excess obv prioriteitsscore lading starten
Bij lading compleet opnieuw obv prioriteitsscore lading starten

Alle laadacties zijn rond de 3kW verbruik, alleen de boost gaat met de immersion heater die exact te moduleren is. Bij veel PV overschot kan er dus een 2e lading gestart worden.

Lastige punten:
- Welke parameter gebruiken voor 1 of 2 ladingen starten: actuele gegevens overschot kan maar geeft wel risico van vaak aan en uit schakelen. Alternatief zou forecast data gebruiken. Dan denk ik wel thuisaccu nodig (wil ik uiteindelijk sowieso).
- hoe hysteresis toe te voegen. Misschien dat het wel goed gaat met gewoon de prioriteitsscore obv buffer lading.

[ Voor 18% gewijzigd door Jag op 12-05-2025 15:45 ]

[Cimpel]

Wellicht dat een van jullie licht in de duisternis kan scheppen.
Ik heb een helper aangemaakt die de (oplopende) waardes van de Elektra teruglevering Normaal en Dal bij elkaar optelt (kWh, energie, oplopend). Deze gebruik ik in het Energiedashboard bij de monitor van individuele apparaten.
So far so good. Hij wordt getoond in samenhang met de andere apparaten en het dagelijkse verbruik/teruglevering.
Echter: zodra HA een herstart heeft geeft het energiedashboard niet meer de dagelijkse opbrengst weer maar de totale waarde (over alle jaren). Een dag daarna is het weer Ok en toont het weer de dagopbrengst.
Het lijkt erop dat na een HA herstart, het energiedashboard de initiële waarde op 0 zet ipv. de laatste waarde te gebruiken.

Iemand een idee ?

[TheFes]

Jag schreef op maandag 12 mei 2025 @ 14:46:
[...]

Nou het is gelukt, met wat hulp van GoT en beetje chatgpt, Het oogt voor mij als chatgpt programmeur erg omslachtig om met twee tussenstappen / variabelen om in op te slaan uiteindelijk twee input nummers te maken. Maar ben al lang blij dat het werkt, best wat tijd op stukgeslagen

YAML:

  - id: ems_fetch_and_store_forecast_data
    alias: "EMS - Fetch and Store Forecast Data"
    trigger:
      - platform: time
        at: "08:00:00"
    mode: single
    action:
      - service: weather.get_forecasts
        target:
          entity_id: weather.forecast_thuis
        data:
          type: hourly
        response_variable: forecast_data

      - variables:
          forecast: "{{ forecast_data['weather.forecast_thuis'].forecast }}"
          avg_24h: >
            {% if forecast | length >= 24 %}
              {{ forecast[:24] | map(attribute='temperature') | average | round(1) }}
            {% else %}
              0
            {% endif %}
          night_low: >
            {% set night_hours = forecast[18:24] | map(attribute='temperature') | list %}
            {% if night_hours %}
              {{ night_hours | min }}
            {% else %}
              0
            {% endif %}

      - service: input_number.set_value
        data:
          entity_id: input_number.ems_avg_temperature_forecast_next_24_hours
          value: "{{ avg_24h }}"

      - service: input_number.set_value
        data:
          entity_id: input_number.ems_night_low_temp_next_night
          value: "{{ night_low }}"

Met ook dank aan @bvw @TheFes @ThinkPad

[Afbeelding]

Dit ga ik nog uitbreiden met ook opwarmen van verwarmingsbuffer (200L vat en 500L vat) en EV laden. Dan komen er 6 mogelijke ladingen:

SWW run
SWW boost
Verwarmings buffer opladen
Verwarmings buffer boost
EV opladen
Accu opladen

Ik wil gaan werken met een prioriteits score op basis van buffer vulling en seizoenstype (die wordt nu dagelijks bepaald).

Bij PV excess obv prioriteitsscore lading starten
Bij lading compleet opnieuw obv prioriteitsscore lading starten

Alle laadacties zijn rond de 3kW verbruik, alleen de boost gaat met de immersion heater die exact te moduleren is. Bij veel PV overschot kan er dus een 2e lading gestart worden.

Lastige punten:
- Welke parameter gebruiken voor 1 of 2 ladingen starten: actuele gegevens overschot kan maar geeft wel risico van vaak aan en uit schakelen. Alternatief zou forecast data gebruiken. Dan denk ik wel thuisaccu nodig (wil ik uiteindelijk sowieso).
- hoe hysteresis toe te voegen. Misschien dat het wel goed gaat met gewoon de prioriteitsscore obv buffer lading.

Maar nu kun je dus in je kaartje de waardes wijzigen (en die worden dan na maximaal een uur om 8:00 's morgens weer overschreven met de de waarde uit de forecast. Als je template sensoren gebruikt ipv input_numbers, krijg je een waarde zoals PV Power Produced die dus verder niet in de GUI aan te passen is. Dat lijkt me hier logischer.

Verder is de tussenstap met de variables natuurlijk niet nodig, je kunt ook gewoon dit doen (heb ook je templates wat versimpeld):

YAML:

    action:
      - service: weather.get_forecasts
        target:
          entity_id: weather.forecast_thuis
        data:
          type: hourly
        response_variable: forecast_data

      - service: input_number.set_value
        data:
          entity_id: input_number.ems_avg_temperature_forecast_next_24_hours
          value: >
            {{
              forecast_data['weather.forecast_thuis'].forecast[:24]
                | map(attribute='temperature')
                | average(default=0)
                | round(1)
            }}

      - service: input_number.set_value
        data:
          entity_id: input_number.ems_night_low_temp_next_night
          value: >
            {{
              forecast_data['weather.forecast_thuis'].forecast[18:24]
                | map(attribute='temperature')
                | min
                | default(0, true)
            }}

[TheFes]

Cimpel schreef op maandag 12 mei 2025 @ 15:24:
Wellicht dat een van jullie licht in de duisternis kan scheppen.
Ik heb een helper aangemaakt die de (oplopende) waardes van de Elektra teruglevering Normaal en Dal bij elkaar optelt (kWh, energie, oplopend). Deze gebruik ik in het Energiedashboard bij de monitor van individuele apparaten.
So far so good. Hij wordt getoond in samenhang met de andere apparaten en het dagelijkse verbruik/teruglevering.
Echter: zodra HA een herstart heeft geeft het energiedashboard niet meer de dagelijkse opbrengst weer maar de totale waarde (over alle jaren). Een dag daarna is het weer Ok en toont het weer de dagopbrengst.
Het lijkt erop dat na een HA herstart, het energiedashboard de initiële waarde op 0 zet ipv. de laatste waarde te gebruiken.

Iemand een idee ?

Niet zonder te weten hoe je die helper aangemaakt hebt, wat voor type helper? Welke instellingen?

[Cimpel]

TheFes schreef op maandag 12 mei 2025 @ 16:00:
[...]


Niet zonder te weten hoe je die helper aangemaakt hebt, wat voor type helper? Welke instellingen?

De herlper is aangemaakt via de UI als type template-sensor met de instellingen meeteenheid: kWh, apparaatklasse: Energie, statusklasse: Totaal oplopend

[TheFes]

Cimpel schreef op maandag 12 mei 2025 @ 16:06:
[...]

De herlper is aangemaakt via de UI als type template-sensor met de instellingen meeteenheid: kWh, apparaatklasse: Energie, statusklasse: Totaal oplopend

En, meest belangrijke dan, welk template?

[Cimpel]

TheFes schreef op maandag 12 mei 2025 @ 16:08:
[...]


En, meest belangijke dan, welk template?

Sensor template

[TheFes]

Cimpel schreef op maandag 12 mei 2025 @ 16:09:
[...]

Sensor template

Ik moet het template zelf hebben, het stukje tekst met de de accolades ({{ en en }} en mogelijk {% en %})

[Cimpel]

TheFes schreef op maandag 12 mei 2025 @ 16:11:
[...]


Ik moet het template zelf hebben, het stukje tekst met de de accolades ({{ en en }} en mogelijk {% en %})

YAML:

 
{{ states('sensor.electricity_meter_energieproductie_tarief_1')|float(0) + states('sensor.electricity_meter_energieproductie_tarief_2')|float(0) }}

[Septillion]

@Cimpel Daar zit je fout, je gebruikt een float filter met default 0. Tijdens starten zijn ze er waarschijnlijk niet gelijk dus rendert de template even 0 + 0 = 0. En dat wordt gezien als reset van de meter.

Mooiste oplossing is om availability te gebruiken maar dat kan niet via de UI. Alternatief is om none te renderen zodra een van de twee sensoren geen waarde heeft. Je wilt immers niet dat die sensor ooit per ongeluk dus omlaag gaat.

[avdwerf]

hemertje schreef op maandag 12 mei 2025 @ 13:41:
[...]


welke blueprint heb je hiervoor nu gebruikt?

Uuhm, geen blueprint (denk ik, nog nooit mee gewerkt) maar home-assistant-solaredge-modbus
via HACS.

[Cimpel]

Septillion schreef op maandag 12 mei 2025 @ 16:19:
@Cimpel Daar zit je fout, je gebruikt een float filter met default 0. Tijdens starten zijn ze er waarschijnlijk niet gelijk dus rendert de template even 0 + 0 = 0. En dat wordt gezien als reset van de meter.

Mooiste oplossing is om availability te gebruiken maar dat kan niet via de UI. Alternatief is om none te renderen zodra een van de twee sensoren geen waarde heeft. Je wilt immers niet dat die sensor ooit per ongeluk dus omlaag gaat.

Thx, ga ik uitproberen. Test op availability van de sensors er omheen zetten dus.

[zunrob]

TheFes schreef op maandag 12 mei 2025 @ 14:36:
[...]


Welke periode is dit nu?
Want met 74kWh teruglevering en 20kWh solar opbrengst zit je op een negatief verbruik
De waardes worden dynamisch berekend, elke keer als je het dashboard opent en op basis van je selecteerde datum range, dus als je data weghaalt dan wordt het ook opnieuw berekend.

Beide screenshots zijn van gister. In de ene heb ik PV opbrengst toegevoegd als parameter, in de andere heb ik deze weggehaald. Ik zou verwachten dat ook in het scenario waar ik hem weghaal hij berekent hoeveel ik verbruikt heb; in de nacht had ik wel gewoon verbruik zonder dat er werd terug geleverd. Zoals je links ook ziet is er daadwerkelijk wel afname van het net geweest. Dus ja, de totalen kloppen niet, en dan zou het negatief zijn, maar de verbruiksberekening voert ie (naar het mij lijkt) per uur uit. Dan had ik dus eigenlijk wel rechtsonder ook gegevens verwacht.

[zunrob]

Zoals hier eerder gepost ben ik van de SolarEdge integratie naar de SolarEdge modbus integratie gegaan. Nu zou ik graag de oude data meenemen naar de nieuwe. Het is mogelijk om dit te doen door de entiteit in de nieuwe integratie de naam van de oude te geven, echter, als je de integratie opnieuw instelt gaat ie terug naar de standaard naam. Niet zo handig. Daarom heb ik onderstaande bedacht. Ben benieuwd of iemand kan zeggen of dit werkt.

Entity ID in de SolarEdge integratie: solaredge_lifetime_energy
Entity ID in de SolarEdge modbus integratie: solaredge_modbus_ac_energy_kwh

Ik wil dus dat alle data die nu al staat in solaredge_lifetime_energy komt te staan onder solaredge_modbus_ac_energy_kwh.

Stappenplan:
1) Terwijl de SolarEdge integratie nog gewoon werkt installeer je ook de modbus integratie. Dit puur en alleen om de naam van het ID te weten te komen. Dit is dus solaredge_modbus_ac_energy_kwh. Je laat de integratie kort draaien.
2) Je verwijdert de modbus integratie weer. Bij 'Ontwikkelingshulpmiddelen' kun je nu onder statistieken solaredge_modbus_ac_energy_kwh verwijderen, omdat deze wordt weergegeven als niet meer beschikbaar. Doe je dit niet dan blijft de ID bestaan, en is er al een stukje geschiedenis.
3) In de gewone SolarEdge integratie wijzig je het ID (met dus alle geschiedenis) van solaredge_lifetime_energy naar solaredge_modbus_ac_energy_kwh. Je maakt hiermee dus een nieuw ID aan, waar al je geschiedenis naar over gaat.
4) Je verwijdert de SolarEdge integratie.
5) Je start de SolarEdge modbus integratie. Omdat de standaard naam solaredge_modbus_ac_energy_kwh is, en deze al bestaat (met geschiedenis) zal deze gebruikt blijven worden en heb je dus de geschiedenis, plus de 'juiste' naam die de integratie zelf al aan de entity toewijzen.

Zou dit werken of zie ik iets over het hoofd?

[ Voor 6% gewijzigd door zunrob op 12-05-2025 16:59 ]

[Septillion]

@Cimpel Iets als:

Django/Jinja:

{% set a = states('sensor.electricity_meter_energieproductie_tarief_1')|float(none) %}
{% set b = states('sensor.electricity_meter_energieproductie_tarief_2')|float(none) %}
{% if a is none or b is none %}
  none
{% else %}
  {{ a + b }}
{% endif %}

[Septillion]

@zunrob Het energy dashboard maakt gebruik van de long term statistics (LTS). Deze worden per uur berekend.

Verder slaat het energy dashboard zelf geen gegevens op. Het wordt dus 100% berekend aan de hand van de LTS die je op dat moment hebt opgegeven. Dus ook voor het verleden wordt alleen naar het verleden gekeken van de NU opgegeven sensoren.

Vandaar dus dat bij wijzigen van bron nog wel eens het trucje uitgehaald wordt om de nieuwe sensor hetzelfde entity id te geven als de oude. Op die manier wordt de LTS van de oude en nieuwe sensor aan elkaar geplakt.

[Cimpel]

Septillion schreef op maandag 12 mei 2025 @ 17:03:
@Cimpel Iets als:

Django/Jinja:

{% set a = states('sensor.electricity_meter_energieproductie_tarief_1')|float(none) %}
{% set b = states('sensor.electricity_meter_energieproductie_tarief_2')|float(none) %}
{% if a is none or b is none %}
  none
{% else %}
  {{ a + b }}
{% endif %}

Ik heb er nu dit van gemaakt:

YAML:

 
{% if has_value('sensor.electricity_meter_energieproductie_tarief_1') and has_value('sensor.electricity_meter_energieproductie_tarief_2') %}
{{ states('sensor.electricity_meter_energieproductie_tarief_1')|float(0) + states('sensor.electricity_meter_energieproductie_tarief_2')|float(0) }}
{% endif %}

Nog niet getest met een herstart

[TheFes]

zunrob schreef op maandag 12 mei 2025 @ 16:57:
Zoals hier eerder gepost ben ik van de SolarEdge integratie naar de SolarEdge modbus integratie gegaan. Nu zou ik graag de oude data meenemen naar de nieuwe. Het is mogelijk om dit te doen door de entiteit in de nieuwe integratie de naam van de oude te geven, echter, als je de integratie opnieuw instelt gaat ie terug naar de standaard naam. Niet zo handig. Daarom heb ik onderstaande bedacht. Ben benieuwd of iemand kan zeggen of dit werkt.

Entity ID in de SolarEdge integratie: solaredge_lifetime_energy
Entity ID in de SolarEdge modbus integratie: solaredge_modbus_ac_energy_kwh

Ik wil dus dat alle data die nu al staat in solaredge_lifetime_energy komt te staan onder solaredge_modbus_ac_energy_kwh.

Stappenplan:
1) Terwijl de SolarEdge integratie nog gewoon werkt installeer je ook de modbus integratie. Dit puur en alleen om de naam van het ID te weten te komen. Dit is dus solaredge_modbus_ac_energy_kwh. Je laat de integratie kort draaien.
2) Je verwijdert de modbus integratie weer. Bij 'Ontwikkelingshulpmiddelen' kun je nu onder statistieken solaredge_modbus_ac_energy_kwh verwijderen, omdat deze wordt weergegeven als niet meer beschikbaar. Doe je dit niet dan blijft de ID bestaan, en is er al een stukje geschiedenis.
3) In de gewone SolarEdge integratie wijzig je het ID (met dus alle geschiedenis) van solaredge_lifetime_energy naar solaredge_modbus_ac_energy_kwh. Je maakt hiermee dus een nieuw ID aan, waar al je geschiedenis naar over gaat.
4) Je verwijdert de SolarEdge integratie.
5) Je start de SolarEdge modbus integratie. Omdat de standaard naam solaredge_modbus_ac_energy_kwh is, en deze al bestaat (met geschiedenis) zal deze gebruikt blijven worden en heb je dus de geschiedenis, plus de 'juiste' naam die de integratie zelf al aan de entity toewijzen.

Zou dit werken of zie ik iets over het hoofd?

Dat zou moeten werken, maar andersom zou het ook moeten werken

1. Noteer entity id van huidige SolarEdge integratie
2. Verwijder SolarEdge integratie
3. Installeer Modbus integratie
4. Hermoen entity id van Modbus naar integratie naar entity_id genoemd bij stap 1

[zunrob]

TheFes schreef op maandag 12 mei 2025 @ 17:13:
[...]


Dat zou moeten werken, maar andersom zou het ook moeten werken

1. Noteer entity id van huidige SolarEdge integratie
2. Verwijder SolarEdge integratie
3. Installeer Modbus integratie
4. Hermoen entity id van Modbus naar integratie naar entity_id genoemd bij stap 1

Klopt, dat werkt. Maar dan gebruik je dus het entity_id van de oorspronkelijke SolarEdge integratie (solaredge_lifetime_energy). Ik zie hier diverse nadelen.
1) De modbus integratie heeft een andere standaardnaam voor het entity_id (solaredge_modbus_ac_energy_kwh). Mocht je de modbus integratie een keer opnieuw instellen, bijv. omdat je het polling interval aan wilt passen, dan moet je dus wel onthouden hebben dat je de standaard naam solaredge_modbus_ac_energy_kwh ooit hebt aangepast naar solaredge_lifetime_energy. Anders ben je alsnog je geschiedenis dan kwijt als je het ID niet meer weet.
2) Als je oorspronkelijke SolarEdge integratie alsnog (tegelijk) ook zou willen gebruiken moet je de standaardnaam daar aanpassen.

Dan is mijn voorstel toch handiger?

[zunrob]

RobertMe schreef op vrijdag 9 mei 2025 @ 16:40:
[...]

Als de polling van HA naar SE achter loopt (of de data aanlevering van de PV naar de SE cloud) zal er dus ineens een spike in opwek zijn. En gezien HA geen spike in teruglevering ziet is dat allemaal eigen verbruik.

Uiteraard dus afkomstig uit dat HA zijn eigen statistieken bijhoudt en puur naar de meterstand is. Waarom die meterstand bv 3 uren "stil staat" en het vierde uur ineens met 10kWh toeneemt weet HA niet. Die heeft gewoon 3 uur 0kWh opwek en het vierde uur 10kWh opwek. Kijk je vervolgens bij SE zelf zie je daar wel correct grafieken met zeg ~2,5kWh opwek per uur, want de cloud heeft het wel correct geregistreerd (en de PV doet intern de data ook zodanig opslaan dat ook met uren of dagen downtime van de aanlevering de gegevens wel nog per uur etc zijn en je in de SE cloud dus nog steeds ziet wat er per uur is opgewekt).

En in zo'n situatie zal HA dus uit P1 0kWh afname halen (of als je pech hebt met een klapperende PV door te hoge netspanning ook nog daadwerkelijk verbruik) en wel teruglevering. Maar dus teruglevering die niet is opgewekt / geregistreerd. Maar het 4e uur lever je bv 2kWh terug, tegenover 10kWh opwek, dus beredeneert HA dat je 7,5kWh eigen verbruik had.
En in minder extreme gevallen kan het nog steeds zo zijn dat HA bv om x:46 pollt en om x+1:01 pollt (geen idee wat het poll interval van HA is en het aanlever interval van de PV naar de cloud). Dan mist die dus nog steeds 14 minuten aan opwek in dat uur, dat het volgende uur er bij wordt geteld. Terwijl de teruglevering in dat uur wel klopt.

Lees je de omvormer lokaal uit via modbus over TCP ben je niet afhankelijk van een cloud omgeving, en heb je de mogelijkheid tot een poll interval (over modbus) tot zelfs 1 seconde (standaard van een van de 2 integraties is 5 seconden bv). Waardoor de gegevens veel minder "scheef" lopen tussen PV meterstand en meterstand van de energiemeter.

Hier twee plaatjes.

Hieronder met de standaard SolarEdge integratie. Zie hoe de laatste uren er opeens een groot gedeelte niet getraceerd is:


Hier met de modbus integratie:

[Faece]

YAML:

 
              - type: custom:mushroom-template-card
                primary: "{{ states('sensor.hp_deskjet_4200_series_tri_color_ink')| float | round(0) }}% "
                card_mod:
                  style:
                    mushroom-state-info$: |
                      .container {
                        margin-left: 48px;
                      }
                      .primary {
                        {% set level = states('sensor.hp_deskjet_4200_series_tri_color_ink') | float %}
                        {% set r = 255 - (level * 2.55) | round(0) %}
                        {% set g = (level * 2.55) | round(0) %}
                        {% set b = 0 %}
                        color: #{{ '{:02x}{:02x}{:02x}'.format(r, g, b) }};
                      }
                    .: |
                      ha-card {
                        margin-top: 8px;
                      }

ik wil de kleur van mijn tekst aanpassen aan de waarde van de state, maar dit blijkt niet te werken. iemand een idee ?

[Toppe]

nvm

[ Voor 99% gewijzigd door Toppe op 12-05-2025 20:33 ]

[zunrob]

zunrob schreef op maandag 12 mei 2025 @ 16:57:
Zoals hier eerder gepost ben ik van de SolarEdge integratie naar de SolarEdge modbus integratie gegaan. Nu zou ik graag de oude data meenemen naar de nieuwe. Het is mogelijk om dit te doen door de entiteit in de nieuwe integratie de naam van de oude te geven, echter, als je de integratie opnieuw instelt gaat ie terug naar de standaard naam. Niet zo handig. Daarom heb ik onderstaande bedacht. Ben benieuwd of iemand kan zeggen of dit werkt.

Entity ID in de SolarEdge integratie: solaredge_lifetime_energy
Entity ID in de SolarEdge modbus integratie: solaredge_modbus_ac_energy_kwh

Ik wil dus dat alle data die nu al staat in solaredge_lifetime_energy komt te staan onder solaredge_modbus_ac_energy_kwh.

Stappenplan:
1) Terwijl de SolarEdge integratie nog gewoon werkt installeer je ook de modbus integratie. Dit puur en alleen om de naam van het ID te weten te komen. Dit is dus solaredge_modbus_ac_energy_kwh. Je laat de integratie kort draaien.
2) Je verwijdert de modbus integratie weer. Bij 'Ontwikkelingshulpmiddelen' kun je nu onder statistieken solaredge_modbus_ac_energy_kwh verwijderen, omdat deze wordt weergegeven als niet meer beschikbaar. Doe je dit niet dan blijft de ID bestaan, en is er al een stukje geschiedenis.
3) In de gewone SolarEdge integratie wijzig je het ID (met dus alle geschiedenis) van solaredge_lifetime_energy naar solaredge_modbus_ac_energy_kwh. Je maakt hiermee dus een nieuw ID aan, waar al je geschiedenis naar over gaat.
4) Je verwijdert de SolarEdge integratie.
5) Je start de SolarEdge modbus integratie. Omdat de standaard naam solaredge_modbus_ac_energy_kwh is, en deze al bestaat (met geschiedenis) zal deze gebruikt blijven worden en heb je dus de geschiedenis, plus de 'juiste' naam die de integratie zelf al aan de entity toewijzen.

Zou dit werken of zie ik iets over het hoofd?

Ok, het is gelukt, maar anders dan hoe ik hierboven zei. Voor wie ook ooit tegen dit probleem aanloopt, hieronder de oplossing.

Probleem
Je hebt een nieuwe entiteit die een oude gaat vervangen, in mijn geval doordat ik een andere integratie ging gebruiken voor mijn zonnepanelen. Ik wou de geschiedenis van de sensor 'vermogen' behouden.

Oplossing

1. In de oude integratie, zoek de entiteit op waarvan je de geschiedenis wilt bewaren, en noteer het Entiteits-ID.
2. Verwijder de oude integratie. Onder Ontwikkelhulpmiddelen en dan Statistieken zul je zien dat de oude entiteit met zijn Statistiek-ID ergens bovenaan staat, en aangeeft dat er een probleem is. Hier doe je niks mee.
3. Start de nieuwe integratie. De nieuwe entiteit krijgt vanzelf een standaard Entiteits-ID vanuit de integratie. Noteer dit standaard Entiteits-ID.
4. Laat deze integratie nu even lopen totdat je ziet dat er minstens 1 geschiedenis-punt is opgeslagen. In mijn geval gebeurde dat steeds op 5 hele minuten.
5. Nu pas je het Statistiek-ID van deze nieuwe entiteit (in de nieuwe integratie) aan naar het oude Statistiek-ID, welke je bij de eerste stap hebt genoteerd. Je ziet dat je nu meteen ook de historie weer hebt.
6. Ga naar Ontwikkelhulpmiddelen en dan Statistieken. Je zult nu zien dat nu het standaard Entiteits-ID van de nieuwe integratie vrij bovenaan staat met de opmerking dat er een probleem mee is. Klik op OPLOSSEN en vervolgens op VERWIJDEREN.
7. Nu kun je van je nieuwe entiteit het Entiteits-ID aanpassen naar de naam die hij standaard had gekregen, en je bij stap 3 hebt opgeschreven.

Met deze werkwijze behoud je je geschiedenis van de oude sensor, en zorg je dat die terecht komt onder de standaard naam van de sensor in de nieuwe integratie. Voordeel hiervan is dat als je de integratie een keer opnieuw aan moet maken, bijv. om iets in de configuratie te wijzigen, je vanzelf de geschiedenis behoudt. Je hoeft dan niet steeds te onthouden wat ook al weer het oude Entiteits-ID was.

[hemertje]

je hebt dus de home-assistant-solaredge-modbus via HACS geinstalleerd?

[zunrob]

hemertje schreef op maandag 12 mei 2025 @ 21:54:
je hebt dus de home-assistant-solaredge-modbus via HACS geinstalleerd?

Niet via HACS, maar gewoon gekopieerd naar de betreffende folder. Maar idd, gebruik nu die integratie.

[avdwerf]

hemertje schreef op maandag 12 mei 2025 @ 21:54:
je hebt dus de home-assistant-solaredge-modbus via HACS geinstalleerd?

Ik heb hem wel via hacs, werkt perfect 👌

[krizzziz]

Kennelijk heeft na een stroomstoring mijn minipc (waar HA op draait via Proxmox) het probleem dat de add-on Zigbee2MQTT mijn Conver stick niet meer vindt. Ik krijg deze foutmelding

code:

 error:     z2m: Error: Error while opening serialport 'Error: Error: No such file or directory, cannot open /dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2432978-if00'
    at SerialPort.<anonymous> (/app/node_modules/.pnpm/zigbee-herdsman@4.0.0/node_modules/zigbee-herdsman/src/adapter/deconz/driver/driver.ts:211:28)
    at SerialPort._error (/app/node_modules/.pnpm/@serialport+stream@13.0.0/node_modules/@serialport/stream/dist/index.js:82:22)
    at /app/node_modules/.pnpm/@serialport+stream@13.0.0/node_modules/@serialport/stream/dist/index.js:118:18

Ik heb de usb stick eruit en weer in gedaan, ook andere usb poort geprobeerd en deze ook aan proxmox toegevoegd.

Echter lijkt de stick niet meer tevoorschijn te komen binnen HA. Iemand nog een tip? Kan de stick ook dood zijn?

[ocf81]

Ik heb opeens het probleem dat ik niet meer bij de webinterface mijn HA installatie kan via DNS. Het is een VM installatie die op Proxmox draait. Ik kan nog wel bij de CLI en de ZigBee knoppen in mijn appartement werken nog wel. Als ik het IP-adres invoer in plaats van homeassistant.local:8123 krijg ik een wit scherm met het HA logo.Als ik het op IP adres probeer lukt het wel maar dan zit noScript in de weg

Weet iemand wat hier de oorzaak van kan zijn? Gisteren werkte alles nog oké. Andere lokale DNS lookups lijken gewoon te werken?

[ Voor 15% gewijzigd door ocf81 op 13-05-2025 00:23 ]

[Septillion]

@ocf81
- Al dus gewoon een DNS resolve gedaan, die is correct?
- Draai je werkelijk een DNS server of gebruik je mDNS?
- Op alle machines last van?

[Septillion]

@krizzziz Je ziet hem dus wel in zowel Proxmox als in HA (na de passthrough)?

En path is 100% correct met wat je via Settings => System => Hardware => All hardware ziet?

Want de error geeft wel echt aan dat het niet bestaat, niet dat hij niet gebruikt kan worden.

[Gizz]

@krizzziz en staat andere software die je stickje kan kapen uit? Denk aan ZHA, Deconz.
Je stick kan maar door één pakket tegelijk gebruikt worden.

[ocf81]

Septillion schreef op dinsdag 13 mei 2025 @ 09:59:
@ocf81
- Al dus gewoon een DNS resolve gedaan, die is correct?
- Draai je werkelijk een DNS server of gebruik je mDNS?
- Op alle machines last van?

HA draait inderdaad met mDNS, dat was ik even vergeten. Maar op de een of andere manier gaat dat opeens niet meer. Ook niet op mijn laptop. Ik denk dat ik eens moet kijken naar hoe dat in OPNsense is ingesteld.

[Septillion]

@ocf81 Dan moet je daar inderdaad wel mDNS toestaan. Ook moet je in hetzelfde netwerk / VLAN zitten. Anders moet je met deflectors aan de gang.

Feit dat het op IP prima werkt (immers is noScript dan gewoon onnodig aan het zeuren) doet mij ook eerder een netwerk issue vermoeden.

[krizzziz]

Gizz schreef op dinsdag 13 mei 2025 @ 10:15:
@krizzziz en staat andere software die je stickje kan kapen uit? Denk aan ZHA, Deconz.
Je stick kan maar door één pakket tegelijk gebruikt worden.

Bedankt, maar ik heb alleen Z2M draaien, Niks anders.

[Septillion]

@Gizz Volgens mij krijg je dan alleen een "could not open" of "resouce busy" ipv een "No such file or directory"

[zunrob]

Volgend op de SolarEdge Modbus integratie, waardoor ik nu veel nauwkeuriger data uit kan lezen, wilde ik dit ook voor Enphase.

Hiervoor heb ik een custom polling interval automation gemaakt, zie hieronder:

YAML:

alias: Envoy custom polling interval
description: ""
triggers:
  - seconds: /10
    trigger: time_pattern
conditions: []
actions:
  - action: homeassistant.update_entity
    data:
      entity_id:
        - sensor.envoy_XXX_current_power_production
mode: single

Deze lijkt echter niet te werken. De integratie blijft op hoe het lijkt random momenten data doorsturen, zeker niet elke 10 seconden. Iemand hier ervaring mee?

[krizzziz]

Septillion schreef op dinsdag 13 mei 2025 @ 12:11:
@Gizz Volgens mij krijg je dan alleen een "could not open" of "resouce busy" ipv een "No such file or directory"

Er lijkt wel niks verbonden te zijn aan mijn proxmox host. Ik heb de USB poorten die ik had toegevoegd verwijderd. En probeer het nu weer, met de conbee stick ingeplugd. Maar het lijkt wel alsof de hardware niet herkend wordt. Voor mijn gevoel stond hier vorige keer dus een fabrikant. Maar nu niks.



Zou de stick gewoon dood zijn? Ik heb een usb verlengkabel naar een hub voor verbetere ontvangst. Heeft het altijd goed gedaan. Maar ook de stick rechtsreeks in de server pluggen en er komt ook niks tevoorschijn.

[Gizz]

@krizzziz nog twee suggesties:

• Al je server een goede powercycle gegeven na de stroomstoring? Dus echt even helemaal de spanning eraf, eventjes wachten en dan weer erop.
• Wordt de stick wel herkent als je 'm in een andere machine stopt? Wordt hij op je normale pc wel herkent bij het inpluggen en kun je firmware flashen?

Als ook bij een andere pc niks gebeurt bij het inpluggen, dan denk ik dat je van een dode stick uit kunt gaan.

[krizzziz]

Gizz schreef op dinsdag 13 mei 2025 @ 12:29:
@krizzziz nog twee suggesties:

• Al je server een goede powercycle gegeven na de stroomstoring? Dus echt even helemaal de spanning eraf, eventjes wachten en dan weer erop.
• Wordt de stick wel herkent als je 'm in een andere machine stopt? Wordt hij op je normale pc wel herkent bij het inpluggen en kun je firmware flashen?

Als ook bij een andere pc niks gebeurt bij het inpluggen, dan denk ik dat je van een dode stick uit kunt gaan.

Ook niks bij een andere PC. Stick is dood. Gelukkig komt vandaag een Sonoff stick binnen. Nu nog even uitvogelen hoe ik het e.e.a overzet.

[Gizz]

krizzziz schreef op dinsdag 13 mei 2025 @ 12:38:
[...]

Ook niks bij een andere PC. Stick is dood. Gelukkig komt vandaag een Sonoff stick binnen. Nu nog even uitvogelen hoe ik het e.e.a overzet.

Dat wordt alles opnieuw pairen, helaas. Succes!

edit: ik zie dat er nu een (zeer) experimentele route is om te kunnen migreren van Deconz naar Zstack/Ember. Misschien de moeite waard om die optie te verkennen als je een groot netwerk hebt. Aan de andere kant weet je met handmatig opnieuw pairen wel zeker dat je tot een werkend eindresultaat komt

[ Voor 38% gewijzigd door Gizz op 13-05-2025 13:07 ]

[Impossibl3]

Ik heb een vraag aan jullie HA (super) gebruikers.

Ik draai al een aantal jaar HAOS op mijn NUC met grote tevredenheid en veel automatiseringen en eigen yaml codes. Nu belast ik mijn NUC steeds zwaarder en dat gaat prima maar komen ook containers mogelijk om de hoek kijken.

Sinds kort draai ik Frigate en wil ik ook persoon herkenning toevoegen. Dit kan bijvoorbeeld via CompreFace of Double Take maar beide stukjes software zijn containers in docker. Nu begrijp ik dat je containers binnen HAOS kan draaien via Portainer alleen is Portainer niet meer onderhouden door Franck Nijhof. Nu is daar wel een fork van gemaakt. Alleen bij Portainer staat

Home Assistant DOES NOT SUPPORT running third party containers on Home Assistant OS or Supervised installation types. Ignoring this, will render your system as unsupported!

Aangezien ik mijn HAOS wel graag supported hou vroeg ik mij af of Parainer nog wel de weg is die ik moet gaan. Een andere optie is Proxmox op mijn NUC te zetten met HA OS of Superviced er op maar kan ik mijn backup er dan zo op zetten zodat alles weer werkt als dat nu het geval is? Als ik het in Proxmox draai dan zou ik docker er naast kunen draaien voor gezicht herkenning. Een andere optie is HA als docker installeren. Maar volgens mij kan ik dan niet een 1 op 1 vervanging doen van mijn HA (op wat verwijzingen die ik sowieso moet doorvoeren als de locatie van ZHA en Coral TPU die in de USB geplugd zit doorgeven). Ik heb namelijk geen zin om al mijn automatiseringen en eigen yaml opnieuw te maken.

Ik hoor graag van jullie wat jullie adviseren. Een optie is nog altijd om gezicht herkenning achter wegen te laten maar tzt komt er vast weer iets wat ik ook zou willen draaien wat niet als add-on binnen HA beschikbaar is. Als ik dan toch eens door de zure appel moet bijten is nu misschien wel het moment.

[D4NG3R]

@Impossibl3
Je huidige installatie virtualiseren en op bijv Proxmox draaien zal je iig veruit de meeste flexibiliteit geven zonder nieuwe hardware te moeten kopen of in te leveren qua support.

Het zou in principe een kwestie moeten zijn van de installatie starten en voor restore from backup te kiezen, maar ik heb zelf nog geen backup terug hoeven te zetten.