stigvi

Disse sier hvor ofte det skal rapporteres. Den du har på batteri ser ikke bra ut og min og max interval kan godt endres fra 0 og 0 til 2700 og 3600

charger dynamic limit blir nullstilt hver gang du setter kontakten i bilen. Prøv heller circuit dynamic limit. Edit: Altså denne, service: easee.set_charger_circuit_dynamic_limit

Har du vifte så sjekk at den ikke er stoppet opp

Det er en Aqara sensor som dette: Aqara Vibration Sensor | NetOnNet Den er montert i lokket på en postkasse lagd av metall og den er montert på et felles stativ ca 30 meter fra huset. Har ingen problem med rekkevidde. Den sender data mer eller mindre kontinuerlig pga vind og små vibrasjoner. Sånn sett er det kanskje lettere å bruke en vindu- eller dørsensor med magnet. Blir det veldig mye vind så er det vanskelig å skille vind-vibrasjonene fra at lokket blir åpnet. Men noen ganger åpnes lokket av vinden så det blir vanskelig uansett......

Hvorfor styrer du med det når du kan få en billig zigbee enhet perfekt til formålet og som drives i minst et par år fra et lite CR2032 batteri. Lodder du på en batteripakke som tar 2 AA batterier så tipper jeg du ser 2 sifret levetid i antall år. Jeg har gjort det på en zigbee temperaturføler i fryser og det er ingenting som tyder på at den skal gå tom for strøm. Den bevegelse-sensoren i postkassen min har sunket fra 100 til 75% i løpet av et år. Men den drives av et cr2032 batteri og i kulde synker den litt på spenningen uansett.

Det aller beste er om du har et eget system for å slå av og på varme. Og så er status fra pid-regulatoren en inngang til dette systemet. Noen har anbefalt schedy, men jeg kjenner ikke til den. Jeg har lagd mitt eget system basert på bayesian sensor i HA, men den krever litt innsats i å sette opp. Ditt problem er at du nå får et skript som slår av og på varme. Hva om du reiser vekk og vil at varme skal være av.

Kikket litt på det og tror nok ikke dette vil virke. Når c<70 så slår du av VVB og varme i gang og du setter turned_of_all til true. Når c endrer seg til mindre enn 10 og mindre enn 2 så vil du aldri slå av varmekabel på bad og skrive til modbus register fordi turned_of_all er true. Istedenfor et flagg som turned_of_all så bør du heller legge inn en sjekk der du tester på tilstanden til hver enkelt climate. Et annet tips er å fordele alle varmekablene mellom 0 og 100% og ikke slå av så mange samtidig ved 10%. Årsaken til at jeg brukte et flagg som turned_of_all er at det jeg slo av (easee og ventilasjonsvarme) er trege med å oppdatere status tilbake igjen. Men dine climate er neppe det og det er mye lurere å teste på om en climate er av eller på.

Med den funksjonen setter jeg bare lading på pause når jeg er over forbruket som er tilgjengelig i et effekttrinn. Jeg styrer mot effekttrinnene og bryr meg ikke om hovedsikring. Den er 50A og spenningen er 400V 3-fase. Begge easee boksene står på en 16A 3-fase kurs og jeg har 11kW å bruke på bil. Den ene bilen lades stort sett med kun 1,3kW og den andre på 2,6kW så jeg prioriterer lav effekt. Bilene er satt opp til å lade til 30% som minimum og deretter videre til 90% om natt for å være ferdig ladet rett før avreise om morgenen. Jeg kunne kanskje spart en krone eller to med å lade kun når strømprisen er lavest, men det er vanskelig når en samtidig skal holde effekten lav. Så det som er der i mitt skript er der ene og alene for å holde meg under en gitt kWt/t grense.

Jeg vil si jeg har et stort system og det bruker bare en brøkdel av rpi4 sitt 4GB store minne. Jeg kjører 32 bits utgaven og den klarer bare å utnytte 2GB, men allikevel er minnebruk på 16% hvis jeg kikker på det HA core bruker og på 40% hvis jeg ser på HA OS. Altså, et stort system bruker 800MB

Jeg bruker state.persist selv i andre sammenhenger så det er også et godt alternativ. I praksis tror jeg ikke forskjellen er så veldig stor annet enn at du legger den under sensor domenet i ene tilfellet og pyscript i det andre. Edit: Grunnen til mitt valg om en malsensor er nok at jeg vil at denne skal ha verdi 100 når jeg starter opp HA istedenfor en annen verdi som sannsynligvis ikke er rett lenger. Utgangen på regulatoren endrer seg kontinuerlig og hva den hadde av verdi før en omstart er en smule uinteressant.

Nei, jeg har ikke dette problemet og jeg måtte kikke i koden min for å se hvorfor. Grunnen er at jeg har definert en malsensor som ser slik ut - unique_id: regulator_energy_usage name: "Regulator pådrag" unit_of_measurement: '%' state: 100 Så min HA starter alltid opp med denne satt til 100% og står til denne verdien fram til skriptet er kommet i gang. Alternativt kan du i skriptet sette denne øverst sammen med initialisering av pid ... turned_off_all = False sensor.regulator_energy_usage = 100.0 Det er bare å beklage at dette ikke er kommet med, men som du har nevnt, informasjonen ligger spredd utover og er en smule uoversiktelig.

