Home Assistant: Open source Python3 home automation - deel 4

[RobertMe]

Beekforel schreef op zaterdag 13 augustus 2022 @ 15:04:
[...]

Dat gaat helaas niet op, mijn power consumption is hoger dan 0 omdat ik maar op 1 fase teruglever en power consumption uit P1 alle fasen optelt. De "tellers" van vebruik blijven wel op 0 staan zolang ik meer opwek dan verbruik.

Van wat ik begrepen heb zou dat wel goed moeten gaan? Een slimme meter met meerdere fasen verrekend zelf intern al dit verschil. Dus als je op één fase teruglevert en de andere verbruiken dan trekt de meter de teruglevering er al vanaf. Of in ieder geval: slimme meters doen deze "saldering" intern. En als over een aantal jaren de salderingsregeling wordt afgeschaft blijft dit wel bestaan. Dus als je op L1 1000W teruglevert en op L2 en L3 500W afneemt dan zal de meter een afname van 0 registreren.

Hm, klopt toch niet helemaal. M'n power_consumption geeft meer aan dan m'n berekende variant. irritante errors met Growatt gooien roet in het eten
De intervallen van de beide sensoren verschillen dus wordt een zaagtand grafiek helaas.

Dat vroeg ik me ook al af. Dit werkt alleen als beiden redelijk gelijk werken. Als je de omvormer uitleest via een API en dat maar elke 15 minuten plaatsvindt, en je dan een live opwek krijgt, terwijl de P1 meter elke X seconden het actuele verbruik meld dan krijg je een resultaat waar je niks mee kunt. Dan moet je al een verbruiksmeter tussen de groepenkast en omvormer plaatsen. Zodat je ook real time weet hoeveel de panelen opwekken.

[Beekforel]

RobertMe schreef op zaterdag 13 augustus 2022 @ 18:04:
[...]

Van wat ik begrepen heb zou dat wel goed moeten gaan? Een slimme meter met meerdere fasen verrekend zelf intern al dit verschil. Dus als je op één fase teruglevert en de andere verbruiken dan trekt de meter de teruglevering er al vanaf. Of in ieder geval: slimme meters doen deze "saldering" intern. En als over een aantal jaren de salderingsregeling wordt afgeschaft blijft dit wel bestaan. Dus als je op L1 1000W teruglevert en op L2 en L3 500W afneemt dan zal de meter een afname van 0 registreren.


[...]

Dat gebeurt ook, tellerwerk staat stil bij voldoende opwek. Maar de sensor power consumption is blijkbaar niet representatief...

[JorisV]

Toppe schreef op zaterdag 13 augustus 2022 @ 17:08:
[...]


Hmm, eens kijken wat de soil sensors zijn, zullen wel die duurste twee zijn

Volgens mij moet het voor iets van €8 kunnen.

[Toppe]

JorisV schreef op zaterdag 13 augustus 2022 @ 18:38:
[...]

Volgens mij moet het voor iets van €8 kunnen.

Je kan niet zomaar elke vocht sensor er voor gebruiken ivm waterdichtheid en dat de sensor zelf vol slipt met bagger. Daarbij wil ik hem gebruiken om de tuin van water te voorzien, hij gaat dus ook ‘ondergedompeld’ worden.

[Septillion]

Beekforel schreef op zaterdag 13 augustus 2022 @ 18:07:
[...]

Dat gebeurt ook, tellerwerk staat stil bij voldoende opwek. Maar de sensor power consumption is blijkbaar niet representatief...

Ja hoor, dat is hij wel. De rekensom van @RobertMe klopt de hele dag door afgezien misschien interval dingetje. Dat zou je eventueel statistics mean sensor op kunnen lossen want als het goed is moet dat gewoon correct uitmiddelen.

[JeroenH]

De laatste paar dagen een watermeter pulsteller opgezet volgens deze handleiding. Dat was snel en goed te doen, en om het mooi te maken met de lasersnijder maar een nette houder gemaakt:



Werkt goed, wel al gezien dat we vandaag 326 liter water verbruikt hebben, dat komt als best veel op me over, gezien de droogteproblemen. Maar ja, gezin van vier, wc's, douchen, etc........

Overigens wel gekkigheden in de meetdata te zien, een paar pieken van onmogelijk hoog verbruik. Ik zal nog wat morrelen aan de positie van de sensor, maar ik zie het rode lampje bovenop keurig 1x aan/1x uit flitsen bij een rotatie van het "liter-wieltje". Kan nog zijn dat dit door mijn morrelen met de sensor komt. Aankijken maar.

[ Voor 14% gewijzigd door JeroenH op 13-08-2022 22:58 ]

[Beekforel]

Septillion schreef op zaterdag 13 augustus 2022 @ 22:23:
[...]

Ja hoor, dat is hij wel. De rekensom van @RobertMe klopt de hele dag door afgezien misschien interval dingetje. Dat zou je eventueel statistics mean sensor op kunnen lossen want als het goed is moet dat gewoon correct uitmiddelen.

Dan zit er iets in mijn meterkast niet goed zou je zeggen want ik heb overdag altijd afname op sensor power_consumption ook al wek ik meer dan voldoende op...

[Boss]

maxxie85 schreef op zaterdag 13 augustus 2022 @ 08:56:
[...]
Ja ik had dat issue gemaakt. En gesloten nadat iemand hier de pr had gedeeld waarin dit is gebeurt. Ze hebben dit dus bewust gedaan.
Snap eigenlijk ook niet waarom. Ik vind het eigenlijk ook irritant. Bij mij is daardoor ook het historische verbruik verdwenen.

Ik heb hier ook last van, hoewel het pas vandaag is begonnen na een migratie van Pi -> Synology + Docker. Hele hostorische verbruik en teruglevering van de P1 meter is weg.

Iemand enig idee hoe dat terug is te krijgen? De data zal toch nog in de DB staan?

[Septillion]

Beekforel schreef op zaterdag 13 augustus 2022 @ 23:09:
[...]

Dan zit er iets in mijn meterkast niet goed zou je zeggen want ik heb overdag altijd afname op sensor power_consumption ook al wek ik meer dan voldoende op...

Hoef niet als je 3-fase hebt. Je energie telwerken (voor kWh) zijn wel netto maar de instantane vermogens (in kW) uit je meter zijn dit niet. Waar bij de energie telwerken er altijd maar één tegelijk loopt geldt dit niet voor de vermogens. Je kan dus daar wel tegelijk power_consumption en power_production hebben. Die zal je dus zelf netto moeten maken door power_consumption - power_production te namen (uitgaande van positieve waarde is netto gebruikte vermogen uit het net).

Voor je totale netto verbruikte vermogen komt hier dus je opwek van je PV nog bij. Dus je eigen verbruikte vermogen is altijd power_consumption - power_production + power_PV waarbij gelijktijdig alle drie een (positieve) waarde kunnen bevatten.

Zoals gezegd kan deze berekening bij schommelingen en niet gelijktijdig wijzigingen doorgeven dus wel een vertekend beeld geven. Maar in een constante situatie (= constant eigen verbruik & constante PV opwekking) houdt het wel stand. Middeling over meerdere samples van de verschillende bronnen zou dit ook weer kloppend moeten maken bij fluctuatie.

'power_consumption' en 'power_production' zijn hierbij de namen voor vermogen (=power) consumptie en productie uit het net

[ Voor 12% gewijzigd door Septillion op 14-08-2022 00:13 ]

[Valkyre]

Rapedapeda schreef op woensdag 10 augustus 2022 @ 21:34:
TLDR: is er ergens in de events/state_changes te zien of een entiteit is aangezet door bijvoorbeeld een automation, of dmv een knop in de UI/HomeKit of een fysieke knop aan de muur (Shelly)? Hoe kan ik die gebruiken als conditie in een automation?

----

Ik zit met het volgende idee/probleem, en heb er op de andere fora helaas geen goed antwoord voor kunnen vinden:
Mijn zonwering gaat in principe automatisch in en uit op basis van een x aantal condities die elke 5 minuten worden gecheckt. Als eraan wordt voldaan, gaat het scherm uit (of in). Dat werkt in de regel prima.

code:

- id: zonwering_zonnescherm
  alias: Zonwering tuin automatisch open
  trigger: 
    - platform: time_pattern
      minutes: "/5"
  condition: [ hele lijst met weerscondities etc]
  action:
    - service: cover.open_cover
      entity_id: cover.zonnescherm

Af en toe (bijvoorbeeld als buienradar regen verkeer voorspelt) willen we handmatig snel het zonnescherm inklappen. Maar doordat de automations eens per (in dit geval) 5 minuten triggeren, gaat het scherm vaak na 5 minuten weer uit.

Met andere woorden, ik wil graag dat het zonnescherm automatisch in en uitgaat, maar dat hij dat niet meer doet als ik handmatig heb overruled.

Dat valt op te lossen als ik ergens de informatie kan terughalen of een state_change komt door een automation, of iets anders. Heeft iemand met dit bijltje gehakt?

Waarom doe je niet alleen een trigger wanneer de zon daadwerkelijk op je huis staat dat je de zonnewering nodig heb?

Bij mij gaat ie uit als de zon op 47graden boven de horizon staat (met een aantal condities) en word ie ingetrokken als de zon nog maar 1 graden boven de horizon staat.

Volgens mij ondervang je dan wat jij wil.
Behalve als het tussendoor regent.

[maxxie85]

Boss schreef op zaterdag 13 augustus 2022 @ 23:29:
[...]


Ik heb hier ook last van, hoewel het pas vandaag is begonnen na een migratie van Pi -> Synology + Docker. Hele hostorische verbruik en teruglevering van de P1 meter is weg.

Iemand enig idee hoe dat terug is te krijgen? De data zal toch nog in de DB staan?

Het kan zijn dat het verwijderd is uit de DB. Maar dan kan je het nog weghalen uit een backup.

Ik weet niet hoe bekend je bent met SQL en foreign key relations. Het is zeker te doen, je moet zorgen dat je oude data verwijst naar de nieuwe identifiers. En zorgen dat je initiële conditie klopt. Waarschijnlijk zal je de eerste entry van je nieuwe data zal moeten aanpassen.

Ik heb niet specifiek in de DB gekeken hiervoor omdat ik vermoed dat alle oude data verwijderd is.

[Koepert]

Ik ben aan t kijken naar n sonoff dongle plus als BU unit voor m’n deconz conbee II

Kan iemand me t verschil uitleggen (ik zie t wel maar snap t niet) tussen de E en P versie vd stick?


https://a.aliexpress.com/_mK0AWeo

[Septillion]

@Koepert Verschil is de chip, de Dongle-P heeft een de bekende CC2652P van Texas Instruments en de Dongle-E heeft de EFR32MG21 van Silicon Labs. Lijkt erop dat TI chips gewoon erg lastig te krijgen zijn dus hebben ze een SL versie gemaakt. Support van de Donlge-E in Z2M is experimental en firmware ervoor wordt niet gemaakt door Koenkk maar door iTead.

[gomaster]

