Joffe

Whenever skrev (På 25.12.2021 den 21.29):

Hei

 

Tar sjansen på å spørre her. Jeg har omtrent Mill ovner i alle rom og i dag er jeg ganske avhengig av Mill-appen for å stille rom/program-temperaturen, slik jeg forstår det er det kun enkelt panelovn som er mulig å stille gjennom integrasjonen (ut av boksen). Er det noen som har fått til å knytte opp set_room_temperature-service opp mot f.eks entities? Gjerne tilsvarende som climate entities? Eventuelt forslag hvor man bør starte?

 

Er nybegynner på HA, så legger ved eksempel på service i fare for at jeg har bommet på forklaringen

 

service: mill.set_room_temperature
data:
  room_name: romnavn
  away_temp: 20

 

https://www.home-assistant.io/integrations/mill/

Heia.

Beklager sent svar. Har holdt på med mitt eget.

Tenker du å bruke "Kalenderen" som er i mill-appen?

Dersom du tenker å lage ditt eget i Home Assistant kan det kanskjegjøres på følgende måte.

1. Sett opp mill ovnene som brytere dersom de kommer opp som klima enhet i Home assistant.. (Switch)

2. Sett min og max grenseverdier (e.g. min 16 og max 23) (bryter av = 16 grader og bryter på = 23 grader) EDIT: Her blir det motsatt. 16 = PÅ og 23 = AV.

3. installert smart thermostat (PID) via HACS. (Er under utvikling, er en del bugs men hyppig oppdatert)

4. Sett opp smart thermostatene under climate.

5. Kjør autotuner på en termostat om gangen. Sparer litt tid og regning.

Med smart thermostat kan du sette eco, home, away, boost temperaturer basert på event_tilstander i home assistant. Med litt arbeid kan du få til mye morro.

La oss si at alle i huset er ute. Dersom du da har lagt til mobiltelefonene og tillatt sporing så vil Home assistant endre temperaturinstillingene til thermostatene.

Lykke til.

Moskus skrev (På 13.12.2021 den 10.13):

Jepp. Kort oppsummert: Den modellen er relativt lite gjennomtenkt og burde blitt navngitt "Fordi Vi Bare Vil Ha Mer Penger"-modellen.

Støtter tankegangen. Men det kan vel kanskje være greit å redusere effekten også i de timene strømmen er dyrest? 

@Join@Moskus

Moskus skrev (11 timer siden):

... "en bonus"? Hva er det som gir bonus?

Jeg tenker på at når ordningen/modellen er innført. Da vil det være enklere å justere opp summene i etterkant.

Erfaringsmessig gjør kraftlaget her endring i nettleie hvert andre år.

stigvi skrev (På 17.12.2021 den 19.34):

Uanz en smule tragisk å lese kommentarfeltet på noen avisartikler om dette. Folk er stort sett på feil jorde, men har likevel sterke meninger. Og folk som åpenbart ville tjent på ny modell, foretrekker å beholde den gamle. Hvorfor det er slik, kan sikker forskes på..........

Jeg hørte en si følgende: "Nei til Ja og Ja til Nei". Det kan vel kanskje ikke sies mye bedre en det.

Moskus skrev (5 timer siden):

I alle tilfeller er nettleien småpenger sammenlignet med de prisene vi har nå. Jeg tror jo ikke disse ekstreme variantene varer evig, men at prisnivået blir økt er jeg redd vi må ta høyde for også i fremtiden...

 

Å bare få innført modellen og tankegangen er en bonus.

Differensieringen vil komme, når sjokket etter hvert har lagt seg.

Kontroll spørsmål:

Kjører du script som oppdaterer alt for ofte?

Med alle de oppdateringene ser det jo ut som at det er noe som "flooder" z-wave nettverket ditt med meldinger.

Se litt på det.

Edit:

Jeg har har en temperatursensor som "fluktuerer" veldig.

Klarer du å øke "sampling perioden"? slik at du unngår at alle fluktueringene skaper chaos?

Hillmar skrev (7 timer siden):

Testet med sensor.accumulated_consumption__adresse nå. Denne treffer bedre, +/- 0,02 kWh.

Antar at det er verdien vi får inn som sensor.last_meter_consumption_adresse som benyttes av nettselskap og strømselskap for beregning ifm. fakturering, så HELT riktig blir det ikke. Men godt nok til å hjelpe til å få en oversikt.

 

Takk for tipset til både @Gjelsvik, og @Joffe som var inne på det samme.

Så flott.

Husk at accumulated_consumption_adresse resetter seg selv til 0 hvert døgn ved midnatt. Det må man ta høyde for.

