ChristerSG

Mulig dette med faste komponenter varierer, men hos Eidsiva betaler man ett fastledd for å være tilkoblet som er uavhengig av forbruk og baserer seg på størrelse på hovedsikring. I tillegg har man jo dette energileddet som legges på løpende forbruk. https://www.eidsivanett.no/globalassets/dokumenter/priser/tariffer-2019/tariffblad-1.0.-e-tariff.pdf

Fastdelen er vel stort sett en fast sum ut fra hvilken tariff man ligger på? Altså størrelse på hovedsikring osv. Så uavhengig av forbruk. Iallfall mener jeg det er slik hos Eidsiva. Edit: Mulig jeg misforstod litt, men jeg tenkte i utgangspunktet at løpende summeres spot + forbruks-leie, samt en annen device som tar for seg faste komponentene + faktisk forbruk så langt denne måneden f.eks.

Hva med å legge inn valg for å inkludere nettleie, både forbruk og faste avgifter i kwh-pris? (Disse må jo selvfølgelig fylles inn manuelt i oppsettet.) Kunne da fått et veldig nøyaktig anslag realtime? Eget device som summerer både løpende og fast, samt at man gir valget om pris som vises pr i dag også skal inkludere forbruks-komponenten eller ikke. Dette kan jo da brukes på Pulse også vil jeg tro.

Jeg er veldig usikker på hvordan dette kan løses i praksis da det er veldig mange variabler, men det hadde vært litt fancy med en oversikt over hvor mye effekt man faktisk flytter bort fra pristoppene. Men den må jo da ha oversikt over normalt forbruk til enhetene, om enheten faktisk ville vært aktiv hvis den ikke hadde blitt tvunget av (sjekke mot termostat om grader er lavere en setpoint?). Ser samtidig at vvb vil kreve at man også overvåker temperatur for å få noe fornuftig ut av den. Har man først antall kwh som er flyttet, så er det sikkert en smal sak for de som kan det å dra med faktisk besparelse i kroner og øre ut fra differansene i pris man flyttet fra og til.

Ser ut til at det fungerer bedre nå ja. Har ikke sjekket hvordan en oppfører seg hvis den møter like priser osv i de dyreste timene, men dette skulle kanskje ikke ha noe å si? Neste skritt blir da å få til noe logikk som faktisk sjekker nødvendigheten av senking, ikke det store poenget når alt beveger seg helt flatt.

Lagt den inn nå, så da lar jeg den bare gå sin gang. Rapporterer tilbake om den ikke fungerer. Krysser fingrene.

Her er logg for klokken 13: juov-14 13:00:30 Device Control Device: Underetasje Gang Mode 1 to Energy Save Heat (11) juov-14 13:00:30 Device Control Device: Underetasje Bad Mode 1 to Energy Save Heat (11) juov-14 13:00:30 Device Control Device: Overetasje Masterbad Mode 1 to Energy Save Heat (11) juov-14 13:00:30 Event Event Trigger "Varmestyring Eco" juov-14 13:00:30 Event Event Trigger "Varmestyring Automatisk eco ved pris" juov-14 13:00:30 TibberSeer GetNthHighestPrice for n = '4': 0,9146 juov-14 13:00:29 TibberSeer Debug UpdateTibberData done! juov-14 13:00:12 TibberSeer Debug UpdateTibberData done! juov-14 13:00:12 TibberSeer Debug TibberPrice, UpdateData done!(root: 1080) juov-14 13:00:12 TibberSeer Debug GetSavePath(), savePath: C:\Program Files (x86)\HomeSeer HS3/html/images/TibberSeer/ juov-14 13:00:12 TibberSeer Debug GetSavePath(), savePath: C:\Program Files (x86)\HomeSeer HS3/html/images/TibberSeer/ juov-14 13:00:12 TibberSeer Debug UpdateData, updateTomorrowChart = True juov-14 13:00:12 TibberSeer Debug UpdateData, updateTodayChart = True juov-14 13:00:12 TibberSeer Debug PriceHigherThanNthHour, true/false: 0 juov-14 13:00:12 TibberSeer Debug PriceHigherThanNthHour, nth: 4 juov-14 13:00:12 TibberSeer GetNthHighestPrice for n = '4': 0,9146 juov-14 13:00:12 TibberSeer Debug CurrentPrice.Total: 0,7752 juov-14 13:00:12 TibberSeer Debug Checking trigger in event with ref: 4 juov-14 13:00:00 TibberSeer Debug TibberPrice, UpdateData starting... (root: 1080) juov-14 13:00:00 TibberSeer Debug UpdateTibberData starting... juov-14 13:00:00 TibberSeer Debug UpdateTibberData starting... Dette ligger i TibberSeer log: juov-14 12:00:12 TibberSeer GetNthHighestPrice for n = '4': 0,9146 juov-14 11:00:30 TibberSeer GetNthHighestPrice for n = '4': 0,9146 juov-14 11:00:12 TibberSeer GetNthHighestPrice for n = '4': 0,9146 juov-14 10:00:30 TibberSeer GetNthHighestPrice for n = '4': 0,9146 juov-14 10:00:10 TibberSeer GetNthHighestPrice for n = '4': 0,9146 juov-14 09:00:10 TibberSeer GetNthHighestPrice for n = '4': 0,9146 juov-14 07:00:09 TibberSeer GetNthHighestPrice for n = '4': 0,9146 juov-14 06:00:09 TibberSeer GetNthHighestPrice for n = '4': 0,9146 juov-14 05:00:10 TibberSeer GetNthHighestPrice for n = '4': 0,9146 juov-14 04:00:10 TibberSeer GetNthHighestPrice for n = '4': 0,9146 juov-14 03:00:09 TibberSeer GetNthHighestPrice for n = '4': 0,9146 juov-14 02:00:08 TibberSeer GetNthHighestPrice for n = '4': 0,9146 juov-14 01:00:08 TibberSeer GetNthHighestPrice for n = '4': 0,9146 juov-13 23:00:07 TibberSeer GetNthHighestPrice for n = '4': 0,8916 juov-13 22:00:08 TibberSeer GetNthHighestPrice for n = '4': 0,8916 juov-13 21:00:41 TibberSeer GetNthHighestPrice for n = '4': 0,8916