Sinds kort probeer ik een 'domme' lamp via een stopcontact met daarachter een Sonoff ZBmini met een traditionele schakelaar op een andere plek in mijn kamer ook met een ZBmini aan en uit te zetten. Hiervoor heb ik in home assistant twee automations draaien: lamp uit, en lamp aan. Het idee is dat de trigger de schakelaar is en als deze van uit naar aan en of aan naar uit gaat de andere ZBmini mee gaat. Dit werkt vaker niet dan wel en ik zou ook graag via andere automations die verlichting willen bedienen, de schakelaar gaat dan natuurlijk niet mee.
Mijn vraag: kan ik dit ook handiger oplossen, zodat bijvoorbeeld de schakelaar bij verzetten altijd de lamp van state veranderd, los van hoe de stand van de schakelaar op dat moment is?

Voor de volledigheid mijn niet altijd werkende automations:

YAML:

- id: '134'
  alias: Woonkamer lampen aan
  description: ''
  trigger:
    - platform: device
      type: turned_on
      device_id: 399b26e38c77ed6eb3c4eb5f7f47218e
      entity_id: light.woonkamer_lichtschakelaar_3244c024_on_off
      domain: light
  condition: []
  action:
    - type: turn_on
      device_id: 8f94a957c137b182fb3c3349e6313f73
      entity_id: light.woonkamer_kleine_lamp_on_off
      domain: light
  mode: single
- id: '135'
  alias: Woonkamer lampen uit
  description: ''
  trigger:
    - platform: device
      type: turned_off
      device_id: 399b26e38c77ed6eb3c4eb5f7f47218e
      entity_id: light.woonkamer_lichtschakelaar_3244c024_on_off
      domain: light
  condition: []
  action:
    - type: turn_off
      device_id: 8f94a957c137b182fb3c3349e6313f73
      entity_id: light.woonkamer_kleine_lamp_on_off
      domain: light
  mode: single

[Peatsmoke]

Ik heb een vraagje en hoop dat iemand van jullie mij hiermee kan helpen.
Vandaag heb ik een virtuele sensor aangemaakt met deze code:

YAML:

sensor:
  - platform: rest
    resource: http://weerlive.nl/api/json-data-10min.php?key=YOURAPIKEY&locatie=YOURLOCATION
    name: "maximum temperatuur vandaag"
    value_template: "{{ value_json.liveweer[0].d0tmax }}"
    unit_of_measurement: "°C"
    scan_interval: "01:00" # every hour, to make sure that the number of requests stays well below maximum 300 per day

Uiteraard heb ik de API en locatie aangepast en ik krijg ook een waarde te zien.

Nu wil ik de rolluiken laten sluiten als een bepaalde waarde overschreden wordt.
Daarvoor heb ik deze automatisering gemaakt:

YAML:

alias: "Automatisering: rolluiken woonkamer dicht bij warm weer"
description: ""
trigger:
  - platform: time_pattern
    minutes: "10"
condition:
  - condition: sun
    after: sunrise
    after_offset: "45"
    before: sunset
  - condition: numeric_state
    entity_id: sensor.maximum_temperatuur_vandaag
    above: "29"
action:
  - device_id: <DEVICE ID>
    domain: rfxtrx
    type: send_command
    subtype: Stop
mode: single

Het vreemde is, dat wanneer ik een gewone sensor en geen read-only/ virtuele sensor (weet de officiële benaming niet) van Buienradar gebruik, bovenstaande code wel gewoon werkt. Maar Buienradar levert niet de verwachte max van vandaag, als sensor.
Waar gaat het nu mis, is dit op te lossen en hoe?

[ Voor 0% gewijzigd door Septillion op 14-08-2022 10:06 . Reden: Denk aan de yaml aub! ]

[Septillion]

@gomaster Daarvoor kan je toggle gebruiken

In de versie met device zou dat zijn:

YAML:

- id: '134'
  alias: Woonkamer lampen aan/uit
  description: ''
  trigger:
    - platform: device
      type: changed_states
      device_id: 399b26e38c77ed6eb3c4eb5f7f47218e
      entity_id: light.woonkamer_lichtschakelaar_3244c024_on_off
      domain: light
  condition: []
  action:
    - type: toggle
      device_id: 8f94a957c137b182fb3c3349e6313f73
      entity_id: light.woonkamer_kleine_lamp_on_off
      domain: light
  mode: single

Met devices is de automation wel heel makkelijk te maken in de UI maar met device_id vind ik ze niet zo heel overzichtelijk. Alternatief met states en service calls zou zijn:

YAML:

alias: Woonkamer lampen aan/uit
description: ""
mode: single
trigger:
  - platform: state
    entity_id:
      - light.woonkamer_lichtschakelaar_3244c024_on_off
condition: []
action:
  - service: light.toggle
    data: {}
    target:
      entity_id: light.woonkamer_kleine_lamp_on_off

[RudolfR]

@Peatsmoke

Ik heb daarvoor een template sensor die net voor middernacht de maximumtemperatuur van morgen opslaat uit de verwachting.

YAML:

- trigger:
    - platform: time
      at: "23:59:00"
  sensor:
    - name: "Forecast max temperature today"
      unique_id: "forecast_max_temperature_today"
      state: "{{ state_attr('weather.home', 'forecast').0.temperature }}"
    - name: "Forecast weather type today"
      unique_id: "forecast_weather_type_today"
      state: "{{ state_attr('weather.buienradar', 'forecast').0.condition }}"

Weet niet precies waarom de rest-sensor niet werkt, misschien omdat de waarde een string is en daardoor moeilijk te vergelijken met de numerieke waarde 29?

[Septillion]

@Peatsmoke Laten we beginnen met je trigger. Timer patern triggers zijn eigenlijk een hele domme manier om ergens op te triggeren. Hele idee van HA is nu juist dat alles event based is en dus direct kan reageren. Een betere versie zou dus zijn:

YAML:

alias: "Automatisering: rolluiken woonkamer dicht bij warm weer"
description: ""
trigger:
  - platform: sun
    event: sunrise
    offset: "45"
  - platform: numeric_state
    entity_id: sensor.maximum_temperatuur_vandaag
    above: "29"
condition:
  - condition: sun
    after: sunrise
    after_offset: "45"
    before: sunset
  - condition: numeric_state
    entity_id: sensor.maximum_temperatuur_vandaag
    above: "29"
action:
  - device_id: <DEVICE ID>
    domain: rfxtrx
    type: send_command
    subtype: Stop
mode: single

Peatsmoke schreef op zondag 14 augustus 2022 @ 10:04:
een gewone sensor en geen read-only/ virtuele sensor (weet de officiële benaming niet)

Alle sensoren zijn read only. Je hebt nu gewoon een sensor aangemaakt via de RESTful Sensor integratie.

Maar kan je via Dev tools => States eens laten zien wat die sensor nu bevat? Ik heb geen API key dus kan de json ook niet bekijken. Kan je anders ook eens de hele json response van weerlive plaatsen?

[ Voor 4% gewijzigd door Septillion op 14-08-2022 10:14 ]

[gomaster]

Septillion schreef op zondag 14 augustus 2022 @ 10:06:
@gomaster Daarvoor kan je toggle gebruiken

In de versie met device zou dat zijn:

YAML:

- id: '134'
  alias: Woonkamer lampen aan/uit
  description: ''
  trigger:
    - platform: device
      type: changed_states
      device_id: 399b26e38c77ed6eb3c4eb5f7f47218e
      entity_id: light.woonkamer_lichtschakelaar_3244c024_on_off
      domain: light
  condition: []
  action:
    - type: toggle
      device_id: 8f94a957c137b182fb3c3349e6313f73
      entity_id: light.woonkamer_kleine_lamp_on_off
      domain: light
  mode: single

Met devices is de automation wel heel makkelijk te maken in de UI maar met device_id vind ik ze niet zo heel overzichtelijk. Alternatief met states en service calls zou zijn:

YAML:

alias: Woonkamer lampen aan/uit
description: ""
mode: single
trigger:
  - platform: state
    entity_id:
      - light.woonkamer_lichtschakelaar_3244c024_on_off
condition: []
action:
  - service: light.toggle
    data: {}
    target:
      entity_id: light.woonkamer_kleine_lamp_on_off

Dank! Exact waar ik naar op zoek was. Weer wat verder in mijn proces

[Peatsmoke]

RudolfR schreef op zondag 14 augustus 2022 @ 10:10:
@Peatsmoke

Ik heb daarvoor een template sensor die net voor middernacht de maximumtemperatuur van morgen opslaat uit de verwachting.

YAML:

- trigger:
    - platform: time
      at: "23:59:00"
  sensor:
    - name: "Forecast max temperature today"
      unique_id: "forecast_max_temperature_today"
      state: "{{ state_attr('weather.home', 'forecast').0.temperature }}"
    - name: "Forecast weather type today"
      unique_id: "forecast_weather_type_today"
      state: "{{ state_attr('weather.buienradar', 'forecast').0.condition }}"

Weet niet precies waarom de rest-sensor niet werkt, misschien omdat de waarde een string is en daardoor moeilijk te vergelijken met de numerieke waarde 29?

Inmiddels werkt het, maar dit is dus ook een goede optie.

Septillion schreef op zondag 14 augustus 2022 @ 10:13:
@Peatsmoke Laten we beginnen met je trigger. Timer patern triggers zijn eigenlijk een hele domme manier om ergens op te triggeren. Hele idee van HA is nu juist dat alles event based is en dus direct kan reageren. Een betere versie zou dus zijn:

YAML:

alias: "Automatisering: rolluiken woonkamer dicht bij warm weer"
description: ""
trigger:
  - platform: sun
    event: sunrise
    offset: "45"
  - platform: numeric_state
    entity_id: sensor.maximum_temperatuur_vandaag
    above: "29"
condition:
  - condition: sun
    after: sunrise
    after_offset: "45"
    before: sunset
  - condition: numeric_state
    entity_id: sensor.maximum_temperatuur_vandaag
    above: "29"
action:
  - device_id: <DEVICE ID>
    domain: rfxtrx
    type: send_command
    subtype: Stop
mode: single

[...]

Alle sensoren zijn read only. Je hebt nu gewoon een sensor aangemaakt via de RESTful Sensor integratie.

Maar kan je via Dev tools => States eens laten zien wat die sensor nu bevat? Ik heb geen API key dus kan de json ook niet bekijken. Kan je anders ook eens de hele json response van weerlive plaatsen?

Laat ik beginnen met het goede nieuws: nu werkt de code, maar ik weet nog steeds niet waaro het eerst niet werkte.

Maar kan je via Dev tools => States eens laten zien wat die sensor nu bevat?

sensor.maximum_temperatuur_vandaag
maximum temperatuur vandaag: 34

Nadat ik de code door YAMLint heb gecontroleerd, kwam er dit uit:

YAML:

action: 
  - 
    device_id: 3549b5757557f6a97d0cae4efb634232
    domain: rfxtrx
    subtype: Stop
    type: send_command
alias: "Automatisering: rolluiken woonkamer dicht bij warm weer"
condition: 
  - 
    after: sunrise
    after_offset: "45"
    before: sunset
    condition: sun
  - 
    above: "29"
    condition: numeric_state
    entity_id: sensor.maximum_temperatuur_vandaag