Tar man det med i betraktning fungerer den ganske greit til å få relativt nøyaktige målinger og beregninger.

Tibber hadde en sensor tidligere med ferdig timesverdi. Denne forsvant ut av integrasjonen nå ved siste oppdatering.

Om den kommer tilbake vet jeg ikke. Vi ser.

Edit:

@stigvi, Når det gjelder saken om at verdier kommer på feil time. Det vil jeg tro er relatert til at de kommer inn under søylen for den timen vi lagrer/oppdaterer dem her i HA.

Det var en interessant problemstilling . Men løsningen er å lagre data i buffer i tidsrommet (xx:59:5x), avhengig av hvor lang tid det tar å lagre data.

Jeg ser at problemet er vanskelig å unngå dersom man man bruker data som dukker opp i feil time.

Man blir jo da veldig avhengig av at Tibber faktisk er oppe og kjører som normalt hele tiden.

Hillmar skrev (5 timer siden):

Dette fungerer ikke optimalt med Tibber Pulse som kilde. Målingene blir 1 time forskjøvet. Det ser ut som om @stigvi har tatt opp dette her, men virker som han taler for døve ører...

@stigvi, Hvilken sensor bruker du opp mot den innebygde energisiden?

Gjelsvik skrev (8 timer siden):

Energy delen løste egentlig problemet mitt ja. 

Men det alltids kjekt å vite hvor man faktisk koder ting. Automations har jeg sett på, men jeg finner ikke enkelt ut hvordan man gjør utregninger og tilegner nye verdier/states.

 

Koden du postet @Joffe, hvor legger du den? Jeg har ikke fått problemer med tibber etter oppdateringen som kom i helgen. Men ser at jeg mistet kontakt med Pulse i 4-5 timer i natt. Lurer litt på om jeg skal bytte ut pulse med en zigbee modul. Futurehome sin skal vist virke bra.

Hei igjen, @Gjelsvik

Dersom du installerer HACS integrasjonen.

Du installerer også studio code server integrasjonen.

gjennom "HACS" kan du igjen installere en custom integrasjon som heter pyscript.

Når du har kommet så langt at pyscript er installert. Da kan du åpne Studio Code Server og manøvrere deg inn i pyscript-mappen.

I pyscript-mappen må du ha en fil som heter config.yaml. Der legger du inn scriptene du ønsker skal kjøre.

En annen fil du trenger dersom du foreksempel skal kjøre PID løsningen til @stigvi er, requirements.txt. Her må  du legge inn eventuelle "pakker" du ønsker å kjøre.

Scriptene kan du sortere under en undermappe som kalles "scripts". (Altså feks, pyscript/scripts/PID_regulering/PID_regulering.py)

Du finner en del god informasjon rundt omkring på dette forumet. Du vil også finne god informasjon på pyscript integrasjonens informasjonssider(github).

NB: Jeg oppdaterer det endelige scriptet jeg enda med og som fungerer som tenkt.

stigvi skrev (4 timer siden):

Det gjelder egentlig alle dippedutter som videresender info fra HAN porten. Måleren rapporterer forbrukt energi etter at timen er ferdig og sånn som Home Assistant er lagd, så blir det feil. Jeg skal foreslå noe bedre, men venter til et mer gunstig tidspunkt enn rett etter en release av en ny versjon. 

For meg ser det ut som at den akkumulerte døgn verdien er live og akkumulerer fortløpende med oppdatering på rundt 2-3 sekunder.

Eller tar jeg feil der?

Hei.

Jeg fikk problem med tibber sin akkumulerte time verdi i dag.

"sensor.accumulated_consumption_current_hour_dinadresse"

Denne er utilgjengelig etter oppgradering til siste versjon av operativsystemet.

Det førte til at PID styringen brøt sammen på grunn av manglende data.

Det jeg gjorde var å bruke pyscript til å lage den nødvendige sensor verdien jeg trengte.

Hvorfor pyscript?

Fordi jeg får masse "float" feil og advarsler dersom jeg bruker template. Har forsøkt å få dette bort uten å lykkes 100%. Det ser ut til at  Home assistant holder på og ender opplegget, uten at jeg har fått med med detaljene rund det. Sånn at jeg regner med mer flere sensorer jeg har bryter sammen i januar oppgraderingen.

Det å bruke pyscript ser ut til å fingere veldig bra.

Du kan bruke tilsvarende metode som under til å oppnå det du ønsker.

@stigvi og/eller andre forum-entusiaster har noen fine eksempler i andre innlegg som gir deg litt informasjon om hvordan du setter opp input_number.

