chrlod

Har prøvd meg på et par automasjoner for dette som ser ut til å fungere tilfredsstillende: Delte automasjonene i to, en for å øke ladehastighet og en for å redusere den. Det sjekkes hvert minutt om bilen er hjemme, om lading er aktiv og justerer evt. ladestrøm mellom 6-16A (3-fas 400V) for å utnytte effektleddet. Jeg benytter estimert forbruk inneværende time i stedet for faktisk forbruk for å kunne utnytte høyere ladehastighet om lading skulle starte uti en time. Jeg benytter meg foreløpig av Tibber for å starte lading basert på strømpris, så disse automasjonene er kun for å optimalisere ladehastigheten i forhold til øvrige laster. Har aldri erfart behov for å stoppe lading for ikke å overskride ønsket effektledd, så det er ikke implementert noen logikk for det. Redusere: alias: TMS charge rate decrease description: "" trigger: - platform: time_pattern minutes: /1 condition: - condition: and conditions: - condition: device device_id: 03a6af1c965b7876f572d3da5bf7de6e domain: device_tracker entity_id: e775722f6b8cb897543a664c8939ed84 type: is_home #sjekker at bilen er hjemme - type: is_charging #sjekker at lading er aktiv condition: device device_id: 03a6af1c965b7876f572d3da5bf7de6e entity_id: 573aab4b8954590eb9af5cbb407c714a domain: binary_sensor - condition: numeric_state entity_id: number.tesa_model_s_charging_amps above: 6 #begrenser reduksjon nedad til 6A - condition: numeric_state entity_id: sensor.estimated_consumption_current_hour above: 9.8 #reduserer ladehastighet når estimert forbruk inneværende time er over 9,8 kWh. Estimatet har noe treghet. action: - service: number.set_value data: value: "{{ (states.number.tesa_model_s_charging_amps.state | int ) - 1 }}" #reduserer ladestrøm med 1A target: entity_id: number.tesa_model_s_charging_amps mode: single Øke: alias: TMS charge rate increase description: "" trigger: - platform: time_pattern minutes: /1 condition: - condition: and conditions: - condition: device device_id: 03a6af1c965b7876f572d3da5bf7de6e domain: device_tracker entity_id: e775722f6b8cb897543a664c8939ed84 type: is_home #sjekker at bilen er hjemme - type: is_charging #sjekker at lading er aktiv condition: device device_id: 03a6af1c965b7876f572d3da5bf7de6e entity_id: 573aab4b8954590eb9af5cbb407c714a domain: binary_sensor - condition: numeric_state entity_id: number.tesa_model_s_charging_amps below: 16 #begrenser ladehastighet oppad til 16A - condition: numeric_state entity_id: sensor.estimated_consumption_current_hour below: 9.5 #øker ladehastighet om estimert forbruk inneværende time er lavere enn 9,5 kWh. Estimatet har noe treghet - condition: template value_template: >- {{ now() - state_attr('automation.tms_charge_rate_decrease', 'last_triggered') > timedelta(minutes=5) }} #for å redusere svingninger må det være mer enn 5 nmin siden automasjon for å redusere hastighet har kjørt action: - service: number.set_value data: value: "{{ (states.number.tesa_model_s_charging_amps.state | int ) + 1 }}" #øker ladehastighet med 1A target: entity_id: number.tesa_model_s_charging_amps mode: single Kun fått prøvd ut 1 gang, så mulig den trenger noe tuning på hvor lenge den skal vente med å øke etter en reduksjon av ladehastighet, eller parametre for estimert forbruk for å komme nærmest 10 kWh uten å overskyte.

