Home Assistant: Open source Python3 home automation - deel 5

[Just_A_User]

Hmmbob schreef op woensdag 11 september 2024 @ 16:24:
[...]

Auto niet per se, wel mijn laadpaal (en dus indirect de auto).

Als je de laadpaal in HA krijgt via een integratie, kan je in 99% van de gevallen ook uitlezen hoeveel deze verbruikt heeft. Maar, dat hangt dus af van je laadpaal.

Ja, nou, die laadpaal is geleverd door mijn werkgever, maar daar kan ik dus zelf helemaal niks mee. Ik kan er niet op inprikken of niks, dus dat gaat niet werken.

[manusjevanalles]

Eriko schreef op woensdag 11 september 2024 @ 15:36:
COP betekent yield / power + 1. Dat is toch hetzelfde als (yield+power) / power. Alles is uitgedrukt in kW. Of alles in Watt mag ook.

Ik wil hier zeker geen off-topic discussie starten, maar weet je het zeker? Ook hier wordt gewoon opwek/verbruik genoemd. In jouw formule is de COP gewoon altijd +1 hoger dan in werkelijkheid.

[The Executer]

Oke, vele errors, indents en weetikwatallemaal verder heb ik weer een fatsoenlijke config en lijkt het allemaal te werken. Ook sensors.yaml word ingeladen zonder errors dit keer volgens mij, de log toont geen errors meer en ik krijg geen melding meer. Maar, ik zie nergens meer mijn entiteiten... Alleen de entiteiten vanuit de utility-meter vanuit de config yaml, maar uit de sensors.yaml niet meer. Komt dat door deze error?

code:

Configuratiewaarschuwingen
Invalid config for 'sensor' at configuration.yaml, line 12: required key 'platform' not provided

Echter wanneer ik in de documentatie kijk, zie ik voor sensors geen platform genoemd worden.

Huidige config:

YAML:

template:
  - sensor:
      - name: "Current Power Consumption"
        unique_id: current_power_consumption
        unit_of_measurement: "W"
        value_template: ">
        {% if (states('sensor.current_from_grid') | float) >= 0 %}
        {{ ((states('sensor.current_from_grid') | float) + (states('sensor.inverter_watts') | float)) | round(0)}}
        {% else %} 
        {{ ((states('sensor.inverter_watts') | float) - (states('sensor.current_to_grid') | float)) | round(0)}}
        {% endif %}"

## Huidig verbruik minus plug
      - name: "Stroomverbruik"
        unique_id: current_power_consumption_minus_plug
        unit_of_measurement: "W"
        value_template: "{{ states('sensor.current_power_consumption')|float - states('sensor.plug_power') |float | round(0)}}"

## Vandaag opgewekt
      - name: "Vandaag opgewekt"
        unique_id: daily_energy_solar
        unit_of_measurement: kWh
        value_template: "{{states('sensor.daily_energy_produced') |float | round(0)}}"

## Vandaag totaal terug geleverd
      - name: "Teruggeleverd"
        unique_id: daily_energy_returned
        unit_of_measurement: kWh
        value_template: "{{ states('sensor.daily_energy_returned_offpeak')|float + states('sensor.daily_energy_returned_peak')|float }}"

## Vandaag totaal gebruikt (Dummy voor daily_energy_netto)
      - name: "Gebruikt"
        unique_id: daily_energy_used
        unit_of_measurement: kWh
        value_template: "{{ states('sensor.electricity_meter_energy_consumption_tarif_1')|float + states('sensor.electricity_meter_energy_consumption_tarif_2')|float }}"

## Netto verbruik vandaag na saldering
      - name: "Verbruikt"
        unique_id: daily_energy_netto
        unit_of_measurement: kWh
        value_template: "{{ states('sensor.daily_energy_used')|float - states('sensor.daily_energy_returned')|float}}"

## Nu naar grid
      - name: "Naar grid"
        unique_id: current_to_grid
        unit_of_measurement: W
        value_template: "{{(states('sensor.electricity_meter_power_production') |float * 1000) | round(0)}}"

## Nu van grid
      - name: "Van grid"
        unique_id: current_from_grid
        unit_of_measurement: W
        value_template: "{{ (states('sensor.electricity_meter_power_consumption') |float * 1000 - states('sensor.electricity_meter_power_production') | float * 1000 |int ) | round(0)}}"

[Septillion]

RobertMe schreef op woensdag 11 september 2024 @ 13:35:
Wat me eigenlijk wel (nog steeds) tegen valt is dat je in templates geen simpele vergelijking met ints/floats kunt doen met inachtneming van unavailable. Dus een "als <sensor> is kleiner dan <X> dan...", waarbij niks gebeurd als de sensor unavailable of zo is (bv een "zet stroom van apparaat uit als vermogen onder de X is, maar als het vermogen niet bekend is, laat dan maar aan staan"). Je moet dan al of is_number(states(...)) and states(...)|float < ... doen, of, stuk korter, "hacken" met de default value van de float filter: states(...)|float(X+1) < X. Waarbij de default dus altijd een false value zal opleveren.

Ik had inderdaad ook graag gezien dat standaard een template sensor unavailable zou gaan als een van de bronnen waar de template gebruik van maakt niet beschikbaar is (of niet matcht met device_class zoals numbers). Dat zou zeker in 90% van de gevallen al goed zijn namelijk. En dat je eventueel als nog zelf een availabilty zou kunnen maken als je ander gedrag wenst.

[Septillion]

The Executer schreef op woensdag 11 september 2024 @ 15:03:
[...]


Ik heb even gekeken, en kom voorzichtig tot de volgende conclusie, klopt dit? Legacy:

YAML:

## Vandaag opgewekt
    daily_energy_solar:
      friendly_name: Opgewekt
      unit_of_measurement: kWh
      value_template: "{{states('sensor.daily_energy_produced') |float | round(0)}}"

Nieuwe stijl:

YAML:

## Vandaag opgewekt
    name: Vandaag opgewekt
    unique_id: daily_energy_solar
    unit_of_measurement: kWh
    value_template: "{{states('sensor.daily_energy_produced') |float | round(0)}}"

Utility meter kan ik nog wel gewoon op deze manier gebruiken toch?

YAML:

utility_meter:
## Dagelijks energie verbruik
  daily_energy_offpeak:
    source: sensor.electricity_meter_energy_consumption_tarif_1
    cycle: daily
  daily_energy_peak:
    source: sensor.electricity_meter_energy_consumption_tarif_2
    cycle: daily
  daily_energy_returned_offpeak:
    source: sensor.electricity_meter_energy_production_tarif_1
    cycle: daily
  daily_energy_returned_peak:
    source: sensor.electricity_meter_energy_production_tarif_2
    cycle: daily
  daily_energy_produced:
    source: sensor.inverter_watthours
    cycle: daily
  daily_gas:
    source: sensor.gas_meter_gas_consumption
    cycle: daily

Bijna, value_template is gewoon state geworden. En belangrijkste is dat de nieuwe dus NIET onder sensors: met platform: template hoort maar onder template:

Utility meter via yaml is niet andes geworden.

En in je laatste post denk ik een copy-past fout dat je een spatie hebt voor template:?

En bij Current Power Consumption" mix je single line yaml met multiline yaml. Of alles tussen quotes, of als je multiline wilt, geen quotes en dan >-. De regel eronder maar twee spaties ingesprongen kan je dan je template op meerdere regels kwijt.

Ook probeer je meerdere sensors te definiëren maar dan moet je elke sensor wel in een eigen array element zetten (dus elke gedeelte van een sensor moet een streepje) Dus

YAML:

 template:
  - sensor:
      - name:
        somehting:
      - name:
      - name:
      - name:

[ Voor 14% gewijzigd door Septillion op 11-09-2024 17:12 ]

[Eriko]

manusjevanalles schreef op woensdag 11 september 2024 @ 16:43:
[...]


Ik wil hier zeker geen off-topic discussie starten, maar weet je het zeker? Ook hier wordt gewoon opwek/verbruik genoemd. In jouw formule is de COP gewoon altijd +1 hoger dan in werkelijkheid.

Inderdaad is het verwarrend. Mijn post staat ook erin:

Proton_ in "Vaillant aroTHERM warmtepomp ervaringen"

Er zijn bij Vaillant dus drie relevante cijfers voor energiestromen die je her en der door elkaar tegen komt:
* Elektrische energie
* Milieuopbrengst
* Warmteopbrengst

De COP is Warmteopbrengst / Elektrische energie = W / E

Warmteopbrengst is op zijn beurt Milieuopbrengst + Elektrische energie. => W = M + E

DUS COP = W / E = (M + E) / E = M/E + E/E = M / E + 1. COP is altijd gelijk of groter dan 1.

[The Executer]

Septillion schreef op woensdag 11 september 2024 @ 17:07:
[...]

Thanks voor je reactie, ben blij met je hulp aan deze dummie . Tis nu ook wel gelijk duidelijk waarom ik geen programmeur ben geworden gok ik .

Moet zeggen, zat aardig hoog in de frustratie, zo'n fijn achterblijfsel van de PTSS. Inmiddels even gegeten, de rust is weer wedergekeerd. Ik ga weer een poging wagen. Studio Code Server snapt het ook allemaal weer, doet weer goede indents etc. Is ook wel klote als die het niet meer snapt, mijn indents werden wel heel klein, of juist heel groot zonder enige logica er meer achter .

Bijna, value_template is gewoon state geworden.

Check... die heb ik gemist en zojuist gecorrigeerd.

En belangrijkste is dat de nieuwe dus NIET onder sensors: met platform: template hoort maar onder template:

Check, die had ik in mijn vorige post al goed staan, in de post van er voor niet. Echter, de validator blijft melden dat ik een platform op moet geven... Maar het is maar een warning .

Utility meter via yaml is niet anders geworden.

Gelukkig , thanks.

En in je laatste post denk ik een copy-past fout dat je een spatie hebt voor template:?

Dit was een foutje inderdaad, druk aan het typen en per ongeluk een spatie in gegooid. In de code stond hij iig niet.

En bij Current Power Consumption" mix je single line yaml met multiline yaml. Of alles tussen quotes, of als je multiline wilt, geen quotes en dan >-. De regel eronder maar twee spaties ingesprongen kan je dan je template op meerdere regels kwijt.

Check, quotes zijn verdwenen.

Ook probeer je meerdere sensors te definiëren maar dan moet je elke sensor wel in een eigen array element zetten (dus elke gedeelte van een sensor moet een streepje) Dus

YAML:

 template:
  - sensor:
      - name:
        somehting:
      - name:
      - name:
      - name:

Yes, die had ik in mijn vorige post ook al goed staan toch? Elke sensor zijn eigen - name-attribuut met daaronder de zaken per sensor. Ik heb de YAML's opnieuw laten laden, maar zie de entiteiten nog steeds niet.

ff klein gedeelte van de code gedaan, alle herhalingen spreken voor zich

YAML:

template:
  - sensor:
      - name: "Current Power Consumption"
        unique_id: current_power_consumption
        unit_of_measurement: "W"
        state: >
          {% if (states('sensor.current_from_grid') | float) >= 0 %}
          {{ ((states('sensor.current_from_grid') | float) + (states('sensor.inverter_watts') | float)) | round(0)}}
          {% else %} 
          {{ ((states('sensor.inverter_watts') | float) - (states('sensor.current_to_grid') | float)) | round(0)}}
          {% endif %}

## Huidig verbruik minus plug
      - name: "Stroomverbruik"
        unique_id: current_power_consumption_minus_plug
        unit_of_measurement: "W"
        state: "{{ states('sensor.current_power_consumption')|float - states('sensor.plug_power') |float | round(0)}}"

## Vandaag opgewekt
      - name: "Vandaag opgewekt"
        unique_id: daily_energy_solar
        unit_of_measurement: kWh
        state: "{{states('sensor.daily_energy_produced') |float | round(0)}}"

[Septillion]

@The Executer Ja, dat ziet er goed uit. Laatste had je inderdaad, dacht hert anders gezien te hebben Ik moet ook eten.

Als je dan nog steeds een error over platform krijgt zit deze denk ik juist in het deel waar je het lopen opschonen ipv het nieuwe template deel.

[The Executer]

Septillion schreef op woensdag 11 september 2024 @ 18:13:
@The Executer Ja, dat ziet er goed uit. Laatste had je inderdaad, dacht hert anders gezien te hebben Ik moet ook eten.

