chrlod
-
Innlegg
50 -
Ble med
-
Besøkte siden sist
Innholdstype
Profiler
Forum
Blogger
Nedlastninger
Artikler
Regler
Hendelser
Galleri
Store
Innlegg skrevet av chrlod
-
-
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.
-
On 29/09/2022 at 22:47, Christoffer said:
Jeg har gjort det veldig simpelt ved at den med høyest nivå bestemmer.
Har ett settpunkt per rom og en hysterese på 100ppm slik at hvi ett av rommet er mer enn 100ppm over settpunktet så øker hastigheten med 10% per 10 minutt. Og så har jeg tilsvarende når alle verdiene er under grenseverdiene -100ppm. Ser i prinsippet at her i huset kunne jeg egentlig bare ha kjørt 50% og 100%, men det er for enkelt.
Har i tillegg fuktighetssensor på bad og vaskerom som overstyrer alt og setter 100%.Høres ut som en fin løsning dette.
Kunne du delt koden? -
On 28/09/2022 at 10:58, Christoffer said:
Jeg har gjort dette med et Flexit uni 3 anlegg jeg har. Måler Co2 vha Netatmo sensorer på soverom og i stue. Så kjapt at med mindre anlegget stod på maks så stiger nivået og stabiliserer seg på 1500ppm i stue og på soverom.
De originale verdiene var 50%, 75% og 100% så det jeg gjør er at anlegget alltid kjører i steg 2 og så justerer jeg innluft og utluft likt opp og ned ift Co2 målingene, i tillegg blir det automatisk 100% inn og ut basert ift fuktighet på bad og vaskerom. Laveste hastighet er 50% slik at det alltid er en viss utskiftning.
Sparer energi på det slik jeg kjører det, mest pga uten styring hadde jeg hatt det på 100% hele tiden da jeg aldri hadde giddet å justere og trykke på det lite repsonsive displayet som følger med.
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? -
1 hour ago, RVM said:
Så man kan altså skrive til en inngang som egentlig er dedikert til en fysisk digital input? Høres jo rart ut, så jeg måtte leite opp dokumentet du har et utklipp fra.
I kapittel 5 skriver de i alle fall at alle innganger og coils er tilgjengelige som registere med en formel for addressen: (Register Address * 16) – 15.
Jeg tipper at du kan lese register 701, og få en eller to bytes som du må dekode til bits iht. oversikten over. Og så kan du skrive til (701*16)-15 = 11201 for DI1 osv for å sette inngangene. Men det er nå bare et gjett, du får prøve deg fram.
Hvis du har satt opp modbus slik at du kan bruke modbus.write_register osv som postet over, kan du prøve:
service: modbus.write_coil data: address: 11201 slave: 1 state: True hub: VTR300
Forutsetter selvfølgelig at du har definert modbus i configuration.yaml med hub VTR300. Usikker på om state må være 1 eller True.
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: VTR300Det 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.
-
1
-
-
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: VTR300Hvordan 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?
-
47 minutes ago, kjetilsn said:
Det som skjer her er at alle entities som slutter på _energy vil få de tre attributtene vi snakker om.
Jeg har selv en del "gamle" heatit termostater som ikke gir med energimåling, der jeg regner dette for å få en kWh teller, som igjen trenger disse attributtene for å "virke" i energi dashboardet:
Det er mer ryddig å gjøre det i en template, men som stigvi er inne på så er det kanskje ikke rett frem.
customize er mer en "nødløsning" men det funker.
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 😀
-
32 minutes ago, kjetilsn said:
Jeg løste det med "customize" prøv å legg til dette i configuration.yaml
customize_glob: sensor.*_energy: last_reset: '1970-01-01T00:00:00+00:00' device_class: energy state_class: measurementDenne 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å.
-
2 minutes ago, kjetilsn said:
Hva ser du som "attributes" på entity?
Tror du må ha med:
'state_class'
'device_class'
'last_reset'
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: totalMen jeg får ikke brukt state_class med sensor.template... Hvordan løser jeg det?
sensor: - platform: template -
13 minutes ago, stigvi said:
Det er nok fordi du har lagd en sensor som viser effekt og det er ikke det samme som energi. Hvis du ikke har energi direkte som en attributt du kan hente ut så kan du se på Integration - Riemann sum integral - Home Assistant (home-assistant.io) for å regne ut energi når du har effekten.
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: measurementi 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?
-
2 hours ago, snorref said:
Derfor tror jeg ikke MVA(VAT) blir lagt til. Hva er deres erfaring?
Samme her ser jeg.
-
On 11/12/2021 at 00:00, snorref said:
Må det ikke være s.summer_night for at dette skal bli riktig?
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
-
4 hours ago, stigvi said:
Får du en feilmelding i loggen til HA?
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?
TIlpasse ladehastighet til effektledd
i Automasjoner
Skrevet · Endret av 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:
Øke:
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.