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?