Det begynner å bli flere automasjoner som ønsker å kjøre når prisen er lavest. Lading av elbil er den desidert mest effektkrevende aktiviteten, og der har jeg mulighet til å sette ladestrøm mellom 6-16A (3-fas 400V). Jeg ser det derfor som hensiktsmessig å justere denne for å utnytte lave strømpriser maksimalt, men samtidig holde meg innenfor ønsket effekttrinn. Ønsket effekttrinn er for øyeblikket 10 kWh - minus en liten sikkerhetsmargin. Tenker det er fornuftig å bruke sensor for estimert forbruk inneværende time (sensor.estimated_consumption_current_hour), slik at det kan benyttes høyere ladehastighet om ladingen starter uti en time. Ladehastighet justeres på: number.tesa_model_s_charging_amps Hvordan best sette opp en automasjon som justerer ladehastighet f.eks hvert minutt mellom 6-16A?

Andre som har problemer med modbus etter siste oppdatering av HA?

Mitt VTR300 hadde følgende fabrikkinnstillinger: (Slave)adresse: 1 Baudrate: 9600 Paritet: Even GND er vel ikke nødvendig her? Er ikke i bruk hos meg hvert fall. Jeg druknet en hel del timer i at manualen hadde feil på +/-. Hos meg er dette en RJ45 kontakt og skulle være leder 4 og 5. problemet var at festehaken for RJ45- kontakten var tegnet inn og jeg brukte denne som referanse for hvilken side man skulle telle fra. I manualen er den nok kun tegnet inn for illustrasjonen sin del, for når jeg til slutt googlet hvilken farge leder 4 og 5 skal ha var det motsatt av manualen. Når jeg byttet om fungerte det med en gang. Ellers er det jo store forskjeller i registeradresse innenfor samme modell. Har du funnet flere «modbus manualer» og testet forskjellige varianter? Hos meg endte jeg opp med å måtte trekke fra 1 fra registeradressen i den beste manualen jeg fant.

Høres ut som en fin løsning dette. Kunne du delt koden?

Hvordan har du løst styringen av viftehastighet basert på de to sensorene?

Hos meg er verdier for tilluft/avtrekk like for de forskjellige brukerhastighetene. Jeg har derimot et veldig godt dimmensjonert rørsystem (160mm hovednett og relativt korte 125mm avstikkere med maksimalt 3 ventiler per avstikker). Antar at pga. lite trykkfall i anlegget så er det lite behov for å korrigere balansen med viftehastighet for mitt anlegg. Romventilene er selvfølgelig justert spesifikt. Forskjeller i viftehastigheter mellom tilluft/avtrekk er for å ta høyde for forskjellig friksjon i de forskjellige kanalstrekkene. Dersom dette er justert av montør for brukerprofilene skal disse verdiene enkelt kunne tilpasses andre viftehastigheter. Friksjonen er styrt av kvadratet av lufthastigheten. En eksponensiell tilpasning av 2 eller flere verdier skal bli korrekt for andre hastigheter. Tanken var en tilnærming til behovsstyrt ventilasjon. Jeg har satt opp en modus for ventilasjonen ved matlaging (basert på strømtrekk fra platetopp). Jeg har ikke RH-sensor i mitt anlegg, men har kjøpt meg en RH-sensor som skal plasseres på badet slik at ved en rask endring av luftfuktighet så skal ventilasjonen settes til høy hastighet. Jeg har også kjøpt et par sensorer med CO2-måling som jeg tenkte å bruke til å bla. justere ventilasjonen. Viftenivået for normalmodusen er jo satt til en tabulert verdi, mener det er basert på en luftmengde per time som tilsvarer halve husets luftvolum (altså teoretisk bytte ut all luft hver 2. time). Dette tar høyde for en rekke scenarier som tilsvarer normal bruk, men er sannsynligvis på den konservative siden store deler av tiden. Av det jeg kan finne vil behovsstyrt ventilasjon kunne mer enn halvere energiforbruket til ventilasjon, sammenliknet med konstant hastighet, uten at det går utover inneklimaet. Nå kommer man jo et stykke på vei ved å ha hjemme/borte-modus men med mange sensorer i et smarthus har man jo straks mange flere muligheter enn det som er tatt høyde for når viftehastighetene for ventilasjonsanlegget er satt. Så tanken var å: - Justere hastighet for å holde anbefalte CO2-verdier basert på hvor mange som faktisk oppholder seg i mitt hus - Energimessig ikke bytte ut mer luft enn nødvendig. Dette vil også hjelpe på å ikke få så lav luftfuktighet på vinterstid Dersom en skal styre på slike parametre er det jo greit å slippe å hoppe mellom hastighetene lav/normal/høy som kan ha relativt store forskjeller i luftmengde. En ønsker jo i så fall å kunne ligge på en viftehastighet mest mulig konstant slik at en ikke får svingende verdier.