description: ""
mode: single
trigger: 
  - 
    minutes: "10"
    platform: time_pattern

Dat heb ik vervolgens in HA geplakt en getest.
Toen werkte het opeens. Het kan zijn dat het een browsercache probleem was, want ik realiseer me nu dat ik die cache nog niet leeggemaakt had.

Timer patern triggers zijn eigenlijk een hele domme manier om ergens op te triggeren. Hele idee van HA is nu juist dat alles event based is en dus direct kan reageren

Klopt, maar ik wilde niet wachten tot morgenochtend om te kijken of het werkt.

Ik ga nu eens kijken of ik deze automatisering kan samenvoegen met deze:

YAML:

alias: "Automatisering: Rolluiken omlaag bij zonnig en warm weer"
description: ""
trigger:
  - platform: time_pattern
    minutes: "10"
condition:
  - type: is_illuminance
    condition: device
    device_id: <ID>
    entity_id: sensor.solar_radiation
    domain: sensor
    above: 100
  - condition: or
    conditions:
      - condition: numeric_state
        entity_id: sensor.zonnepanelen_current_power
        above: "350"
  - type: is_temperature
    condition: device
    device_id: <ID>
    entity_id: sensor.woonkamer_temperature
    domain: sensor
    above: 22.5
  - condition: sun
    before: sunset
    before_offset: "240"
    after: sunrise
    after_offset: "30"
action:
  - device_id: <ID>
    domain: rfxtrx
    type: send_command
    subtype: Stop
mode: single

Hier heb ik voor de tijdsintervallen gekozen omdat ik wil blijven controleren of de temperatuur boven de 22.5 uitkomt. Daar zullen beslist ook andere oplossingen voor zijn, maar ik ben nieuw in de materie en vond dit werkend krijgen al heel wat.

Dat ik pas van Domoticz naar HA ben overgestapt hoef ik wss niet uit te leggen...

[ Voor 10% gewijzigd door Septillion op 14-08-2022 10:44 . Reden: Denk aan de yaml aub! ]

[BlazeMuis]

maxoss schreef op zaterdag 13 augustus 2022 @ 15:43:
[...]


Bespaar je de moeite. Deze sensor is troep. Begon bij mij na een aantal weken/maanden te roesten en meet dan niet meer/onnauwkeurig

Dat komt door elektrolyse, omdat je de sensor 24/7 laat draaien en dus constant stroompjes door de sensors laat gaan waardoor het gaat oxideren. Als je bijvoorbeeld elke 15 of 30 minuten een meting doet (van nog geen seconde) gaat het al een stuk langer mee.

Ik heb inmiddels 3 van die sensors en 3x ESP8266 via amazon besteld, mijn bevindingen zal ik hier posten.

[ Voor 3% gewijzigd door BlazeMuis op 14-08-2022 10:39 ]

[Peatsmoke]

Uiteindelijk heb ik er dit dus van gemaakt:
YAML:

YAML:

alias: "Automatisering: rolluiken woonkamer dicht bij warm weer"
description: >-
  Deze automatisering controleert de verwachte temperatuur voor vandaag. Wanneer
  die hoger is dan 28 graden, sluiten de rolluiken
trigger:
  - platform: sun
    event: sunrise
    offset: "40"
condition:
  - condition: numeric_state
    entity_id: sensor.maximum_temperatuur_vandaag
    above: "28"
action:
  - device_id: <<ID>>
    domain: rfxtrx
    type: send_command
    subtype: Stop
mode: single

[ Voor 0% gewijzigd door Septillion op 14-08-2022 10:53 . Reden: Denk aan de yaml tags aub! ]

[Septillion]

Peatsmoke schreef op zondag 14 augustus 2022 @ 10:38:
Nadat ik de code door YAMLint heb gecontroleerd, kwam er dit uit:

Waarom haal je het door YAMLint die het zo verklooit?

Dat heb ik vervolgens in HA geplakt en getest.
Toen werkte het opeens. Het kan zijn dat het een browsercache probleem was, want ik realiseer me nu dat ik die cache nog niet leeggemaakt had.

Zou niet weten hoe je browser cache iets te maken heeft met een automation op je HA.

Klopt, maar ik wilde niet wachten tot morgenochtend om te kijken of het werkt.

Maak je er van:

YAML:

alias: "Automatisering: rolluiken woonkamer dicht bij warm weer"
description: ""
trigger:
  - platform: sun
    event: sunrise
    offset: "45"
  - platform: numeric_state
    entity_id: sensor.maximum_temperatuur_vandaag
    above: "29"
  - platform: event
    event_type: automation_reloaded
condition:
  - condition: sun
    after: sunrise
    after_offset: "45"
    before: sunset
  - condition: numeric_state
    entity_id: sensor.maximum_temperatuur_vandaag
    above: "29"
action:
  - device_id: <DEVICE ID>
    domain: rfxtrx
    type: send_command
    subtype: Stop
mode: single

Wordt het gelijk na het saven of reloaden van de automation al getriggert.

Of je gebruikt Dev tools om een state even tijdelijk aan te passen. Dat is dan een echte test.

Ik ga nu eens kijken of ik deze automatisering kan samenvoegen met deze:

Tja, weer een "dom" time patern Maar dat is niet hoe een OR werkt. Alles waar je over wilt OR'en moet onder de OR hangen.

PS Waarom haal je steeds je device ID's weg? Bang dat die belangrijke info weg geven?

[Beekforel]

Septillion schreef op zondag 14 augustus 2022 @ 00:10:
[...]

Hoef niet als je 3-fase hebt. Je energie telwerken (voor kWh) zijn wel netto maar de instantane vermogens (in kW) uit je meter zijn dit niet. Waar bij de energie telwerken er altijd maar één tegelijk loopt geldt dit niet voor de vermogens. Je kan dus daar wel tegelijk power_consumption en power_production hebben. Die zal je dus zelf netto moeten maken door power_consumption - power_production te namen (uitgaande van positieve waarde is netto gebruikte vermogen uit het net).

Voor je totale netto verbruikte vermogen komt hier dus je opwek van je PV nog bij. Dus je eigen verbruikte vermogen is altijd power_consumption - power_production + power_PV waarbij gelijktijdig alle drie een (positieve) waarde kunnen bevatten.

Zoals gezegd kan deze berekening bij schommelingen en niet gelijktijdig wijzigingen doorgeven dus wel een vertekend beeld geven. Maar in een constante situatie (= constant eigen verbruik & constante PV opwekking) houdt het wel stand. Middeling over meerdere samples van de verschillende bronnen zou dit ook weer kloppend moeten maken bij fluctuatie.

'power_consumption' en 'power_production' zijn hierbij de namen voor vermogen (=power) consumptie en productie uit het net

Op basis van wat jij zegt zou ik op moment van screenshot dus 490,8 W (3055,8-2832+267) gebruiken? Volgens mij komt 223,8 (3055,8-2832) dichter in de buurt, maar die wijkt dan weer af van de consumption wat vermoedelijk komt door intervalverschillen.

[Septillion]

@Beekforel Correct. Je ziet ook mooi dat je op fase 3 terug levert. Daar is consumptie 0 en productie >0. En op fase 1 en 2 heb je alleen consumptie en geen productie.

Naast je gebruik op fase 1 en 2 van 269W (= 97W + 172W) heb je op fase 3 dus nog een verbruik van 223W (=3055W - 2832W).

Wat hier ook nog mee kan spelen is de onnauwkeurigheid van je omvormer. De waarde die omvormers uitgeven is geen gekalibreerde waarde en er zijn veel omvormers die wat aan de positieve kant zijn. Immers, als jij daar een grotere waarde ziet staan ben jij meer (grote ) blij.

[Peatsmoke]

Septillion schreef op zondag 14 augustus 2022 @ 10:51:
[...]

Waarom haal je het door YAMLint die het zo verklooit?


[...]

Zou niet weten hoe je browser cache iets te maken heeft met een automation op je HA.


[...]

Maak je er van:

YAML:

alias: "Automatisering: rolluiken woonkamer dicht bij warm weer"
description: ""
trigger:
  - platform: sun
    event: sunrise
    offset: "45"
  - platform: numeric_state
    entity_id: sensor.maximum_temperatuur_vandaag
    above: "29"
  - platform: event
    event_type: automation_reloaded
condition:
  - condition: sun
    after: sunrise
    after_offset: "45"
    before: sunset
  - condition: numeric_state
    entity_id: sensor.maximum_temperatuur_vandaag
    above: "29"
action:
  - device_id: <DEVICE ID>
    domain: rfxtrx
    type: send_command
    subtype: Stop
mode: single

Wordt het gelijk na het saven of reloaden van de automation al getriggert.

Of je gebruikt Dev tools om een state even tijdelijk aan te passen. Dat is dan een echte test.


[...]

Tja, weer een "dom" time patern Maar dat is niet hoe een OR werkt. Alles waar je over wilt OR'en moet onder de OR hangen.

PS Waarom haal je steeds je device ID's weg? Bang dat die belangrijke info weg geven?

Dank je voor weer een wijze les!

Om antwoord te geven op je laatste vraag: ja, dat dacht ik dus, maar uit je antwoord begrijp ik dat dit onnodig is.

Wat zou een betere optie zijn om zoiets te blijven controleren? De trigger de verandering van temperatuur van laten zijn, neem ik aan?

Ik ga er eens mee aan de slag en kom wss nog even terug hier...

[Septillion]

@Peatsmoke Device_id's zijn gewoon random bepaald net als automation id's bijvoorbeeld. Puur om uniek te zijn.

En mooie van triggers is dus dat je de volle vrijheid hebt waarop je wilt dat iets gebeurd. Maar omdat er nu elke 10 minuten alle condities wordt gecheckt en dat dus eventueel een actie tot gevolg heeft is het het equivalent om ook te triggeren op dezelfde zaken als in je conditie. Zal je dus nog wel even de OR moeten fixen, deze doe nu niets.

[Beekforel]

@Septillion ok, dan gebruik ik meer stroom dan ik dacht (minder grote blij dus) maar kan ik in elk geval een sensor maken die dat goed inzichtelijk maakt.

[golles]

Peatsmoke schreef op zondag 14 augustus 2022 @ 10:04:
Ik heb een vraagje en hoop dat iemand van jullie mij hiermee kan helpen.
Vandaag heb ik een virtuele sensor aangemaakt met deze code:

YAML:

sensor:
  - platform: rest
    resource: http://weerlive.nl/api/json-data-10min.php?key=YOURAPIKEY&locatie=YOURLOCATION
    name: "maximum temperatuur vandaag"
    value_template: "{{ value_json.liveweer[0].d0tmax }}"
    unit_of_measurement: "°C"
    scan_interval: "01:00" # every hour, to make sure that the number of requests stays well below maximum 300 per day

Uiteraard heb ik de API en locatie aangepast en ik krijg ook een waarde te zien.

Geen antwoord op je vraag, maar check deze even: https://github.com/golles/ha-knmi is misschien leuker dan een rest sensor

[Septillion]

