stigvi

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?

Kan ikke svare på det du spør om, men er du fornøyd så er du jo det. Jeg er fornøyd med Home Assistant som den er uten node-red. For meg er det et poeng å ikke innføre ekstra tannhjul i maskineriet bare fordi en kan. Derfor tar jeg ikke i bruk node red når det allikevel løses lett på andre måter i Home Assistant. Men hvis du vil bruke node red til alt og droppe Home Assistant så er vel det ok. Har node red et greit system for å lage UI?

Ikeas gule batterier er borte – hvor gode er de nye? - Test - Tek.no

Da kan en jo ta prisen på IKEA Ladda og dele den på 2-3 hundre. De er jo ladbare

Rust er noe dritt. Jeg har en dobbelgarasje som er mest mulig tett og isolert. Null ventiler og null lufting annet enn når porten er åpen innimellom. Jeg har en ovn på veggen på 2kW som holder 12 grader om vinteren. Den er montert høyt oppe for ikke å være i veien for sykler og bildører. Jeg varmer sjelden opp mer enn 12 grader selv når jeg jobber. Skifte hjul i 18 grader blir drepende varmt innenfor kjeledressen. Jeg har satt inn en Woods luftavfukter som med en hygrostat kobler ut hvis fuktighet er mindre enn 50%. Vanligvis er fuktighet mellom 50 og 70%, avhengig av hvor mye regnvann det er på de to bilene som parkeres der. Der står også to motorsykler, et skap med klær og det er masse verktøy i garasjen. Ikke på noe som helst ser jeg antydning til rust. Selv ikke på ting som ruster lett som skivebremser eller enkelte verktøy som feks sagblad. Jeg tror ikke du skal bekymre deg for temperatur over 5 grader i garasjen, men du må få ut vann kjapt, tror jeg.

Single-precision floating-point format - Wikipedia "This gives from 6 to 9 significant decimal digits precision."

Det er sikkert mulig å gjøre som du har tenkt. Men hvorfor gjøre det lett når en kan gjøre det vanskelig, er det noe som heter. Det enkle er en billig panelovn i underetasjen.

I dette tilfellet blir en varmepumpe svært lite økonomisk. En slik pumpe har stor investeringskostnad og skal være i drift en god del timer før den lønner seg. I en garasje der en treng oppvarming en gang i blant, vil en panelovn være langt mer økonomisk.

Jeg har rapportert det som en bug i amstomqttbridge at den tar med 3 siffer etter desimalskilletegnet. Jeg ser i koden at målerstand lagres i en float og en float har bare 7 siffers nøyaktighet. Er målerstand større enn 100000 så vil amstomqttbridge ikke kunne rapportere 2 desimaler en gang.