^ Näin etukäteen kyselen jo, elikkäs miten tuossa tapahtuu jos haluan MLPtä ohjata siten, että esimerkiksi 0C ulkolämmössä olisi 6 halvinta tuntia sallittu, -10C ulkolämmössä 12 halvinta ja lämmitystarve alkaisi +10C ulkolämpötilasta? Aktivoin silloin siis vain tuon "mukavuuslämmityksen" ja laitan siihen halutut asetukset? Muilla asetuksilla voi sitten vielä määrätä maksimitunnit ja hintarajan jonka alla lämmitys aina sallittu?
Pörssäri - Useiden ohjauslaitteiden ja helpon web-asetusliittymän yhdistelmä pörssisähköohjaukseen
- Viestiketjun aloittaja tk-
- Aloituspäivämäärä
Heti alkuun hatunnosto ja iso kiitos @tk- kun kehität tällaista palvelua muidenkin iloksi! Minulla on HA:ssa Pörssärin sensorit kokeilumielessä käytössä. Joku ongelma näihin kuitenkin liittyy, jonka haluaisin raportoida, jos vaikka korjauskin joskus löytyisi. Nimittäin jokaisen vuorokauden alussa klo 00-01 välillä (vaihtelee hieman) nuo sensorit kadottavat arvonsa, eli eivät näytä 0 eikä 1:
Minä en ohjaa sensoreilla vielä mitään automaatiota, joten en tiedä mitä tuo "katkos" automaatioille aiheuttaa. Oletan, että ne eivät siitä tykkäisi kovin hyvää.
Logiin tulee myös iso määrä (tuhansia rivejä joka yö) herjoja säännöllisesti. Niiden sisältö on tämän kaltainen:
Tuo ajanhetki 00:39:22 on juurikin se, jolloin yllä olevassa kuvassa ympyröity katkos alkaa. Jos tähän löytyisi korjaus, niin olisi todella hienoa. Odotan nimittäin suurella mielenkiinnolla tuota älykästä lämmityksen ohjausta ja haluaisin päästä sitäkin kokeilemaan.
Minä en ohjaa sensoreilla vielä mitään automaatiota, joten en tiedä mitä tuo "katkos" automaatioille aiheuttaa. Oletan, että ne eivät siitä tykkäisi kovin hyvää.
Logiin tulee myös iso määrä (tuhansia rivejä joka yö) herjoja säännöllisesti. Niiden sisältö on tämän kaltainen:
Koodi:
2023-11-23 00:39:22.738 WARNING (MainThread) [homeassistant.helpers.template] Template variable warning: 'homeassistant.helpers.template.Wrapper object' has no attribute '0' when rendering '{% if is_state('binary_sensor.porssari_json_controls', 'on') %}
{% set curHour = now().hour | string %}
{{ state_attr("sensor.porssari_json_data", "Channel1")[curHour] }}
{% else %}
{{ -1 }}
{% endif %}'
2023-11-23 00:39:22.739 WARNING (MainThread) [homeassistant.helpers.template] Template variable warning: 'homeassistant.helpers.template.Wrapper object' has no attribute '0' when rendering '{% if is_state('binary_sensor.porssari_json_controls', 'on') %}
{% set curHour = now().hour | string %}
{{ state_attr("sensor.porssari_json_data", "Channel2")[curHour] }}
{% else %}
{{ -1 }}
{% endif %}'
2023-11-23 00:39:22.740 WARNING (MainThread) [homeassistant.helpers.template] Template variable warning: 'homeassistant.helpers.template.Wrapper object' has no attribute '0' when rendering '{% if is_state('binary_sensor.porssari_json_controls', 'on') %}
{% set curHour = now().hour | string %}
{{ state_attr("sensor.porssari_json_data", "Channel3")[curHour] }}
{% else %}
{{ -1 }}
{% endif %}'
2023-11-23 00:39:22.741 WARNING (MainThread) [homeassistant.helpers.template] Template variable warning: 'homeassistant.helpers.template.Wrapper object' has no attribute '0' when rendering '{% if is_state('binary_sensor.porssari_json_controls', 'on') %}
{% set curHour = now().hour | string %}
{{ state_attr("sensor.porssari_json_data", "Channel4")[curHour] }}
{% else %}
{{ -1 }}
{% endif %}'
2023-11-23 00:39:22.741 WARNING (MainThread) [homeassistant.helpers.template] Template variable warning: 'homeassistant.helpers.template.Wrapper object' has no attribute '0' when rendering '{% if is_state('binary_sensor.porssari_json_controls', 'on') %}
{% set curHour = now().hour | string %}
{{ state_attr("sensor.porssari_json_data", "Channel5")[curHour] }}
{% else %}
{{ -1 }}
{% endif %}'
2023-11-23 00:39:22.744 WARNING (MainThread) [homeassistant.helpers.template] Template variable warning: 'homeassistant.helpers.template.Wrapper object' has no attribute '0' when rendering '{% if is_state('binary_sensor.porssari_json_controls', 'on') %}
{% set curHour = now().hour | string %}
{{ state_attr("sensor.porssari_json_data", "Channel6")[curHour] }}
{% else %}
{{ -1 }}
{% endif %}'
2023-11-23 00:39:22.745 WARNING (MainThread) [homeassistant.helpers.template] Template variable warning: 'homeassistant.helpers.template.Wrapper object' has no attribute '0' when rendering '{% if is_state('binary_sensor.porssari_json_controls', 'on') %}
{% set curHour = now().hour | string %}
{{ state_attr("sensor.porssari_json_data", "Channel7")[curHour] }}
{% else %}
{{ -1 }}
{% endif %}'
2023-11-23 00:39:22.746 WARNING (MainThread) [homeassistant.helpers.template] Template variable warning: 'homeassistant.helpers.template.Wrapper object' has no attribute '0' when rendering '{% if is_state('binary_sensor.porssari_json_controls', 'on') %}
{% set curHour = now().hour | string %}
{{ state_attr("sensor.porssari_json_data", "Channel8")[curHour] }}
{% else %}
{{ -1 }}
{% endif %}'
2023-11-23 00:39:22.751 WARNING (MainThread) [homeassistant.helpers.template] Template variable warning: 'homeassistant.helpers.template.Wrapper object' has no attribute '0' when rendering '{% if is_state('binary_sensor.porssari_json_controls', 'on') %}
{% set curHour = now().hour | string %}
{{ state_attr("sensor.porssari_json_data", "Channel1")[curHour] }}
{% else %}
{{ -1 }}
{% endif %}'
2023-11-23 00:39:22.752 WARNING (MainThread) [homeassistant.helpers.template] Template variable warning: 'homeassistant.helpers.template.Wrapper object' has no attribute '0' when rendering '{% if is_state('binary_sensor.porssari_json_controls', 'on') %}
{% set curHour = now().hour | string %}
{{ state_attr("sensor.porssari_json_data", "Channel2")[curHour] }}
{% else %}
{{ -1 }}
{% endif %}'
2023-11-23 00:39:22.753 WARNING (MainThread) [homeassistant.helpers.template] Template variable warning: 'homeassistant.helpers.template.Wrapper object' has no attribute '0' when rendering '{% if is_state('binary_sensor.porssari_json_controls', 'on') %}
{% set curHour = now().hour | string %}
{{ state_attr("sensor.porssari_json_data", "Channel3")[curHour] }}
{% else %}
{{ -1 }}
{% endif %}'
2023-11-23 00:39:22.753 WARNING (MainThread) [homeassistant.helpers.template] Template variable warning: 'homeassistant.helpers.template.Wrapper object' has no attribute '0' when rendering '{% if is_state('binary_sensor.porssari_json_controls', 'on') %}
{% set curHour = now().hour | string %}
{{ state_attr("sensor.porssari_json_data", "Channel4")[curHour] }}
{% else %}
{{ -1 }}
{% endif %}'
2023-11-23 00:39:22.754 WARNING (MainThread) [homeassistant.helpers.template] Template variable warning: 'homeassistant.helpers.template.Wrapper object' has no attribute '0' when rendering '{% if is_state('binary_sensor.porssari_json_controls', 'on') %}
{% set curHour = now().hour | string %}
{{ state_attr("sensor.porssari_json_data", "Channel5")[curHour] }}
{% else %}
{{ -1 }}
{% endif %}'
2023-11-23 00:39:22.758 WARNING (MainThread) [homeassistant.helpers.template] Template variable warning: 'homeassistant.helpers.template.Wrapper object' has no attribute '0' when rendering '{% if is_state('binary_sensor.porssari_json_controls', 'on') %}
{% set curHour = now().hour | string %}
{{ state_attr("sensor.porssari_json_data", "Channel6")[curHour] }}
{% else %}
{{ -1 }}
{% endif %}'
2023-11-23 00:39:22.759 WARNING (MainThread) [homeassistant.helpers.template] Template variable warning: 'homeassistant.helpers.template.Wrapper object' has no attribute '0' when rendering '{% if is_state('binary_sensor.porssari_json_controls', 'on') %}
{% set curHour = now().hour | string %}
{{ state_attr("sensor.porssari_json_data", "Channel7")[curHour] }}
{% else %}
{{ -1 }}
{% endif %}'
2023-11-23 00:39:22.759 WARNING (MainThread) [homeassistant.helpers.template] Template variable warning: 'homeassistant.helpers.template.Wrapper object' has no attribute '0' when rendering '{% if is_state('binary_sensor.porssari_json_controls', 'on') %}
{% set curHour = now().hour | string %}
{{ state_attr("sensor.porssari_json_data", "Channel8")[curHour] }}
{% else %}
{{ -1 }}
{% endif %}'Tuo ajanhetki 00:39:22 on juurikin se, jolloin yllä olevassa kuvassa ympyröity katkos alkaa. Jos tähän löytyisi korjaus, niin olisi todella hienoa. Odotan nimittäin suurella mielenkiinnolla tuota älykästä lämmityksen ohjausta ja haluaisin päästä sitäkin kokeilemaan.
Mitäs tähän voi laittaa invertterikoneiden kohdalla? Eihän ne käy juuri koskaan "täysillä"? Eli miten tässä voi huomioida että laitteen antoteho voi olla 1,5kW tai 8kW tai mitä hyvänsä siltä väliltä ja se että laitteelle annetaan lupa lämmittää ei kerro mitään siitä paljonko se tuottaa sitten oikeasti lämpöä? Tai että VILP antaa 12kW plussalla, mutta 5kW kovemmalla pakkasella.
Ts. jos on päälämmitys vaikka 8kW ja lasketaan että lämmitysjaksolla tarvitaan 8kW lämpöä, niin eihän oikeasti mikään lämpöpumppu tunnissa sitä lämpöä välttämättä tuota.
Viimeksi muokattu:
Minusta esimerkiksi vesi-ilmalämpöpumpuissa on sähkövastus sitä varten, että antoteho ei notkahda pakkasella vaan sen voidaan olettaa tuottavan suunniteltu antoteho.
Mutta nostat tässä esiin juuri niitä asioita mitkä ajattelin tuon postauksen ensimmäisessä kappaleessa kuittaavani, eli kyseessä on ensimmäinen kehitysversio. Todennäköisesti jatkossa osataan ottaa huomioon erilaisia lämmitystiloja ja myös sitä, että koska sähkön hinta on riittävän tasaista eikä kannata lämmittää täysillä vs periodissa on muutama halpa hetki ja loput kallista, milloin taas olisi pakko lämmittää täysillä hyötysuhteen kustannuksella.
Toivon mieluummin kehitysehdotuksia kuin puutteiden esille nostamista, niin saadaan kehitystyötä myös sinun toiveidesi mukaan eteenpäin.
Silloin se menisi juurikin noin. Ja todellisuudessa ohjaillaan sitten varttitasolla, toki hinnat on jokaiselle vartille tunnin sisällä vielä samat.
Tarkoituksena ei ole ollut tuoda enää erikseen ainakaan tuota tuntirajaa, mutta olisiko hintaraja tässä mukavuuslämmityksessä kuitenkin tarpeellinen? Se olisi helppo tuoda kyllä kokonaisuuteen mukaan, ehkä ennemmin kuitenkin periodin keskihintaan perustuen kuin yksittäisen tunnin/vartin hintaan.
Tuo uusi versio muuttaa tuota ohjaustiedon hakemista olennaisesti, niin ainakaan samanlainen vika siinä ei voi toistua. Tuo on kyllä vähän mysteeri mistä johtuu, mutta en ehkä selvittele asiaa pidemmälle vaan oletan kaikkien käyttäjien päivittävän tuohon uudempaan versioon!
Eikö normaalisti nosteta esiin ensin puutteita ja sitten niihin voi miettiä ratkaisuja jos puutteet ovat todellisia? Eikä minulla mitään toiveita varsinaisesti ole, mutta huomioita silti voi olla.
Ei VILP käytä vastuksia, että se antaisi aina nimellistehonsa. Eikä MLP aja aina täysillä kierroksilla, että antaisi aina nimellistehonsa. Eikä ILP pyöritetä täydellä puhalluksella ja täydellä pyynnillä että se antaisi nimellistehonsa.
Minusta tämä on ihan olennainen kysymys, jos päälämmitysjärjestelmän "tehon" perusteella lasketaan kauanko lämmitetään. Antottehoa kun ei pirukaan osaa sanoa uudenaikaisessa pumpussa joka säätyy invertterin avulla. Sähkövastus on asia erikseen.
Sama ongelma liittynee myös tapaan missä käyttäjä arvaa tarvittavaa tuntimäärää. Tässähän on vain tarkoitus johtaa sama tieto laskennallisesta talon lämmitystarpeesta.
Mutta kiitos palautteesta, lisään sen kehitysehdotuksiin. Suosittelen myös odottelemaan minkälaisia dokumentaatioita tämän pohjalta on ajateltu kirjoittaa ja miten tätä täysin meidän tiedossa olevaa asiaa on tarkoitus yrittää selättää.
Lämmityslaitteen tyyppi valitaan juuri sen takia, että jatkossa voidaan huomioida tätä antotehon heikkenemistä ulkolämmön laskiessa.
Viimeksi muokattu:
Itellä on kytenyt sellainen ajatus tuosta sääennusteohjauksesta, että se voisi olla ns. lämpökäyrä, menolämpö vaan korvautuu tuntimäärällä.
Eli voisi asetella 10 ulkolämpötila-asteen välein sallittujen tuntien määrän ja lisäksi asettaa minimi- ja maksimituntimäärän. Ja bonuksena hintarajan aina sallituille tunneille.
Tuo olisi ainakin helppo säätää omaan makuun sopivaksi, eri asia sitten onko se helppo toteuttaa.
Tässä on se visio juurikin semmoinen, että tuo minimi- ja maksimitunnit tulisi tavallaan ”automaattisesti” sen mukaan paljonko jaksolla voidaan yli- ja alilämmittää tulevaisuuden lämpöennuste sekä sähkönhinta huomioiden.
En osaa sanoa pääsisikö tuollaisella manuaalisella tuntimäärällä paljon tarkempaan lopputulokseen, mutta säätämistä se vaatisi aika paljon enemmän. Tuossa lämmitysohjauksessa on kuitenkin paljon muuttujia, ja ollenkaan vähäisimpänä ei ole se mitä asukas sitten tekee vaikkapa takalla tms, käytetäänkö uunia sisällä, saunotaanko ja lto ottaa lämpöä talteen jne.
Mutta katsellaan mihin tuo automatiikka taipuu, ja toisena vaihtoehtona on tuo hyvin karkea lineaarinen manuaaliohjaus ehkä jakson keskihintarajalla varustettuna. Uskoisin, että kuukauden sisään ollaan viisaampia onko tämä nykyinen visio susi syntyessään vai onko se hienosäätöä vaille lähes täydellinen. Todennäköisesti jotain siitä väliltä.
Tätä itsekin miettinyt. Ohjattavana on 2-8 kW MLP. Jos laskeskelee tuntitarvetta tiukasti maksimitehon mukaan, saa ohjauksessa nostaa pyyntiä aika reippaasti, että maksimitehot tulee käyttöön. Olen ratkaissut asian toistaiseksi siten, että alustava tuntitarve on arvioitu tuon 8 kW mukaan, mutta olen sitten hienosäätänyt tuntimääriä kokemuksen perusteella.
Lisänä tuossa on se, että maksimitehoilla hyötysuhde heikkenee. Ihan pienen hintaeron vuoksi tuntimäärää ei kannata rajata eli tuntimäärä on minimi ja useimmiten siihen tulee sitten x määrä lisätunteja pienen hintaeron tai absoluuttisesti halpojen hintojen myötä. Minulla hyötysuhteen heikkeneminen on ihan jonkinlainen, kun MLP:n keruupumppu alkaa maksimitehoilla ahdistaa ja delta-T kasvaa. Lisätuntien salliminen poistaa myös tarvetta käyttää tuota huipputehoa.
Alla spoilerissa näkyy sisälämpötilan pyyntiin perustuva MLP:n säätö ja toteutunut pumpun ilmoittama antoteho. Sisälämpötilan pyynti ylhäällä ja antoteho alhaalla.
Tämä tehtiin nyt alkuun omat järjestelmät edellä, mutta käytännössä on tehty niin, että nyt joko kytketään päälle tehostettu lämmitys tai kokonaan pois. Käytännössä palvelee parhaiten sähkölämmittäjiä tai on-off -lämpöpumppujen omistajia.
Seuraavan vaiheen yksi osuus on juurikin arvioida tuon jakson keskihinnan ja keskihajonnan perusteella, että kannattaako lämmittää täysillä vai paremmalla hyötysuhteella. Meillä on projektissa mukana apuvoimia kenellä on tarkkaa dataa juuri tämäntyyppisestä optimoinnista. Kaikkea vaan ei ehdi tehdä kerralla, ja tämäkin systeemi sopinee jo isolle joukolle tämmöisenään.
Toki pitää muistaa, että varsinkaan mlp:ssä se hyötysuhde ei lattialämpöä tehdessä ihan hirveästi notkahda, ja loppuviimeksi sähkön ei tarvitse paljoa kallistua kun se syö jo tuon hyötysuhde-eron vaikutuksen.
Mitä hienompaa seurantaa tehdään ja sen perusteella säädetään + jaksetaan nähdä vaivaa säätämisen eteen, niin sen parempaan lopputulemaan päästään. Mutta jos tämä systeemi nyt ohjaisi vaikkapa ilpit ja tarvittaessa seinäpattereita/lattialämpöä päälle automaattisesti, niin onko se jo riittävän hyvä kuitenkin?
Mutta hyvää pohdintaa, ja palaan mielelläni tähän keskusteluun ihan konkretiankin osalta kun saadaan systeemi pyörimään ja ensimmäiseksi vahvistus siihen, että edes ne arvioidut tuntimäärät menee hehtaarilleen oikein muuallakin kun minulla ja Atella.
Voi olla, että invertterikoneita kannattaa alkuun ajaa tuolla manuaalisäädöllä vähän liian isolla tuntimäärällä, eli käytännössä leikata kalleimpia tunteja pois. Tai sitten Mikin smartheatingilla missä pääsee parametroimaan enemmän manuaalisesti.
Odotan mielenkiinnolla, minkälaisia kehitysaskeleita tulee muuttuvan COPin / pumppujen ohjauksessa. Edelleen olen sitä mieltä, että olet tehnyt Pörssärin kanssa erinomaista työtä. Olen täysin valmis hylkäämään omat räpellykseni, kun tarpeeksi avoin ja toimintavarma valmis vaihtoehto tulee saataville. Nyt tuo oma toimii yllättävän hyvin, kun se on rakennettu juurikin omaan tilanteeseen ja tarpeisiin.
Voi tuo hyötysuhde-ero olla yllättävän suuri. Meillä taitaa pahimmillaan laskea alle 4,5 MLP:n lämmitys-COP ja parhaimmillaan se on yli 6. Vaikuttavia tekijöitä on ainakin kaivosta tulevan liuoksen lämpötila, liuokseen tuleva delta-T sekä lattiassa kiertävän veden lämpötila, jotka kaikki ovat läsnä, kun lyhyessä ajassa yritetään tehdä maksimitehoilla lämpöä. Täällä tosiaan on reilun mittainen kaivo, mutta liuospumpusta loppuu "ylitehoilla" puhti ja tämä näkyy heti hyötysuhteessa.
Nyt kun tuli taas uudet hinnat, on lämmitystunteja täällä ohjauksessa 11 tuntia seuraavalle 24 tunnille (jakson lämpötila -10 astetta). Jaksolla on sen verran tasaiset tuntihinnat, että lisätunteja tulee toiset 11 tuntia eli kiellettyjä onkin vain 2. Saa nähdä, minkälaisena lämmitys toteutuu.
En tiedä olenko tämän kanssa ihan hakoteillä. Jos pitäisi tuotta esim. 10 kWh lämmitystä. Hyötysuhteella 4,5 tarvitaan 2,22 kWh energiaa ja hyötysuhteella 6 tarvitaan 1,67 kWh. Jos esim. halvemmalla 10 c/kWh tuntihinnalla tuotetaan 4,5 hyötysuhteella tuo 10 kWh on kustannus kuvitteellisen 5,5 c/kWh siirron kanssa 34 senttiä. Vastaavasti 6 hyötysuhteella tuntihinta saa olla noin 15 c/kWh, jolloin siirron kanssa (5,5 c/kWh) tulee sama kustannus (1,67 kWh * (15 + 5,5) c/kWh). On luultavasti siis kannattavaa sallia lisätunteja, jos tuntihinnat ovat sopivasti kalliimpia. Voisin kuvitella, että myös pumpun elinkaareen voi vaikuttaa positiivisesti tasaisempi kuormitus.
Kiitos, ja haluan aina näissä muistuttaa, että Atte on kuitenkin se automaatioinsinööri kaiken tämän hienon ohjauskoodin takana!
Itse ajattelisin tuon hyötysuhdelaskennan menevän juurikin noin. Toki jonkinlaisia keskimääräisiä oletuksia joudutaan aina käyttämään, mutta yleensä ne menee melkolailla hehtaarilleen kuitenkin oikein. Invertteripumppujen kanssa ollaan isompien haasteiden edessä, ja täysin optimaalisen systeemin toiminta ei enää periaatteessa voi toimia pelkkään arvailuun perustuen, vaan sitten pitäisi jo kyetä ottamaan myös tietoa vastaan serverin suuntaan laskennan korjaamista varten.
Mutta tuo jakson hintavaihtelu on tarkoitus tehdä heti seuraavaksi, ja juurikin hoitaa tuo, että jos sähkö on kokoajan halpaa/kallista, niin maksimoidaan hyötysuhde lämmittämällä vain tarpeeseen vs isompi hintavaihtelu, jolloin kannattaa lämmittää kovempaa vaikka hyötysuhde vähän notkahtaa. Uskoisin kuukauden sisällä tulevan tähän ensimmäinen kehitysversio kunhan saadaan vähän kerättyä dataa omalla on-off -maalämpöpumpulla ja Aten invertteri-ilmalämpöpumpuilla.
Olen jättänyt tuon oman tarkastelun aika yksinkertaiseksi eli varsinaisten lämmitystuntien lisäksi sallitaan muita tunteja, jos ne on alle valitun prosenttimäärän tai kiinteän senttimäärän kalliimpia kuin varsinaisten lämmitystuntien tuntihintojen keskiarvo. Laitoin exceliin vähän eri skenaariota ja tällä hetkellä prosenttina on 25 %, kun siirron hinta on mukana tarkastelussa. Kompromissi yhtä kaikki. Muuttuvaa rajaa en ole ajatuksissani edes hahmotellut.
Tänään ei klo 21.00 napsahtanut lämmitys päälle, klo 01-08 lämmitti normaalisti. 10 halvinta siis sallittuna.
Laitoin nyt manuaalisesti Shellyn eston pois, onkohan tuo paikallinen vai ulkopuolinen vika/ongelma?
Edit. Buuttasin shellyt (lämmitys ja käyttövesi), laitteet näkyi päivittyneen porssari.fi:n minuutti boottauksen jälkeen. Käyttövesi näkyi päivittyneen 10 min aiemmin, mutta lämmitys oli viimeksi päivittynyt about 22.57.
Laitoin nyt manuaalisesti Shellyn eston pois, onkohan tuo paikallinen vai ulkopuolinen vika/ongelma?
Edit. Buuttasin shellyt (lämmitys ja käyttövesi), laitteet näkyi päivittyneen porssari.fi:n minuutti boottauksen jälkeen. Käyttövesi näkyi päivittyneen 10 min aiemmin, mutta lämmitys oli viimeksi päivittynyt about 22.57.
Viimeksi muokattu:
Tuo päivitys aiheutti nyt vähän harmaita hiuksia, mutta bugit on nyt fiksattu ja kaikki laitteet pakotettu keskusjohtoisesti ruotuun.
Tähän löytyi itseasiassa selitys tuolta serverin päästä. Tuossa kun uutta jsonia rakenneltiin, niin oli tippunut/tiputettu JSON_FORCE_OBJECT pois siitä jsonin muodostamisesta, koska se uudenmuotoinen toimii niinkuin jsonin kuuluu. Se johti puolestaan siihen, että kun tunti oli 00, niin jsonista jätettiin keyt kokonaan pois, ongelma ei vaikuttanut muihin tunteihin ja siksi sitä ei edes saatu kiinni.
No, onpahan nyt tämäkin vielä korjattu. Tosiaan pyritään edelleen siihen, että tarvetta tuon vanhan jsonin käyttöön ei kenelläkään enää tämän viikon jälkeen olisi. Toki tuki sille tuolla serverillä tulee säilymään, joskin varttiohjaus ei sillä toimi ihan oikein koska antaa koko tunnille sen ensimmäisen vartin ohjaustilan.
Uudessa versiossa pyrin tekemään niin, että tuo json säilyy data-sensorissa myös bootin yli. Nythän se pyyhkäistään tyhjäksi ha:n uudelleenkäynnistyessä.
Jos löytyy ketään innokasta Python-osaajaa tekemään HACS-lisäosaa tämän ohjaustiedon hyödyntämiseksi, niin otan mielelläni yhteydenottoja vastaan! Python-koodi tuohon ohjaustiedon hakuun serveriltä on jo olemassa omassa micropython-skriptissä, ja sensorilogiikka on tuossa YAML-koodissa. Kanavanimet saa myös tuolta serveriltä jsonin mukana, eli jos vaan HA:n päässä se on mahdollista, niin friendly namen voisi myös sitä kautta tuoda suoraan. Jollain aikataululla on tarkoitus tehdä asetusten muokkausrajapinta serverin päähän, eli periaatteessa se mahdollistaisi sitten myös palvelinasetusten muokkaamisen ha:n päästä.
Välillä sekä perhe-elämä että työelämä tuntuu häiritsevän harrastuksia, mutta kaikesta huolimatta asiat hiljalleen aina etenee!
Kiitos muutamien aktiivisten debuggaajien ollaan saatu vielä muutama bugi kiinni tuosta lämmitysohjauksesta. Eli ehkäpä sitä nyt uskaltaa jo tarjota paremmin käyttöön. Säätiedot tosiaan haetaan yr.no -rajapinnasta, missä ainakin spot-hinnan fb-ryhmän perusteella tuntuu olevan jonkin verran epätarkkuutta todellisiin lämpötiloihin. En osaa sanoa liittyykö tuo enemmän vuorokauden keskihintaan vai mihin, mutta seuraillaan tilannetta ja tarvittaessa täytyy päivittää tuonne ilmatieteen laitoksen rajapinnalle.
Ohjeistusta lämmitysohjaukseen löytyy sivulta https://docs.porssari.fi/sivuston-ohjeet/laemmityksen-ohjaus, se on vielä osin vajavainen ja mahdollisesti hyvinkin epälooginen. Kyselkää epäselviä asioita, niin yritän selventää ja lisäksi parannella ohjeita! Olen huomannut, että se mikä itselle tuntuu päivänselvälle ei välttämättä tai edes todennäköisesti ole sitä muille.
Tosiaan seuraava vaihe on alkaa muokkaamaan periodin lämmitystarvetta sen mukaan mitä tulevaisuudessa tapahtuu, ja lisäksi tuoda mukaan antotehon hiipumisen arvioimista ulkolämmön painuessa kylmemmäksi, tämä koskee lähinnä ulkoilmasta lämpöään kaappaavia laitteita. Toki VILP ei suoranaisesti vähennä tokikaan lämmitystehoa, vaan ottaa sitten vaan tarvittaessa lisävastuksia avukseen.
Kiitos muutamien aktiivisten debuggaajien ollaan saatu vielä muutama bugi kiinni tuosta lämmitysohjauksesta. Eli ehkäpä sitä nyt uskaltaa jo tarjota paremmin käyttöön. Säätiedot tosiaan haetaan yr.no -rajapinnasta, missä ainakin spot-hinnan fb-ryhmän perusteella tuntuu olevan jonkin verran epätarkkuutta todellisiin lämpötiloihin. En osaa sanoa liittyykö tuo enemmän vuorokauden keskihintaan vai mihin, mutta seuraillaan tilannetta ja tarvittaessa täytyy päivittää tuonne ilmatieteen laitoksen rajapinnalle.
Ohjeistusta lämmitysohjaukseen löytyy sivulta https://docs.porssari.fi/sivuston-ohjeet/laemmityksen-ohjaus, se on vielä osin vajavainen ja mahdollisesti hyvinkin epälooginen. Kyselkää epäselviä asioita, niin yritän selventää ja lisäksi parannella ohjeita! Olen huomannut, että se mikä itselle tuntuu päivänselvälle ei välttämättä tai edes todennäköisesti ole sitä muille.
Tosiaan seuraava vaihe on alkaa muokkaamaan periodin lämmitystarvetta sen mukaan mitä tulevaisuudessa tapahtuu, ja lisäksi tuoda mukaan antotehon hiipumisen arvioimista ulkolämmön painuessa kylmemmäksi, tämä koskee lähinnä ulkoilmasta lämpöään kaappaavia laitteita. Toki VILP ei suoranaisesti vähennä tokikaan lämmitystehoa, vaan ottaa sitten vaan tarvittaessa lisävastuksia avukseen.
Pientä tilapäisviilausta on tehty käyttäjäpalautteen perusteella tuohon lämmitysohjaukseen. Eli alunperin oli ajatuksena, että pisin periodi mille lämmitysvartit jaetaan on 12h, mutta kun toistaiseksi puuttuu se vähennys/lisäys seuraavan jakson perusteella niin toki nykyisellään johtaa tilanteeseen missä esimerkiksi 10h vuorokauden lämmitystarvetta jaetaan tasan kaikkiin 3-12h jaksoihin huolimatta siitä miten niiden keskihinnat toisiinsa suhteutuu.
Eli mahdollisuutena on nyt valita myös tuo 24h tarkastelujakso ( 18-18 ). Toki siinä täytyy huomioida, että vuorokauden keskilämpötila kuvaa huonosti semmoisia päiviä missä vaikkapa pakkanen kovasti haluaa lähteä illasta kiristymään tai lauhtumaan. Tai semmoisia, että päivällä onkin selvästi lämpöisempää kuin yöllä.
Systeemissä on vielä pieni bugi, eli jos seuraavan päivän hintoja ei ole, niin ymppää tuohon jäljelle jäävään 18-00 -periodiin kaiken lämmitystarpeen sille seuraavalle jaksolle. Se korjaantuu aina toki ennen kyseisen jakson alkua kun hinnat päivitetään seuraavalle vuorokaudelle. Tämä korjataan lähipäivinä myös.
Tuota periodien painotusta seuraavan jakson hinnan ja lämmön perusteella aletaan työstää seuraavaksi, ja lisäksi erilaisten ulkoilmasta lämpönsä ottavien laitteiden antotehon heikkenemistä ulkolämmön pudotessa mallinnetaan parhaillaan, ja tuodaan jatkossa osaksi päälläolotarvelaskentaa.
Lisäksi Atella alkaa olla Themo-integraatio valmiina testiin, ja seuraavaksi sitten tekee samalla logiikalla Sensibon. Sivuston ulkoasua on myös lähdetty modernisoimaan uuden templaatin avulla, esimakua saa osoitteesta https://www.porssari.fi/testsite, joskaan sivustolla ei käytännössä tavallisilla tunnuksilla näe mitään muuta kun rankasti keskeneräisen ui:n..
Eli mahdollisuutena on nyt valita myös tuo 24h tarkastelujakso ( 18-18 ). Toki siinä täytyy huomioida, että vuorokauden keskilämpötila kuvaa huonosti semmoisia päiviä missä vaikkapa pakkanen kovasti haluaa lähteä illasta kiristymään tai lauhtumaan. Tai semmoisia, että päivällä onkin selvästi lämpöisempää kuin yöllä.
Systeemissä on vielä pieni bugi, eli jos seuraavan päivän hintoja ei ole, niin ymppää tuohon jäljelle jäävään 18-00 -periodiin kaiken lämmitystarpeen sille seuraavalle jaksolle. Se korjaantuu aina toki ennen kyseisen jakson alkua kun hinnat päivitetään seuraavalle vuorokaudelle. Tämä korjataan lähipäivinä myös.
Tuota periodien painotusta seuraavan jakson hinnan ja lämmön perusteella aletaan työstää seuraavaksi, ja lisäksi erilaisten ulkoilmasta lämpönsä ottavien laitteiden antotehon heikkenemistä ulkolämmön pudotessa mallinnetaan parhaillaan, ja tuodaan jatkossa osaksi päälläolotarvelaskentaa.
Lisäksi Atella alkaa olla Themo-integraatio valmiina testiin, ja seuraavaksi sitten tekee samalla logiikalla Sensibon. Sivuston ulkoasua on myös lähdetty modernisoimaan uuden templaatin avulla, esimakua saa osoitteesta https://www.porssari.fi/testsite, joskaan sivustolla ei käytännössä tavallisilla tunnuksilla näe mitään muuta kun rankasti keskeneräisen ui:n..
Viimeksi muokattu:
Pienenä uutena ominaisuutena tuotiin ilmalämpöpumpun lämmitysteholaskentaan dynaamisuus ulkolämmön mukaan. Eli nyt lämmitysteho ei ole kiinteä, vaan lasketaan nimellistehon ja lämmitysjakson ulkolämmön perusteella. Ilppien ohjausta on vielä haastavaa toteuttaa kun Sensibo ei ole ihan vielä valmis, mutta käytännössä tuo vaikuttaa myös siihen laskentaan missä vaiheessa pitää alkaa pyytää muita lämmitysjärjestelmiä apuun.
Aiemmin lisätyt ilp:t ovat edelleen kiinteällä lämmitysteholla kunnes käyttäjä käy napsauttamassa sen tuohon dynaamiseen moodiin. Eli mitään muutosta ei tapahtunut mikä vaikuttaisi jo olemassaoleviin ohjauksiin.
Sivustolle https://docs.porssari.fi on nyt myös saatu rajapintakuvausta alulle aktiivisen ulkopuolisen kehittäjän avulla joka oli integroidut omalla sovellutuksellaan Pörssärin ohjaamaan controlmyspa-ohjausta tottelevia ulkoporealtaita!
github.com
Aiemmin lisätyt ilp:t ovat edelleen kiinteällä lämmitysteholla kunnes käyttäjä käy napsauttamassa sen tuohon dynaamiseen moodiin. Eli mitään muutosta ei tapahtunut mikä vaikuttaisi jo olemassaoleviin ohjauksiin.
Sivustolle https://docs.porssari.fi on nyt myös saatu rajapintakuvausta alulle aktiivisen ulkopuolisen kehittäjän avulla joka oli integroidut omalla sovellutuksellaan Pörssärin ohjaamaan controlmyspa-ohjausta tottelevia ulkoporealtaita!
GitHub - arska/controlmyspa-porssari: Set a Balboa ControlMySpa Whirlpool temperature according to NordPool power prices using pörssäri.fi
Set a Balboa ControlMySpa Whirlpool temperature according to NordPool power prices using pörssäri.fi - arska/controlmyspa-porssari
github.com
Viimeksi muokattu:
Olisko mahdollista saada tähän Pörssärin ihan "normaaliin ohjaukseen" eli aika/hinta/tms myös lisäominaisuuksia? Eli siellä kun on nyt jo "pisin sallittu tauko" niin sille olisi kiva saada käänteinenkin toiminto, eli "lyhin mahdollinen päälläolo" tms. Eli esim jos asetukset ovat sellaiset, että pisin sallittu tauko on 3h ja "jätä kytkemättä kalleimmat tunnit" on 6h niin voi tulla tilanne eteen, että ollaan 3h pois päältä, tunti päällä ja 2h pois päältä. Ideaalimpi olisi, että olisi 3h pois päältä, vähintään 2h päällä ja sitten vasta taas pois päältä.
En heti lupaa mutten täysin poissulje etteikö tällaista voisi tehdäkin myös tuohon manuaalitilaan. Nykyisellään tuo maksimitauko on toteutettu aika karskilla tavalla, eli täysin hinnasta välittämättä laitetaan aina tunti päälle kun tauko tulee täyteen. Logiikkana se on äärimmäisen yksinkertainen.
Ajattelisin itse, että tuontyyppisen ohjauksen tärkeimmät käyttötarkoitukset löytyy tuolta lämpöpumppujen ohjaamisesta, ehkä myös auton lataamisesta pakkasella. Miksei varaajankin, kun ei sekään nyt ihan hyvää tee, että vartin välein räpsytellään kontaktoria edestakaisin.
Ainakin tuohon lämmitysohjauslogiikkaan on ehdottomasti tulossa mukaan minimipäälläolo. Todennäköisesti vähän samalta pohjalta lähdetään tekemään tuota periodiajattelua sitten myös noihin muihin ohjauksiin, ja oikeastaan tarkoitus olisi päästä jopa kokonaan eroon noista täysin manuaaliohjauksista. En osaa visioa tässä täysin tarkasti nyt avata, mutta kunhan saadaan tuota nyt johonkin malliin niin palataan sitten asiaan tuon manuaaliohjauksen kehittämisen kanssa mikäli sille löytyy vielä selkeä käyttötarkoitus!
Themo-termostaatti- ja Sensibo-integraatiot alkaa olla valmiina käyttöön. Testaillaan vielä hetki toimivuutta, mutta jos on intoa jo ottaa itsellekin testiin niin sivuston palautelomakkeella voi laittaa omat tiedot ja lisään oikeudet sivustolla päästä käsiksi tuohon asetuslomakkeeseen.
Themo-integraatiossa täytyy sivustolle syöttää käyttäjätunnus ja salasana. Ne kryptataan kantaan kuten myös se api-key mikä kerran vuorokaudessa tunnusten avulla haetaan. Tunnukset tarvitaan sen takia, että muutoin tuo apikeyn uudistaminen ei onnistu.
Sensibon osalta homma on siinä mielessä simppelimpi, että apikey luodaan sensibossa ja se vaan lisätään sivustolle. Toki sekin samallalailla kryptataan tietokantaan.
Varmaan parin viikon sisään tulee ohjeistuksineen julkiseen käyttöön, mutta tosiaan testaamaan pääsee jo halutessaan etuajassa. Tehtäneen tuo lämmitystarpeen painotus vielä alulle ennen tuon julkaisemista niin saa koko paketin sitten heti toimimaan optimaalisemmin.
Themo-integraatiossa täytyy sivustolle syöttää käyttäjätunnus ja salasana. Ne kryptataan kantaan kuten myös se api-key mikä kerran vuorokaudessa tunnusten avulla haetaan. Tunnukset tarvitaan sen takia, että muutoin tuo apikeyn uudistaminen ei onnistu.
Sensibon osalta homma on siinä mielessä simppelimpi, että apikey luodaan sensibossa ja se vaan lisätään sivustolle. Toki sekin samallalailla kryptataan tietokantaan.
Varmaan parin viikon sisään tulee ohjeistuksineen julkiseen käyttöön, mutta tosiaan testaamaan pääsee jo halutessaan etuajassa. Tehtäneen tuo lämmitystarpeen painotus vielä alulle ennen tuon julkaisemista niin saa koko paketin sitten heti toimimaan optimaalisemmin.
Oletko @tk- ajatellut koodien julkaisemista jollain avoimehkolla lisenssillä githubissa? Voisi tulla mahdollisesti pull requesteja muiltakin, jopa hyviäkin. Samaten dokumentaation voisi tulla lisää käsipareja. Tietenkin mikäli meinaat kaupallistaa myöhemmin niin silloin IPR loogista pitää omissa hyppysissä
Oikeastaan Atte on kirjoittanut suurimman osan koodeista niin en yksin niistä pysty edes päättämään.
Tässä on tällä hetkellä semmoinen ajatus taustalla, että pidetään vielä omissa hyppysissä, kun meinaa meillä itselläkin välillä koodi ja toimintalogiikat rönsyillä liikaa ja kokonaisuus ei vielä ole betonissa. Kunhan saadaan tuo perusta kuntoon, niin sitten todennäköisesti julkaistaan koodit ja miksei sitten tuota koko serveriäkin voitaisi luovuttaa jonkinlaisen yhteisön ylläpidettäväksi?
Toki hintatietojen haku on periaatteessa aina se ongelma, kun virallista rajapintaa niihin ei ole maksuttomana olemassa.
Dokumentaatio on nykyiselläänkin julkisena githubissa, ja sinne saa vapaasti laittaa pull requesteja kyllä! Itse asiassa se rajapintakuvaus on hyvin pitkälti Pörssäriä hyödyntävän controlmyspa-lisäosan tekemä.
Tarkoitus on tässä kuukauden sisään viedä Pörssäri enemmän kiinteistön kokonaishallinnan suuntaan asetusten osalta mikä puolestaan mahdollistaa helposti myös muiden kun Shellyjen tuomisen mukaan ohjauslogiikkaan.
Onko erityisiä toiveita minkälaisia laitteita jatkossa tuettaisiin? Käytännön sovellutuksena toimisi joko suorat cloud-to-cloud -tyyppiset ratkaisut tai vaihtoehtoisesti MQTT, tarkoituksena on asentaa broker Pörssärin serverille ja sitä sitten hyödyntää ohjaustiedon välitykseen.
Esimakua tulevasta käyttöliittymälogiikasta liitekuvana.
Onko erityisiä toiveita minkälaisia laitteita jatkossa tuettaisiin? Käytännön sovellutuksena toimisi joko suorat cloud-to-cloud -tyyppiset ratkaisut tai vaihtoehtoisesti MQTT, tarkoituksena on asentaa broker Pörssärin serverille ja sitä sitten hyödyntää ohjaustiedon välitykseen.
Esimakua tulevasta käyttöliittymälogiikasta liitekuvana.
Liitetiedostot
Mielestäni en löytänyt Pörssäristä tällaista asetusta:
Salli kaikki tunnit jotka alle vuorokauden pörssihinnan keskiarvon.
En ole matemaattista tutkielmaa suorittanut asiasta, mutta nopeasti mietittynä jos suurin kulutus keskittyy aina vuorokauden noihin yllämainittuohin tunteihin, on vuorokauden kulutusvaikutus aina negatiivinen ja todennäköisesti se on sitä myös kuukausitasolla?
Mitä nopeasti vilkaisin eilisen, tämän päivän ja huomisen osalta niin noita tunteja on samassa järjestyksessä 17/10/14. Jos omaan tilanteeseen peilaan, niin mulle riittää 9 halvinta tuntia helposti talon lämmitykseen korotetulla käyrällä kun takoilla lämmitän loppulämmöt, mutta joku 17 tuntia eilisen osalta olisi aika hyvin ehtinyt myös varaamaan laattaa tuleville pakkaspäiville ja tuollainen "aktiivinen" säätö tuntuu yhtäkkiä ihan hyvältäkin vaihtoehdolta. Jos se vaan käytännössä kulutusvaikutusta pakkasella pitää.
@Mikki laitetaan idea myös jakoon "kilpailijalle" tasapuolisuuden nimissä
Salli kaikki tunnit jotka alle vuorokauden pörssihinnan keskiarvon.
En ole matemaattista tutkielmaa suorittanut asiasta, mutta nopeasti mietittynä jos suurin kulutus keskittyy aina vuorokauden noihin yllämainittuohin tunteihin, on vuorokauden kulutusvaikutus aina negatiivinen ja todennäköisesti se on sitä myös kuukausitasolla?
Mitä nopeasti vilkaisin eilisen, tämän päivän ja huomisen osalta niin noita tunteja on samassa järjestyksessä 17/10/14. Jos omaan tilanteeseen peilaan, niin mulle riittää 9 halvinta tuntia helposti talon lämmitykseen korotetulla käyrällä kun takoilla lämmitän loppulämmöt, mutta joku 17 tuntia eilisen osalta olisi aika hyvin ehtinyt myös varaamaan laattaa tuleville pakkaspäiville ja tuollainen "aktiivinen" säätö tuntuu yhtäkkiä ihan hyvältäkin vaihtoehdolta. Jos se vaan käytännössä kulutusvaikutusta pakkasella pitää.
@Mikki laitetaan idea myös jakoon "kilpailijalle" tasapuolisuuden nimissä
Mielestäni Pörssärissäkin tuo on, mutta päivän keskihinta on spot-hinnassa jo tuettu, rank-and-price skriptissä ainakin.Mielestäni en löytänyt Pörssäristä tällaista asetusta:
Salli kaikki tunnit jotka alle vuorokauden pörssihinnan keskiarvon.
En ole matemaattista tutkielmaa suorittanut asiasta, mutta nopeasti mietittynä jos suurin kulutus keskittyy aina vuorokauden noihin yllämainittuohin tunteihin, on vuorokauden kulutusvaikutus aina negatiivinen ja todennäköisesti se on sitä myös kuukausitasolla?
Mitä nopeasti vilkaisin eilisen, tämän päivän ja huomisen osalta niin noita tunteja on samassa järjestyksessä 17/10/14. Jos omaan tilanteeseen peilaan, niin mulle riittää 9 halvinta tuntia helposti talon lämmitykseen korotetulla käyrällä kun takoilla lämmitän loppulämmöt, mutta joku 17 tuntia eilisen osalta olisi aika hyvin ehtinyt myös varaamaan laattaa tuleville pakkaspäiville ja tuollainen "aktiivinen" säätö tuntuu yhtäkkiä ihan hyvältäkin vaihtoehdolta. Jos se vaan käytännössä kulutusvaikutusta pakkasella pitää.
@Mikki laitetaan idea myös jakoon "kilpailijalle" tasapuolisuuden nimissä
Kyllä se siellä on. Saa lisäksi myös erilaisia keskihajontakertoimia siihen mukaan jos haluaa entistä kireämpää kulutusvaikutusta.Mielestäni en löytänyt Pörssäristä tällaista asetusta:
Salli kaikki tunnit jotka alle vuorokauden pörssihinnan keskiarvon.
En ole matemaattista tutkielmaa suorittanut asiasta, mutta nopeasti mietittynä jos suurin kulutus keskittyy aina vuorokauden noihin yllämainittuohin tunteihin, on vuorokauden kulutusvaikutus aina negatiivinen ja todennäköisesti se on sitä myös kuukausitasolla?
Mitä nopeasti vilkaisin eilisen, tämän päivän ja huomisen osalta niin noita tunteja on samassa järjestyksessä 17/10/14. Jos omaan tilanteeseen peilaan, niin mulle riittää 9 halvinta tuntia helposti talon lämmitykseen korotetulla käyrällä kun takoilla lämmitän loppulämmöt, mutta joku 17 tuntia eilisen osalta olisi aika hyvin ehtinyt myös varaamaan laattaa tuleville pakkaspäiville ja tuollainen "aktiivinen" säätö tuntuu yhtäkkiä ihan hyvältäkin vaihtoehdolta. Jos se vaan käytännössä kulutusvaikutusta pakkasella pitää.
@Mikki laitetaan idea myös jakoon "kilpailijalle" tasapuolisuuden nimissä
Aika- ja hintaohjaus —> Hintaohjaus —> Laskettu hintaraja —> Vuorokauden keskiarvo.
Tuohan toimii silläkin lailla, että jos haluat aina minimissään vaikkapa 3h, mutta sitten enemmän jos vaikka keskiarvo - 1SD -tunteja on enemmän, niin tuo aikaehto kytkee aina ne 3h päälle ja hintaehdon saat moodiin joka antaa noiden myös pysyä päällä vaikkeivat täytä hintaehtoa. Eli siksi on se valinta miten hintaehto toimii (kytke alapuolella, estä yläpuolella, molemmat edellämainitut).
On pohdittu sitäkin pitäisikö tarjota kuluvan kuukauden keskihintaa tuossa myös. Se toki on muuttuva suure eikä välttämättä johda hyvään lopputulokseen, mutta tätä mallinnetaan projektin tutkijavahvistuksen toimesta vielä keväämmällä kun saadaan lämmityskauden hinnat ja kulutukset taulukkoon.
Viimeksi muokattu:
Noniin, kunhan testasin että tunnetteko omat tuotteenne..
Laitetaan testiin
Edit.
Varmistetaan vielä, eli tässä sallitaan aina 9 halvinta tuntia, mutta sallitaan lisäksi kaikki pörssin keskihinnan alittavat tunnit jos niitä on?
Edit2.
Sellainen huomio, että ainakaan mulla Android-kännykällä ei nuo Pörssärin "?"-täpän alla olevat info-ikkunat aukea ollenkaan.
Laitetaan testiin
Edit.
Varmistetaan vielä, eli tässä sallitaan aina 9 halvinta tuntia, mutta sallitaan lisäksi kaikki pörssin keskihinnan alittavat tunnit jos niitä on?
Edit2.
Sellainen huomio, että ainakaan mulla Android-kännykällä ei nuo Pörssärin "?"-täpän alla olevat info-ikkunat aukea ollenkaan.
Viimeksi muokattu:
Menee juuri noin kun sanot.Noniin, kunhan testasin että tunnetteko omat tuotteenne..
Laitetaan testiin
Edit.
Varmistetaan vielä, eli tässä sallitaan aina 9 halvinta tuntia, mutta sallitaan lisäksi kaikki pörssin keskihinnan alittavat tunnit jos niitä on?
Näytä liitetiedosto 93401
Edit2.
Sellainen huomio, että ainakaan mulla Android-kännykällä ei nuo Pörssärin "?"-täpän alla olevat info-ikkunat aukea ollenkaan.
Olen itsekin pistänyt merkille, että kännykällä tuo toimii huonosti. Uusi ohjaushallinta tuo mukanaan myös paremman templaatin tuohon sivustolle mobiilikäyttöön, niin toivon sen korjaavan tuonkin ongelman. Kiitos infosta, itsellä vain i-puhelin niin sillä se näkyy sen aikaa kun painaa pohjassa.
Pörssäri 2.0 etenee. Ajatuksena on lisätä tuollainen muutama esivalinta ehkä yleisimmin ohjatuille kuormille. Vaihtoehtona on sitten käyttää custom-ohjausta mikä tuo esiin sen vanhantyyppisen manuaalisen salli halvimmat/estä kalleimmat + pakko-ohjaa -tyyppisen asetuslomakkeen.
Muutoksena vanhaan logiikkaan tulee se, että itse ohjauslaite asetetaan tuolla kuorman asetuksissa. Eli tavallaan jatkossa asetukset tehdään ohjattavalle kuormalle, ja ohjauslaitetta sille pystyy helposti vaihtamaan.
Mutta kyllä tässä projektissa jokunen viikko vielä menee. Lopputuloksena pitäisi olla alkuun jo jonkinmoinen kuormanhallinta. Kunhan saan HomeWizardin itselle, niin aletaan visioimaan miten saataisiin helpoiten serverin päähän tietoa ohjattavien kuormien tarkasta suuruudesta entistä parempaa suunnittelua varten. Samalla vaivalla tulee myös monikielisyyden tuki, tarkoituksena on tuoda tuki myös toiselle kotimaiselle.
Muutoksena vanhaan logiikkaan tulee se, että itse ohjauslaite asetetaan tuolla kuorman asetuksissa. Eli tavallaan jatkossa asetukset tehdään ohjattavalle kuormalle, ja ohjauslaitetta sille pystyy helposti vaihtamaan.
Mutta kyllä tässä projektissa jokunen viikko vielä menee. Lopputuloksena pitäisi olla alkuun jo jonkinmoinen kuormanhallinta. Kunhan saan HomeWizardin itselle, niin aletaan visioimaan miten saataisiin helpoiten serverin päähän tietoa ohjattavien kuormien tarkasta suuruudesta entistä parempaa suunnittelua varten. Samalla vaivalla tulee myös monikielisyyden tuki, tarkoituksena on tuoda tuki myös toiselle kotimaiselle.
Ei taas aivot käänny, miten tämän saisi onnistumaan Pörssärillä, vai saako:
Käyttöveden teon ohjaus, normaalisti ollut 3 halvinta tuntia sallittuna ja toiminut moitteetta. Nyt on suihkussakäynnissä tapahtunut äkkinäinen muutos (pahempaan) ja kuumaa vettä kuluu normaalia enemmän (eikä sitä voi estää).
Tarve olisi siis lämmittää yksi lisätunti noin klo 12-17 välissä, että lämmintä vettä riittää seuraavaan pidempään lämmityskertaan joka yleensä osuu aina klo 00-05 välille. Olen nyt arponut tuolle pakko-ohjauksen alkamaan klo 16, kun se suunnilleen on halvimmasta päästä noihin aikoihin, mutta ei ole se halvin kuitenkaan läheskään aina.
Käyttöveden lämmitys on meillä isoin kulutuspiikki, joten haluan että tuo osuu aina halvimmille tunneille, tai tässä uudessa tapauksessa niin halvoille kuin mahdollista.
Tässä vielä nykyinen asetus tuolle käyttövedelle, saanko tuosta ohjattua tuon yhden pakko-ohjaustunnin jotenkin niin että se on klo 12-17 välissä aina se halvin tunti?
Käyttöveden teon ohjaus, normaalisti ollut 3 halvinta tuntia sallittuna ja toiminut moitteetta. Nyt on suihkussakäynnissä tapahtunut äkkinäinen muutos (pahempaan) ja kuumaa vettä kuluu normaalia enemmän (eikä sitä voi estää).
Tarve olisi siis lämmittää yksi lisätunti noin klo 12-17 välissä, että lämmintä vettä riittää seuraavaan pidempään lämmityskertaan joka yleensä osuu aina klo 00-05 välille. Olen nyt arponut tuolle pakko-ohjauksen alkamaan klo 16, kun se suunnilleen on halvimmasta päästä noihin aikoihin, mutta ei ole se halvin kuitenkaan läheskään aina.
Käyttöveden lämmitys on meillä isoin kulutuspiikki, joten haluan että tuo osuu aina halvimmille tunneille, tai tässä uudessa tapauksessa niin halvoille kuin mahdollista.
Tässä vielä nykyinen asetus tuolle käyttövedelle, saanko tuosta ohjattua tuon yhden pakko-ohjaustunnin jotenkin niin että se on klo 12-17 välissä aina se halvin tunti?
Viimeksi muokattu:
Tässä kaivattaisiin aika paljon lisälogiikkaa. Eli pitäisi jostain kaivaa toteutuneet kulutukset (datahub?), arvioida miten kuormat olisi jakautuneet ilman ohjausta niille hinnat laskien, ja sitten verrata todellista tuohon laskettuun.
Käsittääkseni liukuri tekee tuon toteutuneen jo aika hyvin, ja ehkä sinne voisi mieluummin kysyä tuollaista mahdollisuutta ”referenssivertailuun”?
Ei valitettavasti saa. Ei olla lisätty tuohon vanhaan systeemiin sitä, että voisi pakottaa osan halvimmista tunneista tiettyyn ajanjaksoon. Tuossa uudessa logiikassa yritetään tätä paremmin mahdollistaa, mutta hetki pitää mennä vielä tuolla osin epäoptimaalisella pakko-ohjauksella.
Niinpäin sen toki voi tehdä nykyisellään, että laittaa ehdoksi 1h ja sen voimassaoloksi 12-17, ja sitten pakko-ohjaa vaikka 03 ja 04 päälle. En tiedä menisikö se enemmän oikein niin? Mutta ei täysin optimaalinen ole sekään.
Mainitaan sen verran, että Spot-hinnalla saat.... käytännössä voinet lisätä sen Pörssärin rinnalle toiseksi skriptiksi, kun Pörssärin skriptikään ei taida enää sotkea "käsinohjausta". Ja "PriorityHours" parametrilla valitset iltapäivätunnit ja niistä 1 halvin tunti.
Tuota mietin myös, mutta joskus käy niinkin että nuo halvimmat tunnit vähän "hyppii" sinne tänne eikä ne välttämättä ole edes peräkkäisiä vaikka osuvatkin 00-05 välille. Tuolla on varsinkin kesällä suuri vaikutus kulutusvaikutukseen, että osuuko ne käyttöveden teot aina halvimmille 3 tunnille vai esim 1. 4. ja 5. halvimmalle (viime kesänä oli sallittu 6 halvinta tuntia ja kulutusvaikutus tuon takia plussalla yhden kuun lopussa, ennen kuin hoksasin rajoittaa tuon 3 halvimpaan tuntiin).
Viimeksi muokattu:
Pitääpä tuota kokeilla, hauska "hybridi"ohjaus joka ei tullutkaan mieleen
Uskaltaakohan tässä sotkea Pörssäri-ketjua sen verran, että toimiiko Pörssärin vahti-scripti kaikille scripteille vai pitääkö Spot-hinnan vahti lisätä myös joka vahtii tuota PriorityHoursia?