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.