ChristerSG

2 timer siden, Moskus skrev:

Ja, jeg har lurt på det, men for å være helt ærlig er det lettere å bare hente alt ferdig tygget fra Tibber.  

Det er jo strengt tatt ingenting som er "fast", alt er jo avhengig av hvor mange kWh man bruker selv om nettleien ikke varierer over døgnet,  men det er jo bare å gange opp forbruket med prisen.

 

... tenker litt mer om det kan gjøres på en enkel måte.

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

5 minutter siden, clio75 skrev:

+1 på den.
Men hvordan fordele fastleddet ?
Hvet mann har antall kwt fra i fjor kan dette brukes eller kanskje bruke forrige måned antall kwt bare for å ha en pekepinn.

Sent from my SM-G930F using Tapatalk
 

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.

På 14.12.2018 den 20.47, Moskus skrev:

Rapporter hvis det fungerer også.  

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.

4 timer siden, Moskus skrev:

OK, @ChristerSG. Prøv 0.0.0.14 herfra:

 

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:

Dette ligger i TibberSeer log:

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? 

Akkurat nå, Moskus skrev:

Ja, sånn skal det jo ikke være... plugin'en gjør jo det samme uansett.

Fungerer det nå, eller er det like problematisk som før?

 

Jeg må melde dette som en bug.

Hvilken HS3-versjon? Windows eller Linux?

 

Den blir nok satt til standalone, for plugin'en vil ikke opprette devices for data som ikke finnes.

Den ser ut til å fungere nå ja.

Jeg er på .478 på Windows.

3 minutter siden, Moskus skrev:

Ja, her ser vi problemet: 

 

 

Denne skal være "Parent".'

 

Etter at du har kjørt en oppdatering, er den fremdeles merket "Standalone"?

Kjører du siste versjon av HomeSeer?

Windows eller Linux?

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? 

4 minutter siden, Moskus skrev:

Jeg ser at parent-device mangler, og DET er problemet.

Root device skal ikke opprettes automatisk av seg selv, men kun når du ber om det på Config-siden.

 

 

 

 

Jeg har enda en mistanke om at det er flere root'er...

 

Hvordan ser Advanced tab ut for Root device?

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.

11 minutter siden, Moskus skrev:

Har du prøvd å trykke "Show all"?

 

Jeg vet ikke hva som kan skje. Men det ser ikke ut som HS oppretter den paren-child forbindelsen den burde, og dermed blir det feil. De runde hjørnene i skjermbildene dine avslører det. Normalt skal det altså se slik ut:

 

 

Her er "Price Root" en parent device, og alle de andre er "child"-devicer. HomeSeer grupperer dem da slik.

 

Hvis du går inn på "Price Today TextSummary", skal du se følgende nederst i den øverste tabellen:

 

 

Hvordan ser det ut hos deg?

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.

13 minutter siden, Moskus skrev:

Slett ALLE TibberSeer devicer, restart HomeSeer, og opprett nye fra config-siden.

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.