@Beekforel Hoger verbruik is nooit leuk natuurlijk.

Voor de nauwkeurigheid van je omvormer zou je dus eens even alle groepen uit kunnen zetten op fase 3 behalve de omvormer. Wat je dan via P1 als productieop L3 ziet zou dan overeen moeten komen met wat de omvormer aan productie laat zien. Enige wat daar dan niet in zit is het verlies over de kabel wat dus eigenlijk ook eigen gebruik is. Zal bij korte kabel weinig doen maar kan je berekenen met de kabellengte, kabeldikte en de stroom.

[Beekforel]

@Septillion goeie tip, ga ik even doen. Qua kabelverlies, er zit max 3 meter tussen omvormer en meterkast.

[Daros]

Hi allemaal,

Ik heb 2 kleine vragen.

1) Ik heb een airco (mhi) waarvan ik de running A kan opvragen en ik weet via P1 welke voltage hij krijgt.

Ik heb nu het volgende gemaakt, is dit een beetje kloppend?

YAML:

      verbruik_airco_zolder:
        friendly_name: "Verbruik Airco Zolder"
        unit_of_measurement: 'W'
        device_class: power
        value_template: >
            {% set V = states('sensor.voltage_phase_l3') | float %}
            {% set BE = states('sensor.steenakker_current_power') | float %}
            {{ (BE*V) | round(2) }}

2) we hebben 5 plekken thuis waar we naar buiten kunnen dus soms word er snachts nog wel is een slot overgeslagen omdat we vergeten dat die deur is opengeweest. Deur sensoren zijn er genoeg maar ik zoek eigenlijk een sensor die ik op een manier op de cilinder of 3 puntslsuiting kan zetten en kan uitlezen of die echt opslot zit of niet.

Hebben jullie hier al ervaring mee?

Na >1k posts gaan we er wel vanuit dat je topic warnings lees Graag yaml-code tags gebruiken

[ Voor 6% gewijzigd door Septillion op 14-08-2022 13:00 ]

[Septillion]

@Daros
1) Ja en nee. Op zich is de berekening goed voor belastingen met een powerfactor van 1. Maar dat hoeft bij een airco zeker niet zo te zijn. Wat je dus eigenlijk berekend is het complex vermogen in VA. Dit kan dus een te hoge waarde zijnv ergeleken met zijn werkelijke vermogen in W. Je zou door de aico als enige te laten draaien eens de P1 uit kunnen lezen en zien hoeveel dit afwijkt.

Overigens rare entity naam zo met power in de naam als het niet om power (= vermogen) gaat maar om stroom.

Daarnaast gebruik je de legacy template sensor. Deze is niet meer aan te raden, zeker niet omdat je geen default mee geeft voor de float-filters. Beter is om de nieuwe state-base template sensor te gebruiken icm de availability parameter.

2) Dat eigenlijk alleen als DIY oplossing gezien. Als kant en klaar kom je denk ik dan snel bij slimme sloten/cilinders.

[ Voor 4% gewijzigd door Septillion op 14-08-2022 13:11 ]

[Beekforel]

@Daros Ik heb ooit een aantal slotsensoren gemaakt op basis van Aqara deursensoren. Het werkte wel redelijk.

Voorbeeld: https://community.home-as...aditional-key-lock/314980 en https://community.home-as...nd-a-soldering-iron/49445

[Peatsmoke]

golles schreef op zondag 14 augustus 2022 @ 11:37:
[...]


Geen antwoord op je vraag, maar check deze even: https://github.com/golles/ha-knmi is misschien leuker dan een rest sensor

Daar heb ik hem van afgeleid , omdat de maximum van vandaag niet als entiteit beschikbaar was, of had ik het op een andere manier moeten doen?

[vonkkie]

@Daros

Kijk eens naar schoot contacten deze zijn makelijk met een esp uit telezen

[FutureCow]

Ik ben mij een beetje aan het oriënteren of ik ga overstappen op HA, zal de komende tijd wellicht nog wel eens vaker met een vraag komen. Eerste waar ik nu tegen aanloop in de "restore at startup". De waarden van mijn template sensors zijn na een restart unknow. Maar ik wil gebruik maken van een REST API, en stop de waarde van een Token in een template sensor. Na een herstart is deze waarde kwijt, en kan ik geen nieuwe token meer aanvragen. Hoe kan ik de waarde van een template terug zetten na een herstart van HA?

code:

  - platform: template
    sensors:
      access_token:
        friendly_name: "Access Token"
        value_template: "{{ state_attr('sensor.get_refrest_token', 'access_token') }}"
      refresh_token:
        friendly_name: "Refresh Token"
        value_template: "{{ state_attr('sensor.get_refrest_token', 'refresh_token') }}"

Had al wel iets gelezen over "trigger-based sensors" maar weet niet of dat de oplossing is? Wel vreemd dat dit zo lastig is?

[golles]

Peatsmoke schreef op zondag 14 augustus 2022 @ 13:29:
[...]

Daar heb ik hem van afgeleid , omdat de maximum van vandaag niet als entiteit beschikbaar was, of had ik het op een andere manier moeten doen?

Die zou je uit de weather entity kunnen halen:

YAML:

{{ state_attr("weather.knmi_purmerend", "forecast")[0].temperature }}

[Toppe]

.

[ Voor 99% gewijzigd door Toppe op 14-08-2022 20:48 ]

[Wilf]

Septillion schreef op vrijdag 17 juni 2022 @ 16:02:
@Wilf En deel twee?

Ik was een tijdje weg ivm werk maar nee helaas, ook andere tijden werken niet.

Voorbeeld:

YAML:

alias: Woon naar 'gezellig'
description: ""
trigger:
  - at: "22:00"
    platform: time
condition:
  - condition: state
    entity_id: input_boolean.filmstand
    state: "off"
  - condition: state
    entity_id: light.woonkamer
    state: "on"
action:
  - data:
      transition: 5.5
    service: scene.turn_on
    target:
      entity_id: scene.woon_warm
mode: single

Werkt ook niet. 2.5, 5.5. 150, 300... Het is gewoon direct aan. Geldt ook voor mijn lichtwekker:

YAML:

alias: Opstaan (werkweek)
description: Wekker doordeweeks (half uur eerder dan wektijd aan)
trigger:
  - platform: template
    value_template: >-
      {{ states('sensor.time') ==
      ((state_attr('input_datetime.werkweekwekker','timestamp') | int - 1800) |
      timestamp_custom('%H:%M', False)) }}
condition:
  - condition: state
    entity_id: binary_sensor.workday_sensor
    state: "on"
  - condition: state
    entity_id: input_boolean.wekker_aan
    state: "on"
action:
  - service: script.woon_opstaan_als_zon_op
    data: {}
  - data: {}
    entity_id: scene.nachtspot_uit
    service: scene.turn_on
  - data:
      entity_id: scene.sunrise_1
      transition: 150
    service: scene.turn_on
  - delay:
      hours: 0
      minutes: 2
      seconds: 30
      milliseconds: 0
  - data:
      entity_id: scene.sunrise_2
      transition: 150
    service: scene.turn_on
  - delay:
      hours: 0
      minutes: 2
      seconds: 30
      milliseconds: 0
  - data:
      entity_id: scene.sunrise_3
      transition: 300
    service: scene.turn_on
  - delay:
      hours: 0
      minutes: 5
      seconds: 0
      milliseconds: 0
  - data:
      entity_id: scene.sunrise_4
      transition: 300
    service: scene.turn_on
  - delay:
      hours: 0
      minutes: 0
      seconds: 0
      milliseconds: 0
  - data:
      entity_id: scene.sunrise_5
      transition: 300
    service: scene.turn_on
  - delay:
      hours: 0
      minutes: 5
      seconds: 0
      milliseconds: 0
  - data:
      entity_id: scene.sunrise_6
      transition: 600
    service: scene.turn_on
  - service: light.turn_on
    target:
      area_id:
        - dca73137e0be4f93bb3eaa0884952867
        - overloop
        - wc_boven
    data:
      transition: 300
      brightness_pct: 70
  - data:
      transition: 600
    service: scene.turn_on
    target:
      entity_id:
        - scene.nachtspot_vol
        - scene.buiten_aan
mode: single

Is gewoon BAM! aan sinds de update in die ik in juni had gedaan (weet niet meer van welke versie van welke want de maanden daarvoor zat ik in het buitenland).

Ook de transitions lager dan 600 (vind nog steeds bizar dat 300 max is; hoe kan je dan subtiele overgangen maken. Ik heb in een bepaalde theatervoorstelling zelfs scenes gehad met 15 minuten transitie, zo raar is dat niet; je ziet dan niet iets veranderen maar de sfeerverandering VOEL je en dat werkt echt ongelooflijk goed; in dit geval bijvoorbeeld om je om 22:00 langzaam moe te maken door het licht zacht en warm te maken).

Ik zit inmiddels op 8.3 en werkt nog steeds niet (meer).

[Step5]

Koepert schreef op zondag 14 augustus 2022 @ 08:45:
Ik ben aan t kijken naar n sonoff dongle plus als BU unit voor m’n deconz conbee II

Kan iemand me t verschil uitleggen (ik zie t wel maar snap t niet) tussen de E en P versie vd stick?


https://a.aliexpress.com/_mK0AWeo

Kun je de Conbee uberhaupt wel zonder meer uitwisselen met een ander type stick? En dan bedoel ik zonder opnieuw alles te pairen

[Koepert]

Step5 schreef op zondag 14 augustus 2022 @ 18:38:
[...]

Kun je de Conbee uberhaupt wel zonder meer uitwisselen met een ander type stick? En dan bedoel ik zonder opnieuw alles te pairen

Zover ik weet kan dat niet nee. Maar daarom was mijn intentie een soft-migratie.