Als je dan nog steeds een error over platform krijgt zit deze denk ik juist in het deel waar je het lopen opschonen ipv het nieuwe template deel.

Het gekke is, hij wil platform op regel 12 hebben:
Invalid config for 'sensor' at configuration.yaml, line 12: required key 'platform' not provided

Dat is na de eerste sensor. Lijkt erop dat die eerste sensor niet 'afgerond' word oid. Heb al mijn commentaar er tussenuit gehaald en de sensors tegen elkaar aan, maakt geen verschil. De eerste (multi-regel) sensor helemaal naar onderen verplaatst, de rest van de sensors naar boven... Hij geeft nog steeds Invalid config for 'sensor' at configuration.yaml, line 12: required key 'platform' not provided. Indentation nog weer veranderd, maakt allemaal geen verschil .

Edit: Multi-regel sensor even compleet uitgecommentaard, ook geen verschil. Nog steeds platform op 12...

[ Voor 4% gewijzigd door The Executer op 11-09-2024 18:27 ]

[Septillion]

@The Executer Is dit echt wat je bovenaan de configuration.yaml als eerste item hebt?

Jij gaat me ook niet laten zoeken naar een typografische apostrof ofzo he?

[oZe NL]

Na zo'n 15 jaar een trouwe 'meelezer' te zijn geweest (vooral om inspiratie op te doen en mijzelf te verwonderen over wat er mogelijk is met HA) waag ik mij weer eens aan een post hier op het forum.

Ik heb via CloudFlare een tunnel opgezet om mijn Home Assistant (HA) vanaf buiten bereikbaar te maken. Dit werkt prima en als ik mijn HA via de URL buitenshuis benader, krijg ik geen certificaatwaarschuwingen. Echter, wanneer ik thuis ben en via Safari of Chrome browse, krijg ik een melding dat het certificaat ongeldig is.

Ik weet eigenlijk niet zo goed waar ik het zoeken moet. De iOS-app van HA kan automatisch bepalen of de interne of externe URL gebruikt moet worden, maar via de laptop vind ik het handig om alleen mijn externe URL te gebruiken.

Is het mogelijk om naast de tunnel ook de interne URL van een certificaat te voorzien zodat HTTPS geforceerd kan worden? Ik heb wat rondgezocht op internet maar kon hier niet helemaal uitkomen. Mijn domeinnaam is ook gehost bij CloudFlare, dus ik heb de mogelijkheid om daar certificaten te genereren.

Heeft iemand hier ervaring mee of suggesties over hoe ik dit het beste kan aanpakken?

[Ronker32]

The Executer schreef op woensdag 11 september 2024 @ 18:25:
[...]


Het gekke is, hij wil platform op regel 12 hebben:
Invalid config for 'sensor' at configuration.yaml, line 12: required key 'platform' not provided

Dat is na de eerste sensor. Lijkt erop dat die eerste sensor niet 'afgerond' word oid. Heb al mijn commentaar er tussenuit gehaald en de sensors tegen elkaar aan, maakt geen verschil. De eerste (multi-regel) sensor helemaal naar onderen verplaatst, de rest van de sensors naar boven... Hij geeft nog steeds Invalid config for 'sensor' at configuration.yaml, line 12: required key 'platform' not provided. Indentation nog weer veranderd, maakt allemaal geen verschil .

Edit: Multi-regel sensor even compleet uitgecommentaard, ook geen verschil. Nog steeds platform op 12...

Is die regel 12 niet de regel in configuration.yaml waar je een verwijzing naar deze yaml hebt staan? Met andere woorden, wil je de eerste regels uit je configuration.yaml eens plaatsen? Daar zit misschien het issue.

[ Voor 5% gewijzigd door Ronker32 op 11-09-2024 18:39 ]

[The Executer]

Septillion schreef op woensdag 11 september 2024 @ 18:28:
@The Executer Is dit echt wat je bovenaan de configuration.yaml als eerste item hebt?

Nee, deze code staat in sensors.yaml.

Jij gaat me ook niet laten zoeken naar een typografische apostrof ofzo he?

Niet bewust... Ik heb alleen de name, unique_id en de state aangepast...

Ronker32 schreef op woensdag 11 september 2024 @ 18:38:
[...]


Is die regel 12 niet de regel in configuration.yaml waar je een verwijzing naar deze yaml hebt staan? Met andere woorden, wil je de eerste regels uit je configuration.yaml eens plaatsen? Daar zit misschien het issue.

Ik had net een post gevonden op de HA community over dat regelnummers soms onlogisch zijn en soms voortkomen uit een regelnummer van een andere YAML waar een include gedaan word.

@Septillion & @Ronker32 Dit blijkt bij mij ook het geval te zijn, de include van sensors.yaml gebeurt op regel 12 van configuration.yaml. Om alle onzekerheid weg te nemen, de gedeeltelijke code van configuration.yaml en de volledige code van sensors.yaml.

configuration.yaml

YAML:

# Loads default set of integrations. Do not remove.
default_config:

# Load frontend themes from the themes folder
# frontend:
#   themes: !include_dir_merge_named themes
frontend: !include themes.yaml
template: !include sidebar.yaml
automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml
sensor: !include sensors.yaml

sensors.yaml

YAML:

template:
  - sensor:
      ## Vandaag totaal terug geleverd
      - name: "Teruggeleverd"
        unique_id: daily_energy_returned
        unit_of_measurement: kWh
        state: "{{ states('sensor.daily_energy_returned_offpeak')|float + states('sensor.daily_energy_returned_peak')|float }}"

      ## Vandaag totaal gebruikt (Dummy voor daily_energy_netto)
      - name: "Gebruikt"
        unique_id: daily_energy_used
        unit_of_measurement: kWh
        state: "{{ states('sensor.electricity_meter_energy_consumption_tarif_1')|float + states('sensor.electricity_meter_energy_consumption_tarif_2')|float }}"

      ## Netto verbruik vandaag na saldering
      - name: "Verbruikt"
        unique_id: daily_energy_totalused
        unit_of_measurement: kWh
        state: "{{ states('sensor.daily_energy_used')|float - states('sensor.daily_energy_returned')|float}}"

      ## Nu naar grid
      - name: "Naar grid"
        unique_id: current_to_grid
        unit_of_measurement: W
        state: "{{(states('sensor.electricity_meter_power_production') |float * 1000) | round(0)}}"

      ## Nu van grid
      - name: "Van grid"
        unique_id: current_from_grid
        unit_of_measurement: W
        state:
          "{{ (states('sensor.electricity_meter_power_consumption') |float * 1000 - states('sensor.electricity_meter_power_production') | float * 1000 |int ) | round(0)}}"

          ##    - name: "Current Power Consumption"
##      unique_id: current_power_consumption
##      unit_of_measurement: "W"
##      state: >
##        {% if (states('sensor.current_from_grid') | float) >= 0 %}
##        {{ ((states('sensor.current_from_grid') | float) + (states('sensor.inverter_watts') | float)) | round(0)}}
##        {% else %}
##        {{ ((states('sensor.inverter_watts') | float) - (states('sensor.current_to_grid') | float)) | round(0)}}
##        {% endif %}
##    - name: "Stroomverbruik"
##      unique_id: current_power_consumption_minus_plug
##      unit_of_measurement: "W"
##      state: "{{ states('sensor.current_power_consumption')|float - states('sensor.plug_power') |float | round(0)}}"
##    - name: "Vandaag opgewekt"
##      unique_id: daily_energy_solar
##      unit_of_measurement: kWh
##      state: "{{states('sensor.daily_energy_produced') |float | round(0)}}"

[Septillion]

@The Executer Dat is dus precies wat ik hier als belangrijk schreef. Dit valt NIET meer onder sensor: maar onder template:. En alles in je sensors.yaml valt onder sensor: door de include.

Als je weer een losse file hebt zou je template.yaml aan kunnen maken en in je configuration.yaml kunnen zetten template: !include template.yaml. En dan mag je in dat bestand bovenaan de template weglaten

[Septillion]

@oZe NL Een certificaat is alleen mogelijk op een domeinnaam. En een door een publiekelijk instantie gesigned certificaat alleen op een publiek domain (dus geen .local bijvoorbeeld).

Nu weet ik niet 100% hoe HA + CloudFlare werkt, maar klinkt dus niet zo zeer als een tunnel maar gewoon een extern adres met https. Dus als HA alleen nog met https te benaderen is zal je dat intern ook met het externe adres moeten doen voor een geldig certificaat.

[The Executer]

Septillion schreef op woensdag 11 september 2024 @ 19:03:
@The Executer Dat is dus precies wat ik hier als belangrijk schreef. Dit valt NIET meer onder sensor: maar onder template:. En alles in je sensors.yaml valt onder sensor: door de include.

Als je weer een losse file hebt zou je template.yaml aan kunnen maken en in je configuration.yaml kunnen zetten template: !include template.yaml. En dan mag je in dat bestand bovenaan de template weglaten

Ik heb een templates.yaml aangemaakt en daar de code ingedropt. Dit werkt nu. Tevens mijn 'rekensom' nu gecorrigeerd met de totaalopwekking per dag er bij zodat totaalverbruik per dag als het goed is nu berekend wordt.

Wat ik nog niet wist is de naamgeving. Ik ging er vanuit dat de unique_id zorgde voor de entiteits-ID maar hier pakt hij simpelweg de waarde uit name voor.

[Septillion]

@The Executer Super! Yep, vind ik ook nog steeds een iets wat eigenaardige keuze.

[Peet3kabo]

Just_A_User schreef op woensdag 11 september 2024 @ 16:32:
[...]


Ja, nou, die laadpaal is geleverd door mijn werkgever, maar daar kan ik dus zelf helemaal niks mee. Ik kan er niet op inprikken of niks, dus dat gaat niet werken.

Welk laadpaal? Meeste gevallen zal het een Alfen Eve Single Pro zijn, kan je toch veel meer mee dan je dan denkt als die het is.

[The Executer]

Septillion schreef op woensdag 11 september 2024 @ 21:30:
@The Executer Super! Yep, vind ik ook nog steeds een iets wat eigenaardige keuze.

Vanavond nog even alles over de kop gegooid omdat de namen verpest waren door het systeem. Hij pakte nog de namen van het name-veld, ondanks dat ik zie inmiddels aangepast had. Templates.yaml leeg gegooid, HA herstart, hiermee waren de entiteiten weg. Ondertussen in kladblok de namen logischer gemaakt en op zo'n manier genoemd dat het makkelijker te gebruiken is in de scripting. Werkt stukken makkelijker nu.

Moet alleen nog weer naar mijn optelsom kijken, die klopt toch nog niet. Zal morgen even de 3 waardes waar ik mee reken even controleren tegenover het energie-dashboard want ergens krijgt iets niet een goede waarde mee.

Energie Dashboard:
Opgewekt: 10,4kWh
Totaal stroomverbruik 8,1kWh

Eigen dashboard:
Opgewekt: 10,4kWh (dus deze klopt)
Totale verbruiksmeter vandaag: 10,2kWh (hier gaat dus iets mis).

Alleen het uitzoeken van de namen van entiteiten in scripts, welke waarde ze hebben gaat wat lustig op de telefoon. Morgen weer een kans!

[Ferra]

Kan het casten naar een Google Nest Hub nog steeds?

[remcoXP]

ik had ooit een theme (weet alleen niet meer welke) die dus bovenste bar op mobiel onderin plaatste, wat met 1 handsbediening erg fijn was.
weet iemand de code of plugin om dat bij andere themes ook voor elkaar te krijgen?

[Cyrus The Virus]

Ik probeer alle history van een entity te verwijderen met the purge functie via actions maar er lijkt niks te gebeuren. Iemand een idee wat ik fout doe ?

YAML:

action: recorder.purge_entities
data:
  keep_days: 0
  entity_id:
    - sensor.victron_battery_history_chargedenergy
    - sensor.victron_battery_history_dischargedenergy

[ Voor 0% gewijzigd door Septillion op 12-09-2024 08:35 ]

[Michel]

Sypher schreef op dinsdag 10 september 2024 @ 16:19:
[...]


