Home Assistant: Open source Python3 home automation - deel 5

[paQ]

Kan me iemand lieden naar een mooie integratie die "rolling averages" kan maken / uitrekenen in een vast te stellen periode?
Bijv. de afgelopen x dagen / uren?

Alle methodes die ik tot dusver handmatig probeer geven of niet de juiste uitkomst, of niet het gewenste resultaat

[hemertje]

1 van de 'Aqara Roller shade driver E1' wil niet meer bewegen

https://www.zigbee2mqtt.i...1LM.html#aqara-znjlbl01lm

Batterij 95%
Link quality (signal strength) 104lqi

heeft iemand een idee waar ik het moet zoeken?

[TheFes]

paQ schreef op woensdag 19 november 2025 @ 21:57:
Kan me iemand lieden naar een mooie integratie die "rolling averages" kan maken / uitrekenen in een vast te stellen periode?
Bijv. de afgelopen x dagen / uren?

Alle methodes die ik tot dusver handmatig probeer geven of niet de juiste uitkomst, of niet het gewenste resultaat

Wat heb je al geprobeerd? Want op zich zou dat met een SQL sensor of de hierboven genoemde recorder.get_statistics prima moeten kunnen.

[Rouwette]

hemertje schreef op woensdag 19 november 2025 @ 23:26:
1 van de 'Aqara Roller shade driver E1' wil niet meer bewegen

https://www.zigbee2mqtt.i...1LM.html#aqara-znjlbl01lm

Batterij 95%
Link quality (signal strength) 104lqi

heeft iemand een idee waar ik het moet zoeken?
[Afbeelding]

Herkoppelen denk ik, ik moest na de 2025-11 update alle aqara temp en pirs opnieuw koppelen.

[paQ]

TheFes schreef op donderdag 20 november 2025 @ 00:00:
[...]


Wat heb je al geprobeerd? Want op zich zou dat met een SQL sensor of de hierboven genoemde recorder.get_statistics prima moeten kunnen.

Heb hier diverse varianten op gemaakt, maar allemaal niet het beoogde resultaat.

YAML:

  battery_charge_daily:
    source: sensor.inverter_today_battery_charge
    cycle: daily

  battery_discharge_daily:
    source: sensor.inverter_today_battery_discharge
    cycle: daily


  battery_charge_weekly:
    source: sensor.battery_charge_daily
    cycle: weekly

  battery_discharge_weekly:
    source: sensor.battery_discharge_daily
    cycle: weekly



sensor:
  - platform: statistics
    name: battery_charge_168h
    entity_id: sensor.battery_charge_daily
    state_characteristic: sum          
    max_age:
      days: 7
    sampling_size: 400                 
    precision: 2

  - platform: statistics
    name: battery_discharge_168h
    entity_id: sensor.battery_discharge_daily
    state_characteristic: sum
    max_age:
      days: 7
    sampling_size: 400
    precision: 2

  - platform: statistics
    name: battery_losses_168h
    entity_id: sensor.inverter_power_losses_filtered_energy_daily
    state_characteristic: sum
    max_age:
      days: 7
    sampling_size: 400
    precision: 2

Het doel is dat ik een 7 day rolling average heb van het RTE wat ik uitreken.
Ik moet bekennen dat ik dat best wel moeilijk vind om de juiste wijze van benaderen te vinden.
Er zijn energiesensoren, ook daily en weekly. Het is me bijv onduidelijk op basis van welke van die 3 ik moet uit gaan. Het is ook niet de bedoeling dat er op vaste tijdstippen / dagen de boel wordt bijgewerkt.
Ergo: ik wil dat het functioneert als de verbruiksmeter in de auto bijv. l/(laatste)100km
Maar dan RTE/7x24 uur
Als ik het gemiddelde over de dagelijkse RTE's bereken dan ontstaat er (uiteraard) ook afwijking.

[TheFes]

paQ schreef op donderdag 20 november 2025 @ 10:09:
[...]

Heb hier diverse varianten op gemaakt, maar allemaal niet het beoogde resultaat.

YAML:

  battery_charge_daily:
    source: sensor.inverter_today_battery_charge
    cycle: daily

  battery_discharge_daily:
    source: sensor.inverter_today_battery_discharge
    cycle: daily


  battery_charge_weekly:
    source: sensor.battery_charge_daily
    cycle: weekly

  battery_discharge_weekly:
    source: sensor.battery_discharge_daily
    cycle: weekly



sensor:
  - platform: statistics
    name: battery_charge_168h
    entity_id: sensor.battery_charge_daily
    state_characteristic: sum          
    max_age:
      days: 7
    sampling_size: 400                 
    precision: 2

  - platform: statistics
    name: battery_discharge_168h
    entity_id: sensor.battery_discharge_daily
    state_characteristic: sum
    max_age:
      days: 7
    sampling_size: 400
    precision: 2

  - platform: statistics
    name: battery_losses_168h
    entity_id: sensor.inverter_power_losses_filtered_energy_daily
    state_characteristic: sum
    max_age:
      days: 7
    sampling_size: 400
    precision: 2

Het doel is dat ik een 7 day rolling average heb van het RTE wat ik uitreken.
Ik moet bekennen dat ik dat best wel moeilijk vind om de juiste wijze van benaderen te vinden.
Er zijn energiesensoren, ook daily en weekly. Het is me bijv onduidelijk op basis van welke van die 3 ik moet uit gaan. Het is ook niet de bedoeling dat er op vaste tijdstippen / dagen de boel wordt bijgewerkt.
Ergo: ik wil dat het functioneert als de verbruiksmeter in de auto bijv. l/(laatste)100km
Maar dan RTE/7x24 uur
Als ik het gemiddelde over de dagelijkse RTE's bereken dan ontstaat er (uiteraard) ook afwijking.

Maar 7 dagen rolling average, is dat hele dagen? Of donderdag 13 november 2025 10:15 tot donderdag 20 november 2025 10:15?

En van hoeveel dagen heb je de data in de recorder staan? De standaard 10 dagen?

[paQ]

TheFes schreef op donderdag 20 november 2025 @ 10:13:
[...]


Maar 7 dagen rolling average, is dat hele dagen? Of donderdag 13 november 2025 10:15 tot donderdag 20 november 2025 10:15?

En van hoeveel dagen heb je de data in de recorder staan? De standaard 10 dagen?

Ik heb nooit iets aan de recorder aangepast, dus ik gok 10 dagen idd.
Doel is dat ik vanaf dit tijdstip (en op elk tijdstip in de toekomst) terugkijk op de afgelopen 7x24 uur.

[TheFes]

paQ schreef op donderdag 20 november 2025 @ 10:18:
[...]

Ik heb nooit iets aan de recorder aangepast, dus ik gok 10 dagen idd.
Doel is dat ik vanaf dit tijdstip (en op elk tijdstip in de toekomst) terugkijk op de afgelopen 7x24 uur.

Oke, en die zijn energy sensoren, dus met een total increasing waarde?
Dus eigenlijk wil je de waarde van 24*7 uur geleden vergelijken met de huidige waarde, en die door 24*7 delen? Of begrijp ik het dan verkeerd?

[paQ]

TheFes schreef op donderdag 20 november 2025 @ 10:24:
[...]


Oke, en die zijn energy sensoren, dus met een total increasing waarde?
Dus eigenlijk wil je de waarde van 24*7 uur geleden vergelijken met de huidige waarde, en die door 24*7 delen? Of begrijp ik het dan verkeerd?

Die energy sensoren lopen op.
De daily en weekly uiteraard niet.

over je andere vraag.
Momenteel doe ik dit voor het RTE van die dag:

code:

{% set cap        = states('input_number.battery_capacity_kwh')|float(0) %}
{% set soc_start  = states('input_number.battery_soc_start')|float(0) %}
{% set soc_now    = states('sensor.inverter_battery')|float(0) %}
{% set delta_soc  = (soc_start - soc_now) / 100 * cap %}

{% set charge     = states('sensor.inverter_today_battery_charge')|float(0) %}
{% set discharge  = states('sensor.inverter_today_battery_discharge')|float(0) %}
{% set losses     = states('sensor.inverter_power_losses_filtered_energy_daily')|float(0) %}

