Home Assistant: Open source Python3 home automation - deel 5

[Acrobat]

B-Force schreef op maandag 12 januari 2026 @ 07:45:
[...]


Welk menuutje is dat aan de rechterkant? Ik gebruik zelf nu een sidebar, maar dit is ook wel netjes!

Als je met rechts de lijst van kamers bedoelt, feitelijk is dat een grid met twee vertical stacks van custom button cards. Een button card voor elke kamer. Mocht je de paarse ‘selector’ daar net boven (‘alle kamers’) bedoelen, dat is een heading card met een badge. Die badge toggle’t bij aantikken alleen een input-boolean die door de visibility condition op de button cards wordt uitgelezen. Zo kun je eenvoudig bepaalde kamers dus button-cards ‘verbergen’.

[Stefan1987]

NeoFoX schreef op maandag 12 januari 2026 @ 10:44:
Iemand hier nog een idee voor een nieuwe / andere oplossing voor:
- Temp sensor
- Humidity sensor
- Met readable-screen
- Stroom / USB powered

Ik heb nu een jaar 2x een Sonoff met screen, maar die batterijen gaat leeg waar je bij staat en daar wil ik dus vanaf.

Idee was dus om deze te vervangen voor die van IKEA: VINDSTYRKA Maar deze is én niet meer beschikbaar én levert geen decimalen achter de komma, wat ik wel graag wil voor wat meer details.
- De nieuwe van de IKEA: ALPSTUGA moet je klikken om de verschillende waardes te zien en dat wil ik niet

Vraag:
- Welke oplossing hebben jullie hiervoor staan / in gebruik?

Mag via WiFi of Zigbee, heb beiden...

Ik heb gisteren nog 2 x Vindstryka bij IKEA Amersfoort gehaald. Ik gebruik deze in combinatie Timmerflotte. Die is alleen geen USB, maar 2 x AAA

[Koepert]

Septillion schreef op maandag 12 januari 2026 @ 13:07:
@Koepert Kijk je in Proxmox of in Glances?

Hier geeft Proxmox namelijk 93% van de 4GB aan en Glances maar 42%.

Glances zegt 1.2GB voor Core en 900MB voor Supervisor.

Both. Deze proxmox-host heeft 1 VM draaien, Home Assistant:

Host:

code:

RAM usage 92.39% (7.09 GiB of 7.68 GiB)

TOP in de Host-shell draaien geeft overigens::

code:

MiB Mem :   7860.6 total,    328.6 free,   7290.8 used,    553.0 buff/cache

VM:

code:

Memory usage 88.96% (7.12 GiB of 8.00 GiB)

Heb studio code server add-on uitgezet, dat scheelt best.

Maar ik zie nu opeens dat de Host 7,68 GiB heeft en de VM 8.00 GiB.. Zou dat oorzaak zijn?

Glances in Home Assistant is inderdaad een stuk milder:

code:

MEM 23%
total:  7.75G
used:   1.8G
free:   5.97G
active: 3.14G
inactive:   3.38G
buffers:    210M
cached: 4.61G

Grootste verbruikers:

code:

hassio_supervisor                  1.16G    
homeassistant                           1.13G   
addon_a0d7b954_influxdb 1.01G

[ Voor 10% gewijzigd door Koepert op 12-01-2026 13:57 ]

[TheFes]

Koepert schreef op maandag 12 januari 2026 @ 13:47:
[...]


Both. Deze proxmox-host heeft 1 VM draaien, Home Assistant:

Host: RAM usage 92.39% (7.09 GiB of 7.68 GiB)
TOP in de Host-shell draaien geeft overigens::

MiB Mem : 7860.6 total, 328.6 free, 7290.8 used, 553.0 buff/cache


VM: Memory usage 88.96% (7.12 GiB of 8.00 GiB) Heb studio code server add-on uitgezet, dat scheelt best.

Maar ik zie nu opeens dat de Host 7,68 GiB heeft en de VM 8.00 GiB.. Zou dat oorzaak zijn?

Glances in Home Assistant is inderdaad een stuk milder:

MEM 23%
total: 7.75G
used: 1.8G
free: 5.97G
active: 3.14G
inactive: 3.38G
buffers: 210M
cached: 4.61G

hassio_supervisor 1.16G
homeassistant 1.13G
addon_a0d7b954_influxdb 1.01G

Weet je zeker dat je niet 7.68 GiB met 8.00 GB vergelijkt? (alhoewel 8 GB overeenkomt met 7.45 GiB)

[Koepert]

TheFes schreef op maandag 12 januari 2026 @ 13:52:
[...]


Weet je zeker dat je niet 7.68 GiB met 8.00 GB vergelijkt? (alhoewel 8 GB overeenkomt met 7.45 GiB)