- 2e stick erin
- Zigbee2MQTT inrichten
- Migreren waar ik zin in heb (nieuw spul sowieso, dan per groep (eerst lampen, dan sensoren, etc)
- Conbee uitfaseren op die manier
- Conbee als BU bewaren

Zoiets was t idee

[Polyphemus]

Step5 schreef op zondag 14 augustus 2022 @ 18:38:
[...]

Kun je de Conbee uberhaupt wel zonder meer uitwisselen met een ander type stick? En dan bedoel ik zonder opnieuw alles te pairen

Ik kon van een CC2351 naar een CC1352P-2 zonder slag of stoot over door alleen in Zigbee2mqtt de USB-poort te wijzigen. Ik hoefde niet te re-pairen. Maar misschien had ik geluk

[RobertMe]

Polyphemus schreef op zondag 14 augustus 2022 @ 19:39:
[...]

Ik kon van een CC2351 naar een CC1352P-2 zonder slag of stoot over door alleen in Zigbee2mqtt de USB-poort te wijzigen. Ik hoefde niet te re-pairen. Maar misschien had ik geluk

Hier toevallig vrijdag, eindelijk, hetzelfde gedaan. CC2531 naar Sonoff. Alleen de Hue lampen deden het niet meer. Nadat ik eentje had uit- en ingedraaid deden ze het wel weer. Totdat ik op het idee kwam om die ene lamp nog eens uit te draaien, en toen bleek, zoals verwacht, dat de rest het weer niet deed. Dus even alle lampen moeten nalopen.

Daarnaast bevat de Z2M documentatie ook een aantal stukken over het vervangen en migreren van de stick. Daarin staat ook dat je het beste het IEEE adres van de oude coördinator doet migreren/clonen naar de nieuwe. Dit omdat er ook ("slechte") devices zijn die niet met ee coördinator van het netwerk babbelen maar specifiek met het IEEE adres, van de coördinator. Zelf heb ik dat dus niet gedaan omdat ik dat nogal "vies" vind. En in principe ging dat dus goed met Hue (GU10 spotjes van de vorige generatie) en wat Xiaomi & Aqara sensoren (switch & wall switch, magneet contacten, PIR en temp sensor). Alleen moesten de Hue lampen dan een schop krijgen. Xiaomi/Aqara spul bleef meteen werken.

[banaliteit]

TheFes schreef op maandag 25 juli 2022 @ 21:23:
Onder het het motto van sharing is caring

Mocht je automations hebben die afhangen van weather entities, is het natuurlijk erg vervelend als die entity niet werkt. Je kunt natuurlijk een tweede weather entity integreren, maar dan moet je al je triggers/conditions dubbel gaan uitvoeren.

Om dat te voorkomen heb ik vandaag wat tijd gestoken in een template weather entity.

Uiteraard heb je daarvoor meerdere weather integraties nodig, ik gebruik nu buienradar (alleen daily forecasts), met.no (zowel daily als hourly), tomorrow.io (daily en hourly) pirateweather (HACS) ( zowel daily en hourly) en accueweather (alleen huidige data, geen forecast).

Ik heb vervolgens een template entity gemaakt die in een attribute een lijst maakt van alle weather entities die beschikbaar zijn, en daarbij de combined weather entities er uit filters. De weather entities moeten daily of hourly in de entity_id hebben om de juiste selectie te kunnen maken.

Op basis van die lijst heb ik vervolgens twee template weather entities gemaakt, voor de numerieke waardes (temperatuur, luchtdruk, regen) neemt hij gemiddeldes, en voor de huidige weerconditie neemt hij de waarde die het vaakst voorkomt in de verschillende entities.

Hier is de code (als een package);
https://github.com/TheFes...ges/combined_weather.yaml

Update:
Daily weather template is gefixt, en er komt geen floodload aan error messages in de log meer over template errors.
Verdere changes:

• datetimes in de forecast items zijn in local time (is wat duidelijker)
• bij elke forecast wordt aangeven van welke weather entities gebruik gemaakt wordt
• in de attribution van de weather enttiy zelf wordt ook aangegeven welke entities gebruikt worden
• geen naming convention foor de entity_ids meer nodig, de template sensor kijkt nu naar de tijd tussen de forecasts om te bepalen of het daily of hourly is

Ik krijg deze error:
Invalid config for [weather.template]: [temperature_unit] is an invalid option for [weather.template]. Check: weather.template->temperature_unit. (See ?, line ?).
Invalid config for [weather.template]: [temperature_unit] is an invalid option for [weather.template]. Check: weather.template->temperature_unit. (See ?, line ?).

Enig idee wat ik fout doe? Ik gebruik buienradar en tomorrow.

De combined_weather.yaml heb ik geconfigureerd op deze manier:

code:

homeassistant:
  customize: !include includes/customize.yaml
  packages: !include_dir_named packages/

Edit: ik zie 't al. Ik moet wel de juiste entities uit de integratie enablen.

[TheFes]

banaliteit schreef op zondag 14 augustus 2022 @ 22:11:
[...]

Ik krijg deze error:
Invalid config for [weather.template]: [temperature_unit] is an invalid option for [weather.template]. Check: weather.template->temperature_unit. (See ?, line ?).
Invalid config for [weather.template]: [temperature_unit] is an invalid option for [weather.template]. Check: weather.template->temperature_unit. (See ?, line ?).

Enig idee wat ik fout doe? Ik gebruik buienradar en tomorrow.

De combined_weather.yaml heb ik geconfigureerd op deze manier:

code:

homeassistant:
  customize: !include includes/customize.yaml
  packages: !include_dir_named packages/

Edit: ik zie 't al. Ik moet wel de juiste entities uit de integratie enablen.

Werkt het nu? Ik zie nog niet echt de link tussen je oplossing en de error. Eerlijk gezegd snap ik de error ook niet aangezien temperature_unit een hele valide optie is voor weather.template

[banaliteit]

TheFes schreef op maandag 15 augustus 2022 @ 08:52:
[...]


Werkt het nu? Ik zie nog niet echt de link tussen je oplossing en de error. Eerlijk gezegd snap ik de error ook niet aangezien temperature_unit een hele valide optie is voor weather.template

Als ik kijk naar de gekopieerde package code, dan zie ik ook een rode wiggly bij temperature_unit, pressure_unit etc.

De oorzaak is denk ik hoe ik mijn configuration.yaml heb ingericht. Zie jij misschien iets raars? Ik denk zelf dat de oorzaak ligt bij hoe ik de templates include

YAML:

#################################################################
## Includes
#################################################################
homeassistant:
  customize: !include includes/customize.yaml
  packages: !include_dir_named packages/

group: !include groups.yaml
automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml
light: !include lights.yaml
sensor: !include includes/sensor/sensors.yaml
utility_meter: !include utility_meter.yaml
template: !include_dir_merge_list includes/template/

[ Voor 0% gewijzigd door Septillion op 15-08-2022 11:36 . Reden: Denk aan de yaml-tags aub! ]

[TheFes]

banaliteit schreef op maandag 15 augustus 2022 @ 09:19:
[...]

Als ik kijk naar de gekopieerde package code, dan zie ik ook een rode wiggly bij temperature_unit, pressure_unit etc.

De oorzaak is denk ik hoe ik mijn configuration.yaml heb ingericht. Zie jij misschien iets raars? Ik denk zelf dat de oorzaak ligt bij hoe ik de templates include

code:

#################################################################
## Includes
#################################################################
homeassistant:
  customize: !include includes/customize.yaml
  packages: !include_dir_named packages/

group: !include groups.yaml
automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml
light: !include lights.yaml
sensor: !include includes/sensor/sensors.yaml
utility_meter: !include utility_meter.yaml
template: !include_dir_merge_list includes/template/

Zie niets geks. Ik neem aan dat je de hele code uit mijn config nu in de packages/ folder gezet hebt?

[Septillion]

Wilf schreef op zondag 14 augustus 2022 @ 18:15:
[...]
Ik was een tijdje weg ivm werk maar nee helaas, ook andere tijden werken niet.

Voorbeeld:

YAML:

alias: Woon naar 'gezellig'
description: ""
trigger:
  - at: "22:00"
    platform: time
condition:
  - condition: state
    entity_id: input_boolean.filmstand
    state: "off"
  - condition: state
    entity_id: light.woonkamer
    state: "on"
action:
  - data:
      transition: 5.5
    service: scene.turn_on
    target:
      entity_id: scene.woon_warm
mode: single

Werkt ook niet. 2.5, 5.5. 150, 300... Het is gewoon direct aan. Geldt ook voor mijn lichtwekker:

YAML:

alias: Opstaan (werkweek)
description: Wekker doordeweeks (half uur eerder dan wektijd aan)
trigger:
  - platform: template
    value_template: >-
      {{ states('sensor.time') ==
      ((state_attr('input_datetime.werkweekwekker','timestamp') | int - 1800) |
      timestamp_custom('%H:%M', False)) }}
condition:
  - condition: state
    entity_id: binary_sensor.workday_sensor
    state: "on"
  - condition: state
    entity_id: input_boolean.wekker_aan
    state: "on"
action:
  - service: script.woon_opstaan_als_zon_op
    data: {}
  - data: {}
    entity_id: scene.nachtspot_uit
    service: scene.turn_on
  - data:
      entity_id: scene.sunrise_1
      transition: 150
    service: scene.turn_on
  - delay:
      hours: 0
      minutes: 2
      seconds: 30
      milliseconds: 0
  - data:
      entity_id: scene.sunrise_2
      transition: 150
    service: scene.turn_on
  - delay:
      hours: 0
      minutes: 2
      seconds: 30
      milliseconds: 0
  - data:
      entity_id: scene.sunrise_3
      transition: 300
    service: scene.turn_on
  - delay:
      hours: 0
      minutes: 5
      seconds: 0
      milliseconds: 0
  - data:
      entity_id: scene.sunrise_4
      transition: 300
    service: scene.turn_on
  - delay:
      hours: 0
      minutes: 0
      seconds: 0
      milliseconds: 0
  - data:
      entity_id: scene.sunrise_5
      transition: 300
    service: scene.turn_on
  - delay:
      hours: 0
      minutes: 5
      seconds: 0
      milliseconds: 0
  - data:
      entity_id: scene.sunrise_6
      transition: 600
    service: scene.turn_on
  - service: light.turn_on
    target:
      area_id:
        - dca73137e0be4f93bb3eaa0884952867
        - overloop
        - wc_boven
    data:
      transition: 300
      brightness_pct: 70
  - data:
      transition: 600
    service: scene.turn_on
    target:
      entity_id:
        - scene.nachtspot_vol
        - scene.buiten_aan
mode: single

Is gewoon BAM! aan sinds de update in die ik in juni had gedaan (weet niet meer van welke versie van welke want de maanden daarvoor zat ik in het buitenland).

Ook de transitions lager dan 600 (vind nog steeds bizar dat 300 max is; hoe kan je dan subtiele overgangen maken. Ik heb in een bepaalde theatervoorstelling zelfs scenes gehad met 15 minuten transitie, zo raar is dat niet; je ziet dan niet iets veranderen maar de sfeerverandering VOEL je en dat werkt echt ongelooflijk goed; in dit geval bijvoorbeeld om je om 22:00 langzaam moe te maken door het licht zacht en warm te maken).

Ik zit inmiddels op 8.3 en werkt nog steeds niet (meer).

Ik bedoelde dus juist eens, probeer eens zonder scene. Dus gewoon een light met transitie te doen.

Verder moet ik zeggen dat ik er dus niet meer zo scherp heb allemaal. Heb ondertussen wel weer HA draaien dus kan deze week misschien wel eens even kijken wat ik zie.

[Toppe]

Ik heb net een NodeMCU voorzien van ESPHome, maar ik mis de knop ‘visit’. Is dit normaal?

[Koepert]

Toppe schreef op maandag 15 augustus 2022 @ 13:07:
Ik heb net een NodeMCU voorzien van ESPHome, maar ik mis de knop ‘visit’. Is dit normaal?
[Afbeelding]

Heb je in de config de 'webserver' gespecificeerd?

YAML:

# Enable Web server.
web_server:
  port: XX

Zonder, ga je er niet naartoe kunnen navigeren namelijk (dat hoeft ook niet altijd denk ik)

[Toppe]

Koepert schreef op maandag 15 augustus 2022 @ 13:14:
[...]


Heb je in de config de 'webserver' gespecificeerd?

YAML:

# Enable Web server.
web_server:
  port: XX

Zonder, ga je er niet naartoe kunnen navigeren namelijk (dat hoeft ook niet altijd denk ik)

Soms is het zo simpel

[Zorian]

Vraagje; Ik heb een HomeWizard watermeter (dus niet de P1 meter!) en wil graag de waterstand gaan bijhouden. Nou kan ik de watermeter prima toevoegen aan het dashboard, echter meet hij de waardes vanaf het installatiemoment en dus niet met inachtneming van de huidige stand.
Hoe kan ik de huidige waterstand invullen zodat ie de correcte waarde weergeeft?

[TheFes]

Zorian schreef op maandag 15 augustus 2022 @ 16:17:
Vraagje; Ik heb een HomeWizard watermeter (dus niet de P1 meter!) en wil graag de waterstand gaan bijhouden. Nou kan ik de watermeter prima toevoegen aan het dashboard, echter meet hij de waardes vanaf het installatiemoment en dus niet met inachtneming van de huidige stand.
Hoe kan ik de huidige waterstand invullen zodat ie de correcte waarde weergeeft?

Een template sensor aanmaken die er een getal (je meterstand op het moment van installatie, ofwel het verschil tussen je huidige meterstand en wat de sensor aangeeft) er bij optelt.
Je zou eventueel een input_number kunnen gebruiken, dan kun je afwijkingen eventueel nog makkelijk corrigeren.

[Zorian]

TheFes schreef op maandag 15 augustus 2022 @ 16:19:
[...]


Een template sensor aanmaken die er een getal (je meterstand op het moment van installatie, ofwel het verschil tussen je huidige meterstand en wat de sensor aangeeft) er bij optelt.
Je zou eventueel een input_number kunnen gebruiken, dan kun je afwijkingen eventueel nog makkelijk corrigeren.

Duidelijk, alleen hoe maak ik een template sensor aan?

[TheFes]

Zorian schreef op maandag 15 augustus 2022 @ 16:21:
[...]

Duidelijk, alleen hoe maak ik een template sensor aan?

Door zoiets in je configuration.yaml te zetten

YAML:

template:
  - sensor:
      - unique_id: watermeter_corrected_template_sensor
        name: Watermeter gecorrigeerd
        state: "{{ states('sensor.jouw_watermeter') | float + states('input_number.watermeter_correctie') | float }}"
        icon: mdi:water
        unit_of_measurement: m3
        availability: "{{ states('sensor.jouw_watermeter') | is_number }}"

Wel even sensor.jouw_watermeter op beide plekken vervangen door de goede entity_id en een input_number.watermeter_correctie aanmaken.

[Zorian]

Thanks, ga het proberen!

[Fabian]

Vaevictis_ schreef op zaterdag 24 april 2021 @ 19:36:
Op verzoek @DutchKel @Matis @bello2011 , mijn dashboard voor water/water Alpha Innotec WP. De integratie werkt met de HACS integratie voor Luxtronik.

Dank voor het delen !

Heb alles probleemloos kunnen overnemen met uitzondering van de COP waarden. Via verschillende templates en sensors is de bron van de COP berekening uiteindelijk iets uit

sensor.heatpump_import_watt_hours
en/of
luxtronik.gezamelijke_warmteproductie

Waar haal je deze uit ?
Is heatpump_import_watt_hours een template die uiteindelijk gebruik maakt van de externe kWh meter ?

[Vaevictis_]

Fabian schreef op maandag 15 augustus 2022 @ 17:05:
[...]


Dank voor het delen !

Heb alles probleemloos kunnen overnemen met uitzondering van de COP waarden. Via verschillende templates en sensors is de bron van de COP berekening uiteindelijk iets uit

sensor.heatpump_import_watt_hours
en/of
luxtronik.gezamelijke_warmteproductie

Waar haal je deze uit ?
Is heatpump_import_watt_hours een template die uiteindelijk gebruik maakt van de externe kWh meter ?

gezamelijke_warmteproductie wordt gesplitst met een utilty meter en import_watt_hours is een externe fysieke modbus kWh meter.

[Johnny5]

TheFes schreef op maandag 15 augustus 2022 @ 16:59:
[...]


Door zoiets in je configuration.yaml te zetten

YAML:

template:
  - sensor:
      - unique_id: watermeter_corrected_template_sensor
        name: Watermeter gecorrigeerd
        state: "{{ states('sensor.jouw_watermeter') | float + states('input_number.watermeter_correctie') | float }}"
        icon: mdi:water
        unit_of_measurement: m3
        availability: "{{ states('sensor.jouw_watermeter') | is_number }}"

Wel even sensor.jouw_watermeter op beide plekken vervangen door de goede entity_id en een input_number.watermeter_correctie aanmaken.

Hoi,

Ik zit toevallig met een soortgelijke situatie met dezelfde meter. Thanks voor de duidelijke uitleg want niet veel op internet maakte voor mij duidelijk waar de suggesties nou eigenlijk geplaatst moesten worden.
Er mist nog wel iets... of ik heb toch nog iets fout gezet.
Zie de screenshot. Ik heb de sensor naam/ID gekopieerd, die total is welke de 0.295 weergeeft op het dashboard. Daar laat ik 445 bij optellen, maar de uitkomst is unknown.

https://cdn.discordapp.co...9534220058654/unknown.png

EDIT:
EXCUSEER mijn re****ness. je voorbeeld werkte met een input variabele dus ik moest de parsing van die variabele weg laten natuurlijk. In dat geval werkt dit goed voor mij:

YAML:

state: "{{ states('sensor.watermeter_3c39e72d69e2_total_water_usage') | float + 445 | float }}"

[ Voor 10% gewijzigd door Johnny5 op 15-08-2022 20:31 ]

[_Marcel_1973]

Of het nu door de update naar 2022.8 of een stroomstoring in de wijk komt maar de Home en Home mini van Google lijken te zijn overleden.
Staan nog twee Nest mini’s die het wel gewoon doen.

Na diverse soft en harde resets, terug naar fabrieksinstellingen etc. heb ik het maar opgegeven. Morgen een nieuwe Nest mini en hub halen. Kan ik gelijk alles maar opnieuw inregelen, want ze zijn ook niet meer zichtbaar en geconnect met Wifi. Ja, max vijf minuutjes en dan zijn ze weer verdwenen.

Kan ik mooi eens kijken of de ingebakken assistant functie in HA werkt, samen met aliassen via cloud.yaml.

[TheFes]

Johnny5 schreef op maandag 15 augustus 2022 @ 20:25:
[...]


Hoi,

Ik zit toevallig met een soortgelijke situatie met dezelfde meter. Thanks voor de duidelijke uitleg want niet veel op internet maakte voor mij duidelijk waar de suggesties nou eigenlijk geplaatst moesten worden.
Er mist nog wel iets... of ik heb toch nog iets fout gezet.
Zie de screenshot. Ik heb de sensor naam/ID gekopieerd, die total is welke de 0.295 weergeeft op het dashboard. Daar laat ik 445 bij optellen, maar de uitkomst is unknown.

https://cdn.discordapp.co...9534220058654/unknown.png

EDIT:
EXCUSEER mijn re****ness. je voorbeeld werkte met een input variabele dus ik moest de parsing van die variabele weg laten natuurlijk. In dat geval werkt dit goed voor mij:

YAML:

state: "{{ states('sensor.watermeter_3c39e72d69e2_total_water_usage') | float + 445 | float }}"

Je hoeft die 455 niet naar een float om te zetten, dat is al een getal.
States zijn echter altijd strings, dus daar kun je niet mee rekenen, vandaar dat dit omgezet moeten worden naar een getal.

[Toppe]

Ik krijg morgen een afstandssensor binnen die ik aan ESPHome ga knopen. Nu wil ik eigenlijk een ‘bereik’ kunnen bepalen aan de hand van de waarde.

Aangezien ik nog even met de hoogtes zou moeten spelen doe ik hier even op percentages:

100% is 25kg
50% is 12.5kg
10% is 2.5kg

Enzovoort.

Iemand enig idee of dat direct in ESPHome kan of dat ik hiervoor een aparte sensor moet aanmaken?

[-Casper]

Toppe schreef op maandag 15 augustus 2022 @ 20:50:
Ik krijg morgen een afstandssensor binnen die ik aan ESPHome ga knopen. Nu wil ik eigenlijk een ‘bereik’ kunnen bepalen aan de hand van de waarde.

Aangezien ik nog even met de hoogtes zou moeten spelen doe ik hier even op percentages:

100% is 25kg
50% is 12.5kg
10% is 2.5kg

Enzovoort.

Iemand enig idee of dat direct in ESPHome kan of dat ik hiervoor een aparte sensor moet aanmaken?

Iemand deelde laatst nog een water ontharder zout checker met afstandsmeter. Daar staat dit in de YAML:

YAML:

  - platform: ultrasonic
    trigger_pin: D1
    echo_pin: D2
    name: "Saltlevel in cm"
    update_interval: 12h
    filters:
    # Replace the 0.42 by the height of your container. From the sensor to the bottom.
    # I multiplied by 100 in order to get CM since the sensor works in meters
    - lambda: return (0.42-x)*100;
    unit_of_measurement: "cm"

Die kan je vast om tweaken

[_Marcel_1973]

Snoekieboe schreef op dinsdag 9 augustus 2022 @ 22:24:
[...]


Ik heb dit opgelost met een ESP8266+HC-SR04 ultrasone sensor en Tasmota.
Deze sensor meet de afstand van het deksel tot de bovenkant van het zout. Ik heb in HA geconfigureerd dat bij een waarde van 80cm tussen deksel en bovenkant zout ik een friendly reminder ontvang om het zout bij te vullen.

[Afbeelding]

Heb jij metingen die scherp genoeg zijn, hier fluctueert het best erg, terwijl de sensor etc niet bewegen of het zout wordt bijgevuld. Ik ga binnenkort iig sensor maar eens vervangen.
Ik gebruik script van Adonno.

[keekeboo]

Heb Rhasspy op een Rpi4 aan home assistant geknoopt (nuc). Werkt prima met een jabra speakerphone, maar das een beetje prijzig als permanente oplossing. Dus zoek ik een goedkope speakerphone die aardig werkt en er graag ook nog een beetje leuk uitziet (zonder Bluetooth of batterij). Heeft iemand een tip?

[loewie1984]

Ik heb vandaag de coinbase add-on geconfigureerd binnen HA, nu krijg ik 1 service te zien en 2 entities, namelijk de exchange rate van een coin (in dit geval BTC) en het aantal crypto's dat ik heb.
Wat ik echter had willen zien is de verwachte waarde van het aantal crypto's.

Iemand hier toevallig iets op gevonden?

[Snoekieboe]

_Marcel_1973 schreef op maandag 15 augustus 2022 @ 21:06:
[...]


Heb jij metingen die scherp genoeg zijn, hier fluctueert het best erg, terwijl de sensor etc niet bewegen of het zout wordt bijgevuld. Ik g.....]