I servicemenyen for ventilasjonsanlegget kan man justere viftehastigheten for de forskjellige brukertrinnene (lav/normal/høy), altså justeringer i veldig mye finere trinn. Det ser ut som dette også er tilgjengelig via modbus. Er det noen som har lekt med tanken om å sette opp en PID-kontroll og justere viftebehov helt nøyaktig basert på f.eks. RH og CO2 sensorer?

Dette er opprinnelig innganger som kan styres via eksterne potensialfrie brytere/relèer, men la merke til at modbus for disse var R/W. Jeg testet write_coil tidligere, men da med register adresse og coil-verdi som state - det fungerte ikke. Når jeg tester slik du foreslår fungerer det State skal være 1/0 for å slå på/av. service: modbus.write_coil data: state: 1 address: 11201 slave: 1 hub: VTR300 Det eneste som er litt irriterende er at det blir krøll om man aktiverer en ny DI uten å slå av den forrige. Men det lar seg nok ordne med noen linjer ekstra med kode.

Fikler med modbus styring av Villavent VTR300 selv om dagene. Bruker en superbillig USB til RS485 adapter. Slenger inn et relatert spørsmål jeg ikke helt finner utav: Min VTR300 virker å være en litt eldre, enklere utgave hvor en bla. kun kan sette lav/normal/høy som viftemodus. For å f.eks. sette modus høy tilluft og lav avtrekk må dette defineres som "digital inngang" DI1, DI2 og DI3. Følgende informasjon finnes om styring av de digitale inngangene via modbus: Her er det plutselig inkludert "bit" og "coil" og ble da straks litt mer avansert enn å skrive en verdi slik jeg har gjort tidligere. En typisk skriving av ny verdi ser slik ut: service: modbus.write_register data: address: 100 slave: 1 value: 2 hub: VTR300 Hvordan vil dette bli om jeg jeg f.eks. ønsker å aktivere DI1 som i følge tabellen over har Bit 0?

Ser ut som det var en "gammel sensor" fra litt prøving og feiling som hang igjen. Tømming av cashe gjorde susen. Denne fungerer om det skulle være til hjelp for andre: template: - sensor: - name: "Lights consumption" unit_of_measurement: "kWh" device_class: energy state_class: total_increasing state: > {{ expand([ 'sensor.dimmer_gang_2etg_kwh', 'sensor.dimmer_bad_2etg_kwh', 'sensor.dimmer_gang_kwh', 'sensor.dimmer_gang_kjeller_kwh', 'sensor.dimmer_soverom_kwh', 'sensor.dimmer_vaskerom_kwh', 'sensor.gulvlampe_stue_kwh', 'sensor.lampe_hylle_kwh', 'sensor.lys_hs_peis_kwh', 'sensor.lys_kjokken_kwh', 'sensor.lys_spisestue_kwh', 'sensor.lys_vs_peis_kwh', 'sensor.spotter_kjellerstue_kwh', 'sensor.taklampe_stue_kwh', ]) | map(attribute='state') | map('float') | sum}} attributes: last_reset: '1970-01-01T00:00:00+00:00'