Ik moest destijds toen ik mijn hor(schuif)deur installeerde ook een alternatieve sensor voor die deur vinden, want er kan niet meer op het kozijn ivm de bevestiging van de hor. Ik kwam toen ook uit op zo'n Sensative Strip. Die Aeotec zag ik toen ook, maar had geen zin te moeten boren.

Aanvankelijk was ik ook erg sceptisch over die Sensative Strip maar ondertussen draait het al sinds Juli 2019 en de batterij beweert nog 50% vol te zitten. Ik weet niet hoe ze het doen, maar somehow werkt het prima Of hij 10 jaar gaan halen valt nog te bezien...

Ik blijf het principe van die strip wel fijn vinden, want het is wel een redelijk permantente actie om te gaan boren. Ben er dan ook nog niet helemaal uit of dat de optie gaat zijn of dat het inderdaad strips gaan worden.

Probleem met de strips is echter dat die hier niet overal gaan passen, nagenoeg alle ramen en deuren sluiten nagenoeg naadloos aan in het kozijn.

[Septillion]

@Cyrus The Virus Je kijk niet toevallig naar de long term statistics? Een purge is alleen voor de state history, niet de long term. Die kan je via Dev tools -> Statistics aanpassen, maar zal je even de entity moeten verwijderen.

[Cyrus The Virus]

Septillion schreef op donderdag 12 september 2024 @ 08:38:
@Cyrus The Virus Je kijk niet toevallig naar de long term statistics? Een purge is alleen voor de state history, niet de long term. Die kan je via Dev tools -> Statistics aanpassen, maar zal je even de entity moeten verwijderen.

Ja ik wil de long term verwijderen dus alle data, via statistics kun je alleen de afzonderlijke datapunten aanpassen en dan ben ik uren bezig om ze een voor een te verwijderen. Had de entity ook al verwijderd maar dat hielp ook niet toen ik hem opnieuw toevoegde.

[ Voor 7% gewijzigd door Cyrus The Virus op 12-09-2024 08:52 ]

[TheFes]

The Executer schreef op donderdag 12 september 2024 @ 00:00:
[...]


Vanavond nog even alles over de kop gegooid omdat de namen verpest waren door het systeem. Hij pakte nog de namen van het name-veld, ondanks dat ik zie inmiddels aangepast had. Templates.yaml leeg gegooid, HA herstart, hiermee waren de entiteiten weg. Ondertussen in kladblok de namen logischer gemaakt en op zo'n manier genoemd dat het makkelijker te gebruiken is in de scripting. Werkt stukken makkelijker nu.

Moet alleen nog weer naar mijn optelsom kijken, die klopt toch nog niet. Zal morgen even de 3 waardes waar ik mee reken even controleren tegenover het energie-dashboard want ergens krijgt iets niet een goede waarde mee.

Energie Dashboard:
Opgewekt: 10,4kWh
Totaal stroomverbruik 8,1kWh

Eigen dashboard:
Opgewekt: 10,4kWh (dus deze klopt)
Totale verbruiksmeter vandaag: 10,2kWh (hier gaat dus iets mis).

Alleen het uitzoeken van de namen van entiteiten in scripts, welke waarde ze hebben gaat wat lustig op de telefoon. Morgen weer een kans!

Juist als je je ze een unique id geeft kun je de name en entity_id aanpassen in de GUI. Hoef je niet heel je config voor overhoop te gooien.
Dat het is het idee van dat unique_id, om ze te kunnen herkennen in de entity storage, zodat daarvoor niet het entity_id nodig is.
Ik gebruik daar altijd een UUID voor zelf.

[TheFes]

Cyrus The Virus schreef op donderdag 12 september 2024 @ 08:50:
[...]


Ja ik wil de long term verwijderen dus alle data, via statistics kun je alleen de afzonderlijke datapunten aanpassen en dan ben ik uren bezig om ze een voor een te verwijderen. Had de entity ook al verwijderd maar dat hielp ook niet toen ik hem opnieuw toevoegde.

Als je in de recorder settings aanpast dat de entity niet opgeslagen moet worden, en daarna herstart, zul je bij devtools > statistics een melding daarover krijgen, met als fix om alle bestaande historie te verwijderen.
Daarna kun je die setting bij recorder weer weghalen om weer historie te gaan opbouwen.

[Septillion]

@Cyrus The Virus Daarom gaf ik ook aan dat je dan de entity even moest verwijderen. Optie van @TheFes is ook mogelijk. Denk dat tijdelijk hernoemen misschien ook wel werkt.

[Cyrus The Virus]

TheFes schreef op donderdag 12 september 2024 @ 08:56:
[...]


Als je in de recorder settings aanpast dat de entity niet opgeslagen moet worden, en daarna herstart, zul je bij devtools > statistics een melding daarover krijgen, met als fix om alle bestaande historie te verwijderen.
Daarna kun je die setting bij recorder weer weghalen om weer historie te gaan opbouwen.

Top dit werkt nu is alle oude data weg bedankt @Septillion @TheFes

[TheFes]

Septillion schreef op donderdag 12 september 2024 @ 08:58:
@Cyrus The Virus Daarom gaf ik ook aan dat je dan de entity even moest verwijderen. Optie van @TheFes is ook mogelijk. Denk dat tijdelijk hernoemen misschien ook wel werkt.

hernoemen werkt niet, dan koppelt hij alle data aan het nieuwe entity_id.

[Just_A_User]

Septillion schreef op woensdag 11 september 2024 @ 18:28:
@The Executer Is dit echt wat je bovenaan de configuration.yaml als eerste item hebt?

Jij gaat me ook niet laten zoeken naar een typografische apostrof ofzo he?

.... Ik vind dit geen leuke opmerking.

[Just_A_User]

Peet3kabo schreef op woensdag 11 september 2024 @ 22:44:
[...]


Welk laadpaal? Meeste gevallen zal het een Alfen Eve Single Pro zijn, kan je toch veel meer mee dan je dan denkt als die het is.

Nee, die is het niet. Het is een Bluebuilt van Coolblue, maar daar heb ik geen connectie mee, het ding hangt niet eens aan wifi, maar heeft een dataverbinding ingebouwd. Het enige wat ik kan (en mag) is het laadoverzicht bekijken op een of andere portal.

[stevenP]

Just_A_User schreef op donderdag 12 september 2024 @ 09:51:
[...]


Nee, die is het niet. Het is een Bluebuilt van Coolblue, maar daar heb ik geen connectie mee, het ding hangt niet eens aan wifi, maar heeft een dataverbinding ingebouwd. Het enige wat ik kan (en mag) is het laadoverzicht bekijken op een of andere portal.

Ik ben er niet in thuis, maar 2s google geeft me deze integratie. Klinkt alsof je gewoon via een API alles kan binnenhengelen - of denk ik nu te simpel?

Blue current != Bluebuilt.. Laat maar
Hoe heet de webportal waar je wel in kan loggen?

[ Voor 7% gewijzigd door stevenP op 12-09-2024 10:01 ]

[Just_A_User]

stevenP schreef op donderdag 12 september 2024 @ 10:00:
[...]

Ik ben er niet in thuis, maar 2s google geeft me deze integratie. Klinkt alsof je gewoon via een API alles kan binnenhengelen - of denk ik nu te simpel?

Blue current != Bluebuilt.. Laat maar
Hoe heet de webportal waar je wel in kan loggen?

Iets van coolblue.nl/laadpalen ofzo, en daar kun je dan weer op inloggen, en dan kun je daar naar je laadsessies gaan en die zie je daar dan staan. Meer is het niet.

[Ben-i]

Iets met door de bomen het bos niet meer zien, dus hoop dat jullie mij willen helpen met een keuze maken.

Ik wil mijn HA systeem gaan upgraden van Raspberry pi 3B naar een "mini PC" met als doel een stabieler systeem dat sneller reageert en toekomst bestendig is.