Ik gebruik de sensor in combinatie met een ESP8266 waarop ik Tasmota draai. De libraries die daar gebruikt worden om de sensor te lezen leveren goede resultaten op. Er zijn wel wat kleine fluctuaties in de meting, maar die dicht ik toe aan reflecties van het ultrasoon signaal in het zoutvat.

[_Marcel_1973]

Snoekieboe schreef op maandag 15 augustus 2022 @ 22:03:
[...]


Ik gebruik de sensor in combinatie met een ESP8266 waarop ik Tasmota draai. De libraries die daar gebruikt worden om de sensor te lezen leveren goede resultaten op. Er zijn wel wat fluctuaties in de meting, maar die dicht ik toe aan reflecties van het ultrasoon signaal in het zoutvat.

Heb je daar een linkje/verwijzing van @Snoekieboe ?
Eens kijken of ik de esp kan omzetten hier.

[Soullancer]

Kom toevallig deze tegen in een ander topic

https://www.lidl.nl/p/sil...bee-smart-home/p100346900

Mensen die deze adviseren of goede ervaring mee hebben? Met name vanwege de verbruiksmeter vind ik hem interessant.

Maar zo zijn er ook blitzwolf, tuya, sonoff, enz welke misschien beter aanbevolen worden met home assistant?