Jeg holder på å rydde litt i energidashboardet i Home Assistant. I den forbindelse ønsker jeg å gruppere en del enheter. F.eks. ønsker jeg å se på lys samlet, i stedet for en haug med små forbrukere. For å få til dette forsøker jeg å sette opp en template sensor: template: - sensor: - name: "all_lights_kwh" unit_of_measurement: kWh device_class: energy state_class: total_increasing state: > {{ expand([ 'sensor.dimmer_gang_2etg_kwh', 'sensor.dimmer_bad_2etg_kwh', 'sensor.dimmer_gang_kwh', 'sensor.dimmer_gang_kjeller_kwh', 'sensor.dimmer_soverom_kwh', 'sensor.dimmer_vaskerom_kwh', 'sensor.gulvlampe_stue_kwh', 'sensor.lampe_hylle_kwh', 'sensor.lys_hs_peis_kwh', 'sensor.lys_kjokken_kwh', 'sensor.lys_spisestue_kwh', 'sensor.lys_vs_peis_kwh', 'sensor.spotter_kjellerstue_kwh', 'sensor.taklampe_stue_kwh', ]) | map(attribute='state') | map('float') | sum}} Den nye sensoren fungerer som tiltenkt som sensor, men jeg får ikke lagt den til energidashboardet. Alle enhetene hver for seg kan legges til energidashboardet. Jeg ser at på tross av å ha lagt til state_class: total_increasing så kommer ikke dette med i sensorens attributter: Regner med at dette er problemet for energidashboardet, men hvordan får jeg fikset dette? Evt. andre måter å løse dette på?

Noen som kan hjelpe kode for en sensor som identifiserer billigste time fra nordpool mellom kl 00 og kl 06 og en sensor som finner billigste time mellom kl 09 og kl 17?

Jeg ønsker å kjøre en automatisering for når strømprisen er lavest. Tibber integrasjonen har attributt som gir laveste pris for døgnet: min_price. Hvordan får jeg satt en trigger som kjører når prisen for gjeldende time = min_price?

Etter å ha fungert fint en god stund har nordpool sensoren min plutselig sluttet å fungere. Jeg fjernet Nordpool integrasjonen fra HACS, fjernet alt i configuration.yaml, installerte på ny og la inn config på ny fra dokumentasjonen men ingen sensor dukker opp. Noen tips?

Takk for forklaringen. Tenkte i starten at * skulle erstattes med sensornavn i koden, men den er jo selvfølgelig der for å tillate alle varianter av sensornavn som slutter på _energy. Litt trøbbel med å implementere "customize_glob", den må stå direkte under "homeassistant:" for å fungere, ref denne om noen andre støter på samme problem: https://www.home-assistant.io/docs/configuration/customizing-devices/ Nå dukker den opp i energidashboardet 😀

Denne har jeg ikke brukt før, hvordan vil resten av sensoren se ut da om jeg skal skrive den om? På hvilken måte brukes dette inn mot det jeg har? Ser ike helt om "customice" er i forbindelse med oppretting av sensoren, eller om det kommer etterpå.

Termostat: Nye sensorer: Ut fra dokumentasjo i HA ser det ut som jeg må ha med device_class, ja: "Integrations need to configure their entities correctly so Home Assistant knows that we need to track statistics for it and how." Av dette ser det ut som wattmålingen skal ha device_class: power og state_class: measurement Strømforbruket bør ha device_class: energy og state_class: total Men jeg får ikke brukt state_class med sensor.template... Hvordan løser jeg det? sensor: - platform: template

Hadde energi også tiljengelig og la til dette for å hente begge: sensor: - platform: template sensors: bad_effekt_energy: friendly_name: "Effekt bad" device_class: energy unit_of_measurement: "W" value_template: "{{ state_attr('climate.gulvvarme_bad_2etg_393', 'current_power_w') }}" bad_energy: friendly_name: "Stromforbruk bad" device_class: energy unit_of_measurement: "kWh" value_template: "{{ state_attr('climate.gulvvarme_bad_2etg_393', 'current_energy_kwh') }}" Men får fortsatt ikke kWh sensoren opp i energidashboardet.

Takker så mye, hadde helt glemt ut oversikten i Developer Tools La til denne og det funker topp i forhold til å få opp en sensor med data: sensor: - platform: template sensors: bad_energy: friendly_name: "Energi bad" device_class: energy unit_of_measurement: "W" value_template: "{{ state_attr('climate.gulvvarme_bad_2etg_393', 'current_power_w') }}" Men, jeg får fortsatt ikke opp sensoren i energidashboardet. Regner med dette har noe med det kjetilsn nevner, men forstår ikke helt hvordan jeg skal implementere det med sensoren vist over. Om jeg bare legger til state_class: measurement i linjene overe får jeg feilmeldingen: Invalid config for [sensor.template]: [state_class] is an invalid option for [sensor.template]. Check: sensor.template->sensors->bad_energy->state_class.