Ergernissen nu zijn dat regelmatig de verbinding weg valt of het inloggen lang duurt (in android app en windows) of dat er even helemaal geen verbinding is voor een paar minuten. (misschien komt dit wel ergens anders door (duckdns, router settings, geen idee maar vrouw en kinderen zijn er dan al snel klaar mee "als het weer eens niet werkt")
Ook heeft de Raspberry moeite met de 2 HD camera's op het dashboard en reageert gewoon traag in het algemeen.
Het idee is dan ook om met een verse installatie alles opnieuw op te gaan bouwen op een meer capabele machine.

Huidige situatie: Raspberry pi 3 met HAOS
Ik heb nu zo'n 50 apparaten in gebruik en er lopen nu 23 automatiseringen voornamelijk voor de lampen en airco.
Tot nu toe wordt HA hier in huis door 4 gebruikers gebruikt voor het bedienen van de Tuya lampen (deels geautomatiseerd) de Airco bedienen en het stroomverbruik monitoren met HomeWizzard (p1) meters en Tuya plugs en 2 hd camera's.

Ik zou graag een media speler als Plex of Kodi erbij of er naast willen (misschien via proxmox ofzo?), films en series kijken doen we nu via de trage Plex app op de LG WebOS tv.
Frigate lijkt me ook wel interessant. En wil in de toekomst apparaten met zonnestroom overschot gaan schakelen.
De bedoeling is dat HA stabiel en soepel draait en meer/vaker gebruikt gaat worden in het dagelijks leven.

Ik heb nu door de positieve reacties op diverse fora's de Beelink s12 pro n100 16GB 500GB ssd voor €178,- op het oog. Is deze het extra geld waard of zal deze "overkill" zijn voor wat ik er mee wil doen en kan ik beter bv via Marktplaats van Maarten een oudere HP T630 quad core (amd gx-420gi) 16GB 250GB ssd voor bijvoorbeeld €94,- kopen?

Ik heb erg weinig verstand van hardware dus hoop dat jullie mij wat wijzer kunnen maken wat een goede aankoop zal zijn.

[Septillion]

@Ben-i Opnieuw beginnen kan een keuze zijn maar een backup is ook gewoon over te zetten.

Als je echt meer dingen ernaast wilt draaien is Proxmox daar wel makkelijk voor. Hele installatie viel mij erg mee.

Zelf draai ik het geheel ook op een N100 met 16GB. Voor HA alleen qua geheugen wel overkill maar de N100 is wel fijn. Mar zeker als je ook video en transcoden wilt gaan doen is het zeker geen overbodige luxe. Dus die HP zou ik dan niet doen. Ook qua stroomverbruik zal het aardig schelen.

Wel hoor ik de laatste tijd wat vaker dat DuckDNS wat loopt te bokken. Zou hier ook wel eens de reden kunnen zijn...

[Sabbi]

@Ben-i
Die thin-clients op marktplaats zijn niet heel krachtig, wel sneller dan een raspberry pi, maar als je nog extra zaken als Plex of Kodi wilt draaien denk ik dat je vrij snel tegen de limiet aanloopt.
De Beelink is dan een prima aankoop, maar je zou ook een tweedehands/refurbished mini-pc kunnen kopen zoals deze lenovo. Zolang je een 8ste generatie of nieuwere intel (dus i5-8*** of hoger) zit je voor Plex ed voor de komende jaren goed onder de pannen.

[Overspark]

Septillion schreef op woensdag 11 september 2024 @ 17:04:
[...]

Ik had inderdaad ook graag gezien dat standaard een template sensor unavailable zou gaan als een van de bronnen waar de template gebruik van maakt niet beschikbaar is (of niet matcht met device_class zoals numbers). Dat zou zeker in 90% van de gevallen al goed zijn namelijk. En dat je eventueel als nog zelf een availabilty zou kunnen maken als je ander gedrag wenst.

Je komt een heel eind met availabillity_template, waarmee je aan kan geven of een template sensor überhaupt available moet zijn. Als je daar alle checks in stops en true of false teruggeeft hoef je er in de rest van je template geen rekening meer mee te houden, dus kan je je template zelf een stuk leesbaarder houden.

Oud voorbeeld wat ik al een tijdje niet meer gebruik:

YAML:

      ventilatie_gewenst_luchtvochtigheid:
        friendly_name: "Ventilatie gewenst luchtvochtigheid"
        unit_of_measurement: "%"
        icon_template: hass:water-percent
        availability_template: >
          {% if states('sensor.ventilatie_luchtvochtigheid')|int(default=0) > 0
          and states('sensor.netatmo_huiskamer_humidity')|int(default=0) > 0
          and states('input_boolean.badkamer_douche') == 'on'
          %}true{% else %}false{% endif %}
        value_template: >
          {% set ventilatie = states('sensor.ventilatie_luchtvochtigheid')|float %}
          {% set huiskamer = states('sensor.netatmo_huiskamer_humidity')|float %}
          {{ ([[ ventilatie - [huiskamer, 45] | max, 10] | min, 0] | max / 10 * 200) | round / 2 }}

[Septillion]

@Overspark Je hoeft mij niet te vertellen hoe availability werkt

Maar ik geeft vooral aan dat in 90% van de gevallen HA best al zelf de availability zou kunnen bedenken aan de hand van de bron entiteiten .

Ga ik jouw wel vertellen dat je vorm van template sensor al wel enkele jaren legacy / deprecated is Dus availability_template zou ik zeker niet meer aanraden.

[Overspark]

Septillion schreef op donderdag 12 september 2024 @ 12:39:
@Overspark Je hoeft mij niet te vertellen hoe availability werkt

Maar ik geeft vooral aan dat in 90% van de gevallen HA best al zelf de availability zou kunnen bedenken aan de hand van de bron entiteiten .

Ga ik jouw wel vertellen dat je vorm van template sensor al wel enkele jaren legacy / deprecated is Dus availability_template zou ik zeker niet meer aanraden.

Ja, zoals gezegd is dit een oud voorbeeld wat ik niet meer gebruik, dus idd legacy syntax. Prima als jij weet hoe het werkt maar niet iedereen in dit topic lijkt door te hebben dat HA wel degelijk wat opties biedt om dit makkelijker/duidelijker te maken.

[Devil103]

Even inpikken op Septillion: Ik heb zelf de laatste tijd ook last met duckdns.
Regelmatig zie in Adguard dns query times voorbijkomen van ettelijke seconden.

De WAF klaagt ook dat home assistant niet altijd beschikbaar is vanop afstand.
Ik ben daarom overgeschakeld naar een eigen (sub)domein die dynamisch naar mijn thuisserver wordt gerouteerd.

[matthijs_087]

Na een aantal dagen gestoeid te hebben met een template sensor kom ik er niet helemaal uit. Ik wil op mijn dashboard een markdown kaart hebben welke de verjaardagen voor de eerstvolgende 2 weken weergeeft. De template ziet er als volgt uit:

YAML:

state: >
        {{
          this.attributes.items() 
            | rejectattr('0', 'in', ['icon', 'friendly_name'])
            | selectattr('1')
            | list
            | count
        }}
      icon: mdi:text-box-search-outline
      attributes:
        anniversaries: >-
          {%- set days_to_show = 14 %}
          {%-set ns = namespace(a=[], message=[]) %}
          {%- for item in expand(integration_entities('anniversaries'))
            | selectattr('domain', 'eq', 'sensor')
          %}
            {%- set d_h = item.attributes.get('days_until_half_anniversary', 999) %}
            {%- set h = d_h < item.state | int %}
            {%- set d = [item.state | int, d_h] | min %}
            {%- set c = item.attributes.get('current_years') %}
            {%- set y = c if c else none %}
            {%- set y = y + (0.5 if h else 1 if d != 0 else 0) if y is not none %}
            {%- set ns.a = ns.a + [ dict(n=item.name, d=d, y=y, h=h)] %}
          {%- endfor %}
          {%- for item in ns.a | sort(attribute='d') -%}
            {%- set n, d, y = item.n, item.d, item.y %}
                        {%- if d <= 1 %}
                {%- set ns.message = ns.message + [icon ~ [' Vandaag: ', ' Morgen '][d] ~ n ~ ((' (' ~ y ~ ' jaar)') if y)] %}
            {%- elif d % 7 == 0 and d <= days_to_show %}
              {%- set w = (d / 7) | int %}
                {%- set ns.message = ns.message + [icon ~ ' Over ' ~ w ~ (' week ' if w == 1 else ' weken ') ~ ': ' ~ n ~ ((' (' ~ y ~ ' jaar)') if y)] %}
            {%- elif d <= days_to_show %}
                {%- set ns.message = ns.message + [icon ~ ' Over ' ~ d ~ ' dagen' ~': ' ~ n ~ ((' (' ~ y ~ ' jaar)') if y)] %}
            {%- endif %}
          {%- endfor %}
          {{ dict(message=ns.message | join('\n'), level='info') }}

Ik wil per persoon dit netjes onder elkaar hebben in een markdown kaart , maar wanneer ik deze sensor koppel aan de kaart:

YAML:

type: markdown
content: '{{ states(''sensor.anniversaries'') }}'
title: Verjaardagen

Krijg ik het volgende in tekst op de kaart te zien:
state: >
0
icon: mdi:text-box-search-outline
attributes:
anniversaries: >-
{'message': ' Over 5 dagen: Persoon A Over 6 dagen: Persoon B', 'level': 'info'}

Heeft iemand een idee hoe ik per persoon dit onder elkaar krijg (+ het aantal dagen tot verjaardag voor betreffend persoon)?

[TheFes]

Overspark schreef op donderdag 12 september 2024 @ 12:31:
[...]


Je komt een heel eind met availabillity_template, waarmee je aan kan geven of een template sensor überhaupt available moet zijn. Als je daar alle checks in stops en true of false teruggeeft hoef je er in de rest van je template geen rekening meer mee te houden, dus kan je je template zelf een stuk leesbaarder houden.

Oud voorbeeld wat ik al een tijdje niet meer gebruik:

YAML:

      ventilatie_gewenst_luchtvochtigheid:
        friendly_name: "Ventilatie gewenst luchtvochtigheid"
        unit_of_measurement: "%"
        icon_template: hass:water-percent
        availability_template: >
          {% if states('sensor.ventilatie_luchtvochtigheid')|int(default=0) > 0
          and states('sensor.netatmo_huiskamer_humidity')|int(default=0) > 0
          and states('input_boolean.badkamer_douche') == 'on'
          %}true{% else %}false{% endif %}
        value_template: >
          {% set ventilatie = states('sensor.ventilatie_luchtvochtigheid')|float %}
          {% set huiskamer = states('sensor.netatmo_huiskamer_humidity')|float %}
          {{ ([[ ventilatie - [huiskamer, 45] | max, 10] | min, 0] | max / 10 * 200) | round / 2 }}

Ondanks dat het een oud voorbeeld is wat je niet meer gebruikt, wil ik je toch wel wat tips geven.

In plaats van de states parsen naar integer met default 0 en dan checken of het hoger is dan 0, kun je tegenwoordig has_value gebruiken op het entity_id om te kijken of de entity een valide state geeft. Dus in plaats van states('sensor.ventilatie_luchtvochtigheid')|int(default=0) > 0 kun je 'sensor.ventilatie_luchtvochtigheid' | has_value gebruiken. Een alternatief is om te checken of the state numeriek is met states('sensor.ventilatie_luchtvochtigheid') | is_number.

Verder hoef je niet met een if statement te werken wat true of false teruggeeft, je kunt dat gewoon hetgeen waar je op test als output gebruiken.

Het zou dan dus dit worden (heb ook states() == x aangepast naar is_state()

code:

{{ 'sensor.ventilatie_luchtvochtigheid' | has_value and 'sensor.netatmo_huiskamer_humidity' | has_value and is_state('input_boolean.badkamer_douche', 'on') }}

Voor je state template kun je in plaats van zowel min en max een alternatieve methode kunnen gebruiken. Om te testen of waarde x tussen de 0 en 10 zit, kun je dit gebruiken: ([0, x, 10] | sort)[1].
Als je dan het max filter voor de waarde voor huiskamer al toepast bij het aanmaken van de variable krijg je

code:

{% set ventilatie = states('sensor.ventilatie_luchtvochtigheid') | float %}
{% set huiskamer = [states('sensor.netatmo_huiskamer_humidity') | float, 45] | max %}
{{ (([0, ventilatie - huiskamer, 10] | sort)[1] / 10 * 200) | round / 2 }}

[TheFes]

matthijs_087 schreef op donderdag 12 september 2024 @ 12:53:
Na een aantal dagen gestoeid te hebben met een template sensor kom ik er niet helemaal uit. Ik wil op mijn dashboard een markdown kaart hebben welke de verjaardagen voor de eerstvolgende 2 weken weergeeft. De template ziet er als volgt uit:

YAML:

state: >
        {{
          this.attributes.items() 
            | rejectattr('0', 'in', ['icon', 'friendly_name'])
            | selectattr('1')
            | list
            | count
        }}
      icon: mdi:text-box-search-outline
      attributes:
        anniversaries: >-
          {%- set days_to_show = 14 %}
          {%-set ns = namespace(a=[], message=[]) %}
          {%- for item in expand(integration_entities('anniversaries'))
            | selectattr('domain', 'eq', 'sensor')
          %}
            {%- set d_h = item.attributes.get('days_until_half_anniversary', 999) %}
            {%- set h = d_h < item.state | int %}
            {%- set d = [item.state | int, d_h] | min %}
            {%- set c = item.attributes.get('current_years') %}
            {%- set y = c if c else none %}
            {%- set y = y + (0.5 if h else 1 if d != 0 else 0) if y is not none %}
            {%- set ns.a = ns.a + [ dict(n=item.name, d=d, y=y, h=h)] %}
          {%- endfor %}
          {%- for item in ns.a | sort(attribute='d') -%}
            {%- set n, d, y = item.n, item.d, item.y %}
                        {%- if d <= 1 %}
                {%- set ns.message = ns.message + [icon ~ [' Vandaag: ', ' Morgen '][d] ~ n ~ ((' (' ~ y ~ ' jaar)') if y)] %}
            {%- elif d % 7 == 0 and d <= days_to_show %}
              {%- set w = (d / 7) | int %}
                {%- set ns.message = ns.message + [icon ~ ' Over ' ~ w ~ (' week ' if w == 1 else ' weken ') ~ ': ' ~ n ~ ((' (' ~ y ~ ' jaar)') if y)] %}
            {%- elif d <= days_to_show %}
                {%- set ns.message = ns.message + [icon ~ ' Over ' ~ d ~ ' dagen' ~': ' ~ n ~ ((' (' ~ y ~ ' jaar)') if y)] %}
            {%- endif %}
          {%- endfor %}
          {{ dict(message=ns.message | join('\n'), level='info') }}

Ik wil per persoon dit netjes onder elkaar hebben in een markdown kaart , maar wanneer ik deze sensor koppel aan de kaart:

YAML:

type: markdown
content: '{{ states(''sensor.anniversaries'') }}'
title: Verjaardagen

Krijg ik het volgende in tekst op de kaart te zien:
state: >
0
icon: mdi:text-box-search-outline
attributes:
anniversaries: >-
{'message': ' Over 5 dagen: Persoon A Over 6 dagen: Persoon B', 'level': 'info'}

Heeft iemand een idee hoe ik per persoon dit onder elkaar krijg (+ het aantal dagen tot verjaardag voor betreffend persoon)?

Haha, ik herken wel waar je dit template vandaan gehaald hebt

Echter, dat template is de volledige YAML voor een template aangemaakt in de configuration.yaml (of een included YAML file). Jij hebt het zo te zien in een template helper geplakt, wat zo niet werkt.
Op zich hoef je er niet eens een template sensor voor aan te maken, je kunt het in de markdown card zelf helemaal oplossen.

Dit in een markdown card zal de verjaardagen van de komende 14 dagen weergeven

Django/Jinja:

{%- set days_to_show = 14 %}
{%-set ns = namespace(a=[], message=[]) %}
{%- for item in expand(integration_entities('anniversaries'))
  | selectattr('domain', 'eq', 'sensor')
%}
  {%- set d_h = item.attributes.get('days_until_half_anniversary', 999) %}
  {%- set h = d_h < item.state | int %}
  {%- set d = [item.state | int, d_h] | min %}
  {%- set c = item.attributes.get('current_years') %}
  {%- set y = c if c else none %}
  {%- set y = y + (0.5 if h else 1 if d != 0 else 0) if y is not none %}
  {%- set ns.a = ns.a + [ dict(n=item.name, d=d, y=y, h=h)] %}
{%- endfor %}
{%- for item in ns.a | sort(attribute='d') -%}
  {%- set n, d, y = item.n, item.d, item.y %}
              {%- if d <= 1 %}
      {%- set ns.message = ns.message + [[' Vandaag: ', ' Morgen '][d] ~ n ~ ((' (' ~ y ~ ' jaar)') if y)] %}
  {%- elif d % 7 == 0 and d <= days_to_show %}
    {%- set w = (d / 7) | int %}
      {%- set ns.message = ns.message + [' Over ' ~ w ~ (' week ' if w == 1 else ' weken ') ~ ': ' ~ n ~ ((' (' ~ y ~ ' jaar)') if y)] %}
  {%- elif d <= days_to_show %}
      {%- set ns.message = ns.message + [' Over ' ~ d ~ ' dagen' ~': ' ~ n ~ ((' (' ~ y ~ ' jaar)') if y)] %}
  {%- endif %}
{%- endfor %}
{{ ns.message | join('\n') }}

[Just_A_User]

Goed, ik heb maar weer eens vraag, eigenlijk 2. Ik heb een EV, een Tesla. Ik lees die auto uit met Teslemetry. Dat levert me een aantal sensoren op, onder andere charge_energy_added. Die laat zien hoeveel de auto vindt dat er bij de meest recente laadsessie (live) wordt toegevoegd.

De laatste laadsessie liet die sensor bijvoorbeeld 10,7 kWh zien. Ik heb dan ook nog een display op de laadpaal zelf, waar 11,37 kWh op te zien was. Ik snap dat er een verschil zit want laadverliezen blabla. Vind ik prima, want ik kan niet inprikken op de laadpaal, want die is door werkgever beschikbaar gesteld en is voor mij simpelweg niet toegankelijk, dus wat de auto me verteld is dan de next best thing.

Maar zoals bij alles, wil ik graag zaken bijhouden per dag, maand, jaar en totaal. Ik heb óók een sensor 'vermogen'. Dus als ik laad met 5 kW vermogen, dan zegt dat ding '5 kW'. Ik gebruik dié sensor om een nuts meter op te maken, om zo te laten zien hoeveel kWh er geladen is in de auto.

Dat is waar het probleem ontstaat, want waar de eerder genoemde sensor 10,7 kWh laat zien, daar laat deze 2e sensor voor diezelfde meest recente laadsessie 52 kW zien. Dus niét 5,2 kWh.

Vraag 1; hoe krijg ik dat ding zo ver dat hij rapporteert in kWh, en niet in kW.
Vraag 2; Wat doe ik fout, want ik zou namelijk verwachten dat het getal wat daar vermeldt wordt min of meer gelijk is aan wat charge_energy_added laat zien, maar het wijkt volledig af?

Waarom gebruik ik dié sensor voor die nutsmeter? Omdat ik er vanuit ga dat het hetzelfde werkt als bij een fibaro tussenstekker. Als ik daar zo'n nutsmeter op doe en die stekker registreert een uur lang 500 watt verbruik, dan zal mijn nutsmeter voor 'verbruik vandaag' 0,5 kWh laten zien. Maar 10,7 kWh tegenover 52 kW....daar gaat iets niet goed.

[matthijs_087]

TheFes schreef op donderdag 12 september 2024 @ 13:14:
[...]


Haha, ik herken wel waar je dit template vandaan gehaald hebt

Echter, dat template is de volledige YAML voor een template aangemaakt in de configuration.yaml (of een included YAML file). Jij hebt het zo te zien in een template helper geplakt, wat zo niet werkt.
Op zich hoef je er niet eens een template sensor voor aan te maken, je kunt het in de markdown card zelf helemaal oplossen.

Dit in een markdown card zal de verjaardagen van de komende 14 dagen weergeven

Django/Jinja:

{%- set days_to_show = 14 %}
{%-set ns = namespace(a=[], message=[]) %}
{%- for item in expand(integration_entities('anniversaries'))
  | selectattr('domain', 'eq', 'sensor')
%}
  {%- set d_h = item.attributes.get('days_until_half_anniversary', 999) %}
  {%- set h = d_h < item.state | int %}
  {%- set d = [item.state | int, d_h] | min %}
  {%- set c = item.attributes.get('current_years') %}
  {%- set y = c if c else none %}
  {%- set y = y + (0.5 if h else 1 if d != 0 else 0) if y is not none %}
  {%- set ns.a = ns.a + [ dict(n=item.name, d=d, y=y, h=h)] %}
{%- endfor %}
{%- for item in ns.a | sort(attribute='d') -%}
  {%- set n, d, y = item.n, item.d, item.y %}
              {%- if d <= 1 %}
      {%- set ns.message = ns.message + [[' Vandaag: ', ' Morgen '][d] ~ n ~ ((' (' ~ y ~ ' jaar)') if y)] %}
  {%- elif d % 7 == 0 and d <= days_to_show %}
    {%- set w = (d / 7) | int %}
      {%- set ns.message = ns.message + [' Over ' ~ w ~ (' week ' if w == 1 else ' weken ') ~ ': ' ~ n ~ ((' (' ~ y ~ ' jaar)') if y)] %}
  {%- elif d <= days_to_show %}
      {%- set ns.message = ns.message + [' Over ' ~ d ~ ' dagen' ~': ' ~ n ~ ((' (' ~ y ~ ' jaar)') if y)] %}
  {%- endif %}
{%- endfor %}
{{ ns.message | join('\n') }}

Hartelijk dank! Heb het één en ander van chatGPT, maar heb ook veel aan jouw config gehad idd .

[TheFes]

Just_A_User schreef op donderdag 12 september 2024 @ 13:18:
Goed, ik heb maar weer eens vraag, eigenlijk 2. Ik heb een EV, een Tesla. Ik lees die auto uit met Teslemetry. Dat levert me een aantal sensoren op, onder andere charge_energy_added. Die laat zien hoeveel de auto vindt dat er bij de meest recente laadsessie (live) wordt toegevoegd.

De laatste laadsessie liet die sensor bijvoorbeeld 10,7 kWh zien. Ik heb dan ook nog een display op de laadpaal zelf, waar 11,37 kWh op te zien was. Ik snap dat er een verschil zit want laadverliezen blabla. Vind ik prima, want ik kan niet inprikken op de laadpaal, want die is door werkgever beschikbaar gesteld en is voor mij simpelweg niet toegankelijk, dus wat de auto me verteld is dan de next best thing.

Maar zoals bij alles, wil ik graag zaken bijhouden per dag, maand, jaar en totaal. Ik heb óók een sensor 'vermogen'. Dus als ik laad met 5 kW vermogen, dan zegt dat ding '5 kW'. Ik gebruik dié sensor om een nuts meter op te maken, om zo te laten zien hoeveel kWh er geladen is in de auto.

Dat is waar het probleem ontstaat, want waar de eerder genoemde sensor 10,7 kWh laat zien, daar laat deze 2e sensor voor diezelfde meest recente laadsessie 52 kW zien. Dus niét 5,2 kWh.

Vraag 1; hoe krijg ik dat ding zo ver dat hij rapporteert in kWh, en niet in kW.
Vraag 2; Wat doe ik fout, want ik zou namelijk verwachten dat het getal wat daar vermeldt wordt min of meer gelijk is aan wat charge_energy_added laat zien, maar het wijkt volledig af?

Waarom gebruik ik dié sensor voor die nutsmeter? Omdat ik er vanuit ga dat het hetzelfde werkt als bij een fibaro tussenstekker. Als ik daar zo'n nutsmeter op doe en die stekker registreert een uur lang 500 watt verbruik, dan zal mijn nutsmeter voor 'verbruik vandaag' 0,5 kWh zien. Maar 10,7 kWh tegenover 52 kW....daar gaat iets niet goed.

Je kunt power ((k)W) niet zomaar vergelijken met energy ((k)Wh).
power kun je vergelijken met de snelheid van je auto op je dashboard. Dat is een momentopname, je kunt de ene keer wellicht 100km/h rijden, maar als je dan de bebouwde kom in rijdt ga je terug naar 50km/h.
Energie is te vergelijken met de afstandsmeter op je auto, die loopt alleen maar op. Als je van Tilburg naar Amsterdam rijdt, begint hij bijvoorbeeld op 1234 km, en loopt hij tijdens de rit op naar 1345 km.

Dat laatste, die afstand, is makkelijk te vatten in een nutsmeter, maar die snelheid niet. Dit gezien die continu anders is. Je kunt de snelheid wel omzetten naar afgelegde afstand, maar dan moet je dus weten hoe lang je op die snelheid gereden hebt, als je bijvoorbeeld een half uur 100km/u rijdt, en daarna een half uur 50 km/u, dan heb je dus 0.5u * 100 km/h + 0.5u * 50km/h = 75km afgelegd

Dat laatste kan in HA ook, met een Riemann Sum integral. Die kun je vinden onder Helpers. Dat zal dus de waarde in (k)W omzetten naar een waarde in (k)Wh door te kijken hoe lang je sensor op een bepaalde W waarde heeft gestaan. De output daarvan kun je dan dus in een nutsmeter gebruiken. Je kunt dan het beste de linker integral methode gebruiken.

offtopic:
Het lijkt een beetje verwarrend dat bij km/h de uren bij de snelheid staan, terwijl ze bij power/energy juist bij energy staan. Maar bij power/energy is het dus W*h waar je bij snelheid/afstand deelt door uren.
Maar als je power ziet als Wh per uur, krijg je W*h/h wat dus gewoon W is

[Just_A_User]

TheFes schreef op donderdag 12 september 2024 @ 13:33:
[...]


Je kunt power ((k)W) niet zomaar vergelijken met energy ((k)Wh).
power kun je vergelijken met de snelheid van je auto op je dashboard. Dat is een momentopname, je kunt de ene keer wellicht 100km/h rijden, maar als je dan de bebouwde kom in rijdt ga je terug naar 50km/h.
Energie is te vergelijken met de afstandsmeter op je auto, die loopt alleen maar op. Als je van Tilburg naar Amsterdam rijdt, begint hij bijvoorbeeld op 1234 km, en loopt hij tijdens de rit op naar 1345 km.

Dat laatste, die afstand, is makkelijk te vatten in een nutsmeter, maar die snelheid niet. Dit gezien die continu anders is. Je kunt de snelheid wel omzetten naar afgelegde afstand, maar dan moet je dus weten hoe lang je op die snelheid gereden hebt, als je bijvoorbeeld een half uur 100km/u rijdt, en daarna een half uur 50 km/u, dan heb je dus 0.5u * 100 km/h + 0.5u * 50km/h = 75km afgelegd

Dat laatste kan in HA ook, met een Riemann Sum integral. Die kun je vinden onder Helpers. Dat zal dus de waarde in W omzetten naar een waarde in kWh door te kijken hoe lang je sensor op een bepaalde W waarde heeft gestaan. De output daarvan kun je dan dus in een nutsmeter gebruiken. Je kunt dan het beste de linker integral methode gebruiken.

offtopic:
Het lijkt een beetje verwarrend dat bij km/h de uren bij de snelheid staan, terwijl ze bij power/energy juist bij energy staan. Maar bij power/energy is het dus W*h waar je bij snelheid/afstand deelt door uren.
Maar als je power ziet als Wh per uur, krijg je W*h/h wat dus gewoon W is

Ah, kijk aan, ik ga eens even wat prutsen. Dank voor de uitleg.

[Septillion]

@Just_A_User En als die sensor met vermogen ook uit de auto komt zal het me verbazen als je hiermee een andere totale energie krijgt.

Alternatief zou zijn zelf een meter tussen de laadpaal en de meterkast (/ in de meterkast) te monteren. Helaas zijn 3-fase meters wat beperkt en duur.

[Just_A_User]

TheFes schreef op donderdag 12 september 2024 @ 13:33:
[...]


Je kunt power ((k)W) niet zomaar vergelijken met energy ((k)Wh).
power kun je vergelijken met de snelheid van je auto op je dashboard. Dat is een momentopname, je kunt de ene keer wellicht 100km/h rijden, maar als je dan de bebouwde kom in rijdt ga je terug naar 50km/h.
Energie is te vergelijken met de afstandsmeter op je auto, die loopt alleen maar op. Als je van Tilburg naar Amsterdam rijdt, begint hij bijvoorbeeld op 1234 km, en loopt hij tijdens de rit op naar 1345 km.

Dat laatste, die afstand, is makkelijk te vatten in een nutsmeter, maar die snelheid niet. Dit gezien die continu anders is. Je kunt de snelheid wel omzetten naar afgelegde afstand, maar dan moet je dus weten hoe lang je op die snelheid gereden hebt, als je bijvoorbeeld een half uur 100km/u rijdt, en daarna een half uur 50 km/u, dan heb je dus 0.5u * 100 km/h + 0.5u * 50km/h = 75km afgelegd

Dat laatste kan in HA ook, met een Riemann Sum integral. Die kun je vinden onder Helpers. Dat zal dus de waarde in (k)W omzetten naar een waarde in (k)Wh door te kijken hoe lang je sensor op een bepaalde W waarde heeft gestaan. De output daarvan kun je dan dus in een nutsmeter gebruiken. Je kunt dan het beste de linker integral methode gebruiken.

offtopic:
Het lijkt een beetje verwarrend dat bij km/h de uren bij de snelheid staan, terwijl ze bij power/energy juist bij energy staan. Maar bij power/energy is het dus W*h waar je bij snelheid/afstand deelt door uren.
Maar als je power ziet als Wh per uur, krijg je W*h/h wat dus gewoon W is

Maar dan heb ik toch het volgende probleem. Dus ik heb een Left Riemann aangemaakt, en dan moet je kiezen wat je wil, dus ik heb gekozen voor K(ilo) en h(our). Nou, ik heb de correcte sensor gebruikt om hem aan te maken, maar dan héb ik hem vervolgens aangemaakt, en dan kijk ik naar die sensor, en dan zie ik dit:



kkWh? Dat lijkt me niet helemaal goed...?

[TheFes]

Just_A_User schreef op donderdag 12 september 2024 @ 14:02:
[...]


Maar dan heb ik toch het volgende probleem. Dus ik heb een Left Riemann aangemaakt, en dan moet je kiezen wat je wil, dus ik heb gekozen voor K(ilo) en h(our). Nou, ik heb de correcte sensor gebruikt om hem aan te maken, maar dan héb ik hem vervolgens aangemaakt, en dan kijk ik naar die sensor, en dan zie ik dit:

[Afbeelding]

kkWh? Dat lijkt me niet helemaal goed...?

Is je bronsensor al in kW? Dan moet je geen kilo kiezen, maar gewoon leeg houden. Je krijgt dan inderdaal k*k*W*h is dus eigenlijk MWh

[Just_A_User]

TheFes schreef op donderdag 12 september 2024 @ 14:05:
[...]

Is je bronsensor al in kW? Dan moet je geen kilo kiezen, maar gewoon leeg houden. Je krijgt dan inderdaal k*k*W*h is dus eigenlijk MWh

Ik heb hem opnieuw gemaakt, en inderdaad, nu is het, zonder kilo te kiezen, wél netjes kWh.

[HuismAndré]

Ferra schreef op donderdag 12 september 2024 @ 07:16:
Kan het casten naar een Google Nest Hub nog steeds?

Jazeker. Hier bijvoorbeeld een scriptje waarmee je het lovelace dashboard kunt casten:

YAML:

alias: Cast Dashboard
sequence:
  - data:
      entity_id: media_player.huiskamer_nest
      dashboard_path: lovelace
      view_path: default_view
    action: cast.show_lovelace_view
mode: single
icon: mdi:monitor-dashboard

[Just_A_User]

Hoe krijg ik meerdere van dit soort elementen op een kaart? Dit is afkomstig van het iOS Dark Mode Theme in HACS, en ik vind dat theme sowieso mooi, maar hoe krijg ik meerdere info elementen op 1 zo'n kaartje? Kan dat altijd of is dat een mogelijkheid die zit ingebakken in dat theme?

[The Executer]

The Executer schreef op donderdag 12 september 2024 @ 00:00:
[...]
Moet alleen nog weer naar mijn optelsom kijken, die klopt toch nog niet. Zal morgen even de 3 waardes waar ik mee reken even controleren tegenover het energie-dashboard want ergens krijgt iets niet een goede waarde mee.

Energie Dashboard:
Opgewekt: 10,4kWh
Totaal stroomverbruik 8,1kWh

Eigen dashboard:
Opgewekt: 10,4kWh (dus deze klopt)
Totale verbruiksmeter vandaag: 10,2kWh (hier gaat dus iets mis).

Zojuist eens even in de rekensom gedoken. Wat blijkt... De afzonderlijke waardes uit de entiteiten kloppen. De code:

YAML:

    ## Netto verbruik vandaag na saldering
    - name: "energy.today.used"
      unique_id: energy.today.used
      unit_of_measurement: kWh
      state: "{{ states('sensor.energy_today_usedfromgrid')|float - states('sensor.energy_today_returnedtogrid')|float + states('sensor.daily_energy_produced')|float }}"

De waardes:
sensor.energy_today_usedfromgrid: 2,299 kWh
sensor.energy_today_returnedtogrid: 3,299 kWh
sensor.daily_energy_produced: 5.747 Wh

Dan krijg je de som (Even afgerond): 2.3 -3.3 + 5.7 = 4.7.

Energiedashboard is het daar aardig mee eens:


Wat geeft sensor.energy.today.used? 5.774,007 kWh. En nee, dit is geen waarde van 1 van de telwerken van de meter ofzo .

[ Voor 4% gewijzigd door The Executer op 12-09-2024 15:23 ]

[TheFes]

The Executer schreef op donderdag 12 september 2024 @ 15:23:
[...]


Zojuist eens even in de rekensom gedoken. Wat blijkt... De afzonderlijke waardes uit de entiteiten kloppen. De code:

YAML:

    ## Netto verbruik vandaag na saldering
    - name: "energy.today.used"
      unique_id: energy.today.used
      unit_of_measurement: kWh
      state: "{{ states('sensor.energy_today_usedfromgrid')|float - states('sensor.energy_today_returnedtogrid')|float + states('sensor.daily_energy_produced')|float }}"

De waardes:
sensor.energy_today_usedfromgrid: 2,299 kWh
sensor.energy_today_returnedtogrid: 3,299 kWh
sensor.daily_energy_produced: 5.747 Wh

Dan krijg je de som (Even afgerond): 2.3 -3.3 + 5.7 = 4.7.

Energiedashboard is het daar aardig mee eens:
[Afbeelding]

Wat geeft sensor.energy.today.used? 5.774,007 kWh. En nee, dit is geen waarde van 1 van de telwerken van de meter ofzo .

Je hebt geen availability op die sensor? Of heb je die weggelaten voor nu?

Het probleem zal zitten in de update frequentie. Stel, used staat op 2.2, en returned verandert van 3.2 naar 3.3. Op dat moment wordt de waarde van je template sensor lager dan hij was. Dat is natuurlijk vreemd voor een energy sensor, die normaal oplopend is. De utility meter zal dit zien als een sensor die gereset is, en het geheel weer optellen bij de oude waarde.
(of je hebt je utility meter sowieso geconfigureerd om elke waarde als een delta te zien).

Je kunt wellicht beter dagelijkse utlity meters aanmaken op de bronsensoren, en dan een template sensor op de dagelijkse utility meters.

[ Voor 4% gewijzigd door TheFes op 12-09-2024 15:46 ]

[Toppe]

Ik ben even ruzie aan het maken met Node-Red en MQTT richting Home Assistant.

Doel: Een sensor automatisch in Home-Assistant laten opnemen.

Ik ben verplicht om de MQTT flow route te gebruiken aangezien ik geen pallete kan installeren.

Nieuwe sensor:

YAML:

sensor:
  - name: milesight
    state_topic: sensors/milesight
    value_template: "{{ value_json.temp | int }}"

Een inject gemaakt in Node-Red met de payload:

JSON:

{
    "temp": 28
}

en een MQTT out node met het volgende topic:
sensors/milesight

In mn MQTT explorer komt hij netjes voor bij, maar de sensor doet in HA helemaal niets.

Iemand een werkende flow zonder HA pallete?

[jvanderkroon]

Just_A_User schreef op donderdag 12 september 2024 @ 15:11:
[Afbeelding]

Hoe krijg ik meerdere van dit soort elementen op een kaart?

Ik gok dat ze dat met https://github.com/custom-cards/stack-in-card hebben gedaan.

[Just_A_User]

jvanderkroon schreef op donderdag 12 september 2024 @ 15:59:
[...]


Ik gok dat ze dat met https://github.com/custom-cards/stack-in-card hebben gedaan.

Die heb ik geinstalleerd zojuist, vanuit HACS, maar ik weet nu niet hoe ik 'm moet gebruiken.

[verjager]

@The Executer Zijn alle eenheden van je bronsensors wel gelijk?
De uitkomst lijkt een beetje op 2.3-3.3+5747=5746.

In je waardes vermeld je getallen met een , en een . en ook verschillende eenheden kWh en Wh.

[rkonings]

Just_A_User schreef op donderdag 12 september 2024 @ 16:24:
[...]


Die heb ik geinstalleerd zojuist, vanuit HACS, maar ik weet nu niet hoe ik 'm moet gebruiken.

deze al gevonden?
https://community.home-as...l-stack-in-card/180072/15

[Just_A_User]

rkonings schreef op donderdag 12 september 2024 @ 16:26:
[...]


deze al gevonden?
https://community.home-as...l-stack-in-card/180072/15

Vanwege de problemen met dat ding? Nee, had ik nog niet gevonden, maar ik ben hier zó niet in thuis dat het me ook niet veel zegt.

[TheFes]

Toppe schreef op donderdag 12 september 2024 @ 15:52:
Ik ben even ruzie aan het maken met Node-Red en MQTT richting Home Assistant.

Doel: Een sensor automatisch in Home-Assistant laten opnemen.

Ik ben verplicht om de MQTT flow route te gebruiken aangezien ik geen pallete kan installeren.

Nieuwe sensor:

YAML:

sensor:
  - name: milesight
    state_topic: sensors/milesight
    value_template: "{{ value_json.temp | int }}"

Een inject gemaakt in Node-Red met de payload:

JSON:

{
    "temp": 28
}

en een MQTT out node met het volgende topic:
sensors/milesight

In mn MQTT explorer komt hij netjes voor bij, maar de sensor doet in HA helemaal niets.

Iemand een werkende flow zonder HA pallete?

Als je wil dat HA dat automatisch oppakt moet je een autodiscovery topic aanmaken, maar je kunt ook handmatig een MQTT sensor aanmaken met dat topic als bron.
Excuus, je hebt al een mqtt sensor aangemaakt (dat had ik een gemist omdat de mqtt: ontbrak)

[ Voor 5% gewijzigd door TheFes op 12-09-2024 16:40 ]

[Ben-i]

Septillion schreef op donderdag 12 september 2024 @ 12:14:
@Ben-i Opnieuw beginnen kan een keuze zijn maar een backup is ook gewoon over te zetten.

Als je echt meer dingen ernaast wilt draaien is Proxmox daar wel makkelijk voor. Hele installatie viel mij erg mee.

Zelf draai ik het geheel ook op een N100 met 16GB. Voor HA alleen qua geheugen wel overkill maar de N100 is wel fijn. Mar zeker als je ook video en transcoden wilt gaan doen is het zeker geen overbodige luxe. Dus die HP zou ik dan niet doen. Ook qua stroomverbruik zal het aardig schelen.

Wel hoor ik de laatste tijd wat vaker dat DuckDNS wat loopt te bokken. Zou hier ook wel eens de reden kunnen zijn...

Even een back up terug zetten is natuurlijk het makkelijkst, maar ik heb best wat lopen "pielen" en aanklooien met addons en met codes in de yaml waar ik eigenlijk geen verstand van heb, dat het misschien maar verstandiger is om schoon te beginnen.
Zal eens kijken wat ik kan vinden over duckdns, thanks voor je input.

[Just_A_User]

jvanderkroon schreef op donderdag 12 september 2024 @ 15:59:
[...]


Ik gok dat ze dat met https://github.com/custom-cards/stack-in-card hebben gedaan.

Is het daadwerkelijk de stack-in-card die daarvoor gebruikt is? Dat ding is uit 2020, ik kan me niet voorstellen dat daar inmiddels niet een andere oplossing voor is?

[Septillion]

@The Executer HA regelt in een template niet opeens de conversie voor je

Dus als je de PV in Wh mee wilt nemen in een optel waar je kWh uit wilt hebben zal je de waarde dus zelf even moeten omzetten naar kWh aka delen door 1000

YAML:

    ## Netto verbruik vandaag na saldering
    - name: "energy.today.used"
      unique_id: energy.today.used
      unit_of_measurement: kWh
      state: >-
        {{ states('sensor.energy_today_usedfromgrid')|float
          - states('sensor.energy_today_returnedtogrid')|float 
          + (states('sensor.daily_energy_produced')|float / 1000) }}
      availability: >-
        {{ states('sensor.energy_today_usedfromgrid')|is_number
          and states('sensor.energy_today_returnedtogrid')|is_number
          and states('sensor.daily_energy_produced')|is_number) }}

[Just_A_User]

Ik snap hier niks van. Ik heb dus een nuts meter gemaakt die netjes het verbruik van vandaag laat zien voor wat ik in de auto heb geladen, en eerder liet ie dat zien in kW, en dat was niet goed. Met hulp van @TheFes is het gelukt om er kWh van te maken.

Om dat te doen heb ik een Riemann Left dinges gemaakt, en dat is dan weer de basis voor mijn Nutsmeter om hem te resetten na 0.00u. Werkt prima, wordt ook gerapporteerd in kWh.

Nu maak ik net een 2e Nutsmeter, met als enige verschil niet een daily cycle maar een monthly cycle, en dan ben ik weer terug bij kW?

[Septillion]

Toppe schreef op donderdag 12 september 2024 @ 15:52:
Ik ben even ruzie aan het maken met Node-Red en MQTT richting Home Assistant.

Doel: Een sensor automatisch in Home-Assistant laten opnemen.

Ik ben verplicht om de MQTT flow route te gebruiken aangezien ik geen pallete kan installeren.

Nieuwe sensor:

YAML:

sensor:
  - name: milesight
    state_topic: sensors/milesight
    value_template: "{{ value_json.temp | int }}"

Een inject gemaakt in Node-Red met de payload:

JSON:

{
    "temp": 28
}

en een MQTT out node met het volgende topic:
sensors/milesight

In mn MQTT explorer komt hij netjes voor bij, maar de sensor doet in HA helemaal niets.

Iemand een werkende flow zonder HA pallete?

Als ik die sensor hier toevoeg werkt het direct.

Weet je zeker dat je via NR hem post in sensors/milesight en niet bijvoorbeeld in sensors/milesight/ ?

[Septillion]

@Just_A_User Een nutsmeter neemt gewoon unit over van de bron. Dus gokje, je selecteert niet de entity van de riemann som maar die van de power.

[Toppe]

Septillion schreef op donderdag 12 september 2024 @ 17:35:
[...]

Als ik die sensor hier toevoeg werkt het direct.

Weet je zeker dat je via NR hem post in sensors/milesight en niet bijvoorbeeld in sensors/milesight/ ?

Hm, zal straks eens kijken of het echt een typo is

[Just_A_User]

Septillion schreef op donderdag 12 september 2024 @ 17:37:
@Just_A_User Een nutsmeter neemt gewoon unit over van de bron. Dus gokje, je selecteert niet de entity van de riemann som maar die van de power.

Dit is mijn Riemann:



Deze is in kWh. Vervolgens maak ik een Tesla - Dagelijks aan en die gebruikt die Tesla Verbruik. Die rapporteert ook mooi in kWh:



Vervolgens maak ik een nieuwe nutsmeter aan, Tesla - Maandelijks; waarbij ik wederom Tesla Verbruik gebruik als bron, die in kWh rapporteert, en ik krijg kW:



Als ik dan kijk naar de instellingen van dat ding, dan zie ik dit:



Daar staat toch echt kW, en geen mogelijkheid om dat om te zetten naar kWh, ik kan kiezen uit kW, of W.

[TheFes]

Just_A_User schreef op donderdag 12 september 2024 @ 17:51:
[...]


Dit is mijn Riemann:

[Afbeelding]

Deze is in kWh. Vervolgens maak ik een Tesla - Dagelijks aan en die gebruikt die Tesla Verbruik. Die rapporteert ook mooi in kWh:

[Afbeelding]

Vervolgens maak ik een nieuwe nutsmeter aan, Tesla - Maandelijks; waarbij ik wederom Tesla Verbruik gebruik als bron, die in kWh rapporteert, en ik krijg kW:

[Afbeelding]

Als ik dan kijk naar de instellingen van dat ding, dan zie ik dit:

[Afbeelding]

Daar staat toch echt kW, en geen mogelijkheid om dat om te zetten naar kWh, ik kan kiezen uit kW, of W.

En wat staat er bij die maandelijkse bij de nutsmeter opties?

[Septillion]

@Just_A_User Laat je precies het belangrijkste scherm niet zien, de bron sensor

[edit]Spuit 11....

[Just_A_User]

TheFes schreef op donderdag 12 september 2024 @ 17:52:
[...]


En wat staat er bij die maandelijkse bij de nutsmeter opties?

Dit:

[TheFes]

Just_A_User schreef op donderdag 12 september 2024 @ 17:54:
[...]


Dit:

[Afbeelding]

Had je dit maandelijkse sensor wellicht al eerder aangemaakt op basis van de verkeerde sensor? Ik vermoed dat daar iets fout gaat. Verwijder deze eens een maak hem opnieuw aan, maar dan met een andere naam, bijvoorbeeld "Tesla - Per maand"

[Just_A_User]

TheFes schreef op donderdag 12 september 2024 @ 17:59:
[...]


Had je dit maandelijkse sensor wellicht al eerder aangemaakt op basis van de verkeerde sensor? Ik vermoed dat daar iets fout gaat. Verwijder deze eens een maak hem opnieuw aan, maar dan met een andere naam, bijvoorbeeld "Tesla - Per maand"

Ja, dat heb ik. Ik ga dat even doen.

Gedaan; tesla_maandelijks_laden en die vindt nu dat het 'onbekend' is. Dat is in ieder geval geen kW, maar het is ook (nog) geen kWh.

[ Voor 14% gewijzigd door Just_A_User op 12-09-2024 18:02 ]

[TheFes]

Just_A_User schreef op donderdag 12 september 2024 @ 18:00:
[...]


Ja, dat heb ik. Ik ga dat even doen.

Gedaan; tesla_maandelijks_laden en die vindt nu dat het 'onbekend' is. Dat is in ieder geval geen kW, maar het is ook (nog) geen kWh.

Een nutsmeter heeft een state change van de bron sensor nodig voor hij werkt

[Just_A_User]

TheFes schreef op donderdag 12 september 2024 @ 18:30:
[...]


Een nutsmeter heeft een state change van de bron sensor nodig voor hij werkt

Ja, dat gaat dan pas morgen of zaterdag zijn als ik weer ga laden, dan denk ik dat het nu wel goed komt Thanks again.

[Toppe]

Septillion schreef op donderdag 12 september 2024 @ 17:35:
[...]

Als ik die sensor hier toevoeg werkt het direct.

Weet je zeker dat je via NR hem post in sensors/milesight en niet bijvoorbeeld in sensors/milesight/ ?

Vraag me niet hoe, maar na een herstart van HA werkt het wel.

[belly89]

Ik heb een nutsmeter die de tijd weergeeft dat een switch aan is geweest vandaag. Nu wil ik graag een sensor maken die berekend wat de totale tijd aan is als hij vanaf nu continu aan staat.

Dus
Switch heeft 2 uur aangestaan
Huidige tijd is 22:00 uur, dus nog 2 uur resterend die dag
Sensor geeft dan 4 uur aan (2 uur aan geweest + 2 uur resterend)

Ik heb al flink zitten zoeken maar kan het niet vinden. Iemand die mij in de juiste richting kan helpen

[marnie]

belly89 schreef op vrijdag 13 september 2024 @ 09:43:
Ik heb een nutsmeter die de tijd weergeeft dat een switch aan is geweest vandaag. Nu wil ik graag een sensor maken die berekend wat de totale tijd aan is als hij vanaf nu continu aan staat.

Dus
Switch heeft 2 uur aangestaan
Huidige tijd is 22:00 uur, dus nog 2 uur resterend die dag
Sensor geeft dan 4 uur aan (2 uur aan geweest + 2 uur resterend)

Ik heb al flink zitten zoeken maar kan het niet vinden. Iemand die mij in de juiste richting kan helpen

Mijn warmtepomp bedrijfsuren in sensor.yaml vanaf 9 augustus gemeten, zie ook https://www.home-assistant.io/integrations/history_stats/.

YAML:

- platform: history_stats
  name: "WP bedrijfsuren"
  unique_id: wp_bedrijfsuren
  entity_id: switch.adlar_warmtepomp_wp_hoofdschakelaar
  state: "on" 
  type: time
  start: '2024-08-09 00:00:00+00:00'
  end: '{{ now() }}'

[RudolfR]

@belly89

Je kunt wel een timedelta bij je end: opgeven, maar ik kan me voorstellen dat dat niet werkt.

YAML:

- platform: history_stats
  name: Home Battery charger cycles today
  unique_id: 2e6f416b-7c49-488e-aa4b-61657b6ca2c1
  entity_id: switch.bw_shp_13_1
  state: "on"
  type: count
  start: "{{ today_at() }}"
  end: "{{ today_at() + timedelta(1) }}"

Ik zou met een template sensor het aantal resterende uren van de dag uitrekenen en dat er zelf bij optellen.

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

[belly89]

marnie schreef op vrijdag 13 september 2024 @ 09:56:
[...]

Mijn warmtepomp bedrijfsuren in sensor.yaml vanaf 9 augustus gemeten, zie ook https://www.home-assistant.io/integrations/history_stats/.

YAML:

- platform: history_stats
  name: "WP bedrijfsuren"
  unique_id: wp_bedrijfsuren
  entity_id: switch.adlar_warmtepomp_wp_hoofdschakelaar
  state: "on" 
  type: time
  start: '2024-08-09 00:00:00+00:00'
  end: '{{ now() }}'

Die is niet helemaal wat ik bedoel, gaat juist dat hij de bedrijfsuren optelt met de nog te resterende tijd van deze dag. Dus elke dag weer opnieuw. De nutsmeter reset al elke dag dus kan hiervoor als basis gebruikt worden.

RudolfR schreef op vrijdag 13 september 2024 @ 10:13:
@belly89

Je kunt wel een timedelta bij je end: opgeven, maar ik kan me voorstellen dat dat niet werkt.

code:

- platform: history_stats
  name: Home Battery charger cycles today
  unique_id: 2e6f416b-7c49-488e-aa4b-61657b6ca2c1
  entity_id: switch.bw_shp_13_1
  state: "on"
  type: count
  start: "{{ today_at() }}"
  end: "{{ today_at() + timedelta(1) }}"

Ik zou met een template sensor het aantal resterende uren van de dag uitrekenen en dat er zelf bij optellen.

De vraag is inderdaad hoe ik een template sensor kan aanmaken die de resterende uren van de dag berekend, hier kom ik niet uit

[Septillion]

@belly89 Een template met tijd tot middernacht:

Django/Jinja:

{{ today_at('00:00') + timedelta(days=1) - now() }}

Ligt er even aan hoe de huidige waarde is hoe je het op kunt tellen.

En utility meter, heb je ergens een all time runtime sensor ofzo? Anders zou een history stat inderdaad logischer zijn.

[belly89]

Septillion schreef op vrijdag 13 september 2024 @ 11:55:
@belly89 Een template met tijd tot middernacht:

Django/Jinja:

{{ today_at('00:00') + timedelta(days=1) - now() }}

Ligt er even aan hoe de huidige waarde is hoe je het op kunt tellen.

En utility meter, heb je ergens een all time runtime sensor ofzo? Anders zou een history stat inderdaad logischer zijn.

Top, dit zocht ik inderdaad! Bedankt.

De nutsmeter en History stat had ik even door de war gehaald. Ik heb inderdaad een history stat met de bedrijfsuren van vandaag.

Ook een idee hoe dit samen op te tellen? De History stat geeft het aantal uur weer (bijv. 12.34 uur) en bovenstaande geeft "11:50:25.237655" aan. een simpele template met + werkt helaas niet

[Septillion]

@belly89 Volgens mij heb je nu een decimaal getal in uren toch? Dus 12.34 = 12 uur en 20 minuten.

Dan iets als:

Django/Jinja:

{% set d = today_at('00:00') + timedelta(days=1) - now() %}
{% set e = states('sensor.history') %}
{{ ( e|float(0) + ( d.total_seconds() / 3600 ) ) |round(2) }}

[PeteSplit]

Mijn HA heeft altijd problemen met de update van HA-supervisor. Ik had gisteren avond een melding van een update van HA-supervisor. Ik wilde deze vanmorgen installeren, maar dit was 's nachts al automatisch gebeurd. Net als de vorige keer met enkele foutmeldingen (zie afbeelding). De huidige versie is nu 2024.09.1

Hebben jullie ook deze foutmeldingen ? Is nu toch de nieuwe update geinstalleerd ?

[TheFes]

PeteSplit schreef op vrijdag 13 september 2024 @ 13:43:
Mijn HA heeft altijd problemen met de update van HA-supervisor. Ik had gisteren avond een melding van een update van HA-supervisor. Ik wilde deze vanmorgen installeren, maar dit was 's nachts al automatisch gebeurd. Net als de vorige keer met enkele foutmeldingen (zie afbeelding). De huidige versie is nu 2024.09.1

Hebben jullie ook deze foutmeldingen ? Is nu toch de nieuwe update geinstalleerd ?

[Afbeelding]

HA Supervisor installeert inderdaad automatisch na een aantal uur (weet niet precies hoeveel maar geloof dat het 6 was).
Je kunt bij Settings > About zien op welke versie je nu zit. Bij mij is dat nu

code:

Core: 2024.9.1
Supervisor: 2024.09.1
Operating System: 13.1
Frontend: 20240906.0

[PeteSplit]

TheFes schreef op vrijdag 13 september 2024 @ 13:55:
[...]


HA Supervisor installeert inderdaad automatisch na een aantal uur (weet niet precies hoeveel maar geloof dat het 6 was).
Je kunt bij Settings > About zien op welke versie je nu zit. Bij mij is dat nu

code:

Core: 2024.9.1
Supervisor: 2024.09.1
Operating System: 13.1
Frontend: 20240906.0

Ik had de melding om 21:21 en 2:36 was de foutmelding = 5:15 uur.

Ik heb dezelfde versie (met de nieuwe naam):



Dus de foutmeldingen kunnen geen kwaad, de update wordt toch gedaan.

[Brynnie]

Septillion schreef op donderdag 16 februari 2023 @ 10:29:
[...]

Zelf gebruik ik daarvoor nog een custom component (via HACS) om de bakken altijd in volgorde te zetten. En nog weer templates om de dag "logisch" weer te geven met plaatje van de afvalverwerker (ACV). Niet heel erg beginner proof dus
[Afbeelding]

Card:

YAML:

type: custom:auto-entities
card:
  type: glance
filter:
  include:
    - entity_id: sensor.wast_gft
    - entity_id: sensor.wast_paper
    - entity_id: sensor.wast_pmd
    - entity_id: sensor.wast_rest
sort:
  attribute: Days_until
  method: attribute
  numeric: true

Templates (in configuration.yaml)

YAML:

template:
  - sensor:
      unique_id: wast_gft
      name: 'GFT'
      availability: "{{ states('sensor.acv_gft') not in ['unavailable'] }}"
      state: >-
        {% set e = 'sensor.acv_gft' %}
        {% set x = state_attr(e, 'Days_until') %}
        {% if not x|is_number %}
          unknown
        {% else %}
          {% if x == 0 %}
            Today
          {% elif x == 1 %}
            Tomorrow
          {% elif x > 13 %}
            {{ (states(e)|as_datetime).strftime('%a %-d %b') }}
          {% elif x > 6 %}
            Next {{ (states(e)|as_datetime).strftime('%A')|lower }}
          {% elif x > 1 %}
            {{ (states(e)|as_datetime).strftime('%A') }}
          {% else %}
            unknown
          {% endif %}
        {% endif %}
      attributes:
        Days_until: "{{ state_attr('sensor.acv_gft', 'Days_until') }}"
      picture: /local/icons/gft-on.png
  - sensor:
      unique_id: wast_pmd
      name: 'PMD'
      availability: "{{ states('sensor.acv_pmd') not in ['unavailable'] }}"
      state: >-
        {% set e = 'sensor.acv_pmd' %}
        {% set x = state_attr(e, 'Days_until') %}
        {% if not x|is_number %}
          unknown
        {% else %}
          {% if x == 0 %}
            Today
          {% elif x == 1 %}
            Tomorrow
          {% elif x > 13 %}
            {{ (states(e)|as_datetime).strftime('%a %-d %b') }}
          {% elif x > 6 %}
            Next {{ (states(e)|as_datetime).strftime('%A')|lower }}
          {% elif x > 1 %}
            {{ (states(e)|as_datetime).strftime('%A') }}
          {% else %}
            unknown
          {% endif %}
        {% endif %}
      attributes:
        Days_until: "{{ state_attr('sensor.acv_pmd', 'Days_until') }}"
      picture: /local/icons/pmd-on.png
  - sensor:
      unique_id: wast_paper
      name: 'Paper'
      availability: "{{ states('sensor.acv_papier') not in ['unavailable'] }}"
      state: >-
        {% set e = 'sensor.acv_papier' %}
        {% set x = state_attr(e, 'Days_until') %}
        {% if not x|is_number %}
          unknown
        {% else %}
          {% if x == 0 %}
            Today
          {% elif x == 1 %}
            Tomorrow
          {% elif x > 13 %}
            {{ (states(e)|as_datetime).strftime('%a %-d %b') }}
          {% elif x > 6 %}
            Next {{ (states(e)|as_datetime).strftime('%A')|lower }}
          {% elif x > 1 %}
            {{ (states(e)|as_datetime).strftime('%A') }}
          {% else %}
            unknown
          {% endif %}
        {% endif %}
      attributes:
        Days_until: "{{ state_attr('sensor.acv_papier', 'Days_until') }}"
      picture: /local/icons/paper-on.png
  - sensor:
      unique_id: wast_rest
      name: 'Rest'
      availability: "{{ states('sensor.acv_restafval') not in ['unavailable'] }}"
      state: >-
        {% set e = 'sensor.acv_restafval' %}
        {% set x = state_attr(e, 'Days_until') %}
        {% if not x|is_number %}
          unknown
        {% else %}
          {% if x == 0 %}
            Today
          {% elif x == 1 %}
            Tomorrow
          {% elif x > 13 %}
            {{ (states(e)|as_datetime).strftime('%a %-d %b') }}
          {% elif x > 6 %}
            Next {{ (states(e)|as_datetime).strftime('%A')|lower }}
          {% elif x > 1 %}
            {{ (states(e)|as_datetime).strftime('%A') }}
          {% else %}
            unknown
          {% endif %}
        {% endif %}
      attributes:
        Days_until: "{{ state_attr('sensor.acv_restafval', 'Days_until') }}"
      picture: /local/icons/rest-on.png

Misschien al eerder gevraagd, maar ik vind het niet:
Hoe zorg je ervoor dat de getoonde datum informatie in het Nederlands wordt weergegeven? In mijn HA app staat alles op Nederlands, en toch zie ik bvb “Monday” ipv “maandag” bij het toepassen van bovenstaande template.

[TheFes]

Brynnie schreef op vrijdag 13 september 2024 @ 14:24:
[...]


Misschien al eerder gevraagd, maar ik vind het niet:
Hoe zorg je ervoor dat de getoonde datum informatie in het Nederlands wordt weergegeven? In mijn HA app staat alles op Nederlands, en toch zie ik bvb “Monday” ipv “maandag” bij het toepassen van bovenstaande template.

Dat komt omdat strftime de OS locale gebruikt. Als je HAOS gebruikt zal die op Engels staan en die kun je niet wijzigen.
Je zult zelf de vertalingen moeten verzorgen je template.

[Sjoop1985]

Heb een beetje een niche issue ontdekt terwijl ik op vakantie was.

Ik gebruik de Nabu Casa Cloud connectie voor toegang buitenshuis. Ik draai Frigate op mijn NAS, geïntegreerd in HA met de Frigate integratie en de Frigate Card uit HACS. Nu viel het me op dat wanneer ik buitenshuis het dashboard met de Frigate card open, de livestream zonder problemen laadt, maar zodra ik terug wil naar een recording, verliest de app zijn connectie met HA volledig (dus geen melding van Frigate, maar van de companion app zelf dat de verbinding verbroken is).

Nu ik thuis ben heb ik dit kunnen reproduceren terwijl ik lokaal toegang heb tot HA, maar de instance blijft gewoon responsive.

Iemand enig idee wat er mis zou kunnen gaan? Op basis van de symptomen lijkt het probleem me bij de Nabu Casa Connectie te zitten, waar ik helaas niks aan kan veranderen qua settings.

[belly89]

Septillion schreef op vrijdag 13 september 2024 @ 13:43:
@belly89 Volgens mij heb je nu een decimaal getal in uren toch? Dus 12.34 = 12 uur en 20 minuten.

Dan iets als:

Django/Jinja:

{% set d = today_at('00:00') + timedelta(days=1) - now() %}
{% set e = states('sensor.history') %}
{{ ( e|float(0) + ( d.total_seconds() / 3600 ) ) |round(2) }}

Ja klopt, dit werkt perfect. Super bedankt!!

[Eriko]

De grafische weergave met datum invoer knoppen (dag of dagen) lijkt me interessant:

https://github.com/alexarch21/history-explorer-card

Echter is het niet meer ondersteund. Is er een opvolger bekend?

[Eriko]

Ach nu ontdek ik pas.

De procedure is als volgt:

Ga naar menu History
Vul wat entities wat je maar wilt
Opslaan via drie dubbele puntjes: Add current view as card
Ga naar de juiste dashboard/view
Bekijk deze card
Druk op knop '>'
Je zit weer in de menu History met opgeslagen entities.

[TheFes]

Eriko schreef op vrijdag 13 september 2024 @ 16:06:
De grafische weergave met datum invoer knoppen (dag of dagen) lijkt me interessant:

https://github.com/alexarch21/history-explorer-card

Echter is het niet meer ondersteund. Is er een opvolger bekend?

De kaart werkt nog gewoon, je moet hem alleen manueel installeren, kan dus niet meer via HACS

[Gonzalez]

Ferra schreef op donderdag 12 september 2024 @ 07:16:
Kan het casten naar een Google Nest Hub nog steeds?

Ja hoor.

[Tomba]

In de keuken heb ik een iPad hangen met een HA dashboard die altijd aanstaat en sinds kort (ik denk sinds de upgrade naar 2024.8?) crasht de app dagelijks (meestal ‘s nachts) ik moet de app dan herstarten en het juiste dashboard kiezen (hij lijkt dus ook zijn settings te verliezen) iPadOS is up-to-date (17.6.1) en het betreft een IPP2017. Iemand die dit herkent en/of een oplossing weet?

[Just_A_User]

Is het mogelijk om het aantal cijfers achter de komma te beperken bij een nuts meter? Ik heb eerder een nuts meter aangemaakt (werkt nu goed overigens, thanks @TheFes & @Septillion. Hij rapporteert dus prima, maar ik heb 'm net aan de lader gezet, en hij rapporteert dus nu 28(!) cijfers achter de komma.



Van andere sensoren ben ik ook wel gewend dat ze dat doen, maar op een gegeven moment wordt dat gewoon op 2 cijfers achter de komma en dat vind ik ook wel voldoende. Bij deze echter gebeurt dat niet automatisch, dus is dat te beperken?

[ Voor 4% gewijzigd door Just_A_User op 14-09-2024 10:32 ]

[marnie]

Just_A_User schreef op zaterdag 14 september 2024 @ 10:31:
Is het mogelijk om het aantal cijfers achter de komma te beperken bij een nuts meter? Ik heb eerder een nuts meter aangemaakt (werkt nu goed overigens, thanks @TheFes & @Septillion. Hij rapporteert dus prima, maar ik heb 'm net aan de lader gezet, en hij rapporteert dus nu 28(!) cijfers achter de komma.

[Afbeelding]

Van andere sensoren ben ik ook wel gewend dat ze dat doen, maar op een gegeven moment wordt dat gewoon op 2 cijfers achter de komma en dat vind ik ook wel voldoende. Bij deze echter gebeurt dat niet automatisch, dus is dat te beperken?

Klik eens op het tandwieltje, kan je daar de precisie aangeven?