Hvordan gjør du styringen av forbrukere, da? Klarer du å holde deg under en grense som du setter?

Jeg har lagt inn 5 og 10 som er de eneste aktuelle for meg. Min netteier har utsatt innføring til 1. juli så jeg ser det hele an litt. Den kan du slette. Det er noe jeg lagde for å vise forbruket i en time ut i fra det som måleren rapporterer hver time. Så har jeg lagd et varsel på mobil

Når denne endres (til 30, som du viste til) så må pid regulatoren få vite om det. Det gjør en med å lage en trigger på input_number.max_energy_usage og sette ny setpoint. Jeg har lagt med mitt skript så ser du hvordan jeg har gjort det. Der er det også tatt med andre endringer som at jeg setter utgangen til 100% ved oppstart av HA og jeg har også laget et filter på pid-utgangen for å dempe ned plutselige endringer. Men etter at jeg laget dette er det kommet en pid-regulator i HACS. Kanskje den er lettere for deg å bruke? Da slipper du å styre med et skript. soloam/ha-pid-controller: PID Controller to Home Assistant (github.com) Jeg vet ikke om parametrene for p, i og d kan brukes slik som de er i skriptet, men sannsynligvis kan de det. from simple_pid import PID pid = PID(40.0, 0.4, 2500.0, setpoint=float(input_select.nettleie_pristrinn) - 0.2) pid.set_auto_mode(False) pid.sample_time = 1.9 pid.output_limits = (0, 100) pid.proportional_on_measurement = False pid.set_auto_mode(True, last_output=100.0) last_c = 100.0 turned_off_all = False turned_off_car_red = False turned_off_car_blue = False @state_trigger("sensor.energy") def new_state(): global pid global last_c global turned_off_all global turned_off_car_red global turned_off_car_blue c = (0.9 * last_c) + (0.1 * pid(float(sensor.estimated_hourly_consumption))) #p, i, d = pid.components #state.set("sensor.regulator_p", round(p,1)) #state.set("sensor.regulator_i", round(i,1)) #state.set("sensor.regulator_d", round(d,1)) if round(last_c, 0) != round(c, 0): sensor.regulator_energy_usage = round(c, 0) v = max(5 * round(c, 0) - 400, 0.0) number.effekt_varmtvannsbereder.set_value(round(v,1)) last_c = c if c < 10 and turned_off_car_red == False: easee.set_charger_dynamic_limit(charger_id = "EH430587", current = "0") turned_off_car_red = True if c > 12 and turned_off_car_red == True: easee.set_charger_dynamic_limit(charger_id = "EH430587", current = "16") turned_off_car_red = False if c < 70 and turned_off_car_blue == False: easee.set_charger_dynamic_limit(charger_id = "EH3JE5CS", current = "0") turned_off_car_blue = True if c > 72 and turned_off_car_blue == True: easee.set_charger_dynamic_limit(charger_id = "EH3JE5CS", current = "16") turned_off_car_blue = False if c < 2 and turned_off_all == False: esphome.terrassevarmer_pause() switch.heru_electric_heater_connected.turn_off() persistent_notification.create(title = "Strøm", message = "Effektbegrensing slo av alt.") turned_off_all = True if c > 5 and turned_off_all == True: esphome.terrassevarmer_resume() switch.heru_electric_heater_connected.turn_on() turned_off_all = False @state_trigger("input_select.nettleie_pristrinn") def setpoint(value=None): pid.setpoint = float(value) - 0.2 @state_trigger("input_number.consumption_lasthour") def hourly_usage(value=None): if float(value) >= float(input_select.nettleie_pristrinn): script.turn_on(entity_id = "script.send_melding", variables = {'message': 'Strømforbruk var større enn grense', 'title': 'Strøm', 'channel': 'Info'})

Har du lagt inn kode for å sette nytt settpunkt når du endrer det? Jeg har dette: @state_trigger("input_select.nettleie_pristrinn") def setpoint(value=None): pid.setpoint = float(value) - 0.2 Du må bruke input_number.max_energy_usage istedenfor input_select.nettleie_pristrinn Jeg ville laget en state_trigger på accumulated consumption current .... Kanskje det er det du har?

