Gå til innhold
  • Bli medlem

stigvi

Medlemmer
  • Innlegg

    2 836
  • Ble med

  • Besøkte siden sist

  • Dager vunnet

    161

Alt skrevet av stigvi

  1. Det hjalp veldig å lavpassfiltrere regulatorutgangen: c = (0.9 * last_c) + (0.1 * pid(float(sensor.estimated_hourly_consumption))) Og så har jeg endret dette fra å konvertere til int til heller å bruke round for å få en bedre avrunding. if round(last_c, 0) != round(c, 0): sensor.regulator_energy_usage = round(c, 0)
  2. Ja, jeg vil svært gjerne ha en tabell som inneholder dette og neste døgns strømpriser sånn at jeg kan kutte ut å hente dette fra Nordpool. Men de to du nevner er et bra tiltak. Hva med klokkeslett og dato som en attributt på den siste av de to?
  3. Trådstarter kunne jo vært litt mer informativ og fortalt hva en ønsker å oppnå. I utgangspunktet klarer jo varmtvannstanken å styre seg selv.
  4. Jeg jobber litt mer med å få timeskifte til å fungere bedre. Problemet oppstår når en har hatt et lite forbruk helt til slutten av timen og ligger langt under grensen. Så settes på en stor forbruker. Fram mot timeslutt vil forbruket ikke passere grensen, men akkurat i det en kommer inn i ny time så vil estimert forbruk gjøre et hopp oppover. Og da gjelder det å begrense utgangen på pid-regulatoren så den ikke går rett ned på null. Jeg løser det med et lavpassfilter på estimert forbruk og pr i dag ser det slik ut. - platform: filter name: "estimated_hourly_consumption" entity_id: sensor.estimated_hourly_consumption_unfiltered filters: - filter: outlier window_size: 4 radius: 0.25 - filter: lowpass time_constant: 10 precision: 3 At det virker ser en på denne kurven der estimert forbruk øker sakte fra 0900 til 0901 Utgangen gikk ned til ca 40% for så å stige igjen Kanskje er det lurt med et filter på utgangen også? Det ser jeg på etterhvert, i så fall. Men jeg ser også at nå bruker pid-regulatoren omtrent 1-2 minutt på å redusere forbruket og det er helt ok. Dette var i starten på en time og da vil estimert forbruk fluktuere en del, men samtidig har en god tid på å regulere seg inn. I slutten av timen vil estimert forbruk være mer stabil og dermed blir utgangen på pid-regulatoren også mer stabil.
  5. Det blir jo en økt fare. Men dersom du en gang i uka sjekker stikkontakt, støpsel og fjernstyrt bryter for misfarging pga av varme så er du rimelig trygg. Det er ikke slik at dette plutselig en dag sier poff. Varmgang pga stor strøm til VVB er noe som vanligvis utvikler seg over lang tid og de aller fleste sjekker ikke tilstand på noe som gjerne står stuet vekk innerst under trappa eller noe annet ufremkommelig sted.
  6. Jeg har et veldig spesielt system for å styre ovner som er basert på Home Assistant sine bayesian sensor. En bayesian sensor styrer en varmekabel eller panelovn og hver av disse sensorene har en drøss innganger som er relatert varmestyring. En av inngangene er om pid regulatoren er under en grenseverdi. Nedenfor er en slik og den slår av ovn når pid regulator er under 32%. Du må se hva du gjør i ditt system. Det fikses jo lett med noen automasjoner eller i skriptet som jeg har gjort for bil. - platform: bayesian name: 'Panelovner stue' prior: 0.35 probability_threshold: 0.5 observations: - platform: 'numeric_state' entity_id: 'sensor.regulator_energy_usage' prob_given_true: 0.001 below: 32 - entity_id: input_boolean.travel_enabled prob_given_true: 0.001 platform: 'state' to_state: 'on' - entity_id: binary_sensor.vindu_2_etg_a prob_given_true: 0.001 platform: 'state' to_state: 'on' - entity_id: binary_sensor.vindu_2_etg_b prob_given_true: 0.001 platform: 'state' to_state: 'on' - entity_id: binary_sensor.noen_er_hjemme prob_given_true: 0.7 platform: 'state' to_state: 'on' - entity_id: input_boolean.sleeptime prob_given_true: 0.32 platform: 'state' to_state: 'on' - entity_id: binary_sensor.soonsleeptime prob_given_true: 0.32 platform: 'state' to_state: 'on' - entity_id: binary_sensor.preheat_day prob_given_true: 0.66 platform: 'state' to_state: 'on' - entity_id: binary_sensor.preheat_night_weekend prob_given_true: 0.64 platform: 'state' to_state: 'on' - entity_id: binary_sensor.heatlimit_morning prob_given_true: 0.4 platform: 'state' to_state: 'on' - entity_id: input_boolean.soonhome prob_given_true: 0.66 platform: 'state' to_state: 'on' - entity_id: input_boolean.visitors_comfort_temp prob_given_true: 0.64 platform: 'state' to_state: 'on' - entity_id: sensor.pricelevel prob_given_true: 0.48 platform: 'state' to_state: 'EXPENSIVE' - entity_id: sensor.pricelevel prob_given_true: 0.3 platform: 'state' to_state: 'VERY_EXPENSIVE' - entity_id: sensor.pricelevel prob_given_true: 0.3 platform: 'state' to_state: 'EXTREMELY_EXPENSIVE' - entity_id: binary_sensor.preheat_night_home_office prob_given_true: 0.64 platform: 'state' to_state: 'on' Skriptet mitt ang pid regulator er pr i dag som dette: from simple_pid import PID pid = PID(40.0, 1.0, 1600.0, setpoint=float(input_number.max_energy_usage)) pid.sample_time = 1.9 pid.output_limits = (0, 100) pid.proportional_on_measurement = False pid.auto_mode = True last_c = 0 turned_off_all = False turned_off_car = False @state_trigger("sensor.energy") def new_state(): global pid global last_c global turned_off_all global turned_off_car c = 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 last_c != c: sensor.regulator_energy_usage = int(c) #, attributes = {"unit_of_measurement": "%", "friendly_name": "Pådrag varme"}) last_c = c if c < 10 and turned_off_car == False: easee.set_charger_circuit_dynamic_limit(charger_id = "EH430587", currentP1 = "0") turned_off_car = True if c > 12 and turned_off_car == True: easee.set_charger_circuit_dynamic_limit(charger_id = "EH430587", currentP1 = "6") turned_off_car = False if c < 2 and turned_off_all == False: esphome.terrassevarmer_pause() esphome.varmtvannstank_pause() 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() esphome.varmtvannstank_resume() turned_off_all = False @state_trigger("input_number.max_energy_usage") def setpoint(value=None): pid.setpoint = float(value) @state_trigger("input_number.consumption_lasthour") def hourly_usage(value=None): if float(value) > float(input_number.max_energy_usage): script.turn_on(entity_id = "script.send_melding", variables = {'message': 'Strømforbruk var større enn grense', 'title': 'Strøm', 'channel': 'Info'})
  7. Her står det litt om legionella: Behandlingsmetoder - FHI Dusjhodet har stort sett optimal temperatur hele tiden. Men det er sjelden en hører om bekymringer ang. dette. På meg virker det som om massemedia har klart å skape et aldri så lite hysteri når det gjelder VVB 🙄
  8. Definitivt ingen fare for legionella. Temperaturen synker omtrent 0,4 grader i timen hvis du ikke tapper vann av den. Fra 70 til 45 grader kan den stå strømløs i ca 60 timer. 45 grader er fortsatt varmt nok til en dusj.
  9. Jeg løser det med at jeg sikter meg inn på 4,8kWh istedenfor 5. Da kan jeg bruke 2kW ekstra de siste 5 minutt uten å komme over grensen og systemet mitt bruker omtrent den tiden på å få slått av alt annet. Det er ikke så vanskelig og det blir også lettere og lettere etterhvert som timen nærmer seg slutten. Klokken 10:35 er estimatet 1,78kWh og timen som sluttet kl 10 var på 1,75kWh. Men en vet jo ikke hva som skjer. Plutselig settes bilen på lading og forstyrrer.
  10. Jeg var snar med å sette denne tilbake til 5 minutter. Når varmekablene slår seg av og på i 5 minutters intervaller så ender jeg opp med å ha et rolig og fint strømforbruk hvis jeg ser på snittet de siste 5 minutt. Men på kortere intervall går strømforbruket opp og ned som en jojo. Å prøve å estimere timesforbruket med et tidsvindu kortere enn 5 minutt ble håpløst for min del, men dere må jo se hva som passer best i deres hus. Jeg satte meg på en krakk ved siden av en termostat og tok tiden med stoppeklokke mellom klikkene i releet på termostaten. Total periodetid var på sekundet 5 minutt.
  11. Jeg har kuttet ut Tibber Pulse. Den hadde for mange utfall og da ble det umulig å holde seg under en kwh grense. Nå bruker jeg en enkel esp32 dings som kjører amstomqttbridge. Du finner tråder her på forumet om denne. Men så lenge du får ditt effektbruk inn i Home Assistant på faste 2,5s intervall så er det samme hva du bruker. Det eneste jeg har brukt som ikke er standard med i Home Assistant er pyscript. Denne er lastet inn ved hjelp av HACS. Appdaemon kan også brukes.
  12. - platform: derivative source: sensor.sensor_klepp_energi_effekt_integral name: real_time_consumption_gabriel_edlands_veg_16_integral_derivative round: 3 unit_time: h time_window: "00:02:30" Jeg har mange varmekabler som slår seg av og på innenfor 5 minutters intervaller og derfor hadde jeg tidsvindu på denne satt til 5 minutt. Men det gir en tregere respons når en større forbruker slås på så her må du se hva som passer for deg. Jeg tester litt med kortere intervall og ser om det gir bedre resultat hos meg.
  13. Her er bil på lading og VVB påslått og da har PID regulator etterhvert havnet på 68% og to varmekabler i gulv avslått for å holde det under 4,8kWh denne timen. Jeg fant ut jeg kunne liste opp hver av komponentene P, I og D og hvor mye de bidrar på utgangens 68%. Det gjør det mye lettere å "tune" den inn. c = 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))
  14. Jeg bruker enkelt og greit denne: Utility Meter - Home Assistant (home-assistant.io) utility_meter: energy: source: sensor.sensor_klepp_energi_effekt_integral cycle: hourly
  15. Jeg holder forresten på med å teste og justere på PID parametre og annen logikk. Kan poste dette også en eller annen gang i desember. Men parametrene jeg har i dag er pid = PID(40.0, 2.0, 800.0, setpoint=float(input_number.max_energy_usage)) .... som sikkert kommer til å endre seg mange ganger. Spesielt D=800 er jeg usikker på.
  16. Dette er i HomeSeer seksjonen av forumet og burde kanskje vært i en tråd under Home Assistant. Så du kan kanskje lage en tråd der hvis det er flere spørsmål? - unique_id: estimated_hourly_consumption_unfiltered name: "estimated_hourly_consumption_unfiltered" unit_of_measurement: 'kWh' device_class: power state: "{{ (states('sensor.energy')|float(15)+states('sensor.real_time_consumption_gabriel_edlands_veg_16_integral_derivative')|float(0) *(3600-now().minute*60-now().second)/3600) | round(3) }}"
  17. Du har kanskje ingen syntaks feil, men en logisk feil. Det som skal være under sensors: er en liste med sensorer. Men sånn du har formatert det så er ikke dette en liste. Et annet tips. Home Assistant har endret måten template sensorer skal skal oppføres og du kan like godt endre på det også når du først er igang. Det er ikke det som er problemet her, men det blir kanskje et problem i 2022 når Home Assistant ikke lenger støtter gammelt format.
  18. Du må sjekke opp innrykk. Ser ut som om filen din er feil formatert, rett og slett
  19. template: - sensor: - unique_id: billigste_time_tidspunkt name: billigste_time_tidspunkt state: >- {% set l=state_attr('sensor.nordpool', 'raw_today')|sort(attribute='value') %} {{ l[0].start.strftime('%H:%M') }}
  20. Jeg har brukt dette en stund, men i forrige uke ble min gateway tatt ned og jeg pillet ut batteriene på de sensorene jeg hadde på dette nettet. TTN har gått over til en ny arkitertur og heter nå TTS. De gamle serverene blir stengt ned i desember. Og jeg var rett og slett ikke i stand til å få min Mosquitto til å samarbeide med den nye MQTT tjenesten til TTS. Livet er for kort til å plages med data så etter noen dagers pest og plage så kastet jeg inn håndkleet og byttet ut sensorer med tilsvarende med zigbee. Opprinnelig var avstand en grunn til at jeg gikk for lorawan, men i ettertid har det vist seg at mitt zigbee nett har god nok rekkevidde til mitt bruk.
  21. Du kortslutter både når begge releer er på og begge er av Du er sikker på at du har tegnet riktig? Det er mer naturlig å lage dette med "motor" og "batteri" byttet om.
  22. Du er klar over at du kortslutter batteri?
  23. Når jeg tenker meg om så tror jeg faktisk Tibber gir deg akkumulert timesforbruk oftere enn hver time via sitt api. Tibber integrerer opp effekten for deg så du slipper å gjøre det selv.
  24. Slik gjør jeg det og hvis du søker litt så finner du andre sine løsninger. Problemet er at han-porten gir deg forbrukt energi bare hver time og på etterskudd. Hvis du vil være i forkant så må du selv lage noe for å integrere opp effekten som måleren rapporterer ca hvert 2. sekund for å få forbrukt energi hittil innenfor en time. Tipper du må over på noe annet enn Telldus Live også....... Home Assistant har mulighet for å integrere og å splitte opp i timesforbruk, men det må konfigureres. Det er bare byggeklosser i Home Assistant som du setter sammen ved hjelp av konfigurering og skripting.
  25. Det finnes mange tråder her om utstyr en kan koble til HAN porten. Noen kan du lage selv og noen kan du kjøpe fiks ferdig.
×
×
  • Opprett ny...

Viktig informasjon

Vi har plassert informasjonskapsler/cookies på din enhet for å gjøre denne siden bedre. Du kan justere dine innstillinger for informasjonskapsler, ellers vil vi anta at dette er ok for deg.