[banaliteit]

TheFes schreef op maandag 15 augustus 2022 @ 09:33:
[...]


Zie niets geks. Ik neem aan dat je de hele code uit mijn config nu in de packages/ folder gezet hebt?

Ik heb de inhoud van weather_combined.yaml gekopieerd naar mijn weather_combined.yaml file en deze in de folder packages gezet.

Ik heb ook geprobeerd verschillende includes uit te commenten, maar hij blijft deze melding geven. Ik weet het even niet meer. Even erop broeden.

[Snoekieboe]

_Marcel_1973 schreef op maandag 15 augustus 2022 @ 23:02:
[...]


Heb je daar een linkje/verwijzing van @Snoekieboe ?
Eens kijken of ik de esp kan omzetten hier.

Het is eigenlijk zo eenvoudig als:

* Tasmota flashen op je ESP -> https://tasmota.github.io/install/
* Configureren als "Generic Module (18)" in de "configure module" sectie
* Sensor aansluiten op GPIO4 (RX) en GPIO5 (TX)
* In tasmota (wederom bij configure module) de juiste sensor configuratie geven (zie screenshot)
* MQTT configureren in Tasmota (eventueel Setoption19 1 voor autodiscovery van de module in HA)
* Tasmota herstarten

Et voila! Een werkende zoutmeter in HA die bij elke update (standaard elke 5 seconden volgens mij) een
waarde van je zoutniveau uitstuurt.

[ Voor 0% gewijzigd door Snoekieboe op 16-08-2022 10:46 . Reden: type ]

[TheFes]

banaliteit schreef op dinsdag 16 augustus 2022 @ 07:32:
[...]

Ik heb de inhoud van weather_combined.yaml gekopieerd naar mijn weather_combined.yaml file en deze in de folder packages gezet.

Ik heb ook geprobeerd verschillende includes uit te commenten, maar hij blijft deze melding geven. Ik weet het even niet meer. Even erop broeden.

Je draait wel gewoon een recente versie van HA?

[Toppe]

Soullancer schreef op maandag 15 augustus 2022 @ 23:55:
Kom toevallig deze tegen in een ander topic

https://www.lidl.nl/p/sil...bee-smart-home/p100346900

Mensen die deze adviseren of goede ervaring mee hebben? Met name vanwege de verbruiksmeter vind ik hem interessant.

Maar zo zijn er ook blitzwolf, tuya, sonoff, enz welke misschien beter aanbevolen worden met home assistant?

Ik heb ze nu van Athom.tech waarbij de prijs relatief vergelijkbaar is. Had een 2-pack besteld en die had ik een week later in huis.

Die van mij heb ik besteld met ESPHome en dat bevalt prima.

[TheFes]

Soullancer schreef op maandag 15 augustus 2022 @ 23:55:
Kom toevallig deze tegen in een ander topic

https://www.lidl.nl/p/sil...bee-smart-home/p100346900

Mensen die deze adviseren of goede ervaring mee hebben? Met name vanwege de verbruiksmeter vind ik hem interessant.

Maar zo zijn er ook blitzwolf, tuya, sonoff, enz welke misschien beter aanbevolen worden met home assistant?

Zullen prima werken, mits je een Zigbee stick hebt. Echter als je ook stroommeting wil, zou ik een BlitzWolf SHP13 of BlitzWolf SHP15 aanraden.

[Septillion]

loewie1984 schreef op maandag 15 augustus 2022 @ 21:47:
Ik heb vandaag de coinbase add-on geconfigureerd binnen HA, nu krijg ik 1 service te zien en 2 entities, namelijk de exchange rate van een coin (in dit geval BTC) en het aantal crypto's dat ik heb.
Wat ik echter had willen zien is de verwachte waarde van het aantal crypto's.

Iemand hier toevallig iets op gevonden?

(State based) template sensor aanmaken

Zoiets denk ik:

YAML:

template:
  - sensor:
      unique_id: btc_expected
      name: "My expected BTC value"
      unit_of_measurement: "$"
      device_class: monetary
      state: "{{ states('sensor.btc_mine')|float * states('sensor.btc_rate')|float }}"
      availability: "{{states('sensor.btc_mine')|is_number and states('sensor.btc_rate')|is_number }}"

Wel de juiste sensor namen gebruiken natuurlijk

[Septillion]

Snoekieboe schreef op dinsdag 16 augustus 2022 @ 07:43:
* MQTT configureren in Tasmota (eventueel Setoption19 1 voor autodiscovery van de module in HA)

Tegenwoordig niet echt meer aan te raden. Met SetOption19 = 0 maakt Tasmota gebruik van de Tasmota integratie en heb je (betere) auto-discovery dan via de (ondertussen legacy) MQTT discovery die je hebt met SetOption19 = 1.

[Snoekieboe]

vandaar ook de toevoeging "optioneel" :-) maar goed om dat nog even expliciet te maken

[ Voor 35% gewijzigd door Snoekieboe op 16-08-2022 10:44 ]

[Septillion]

@Snoekieboe Noemde het nog even omdat het zo klonk dat je SetOption19 = 1 nodig hebt voor auto-discovery maar dat dit niet zo is. Het zorgt alleen voor lagacy discovery ipv Tasmota integratie disovery. Laatste biedt vaak betere auto discovery.

[oltk]

TheFes schreef op dinsdag 16 augustus 2022 @ 08:50:
[...]


Zullen prima werken, mits je een Zigbee stick hebt. Echter als je ook stroommeting wil, zou ik een BlitzWolf SHP13 of BlitzWolf SHP15 aanraden.

Was er niet iets met Blitzwolf? CyberThijs in "Home Assistant: Open source Python3 home automation - deel 4"

Ik heb zelf de Shelly S (tot 2500 W) en de "gewone" Shelly plug (tot 3500 W).

[Mimiix]

oltk schreef op dinsdag 16 augustus 2022 @ 11:07:
[...]


Was er niet iets met Blitzwolf? CyberThijs in "Home Assistant: Open source Python3 home automation - deel 4"

Ik heb zelf de Shelly S (tot 2500 W) en de "gewone" Shelly plug (tot 3500 W).

Ja. Die dingen hebben verschillende chips. De SHP13 is relatief consistent daarin (doet niet aan reporting). Er zijn bij de SHP15 een aantal die zelf rapporteren en een aantal die dat niet doen.

[TheFes]

Mimiix schreef op dinsdag 16 augustus 2022 @ 11:11:
[...]


Ja. Die dingen hebben verschillende chips. De SHP13 is relatief consistent daarin (doet niet aan reporting). Er zijn bij de SHP15 een aantal die zelf rapporteren en een aantal die dat niet doen.

De SHP15 werkt wel gewoon in Deconz toch? Volgens dit overzicht namelijk niet
https://zigbee.blakadder.com/BlitzWolf_BW-SHP15.html (althans niet confirmed)

[Mimiix]

TheFes schreef op dinsdag 16 augustus 2022 @ 11:31:
[...]


De SHP15 werkt wel gewoon in Deconz toch? Volgens dit overzicht namelijk niet
https://zigbee.blakadder.com/BlitzWolf_BW-SHP15.html (althans niet confirmed)

Ja, maar als je dus een chip krijgt die nog niet ondersteund is werkt het niet gelijk en moet je de DDF aanpassen

Dat is het probleem een beetje met die apparaten.

[Beekforel]

Beekforel schreef op zaterdag 13 augustus 2022 @ 15:04:
[...]

Dat gaat helaas niet op, mijn power consumption is hoger dan 0 omdat ik maar op 1 fase teruglever en power consumption uit P1 alle fasen optelt. De "tellers" van vebruik blijven wel op 0 staan zolang ik meer opwek dan verbruik.

Maar ik bedacht net: als opwek > 0 dan opwek - teruglevering en anders P1 afname. Even prutsen met een template.

Dit lijkt te doen wat ik wens:

YAML:

      calculated_energy_usage:
        friendly_name: Energieverbruik (berekend)
        unit_of_measurement: 'Watt'
        value_template: >
          {% if float(states('sensor.total_output_power')) > 0 %}
            {{ (states('sensor.total_output_power')|float) - (states('sensor.power_production')|float)*1000 }}
          {% else %}
            {{ (states('sensor.power_consumption')|float)*1000 }}
          {% endif %}

Hm, klopt toch niet helemaal. M'n power_consumption geeft meer aan dan m'n berekende variant. irritante errors met Growatt gooien roet in het eten
De intervallen van de beide sensoren verschillen dus wordt een zaagtand grafiek helaas.

Hier klopt sowieso net niks van zodra er meer verbruik dan opwek is. Toch niet zo eenvoudig als ik dacht dit.

Heb hem inmiddels al weer iets verfijnd:

YAML:

      - name: Energieverbruik (berekend)
        state: >
          {% if float(states('sensor.power_production')) > 0 and (not is_state('sensor.total_output_power', 'unavailable')) %}
            {{ ((states('sensor.power_consumption')|float)*1000 - (states('sensor.power_production')|float)*1000 + (states('sensor.total_output_power')|float))|round(2, default=0)  }}
          {% else %}
            {{ (states('sensor.power_consumption')|float)*1000 }}
          {% endif %}
        unit_of_measurement: 'Watt'
        state_class: measurement
        unique_id: calculated_energy_usage
        device_class: energy

Maar de updateintervallen van sensor.power_production en sensor.total_output_power zijn ongelijk waardoor dit nog niet een helemaal betrouwbare sensor is. Ik dacht misschien kan ik de interval van deze templatesensor wat lager zetten maar dat zal alsnog potentieel verkeerde waardes kunnen geven.

Iemand nog een slim idee?

[ Voor 0% gewijzigd door Septillion op 16-08-2022 11:51 . Reden: Denk aan de yaml-tags aub! ]

[loewie1984]

Septillion schreef op dinsdag 16 augustus 2022 @ 10:04:
[...]

(State based) template sensor aanmaken

Zoiets denk ik:

YAML:

template:
  - sensor:
      unique_id: btc_expected
      name: "My expected BTC value"
      unit_of_measurement: "$"
      device_class: monetary
      state: "{{ states('sensor.btc_mine')|float * states('sensor.btc_rate')|float }}"
      availability: "{{states('sensor.btc_mine')|is_number and states('sensor.btc_rate')|is_number }}"

Wel de juiste sensor namen gebruiken natuurlijk

Het blijkt dat ik met een entity item in het dashboard het attribute "Balance in native currency" kan weergeven en daarmee zie ik de actuele waarde. Toch bedankt voor je reactie!

[TheFes]

Beekforel schreef op dinsdag 16 augustus 2022 @ 11:44:
[...]

Heb hem inmiddels al weer iets verfijnd:

YAML:

      - name: Energieverbruik (berekend)
        state: >
          {% if float(states('sensor.power_production')) > 0 and (not is_state('sensor.total_output_power', 'unavailable')) %}
            {{ ((states('sensor.power_consumption')|float)*1000 - (states('sensor.power_production')|float)*1000 + (states('sensor.total_output_power')|float))|round(2, default=0)  }}
          {% else %}
            {{ (states('sensor.power_consumption')|float)*1000 }}
          {% endif %}
        unit_of_measurement: 'Watt'
        state_class: measurement
        unique_id: calculated_energy_usage
        device_class: energy

Maar de updateintervallen van sensor.power_production en sensor.total_output_power zijn ongelijk waardoor dit nog niet een helemaal betrouwbare sensor is. Ik dacht misschien kan ik de interval van deze templatesensor wat lager zetten maar dat zal alsnog potentieel verkeerde waardes kunnen geven.

Iemand nog een slim idee?

Dat default op je round heeft niet zo veel zin, je template is al lang in error op de float filters als er iets fout is in je input.
Weet je wat het update interval van beide sensoren is? Je zou eventueel een trigger based template sensor kunnen gebruiken en op de traagste triggeren.

[Septillion]

@Beekforel Waarom de if? Of wordt je omvormer 's nachts unavailable?

Maar zelfs als dat het geval is, is het niet logisch om op 'power_production' te checken. Want als je dan niet terug levert maar wel PV opwek hebt mis je dat deel in je eigen energieverbruik.

En voor bonus punten kan avilability parameter toevoegen aan de sensor.

Voor het probleem met verschillende intervallen va je P1 en je omvormer zou ik deze sensor weer door een statistics mean sensor halen. Dan gemiddelde nemen over minimaal 1 a 2 keer de tijd van de traagst updatende sensor denk ik.

[ Voor 30% gewijzigd door Septillion op 16-08-2022 12:01 ]

[Beekforel]

@Septillion de Growatt integratie is wat onbetrouwbaar helaas, de if zorgt voor minder gedoe.

Maar er is inderdaad nog een moment dat deze sensor niet klopt wanneer er wel opwek is maar geen teruglevering, zal daar nog naar kijken.

Ik ga even wat testen met trigger based zoals @TheFes aangeeft en zal dan ook availability toevoegen!

[crimby]

Sinds een paar weken heb ik bij 1 grafiek (incl de historie van de sensor) dat deze behoorlijke dips laat zien.
De luchtvochtigheid, gemeten door hetzelde apparaat, gaat wel goed.


Hetzelfde grafiekje van een andere multisensor (zelfde merk en type) gaat ook goed.


Als ik over een langere periode kijk, zie je dat de sensor het wel goed deed maar ineens niet meer.


Kan ik dan concluderen dat de sensor kapot is of kan ik iets in HA aanpassen dat dit wel weer goed gaat?

YAML:

type: vertical-stack
cards:
  - type: custom:apexcharts-card
    header:
      show: true
      title: Temperatuur
    series:
      - entity: sensor.temperature_13
        stroke_width: 2
    update_interval: 10min
    graph_span: 7d
    cache: true
  - type: custom:apexcharts-card
    header:
      show: true
      title: Vochtigheid
    series:
      - entity: sensor.humidity_14
        stroke_width: 2
    update_interval: 10min
    graph_span: 7d
    cache: true

[Septillion]

@Beekforel Denk dat mooiste oplossing dan is de hele if weg te halen en het met de anavailable te regelen. Immers als je de info van de omvormer niet hebt kan je niets over je eigen verbruik zeggen dus zou ik het logisch vinden dat je sensor dan ook anavailable wordt.

Uitzondering hierop is als de sensor van je omvormer elke nacht gewoon unavailable gaat. Dan zou het wel onhandig zijn dat je dan geen verbruik kunt aflezen. Maar dan is de enige check die je moet doen dat je omvormer een waarde uit geeft. Checken op 'power_production' moet je dan gewoon weg laten uit de if. Eventueel een error-state toevoegen als je omvormer geen waarde geeft maar je wel 'power_production' hebt.

Op zich zou trigger based op de traagste ook wel een oplossing zijn ja.

[Septillion]

@crimby Hij lijkt heel steady naar -100 te gaan soms dus ja, de lijkt me stuk. Enige wat je dan in HA zou kunnen doen is een template sensor er mee maken die de -100 negeert en dan de oude waarde bewaard of unavailable wordt. Maar goed, dat is dan een work around.

[crimby]

Septillion schreef op dinsdag 16 augustus 2022 @ 12:09:
@crimby Hij lijkt heel steady naar -100 te gaan soms dus ja, de lijkt me stuk. Enige wat je dan in HA zou kunnen doen is een template sensor er mee maken die de -100 negeert en dan de oude waarde bewaard of unavailable wordt. Maar goed, dat is dan een work around.

was er al een beetje bang voor toen ik het bericht typte. Binnenkort maar eens een nieuwe bestellen dan

[TheFes]

Septillion schreef op dinsdag 16 augustus 2022 @ 12:06:
@Beekforel Denk dat mooiste oplossing dan is de hele if weg te halen en het met de anavailable te regelen. Immers als je de info van de omvormer niet hebt kan je niets over je eigen verbruik zeggen dus zou ik het logisch vinden dat je sensor dan ook anavailable wordt.

Uitzondering hierop is als de sensor van je omvormer elke nacht gewoon unavailable gaat. Dan zou het wel onhandig zijn dat je dan geen verbruik kunt aflezen. Maar dan is de enige check die je moet doen dat je omvormer een waarde uit geeft. Checken op 'power_production' moet je dan gewoon weg laten uit de if. Eventueel een error-state toevoegen als je omvormer geen waarde geeft maar je wel 'power_production' hebt.

Op zich zou trigger based op de traagste ook wel een oplossing zijn ja.

float(0) werkt natuurlijk ook gewoon prima als de sensor unavailable tijdens de nacht is

[Septillion]

@TheFes Vanuit een error perspectief wel ja. Vanuit het dan hebben van kloppende info natuurlijk niet

[Beekforel]

@TheFes @Septillion

YAML:

  - trigger:
      platform: state
      entity_id: sensor.total_output_power
    sensor:
      - name: Energieverbruik (berekend)
        state: >
            {% set consumption = states('sensor.power_consumption')| float*1000 %}
            {% set production = states('sensor.power_production')| float*1000 %}
            {% set solar_production = states('sensor.total_output_power') | float %}
            {{ (consumption - production + solar_production) | round(2, default=0)  }}
        unit_of_measurement: 'Watt'
        state_class: measurement
        unique_id: calculated_energy_usage
        device_class: energy
        availability: >
          {{ (not is_state('sensor.total_output_power', 'unavailable')) }}

Zoiets zou het dan worden. Kom er nu wel achter dat m'n solar wel heeel traag update dus even aankijken of dit nou zo handig is. Zal ook wat testen met zo'n statistics sensor.

[ Voor 0% gewijzigd door Septillion op 16-08-2022 12:29 . Reden: Denk aan de yaml-tags aub! ]

[Septillion]

@Beekforel Traagste sensor zal altijd leidend zijn natuurlijk. Maar met een statistics sensor zou je al wel een beetje verandering moeten kunnen zien. Zit alleen even te kijken en denk dat een average_linear hier beter is dan een mean.

[Peatsmoke]

CyberThijs schreef op donderdag 6 januari 2022 @ 11:33:
[...]


Ik zou momenteel de aankoop van Zigbee plugs geproduceerd door TuYa (zoals bijv. de Blitzwolf SHP-13 of SHP-15) afraden. Ik kreeg begin vorige maand plugs geleverd (aangekocht op banggood.com), en na wat debuggen ben ik tot de vaststelling gekomen dat deze geleverd zijn met een nieuwe firmware-versie waarbij TuYa heel wat functionaliteit (bewust?) heeft gebroken door ze te verhuizen naar een private API (cfr. https://github.com/Koenkk/zigbee2mqtt/issues/9057 )

Concreet: de plugs rapporteren niet meer automatisch een verandering van status. Het gebruik van de knop op de plug om aan/uit te schakelen kan je niet via Zigbee detecteren

Hopelijk krijgen we het nog gefixed, maar zal afhangen van de goodwill van TuYa.

Da's mooi k*t, er zijn er twee onderweg vanuit China...

[TheFes]

Peatsmoke schreef op dinsdag 16 augustus 2022 @ 12:36:
[...]

Da's mooi k*t, er zijn er twee onderweg vanuit China...

Inmiddels werken ze wel weer hoor, alleen het is nu polling geworden in plaast van dat ze zelf de upates pushen.

[crimby]

Wat zijn een beetje de DB groottes bij jullie? Zit hier nu op 10gb en daar komt maandelijks 1-2GB op. Heb de purge op 730 dagen staan zodat ik 2 jaar bij houdt (ivm vergelijkingen). Dus ik zou op ongeveer 25-30gb uitkomen dan. Ik gebruik een SSD van 450gb, dus dat is geen probleem.

Op dit moment sluit ik geen data uit, dus alle sensor data blijft bewaard voor de ingestelde periode. Dit kan ik wel optimaliseren natuurlijk, maar wel benieuwd of dat nodig is.

[Mimiix]

crimby schreef op dinsdag 16 augustus 2022 @ 12:05:
Sinds een paar weken heb ik bij 1 grafiek (incl de historie van de sensor) dat deze behoorlijke dips laat zien.
De luchtvochtigheid, gemeten door hetzelde apparaat, gaat wel goed.
[Afbeelding]

Hetzelfde grafiekje van een andere multisensor (zelfde merk en type) gaat ook goed.
[Afbeelding]

Als ik over een langere periode kijk, zie je dat de sensor het wel goed deed maar ineens niet meer.
[Afbeelding]

Kan ik dan concluderen dat de sensor kapot is of kan ik iets in HA aanpassen dat dit wel weer goed gaat?

YAML:

type: vertical-stack
cards:
  - type: custom:apexcharts-card
    header:
      show: true
      title: Temperatuur
    series:
      - entity: sensor.temperature_13
        stroke_width: 2
    update_interval: 10min
    graph_span: 7d
    cache: true
  - type: custom:apexcharts-card
    header:
      show: true
      title: Vochtigheid
    series:
      - entity: sensor.humidity_14
        stroke_width: 2
    update_interval: 10min
    graph_span: 7d
    cache: true

Meestal doen ze dit als de batterij bijna op is.