Det er helt sikkert rom for forbedringer i eksempelet under.(Ble gjort i bilen på vei til shopping senteret)

Eksempel på kode: (oppdatert)

Hei igjen.

Da ser det ut som at noe informasjon om ny nettleie har kommet for oss på vest/sør-vestlandet.

* Et månedlig beløp, avhengig av høyeste timeforbruk. (Kapasitetsledd)

* Et fastbeløp per kWh forbruk (Energiledd)

https://haugaland-nett.no/ny-nettleie-fra-arsskiftet/

SveinHa skrev (3 minutter siden):

Hvis en ikke har mulighet til gulvsensor så vil nok det være en grei tilnærming. I mine betonggulv med vannbåren varme tror jeg nok ikke en kommer unna uten gulvsensor (som jeg har) siden temperaturen på tilført vann vil variere en god del og flowen også ut fra hvilke og hvor mange gulvventiler som er åpne samtidig.

Ser den.

Jeg tenker at man kan kanskje allikvel dra nytte av å vite de termiske egenskapene i gulvene.

For meg handler dette også om forbruksplanlegging. Både sett iforhold til energipris og effekttopper, for å gi en best mulig fordelaktig strøm-/energiregning. Dersom man vet at man feks bruker 0,5 timer på å varme opp gulvet 1 grad. Og at det tar feks tar 7 timer for at temperaturen synker med 1 grad. Da kan man programmere opp automatiseringen til gjøre å gjøre vurderinger og ta å ta besluttninger. Alt for å gi deg best mulig kostnadsscenario uten å måtte tenke for mye i det daglige.

Jeg ønsker å bidra med et moment som kan være greit å ta med i betraktning for de med gulvvarme.

Å kartlegge og lage en formel som inkluderer de termiskeegenskapene i gulvene dine kan bidra til å optimalisere effektforbruket ytterligere. (Kartlegge hvor lang tid det tar for gulvet å endre seg 1 grad celcius/kelvin og hvor mye energi som går med.) Dette vil selvfølgelig påvirkes av grunntemperaturen/utetemperaturen også.

Jeg vet at denne metoden, gjerne sammen med maskinlæring er brukt enkelte steder. I praksis trenger man da ikke gulv sensor for å regulere nødvendig energitilførsel for å opprettholde nødvendig/ønsket temperatur i gulv.

Tygg litt på den.

Jeg er ikke komt så langt at jeg kan inkludere dette i mitt opplegg. Men jeg har noen tanker rundt det.

Hei.

Jeg er ny her på forumet.

Jeg har tenkt lenge på å starte automatisering av huset her hjemme.

Jeg begynte med X-comfort for noen år siden men drog i nødbremsen da det viste seg at Z-wave ville trolig bli en åpen standard som hadde fremtiden med seg. X-comfort er som kjent propriært, lukket og dyrt. Her taper Eaton/X-comfort terreng selv om X-comfort er en meget habilt produkt protefølje.

Jeg har nå endelig gått igang med Home Assistant. Det stod mellom Home assistant og HomeSeer. For meg ble det følelsen av at støtten for produkter var bredere og brukerbasen større for Home Assistant. Det var bakgrunnen for valget mitt.

Kjøpte min første "puck" for å styre varmekabler. Har i dag bare en puck fordi jeg var veldig usikker på produktet.

Foreløbig ser det ut til å fungere bra. Kan være fordi jeg omtrent ikke har enheter på Z-wave nettverket.

Jeg landet på en Qubino Flush On/Off Thermostat 2 og det ser ut til at jeg kommer til å kjøpe 5 stk av denne for å få alle varmekablene i 1egt med før jul.

Jeg går da fra gammel tradisjonell Hager varmestyring med termostat og relestyring montert i hovedtavle til en mer moderne løsning. Jeg har koblingsboks nede ved gulvet slik at en ordinær veggmontert termostat er en dårlig løsning for meg.

Det gledes at jeg har funnet noe som ser ut til å kunne fungere.

Videre vil jeg takke Stigvi og gjengen her for å tilført inspirasjon til å programmere opp PID-regulatoren samt sette hode i planleggings modus med tanke på automatiseringen jeg skal til med fremover.

Det jeg synes har vært vanskeligst med Home Assistant er å finne ut av hvordan man kombinerer de ulike språkene(syntax) og hvor koden skal plasseres. Dette er nå kartlagt og forstått godt nok at jeg kan komme meg videre. Da blir det en hel del enklere å lykkes i arbeidet fremover.

Ha en flott søndag, godt folk.