Jeg har flere enheter som viser faktisk strømbruk for enheten (termostat, wall plug osv). Jeg bruker Vera Plus som kontroller, og har integrert denne mot HA. I Vera UI får jeg opp strømforbruket i watt på enhetene som støtter dette, men jeg finner ikke dette igjen i HA. Entitetene dukker heller ikke opp som valg i energidashboardet. Om jeg forstår det riktig må jeg opprette en sensor for dette i HA type: sensor: - platform: template sensors: watt_from_plug: friendly_name: "Watt from Plug" unit_of_measurement: "W" value_template: "{{ state_attr('switch.your_switch', 'energy') }}" Hvor switch.your_switch erstattes med entity_id - dette er OK og energy erstattes med navnet på attributten som inneholder wattmålingen - hvor finner jeg dette navnet i HA? Når dette er på plass og definert som en energiattributt i HA regner jeg med at den vil dukke opp i energidashboardet slik at man kan aggregere strømforbruker for en dag, uke, måned osv. og se hvor stor andel av forbruket forskjellige enheter utgjør?

Samme her ser jeg.

Det har du helt rett i. Var derfor logikkenmin i noen poster over her feilet. Bra spottet. Nå fungerer alt fint i forhold til å bruke tariffunksjonen til å legge til varierende netleie

Får inen feilmeldinger, men sensoren blir "Unavailable". Fungerer igjen med en gang jeg gjør om tariffleddet til #tekst. Har kopiert tariffleddet inn på ny fra github og funnet riktig innrykk som fungerer: additional_costs: '{% set s = { "hourly_fixed_cost": 0.2192, "winter_night": 0.2248, "winter_day": 0.3048, "summer_day": 0.3704, "summer_night": 0.2904, "cert": 0.01 } %} {% if now().month >= 4 and now().month <11 %} {% if now().hour >=6 and now().hour <22 %} {{s.summer_day+s.hourly_fixed_cost+s.cert|float}} {% else %} {{s.night+s.hourly_fixed_cost+s.cert|float}} {% endif %} {% else %} {% if now().hour >=6 and now().hour <22 %} {{s.winter_day+s.hourly_fixed_cost+s.cert|float}} {%else%} {{s.winter_night+s.hourly_fixed_cost+s.cert|float}} {% endif %} {% endif %}' Har gjort en og en endring, og den feiler når jeg endrer sommermåned til: #fra {% if now().month >= 4 and now().month <11 %} #til {% if now().month >= 4 %} Det er jo foreslått en annen, lavere, tariff fra jan-mars 2022 så tanken var å definere dette som winter_day og winter_night. I denne sammenheng vil jeg ikke at nov og des skal være vintermåneder. Noen som ser hvorfor endringen over feiler?

Noen innspill på hvorfor denne tariffunksjonen ikke fungerer? additional_costs: >- {% set s = { "hourly_fixed_cost": 0.2192, "winter_night": 0.2248, "winter_day": 0.3048, "summer_day": 0.3704, "summer_night": 0.2904, "cert": 0.01 } %} {% if now().month >= 4 %} {% if now().hour >=6 and now().hour <22 %} {{(s.summer_day+s.hourly_fixed_cost+s.cert)|float}} {% else %} {{(s.night+s.hourly_fixed_cost+s.cert)|float}} {% endif %} {% else %} {% if now().hour >=6 and now().hour <22 %} {{(s.winter_day+s.hourly_fixed_cost+s.cert)|float}} {%else%} {{(s.winter_night+s.hourly_fixed_cost+s.cert)|float}} {% endif %} {% endif %} Hvordan håndterer dere alternativt kommende varierende nettleie?