Jeg har de siste to ukene målt varmetapet i min OSO 200l tank ved forskjellige vanntemperaturer. Temperatur er på X-aksen og varmetap på Y-aksen. Ved 50 grader er tapet 58W, ved 65 grader er tapet 99W og ved 75 grader er tapet 125W. Hvis en skrur ned temperaturen på tanken fra 75 til 65 grader så vil en i løpet av et år spare 228kWh. Reduserer en temperaturen mer, f.eks til 50 grader så kan en potensielt spare 590kWh. Men da tror jeg det er lurt å øke temperaturen til 75 grader en gang pr uke for å ta knekken på bakterier. 50 grader er allikevel høy nok temperatur til at en ikke får noen oppblomstring av legionella. Men så er det da et spørsmål om hvor mye en sparer på å ha en konstant lav temperatur kontra det å varme opp til maks temperatur når det er billig strøm på nattetid. Kanskje kombinere det med å varme opp til 60 grader på natt og la det synke til 50 grader i løpet av dagen. Og hver natt til søndag varme opp til 75 grader.

Nei, har ikke det. Jeg har ikke noe zwave utstyr.

Selv om en kan gjøre det slik du beskriver, å la Homey være mellom zigbee og zwave utstyr, så anbefaler jeg at lys og lysutstyr konsekvent er enten bare zigbee eller zwave. Da har en mulighet for å sette opp direkte koblinger, noe både zigbee og zwave støtter. Med direkte koblinger kan en styre lys fra fjernkontroller eller brytere selv om sentral styreenhet er ute av drift. For lys synes jeg dette er vesentlig å få på plass.

Nei, Philips Hue er standard zigbee og virker sammen med annet zigbee utstyr

Philips Hue wall switch module | Elektroimportøren AS (elektroimportoren.no) Det finnes størst utvalg av lysutstyr som støtter zigbee

En kontaktor sin spole er en ren induktiv last så denne vil lage litt gnister på et rele i en rimelig smartbryter. Jeg har brukt en slik løsning, men jeg koblet til en varistor i parallell med kontaktor for å unngå gnistring.

Jeg tviler ikke på at det er lett å lage automasjoner. Det er det som skjer etter at automasjonen er laget, jeg er skeptisk til. Men det gjelder hvis en kjører node-red som en tilleggsdel til Home Assistant (eller HomeSeer). Alle endringer i tilstand skal overføres via et eller annet api (antar det er et rest-api) mellom node-red og HA (eller HS), node-red skal prosessere i sin automasjon og sette sin egen tilstandsmaskin før tilstander igjen skal overføres til HA. Alternativet er altså HA (eller HS) sine automasjoner som jobber med sin egen tilstandsmaskin. Kjører en kun node-red så er det noe annet. Da forsvinner min skepsis til det. Bare for å pirke: Home Assistant krever ikke dette. Det er et valg du gjorde med å kjøre HA på denne måten på en Ubuntu server 🙂 Bare nevner dette i tilfelle andre leser her og får et inntrykk av at HA er tung å sette opp.

Lys og varme er enkelt og går stort sett på automatikk hos meg også. Men når kona skal endre lading av bil fordi hun en dag har en litt annen rutine, da bør det helst ikke være for nerdete. Ikke noe galt om min kone. Hun er den største pådriveren til at vi har et fungerende smarthus. Men når en er innom appen ikke så alt for ofte så synes verken hun eller jeg at det er greit å bla seg forbi masse nerdeting for å komme fram til det en skal gjøre. Bare for å spore det tilbake igjen. Er node red nerdenes ultimate nerdeting? Noe vi vil ha fordi det tilfredstiller noe i oss? Kanskje ufint av meg å spørre slikt her? Jeg liker sånn sett node-red selv. Men jeg vet hvor galt det bærer avsted hvis jeg tar den i bruk. Dessuten bor jeg ikke i en fabrikk. Det er begrenset hvor mye en trenger å automatisere et bolighus. Node red blir kun "kjekt å ha" sånn sett.

Sånt er i allefall viktig for meg. UI bare må på plass for at de andre i heimen skal være fornøyde med å bo i et smarthus. Dessuten bidrar HA appen med data inn til systemet i form av sensorer som er nyttige. Men som nevnt. Gjør det du liker best uten å tenke så mye på hva andre gjør. Uansett ikke hør på meg for jeg er for sær med spesielle meninger. Jeg innser at jeg er ekstremt opptatt av å holde systemet mest mulig enkelt og uten noe ekstra uten at det er en veldig god grunn for det. Jeg er rimelig sikker på at jeg kommer til å droppe pyscript. Må bare vente på at HA sin automasjon er blitt litt bedre på å organisere koden i mapper eller grupper. Det blir for uoversiktelig med en drøss automasjoner i en flat liste. Jeg er også interessert i å kutte vekk mqtt broker som jeg ser på som en "unødvendig" byggekloss. Foreløpig er den mer nødvendig enn unødvendig........

Det finnes alternativer også som pyscript og appdaemon. Begge er nye tannhjul, men kanskje mindre enn node-red. Hvis det har noe å si, da. Begge disse to er uansett helt avhengig av home assistant. De kan ikke erstatte HA helt og holdent. Jeg er programmerer av yrke og liker helst å skrive kode i tekstfiler istedenfor å bruke node-red sin tilnærming til det å lage kode. Men det er smak og behag. PS. Du svarte ikke på det jeg lurte på. Hvordan er node-red på UI? Har de en bra app til telefon?