Det var noe rart med denne også. Endret eventet nå, men den trigget igjen klokka 10. Kan det være fordi den leser klokken 7 og 8 samt 16 og 17 som samme verdi? Eller den skulle jo forsåvidt ikke trigget uansett da det er flere timer som er høyere. Current price er oppdatert 20 sekunder før event er kjørt.

Da prøver jeg den varianten.

Det var noe slikt jeg konkluderte med etter jeg fikk tenkt litt på det. Men ett nytt "problem". Mulig dette kan løses på en helt annen måte. Jeg kjører en event som sjekker om prisen er av de 4 høyeste gjennom døgnet og setter termostater i eco og tilbake i heat etter etter en time. Problemet er hvis det er samme pris 2 timer på rad, noe som skjer 2 ganger i dag, så vil den jo ikke oppdatere prisen og eventet blir ikke trigget på nytt.

Det er avvik mellom Price Statistics Tomorrow Low og High, i forhold til hva som presenteres i Price Tomorrow TextSummary. Samme gjelder forsåvidt for Today også. Er det noen grunn til dette? Og hvilke konsekvenser vil det ha for events som benytter disse feltene? Edit: Det er vel kanskje intensjonen at den ikke skal vise den ene høyeste timen, men et snitt av de høyeste? Hvordan ser formelen ut?

Den ser ut til å fungere nå ja. Jeg er på .478 på Windows.

Etter jeg opprettet den på nytt nå, med samme fremgangsmåte som tidligere så har den blitt Parent 10th times a charm tydeligvis. Prøvde samtidig å opprette ny for Consumption, men den kom som Standalone. Vet ikke om det kan være påvirket av at de ikke har noe historiske data på meg?

Jeg finner ikke flere root devices. Den opprettes kun igjen når jeg går via plugin, haker av på info jeg vil ha og trykker done.

Ja, show all er trykket inn mange ganger, så jeg har slettet også root-devicen, men den oppretter seg igjen for seg selv. :

Jeg har ikke igjen noen devices som er relatert til TibberSeer med mindre det er godt gjemt et annet sted. Jeg får opp igjen price-root etter jeg setter opp pricegrabbing på nytt, så det kun er denne (pluss consumption) så har jeg slettet de. Consumption har jeg behov for helt enda.

Forsøkte det i går og igjen nå, men samme problemet. Prøvde nå 2 manuelle refresh for å få fortgang og da ser der slik ut:

Jeg sliter nå med samme problemene med at den lager nye devices ved hver kjøring. Forsøkte å slette alle devices som foreslått over og restartet pluginen, men det hjalp ikke. Andre forslag til løsning?

Mye bra her! Ser Pulse er nevnt, så slenger meg på den. Er ikke så dreven i Homeseer enda, men ser jo fordeler med at man kan få inn totalforbruk og eventuelle sammenstillinger med forbruk fra alle enheter i en graf. Jeg ser også at Tibber lister opp Heatit sine termostater direkte i appen sin hvis man bruker Futurehome. Hvordan er muligheten for at denne pluginen også kan sende slik type data tilbake? Kan man potensielt gi Tibber direkte tilgang til hver enkelt termostat og la disse AI'ene dems gjøre jobben for seg? Jo mer samspill i begge retninger jo bedre tenker jeg. F.eks lese av om Tibber er satt i Ferie-modus oss og oppdatere Homeseer til samme status og motsatt. EDIT: Hadde jeg lest roadmapen til Tibber så hadde jeg sett at disse punktene allerede lå der, så er vel ikke så mye man får gjort før de får det på plass, men veldig lovende at de også gir tilgang til disse funksjonene. Access to our AI for heat control: self learning schedules and adaptive heating plans Virtual devices: create your own “bubbles” in the Tibber app

Jeg satte opp akkurat dette i forrige uke, og hadde i starten problemer med Switch Multilevel 2 levde sitt eget liv. Det kan virke som om at den fortsatt tidvis gjør det, men problemene er i all hovedsak borte. Jeg tror mye av det ble borte når jeg fikk satt opp riktige assosiasjoner på dimmerne. (Noe som for øvrig ikke gikk like enkelt som det burde ha gjort) Oppsettet her er nok ikke optimalt, så kom gjerne med feedback ved opplagte flaws. Jeg har 2 "triggere" / impulsbrytere koblet til S2, da ved utgangsdør og på soverommet som sjekker status på en virtuell device som forteller om jeg er hjemme eller borte/sover. Siden S2 fortsatt oppfører seg rart og plutselig satte seg selv til "on" 2-3 ganger pr ett trykk på bryteren så la jeg inn en wait for å forhindre at sekvensene loopet, noe de gjorde et par ganger før jeg la det inn. Jeg har da også tilsvarende events hvis "Hjem/Våken" er "Off", disse sjekker også på klokkeslett for hvor mye lys den faktisk skal skru på, da jeg helst ville unngå flombelysning midt på natta. Ikke at det er relatert til spørsmålet, men det gir jo enkelt muligheten til å utvide med flere triggere, som f.eks proximity sensor eller geofencing for å gjøre dette automatisk når man kommer hjem eller reiser ut.