Hoe bedoel je dat? Alles dat ik hier geplakt heb is zoals het in de interface staat (voor de verduidelijking dat ff in codeblocks gezet in mn vorige post.

[TheFes]

Koepert schreef op maandag 12 januari 2026 @ 13:55:
[...]


Hoe bedoel je dat? Alles dat ik hier geplakt heb is zoals het in de interface staat (voor de verduidelijking dat ff in codeblocks gezet in mn vorige post.

Dat er een verschil zit in GiB en GB
8 GB (gigabyte) is 8 * 10⁹ bytes = 8.000.000.000 bytes
8 GiB (gibibyte) is 8 * 2³⁰ bytes = 8.589.934.592 bytes

Dus als bij de ene waarde je unit GB is, en bij de andere GiB, dan kun je die niet met elkaar vergelijken.
8,00 gigabyte komt overeen met 7,45 gibibyte.

[PeteSplit]

NeoFoX schreef op maandag 12 januari 2026 @ 10:44:
Iemand hier nog een idee voor een nieuwe / andere oplossing voor:
- Temp sensor
- Humidity sensor
- Met readable-screen
- Stroom / USB powered

Ik heb nu een jaar 2x een Sonoff met screen, maar die batterijen gaat leeg waar je bij staat en daar wil ik dus vanaf.

Idee was dus om deze te vervangen voor die van IKEA: VINDSTYRKA Maar deze is én niet meer beschikbaar én levert geen decimalen achter de komma, wat ik wel graag wil voor wat meer details.
- De nieuwe van de IKEA: ALPSTUGA moet je klikken om de verschillende waardes te zien en dat wil ik niet

Vraag:
- Welke oplossing hebben jullie hiervoor staan / in gebruik?

Mag via WiFi of Zigbee, heb beiden...

Ik wilde een Shelly aanschaffen, deze zou een USB aansluiting hebben, maar is wel duur. Ik twijfel nog.
uitvoering: Shelly H&T Gen3 Wit

[Septillion]

@Koepert Meet RAM aan de VM geven dan de host heeft is natuurlijk wel vreemd. Maar neem aan de Proxmox dat dan wel in de gaten houdt.

Maar volgens mij rekent Proxmox alle eventuele cache ook mee en vult daarmee het geheugen altijd wel hard vs wat het OS zelf werkelijk doet (en laat zien via Glances). Dus volgens mij zolang Glances geen enorm vol geheugen laat zien is er volgens mij niets aan de hand.

[ Voor 14% gewijzigd door Septillion op 12-01-2026 14:08 ]

[Koepert]

TheFes schreef op maandag 12 januari 2026 @ 14:01:
[...]

Dat er een verschil zit in GiB en GB
8 GB (gigabyte) is 8 * 10⁹ bytes = 8.000.000.000 bytes
8 GiB (gibibyte) is * * 2³⁰ bytes = 8.589.934.592 bytes

Dus als bij de ene waarde je unit GB is, en bij de andere GiB, dan kun je die niet met elkaar vergelijken.
8,00 gigabyte komt overeen met 7,45 gibibyte.

Oh ja zo

Host is 7.68 GiB
VM is 8.00 GiB

Beide dus Gibibyte. Aldus de interface althans.

[Koepert]

Septillion schreef op maandag 12 januari 2026 @ 14:07:
@Koepert Meet RAM aan de VM geven dan de host heeft is natuurlijk wel vreemd. Maar neem aan de Proxmox dat dan wel in de gaten houdt.

Maar volgens mij rekent Proxmox alle eventuele cache ook mee en vult daarmee het geheugen altijd wel hard vs wat het OS zelf werkelijk doet (en laat zien via Glances).

Ja misschien voor de zekerheid aanpassen, maar komt wellicht ook omdat je het weer toekent in MiB (Dus 8192) ipv GiB, dus die omrekenfactor speelt ook mee. HA werkt verder prima overigens.

Mbt dat meerekenen, dat zou kunnen. Op zich is t ook prima, maar voor mn gevoel trok HA opeens "meer RAM" want die VMsetting staat al weetikhoelang zo. Dus t zal wel goed blijven gaan. Maar wellicht dat updaten van de host (naar Proxmox v9) er wat mee van doen heeft.

[Gizz]

Koepert schreef op maandag 12 januari 2026 @ 13:47:
Glances in Home Assistant is inderdaad een stuk milder:

code:

MEM 23%
total:  7.75G
used:   1.8G
free:   5.97G
active: 3.14G
inactive:   3.38G
buffers:    210M
cached: 4.61G

Dat is allemaal redelijk vergelijkbaar met mijn HA-installatie in Proxmox met 8GB voor de HA VM. En ook bij mij zegt Proxmox dat de VM heel veel van z'n geheugen gebruikt. Dat is normaal en Proxmox pakt het vrije ram terug van de HA VM als het ergens anders wél nodig is, dat heet ballooning. Dat betreft dan het stuk dat nu door HAOS als cached wordt ingezet. Linux houdt niet van geheugen onbenut laten als het ook als cache gebruikt kan worden.

Proxmox laat in het overzicht bij de VM alleen zien hoeveel ram door HAOS 'aangeraakt' (touched) is. Niet hoeveel daarvan echt noodzakelijk is en welk deel als cache wordt ingezet.

edit: zie dat ik nu hetzelfde zeg als @Septillion

[ Voor 27% gewijzigd door Gizz op 12-01-2026 14:20 ]

[Septillion]

@Koepert Ik weet niet anders dan dat Proxmox 90%+ aangeeft na een tijdje. Na een start is het lager maar loopt dus gewoon op omdat de VM dus meer geheugen "aanraakt".

[frankwopereis]

doerakje schreef op vrijdag 9 januari 2026 @ 14:38:
[...]

Een mogelijke oplossing met een andere invalshoek:
Maak een automation die start zodra er wordt gebeld. Laat die automation het belsignaal geven na 9 seconden. Evt nog verder uitwerken met voorwaarden, zoals geen actie als de deur na het 1e belsignaal is opengegaan o.i.d.

Dat vind ik wel een mooie oplossing, zo kan je eigenlijk alle kanten op. Je kunt ook naast een "geluid" een licht laten knipperen of iets anders doen zodat de deurbel op valt. Foto pop-up op je TV bv.

skank schreef op zaterdag 10 januari 2026 @ 08:57:
[...]
Kijk eens naar reolink
Zelf ook aantal deurbellen gehad, en enorm tevreden van reolink

Zijn best prima deurbellen, ken mensen die ze hebben inderdaad. Ik ben echter ooit begonnen aan Unify, en dan ben je toch een beetje verslaafd

[JeroenH]

Ik heb een klein probleem waar ik zelfs met Mistral AI (wat me doorgaans erg goed helpt) niet uikom.

Ik heb een Renault Twizy, en daarin een kastje die via MQTT allerlei meetwaarden naar mijn HA stuurt. Eén van die meetwaarden is de batterij-temperatuur. Werkt helemaal goed, behalve dat de ecu van het voertuig deze waarde alleen meestuurt als hij aan is ("gestart"). Als hij uit is of aan het laden, is het betreffende veld in de json leeg. Dat is jammer, maar het is niet anders. De MQTT sensor in HA echter, houdt dan de laatst geleverde waarde, maar die heeft dan niet meer te maken met de realiteit, tot het voertuig gestart wordt en weer meetwaarden begint te leveren. Ik wil de sensor op iets van unavailable of unknown hebben als er voor een x tijd (zeg 15 minuten) geen waarde is gearriveerd.

De sensor ziet er als volgt uit in de configuration.yaml:

YAML:

mqtt:
  sensor:
    - name: "Twizy battery temperature"
      state_topic: "ToM/TopicJson"
      unit_of_measurement: "°C"
      value_template: "{{ value_json['B-T'] }}"

En dit werkt dus op zich goed.

De AI had het idee voor een extra sensor die na 15 minuten op "unknown" gaat:

YAML:

sensor:
  - name: "Twizy battery temperature (Filtered)"
    unit_of_measurement: "°C"
    state: >
      {% if (as_timestamp(now()) - as_timestamp(states.sensor.twizy_battery_temperature_2.last_updated)) < 900 %}
        {{ states.sensor.twizy_battery_temperature_2.state }}
      {% else %}
        unknown
      {% endif %}

Deze sensor volgt de waarde van de oorspronkelijke sensor als er een waarde is, maar gaat niet na 15 minuten op " unknown".

Nog een automation opgezet die deze extra sensor elke minuut update of activeert of zoiets:

YAML:

alias: Update Twizy Battery Temperature Filtered
description: ""
triggers:
  - minutes: /1
    trigger: time_pattern
actions:
  - target:
      entity_id: sensor.twizy_battery_temperature_filtered
    action: homeassistant.update_entity

Maar dat heeft geen effect. Ik zie die automation wel elke minuut triggeren.

Nog wat andere ideeën verkend met helpers en automations maar dit begint qua complexiteit uit te hand te lopen. Dit zou voor mijn gevoel toch niet zo moeilijk moeten zijn?

Heeft iemand een idee hoe dat het beste aan te pakken is?

[TheFes]

JeroenH schreef op maandag 12 januari 2026 @ 16:05:
Ik heb een klein probleem waar ik zelfs met Mistral AI (wat me doorgaans erg goed helpt) niet uikom.

Ik heb een Renault Twizy, en daarin een kastje die via MQTT allerlei meetwaarden naar mijn HA stuurt. Eén van die meetwaarden is de batterij-temperatuur. Werkt helemaal goed, behalve dat de ecu van het voertuig deze waarde alleen meestuurt als hij aan is ("gestart"). Als hij uit is of aan het laden, is het betreffende veld in de json leeg. Dat is jammer, maar het is niet anders. De MQTT sensor in HA echter, houdt dan de laatst geleverde waarde, maar die heeft dan niet meer te maken met de realiteit, tot het voertuig gestart wordt en weer meetwaarden begint te leveren. Ik wil de sensor op iets van unavailable of unknown hebben als er voor een x tijd (zeg 15 minuten) geen waarde is gearriveerd.

De sensor ziet er als volgt uit in de configuration.yaml:

YAML:

mqtt:
  sensor:
    - name: "Twizy battery temperature"
      state_topic: "ToM/TopicJson"
      unit_of_measurement: "°C"
      value_template: "{{ value_json['B-T'] }}"

En dit werkt dus op zich goed.

De AI had het idee voor een extra sensor die na 15 minuten op "unknown" gaat:

YAML:

sensor:
  - name: "Twizy battery temperature (Filtered)"
    unit_of_measurement: "°C"
    state: >
      {% if (as_timestamp(now()) - as_timestamp(states.sensor.twizy_battery_temperature_2.last_updated)) < 900 %}
        {{ states.sensor.twizy_battery_temperature_2.state }}
      {% else %}
        unknown
      {% endif %}

Deze sensor volgt de waarde van de oorspronkelijke sensor als er een waarde is, maar gaat niet na 15 minuten op " unknown".

Nog een automation opgezet die deze extra sensor elke minuut update of activeert of zoiets:

YAML:

alias: Update Twizy Battery Temperature Filtered
description: ""
triggers:
  - minutes: /1
    trigger: time_pattern
actions:
  - target:
      entity_id: sensor.twizy_battery_temperature_filtered
    action: homeassistant.update_entity

Maar dat heeft geen effect. Ik zie die automation wel elke minuut triggeren.

Nog wat andere ideeën verkend met helpers en automations maar dit begint qua complexiteit uit te hand te lopen. Dit zou voor mijn gevoel toch niet zo moeilijk moeten zijn?

Heeft iemand een idee hoe dat het beste aan te pakken is?

Je kunt beter een trigger based template sensor aanmaken op basis van die MQTT sensor, die zijn state allen aanpast als de MQTT sensor ook een valide state heeft

YAML:

triggers:
  - trigger: state
    entity_id: sensor.twizy_battery_temperature_2
    to: ~
conditions:
  - condition: template
    value_template: "{{ trigger.to_state.state | is_number }}"
sensor:
  - unique_id: 1b4da1b3-bd0f-4cf2-b86d-70991ff217ef
    name: "Twizy battery temperature (Filtered)"
    state: "{{ trigger.to_state.state }}"
    unit_of_measurement: "°C"
    device_class: temperature
    state_class: measurement

Oh wacht, ik begrijp nu het probleem pas..

Je template rendert vanzelf al elke minuut opnieuw omdat je now() gebruikt.. Je automation doet verder niets.
Verder mag je geen string als state opgeven als je ook een unit of measurement opgeeft, none mag wel.

YAML:

sensor:
  - name: "Twizy battery temperature (Filtered)"
    unit_of_measurement: "°C"
    state: >
      {% set sensor  = 'sensor.twizy_battery_temperature_2' %}
      {% set current = states(sensor) %}
      {{ current if current | is_number and now() - states[sensor].last_updated < timedelta(minutes=15) else none }}

[ Voor 9% gewijzigd door TheFes op 12-01-2026 16:23 ]

[Hippe Lip]

NeoFoX schreef op maandag 12 januari 2026 @ 10:44:
Iemand hier nog een idee voor een nieuwe / andere oplossing voor:
- Temp sensor
- Humidity sensor
- Met readable-screen
- Stroom / USB powered

Ik heb nu een jaar 2x een Sonoff met screen, maar die batterijen gaat leeg waar je bij staat en daar wil ik dus vanaf.

Idee was dus om deze te vervangen voor die van IKEA: VINDSTYRKA Maar deze is én niet meer beschikbaar én levert geen decimalen achter de komma, wat ik wel graag wil voor wat meer details.
- De nieuwe van de IKEA: ALPSTUGA moet je klikken om de verschillende waardes te zien en dat wil ik niet

Vraag:
- Welke oplossing hebben jullie hiervoor staan / in gebruik?

Mag via WiFi of Zigbee, heb beiden...

@NeoFoX Dit behoeft geen frequente update? 2x per uur is voldoende?

Kijk dan eens naar het Electronic Shelf Labels Topic.
Ik gebruik die dingen voor buitenthermometers en voor de status van mijn auto (EV).
Is er in allerlei formaten, werkt draadloos en op batterijen en als je niet al te vaak update, dan gaan die wel een jaar mee.

[JeroenH]

TheFes schreef op maandag 12 januari 2026 @ 16:14:
Verder mag je geen string als state opgeven als je ook een unit of measurement opgeeft, none mag wel.

YAML:

sensor:
  - name: "Twizy battery temperature (Filtered)"
    unit_of_measurement: "°C"
    state: >
      {% set sensor  = 'sensor.twizy_battery_temperature_2' %}
      {% set current = states(sensor) %}
      {{ current if current | is_number and now() - states[sensor].last_updated < timedelta(minutes=15) else none }}

OK, ik ga het proberen, dank!

-edit-

Uhm, het werkt niet...

Ik heb de Twizy net even aangezet, en de oorspronkelijk sensor update dan. Maar de filtered sensor verandert niet mee. Dus hij krijgt sowieso de actuele meetwaarde niet mee. Hij gaat ook niet naar "none", want hij wordt dus niet geüpdate (staat nu op 2 uur geleden...).

[ Voor 22% gewijzigd door JeroenH op 12-01-2026 17:10 ]

[HuismAndré]

JeroenH schreef op maandag 12 januari 2026 @ 16:40:
[...]


OK, ik ga het proberen, dank!

-edit-

Uhm, het werkt niet...

Ik heb de Twizy net even aangezet, en de oorspronkelijk sensor update dan. Maar de filtered sensor verandert niet mee. Dus hij krijgt sowieso de actuele meetwaarde niet mee. Hij gaat ook niet naar "none", want hij wordt dus niet geüpdate (staat nu op 2 uur geleden...).

Dit soort trucjes werken vaak niet omdat de template niet update als de sensor niet update. Een oplossing is dan om een trigger te maken die bijvoorbeeld 20 minuten na een wijziging van de sensor triggert ALS het een sensor is die normaliter elke 15 minuten bijwerkt. Die trigger vuurt dan alleen maar als de onderliggende sensor niet meer bijgewerkt wordt. Je maakt dus een template dat én op de sensor zelf triggert (zodat de output bijgewerkt wordt zodra de sensor bijwerkt) én triggert als de sensor 20 minuten geleden gewijzigd is (waardoor je dus weet dat de sensor "stale" is en je zelf via de template een andere waarde door gaat geven). Als het wellicht wat abstract voor je is, hier een voorbeeld van een template die 5:20 na de laatste wijziging van een sensor de extra trigger vuurt (van een sensor die dus normaliter elke 5 minuten bijwerkt). Deze plaats je dus in templates.yaml:

YAML:

- trigger:
  - platform: state
    entity_id: sensor.gas_consumed
  - platform: state
    entity_id: sensor.gas_consumed
    for: "00:05:20"
  sensor:
  - name: "Gas/Minuut"
    unique_id: gas_per_minuut
    unit_of_measurement: "L/min"
    state_class: measurement
    device_class: volume_flow_rate
    availability: "{{ has_value('sensor.gas_consumed') }}"
    state: >-
      {% set previous = trigger.from_state.state | float(0) %}
      {% set current = trigger.to_state.state | float(0) %}
      {% set verbruik = iif(trigger.for, 0, (current - previous) * 200) %}
      {{ (verbruik | round(2)) if 50 > verbruik > 0 else 0 }}

[ Voor 28% gewijzigd door HuismAndré op 12-01-2026 17:21 ]

[JeroenH]

HuismAndré schreef op maandag 12 januari 2026 @ 17:18:
Een oplossing is...

Dank voor de uitgebreide uitleg, maar ik ben bang dat dit met mijn kennisniveau van HA en yaml te hoog gegrepen is.

Ik denk dat ik het maar opgeef en gewoon zelf moet opletten of de waarde niet stale is als ik er op een dashboard naar kijk.

[HuismAndré]

JeroenH schreef op maandag 12 januari 2026 @ 17:21:
[...]


Dank voor de uitgebreide uitleg, maar ik ben bang dat dit met mijn kennisniveau van HA en yaml te hoog gegrepen is.

Ik denk dat ik het maar opgeef en gewoon zelf moet opletten of de waarde niet stale is als ik er op een dashboard naar kijk.

Wat is de naam van de originele sensor?

[JeroenH]

HuismAndré schreef op maandag 12 januari 2026 @ 17:21:
Wat is de naam van de originele sensor?

sensor.twizy_battery_temperature_2

[HuismAndré]

JeroenH schreef op maandag 12 januari 2026 @ 17:23:
[...]


sensor.twizy_battery_temperature_2

Probeer deze eens:

YAML:

- trigger:
  - platform: state
    entity_id: sensor.twizy_battery_temperature_2
    id: update
  - platform: state
    entity_id: sensor.twizy_battery_temperature_2
    for: "00:20:00"
    id: stale
  sensor:
  - name: "Twizy Battery Temp_NoStale"
    unique_id: twizy_battery_temp
    availability: "{{ has_value('sensor.twizy_battery_temperature_2') }}"
    state: >-
      {% if trigger.id == 'stale' %}
        none
      {% else %}
        {{ trigger.to_state.state }}
      {% endif %}

Komt in templates.yaml

[JeroenH]

HuismAndré schreef op maandag 12 januari 2026 @ 17:33:
Komt in templates.yaml

Betekent dat, in de configuration.yaml onder het kopje "template:", of moet ik daarvoor een nieuw bestand aanmaken genaamd "templates.yaml"?

[HuismAndré]

JeroenH schreef op maandag 12 januari 2026 @ 18:09:
[...]


Betekent dat, in de configuration.yaml onder het kopje "template:", of moet ik daarvoor een nieuw bestand aanmaken genaamd "templates.yaml"?

Als je nog geen templates.yaml hebt dan kun je het ook gewoon in configuration.yaml zetten MAAR dat wordt de opmaak wel een beetje anders:

YAML:

template:
  - trigger:
    - platform: state
      entity_id: sensor.twizy_battery_temperature_2
      id: update
    - platform: state
      entity_id: sensor.twizy_battery_temperature_2
      for: "00:20:00"
      id: stale
    sensor:
    - name: "Twizy Battery Temp_NoStale"
      unique_id: twizy_battery_temp
      availability: "{{ has_value('sensor.twizy_battery_temperature_2') }}"
      state: >-
        {% if trigger.id == 'stale' %}
          none
        {% else %}
          {{ trigger.to_state.state }}
        {% endif %}

[TheFes]

HuismAndré schreef op maandag 12 januari 2026 @ 17:18:
[...]

Dit soort trucjes werken vaak niet omdat de template niet update als de sensor niet update. Een oplossing is dan om een trigger te maken die bijvoorbeeld 20 minuten na een wijziging van de sensor triggert ALS het een sensor is die normaliter elke 15 minuten bijwerkt. Die trigger vuurt dan alleen maar als de onderliggende sensor niet meer bijgewerkt wordt. Je maakt dus een template dat én op de sensor zelf triggert (zodat de output bijgewerkt wordt zodra de sensor bijwerkt) én triggert als de sensor 20 minuten geleden gewijzigd is (waardoor je dus weet dat de sensor "stale" is en je zelf via de template een andere waarde door gaat geven). Als het wellicht wat abstract voor je is, hier een voorbeeld van een template die 5:20 na de laatste wijziging van een sensor de extra trigger vuurt (van een sensor die dus normaliter elke 5 minuten bijwerkt). Deze plaats je dus in templates.yaml:

YAML:

- trigger:
  - platform: state
    entity_id: sensor.gas_consumed
  - platform: state
    entity_id: sensor.gas_consumed
    for: "00:05:20"
  sensor:
  - name: "Gas/Minuut"
    unique_id: gas_per_minuut
    unit_of_measurement: "L/min"
    state_class: measurement
    device_class: volume_flow_rate
    availability: "{{ has_value('sensor.gas_consumed') }}"
    state: >-
      {% set previous = trigger.from_state.state | float(0) %}
      {% set current = trigger.to_state.state | float(0) %}
      {% set verbruik = iif(trigger.for, 0, (current - previous) * 200) %}
      {{ (verbruik | round(2)) if 50 > verbruik > 0 else 0 }}

De sensor update, dat geeft hij juist aan, dus zou de template sensor ook moeten updaten.

@JeroenH waar heb jij deze code nu staan, want ik vermoed dat er daar iets mis gaat? Zet je dit in een template helper config in de GUI?

[JeroenH]

TheFes schreef op maandag 12 januari 2026 @ 19:00:
@JeroenH waar heb jij deze code nu staan, want ik vermoed dat er daar iets mis gaat? Zet je dit in een template helper config in de GUI?

Nee, zowel de oorspronkelijke sensor (als MQTT sensor) en deze afgeleide sensor (als template sensor) staan in de configuration.yaml.

[TheFes]

JeroenH schreef op maandag 12 januari 2026 @ 20:04:
[...]


Nee, zowel de oorspronkelijke sensor (als MQTT sensor) en deze afgeleide sensor (als template sensor) staan in de configuration.yaml.

Staat het onder de template key dan? Kun je het volledige blok waaronder de template sensor config staat eens plaatsten?

[JeroenH]

HuismAndré schreef op maandag 12 januari 2026 @ 18:22:
[...]

Als je nog geen templates.yaml hebt dan kun je het ook gewoon in configuration.yaml zetten MAAR dat wordt de opmaak wel een beetje anders:

YAML:

template:
  - trigger:
    - platform: state
      entity_id: sensor.twizy_battery_temperature_2
      id: update
    - platform: state
      entity_id: sensor.twizy_battery_temperature_2
      for: "00:20:00"
      id: stale
    sensor:
    - name: "Twizy Battery Temp_NoStale"
      unique_id: twizy_battery_temp
      availability: "{{ has_value('sensor.twizy_battery_temperature_2') }}"
      state: >-
        {% if trigger.id == 'stale' %}
          none
        {% else %}
          {{ trigger.to_state.state }}
        {% endif %}

Dit werkt PERFECT:



Zeer bedankt hiervoor! Ik heb nog een paar sensoren waar hetzelfde mee moet gebeuren, maar dat zal me zelf wel lukken.

[superduper1969]

C.A.F.E. Integratie is net nieuw en een soort Node Red lite.
Ziet er tof uit.
[Project Release] C.A.F.E. – A “Third Way” for automations. Visual flows like Node-RED, but 100% native YAML/Storage. No extra engines.

Youtube mini tutorial.
Github

[ Voor 5% gewijzigd door superduper1969 op 13-01-2026 13:12 ]

[Driek]

Ik heb een sections dashboard gemaakt die ik in het sidebar menu kan benaderen.
Nu is het in de praktijk toch makkelijker om deze als een tab op een ander (main) dashboard te laten zien.
Ik kan alleen niet het dashboard verplaatsen, of de yaml bekijken, waardoor ik hem niet makkelijk kan kopieren naar een tabblad.

Zijn er makkelijke opties dan opnieuw aanmaken?

[Ora et Labora]

Driek schreef op dinsdag 13 januari 2026 @ 14:17:
Ik heb een sections dashboard gemaakt die ik in het sidebar menu kan benaderen.
Nu is het in de praktijk toch makkelijker om deze als een tab op een ander (main) dashboard te laten zien.
Ik kan alleen niet het dashboard verplaatsen, of de yaml bekijken, waardoor ik hem niet makkelijk kan kopieren naar een tabblad.

Zijn er makkelijke opties dan opnieuw aanmaken?

Die kun je wel als YAML bekijken hoor.
In het dashboard, potloodje, 3 puntjes, raw configuration editor.

[SonOfSam]

NeoFoX schreef op maandag 12 januari 2026 @ 10:44:
Iemand hier nog een idee voor een nieuwe / andere oplossing voor:
- Temp sensor
- Humidity sensor
- Met readable-screen
- Stroom / USB powered

Ik heb nu een jaar 2x een Sonoff met screen, maar die batterijen gaat leeg waar je bij staat en daar wil ik dus vanaf.

Idee was dus om deze te vervangen voor die van IKEA: VINDSTYRKA Maar deze is én niet meer beschikbaar én levert geen decimalen achter de komma, wat ik wel graag wil voor wat meer details.
- De nieuwe van de IKEA: ALPSTUGA moet je klikken om de verschillende waardes te zien en dat wil ik niet

Vraag:
- Welke oplossing hebben jullie hiervoor staan / in gebruik?

Mag via WiFi of Zigbee, heb beiden...

Mijn zwager heeft deze hangen, heb ze zelf ook op m'n lijstje gezet, maar nog geen ervaringen mee. Hij is er blij mee. Wel duurder, want ook co2 sensor. Maar dat is voor mij een musthave om m'n ventilatie mee aan te sturen: https://www.switch-bot.co...bot-meter-pro-co2-monitor

[Driek]

Ora et Labora schreef op dinsdag 13 januari 2026 @ 14:24:
[...]

Die kun je wel als YAML bekijken hoor.
In het dashboard, potloodje, 3 puntjes, raw configuration editor.

ja, maar dat geeft een code die ik niet zomaar in kan passen in het andere dashboard.
Het lijkt op een te "hoog" niveau.

Edit:
Toch gevonden, zit in de 3 puntjes van de tab verstopt, daar kon ik edit in yaml kiezen, en vervolgens copy pasten.

[ Voor 15% gewijzigd door Driek op 13-01-2026 14:38 ]

[Ora et Labora]

Driek schreef op dinsdag 13 januari 2026 @ 14:36:
[...]

ja, maar dat geeft een code die ik niet zomaar in kan passen in het andere dashboard.
Het lijkt op een te "hoog" niveau.

Edit:
Toch gevonden, zit in de 3 puntjes van de tab verstopt, daar kon ik edit in yaml kiezen, en vervolgens copy pasten.

Je kunt op je main een tabblad maken, bijvoorbeeld X.
Dan open je een ander dashboard aan de zijkant, de RAW editor, kopieren.
Daar zoek je op iets als "title X" in de raw editor van je main.
En daar plak je het gedeelte in van het andere dashboard. Het kan zijn dat je wat moet spelen met spaties/tabs en iets moet verwijderen wat ervoor staat maar dit zou gewoon moeten kunnen, heb ik ook wel eens gedaan.

[NeoFoX]

SonOfSam schreef op dinsdag 13 januari 2026 @ 14:27:
[...]


Mijn zwager heeft deze hangen, heb ze zelf ook op m'n lijstje gezet, maar nog geen ervaringen mee. Hij is er blij mee. Wel duurder, want ook co2 sensor. Maar dat is voor mij een musthave om m'n ventilatie mee aan te sturen: https://www.switch-bot.co...bot-meter-pro-co2-monitor

Lijkt een supergoed alternatief, is wel BLE.. daar ben ik dan weer wat minder fan van. Maar ik neem het mee in overweging.

[MazzHead]

NeoFoX schreef op dinsdag 13 januari 2026 @ 15:38:
[...]


Lijkt een supergoed alternatief, is wel BLE.. daar ben ik dan weer wat minder fan van. Maar ik neem het mee in overweging.

Als batterij/BLE dan toch in overweging wordt genomen: Xiaomi LYWSD03MMC, €4-5/stuk en als je pvvx firmware flashed en advertising frequentie aanpast kan de CR2032 2 jaar mee. Kun je ook naar Zigbee flashen als je perse wilt.

Als je liever geen BT in HA gebruikt kun je de ESPHome BLE tracker route nemen, BLE via Wifi

[PnD]

Heb een Nspanel pro 120 in gebruik en er een Dashboard voor gemaakt. Krijg alleen die knoppen van de tabbladen niet groter. Kan wel tekst doen dan wordt het breder, maar zou het liever ook wat hoger hebben. Iemand een idee hoe?

[_ferry_]

Okee, ik ben vast niet de eerste die dit wil, maar wat ik tot nu toe tegen kwam was vooral de agenda functie. Maar ik zoek eigenlijk meer een planner binnen home assistant
Dus snel een datum/tijd selecteren, waarop ik een knop omzet of actie oproep.
Ik heb natuurlijk heel veel automations, maar die zijn vooral makkelijk als iets elke dag moet en er niet vaak aanpassingen nodig zijn.

Iets specifieker: ik zie dat morgen de stroom duur is over een langere periode. Dan wil ik eigenlijk gewoon voor morgen om 15:00 de batterij op NOM zetten, en om een uur of 20:00 weer uit.
De standaard automation die ik gebruik kijkt namelijk naar het duurste uur van die dag, maar in dit geval wil ik 5 uur lang NOM draaien.
Wat ik tegenkwam was dat je dan in de agenda je agenda item een specifieke naam moet geven, en dan je automation weer de agenda laten checken. Maar IMHO is dat een beetje de omgekeerde wereld, ik wil een agenda die een automation start. Veel makkelijker.

[Impossibl3]

@_ferry_ ik heb een aparte agenda phev laden. Daar zet ik de uren in en zodra het moment actief wordt gaat mijn laadpaal laden. Volgens mij wil je dit. Hij kijkt dus niet naar een specifieke naam maar naar een event in een specifieke agenda.

YAML:

alias: Easee laadlimiet - Cheapest hours start
description: Zet dynamisch laden aan
triggers:
  - event: start
    offset: "0:0:0"
    entity_id: calendar.stroomprijs_phev
    trigger: calendar
conditions: []
actions:
  - action: input_boolean.turn_on
    metadata: {}
    data: {}
    target:
      entity_id: input_boolean.laadpaal_dynamische_prijzen_laden
mode: single

[_ferry_]

Impossibl3 schreef op dinsdag 13 januari 2026 @ 18:21:
@_ferry_ ik heb een aparte agenda phev laden. Daar zet ik de uren in en zodra het moment actief wordt gaat mijn laadpaal laden. Volgens mij wil je dit. Hij kijkt dus niet naar een specifieke naam maar naar een event in een specifieke agenda.

YAML:

alias: Easee laadlimiet - Cheapest hours start
description: Zet dynamisch laden aan
triggers:
  - event: start
    offset: "0:0:0"
    entity_id: calendar.stroomprijs_phev
    trigger: calendar
conditions: []
actions:
  - action: input_boolean.turn_on
    metadata: {}
    data: {}
    target:
      entity_id: input_boolean.laadpaal_dynamische_prijzen_laden
mode: single

Ah das ook een optie, en logisch eigenlijk. Niet naar de benaming kijken van het event maar gewoon de agenda zelf

[Brynnie]

YAML:

                    type: 'custom:mushroom-template-card',
                    entity: eid,
                    primary: name,
                    secondary: badgetekst,
                    layout: 'horizontal',
                    fill_container: true,
                    tap_action: { action: 'toggle' },
                    icon: iconTpl,
                    icon_color: iconColorTpl,
                    card_mod: { }

Met welke card_mod kan ik de secondary tekst rood maken? Ik vind het juiste element niet.

Cascading Stylesheet:

                    ha-card * {
                      color: var(--disabled-color);
                      opacity: 0.8;                  
                    }

maakt de hele tekst in die stijl. Maar ik wil specifiek de secondary tekst stijlen.

Online ( https://community.home-as...ng-config-guide/600472/13 ) vind ik:

YAML:

card_mod:
  style:
    mushroom-state-info$: |
      .container {
        --card-primary-color: blue;
        --card-secondary-color: orange;
      }

maar dat werkt niet blijkbaar? Of ik implementeer het verkeerd in mijn code?

YAML:

                    const tileStyle = commonStyle + (isUnavail ? `
                      mushroom-state-info$ {
                        .container {
                          --card-primary-color: blue;
                          --card-secondary-color: orange;
                        }
                      }
                    ` : ``);

                 return {
                    type: 'custom:mushroom-template-card',
                    entity: eid,
                    multiline_secondary: false,
                    primary: name,
                    secondary: badgetekst,
                    layout: 'horizontal',
                    fill_container: true,
                    tap_action: { action: 'toggle' },
                    icon: iconTpl,
                    icon_color: iconColorTpl,
                    card_mod: {
                      style: tileStyle
                    }
                  };

Na wat experimenteren: Dit werkt wel

YAML:

                    const tileStyle = commonStyle + (isUnavail ? `
                      ha-card .content > *:last-child > *:last-child {
                        color: var(--error-color) !important;
                      }
                    ` : ``);

Maar ik weet niet of het de meest elegante oplossing is.

[ Voor 53% gewijzigd door Brynnie op 14-01-2026 08:27 ]

[peterpijpelink]

PnD schreef op dinsdag 13 januari 2026 @ 17:22:
Heb een Nspanel pro 120 in gebruik en er een Dashboard voor gemaakt.

is dit met de standaard Sonof code of een alternatieve firmware?

[PnD]

peterpijpelink schreef op woensdag 14 januari 2026 @ 08:37:
[...]


is dit met de standaard Sonof code of een alternatieve firmware?

Ik heb de standard gebruikt, de weergave is overigens hetzelfde op mijn iphone app en in Edge.

[ Voor 51% gewijzigd door PnD op 14-01-2026 09:19 ]

[Toppe]

Iemand deze al gezien?

C.A.F.E.


Slaat dus direct alle automatiseringen op als YAML file

[_ferry_]

@Impossibl3
Ik wilde de kalender toevoegen aan mijn Automation, toen zag ik dat er ook een datum/tijd helper is, die is iets sneller in te stellen vanuit een dashboard;


Dus daar ga ik wat moois proberen mee te maken.

De kalender kan natuurlijk wel weer heel handig zijn voor zaken die je elke x-dag wil herhalen bijvoorbeeld.

[dixet]

Toppe schreef op woensdag 14 januari 2026 @ 09:43:
Iemand deze al gezien?

C.A.F.E.
[Afbeelding]

Slaat dus direct alle automatiseringen op als YAML file

Ja dus superduper1969 in "Home Assistant: Open source Python3 home automation - deel 5"

Ziet er veelbelovend uit, als is met de laatste releases van HA het maken van automations iedere keer makkelijker geworden. Projecten met effectief 1 contributor kijk ik liever eerst even aan voordat ik me er aan commit. Maar ik ben benieuwd naar de ervaringen van anderen

[Septillion]

Mij 2-cents voor CAFE:

Leuk dat er ook een native oplossing is voor HA. En dat je dus heen en weer zou kunnen.

Maar voor mij nemen ze een van de grootste downside van NR mee en dat is dat volledige free-form aspect. Ik niets met de brei van lijntje van NR. Persoonlijk zou ik liever een vergelijkbare structuur zien zoals HA al gebruikt in de traces. Dus gewoon automatisch een strak georganiseerd flowdiagram.

[Hippe Lip]

Septillion schreef op woensdag 14 januari 2026 @ 16:52:
Persoonlijk zou ik liever een vergelijkbare structuur zien zoals HA al gebruikt in de traces. Dus gewoon automatisch een strak georganiseerd flowdiagram.

@Septillion Ik ben benieuwd wanneer je dat gaat bouwen, want dan zou ik dat graag gebruiken.

[Schway]

dixet schreef op woensdag 14 januari 2026 @ 11:31:
[...]

Ja dus superduper1969 in "Home Assistant: Open source Python3 home automation - deel 5"

Ziet er veelbelovend uit, als is met de laatste releases van HA het maken van automations iedere keer makkelijker geworden. Projecten met effectief 1 contributor kijk ik liever eerst even aan voordat ik me er aan commit. Maar ik ben benieuwd naar de ervaringen van anderen

Stel het loopt mis of stopt, of wint de loterij, dan zou je altijd nog gewoon de native yaml hebben.

[Toppe]

Septillion schreef op woensdag 14 januari 2026 @ 16:52:
Mij 2-cents voor CAFE:

Leuk dat er ook een native oplossing is voor HA. En dat je dus heen en weer zou kunnen.

Maar voor mij nemen ze een van de grootste downside van NR mee en dat is dat volledige free-form aspect. Ik niets met de brei van lijntje van NR. Persoonlijk zou ik liever een vergelijkbare structuur zien zoals HA al gebruikt in de traces. Dus gewoon automatisch een strak georganiseerd flowdiagram.

Grafisch programmeren heeft toch ook z’n voordelen. De gevorderde gebruiker zal denk ik relatief snel naar YAML gaan?

[Septillion]

@Toppe Absoluut! Doe ook niet voor niets 90% van mijn automations in de UI. Ben alleen geen fan van de free-form spagetti. De nieuwe HA weergeven laat zaken al duidelijker zien. Maar zou voor mij echt gewoon het strakke flowdiagram van de traces mogen zijn. En dat je daar dan gewoon grafisch in zou kunnen slepen en klikken.

Maar goed, dit is wel al een leuk alternatief dat laat zien dat het wel gewoon met de native engine mogelijk is. Dus misschien dat dit een begin kan zijn van gewoon meer weergavevormen van de automation? Nested blokken (huidige UI), free-form, flow diagram en yaml, gewoon naast elkaar als alternatieve weergave van dezelfde automation? Dus ik zie zeker kansen!

@Hippe Lip En kan prima wat code schrijven maar dit gaat me helaas te ver om te proberen te maken

[firecaps30]

RobertMe schreef op dinsdag 30 december 2025 @ 14:58:
[...]

Nja, dit dus. Of stel een harde lijn met "dit moet het zijn" en pas dus integraties aan (vandaar ook de opmerking dat er maar één integratie een PR heeft (wellicht gehad intussen) om wat recht te trekken), of maak het configurabel.

Nu is er niet ens een conclusie over "hoe het moet / opgelost gaat worden" en is het een halfbakken feature zonder perspectief dat het wordt opgelost.

En v.w.b. harde lijn, volgens mij is het nu al scheef? Een accu die ontlaadt moet negatief zijn? Terwijl dat dus stroom is die de woning in gaat. Maar stroom die de woning in gaat uit opwek of vanaf de grid miet dan weer positief zijn. Dus dat is dan ook al scheef. Dan moet je ook gewoon zeggen "alle stroom die de woning in gaat is negatief en alle stroom naar verbruikers of naar de grid (semi verbruiker) is positief" (en dus opwek met overschot is negatieve opwek en positieve teruglevering).
Immers zou het totaal natuurlijk altijd 0 moeten zijn, als je alles optelt (en daarbij negatief dus negatief laat). Dus 1,5kW opwekken, een aantal verbruikers die in totaal 500W verbruiken en 1kW teruglevering zou moeten resulteren in -1500 + 500 + 1000 = 0. (En uiteraard kun / zul je untracked verbruik hebben en dat is dan de afwijking van 0).

En dat allemaal natuurlijk het liefst afdwingen in combinatie met een statistics migratie optie zodat positieve opwek (en grid afname) dus wordt omgezet naar negatief.

Hoe heb je dit uiteindelijk aangepakt? Een extra sensor die de waardes invert?

[RobertMe]

firecaps30 schreef op woensdag 14 januari 2026 @ 20:03:
[...]


Hoe heb je dit uiteindelijk aangepakt? Een extra sensor die de waardes invert?

Ik wacht rustig af

Met het aanmaken van een template sensor heb ik nog geen (echt) historische data. En ik ben ook niet van plan om de data dubbel op te slaan.

[Hippe Lip]

Septillion schreef op woensdag 14 januari 2026 @ 19:56:

@Hippe Lip En kan prima wat code schrijven maar dit gaat me helaas te ver om te proberen te maken

@Septillion
Meer zoiets dan? Zou mooi zijn als dit in HA zou zitten.

[ Voor 6% gewijzigd door Hippe Lip op 15-01-2026 09:38 ]

[denneappel]

Kan iemand mij een klein stapje in de goede richting duwen?

Ik ben aan het uitzoeken waarom mijn instance (HA OS) niet meer opstart. Daarvoor heb ik vannochtend oa safe mode geactiveerd. Nu krijg ik onderstaande terug uit ha core check. Kan iemand mij vertellen waar ik deze config terug kan vinden? Ik heb in mijn /config directory gezocht welke bestanden het laatst zijn geedit maar ik kom er even niet uit.

code:

# ha core check
Processing... Done.

Error: Testing configuration at /config
Fatal error wihle loading config: 'disabled_by'
Failed config
  General Errors:
      - 'disabled_by'
      
Succesful config (partial)

# _

[Get!em]

denneappel schreef op donderdag 15 januari 2026 @ 11:22:
Kan iemand mij een klein stapje in de goede richting duwen?

Ik ben aan het uitzoeken waarom mijn instance (HA OS) niet meer opstart. Daarvoor heb ik vannochtend oa safe mode geactiveerd. Nu krijg ik onderstaande terug uit ha core check. Kan iemand mij vertellen waar ik deze config terug kan vinden? Ik heb in mijn /config directory gezocht welke bestanden het laatst zijn geedit maar ik kom er even niet uit.

code:

# ha core check
Processing... Done.

Error: Testing configuration at /config
Fatal error wihle loading config: 'disabled_by'
Failed config
  General Errors:
      - 'disabled_by'
      
Succesful config (partial)

# _

Leuke typo in de error (wihle = while )

Waarschijnlijk heb je een of meer disabled devices ergens in de diepe config. En zit daar een foutje in. Zoals in een topic op de community stond quote:

The only other solution I’ve found is to manually go into the .config/storage folder and editing one or more of the following files: core.config_entries, core.device_registry, and core.entity_registry.

Start with the core.config_entries file and search for your device, and change the "disabled_by": "config_entry" entries to "disabled_by": null, or "disabled_by": "user". Do the same thing in the device registry and entity registry files.

It goes without saying - do a system backup before you try any of this. Once you’re done, restart HA. Good luck!

Als je uit je hoofd weet welke integratie een disabled device heeft, kun je die integratie ook even disablen in je main config yaml.

[ Voor 4% gewijzigd door Get!em op 15-01-2026 11:54 ]

[Kevin O]

Toppe schreef op vrijdag 5 december 2025 @ 13:16:
Nadat m’n 3d plattegrond er mee stopte terug gegaan naar een simpel dashboard. Vrijwel alle ‘info’ sensoren zijn klikbaar naar uitgebreide informatie of via een pop-up krijg je een ander scherm te zien.

Ik heb er een heleboel badges (17) in verwerkt die alléén zichtbaar worden als ze relevant zijn en alleen de weer badge is altijd zichtbaar (maar die gaat weer weg).

Ik zoek nog inspiratie voor een goede klok/datum badge die lekker simpel is
[Afbeelding]

Voor die ‘ruimtes’ gebruik ik gewoon de kop kaart met bijbehorende entiteiten:
[Afbeelding]

Op de tablet ziet het er dan zo uit;
[Afbeelding]
_{Voor de scherpe kijker: die tekst met datum/tijd is nu vervangen voor een badge}

Lekker rustig en alleen direct relevante informatie zichtbaar en omdat er een hoop klikbaar is kan je wel vrij eenvoudig alle informatie oproepen.

Onder de menu knop (die 3 bolletjes) zit nog een wifi QR code, herstarten, ontwikkelaar tool en instellingen

Mag ik vragen welke camera jij gebruikt die daar te zien is?

[Toppe]

Kevin O schreef op donderdag 15 januari 2026 @ 14:27:
[...]


Mag ik vragen welke camera jij gebruikt die daar te zien is?

DS-2CD2387G3 Hikvision

[noo]

Is het mogelijk om de 'name' van een entity in een entities card te vullen vanuit een sensor? Ik wil de forecasts van Solcast voor de komende zeven dagen laten zien met als 'name' de naam van de dag, dus vandaag (virijdag) zouden de entity names 'Today', 'Tomorrow', 'Saturday', 'Sunday' etc zijn, en morgen 'Today', 'Tomorrow', 'Sunday', 'Monday' etc. Ik heb template sensors voor de namen van de dagen zoals bv 'sensor.today_plus2days' voor vandaag + 2 dagen (waarde nu 'Saturday') etc. Hoe kan ik de waarde van die sensors gebruiken als 'name' in de entities card? Kan dat überhaupt of heb ik daar een andere card voor nodig?

YAML:

type: entities
entities:
  - entity: sensor.solcast_pv_forecast_forecast_today
    name: Today
  - entity: sensor.solcast_pv_forecast_forecast_tomorrow
    name: Tomorrow
  - entity: sensor.solcast_pv_forecast_forecast_day_3
    name: << op een of andere manier de waarde van sensor.today_plus2days >>
  - entity: sensor.solcast_pv_forecast_forecast_day_4
  - entity: sensor.solcast_pv_forecast_forecast_day_5
  - entity: sensor.solcast_pv_forecast_forecast_day_6
  - entity: sensor.solcast_pv_forecast_forecast_day_7
title: Solcast Forecasts

[verjager]

noo schreef op donderdag 15 januari 2026 @ 19:21:
Is het mogelijk om de 'name' van een entity in een entities card te vullen vanuit een sensor? Ik wil de forecasts van Solcast voor de komende zeven dagen laten zien met als 'name' de naam van de dag, dus vandaag (virijdag) zouden de entity names 'Today', 'Tomorrow', 'Saturday', 'Sunday' etc zijn, en morgen 'Today', 'Tomorrow', 'Sunday', 'Monday' etc. Ik heb template sensors voor de namen van de dagen zoals bv 'sensor.today_plus2days' voor vandaag + 2 dagen (waarde nu 'Saturday') etc. Hoe kan ik de waarde van die sensors gebruiken als 'name' in de entities card? Kan dat überhaupt of heb ik daar een andere card voor nodig?

YAML:

type: entities
entities:
  - entity: sensor.solcast_pv_forecast_forecast_today
    name: Today
  - entity: sensor.solcast_pv_forecast_forecast_tomorrow
    name: Tomorrow
  - entity: sensor.solcast_pv_forecast_forecast_day_3
    name: << op een of andere manier de waarde van sensor.today_plus2days >>
  - entity: sensor.solcast_pv_forecast_forecast_day_4
  - entity: sensor.solcast_pv_forecast_forecast_day_5
  - entity: sensor.solcast_pv_forecast_forecast_day_6
  - entity: sensor.solcast_pv_forecast_forecast_day_7
title: Solcast Forecasts

Dat lukt niet met een gewone entity-row, want daarin kun je geen template gebruiken.

Hiervoor kun je template-entity-row installeren.

En dan met een template de state van de juiste sensor ophalen, als je je huidige sensoren wilt gebruiken. Alternatief zou je kunnen gebruik majen van Easy Time en dan van weekday() m.b.v. custom_templates.

[JPtjeeNL]

Hoi mede-Tweakers! Ik heb recent een soort zoekmachine gebouwd om Home Assistant-automations in de community te kunnen vinden: https://hadiscover.com/

Het idee is dat je hiermee:
• Nieuwe integraties kan vinden om in je setup uit te proberen
• Zien hoe anderen vergelijkbare automatiseringsproblemen hebben opgelost
• Inspiratie opdoen voor je eigen automatiseringen

Ieder uur doorzoekt ‘ie publieke GitHub repositories met de ‘hadiscover’ topic/tag. Dus mocht je zelf je repo toe willen voegen, zou het top zijn als je het topic toevoegt aan je repo.

Feedback is welkom!

[noo]

verjager schreef op donderdag 15 januari 2026 @ 19:57:
[...]

Dat lukt niet met een gewone entity-row, want daarin kun je geen template gebruiken.

Hiervoor kun je template-entity-row installeren.

En dan met een template de state van de juiste sensor ophalen, als je je huidige sensoren wilt gebruiken. Alternatief zou je kunnen gebruik majen van Easy Time en dan van weekday() m.b.v. custom_templates.

Bedankt voor de tip!

Voor hen die dit wellicht ook willen:

YAML:

type: entities
entities:
  - entity: sensor.solcast_pv_forecast_forecast_today
    name: Today
  - entity: sensor.solcast_pv_forecast_forecast_tomorrow
    name: Tomorrow
  - type: custom:template-entity-row
    name: "{{ state_attr('sensor.solcast_pv_forecast_forecast_day_3', 'dayname') }}"
    state: "{{ states('sensor.solcast_pv_forecast_forecast_day_3', with_unit=True) }}"
    icon: mdi:solar-power
  - type: custom:template-entity-row
    name: "{{ state_attr('sensor.solcast_pv_forecast_forecast_day_4', 'dayname') }}"
    state: "{{ states('sensor.solcast_pv_forecast_forecast_day_4', with_unit=True) }}"
    icon: mdi:solar-power
  - type: custom:template-entity-row
    name: "{{ state_attr('sensor.solcast_pv_forecast_forecast_day_5', 'dayname') }}"
    state: "{{ states('sensor.solcast_pv_forecast_forecast_day_5', with_unit=True) }}"
    icon: mdi:solar-power
  - type: custom:template-entity-row
    name: "{{ state_attr('sensor.solcast_pv_forecast_forecast_day_6', 'dayname') }}"
    state: "{{ states('sensor.solcast_pv_forecast_forecast_day_6', with_unit=True) }}"
    icon: mdi:solar-power
  - type: custom:template-entity-row
    name: "{{ state_attr('sensor.solcast_pv_forecast_forecast_day_7', 'dayname') }}"
    state: "{{ states('sensor.solcast_pv_forecast_forecast_day_7', with_unit=True) }}"
    icon: mdi:solar-power
title: Solcast Forecasts

[ Voor 11% gewijzigd door noo op 16-01-2026 08:16 . Reden: de dayname kan nog simpeler zonder aparte template sensor want het is een attribute van de forceast entity. Met 'with_unit=True' in het state template wordt ook de 'kWh' en display_precision overgnomen ]

[verjager]

@noo Je kunt gewoon entity: sensor gebruiken i.p.v. state: "{{ states(sensor) }}". Dan heb je wellicht ook direct de icon al goed staan.

[ Voor 21% gewijzigd door verjager op 15-01-2026 20:44 ]

[noo]

verjager schreef op donderdag 15 januari 2026 @ 20:44:
@noo Je kunt gewoon entity: sensor gebruiken i.p.v. state: "{{ states(sensor) }}". Dan heb je wellicht ook direct de icon al goed staan.

De icon wel, maar de 'kWh' en de round(2) ben ik dan kwijt.
(die 'kWh' zou ik ook nog uit een attribute kunnen halen, maar 'kWh' is minder typen )
Dat laatste kan dus gewoon door with_unit=True toe te voegen aan het state template.

[ Voor 23% gewijzigd door noo op 16-01-2026 08:13 . Reden: Voortschrijdend inzicht ]

[PhilipsFan]

Ik wil graag mijn electriciteitsverbruik beter in kaart brengen (splitsen naar afzonderlijke apparaten). Ik heb dit gedeeltelijk gedaan voor sommige apparaten mbv een zigbee-stekker die het verbruik meet (koelkast, wasmachine). Maar nu wil ik dit ook graag doen voor de verlichting.

Om niet voor alle lampen een zigbee-stekker te hangen, gebruik ik PowerCalc. Dat is een custom component voor Home Assistant, die voor elke Hue lamp een energy-sensor aanmaakt. Hij weet welk type lamp het is en hoeveel die verbruikt, en hij weet via de Hue koppeling ook wanneer een lamp brandt. Tot zover gaat alles nog goed.

Maar ik wil niet elke afzonderlijke lamp in mijn energiedashboard toevoegen als individual device. Ik zou de lampen graag willen groeperen. Hiervoor gebruik ik de 'Group' integration. Die maakt een sensor aan met de samengevoegde waarden van de members van de group. Waar ik uiteraard de door PowerCalc aangemaakte energy-sensoren aan heb toegevoegd. Het type van de groep is 'sum'. Vervolgens heb ik de Group toegevoegd als Individual Device in m'n Energy dashboard.

Gevolg: De somwaarde van alle lampen ever worden weergegeven bij vandaag. Dat is dus iets van 100kWh (die afzonderlijke lichtsensoren bestaan al lang) wat op 1 dag wordt toegevoegd aan een individual device. Dat was dus niet de bedoeling. Hij moet alleen de toename van de waarde op die dag registreren, net zoals bv een kWh-meter.

Heeft iemand enig idee hoe ik dat juist kan configureren? En is het wellicht ook mogelijk om de historische waarden van de energy-sensoren mee te nemen in de historie van de groep?

[Ferra]

PhilipsFan schreef op vrijdag 16 januari 2026 @ 01:21:
Ik wil graag mijn electriciteitsverbruik beter in kaart brengen (splitsen naar afzonderlijke apparaten). Ik heb dit gedeeltelijk gedaan voor sommige apparaten mbv een zigbee-stekker die het verbruik meet (koelkast, wasmachine). Maar nu wil ik dit ook graag doen voor de verlichting.

Om niet voor alle lampen een zigbee-stekker te hangen, gebruik ik PowerCalc. Dat is een custom component voor Home Assistant, die voor elke Hue lamp een energy-sensor aanmaakt. Hij weet welk type lamp het is en hoeveel die verbruikt, en hij weet via de Hue koppeling ook wanneer een lamp brandt. Tot zover gaat alles nog goed.

Maar ik wil niet elke afzonderlijke lamp in mijn energiedashboard toevoegen als individual device. Ik zou de lampen graag willen groeperen. Hiervoor gebruik ik de 'Group' integration. Die maakt een sensor aan met de samengevoegde waarden van de members van de group. Waar ik uiteraard de door PowerCalc aangemaakte energy-sensoren aan heb toegevoegd. Het type van de groep is 'sum'. Vervolgens heb ik de Group toegevoegd als Individual Device in m'n Energy dashboard.

Gevolg: De somwaarde van alle lampen ever worden weergegeven bij vandaag. Dat is dus iets van 100kWh (die afzonderlijke lichtsensoren bestaan al lang) wat op 1 dag wordt toegevoegd aan een individual device. Dat was dus niet de bedoeling. Hij moet alleen de toename van de waarde op die dag registreren, net zoals bv een kWh-meter.

Heeft iemand enig idee hoe ik dat juist kan configureren? En is het wellicht ook mogelijk om de historische waarden van de energy-sensoren mee te nemen in de historie van de groep?

Utility sensoren maken op refresh-stand daily van je sensoren waar het aantal kWH op wordt geregistreerd. En die dan groeperen.

[TheFes]

PhilipsFan schreef op vrijdag 16 januari 2026 @ 01:21:
Ik wil graag mijn electriciteitsverbruik beter in kaart brengen (splitsen naar afzonderlijke apparaten). Ik heb dit gedeeltelijk gedaan voor sommige apparaten mbv een zigbee-stekker die het verbruik meet (koelkast, wasmachine). Maar nu wil ik dit ook graag doen voor de verlichting.

Om niet voor alle lampen een zigbee-stekker te hangen, gebruik ik PowerCalc. Dat is een custom component voor Home Assistant, die voor elke Hue lamp een energy-sensor aanmaakt. Hij weet welk type lamp het is en hoeveel die verbruikt, en hij weet via de Hue koppeling ook wanneer een lamp brandt. Tot zover gaat alles nog goed.

Maar ik wil niet elke afzonderlijke lamp in mijn energiedashboard toevoegen als individual device. Ik zou de lampen graag willen groeperen. Hiervoor gebruik ik de 'Group' integration. Die maakt een sensor aan met de samengevoegde waarden van de members van de group. Waar ik uiteraard de door PowerCalc aangemaakte energy-sensoren aan heb toegevoegd. Het type van de groep is 'sum'. Vervolgens heb ik de Group toegevoegd als Individual Device in m'n Energy dashboard.

Gevolg: De somwaarde van alle lampen ever worden weergegeven bij vandaag. Dat is dus iets van 100kWh (die afzonderlijke lichtsensoren bestaan al lang) wat op 1 dag wordt toegevoegd aan een individual device. Dat was dus niet de bedoeling. Hij moet alleen de toename van de waarde op die dag registreren, net zoals bv een kWh-meter.

Heeft iemand enig idee hoe ik dat juist kan configureren? En is het wellicht ook mogelijk om de historische waarden van de energy-sensoren mee te nemen in de historie van de groep?

Waarom maak je geen groepen in PowerCalc?

Het probleem van een som sensor is dat je som ook even lager kan worden als er een lamp niet beschikbaar is. En dat wordt dan in HA gezien als een reset.

[ Voor 3% gewijzigd door TheFes op 16-01-2026 09:06 ]

[Septillion]

@PhilipsFan Denk dat het morgen dan wel rechtgetrokken is. En anders gewoon via Dev tools +> statistics voor vandaag corrigeren.

[Septillion]

noo schreef op donderdag 15 januari 2026 @ 20:48:
[...]

De icon wel, maar de 'kWh' en de round(2) ben ik dan kwijt.
(die 'kWh' zou ik ook nog uit een attribute kunnen halen, maar 'kWh' is minder typen )
Dat laatste kan dus gewoon door with_unit=True toe te voegen aan het state template.

Je kan ook gewoon entity en state/name opgeven. En kan je zelfs in de name (en state) doen {{ state_attr(config.entity, 'dayname') }}

Maar uhm, ik zie nu juist toch geen round staan?

[TheFes]

De kogel is door de kerk. Add-ons worden binnenkort Apps

[belly89]

TheFes schreef op vrijdag 16 januari 2026 @ 09:36:
De kogel is door de kerk. Add-ons worden binnenkort Apps

Zeker voor nieuwe gebruikers denk ik een fijne keuze. Zie dat het alleen de naam wijziging is, verder blijft het onveranderd. Dus lijkt mij een prima keuze

[noo]

Septillion schreef op vrijdag 16 januari 2026 @ 09:02:
[...]

Je kan ook gewoon entity en state/name opgeven. En kan je zelfs in de name (en state) doen {{ state_attr(config.entity, 'dayname') }}

Maar uhm, ik zie nu juist toch geen round staan?

Zie 'reden van edit' van noo in "Home Assistant: Open source Python3 home automation - deel 5"

[Septillion]

@noo Dat is alleen totaal geen antwoord op mijn vragen Ik zeg dus dat het nog makkelijker kan door wel entity te gebruiken.

En je hebt het er over dat je dan round(2) kwijt bent maar die zie ik nu toch al niet...

[noo]

Septillion schreef op vrijdag 16 januari 2026 @ 10:31:
@noo Dat is alleen totaal geen antwoord op mijn vragen Ik zeg dus dat het nog makkelijker kan door wel entity te gebruiken.

En je hebt het er over dat je dan round(2) kwijt bent maar die zie ik nu toch al niet...

Ik had de yaml in mijn post al aangepast voor jij postte dus vandaar dat je die round niet meer zag want die was na het toevoegen van with_unit=True niet meer nodig. Ik heb naar aanleiding van jouw opmerking over het gebruiken van de entity en config.entity mijn card rows aangepast. Dank voor de hints.

YAML:

  - type: custom:template-entity-row
    entity: sensor.solcast_pv_forecast_forecast_day_3
    name: "{{ state_attr(config.entity, 'dayname') }}"
    state: "{{ states(config.entity, with_unit=True) }}"

[verjager]

@Septillion Met with_unit gebruik je inderdaad de precisie die is geconfigureerd voor de sensor.
Kan je overigens ook weer overriden indien gewenst:

Django/Jinja:

{{ states(config.entity, with_unit=True, rounded=False) }}

[Septillion]

@verjager Ah, ja. zo had ik de documentatie niet gelezen. Want tikkeltje verwarrend dat de default voor rounded dus aanpast door wat je bij with_unit gebruikt Ik las het eerste voorbeeld als "default".

Maar @noo, als je toch gewoon de standaard afronding wilt incl unit, dan is dat toch hetzelfde als state weglaten en deze automatisch te laten vullen op basis van de gegeven entity?

[noo]

Septillion schreef op vrijdag 16 januari 2026 @ 11:59:
@verjager Ah, ja. zo had ik de documentatie niet gelezen. Want tikkeltje verwarrend dat de default voor rounded dus aanpast door wat je bij with_unit gebruikt Ik las het eerste voorbeeld als "default".

Maar @noo, als je toch gewoon de standaard afronding wilt incl unit, dan is dat toch hetzelfde als state weglaten en deze automatisch te laten vullen op basis van de gegeven entity?

Nope, zonder state krijgt je het onafgeronde getal zonder unit.

[verjager]

@Septillion @noo Het probleem is dat de custom:template-entity-row inmiddels een al wat oudere custom card is. De nieuwe verbeteringen van with_unit, precision en landspecifieke instellingen (punt of komma) worden hierin niet hetzelfde behandeld als voor een standaard entity-row.

Een standaard entity-row toont de waarde met unit, incl. precision.
Een template-entity-row toont de waarde zonder unit, zonder precision.

Maar in een gewone entity-row kun je helaas niet templaten.

[Septillion]

@verjager Ja, dat had ik niet verwacht. Had verwacht dat het dan just de standaard weergave zou doen. Juist omdat de standaard weergave eerst niet mogelijk was met een template omdat je niet op een afgeronde waarde kon vragen via een template.

[verjager]

Ik denk dat de custom row gewoon states(...) opvraagt en that's it.

En de weergave voor standaard kaarten zal tegenwoordig dus zijn gebaseerd op with_unit (en dus ook met de default precision).

[WoBBeL]

Wat kan ik het beste gebruiken om een climate device (airco in dit geval) uit te schakelen (vanuit een automation)?

YAML:

          - device_id: f51f8df1d46265fffb08d8dd0907a043
            domain: climate
            entity_id: 395fd1ff5dcef6a34e49b5a03a7f19e8
            type: set_hvac_mode
            hvac_mode: "off"

YAML:

          - action: climate.turn_off
            metadata: {}
            target:
              entity_id: climate.climacontrol_woonkamer_climate
            data: {}

Je kan in de automation kiezen voor acties op een device of een climate actie op een entiteit. Beiden doen hetzelfde (zover ik kan vinden) maar is de climate.turn_off netter? Daar zie je ook de naam ipv ID

[TheFes]

WoBBeL schreef op vrijdag 16 januari 2026 @ 15:13:
Wat kan ik het beste gebruiken om een climate device (airco in dit geval) uit te schakelen (vanuit een automation)?

YAML:

          - device_id: f51f8df1d46265fffb08d8dd0907a043
            domain: climate
            entity_id: 395fd1ff5dcef6a34e49b5a03a7f19e8
            type: set_hvac_mode
            hvac_mode: "off"

YAML:

          - action: climate.turn_off
            metadata: {}
            target:
              entity_id: climate.climacontrol_woonkamer_climate
            data: {}

Je kan in de automation kiezen voor acties op een device of een climate actie op een entiteit. Beiden doen hetzelfde (zover ik kan vinden) maar is de climate.turn_off netter? Daar zie je ook de naam ipv ID

device triggers/conditions/actions zo veel mogelijk voorkomen.
Dit maakt het een stuk makkelijker om uiteindelijk devices te vervangen, omdat je simpelweg kunt zorgen dat het nieuwe device dezelfde entity_id's gebruikt.
Bij devices krijgt het device altijd een uniek device id, wat niet te wijzigen is, dus dan moet je in al je automations de device triggers/conditions/actions gaan wijzigen.

[RobertMe]

TheFes schreef op vrijdag 16 januari 2026 @ 15:39:
[...]


device triggers/conditions/actions zo veel mogelijk voorkomen.
Dit maakt het een stuk makkelijker om uiteindelijk devices te vervangen, omdat je simpelweg kunt zorgen dat het nieuwe device dezelfde entity_id's gebruikt.
Bij devices krijgt het device altijd een uniek device id, wat niet te wijzigen is, dus dan moet je in al je automations de device triggers/conditions/actions gaan wijzigen.

En dan? Event gebruiken? Die geven elke keer kopzorgen als je een automation maakt*. Een apparaat vervangen heb ik in de ~9 jaar dat ik nu iets met domotica doe (nog) niet hoeven doen. En als het dan uiteindelijk eens voor zou komen doe ik dan wel een search & replace.

* ook zo'n feature die het niet is, events en event triggers. En ook niet wordt opgelost / verbeterd. Net zoals nu power op het energy dashboard waar er 0,0 gedaan is/wordt om om te kunnen gaan met positieve vermogens waar negatief verwacht wordt en andersom.

Edit:
Owja, uiteraard puur als rant. Niet persoonlijk aan jou gericht

Edit2:
Niet "events en event triggers". Het ontbreken van event triggers en maar state triggers moeten gebruiken is juist het hele probleem

[ Voor 9% gewijzigd door RobertMe op 16-01-2026 17:10 ]

[TheFes]

RobertMe schreef op vrijdag 16 januari 2026 @ 17:06:
[...]

En dan? Event gebruiken? Die geven elke keer kopzorgen als je een automation maakt*. Een apparaat vervangen heb ik in de ~9 jaar dat ik nu iets met domotica doe (nog) niet hoeven doen. En als het dan uiteindelijk eens voor zou komen doe ik dan wel een search & replace.

* ook zo'n feature die het niet is, events en event triggers. En ook niet wordt opgelost / verbeterd. Net zoals nu power op het energy dashboard waar er 0,0 gedaan is/wordt om om te kunnen gaan met positieve vermogens waar negatief verwacht wordt en andersom.

Edit:
Owja, uiteraard puur als rant. Niet persoonlijk aan jou gericht

Edit2:
Niet "events en event triggers". Het ontbreken van event triggers en maar state triggers moeten gebruiken is juist het hele probleem

Fatsoenlijk event triggers zitten in de pijplijn. Daar wordt wel aan gewerkt.

[PuceTundra]

MennodR schreef op vrijdag 16 januari 2026 @ 17:27:
Na hier op het forum heel wat dashboards te hebben bekeken en na een half jaartje aanklooien met mijn eigen Home Assistant-dashboard ook wel tijd om hier iets te delen.

Mijn filosofie voor Home Assistant is eigenlijk dat alles zo automatisch mogelijk moet werken, zonder dat je zelf nog veel knoppen in moet drukken. Zo schakelen bij ons de tv en speakers automatisch in (op de juiste ingang en met het juiste volume) zodra we beginnen met casten vanaf de telefoon. Dingen die om een actie vragen worden omgeroepen, zoals: “de wasmachine is klaar” of “morgen wordt het GFT opgehaald” of in de zomer “het is buiten koeler dan binnen, overweeg de ramen open te zetten om het huis af te laten koelen”.

Maargoed niet alles kan natuurlijk geautomatiseerd worden, dus is een dashboard waarop je het een en ander kunt bedienden toch wel handig Ik heb er eentje gemaakt die we zowel op de telefoon gebruiken als op een scherm aan de muur hangt. Een grote tablet vond ik te dominant in het interieur, daarom heb ik gekozen voor een kleinere variant: de Sonoff NSPanel Pro. Qua layout heb ik geprobeerd het zo minimalistisch mogelijk te houden, met de focus op de knoppen en informatie die we het meest gebruiken.

Op het startscherm zie je direct de temperatuur binnen, buiten en in de serre in de tuin.
Linksboven staat de vertrektijd van de eerstvolgende twee metro’s richting het centrum, rechtsboven het actuele stroomverbruik. Door daarop te klikken open je een tab met het stroomverbruik per apparaat, waarbij alleen de apparaten worden getoond die op dat moment aan staan.

Het schermpje hangt op de oude plek van de thermostaat:
[Afbeelding]

Homescreen:
[Afbeelding]

Verder toont het homescreen het percentage van de compressor van de warmtepomp. Het icoon geeft de huidige status aan (verwarmen, koelen, defrost of tapwater). Door hierop te klikken opent een popup met meer gedetailleerde informatie (zie ook het filmpje).

[YouTube: Home Assistant Dashboard]

Via de menubalk onderin (navbar card) zijn verschillende popups te openen, waaronder Spotify (Spotify Web Player Card) en de verlichting. Ook kan ik hiermee het volume van de verschillende speakers bedienen.

Het scherm hangt er nog niet zo lang, maar we merken nu al dat zowel mijn vriendin als ik het verrassend vaak gebruiken. Vooral voor muziek afspelen en het aanpassen van het volume van de speakers.

Wauw!
Dit is precies wat ik graag zou willen voor mijn NSPanel Pro in de woonkamer. Zou je ons kunnen vertellen hoe je dit hebt gebouwd, of zou je de code met ons willen delen?

[Driek]

Vannacht is mijn fritzbox geupdate en nu kan ik mijn home assistant niet meer extern benaderen.
Ik verbind via duckdns en heb in de fritsbox portforwarding ingesteld.

Ik kon altijd intern en extern HA benaderen via https://<site>.duckdns.org/
Maar nu dus niet meer.

Intern kan ik nog wel via https://192.168.178.96:8123 HA benaderen, maar krijg wel een certificaat error.
Op duckdns staat alles nog goed, en in HA bij de duckdns integratie staat ook alles goed (als ik de log mag geloven)

Ik ben even uit mijn opties om het weer goed te krijgen.
Ideeen?

[Racer89]

Foutje...

[ Voor 96% gewijzigd door Racer89 op 16-01-2026 20:24 ]

[Septillion]

@Driek De vragen die ik dan heb:

- Heb je gekeken wat je externe IP nu is?
- Komt die overeen met die van DuckDNS
- En wat als je naar https://[externIP]:8123/ gaat?
- En de Fritzbox heeft niet opeens bedacht een andere range intern te gaan gebruiken?

[Driek]

Septillion schreef op vrijdag 16 januari 2026 @ 20:25:
@Driek De vragen die ik dan heb:

- Heb je gekeken wat je externe IP nu is?
- Komt die overeen met die van DuckDNS
- En wat als je naar https://[externIP]:8123/ gaat?
- En de Fritzbox heeft niet opeens bedacht een andere range intern te gaan gebruiken?

ja, de externe ip adres en duckdns matchen, externe ip adres ook gevalideerd met https://www.whatsmyip.org/
browsen naar het externe adres met poort 8123 werkt niet, heb ik ook niet geofrward, heb 443 geforward, die doet het ook niet.
De fritsbox range is voor zover ik kan zien niet veranderd, alle interne ipadressen zijn ook nog werkend.

[Septillion]

@Driek Dus je hebt forward op de router van 443 naar 8123?

Anders zou ik die eens weggooien en opnieuw toevoegen. Of zoeken of ze gekke andere firewall zaken hebben toegevoegd.

[Driek]

Septillion schreef op vrijdag 16 januari 2026 @ 20:40:
@Driek Dus je hebt forward op de router van 443 naar 8123?

Anders zou ik die eens weggooien en opnieuw toevoegen. Of zoeken of ze gekke andere firewall zaken hebben toegevoegd.

Ja 443 extern naar 8123 intern.
Ga zo router herstarten en de forwarding opnieuw doen

Helaas, werkt helaas niet

Kom er nu ook achter dat wireguard-vpn het ook niet meer doet.
en in de logging van de frits zie ik ook de melding:
cat: can't open '/proc/kdsld/dsliface/lan0/ip6_ct/openports': No such file or directory

Dus denk toch een bug in de fritsbox, toch maar eens met frits contact opnemen

[ Voor 29% gewijzigd door Driek op 16-01-2026 21:29 ]

[Rik.]

Iemand enig idee hoe het kan dat ik via WiFi regelmatig niet kan verbinden met HA?

[ Voor 29% gewijzigd door Septillion op 16-01-2026 21:52 . Reden: Plaatje wat kleiner voor de desktopgebruikers ]

[GoBieN-Be]

Wellicht probeert de Companion App de externe URL omdat deze nog open stond en verbonden was.
En als die externe URL niet werkt vanaf je intern netwerk, wat veel voorkomt heb je een probleem.
Kijk als je in je router ook hairpin NAT kan aanzetten voor de portforward.
Dan laat je router ook toe dat een intern apparaat probeert verbinding te maken met je extern publiek IP adres.

[ Voor 20% gewijzigd door GoBieN-Be op 16-01-2026 21:49 ]

[Driek]

Rik. schreef op vrijdag 16 januari 2026 @ 21:26:
Iemand enig idee hoe het kan dat ik via WiFi regelmatig niet kan verbinden met HA?

[Afbeelding]

[Afbeelding]

werkt verbinden met je ipadres wel?

toevallig een fritsbox modem?
Zie mijn berichten hierboven

[Rik.]

Driek schreef op vrijdag 16 januari 2026 @ 21:31:
[...]

werkt verbinden met je ipadres wel?

toevallig een fritsbox modem?
Zie mijn berichten hierboven

Nee geen fritsbox
Via browser werkt met IP wel, maar met certificaat error uiteraard want die zit op DuckDNS
In app werkt dat niet

Lijkt nu te werken door lokaal netwerk in HA settings ook op DuckDNS url te zetten, maar weet dit nog niet zeker
Hierdoor kan ik via browser alleen niet meer via IP verbinden, enkel via DuckDNS URL

[ Voor 8% gewijzigd door Rik. op 16-01-2026 21:46 ]

[Septillion]

@Rik. Ik zet in op DuckDNS. Dat is sinds 1,5 jaar echt zo suuuuper flacky.

En hoe doe je https, native of met een reverse proxy (zoals Nginx)?

[Antonio di]

Rik. schreef op vrijdag 16 januari 2026 @ 21:43:
[...]

Nee geen fritsbox
Via browser werkt met IP wel, maar met certificaat error uiteraard want die zit op DuckDNS
In app werkt dat niet

Lijkt nu te werken door lokaal netwerk in HA settings ook op DuckDNS url te zetten, maar weet dit nog niet zeker
Hierdoor kan ik via browser alleen niet meer via IP verbinden, enkel via DuckDNS URL

en ook @Driek
Ik heb al weer een tijdje geleden problemen gehad met verbinding via Wifi (duckdns) , Bleek dat ik alle 3 mijn SSID's van de Router-Wifi moest toevoegen via de HA Company app. Dat begon weer opnieuw (SSID's toevoegen) na een router wissel (i.v.m. met overstap provider) en ook een keer na een reset van de "nieuwe" van Ziggo router (Sagem), weer SSID's opnieuw toevoegen (na verwijderen). Er was ook nog een keer iets met niet werkende Duckdns i.s.m. met de HA app met de locatie die ik standaard UIT heb staan (weet niet meer hoe dat zat). Daarnaast ook nog een keer problemen gehad door het toevoegen van een HA integratie die poortje 80 gebruikt en alle anderen die 443 gebruiken en toen ook Duckdns i.s.m. NGINX proxy gaan gebruiken.

[Driek]

Antonio di schreef op vrijdag 16 januari 2026 @ 22:03:
[...]

en ook @Driek
Ik heb al weer een tijdje geleden problemen gehad met verbinding via Wifi (duckdns) , Bleek dat ik alle 3 mijn SSID's van de Router-Wifi moest toevoegen via de HA Company app. Dat begon weer opnieuw (SSID's toevoegen) na een router wissel (i.v.m. met overstap provider) en ook een keer na een reset van de "nieuwe" van Ziggo router (Sagem), weer SSID's opnieuw toevoegen (na verwijderen). Er was ook nog een keer iets met niet werkende Duckdns i.s.m. met de HA app met de locatie die ik standaard UIT heb staan (weet niet meer hoe dat zat). Daarnaast ook nog een keer problemen gehad door het toevoegen van een HA integratie die poortje 80 gebruikt en alle anderen die 443 gebruiken en toen ook Duckdns i.s.m. NGINX proxy gaan gebruiken.

dus je advies, duckdns de deur uit?

[Septillion]

@Driek Op zich, ja, want brak.

Maar als je HA ook niet kunt bereiken in de browser op extern IP is DuckDNS niet het probleem.

[Driek]

Septillion schreef op vrijdag 16 januari 2026 @ 22:53:
@Driek Op zich, ja, want brak.

Maar als je HA ook niet kunt bereiken in de browser op extern IP is DuckDNS niet het probleem.

ja, dat was ook mijn gedachte.
Overigesn heb ik de laatste tijd regelmatig dat er steeds tijdelijk geen verbinding te maken is, dat zal dan toch de duckdns brakheid zijn.

Denk dat het toch in de frits software zit.
Heb de dns settings weer neutraal gezet in de router, nu werkt wireguard weer, maar HA bereiken werkt niet.
Heb nu ook poort 8123 geprobeerd, maar die resulteert ook in connection refused