{# ---- Effective in/out ---- #}
{% set d_eff = discharge - delta_soc %}
{% set c_eff = charge + losses  %}

{% set rte = (d_eff / c_eff * 100) if c_eff > 0 else 0 %}

cap:          {{ cap }} kWh
soc_start:    {{ soc_start }} %
soc_now:      {{ soc_now }} %
delta_soc_kwh {{ delta_soc }} kWh

charge:       {{ charge }} kWh
discharge:    {{ discharge }} kWh
losses:       {{ losses }} kWh

d_eff:        {{ d_eff }} kWh
c_eff:        {{ c_eff | round(3) }} kWh

RTE_calc:     {{ rte | round(2) }} %
Life cycle today:  {{ states('sensor.inverter_today_battery_life_cycles') }}

Daar komt dan dit uit

cap: 48.2 kWh
soc_start: 31.0 %
soc_now: 53.0 %
delta_soc_kwh -10.604000000000001 kWh

charge: 24.1 kWh
discharge: 12.5 kWh
losses: 2.083 kWh

d_eff: 23.104 kWh
c_eff: 26.183 kWh

RTE_calc: 88.24 %
Life cycle today: 0.51

Ik haal per dag een life cycle van 0.4 - 0.8 ongeveer. Geheel afhankelijk van de geladen energie.
Als er weinig wordt geladen krijg je dus ook een volatiel RTE, want lage cycle. Als er helemaal niet wordt geladen krijg je een RTE onder de 50 bijv. Zinloos.

De gedachte is dat als ik het dus 'rolling' over de afgelopen 7x24 uren doe, ik altijd een keurige RTE waarde heb, immers (schat ik) van ca 3-5 cycles.

[TheFes]

paQ schreef op donderdag 20 november 2025 @ 10:33:
[...]

Die energy sensoren lopen op.
De daily en weekly uiteraard niet.

over je andere vraag.
Momenteel doe ik dit voor het RTE van die dag:

code:

{% set cap        = states('input_number.battery_capacity_kwh')|float(0) %}
{% set soc_start  = states('input_number.battery_soc_start')|float(0) %}
{% set soc_now    = states('sensor.inverter_battery')|float(0) %}
{% set delta_soc  = (soc_start - soc_now) / 100 * cap %}

{% set charge     = states('sensor.inverter_today_battery_charge')|float(0) %}
{% set discharge  = states('sensor.inverter_today_battery_discharge')|float(0) %}
{% set losses     = states('sensor.inverter_power_losses_filtered_energy_daily')|float(0) %}

{# ---- Effective in/out ---- #}
{% set d_eff = discharge - delta_soc %}
{% set c_eff = charge + losses  %}

{% set rte = (d_eff / c_eff * 100) if c_eff > 0 else 0 %}

cap:          {{ cap }} kWh
soc_start:    {{ soc_start }} %
soc_now:      {{ soc_now }} %
delta_soc_kwh {{ delta_soc }} kWh

charge:       {{ charge }} kWh
discharge:    {{ discharge }} kWh
losses:       {{ losses }} kWh

d_eff:        {{ d_eff }} kWh
c_eff:        {{ c_eff | round(3) }} kWh

RTE_calc:     {{ rte | round(2) }} %
Life cycle today:  {{ states('sensor.inverter_today_battery_life_cycles') }}

Daar komt dan dit uit

cap: 48.2 kWh
soc_start: 31.0 %
soc_now: 53.0 %
delta_soc_kwh -10.604000000000001 kWh

charge: 24.1 kWh
discharge: 12.5 kWh
losses: 2.083 kWh

d_eff: 23.104 kWh
c_eff: 26.183 kWh

RTE_calc: 88.24 %
Life cycle today: 0.51

Ik haal per dag een life cycle van 0.4 - 0.8 ongeveer. Geheel afhankelijk van de geladen energie.
Als er weinig wordt geladen krijg je dus ook een volatiel RTE, want lage cycle. Als er helemaal niet wordt geladen krijg je een RTE onder de 50 bijv. Zinloos.

De gedachte is dat als ik het dus 'rolling' over de afgelopen 7x24 uren doe, ik altijd een keurige RTE waarde heb, immers (schat ik) van ca 3-5 cycles.

Ik zit totaal niet in deze materie, en heb nu niet de tijd om me in deze berekening te verdiepen.
Maar als je een totaal over een periode wil hebben kun je dus recorder.get_statistics kunnen gebruiken.

Voorbeeld, dit zou, mits je inderdaad 10 dagen in je recorder hebt, alle 5 minute changes van een bepaalde total_increasing sensor moeten geven.

YAML:

action: recorder.get_statistics
data:
  period: 5minute
  statistic_ids:
    - sensor.je_total_increasing_sensor
  types:
    - change
  start_time: "{{ now() - timedelta(days=7, minutes=5) }}"
response_variable: response

Dat resultaat zou je dan dus in een trigger based template sensor, die elke 5 minuten triggert, kunnen omrekenen naar een gemiddelde over die periode.

Django/Jinja:

{% set values = response.statistics.values() | first %}
{% set change = values | map(attribute='change') | sum %}
{% set hours  = (values[-1].end | as_datetime - values[0].start | as_datetime).total_seconds() / 3600 %}
{{ change / hours }}

Maar goed, het is me dus nog niet helemaal duidelijk of dat ook is wat je zoekt.

[paQ]

@TheFes thanks, ik zal die methode eens gaan proberen.
Heb al zoveel geprobeerd dat ik intussen nieteens meer weet wat allemaal precies en waarom dat dan niet voor me werkte.
Had ook wel een stille hoop op een integratie die ik voed en waar je diverse uitkomsten uit kunt trekken. Een beetje een Powercalc achtig iets.

[Brynnie]

Bestaat er een mogelijkheid om aan de hand van lat en long van een person, de locale tijd op die plaats op te halen? Ik wil een periodieke notificatie sturen op basis van een tijdstip (bvb dagelijks om 8u), maar de person bevindt zich vaak op andere locaties, USA/Europa/… en ik wil de notificatie op het juiste tijdstip kunnen sturen. Lokale tijd 8u bvb.

[Hmmbob]

De HA Companion app heeft een sensor "current timezone", wellicht kun je daar een template mee bouwen? Staat volgens mij niet standaard aan, moet je inschakelen in de instellingen.

Die sensor geeft voor mij nu de status Central European Standard Time, attributes:

code:

icon: mdi:map-clock
friendly_name: SM-A556B Current time zone
in_daylight_time: false
time_zone_id: Europe/Amsterdam
time_zone_short: GMT+01:00
uses_daylight_time: true
utc_offset: 3600000

[ Voor 68% gewijzigd door Hmmbob op 20-11-2025 11:53 ]

[synoniem]

Of je kijkt naar https://github.com/noandrea/geo2tz een lokaal te draaien container.

[Get!em]

Pffff, was even zweten zeg.....

Ik heb hier een MariaDB in een LXC container op Proxmox als plek voor de recorder / short-term en de statistics.

Nu was proxmox geupgrade naar 9.x (gisteren 9.1) met Trixie, succesvol.
Vandaag wilde ik ook de LXC upgraden naar Trixie. Bij de meeste containers ging dit goed en vlot, maar bij MariaDB was dit toch wel een dingetje. Moest er een MariaDB upgrade achteraan doen.

Uiteindelijk er wel uitgekomen.
Even uitgaande van een werkende Proxmox 9.1 zijn de stappen grofweg als volgt:
Pre: backup/backup/snapshot
1: volg de LXC upgrade: https://github.com/commun...roxmoxVE/discussions/7489
a) mogelijk krijg je een warning over dpkg, volg die instructie.
2: upgrade mariadb met de nieuwe sources en 12.x versie https://scohostings.com/h...ntu-a-step-by-step-guide/ (vervang in de upgrade version dus door 12.1.2 )

[TheFes]

Hmmbob schreef op donderdag 20 november 2025 @ 11:49:
De HA Companion app heeft een sensor "current timezone", wellicht kun je daar een template mee bouwen? Staat volgens mij niet standaard aan, moet je inschakelen in de instellingen.

Die sensor geeft voor mij nu de status Central European Standard Time, attributes:

code:

icon: mdi:map-clock
friendly_name: SM-A556B Current time zone
in_daylight_time: false
time_zone_id: Europe/Amsterdam
time_zone_short: GMT+01:00
uses_daylight_time: true
utc_offset: 3600000

Dat lijkt me zeker bruikbaar.
@Brynnie
Je zou dan zoiets kunnen doen in een template sensor

Django/Jinja:

{% set sensor = 'sensor.pixel_10_pro_current_time_zone' %}
{% set time = '08:00:00'%}
{{ utcnow() + timedelta(seconds=state_attr(sensor, 'utc_offset')/1000) > as_datetime(now().date()~'T'~time~'+00:00') }}

Er zouden wel issues kunnen zijn als de gewenste tijd niet dezelfde datum heeft als de tijd in UTC, maar ervan uit gaande dat je server CET gebruikt moet dat met 8:00 geen probleem zijn.

[ Voor 9% gewijzigd door TheFes op 20-11-2025 12:29 ]

[Septillion]

Maeslant schreef op woensdag 19 november 2025 @ 17:21:
[...]


Juist, dit is ook aan de hand. Echter nu is het dus blijkbaar pech en 3 jaar data verloren? (Mijn backup is 15 dagen oud en heeft ook een currupte DB)

Wel handwerk maar niet verloren: Septillion in "Home Assistant - Show je setup"

[Brynnie]

Hmmbob schreef op donderdag 20 november 2025 @ 11:49:
De HA Companion app heeft een sensor "current timezone", wellicht kun je daar een template mee bouwen? Staat volgens mij niet standaard aan, moet je inschakelen in de instellingen.

Die sensor geeft voor mij nu de status Central European Standard Time, attributes:

code:

icon: mdi:map-clock
friendly_name: SM-A556B Current time zone
in_daylight_time: false
time_zone_id: Europe/Amsterdam
time_zone_short: GMT+01:00
uses_daylight_time: true
utc_offset: 3600000

Inschakelen in de instellingen op de Home Assistant server of individueel in de settings van de commando’s app? Ben nu helaas niet in de buurt van een toestel of de server dus kan het niet snel zelf checken.

Ik keek al naar oplossingen zoals https://developers.google...do-with-the-time-zone-api

[TheFes]

Brynnie schreef op donderdag 20 november 2025 @ 14:19:
[...]


Inschakelen in de instellingen op de Home Assistant server of individueel in de settings van de commando’s app? Ben nu helaas niet in de buurt van een toestel of de server dus kan het niet snel zelf checken.

Ik keek al naar oplossingen zoals https://developers.google...do-with-the-time-zone-api

Je moet die sensor activeren in de Home Assistant app op de telefoon/tablet/whatever.

Sensor is overigens wel Android only
https://companion.home-as...#current-time-zone-sensor

[ Voor 9% gewijzigd door TheFes op 20-11-2025 14:25 ]

[Brynnie]

TheFes schreef op donderdag 20 november 2025 @ 14:24:
[...]

Je moet die sensor activeren in de Home Assistant app op de telefoon/tablet/whatever.

Sensor is overigens wel Android only
https://companion.home-as...#current-time-zone-sensor

Jammer. Bij mij gaat het om iPhones…

Wat heel raar is: een template sensor maken in configuration.yaml werkt voor de ene persoon wel, maar voor de andere niet. Van beiden zijn lat en long gekend. De Google api rechtstreeks aanroepen geeft voor beide een correct resultaat.

YAML:

rest:
  - resource_template: >-
      https://maps.googleapis.com/maps/api/timezone/json
      ?location={{ state_attr('person.persoona', 'latitude') | float(0) }},
                {{ state_attr('person.persoona', 'longitude') | float(0) }}
      &timestamp={{ now().timestamp() | int }}
      &key=KEY
    method: GET
    headers:
      Accept: application/json
      User-Agent: HomeAssistant
    scan_interval: 300
    sensor:
      - name: "TimeZone_PersoonA"
        unique_id: 8352b3ec-b5f4-4bd2-b8ea-54cd2d77bede
        value_template: >-
          {% if value_json.status == 'OK' and value_json.timeZoneId is defined %}
            {{ value_json.timeZoneId }}
          {% else %}
            {{ value_json.status | default('unknown') }}
          {% endif %}
        json_attributes:
          - status
          - dstOffset
          - rawOffset
          - timeZoneId
          - timeZoneName
          - errorMessage

[TheFes]

Brynnie schreef op donderdag 20 november 2025 @ 14:42:
[...]


Jammer. Bij mij gaat het om iPhones…

Wat heel raar is: een template sensor maken in configuration.yaml werkt voor de ene persoon wel, maar voor de andere niet. Van beiden zijn lat en long gekend. De Google api rechtstreeks aanroepen geeft voor beide een correct resultaat.

YAML:

rest:
  - resource_template: >-
      https://maps.googleapis.com/maps/api/timezone/json
      ?location={{ state_attr('person.persoona', 'latitude') | float(0) }},
                {{ state_attr('person.persoona', 'longitude') | float(0) }}
      &timestamp={{ now().timestamp() | int }}
      &key=KEY
    method: GET
    headers:
      Accept: application/json
      User-Agent: HomeAssistant
    scan_interval: 300
    sensor:
      - name: "TimeZone_PersoonA"
        unique_id: 8352b3ec-b5f4-4bd2-b8ea-54cd2d77bede
        value_template: >-
          {% if value_json.status == 'OK' and value_json.timeZoneId is defined %}
            {{ value_json.timeZoneId }}
          {% else %}
            {{ value_json.status | default('unknown') }}
          {% endif %}
        json_attributes:
          - status
          - dstOffset
          - rawOffset
          - timeZoneId
          - timeZoneName
          - errorMessage

Heb je die tweede opnieuw onder een rest: key gezet? Zo ja, dan is dat je probleem. Zet ze beide onder dezelfde key.

[ Voor 8% gewijzigd door TheFes op 20-11-2025 15:27 ]

[maartend]

Probleem

Sinds de laatste update is mijn Shelly lamp onzichtbaar geworden in HA.

Ik zie hem nog wel in de Shelly app op mijn telefoon. Ik krijg hem ook niet gevonden in HA.
Ik gebruik Shelly Smart home in HA.

Iemand die me een richting op kan sturen?
Er wordt ook niet gevraagd om een ip adres in te voeren, ik kan niks

[TheFes]

maartend schreef op donderdag 20 november 2025 @ 16:28:
Probleem

Sinds de laatste update is mijn Shelly lamp onzichtbaar geworden in HA.

Ik zie hem nog wel in de Shelly app op mijn telefoon. Ik krijg hem ook niet gevonden in HA.
Ik gebruik Shelly Smart home in HA.

Iemand die me een richting op kan sturen?
Er wordt ook niet gevraagd om een ip adres in te voeren, ik kan niks

Wat is Shelly Smart home?
De standaard ingebouwde integratie heet gewoon Shelly. Gebruik je dus een custom integratie?

Ik zie hier wel Shelly smart home staan. Die integratie is jaren geleden voor het laatst bijgewerkt, en toen overbodig geworden omdat de ingebouwde Shelly integratie een flinke upgrade kreeg. Ik zou die custom integratie er dus gewoon af gooien, en de gewone ingebouwde integratie gebruiken.

[ Voor 22% gewijzigd door TheFes op 20-11-2025 16:37 ]

[maartend]

TheFes schreef op donderdag 20 november 2025 @ 16:33:
[...]


Wat is Shelly Smart home?
De standaard ingebouwde integratie heet gewoon Shelly. Gebruik je dus een custom integratie?

Ik zie hier wel Shelly smart home staan. Die integratie is 5 jaar geleden voor het laatst bijgewerkt, en toen overbodig geworden omdat de ingebouwde Shelly integratie een flinke upgrade kreeg. Ik zou die custom integratie er dus gewoon af gooien, en de gewone ingebouwde integratie gebruiken.

Ik gebruik diegene die jij gebruikt. Maar wel wat geks. Bij de intergratie staat dit+
Shelly smart home
Version 1.0.10
Custom integration that replaces a Core component

En als ik op het vraagteken druk wordt ik doorverwezen naar de Shellyfor HAss pagina.

Maar ik heb de intergratie van Shelly zelf, vanuit intergrations

[Get!em]

maartend schreef op donderdag 20 november 2025 @ 16:38:
[...]

Ik gebruik diegene die jij gebruikt. Maar wel wat geks. Bij de intergratie staat dit+
Shelly smart home
Version 1.0.10
Custom integration that replaces a Core component

En als ik op het vraagteken druk wordt ik doorverwezen naar de Shellyfor HAss pagina.

Maar ik heb de intergratie van Shelly zelf, vanuit intergrations

Die dus https://github.com/StyraHem/ShellyForHASS

Deinstalleren via HACS?

[maartend]

Get!em schreef op donderdag 20 november 2025 @ 16:39:
[...]

Die dus https://github.com/StyraHem/ShellyForHASS

Deinstalleren via HACS?

Nee, die gebruik ik niet. Ik doe de intergratie van Shelly zelf. dit geeft hij aan op de intergratie pagina+
Shelly smart home

Deze dus ; https://www.home-assistant.io/integrations/shelly/

wacht even ; shelly for has zat er ook nog.

Even allebij verwijderen, resetten en opnieuw opstarten

[ Voor 19% gewijzigd door maartend op 20-11-2025 16:49 ]

[Brynnie]

TheFes schreef op donderdag 20 november 2025 @ 15:26:
[...]


Heb je die tweede opnieuw onder een rest: key gezet? Zo ja, dan is dat je probleem. Zet ze beide onder dezelfde key.

Staan allebei onder 1 rest key, samen met andere (werkende) sensoren.

[TheFes]

maartend schreef op donderdag 20 november 2025 @ 16:45:
[...]

Nee, die gebruik ik niet. Ik doe de intergratie van Shelly zelf. dit geeft hij aan op de intergratie pagina+
Shelly smart home

Deze dus ; https://www.home-assistant.io/integrations/shelly/

wacht even ; shelly for has zat er ook nog.

Even allebij verwijderen, resetten en opnieuw opstarten

Shelly 4 Hass vervangt de core integratie, dat is precies wat je zelf ook al plaatste:
"Custom integration that replaces a Core component"

Na verwijderen en een herstart zou je Shelly vanzelf gevonden moeten worden.

[Hmmbob]

Brynnie schreef op donderdag 20 november 2025 @ 14:42:
[...]


Jammer. Bij mij gaat het om iPhones…

Wat heel raar is: een template sensor maken in configuration.yaml werkt voor de ene persoon wel, maar voor de andere niet. Van beiden zijn lat en long gekend. De Google api rechtstreeks aanroepen geeft voor beide een correct resultaat.

Iets in de logs? Wat is je volledige code, voor beide devices dus?

[maartend]

TheFes schreef op donderdag 20 november 2025 @ 17:04:
[...]

Shelly 4 Hass vervangt de core integratie, dat is precies wat je zelf ook al plaatste:
"Custom integration that replaces a Core component"

Na verwijderen en een herstart zou je Shelly vanzelf gevonden moeten worden.

Bijzondere was, hij deed het tot de update. Maar bleek dat ik op beide inytergraties probeerde te draaien, werkt nu als een tierelier weer

[Driek]

ik heb een zigbee scene switch aangeschaft die zich laat herkennen in zigbee2mqtt als
https://www.zigbee2mqtt.io/devices/TS0043.html
Het ding ziet er anders uit, maar prima. Pairen is ook gelukt dus mooi.

Echter zie ik in de mqtt devices alleen de batterij en linksensor.

Als ik op de mqtt berichten kijk, dan zie ik wel de berichten voorbij komen als ik op een knop klik.
Het topic is
zigbee2mqtt/0xe406bffffe4bea50/action
met de waarde 1_single, 2_single of 3_single.

Hoe kan ik nu die waardes gebruiken in een automation om een actie uit te voeren?

Gelukt, de blueprint werkte niet, maar gewoon een mqtt topic gebruiken als automation trigger was de oplossing

[ Voor 9% gewijzigd door Driek op 20-11-2025 19:50 ]

[Septillion]

@Driek Of device triggers gebruiken, of legacy action sensor aanzetten of experimental event entities aanzetten

MQTT topic gebruiken is precies de variant die ik af zou raden omdat er dan vanuit HA gezien geen enkele link met het device is.

[Septillion]

paQ schreef op donderdag 20 november 2025 @ 10:09:
[...]

Heb hier diverse varianten op gemaakt, maar allemaal niet het beoogde resultaat.

YAML:

  battery_charge_daily:
    source: sensor.inverter_today_battery_charge
    cycle: daily

  battery_discharge_daily:
    source: sensor.inverter_today_battery_discharge
    cycle: daily


  battery_charge_weekly:
    source: sensor.battery_charge_daily
    cycle: weekly

  battery_discharge_weekly:
    source: sensor.battery_discharge_daily
    cycle: weekly



sensor:
  - platform: statistics
    name: battery_charge_168h
    entity_id: sensor.battery_charge_daily
    state_characteristic: sum          
    max_age:
      days: 7
    sampling_size: 400                 
    precision: 2

  - platform: statistics
    name: battery_discharge_168h
    entity_id: sensor.battery_discharge_daily
    state_characteristic: sum
    max_age:
      days: 7
    sampling_size: 400
    precision: 2

  - platform: statistics
    name: battery_losses_168h
    entity_id: sensor.inverter_power_losses_filtered_energy_daily
    state_characteristic: sum
    max_age:
      days: 7
    sampling_size: 400
    precision: 2

Het doel is dat ik een 7 day rolling average heb van het RTE wat ik uitreken.
Ik moet bekennen dat ik dat best wel moeilijk vind om de juiste wijze van benaderen te vinden.
Er zijn energiesensoren, ook daily en weekly. Het is me bijv onduidelijk op basis van welke van die 3 ik moet uit gaan. Het is ook niet de bedoeling dat er op vaste tijdstippen / dagen de boel wordt bijgewerkt.
Ergo: ik wil dat het functioneert als de verbruiksmeter in de auto bijv. l/(laatste)100km
Maar dan RTE/7x24 uur
Als ik het gemiddelde over de dagelijkse RTE's bereken dan ontstaat er (uiteraard) ook afwijking.

Als het dus total increasing sensoren zijn dan had je juist state_characteristic: change willen toepassen. En al naar gelang hoe veel updates je binnen krijgt kan het nog wel eens zijn dan 400 punten niet genoeg is. Dat zijn er namelijk maar 2,4 per uur. Volgens mij mag je hem tegenwoordig leeg laten voor onbeperkt zodat hij volledig gedreven is door max_age.

Alleen zal je daarna het nog moeten delen door aantal dag/uren dat je wilt voor het gemiddelde per dag/uur.

De optie van @TheFes met recorder.get_statistics is ook een mooie maar dan moet je wel wachten op de LTS update. Maar voordeel is wel dat het ook werkt als de bron tussentijds reset.

[ Voor 3% gewijzigd door Septillion op 20-11-2025 20:11 ]

[paQ]

Septillion schreef op donderdag 20 november 2025 @ 20:08:
[...]

Als het dus total increasing sensoren zijn dan had je juist state_characteristic: change willen toepassen. En al naar gelang hoe veel updates je binnen krijgt kan het nog wel eens zijn dan 400 punten niet genoeg is. Dat zijn er namelijk maar 2,4 per uur. Volgens mij mag je hem tegenwoordig leeg laten voor onbeperkt zodat hij volledig gedreven is door max_age.

Alleen zal je daarna het nog moeten delen door aantal dag/uren dat je wilt voor het gemiddelde per dag/uur.

De optie van @TheFes met recorder.get_statistics is ook een mooie maar dan moet je wel wachten op de LTS update. Maar voordeel is wel dat het ook werkt als de bron tussentijds reset.

Kwam ik 45 min geleden toevallig achter

YAML:

{% set cap       = states('input_number.battery_capacity_kwh') | float(48.2) %}
          {% set soc_now   = states('sensor.inverter_battery') | float(0) %}
          {% set soc_start = states('sensor.soc_168_uur_geleden') | float(soc_now) %}
          {% set charge    = states('sensor.charge_168u')      | float(0) %}
          {% set discharge = states('sensor.discharge_168u')   | float(0) %}
          {% set losses    = states('sensor.power_losses_filtered_168u') | float(0) %}

          {% set delta_soc_kwh = (soc_start - soc_now) / 100 * cap %}
          {% set d_eff = discharge - delta_soc_kwh %}
          {% set c_eff = charge + losses %}

          {{ ((d_eff / c_eff * 100) if c_eff > 0.1 else 0) | round(2) }}

        attributes:
          periode: "168 uur / 7 dagen"
          soc_start: "{{ states('sensor.soc_168_uur_geleden') | float | round(1) }} %"
          soc_now: "{{ states('sensor.inverter_battery') | float | round(1) }} %"
          delta_soc_kwh: "{{ ((states('sensor.soc_168_uur_geleden') | float - states('sensor.inverter_battery') | float) / 100 * states('input_number.battery_capacity_kwh') | float(48.2)) | round(3) }} kWh"
          charge: "{{ states('sensor.charge_168u') | float | round(2) }} kWh"
          discharge: "{{ states('sensor.discharge_168u') | float | round(2) }} kWh"
          losses: "{{ states('sensor.power_losses_filtered_168u') | float | round(2) }} kWh"
          effective_discharge: "{{ (states('sensor.discharge_168u') | float - ((states('sensor.soc_168_uur_geleden') | float - states('sensor.inverter_battery') | float) / 100 * states('input_number.battery_capacity_kwh') | float(48.2))) | round(3) }} kWh"
          effective_charge: "{{ (states('sensor.charge_168u') | float + states('sensor.power_losses_filtered_168u') | float) | round(3) }} kWh"
          life_cycles_168h: "{{ (states('sensor.discharge_168u') | float / states('input_number.battery_capacity_kwh') | float(48.2)) | round(3) }}"
          life_cycles_total_now: "{{ states('sensor.inverter_total_battery_life_cycles') | float(0) | round(3) }}"
          last_update: "{{ now().strftime('%Y-%m-%d %H:%M') }}"

YAML:

sensor:
    
  - platform: statistics
    name: "charge 168u"
    entity_id: sensor.inverter_total_battery_charge
    state_characteristic: change
    max_age:
      hours: 168

  - platform: statistics
    name: "discharge 168u"
    entity_id: sensor.inverter_total_battery_discharge
    state_characteristic: change
    max_age:
      hours: 168

  - platform: statistics
    name: "power losses filtered 168u"
    entity_id: sensor.inverter_power_losses_filtered_energy
    state_characteristic: change
    max_age:
      hours: 168
     
  - platform: statistics
    name: "SOC verandering 168h"
    entity_id: sensor.inverter_battery
    state_characteristic: change
    max_age:
      hours: 168

De SOC change verreken ik met de SOC now, en dat wordt dan de SOC start.


voorlopige (?) uitkomst
87.14

attributes:
periode: "168 uur / 7 dagen"
soc_start: "61.0 %"
soc_now: "25.0 %"
delta_soc_kwh: "17.352 kWh"
charge: "187.6 kWh"
discharge: "198.6 kWh"
losses: "20.4 kWh"
effective_discharge: "181.248 kWh"
effective_charge: "208.0 kWh"
life_cycles_168h: "4.12"
life_cycles_total_now: "8.28"
last_update: "2025-11-20 20:36"

Het is wat aan de lage kant dus even kijken of het bijtrekt. Misschien nog wat oude meetfouten.
gefixt

[Septillion]

@paQ Je hebt wel allemaal floats zonder default. Dus dat kan wel bergje errors geven.

[JT]

Ik wou vandaag wat gaan doen met live energiekosten berekenen enzo, Dus ik denk, eens kijken hoe ik dat moet doen met de nieuwe prijzen-per-kwartier voor dynamische energie. Tot mijn grote verbazing vind ik er heel weinig over in relatie tot Home Assistant. Het enige dat ik heb kunnen vinden was een discussie op Github bij HA waarin aangegeven wordt dat de huidige energieverbruikmonitoring per uur wordt opgeslagen en dat dat dan aangepast zou moeten worden. Gezien de hoeveelheid mensen die zich bezig houden met dynamische prijzen ophalen lijken mensen met een dynamisch contract een significante groep van de HA-gebruikers. Toch vind ik er verder weinig over Ik heb ook in dit topic gezocht op "15 minuten" en ook hier vind ik weinig. Kijk ik verkeerd of wordt er inderdaad weinig mee gedaan?

[paQ]

Septillion schreef op donderdag 20 november 2025 @ 20:49:
@paQ Je hebt wel allemaal floats zonder default. Dus dat kan wel bergje errors geven.

Hmm. nog geen error gezien, maar noted
Iets om even in de gaten te houden idd.

[Septillion]

@JT Stats worden per uur opgeslagen in de long term. Maar berekening is per 5 minuten (of misschien zelfs direct). Dus het is geen issue

[smeerbartje]

Ik denk een hele simpele vraag, maar ik zie zojuist dit bericht: IKEA kondigt eerste 21 smarthomeproducten met Matter aan. Dit is interessant! Echter ik heb tot dusver alleen maar wifi acessoires gekoppeld aan mijn home assistant installatie.

Nu wil ik toch wel eens proberen om de uit te breiden met matter. Maar wat heb ik daar nu precies voor nodig? Ik neem aan iets van een USB device dat dient als "antenne" waarmee de dichtstbijzijnde matter device kan praten toch? En dan vormen ze onderling een mesh? Welk USB device moet ik dan hebben? Deze zou al moeten voldoen toch? Of mis ik dan nog iets?

[ Voor 11% gewijzigd door smeerbartje op 20-11-2025 21:34 ]

[JT]

Septillion schreef op donderdag 20 november 2025 @ 21:05:
@JT Stats worden per uur opgeslagen in de long term. Maar berekening is per 5 minuten (of misschien zelfs direct). Dus het is geen issue

Ok, ik moet alleen dan even uitzoeken hoe ik kom bij de berekening per 5 minuten om daar wat wizardy mee te doen. Maar goed, dat is gewoon uitzoekwerk. Wat ik mij dan wel afvraag is, als per 5 minuten geen long term data is, verdwijnt dat dan niet op enig moment en zo ja wanneer? Zou jammer zijn als ik niet een week of maand terug kan...

[JT]

smeerbartje schreef op donderdag 20 november 2025 @ 21:33:
Ik denk een hele simpele vraag, maar ik zie zojuist dit bericht: IKEA kondigt eerste 21 smarthomeproducten met Matter aan. Dit is interessant! Echter ik heb tot dusver alleen maar wifi acessoires gekoppeld aan mijn home assistant installatie.

Nu wil ik toch wel eens proberen om de uit te breiden met matter. Maar wat heb ik daar nu precies voor nodig? Ik neem aan iets van een USB device dat dient als "antenne" waarmee de dichtstbijzijnde matter device kan praten toch? En dan vormen ze onderling een mesh? Welk USB device moet ik dan hebben? Deze zou al moeten voldoen toch? Of mis ik dan nog iets?

Klopt. Ik ben zelf nog niet bezig met thread dus ik heb geen idee of het native is in HA zoals Zigbee of dat je een add-on nodig hebt, maar ik heb voor Zigbee iets van smlight, zoals dit. Erg tevreden over. Zodra ik eindelijk m'n accesspoints goed kan/ga ophangen op een strategische plek qua bereik in ons huis dan verhuis ik deze daar ook naartoe met PoE-voeding, net zoals mijn ap. Firmware is ook lekker uitgebreid.

[Seafarer]

smeerbartje schreef op donderdag 20 november 2025 @ 21:33:
Ik denk een hele simpele vraag, maar ik zie zojuist dit bericht: IKEA kondigt eerste 21 smarthomeproducten met Matter aan. Dit is interessant! Echter ik heb tot dusver alleen maar wifi acessoires gekoppeld aan mijn home assistant installatie.

Nu wil ik toch wel eens proberen om de uit te breiden met matter. Maar wat heb ik daar nu precies voor nodig? Ik neem aan iets van een USB device dat dient als "antenne" waarmee de dichtstbijzijnde matter device kan praten toch? En dan vormen ze onderling een mesh? Welk USB device moet ik dan hebben? Deze zou al moeten voldoen toch? Of mis ik dan nog iets?

In HA kun je matter installeren. Dan kun je gelijk over wifi verbinden.
Devices & services.

[JT]

Seafarer schreef op donderdag 20 november 2025 @ 21:40:
[...]

In HA kun je matter installeren. Dan kun je gelijk over wifi verbinden.
Devices & services.

Hmmm, ik haal matter en thread door elkaar Wel handig denk ik voor @smeerbartje om even na te gaan wat voor- en nadelen zijn van thread of wifi. Hij heeft het over mesh, dat heb je niet op die manier met wifi.

[Seafarer]

JT schreef op donderdag 20 november 2025 @ 21:46:
[...]

Hmmm, ik haal matter en thread door elkaar Wel handig denk ik voor @smeerbartje om even na te gaan wat voor- en nadelen zijn van thread of wifi. Hij heeft het over mesh, dat heb je niet op die manier met wifi.

Maar matter gaat ook over tread en kan een mes maken.

Lang verhaal:
https://www.tink.nl/blog/...20Wifi%E2%80%9D%20genoemd.

[Septillion]

@JT Wat voor magie zou je willen doen dan?

Want even uit mijn hoofd wordt de 5 min data elke dag gewist nadat er een 1 uur samenvatting van gemaakt is.

[Septillion]

@smeerbartje Op aanvulling op @Seafarer, moet moet dus wel een Thread border router hebben die de brug slaat tussen Thread en HA/ethernet.

[RobertMe]

Seafarer schreef op donderdag 20 november 2025 @ 21:40:
[...]

In HA kun je matter installeren. Dan kun je gelijk over wifi verbinden.
Devices & services.

Matter draait over je LAN (/WLAN). Thread is een soort van wifi alternatief, in dat het het draadloze protocol is, en gaat nog steeds IP zoals Matter overheen.
Om Thread te kunnen gebruiken heb je een Thread Border Router (TBR) nodig. Dat kan in hardware de ZBT-2 zijn die je linkte, maar ook bv de aangehaalde SMLight sticks (je zou dan ook een multi radio variant kunnen kopen zodat je een met Zigbee en een met Thread kunt gebruiken). Maar, Thread is "universeel". Als het goed is kun je ook de Ikea hub / "TBR" kopen. Die doet dan nog steeds dienst als "gateway" van Thread naar je LAN / netwerk en visa versa. In dat geval kun je Home Assistant laten verbinden met de Ikea hub en babbelt HA nog steeds via Matter "rechtstreeks" met je Thread apparaten. Dat dat onderwater via de Ikea hub gaat is vervolgens redelijk transparant. Hetzelfde als dat HA er niet van weet dat als die bv een "wifi apparaat" aanstuurt dat daar nog een access point / router tussen zit die een vertaling van ethernet over de kabel naar ethernet in de lucht doet.
Wil je alsnog een volledig generieke TBR hebben, met dan een eigen stick (ZBT-2, SMLight, ...) komt er bij mijn weten wel wat meer software bij kijken. Ten eerste heb je de TBR software nodig, en daarnaast meen ik ook een Matter controller (software). Waarna de HA Matter integratie dus verbind met de Matter controller (en de Thread apparaten dus via de TBR software op je LAN aankomen en ook babbelen met de Matter controller).

En owja, het kan ook zijn dat je al een TBR in huis hebt. Apple TV verschillende generaties zit een TBR in ingebakken, evenals verschillende HomePods. De Google Streamer meen ik ook? En potentieel nog veel meer hardware. Als je een van die apparaten hebt kun je dus direct aan de slag. Home Assistant koppel je aan die TBR (Apple TV bv dus), en de Ikea spulletjes (lampen / sensoren / ...) kun je ook pairen met de Apple TV. En HA ziet vervolgens die Matter (over Thread) apparaten.

Edit/aanvulling:
De theorie is overigens dat ook als je een Ikea hub met Thread koopt dat die universeel is. In theorie kun je daar dus ook Thread apparaten van andere merken aan koppelen en zullen deze normaliter ook volledig functioneren. Dus bv als je een Tado X thermostaat koopt zou je die moeten kunnen koppelen aan een Ikea TBR (of Apple TV, of HomePod, of Google Streamer, of ...) en vervolgens gewoon de Tado app kunnen gebruiken voor de volledige functionaliteit, of dan in HA gebruiken via de "Matter standaarden" (waarbij mogelijk niet alle functionaliteit beschikbaar is).

Edit / aanvulling 2:
En als je de "custom" oplossing route gaat bewandelen. Zowel de Matter controller als de OpenThread Border Router zijn bij mijn weten als addons in HA(OS) beschikbaar en dus met een paar klikken geregeld. (En mogelijk automagisch "ontdekt" / "voorbesteld" op basis van dat je een "Thread stick" hebt aangesloten?)

[ Voor 16% gewijzigd door RobertMe op 20-11-2025 22:29 ]

[Septillion]

@RobertMe Je eerste zin klopt niet. Matter kan je direct over LAN / WLAN draaien maar hoeft niet. Thread is in de basis protocolloos. Maar waar mensen het vaak over Thread hebben bedoelen ze dus Matter over Thread. Maar in principe zou het geen Matter hoeven zijn. Dat inzicht heeft bij mij ook even geduurd

[Brynnie]

Hmmbob schreef op donderdag 20 november 2025 @ 17:06:
[...]

Iets in de logs? Wat is je volledige code, voor beide devices dus?

Probleem was dat er telkens nieuwe entities gemaakt werden, entity_1, _2 en zo verder. Vaste uniqueid heeft het opgelost. Bedankt voor de feedback aan allen 👍🏻

[RobertMe]

Septillion schreef op donderdag 20 november 2025 @ 22:28:
@RobertMe Je eerste zin klopt niet. Matter kan je direct over LAN / WLAN draaien maar hoeft niet.

Mwah. in principe wel? Het hele idee is dat het "uiteindelijk" op je LAN / WLAN draait en ook internet connectivity en alles heeft. De "core" zeg maar draait dus op je LAN. Maar bv communicatie tussen twee Thread devices zal wel rechtstreeks aan elkaar worden geknoopt door Thread of de TBR (hetzelfde als dat een wifi AP niet je hele netwerk over gaat met communicatie tussen 2 clients van hetzelfde AP (maar in dat geval wel nog steeds client 1 iets naar het AP stuurt, en het AP het naar client 2 stuurt. Maar ik vermoed dat Thread dat nog steeds doet tenzij je iets als "direct bindings" gebruikt. Zigbee, ook gebaseerd op 802.15.4 is immers ook afhankelijk van de controller tenzij je direct bindings gebruikt).

Thread is in de basis protocolloos. Maar waar mensen het vaak over Thread hebben bedoelen ze dus Matter over Thread. Maar in principe zou het geen Matter hoeven zijn. Dat inzicht heeft bij mij ook even geduurd

Thread is inderdaad puur een "wifi alternatief" waar IP overheen gaat. Matter over Thread heeft dan Matter als data laag over IP en dan IP over Thread (i.p.v. IP over je LAN). Maar bv ESPHome gebruikt dan ook al Thread op de Thread supported ESP32 microcontrollers, als "ESPHome (API?) over Thread". Wat dus ook gewoon exact dezelfde data (over IP) is als bij de wifi devices over je (W)LAN gaat alleen dan over Thread (en door de TBR alsnog "omgezet" naar je LAN). ESPHome wisselt dus gewoon de onderliggende verbinding uit van een TCP/IP verbinding naar een Thread verbinding. Waarbij Matter/Thread/... natuurlijk ook al op IPv6 gebaseerd zijn, dus zelfs "de bestemming" veranderd vast niet en zal gewoon het IPv6 adres van je HA server blijven.

Edit:
Het feit dat Thread apparaten rucksichloss met internet mogen babbelen toont trouwens ook wel aan dat Thread gewoon een wifi/ethernet alternatief is zonder enige verdere kennis over de (IP) data die er overheen gaat. Anders kon je natuurlijk niet en een generieke TBR gebruiken (zelfbouw, Apple TV, ...) en alsnog je hardware bv buiten de deur via de cloud van de fabrikant aansturen. De generieke TBR kan immers geen "vertaling" doen zoals de merk specifieke hubs bij bv Zigbee wel doen. In de zin dat bv bij Hue (met Zigbee dan) de Hue app ook buiten de deur een API verzoek naar de Hue bridge stuurt, en de Hue bridge op basis daarvan een Zigbee bericht opstelt en naar de lamp(en) stuurt. Bij Thread kan dat echter niet, want de TBR is volledig transparant en uitwisselbaar, die kan niet een bericht komende van een vendor specifieke app verwerken en dat "vertalen" en op basis daarvan actie ondernemen. Die kan alleen maar de "brief" in een andere "envelop" stoppen en die envelop versturen.

[ Voor 20% gewijzigd door RobertMe op 20-11-2025 22:46 ]

[TheFes]

Septillion schreef op donderdag 20 november 2025 @ 21:55:
@JT Wat voor magie zou je willen doen dan?

Want even uit mijn hoofd wordt de 5 min data elke dag gewist nadat er een 1 uur samenvatting van gemaakt is.

Short Term Statistics zijn net zo lang als de recorder periode, standaard 10 dagen dus

[Septillion]

@RobertMe Helemaal correct. Maar doelde er dus vooral op dat je dus wel onderscheid moet maken tussen Thread en Matter over Thread. En dat toch meestal het laatste bedoelt wordt als mensen het over Thread hebben.

Juist dat inzicht dat Thread puur een low energy netwerk is waar je Matter over kunt draaien. Eigenlijk gewoon met jaloers oog naar Zigbee maar er was IP ondersteuning nodig. Maar ook Esphome over Thread, Tado over Thread etc. Maar die devices hoeven elkaar dus niet te verstaan. En om ze te integreren in HA heb je voor elk dus ook een eigen integratie nodig.

Probeer dus vooral bewust te maken dat als mensen zeggen "het device ondersteund Thread" dat dit maar de helft van het verhaal is. Er moet wel gespecificeerd worden "wat over Thread". Maarja, dat is steeds zo'n mond vol... Toch maar hebben over MoT?

[ Voor 6% gewijzigd door Septillion op 20-11-2025 22:50 ]

[RobertMe]

Septillion schreef op donderdag 20 november 2025 @ 22:47:
Tado over Thread

Deze bestaat niet Tado X gebruikt gewoon Matter. Waarbij Matter dan wel weer vendor specifieke "extensies" toestaat. Het kan dus best dat Tado (of welk ander merk dan ook) vendor specifieke extensies gebruikt voor bv functionaliteit die (nog) niet gestandariseerd is (of dus daadwerkelijk custom functionaliteit die nooit gestandariseerd zal worden). Daardoor kan/zal bepaalde functionaliteit dus niet werken in alternatieve "apps" (HA bv). Maar in theorie kan alles dus wel op basis van Matter en hoeft niet alsnog elke fabrikant zijn eigen "X over Thread" te bouwen.

Vanuit ESPHome is het dan wel weer logisch dat ze gewoon hun bestaande API aanhouden en over Thread sturen. Scheelt enorm veel werk om ook nog eens Matter ondersteuning toe te voegen. En door de generieke opzet van ESPHome (je klinkt je sensoren / data bij elkaar zeg maar) valt het toch al niet in Matter toe te passen denk ik zo (behalve dan "alles zit in een custom deel van Matter").

Mogelijk dat wel iets als HomeKit ook over Thread kan? Dat zou mij dan weer niks verbazen. Ook daarbij half omwille van "legacy".

[Septillion]

@RobertMe Okay, Tado was misschien een slecht voorbeeld. Maar niets stopt ze om een eigen protocol te draaien. Mijn punt was, je moet altijd spreken over "x over Thread" ipv over gewoon Thread als je wilt weten wat samen kan werken of hoe het integreert in HA. En naar mijn idee wordt dat steeds te slecht uitgelegd aan beginners. En waar een beginner dus vaak struikelt met het lezen van je antwoord. Niet dat het fout is dus.

Nog de grootste flaw van Matter daargelaten, de vendor extensions De grote dooddoener om devices onderling samen te laten werken als je het mij vraagt.

[JT]

Septillion schreef op donderdag 20 november 2025 @ 21:55:
@JT Wat voor magie zou je willen doen dan?

Want even uit mijn hoofd wordt de 5 min data elke dag gewist nadat er een 1 uur samenvatting van gemaakt is.

Ik wil inzicht in mijn kosten per kwartier. In dynamische contracten betaal je nu per kwartier een ander tarief. In HA kun je nu lang terug naar je verbruik per uur maar dat sluit sinds kort (de overgang naar elk kwartier een tarief is vrij kort geleden) dus niet meer aan bij de dynamische markt. De volgende stap is dat ik het verbruik van mijn ev-lader eraf trek qua verbruik. Want omdat ik met Grid Rewards laad is mijn laadtarief lager dan de reguliere energieprijs en zou ik een vertekend beeld van de kosten krijgen als ik laadkosten probeer mee te nemen. Helaas zijn de grid reward tarieven nog niet beschikbaar via een api en wil ik dus de elektrakosten ex laadpaal inzichtelijk hebben. Langer dan 10 dagen terug

[RobertMe]

Septillion schreef op donderdag 20 november 2025 @ 23:06:
Nog de grootste flaw van Matter daargelaten, de vendor extensions De grote dooddoener om devices onderling samen te laten werken als je het mij vraagt.

Van de ene kant 100% gelijk dat het een flaw is. Anderzijds 99% gelijk dat het er wel in zit. Alleen al nu in de "opbouw" fase dat lang niet alles in Matter zit. Wel zo fijn dan voor fabrikanten dat ze hun eigen zaken wel kunnen doen. Zie bv die nieuwe Aqara FP300 PIR / mmwave / lux / temp / luchtvochtigheid sensor. Met de Zigbee firmware "werkt alles" (incl in Z2M). Met de Matter/Thread firmware (default out of the box, switchen kan via hun app over Bluetooth) ontbreken er verschillende zaken / sensoren, met als reden "dat Matter het niet ondersteund" (IIRC is er bv maar 1 sensor voor "er is iemand", en is er geen onderscheid tussen de PIR en mmwave terwijl dat er wel is via Zigbee).

En gezien de levendige community bij Z2M en vast ook ZHA lijkt mij dat waar nodig HA ook wel custom extensies van Matter zou kunnen ondersteunen en dat bedreven wordt toegevoegd / onderhouden. Alleen zal dat natuurlijk een stuk minder gelden bij gesloten oplossingen. Apple of Google etc etc zullen niet snel ook nog eens allemaal merk specifieke zaken toevoegen qua ondersteuning, die zullen wel alleen de Matter standaard ondersteunen.
En bij Zigbee is de hele implementatie van endpoints en (mogelijke) waardes natuurlijk uberhaupt al vrijheid blijheid. Hier en daar liggen wel wat zaken vast (Zigbee Light Link voor lampen bv) maar vaak doet een fabrikant toch zijn eigen ding waardoor er uberhaupt aan de software kant een stuk "configuratie" nodig is om de verschillende endpoints correct te interpreteren / verwerken. En ook dat gaat heel prima in de HA / Z2M wereld. Dat Matter vervolgens een beetje een mix is van een "halve" (en levendige) standaard met daar bovenop nog merk specifieke zaken hoeft dan niet perse een probleem te zijn.

[Brynnie]

Met card_mod css

code:

.completed {
 display: none !important;
 height: 0 !important;
 margin: 0 !important;
 padding: 0 !important;
}

kan ik completed items van een local todo list verbergen.

Maar is er ook een mogelijkheid om na te gaan (via de integratie / entiteit / css / …) of een todo.entity afgevinkte (completed) items heeft?

Ik wil een button tonen om completed items te wissen. Dat lukt. Maar ik wil die button niet weergeven als er geen completed items zijn.

[Septillion]

@RobertMe Naar mijn idee hadden we in de overgang best even zonder gekund. En dan gewoon de device-gaten als er vraag was.

Want Tuurlijk zijn die vendor specifieke extensies wel weer te maken net als nu met ZHA/Z2M gebeurd. Maar dit gaat gewoon zorgen dat vendors nog steeds extraatjes daarachter gaan plakken. Precies zoals je zegt, andere vendors zie ik niet zo snel de custom extensions van de concurrent inbakken, in tegenstelling tot de community. En dus is inter-vendor compatibiliteit die belooft was dus toch niet zo waar. En dat vind ik dus zo jammer

[Septillion]

@Brynnie Er is todo.get_items waarmee je de completed items op kan vragen. Die zou je dus in een template sensor kunnen gieten om de items te tellen.

[RobertMe]

Septillion schreef op vrijdag 21 november 2025 @ 10:12:
Want Tuurlijk zijn die vendor specifieke extensies wel weer te maken net als nu met ZHA/Z2M gebeurd. Maar dit gaat gewoon zorgen dat vendors nog steeds extraatjes daarachter gaan plakken. Precies zoals je zegt, andere vendors zie ik niet zo snel de custom extensions van de concurrent inbakken, in tegenstelling tot de community. En dus is inter-vendor compatibiliteit die belooft was dus toch niet zo waar. En dat vind ik dus zo jammer

Maar voor ons met HA maakt inter-vendor compatibiliteit natuurlijk niet uit. En voor anderen zal de compatibiliteit wel flink toenemen.

Daarnaast vraag ik me ook af of alles echt gestandaardiseerd moet zijn. Terug naar Tado. De thermostaatknoppen moeten links of rechtsom hun warmte vraag naar de thermostaat kunnen sturen (die dit combineert en de ketel, bij voorkeur dan modulerend, aanstuurt). Is dit iets dat echt in de Matter spec uitgewerkt moet zitten? Zo gek is het IMO niet dat iemand of voor het volledige Tado systeem (of Evo, of ...) kiest en niet een Tado thermostaat gaat gebruiken met Sonoff knoppen of een Bosch thermostaat met Tado knoppen.

Excusses, quote en wijzig zitten dicht bij elkaar

[ Voor 26% gewijzigd door Septillion op 22-11-2025 15:43 ]

[ArthurMorgan]

Ik heb in mijn configuration.yaml dit blok staan. Het is van de neerslagkaart. ( https://github.com/aex351/home-assistant-neerslag-card )

_{de decimalen heb ik even op 00 gezet vanwege de privacy}

YAML:

    sensor:
  - platform: command_line
    command: python3 -c "import requests; import json; import random; dataRequest = requests.get('https://gpsgadget.buienradar.nl/data/raintext?lat=52.00&lon=6.00&c='+str(random.randint(0,999999999999999)) ).text; dataRequest = dataRequest.replace('\r\n',' '); data = '{\"data\":\"'+dataRequest+'\"}';    print(data);"
    name: Neerslag_Buienradar_Regen_Data
    json_attributes:
      - data
    value_template: 'last_changed: {{states.sensor.neerslag_buienradar_regen_data.last_changed | default(now())}}'
    scan_interval: 240

Echter ik krijg geen goed werkende entiteit eruit. (bij entiteiten staat "Niet beschikbaar". Via ontwikkelhulpmiddelen statussen ook (unavailable).

Als ik handmatig het adres https://gpsgadget.buienra...ndint(0,999999999999999)) opvraag krijg ik een wekende pagina (denk ik want er is geen regen op komst dus de waarden na de tijden zijn blanco)

Ik heb chatgpt het blok laten herschrijven. Die zegt dat er een ' in plaats van " moet op de command python lijn. Dat heb ik geprobeerd maar gaf geen andere uitkomst. (Daarna het origineel teruggezet omdat ik bij chatgpt toch vaak problemen krijg met die codes.)

Ik ben een echte beginner, meestal kom ik er wel uit, maar hier heb ik even geen idee waar ik precies moet kijken. Ik heb wel heel bewust de locatie hard ingevoerd, omdat me dat minder foutgevoelig lijkt dan hem uit HA zelf te halen.)

/edit: de buienalarm versie heeft zijn eigen probleem, maar dat lijkt niet bij de gebruiker te liggen. Dus dat is even geen optie.

[ Voor 6% gewijzigd door ArthurMorgan op 21-11-2025 10:36 ]

[Oon]

JT schreef op donderdag 20 november 2025 @ 20:50:
Ik wou vandaag wat gaan doen met live energiekosten berekenen enzo, Dus ik denk, eens kijken hoe ik dat moet doen met de nieuwe prijzen-per-kwartier voor dynamische energie. Tot mijn grote verbazing vind ik er heel weinig over in relatie tot Home Assistant. Het enige dat ik heb kunnen vinden was een discussie op Github bij HA waarin aangegeven wordt dat de huidige energieverbruikmonitoring per uur wordt opgeslagen en dat dat dan aangepast zou moeten worden. Gezien de hoeveelheid mensen die zich bezig houden met dynamische prijzen ophalen lijken mensen met een dynamisch contract een significante groep van de HA-gebruikers. Toch vind ik er verder weinig over Ik heb ook in dit topic gezocht op "15 minuten" en ook hier vind ik weinig. Kijk ik verkeerd of wordt er inderdaad weinig mee gedaan?

Ik heb gewoon een scriptje dat de prijzen van enever.nl plukt, een REST sensor die ze daar weer vanaf haalt, en dan een template sensor die 'huidige energieprijs' heet. Het Energy dashboard leest die uit en klaar.
Als mijn prijzen naar per kwartier ipv per uur gaan zou dat niks veranderen want ik heb nu al een 'geldig vanaf' en 'geldig tot' attribuut in de JSON data zitten.

[ Voor 6% gewijzigd door Oon op 21-11-2025 10:37 ]

[TheFes]

ArthurMorgan schreef op vrijdag 21 november 2025 @ 10:34:
Ik heb in mijn configuration.yaml dit blok staan. Het is van de neerslagkaart. ( https://github.com/aex351/home-assistant-neerslag-card )

_{de decimalen heb ik even op 00 gezet vanwege de privacy}

YAML:

    sensor:
  - platform: command_line
    command: python3 -c "import requests; import json; import random; dataRequest = requests.get('https://gpsgadget.buienradar.nl/data/raintext?lat=52.00&lon=6.00&c='+str(random.randint(0,999999999999999)) ).text; dataRequest = dataRequest.replace('\r\n',' '); data = '{\"data\":\"'+dataRequest+'\"}';    print(data);"
    name: Neerslag_Buienradar_Regen_Data
    json_attributes:
      - data
    value_template: 'last_changed: {{states.sensor.neerslag_buienradar_regen_data.last_changed | default(now())}}'
    scan_interval: 240

Echter ik krijg geen goed werkende entiteit eruit. (bij entiteiten staat "Niet beschikbaar". Via ontwikkelhulpmiddelen statussen ook (unavailable).

Als ik handmatig het adres https://gpsgadget.buienra...ndint(0,999999999999999)) opvraag krijg ik een wekende pagina (denk ik want er is geen regen op komst dus de waarden na de tijden zijn blanco)

Ik heb chatgpt het blok laten herschrijven. Die zegt dat er een ' in plaats van " moet op de command python lijn. Dat heb ik geprobeerd maar gaf geen andere uitkomst. (Daarna het origineel teruggezet omdat ik bij chatgpt toch vaak problemen krijg met die codes.)

Ik ben een echte beginner, meestal kom ik er wel uit, maar hier heb ik even geen idee waar ik precies moet kijken. Ik heb wel heel bewust de locatie hard ingevoerd, omdat me dat minder foutgevoelig lijkt dan hem uit HA zelf te halen.)

/edit: de buienalarm versie heeft zijn eigen probleem, maar dat lijkt niet bij de gebruiker te liggen. Dus dat is even geen optie.

Deze custom integratie van dezelfde developer maakt zelf de sensoren aan geeft je ook beschikking over de card. Je hebt dat andere Hacs component dan dus niet nodig
https://github.com/aex351/home-assistant-neerslag-app

[ArthurMorgan]

TheFes schreef op vrijdag 21 november 2025 @ 11:11:
[...]


Deze custom integratie van dezelfde developer maakt zelf de sensoren aan geeft je ook beschikking over de card. Je hebt dat andere Hacs component dan dus niet nodig
https://github.com/aex351/home-assistant-neerslag-app

Dank! Ik denk dat ik met mijn suffe hoofd ze sowieso door elkaar gebruikte. Want die had ik ook gedownload. Maar het werkt nu in elk geval.

[badkuip]

Hallo. Zijn er meer mensen die een Slimmelezer+ samen met Home assistant?
Het valt me vanochtend op dat ik al een uur lang geen data binnenkrijg. Maar het device is gewoon bereikbaar:


Hieronder een screenshot van de esphome-interface van de Slimmelezer.


Hierbij een export uit de database:


Waar of hoe begin ik met debuggen? Het Home assistant logboek heeft geen foutmeldingen voor dit device.

[TheFes]

badkuip schreef op vrijdag 21 november 2025 @ 11:29:
Hallo. Zijn er meer mensen die een Slimmelezer+ samen met Home assistant?
Het valt me vanochtend op dat ik al een uur lang geen data binnenkrijg. Maar het device is gewoon bereikbaar:
[Afbeelding]

Hieronder een screenshot van de esphome-interface van de Slimmelezer.
[Afbeelding]

Hierbij een export uit de database:
[Afbeelding]

Waar of hoe begin ik met debuggen? Het Home assistant logboek heeft geen foutmeldingen voor dit device.

Verbruik je niet gewoon al je zonnestroom, zodat je niets meer exporteert? Droger aangezet ofzo?

[Brynnie]

Septillion schreef op vrijdag 21 november 2025 @ 10:12:
@RobertMe Naar mijn idee hadden we in de overgang best even zonder gekund. En dan gewoon de device-gaten als er vraag was.

Want Tuurlijk zijn die vendor specifieke extensies wel weer te maken net als nu met ZHA/Z2M gebeurd. Maar dit gaat gewoon zorgen dat vendors nog steeds extraatjes daarachter gaan plakken. Precies zoals je zegt, andere vendors zie ik niet zo snel de custom extensions van de concurrent inbakken, in tegenstelling tot de community. En dus is inter-vendor compatibiliteit die belooft was dus toch niet zo waar. En dat vind ik dus zo jammer

Ik wil in een dashboard het aantal completed items zien, om aan de hand daarvan de "wis-button" wel of niet te tonen.
Een todo.xyz entity heeft blijkaar een zeer beperkt aantal attributen:

code:

type: markdown
content: >
  {% set e = states['todo.xyz'] %}
  **{{ e.entity_id }}**

  State: `{{ e.state }}`

  **Attributen:**
  {% for k, v in e.attributes.items() %}
  - **{{ k }}:** {{ v }}
  {% endfor %}

geeft

code:

todo.xyz
State: 1
Attributen: - friendly_name: Xyz- supported_features: 127

Waarvoor staat dat supported_features attribuut eigenlijk? Dat heb ik al vaker zien terugkomen.

[badkuip]

TheFes schreef op vrijdag 21 november 2025 @ 11:55:
[...]


Verbruik je niet gewoon al je zonnestroom, zodat je niets meer exporteert? Droger aangezet ofzo?

Dat zou best het geval kunnen zijn.
Maar ik zou toch nog steeds berichten moeten ontvangen in Home assistant?
Het lijkt alsof er voor een langere tijd helemaal geen berichten zijn binnengekomen.

[TheFes]

Brynnie schreef op vrijdag 21 november 2025 @ 12:05:
[...]


Ik wil in een dashboard het aantal completed items zien, om aan de hand daarvan de "wis-button" wel of niet te tonen.
Een todo.xyz entity heeft blijkaar een zeer beperkt aantal attributen:

code:

type: markdown
content: >
  {% set e = states['todo.xyz'] %}
  **{{ e.entity_id }}**

  State: `{{ e.state }}`

  **Attributen:**
  {% for k, v in e.attributes.items() %}
  - **{{ k }}:** {{ v }}
  {% endfor %}

geeft

code:

todo.xyz
State: 1
Attributen: - friendly_name: Xyz- supported_features: 127

Waarvoor staat dat supported_features attribuut eigenlijk? Dat heb ik al vaker zien terugkomen.

Supported featues geeft een bitwise waarde van de features die het support.

Voorbeeld voor een light:
featues:

code:

    EFFECT = 4
    FLASH = 8
    TRANSITION = 32

als een light dan zowel effect als transition ondersteunt, wordt de supported_featueres waarde 36 (4+32)
Als het effect en flash ondersteunt is het 12 (4+8)

Voor todo zijn dit de features:

code:

    CREATE_TODO_ITEM = 1
    DELETE_TODO_ITEM = 2
    UPDATE_TODO_ITEM = 4
    MOVE_TODO_ITEM = 8
    SET_DUE_DATE_ON_ITEM = 16
    SET_DUE_DATETIME_ON_ITEM = 32
    SET_DESCRIPTION_ON_ITEM = 64

Jouw todo entity ondersteunt dus al deze features (1+2+4+8+16+32+64)

[TheFes]

badkuip schreef op vrijdag 21 november 2025 @ 12:08:
[...]


Dat zou best het geval kunnen zijn.
Maar ik zou toch nog steeds berichten moeten ontvangen in Home assistant?
Het lijkt alsof er voor een langere tijd helemaal geen berichten zijn binnengekomen.

Zolang de state hetzelfde blijft (0 dus) rapporteert de entity geen state wijziging, dus als hij een uur lang op 0 blijft, dan zul je zien dat hij 1 uur geleden voor het laatst gewijzigd is.

Er is ook een last_reported waarde, maar die kun je alleen met templates zien.

[badkuip]

TheFes schreef op vrijdag 21 november 2025 @ 12:43:
[...]


Zolang de state hetzelfde blijft (0 dus) rapporteert de entity geen state wijziging, dus als hij een uur lang op 0 blijft, dan zul je zien dat hij 1 uur geleden voor het laatst gewijzigd is.

Er is ook een last_reported waarde, maar die kun je alleen met templates zien.

Bedankt voor je reactie en voor je pointers. Ik zal het binnenkort eens nalopen aan de hand van de last_reported-waarde.

[Brynnie]

TheFes schreef op vrijdag 21 november 2025 @ 12:41:
[...]

Supported featues geeft een bitwise waarde van de features die het support.

Voorbeeld voor een light:
featues:

code:

    EFFECT = 4
    FLASH = 8
    TRANSITION = 32

als een light dan zowel effect als transition ondersteunt, wordt de supported_featueres waarde 36 (4+32)
Als het effect en flash ondersteunt is het 12 (4+8)

Voor todo zijn dit de features:

code:

    CREATE_TODO_ITEM = 1
    DELETE_TODO_ITEM = 2
    UPDATE_TODO_ITEM = 4
    MOVE_TODO_ITEM = 8
    SET_DUE_DATE_ON_ITEM = 16
    SET_DUE_DATETIME_ON_ITEM = 32
    SET_DESCRIPTION_ON_ITEM = 64

Jouw todo entity ondersteunt dus al deze features (1+2+4+8+16+32+64)

Maar wat ik wil, 'on the fly' checken of er completed items zijn, om een button wel/niet te verbergen, kan niet?

[TheFes]

Brynnie schreef op vrijdag 21 november 2025 @ 12:56:
[...]


Maar wat ik wil, 'on the fly' checken of er completed items zijn, om een button wel/niet te verbergen, kan niet?

Nee, dat kan niet. Om te kijken of er afgestreepte items zijn moet je een action gebruiken.
Wat je kunt doen is een trigger based template binary sensor maken, die triggert op een state change van de todo-entity.
Vervolgens met de action de items van de todo entity ophalen, en de binary sensor naar on laten gaan als er afgestreepte items zijn.
Die kun je dan gebruiken als condition voor je kaart.

[Septillion]

RobertMe schreef op vrijdag 21 november 2025 @ 10:25:
[...]

Maar voor ons met HA maakt inter-vendor compatibiliteit natuurlijk niet uit.

Dat zou ik niet willen zeggen. Nu moeten als nog mensen protocollen gaan reverse engineeren. Die zullen de meeste vendors toch niet op een presenteerblaadje geven.

En voor anderen zal de compatibiliteit wel flink toenemen.

En daar ben ik dus heel sceptisch over...

Daarnaast vraag ik me ook af of alles echt gestandaardiseerd moet zijn. Terug naar Tado. De thermostaatknoppen moeten links of rechtsom hun warmte vraag naar de thermostaat kunnen sturen (die dit combineert en de ketel, bij voorkeur dan modulerend, aanstuurt). Is dit iets dat echt in de Matter spec uitgewerkt moet zitten? Zo gek is het IMO niet dat iemand of voor het volledige Tado systeem (of Evo, of ...) kiest en niet een Tado thermostaat gaat gebruiken met Sonoff knoppen of een Bosch thermostaat met Tado knoppen.

Naar mijn idee, heel graag. Juist dat je dus niet nog een hub nodig hebt als je ook Hue wilt gebruiken juich ik toe.

[RobertMe]

Septillion schreef op zaterdag 22 november 2025 @ 15:44:
[...]

Naar mijn idee, heel graag. Juist dat je dus niet nog een hub nodig hebt als je ook Hue wilt gebruiken juich ik toe.

Nah, maar dat hoeft sowieso niet. Tado X werkt als het goed is prima over een Apple TV bv (dat staat op hun eigen website namelijk). Dus welke TBR je gebruikt maakt niet uit, en dan heb je ook geen extra hardware nodig buiten een thermostaat en eventueel knoppen (of alleen knoppen als je stadsverwarming / ... hebt en dus geen CV / warmtepomp hoeft aan te sturen). In die mate is de compatibiliteit er dus om zaken in 1 Thread netwerk te gooien zonder dat je bv de Tado Bridge X moet kopen. Dat "anderen" (gedeeltelijk) kunnen mee luisteren naar het IP verkeer dat over het netwerk gaat en een deel van de Matter inhoud wel snappen en een deel niet maakt dan verder niet heel veel uit. Zolang de "basis functionaliteit" (uitlezen temperatuur, instellen temperatuur, ...) maar werkt op basis van wat daadwerkelijk in Matter vast ligt. Dat er dan ook "inhoud" is v.w.b. "mijn zone heeft graag 'voor 33% warmtevraag'" tussen een knop en de thermostaat is IMO dan minder relevant. Tenzij je dus zou willen mix en matchen van merken hardware in de verwarming aansturing. Maar als je dat wilt zou ik dus niet in een semi gesloten systeem als Tado stappen die het als een geheel verkopen. (terwijl bv Bosch meen ik wel "knoppen" en "thermostaten" verkoopt maar het niet als een geheel doet en bv dan ook niet "je moet beginnen met een starter set").

[Septillion]

TheFes schreef op vrijdag 21 november 2025 @ 12:43:
[...]


Zolang de state hetzelfde blijft (0 dus) rapporteert de entity geen state wijziging, dus als hij een uur lang op 0 blijft, dan zul je zien dat hij 1 uur geleden voor het laatst gewijzigd is.

Er is ook een last_reported waarde, maar die kun je alleen met templates zien.

En @badkuip, volgens mij is dat dus recent wat aangepast. Eerst kon je alle update punten nog in de grafiek zien naar mijn idee.

En er lijkt me een bug in te zitten. Als je in more info over de tijd gaat krijg je een tooltip box die zowel last changed als last updated geeft. Maar voor ESPHome sensor waarvan ik zeker weet dat hij wel elke seconde update maar niet wijzigt geeft deze dezelfde tijden weer Ook als ik in dev tools de last_changed en last_updated bekijk zijn deze gelijk.

Weet even niet of dit een HA bug is of een bug in de ESPHome integratie.

[ Voor 9% gewijzigd door Septillion op 22-11-2025 15:59 ]

[Septillion]

@RobertMe Tja, dan verschillen we daar gewoon van mening. En ben ik dus sceptisch over de compatibiliteit. Ja, kan dan over één Thread netwerk maar dat noem ik geen compatibiliteit.

[RobertMe]

Septillion schreef op zaterdag 22 november 2025 @ 16:04:
@RobertMe Tja, dan verschillen we daar gewoon van mening. En ben ik dus sceptisch over de compatibiliteit. Ja, kan dan over één Thread netwerk maar dat noem ik geen compatibiliteit.

Nouja, IMO moet er dus ook compatibiliteit zijn, en dat is er AFAIK ook wel. Maar voor de gewone consument en de "standaard" generieke controller (Google Home, Apple Home(Kit?), ...) en evt ook Home Assistant etc is natuurlijk het voornaamste dat het mogelijk is om de temperatuur van een ruimte in te stellen (en de huidige temp te kunnen zien etc). De werking onderwater dat de thermostaatknop vervolgens babbelt met de thermostaat om zijn warmtevraag bekend te maken (zodat de thermostaat de ketel "start" of "stopt) is niet heel relevant
Tenzij je dus echt volledig zelf de CV wilt bouwen en zelf de ketel aansturen. (Dus zelf in een controller de temperaturen tegen setpoints af zet, bepaalt hoe hard de ketel moet lopen, en via bv een OpenTherm Gateway de ketel aanstuurt). En ik heb juist, eerder, Tado (v3, dus nog geen Thread) gekocht juist omdat ik niet alles zelf wil bouwen incl aansturing ketel etc. Zolang HA gewoon een setpoint kan instellen in een ruimte en Tado het zelf uitzoekt vind ik het helemaal prima. Of nouja..., eigenlijk werkt Tado zo slecht / "dom" dat ik alsnog hik tegen zelfbouw. Maar "Henk en Ingrid" zullen dat uberhaupt niet overwegen.

[TheFes]

Septillion schreef op zaterdag 22 november 2025 @ 15:57:
[...]

En @badkuip, volgens mij is dat dus recent wat aangepast. Eerst kon je alle update punten nog in de grafiek zien naar mijn idee.

En er lijkt me een bug in te zitten. Als je in more info over de tijd gaat krijg je een tooltip box die zowel last changed als last updated geeft. Maar voor ESPHome sensor waarvan ik zeker weet dat hij wel elke seconde update maar niet wijzigt geeft deze dezelfde tijden weer Ook als ik in dev tools de last_changed en last_updated bekijk zijn deze gelijk.

Weet even niet of dit een HA bug is of een bug in de ESPHome integratie.

Volgens mij is daar niets aan veranderd.
Wat wel verandert is, is dat er een last_reported waarde toegevoegd is aan het state object. Deze kun je echter niet zien in devtools > states, maar wel via templates.

[Septillion]

@TheFes En wat is dan het verschil tussen last updated en last reported?

[TheFes]

Septillion schreef op zaterdag 22 november 2025 @ 22:10:
@TheFes En wat is dan het verschil tussen last updated en last reported?

last_updated is de laatste keer wanneer de state of één van de attributes gewijzigd is.
last_changed is de laatste keer wanneer de state gewijzigd is.
last_reported is de laatste keer wanneer er een update van de integration is ontvangen.

Hier meer info
https://developers.home-a...state_reported_timestamp/

[remcoXP]

iemand al de led boards van de action (https://www.action.com/nl-nl/p/3217439/led-pixelbord/) in home assistant aan de praat gekregen?
ik zie dat iemand al ver is met een python prog (https://github.com/Pupariaa/Bk-Light-AppBypass/), dus een home assistant addon of integratie moet ook kunnen.
of misschien nog leuker een esphome die het board aanstuurt.

ik zou dan een parkeer sensor willen maken, of een clock met af en toe belangrijke notifications.

[JPD68]

Gisteren een Core update van Home Assistant gedraaid. Nu is HA de connectie met de Alfen Lader kwijt, in de (condensed) logs staat geen foutmelding. Heb debugging aangezet en zie daar de volgende 'fout':
[custom_components.alfen_wallbox.coordinator] Finished fetching alfen_wallbox data in 30.003 seconds (success: False)

Bij de integratie staat:

code:

Failed setup, will retry:
Check the logs

En bij alle informatie in de dashboards:

code:

This entity is no longer being provided by the alfen_wallbox integration. If the entity is no longer in use, delete it in settings.

Uit de debug log blijkt dat er wel verbinding wordt gemaakt, de lader functioneert ook goed.

Iemand enig idee wat er aan de hand kan zijn?

Update 24-11:Integratie verwijderd en opnieuw toegevoegd. Nu werkt het wel

[ Voor 4% gewijzigd door JPD68 op 24-11-2025 12:45 . Reden: Opgelost ]

[badkuip]

Septillion schreef op zaterdag 22 november 2025 @ 15:57:
[...]

En @badkuip, volgens mij is dat dus recent wat aangepast. Eerst kon je alle update punten nog in de grafiek zien naar mijn idee.

En er lijkt me een bug in te zitten. Als je in more info over de tijd gaat krijg je een tooltip box die zowel last changed als last updated geeft. Maar voor ESPHome sensor waarvan ik zeker weet dat hij wel elke seconde update maar niet wijzigt geeft deze dezelfde tijden weer Ook als ik in dev tools de last_changed en last_updated bekijk zijn deze gelijk.

Weet even niet of dit een HA bug is of een bug in de ESPHome integratie.

Bedankt voor de analyse. Het is voor mij nu wel verklaard hoe het kan.

Maar in welk scherm heb jij die tooltip box? Het More info-scherm kan ik niet vinden, het "Toon Meer" (in het engels Show more?) scherm wel. Daar zie ik maar 1 tijdstip genoemd worden in de tooltip.




Welk scherm bedoel je dus?

[commentator]

Heeft iemand wel eens de bestaande deurbel hergebruikt via HA na aanschaf van bijv een reolink deurbel?
Zo ja hoe?

[Just_A_User]

Ik zie in verschillende voorbeeldschermen van de GUI die mensen zelf maken, niet per se in dit topic maar op internet verschillende pie chart diagrammen voorbij komen.

Daar wil ik wat mee experimenteren, maar ik lijk geen pie chart te kunnen vinden in de beschikbare set Kaarten. Iemand een tip wat ik daarvoor kan gebruiken?

[JeroenH]

UnitedJunk schreef op dinsdag 15 juli 2025 @ 16:15:
Ik heb mijn IKEA lampen en stekkers via Matter integratie aangesloten op HA. Nu was het bekend dat de Inspelning stekker (die met energiemonitor) via Zigbee het verbruik wel doorgeeft, en via Matter (nog) niet. Maar nu de Dirigera onlangs een Matter update heeft gekregen zou ik verwachten dat dit nu wel werkt, maar helaas. Komt dit nog of?

Weet iemand hoe dit annu nu zit? Ik heb tien Inspelnings gekocht, en power/energy entiteiten zijn niet zichtbaar in HA (wel in de Ikea app).

"Hoort" dit, of is het mogelijk om dit werkzaam te maken via de Dirigera hub?

Ik heb geprobeerd Matter werkzaam te maken, met de Dirigera als Matter... "hub"? maar ik begrijp er niets van hoe dat zou moeten. Ik zit al twee dagen te googlen, maar ik kan geen fatsoenlijke howto vinden die werkt. Sowieso vind ik van zowel de Dirigera als de Inspelnings (ze hebben beiden de laatste FW) letterlijk geen enkele indicatie dat ze Matter daadwerkelijk ondersteunen. Geen Matter-logo op de hardware, en alles wat met de Dirigera in de app te maken heeft werkt niet.

Iemand een idee? Anders breng ik die Inspelnings maar weer terug, nu ik er mijn geld nog voor terug krijg...

[Borromini]

Just_A_User schreef op zondag 23 november 2025 @ 15:19:
Ik zie in verschillende voorbeeldschermen van de GUI die mensen zelf maken, niet per se in dit topic maar op internet verschillende pie chart diagrammen voorbij komen.

Daar wil ik wat mee experimenteren, maar ik lijk geen pie chart te kunnen vinden in de beschikbare set Kaarten. Iemand een tip wat ik daarvoor kan gebruiken?

Apex Charts kan dat. Documentatie: https://apexcharts.com/docs/chart-types/pie-donut/

[peterpijpelink]

- verkeerde topic -

[ Voor 95% gewijzigd door peterpijpelink op 23-11-2025 17:21 ]

[alex3305]

Misschien wel leuk om te vermelden. Vandaag heb ik de batterijen van een van mijn Philips Hue Remotes vervangen. "Maar Alex", hoor ik jullie door mijn scherm al denken, "wat kan mij die verrotte batterijen van jou toch interesseren ?".

Nou, in mei van dit jaar gaf @peterpijpelink de suggestie om een batterij notificatie blueprint te gebruiken om batterijstatus in de gaten te houden. Toen reageerde ik daar al op dat ik die blueprints dus onhandig vind, omdat sommige apparaten heel lang een 'leeg' kunnen rapporteren. Ik vind dat enorm zonde van de batterijen.

Destijds gaf k dus het voorbeeld van deze afstandsbediening. Die rapporteert namelijk sinds maart dat deze leeg of bijna leeg is:



Gisteren was echter pas het moment dat de afstandsbediening kuren begon te vertonen en niet meer betrouwbaar reageerde. Dat betekend dus dat dit apparaat nog 5 maanden mee kon gaan op een 'lege batterij'. Dit was tevens niet de eerste keer, want vorig jaar was er een vergelijkbare situatie:



In dat geval duurde het zo'n 3 maanden voordat vervanging echt noodzakelijk was. Tot nu toe heb ik dus al 8 maanden batterijduur uitgespaard.

Hierom ben ik dus in veel gevallen geen fan van 'lege batterij'-notificaties en vervang ik veel liever batterijen wanneer dit pas echt nodig is. Bijvoorbeeld als de betrouwbaarheid omlaag gaat of functionaliteit wegvalt. Dat korte ongemak neem ik dan maar voor lief.

[Septillion]

TheFes schreef op zaterdag 22 november 2025 @ 22:32:
[...]


last_updated is de laatste keer wanneer de state of één van de attributes gewijzigd is.
last_changed is de laatste keer wanneer de state gewijzigd is.
last_reported is de laatste keer wanneer er een update van de integration is ontvangen.

Hier meer info
https://developers.home-a...state_reported_timestamp/

Aha. Ja, eerst deed last_updated dienst als "er is een update van de integratie" en was er geen echte manier on direct de laatste wijziging van een attribute te zien.

Maar zou wel nice zijn als ze dan last_reported ook toe zouden voegen aan de UI.

@badkuip Je eerst screenshot is het more info scherm. Krijg je na de action more-info op een button.

Als je daar over "1 minuut geleden" gaat krijg je een tooltip waar ook last_updated in staat. Maar het zou naar mijn idee nu wel iets duidelijker in de UI verwerkt mogen worden. (En stoppen met aggregated daar...)

[TheFes]

Septillion schreef op zondag 23 november 2025 @ 17:40:
[...]

Aha. Ja, eerst deed last_updated dienst als "er is een update van de integratie" en was er geen echte manier on direct de laatste wijziging van een attribute te zien.

Maar zou wel nice zijn als ze dan last_reported ook toe zouden voegen aan de UI.

@badkuip Je eerst screenshot is het more info scherm. Krijg je na de action more-info op een button.

Als je daar over "1 minuut geleden" gaat krijg je een tooltip waar ook last_updated in staat. Maar het zou naar mijn idee nu wel iets duidelijker in de UI verwerkt mogen worden. (En stoppen met aggregated daar...)

last_updated is altijd alleen gewijzigd bij een wijziging van een attribute. Voordat last_reported toegevoegd is was er geen manier om te zien wanneer er voor het laatst een update vanuit de integratie was.

Zie ook bijvoorbeeld dit oude WTH issue uit 2022.
https://community.home-as...-received/480251?u=thefes

Overigens is last_reported al in 2024.4 toegevoegd, dat is al wat langer geleden dan ik zelf dacht.

[Pierovic]

remcoXP schreef op zaterdag 22 november 2025 @ 23:32:
iemand al de led boards van de action (https://www.action.com/nl-nl/p/3217439/led-pixelbord/) in home assistant aan de praat gekregen?
ik zie dat iemand al ver is met een python prog (https://github.com/Pupariaa/Bk-Light-AppBypass/), dus een home assistant addon of integratie moet ook kunnen.
of misschien nog leuker een esphome die het board aanstuurt.

ik zou dan een parkeer sensor willen maken, of een clock met af en toe belangrijke notifications.

Ik kwam deze tegen: https://github.com/Bram-diederik/iPixel-CLI-for-hass Misschien is dit iets voor jouw.

[Barfman]

Er is een update geweest van Studio Code Server v6.0.0, en daar is de handige functie uuid-generator uitgehaald.

Remove netcorext.uuid-generator, it is now built-in the HA extension

Misschien kijk ik ergens over heen, maar hoe activeer of gebruik je de built-in HA extension

[TheFes]

Barfman schreef op zondag 23 november 2025 @ 21:06:
Er is een update geweest van Studio Code Server v6.0.0, en daar is de handige functie uuid-generator uitgehaald.

[...]


Misschien kijk ik ergens over heen, maar hoe activeer of gebruik je de built-in HA extension

Die heb ik inderdaad ook nog niet gevonden

@Barfman
Hij zou het zo te zien zelf moeten aanbieden
https://github.com/keessc...-home-assistant/pull/3573

[ Voor 14% gewijzigd door TheFes op 23-11-2025 21:18 ]

[Barfman]

@TheFes Hij bied bij mij niets aan

Edit: Je moet id: typen en dan komt er een pop-up met Generate UUID

[ Voor 47% gewijzigd door Barfman op 23-11-2025 22:10 ]

[fissa]

Worden er ergens nog leuke black Friday deals bijgehouden / gedeeld inzake home assistant hardware? Hoop eigenlijk een nucje met n100/n500 met 8-16gb en 256 ssd op de kop te tikken. Wil in principe gewoon ha draaien, maar dan wel toekomstbestendig. Excuus als het niet de bedoeling is om hier de vraag weg te leggen. Gr.

Hier is inderdaad niet de bedoeling. Je kan een topic openen in Aanbiedingen en kortingscodes als je leuke aanbiedingen hebt gevonden.

[ Voor 20% gewijzigd door Septillion op 24-11-2025 10:09 ]

[Btje]

YAML:

        - icon: mdi:power
          entity: input_select.tutorial_thermostat
          name: false
          state_styles:
            "off":
              button:
                background: var(--active-small)
              icon:
                color: var(--black)
          tap_action:
            action: call-service
            service: input_select.select_option
            target:
              entity_id: input_select.tutorial_thermostat
            service_data:
              option: "off"
          ripple: none
          styles:
            button:
              background: var(--gray150)
              width: 34px
              height: 34px
              border-radius: 50% 0 0 50%
            icon:
              color: var(--gray800)

Ik heb een stuk yaml code overgenomen voor een thermostaat card. Aangegeven werd dat de buttons acties aangepast moeten worden naar je eigen airco in dit geval. Maar hoe vind ik die (input-select)?

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

[TheFes]

Btje schreef op maandag 24 november 2025 @ 15:51:

code:

        - icon: mdi:power
          entity: input_select.tutorial_thermostat
          name: false
          state_styles:
            "off":
              button:
                background: var(--active-small)
              icon:
                color: var(--black)
          tap_action:
            action: call-service
            service: input_select.select_option
            target:
              entity_id: input_select.tutorial_thermostat
            service_data:
              option: "off"
          ripple: none
          styles:
            button:
              background: var(--gray150)
              width: 34px
              height: 34px
              border-radius: 50% 0 0 50%
            icon:
              color: var(--gray800)

Ik heb een stuk yaml code overgenomen voor een thermostaat card. Aangegeven werd dat de buttons acties aangepast moeten worden naar je eigen airco in dit geval. Maar hoe vind ik die (input-select)?

Een input_select is een helper, die je zelf aan moet maken.
Die doet verder ook niets als hij wijzigt, dus daar zul je dan ook zelf een automation achter moeten hangen.

[Btje]

TheFes schreef op maandag 24 november 2025 @ 15:56:
[...]

Een input_select is een helper, die je zelf aan moet maken.
Die doet verder ook niets als hij wijzigt, dus daar zul je dan ook zelf een automation achter moeten hangen.

Kan mij niet voorstellen dat voor het aan en uitzetten of aanpassen temperatuur van een airco automations gebruikt worden.

Dit wou ik na maken:

YouTube: Advanced Thermostat Card for Home Assistant