Pörssäri & Home Assistant

[tk-]

Tuossa toisessa ketjussa on tullut jo jonkin verran mainittua siitä, että ollaan tuomassa myös Home Assistant -integraatio mukaan. Nyt tämä alkaa olla jo beta-kunnossa, eli avaan aiheesta uuden ketjun.

Githubissa osoitteessa https://github.com/Porssari/HomeAssistant-client on yaml-tiedostot sekä jonkinmoinen alustava ohje tuon käyttöönottoon.

Clientin käyttöönottoa varten tarvitsee tosiaan tuonne sivustolle käydä rekisteröitymässä. Kun omiin laitteisiin lisää laitteen "Home Assistant", sivustolla generoidaan tuo laitetunnus mikä sitten lisätään tuonne Home Assistantin sensoriin. Oletuksena laitteelle luodaan 8 ohjauskanavaa joita voi käyttää sitten erilaisilla ehdoilla kanavaohjauksiin. Lisäksi käyttäjäkohtaiset hintatiedot toimitetaan kuluvalta vuorokaudelta ja seuraavalta vuorokaudelta heti kun ne on saatavissa.

Muutettiin nyt vielä nuo sivuston käyttöehdot semmoiseksi, että jos joskus "palvelinkustannusten" vuoksi haluttaisiin alkaa tästä rahaa keräämään, niin olemassaolevat käyttäjät saavat jatkaa palvelun maksutonta käyttöä koko laajuudessaan. Tämä on ja tulee pysymään kuitenkin harrastusprojektina jota kehitetään ensisijaisesti omiin tarpeisiin. Meillä on kuitenkin mahdollisuus estää uusien käyttäjien rekisteröityminen tilanteessa missä palvelinkapasiteetti alkaisi kolkutella rajoja, eli siinä mielessä mitään ennakoimatonta liikenteen kasvua ei oikein koskaan ole edes odotettavissa.

Ottakaahan tätä testiin, kehitysideoita otetaan vastaan ja mikäli jotain sensoreita tai muita templaatteja joku innostuu väsäilemään, niin lisään mielellään tuonne Githubiin esimerkkejä! Todennäköisesti tuota core-tiedostoa tullaan lähiaikoina vähän vielä päivittämään, mutta nykyisellään se on jo melko toimintavarma.

 

[tk-]

Semmoinen ominaisuus tässä saattaa vielä nyt olla, että hintatietojen päivittäminen sivustolle näkyy Home Assistantissa vasta vajaan tunnin viiveellä kun json seuraavan kerran automaattisesti haetaan. Ohjaustietojen päivitys toki tapahtuu heti seuraavalla kyselykerralla.

Tarkistan tuon toiminnan illalla, ja tarvittaessa lisätään myös tuo hintatietojen päivitys triggeröimään heti seuraavalla kyselyllä (eli 1,5-2,5min sisään) uusi ohjaustiedon haku. Toki ongelmana sinällään marginaalinen kun ei noita yhtenään yleensä muuteta, mutta saisi toki toimia optimaalisesti!

 

[tk-]

Mukavasti on herättänyt kiinnostusta tämä Home Assistant -ohjausmahdollisuus!

Tuohon automaatioiden luomiseen vielä yksinkertainen kuvaohje. Eli tässä käytetään ohjauskanavaa 1 Shelly Plugin ohjaamiseen päälle ja pois.

Spoiler: Shelly Plug päälle

Spoiler: Shelly Plug pois

 

[hemaris]

Mukavasti on herättänyt kiinnostusta tämä Home Assistant -ohjausmahdollisuus!

Tuohon automaatioiden luomiseen vielä yksinkertainen kuvaohje. Eli tässä käytetään ohjauskanavaa 1 Shelly Plugin ohjaamiseen päälle ja pois.

Näiden esimerkkien mukaan Pörssärin sensorit olisivat binäärisensoreita tai vastaavia joita voisi käyttää triggerinä. Githubissa puhutaan että "laitteet" lisättäisiin Pörssärin verkkosivujen kautta ja laitteina on erityisesti mainittu Shellyt. Itselläni ei ole shellyjä, ohjailen omilla automaatioilla Zwave-kytkimiä ja vastaavia. Periaatteessa hyvin toimiva triggeritieto voisi tässäkin olla hyödyllinen - siis jos se peittoaa "älyssä" omat räpellykset ja jos luottaa että nettiyhteys ei kyykkää.

Toimiiko tuo pörssäri myös ilman mitään siihen rekisteröityjä laitetietoja.

 

[tk-]

Näiden esimerkkien mukaan Pörssärin sensorit olisivat binäärisensoreita tai vastaavia joita voisi käyttää triggerinä. Githubissa puhutaan että "laitteet" lisättäisiin Pörssärin verkkosivujen kautta ja laitteina on erityisesti mainittu Shellyt. Itselläni ei ole shellyjä, ohjailen omilla automaatioilla Zwave-kytkimiä ja vastaavia. Periaatteessa hyvin toimiva triggeritieto voisi tässäkin olla hyödyllinen - siis jos se peittoaa "älyssä" omat räpellykset ja jos luottaa että nettiyhteys ei kyykkää.

Toimiiko tuo pörssäri myös ilman mitään siihen rekisteröityjä laitetietoja.

Tuo ohjeistus on vielä vähän ehkä vaiheessa ja siksi epäselvä. Eli tosiaan alunperin tuo Pörssäri suunniteltiin niin, että Shelly/Pico W/muu mikrokontrolleri lisätään tuonne palvelimelle josta se kyselee ohjaustiedon. Tässä kuva tuolta omasta laitehallinnasta missä on lisättynä tällä hetkellä ohjauslaitteena suoraan toimiva Pico W ja tuo Home Assistant, minkä kautta ohjaukset on jatkossa tarkoitus välittää.

Tämä Home Assistant täytyy tuonne Pörssäriin lisätä tuollaiseksi "laitteeksi", eli sinulla riittää tuo pelkkä Home Assistantin lisääminen sivustolle.

Spoiler: Laitehallinta

Eli sen jälkeen sivustolla on ne kahdeksan ohjauskanavaa käytettävissä asetusten tekemiseen. Noiden kahdeksan kanavan tila sitten tuntikohtaisesti vaihdetaan joko 1 = päällä, 0 = pois tai -1 = ei käytössä. Seuraavassa esimerkki tuosta omasta laitteesta, missä tuo Shelly Plugia ohjaava kanava on asetettu menemään päälle 7 edullisinta tuntia sekä klo 20-21 hinnasta huolimatta.

Spoiler: Asetukset

Ja se tosiaan johtaa siihen, että tuo kanava saa Home Assistantissa joko arvon 0 tai 1 tuon ohjauslogiikan mukaan.

Spoiler: Home Assistant

Ohjauslogiikka on vielä aika yksinkertainen, mutta yritetään sitä pikkuhiljaa kehittää kokoajan paremmaksi. Ja toki tuon hintatiedon avulla on mahdollisuus rakentaa sitten omiakin ohjauksia vielä suoraan Home Assistantiin noiden palvelimelta tulevien rinnalle.

Periaatteessa tuo toimii ilman nettiyhteyttä aina vähintään vuorokauden loppuun, ja iltapäivästä alkaen 23h eteenpäin kunhan hintatiedot seuraavalle vuorokaudelle on haettu, koska tuo ohjausdata tallennetaan paikallisesti sensoriin mikä päivitetään vain jos palvelinkysely onnistuu. Hintatiedot haetaan entso-e:n transparency platformista ja varalla on eleringin api.

Jos ohjausdatan päivitys ei onnistu, niin tuo "JSON-ohjaustieto käytettävissä" muuttuu tilaan Off siinä vaiheessa kun edellisestä päivityksestä on kulunut aikaa se tuntimäärä minkä json sisältää ohjaustietoa. Lisäksi noiden kanavasensoreiden pitäisi tällaisessa tilanteessa muuttua aina tilaan -1, mutta se on vielä käytännön elämässä testaamatta. Eli tarkoitus olisi estää ohjaus kokonaan jos oikeaa hintatietoa ei ole saatavilla.

Paikallisestihan tuolla yhdellä kanavalla voi sitten ohjata niin monia laitteita kun haluaa, eli käytännössä Pörssäristä saa kahdeksan erilaista triggeritietoa käyttöön erilaisilla parametreilla.

Avasiko tämä yhtään tuota toimintalogiikkaa? Tee ihmeessä tili tuonne sivustolle ja kokeile miten tämä toimisi. Ei maksa mitään, ja siitä tilistä pääsee tarvittaessa eroon. Tarkoituksena on lisätä tulevaisuudessa tuonne semmoinen automaattinen "siivoustoiminto", eli kaikki sellaiset käyttäjät joilla ei ole kuukauteen ollut yhtäkään laitetta tietokannassa tai ei ole tallennettuna henkilökohtaisia hintatietoja, poistetaan sivustolta.

Tuo lämmityksen ohjauslogiikka on tosiaan tarkoituksena rakentaa tulevaan talveen mennessä. Ajatuksena on tehdä se neliportaiseksi, ja tuo ohjaustieto olisi sitten saatavissa kahdella eri tavalla. Eli joko 0/1 kanava-asetuksissa valitun lämmitystilan mukaan, eli esimerkiksi toimisi itsellä tuon Niben kanssa kun sitä ohjaa noilla potentiaalivapailla releillä. Tai vaihtoehtoisesti yksittäinen kanava antaa ulos senhetkisen lämmityksen tilatiedon muodossa 10-20-30-40 (estä lämmitys - normaali lämmitys - tehostus 1 - tehostus 2), eli sitä voitaisiin käyttää vaikkapa Home Assistantissa automaatiotriggerinä ohjaamaan eri lämpöasetukset termostaatteihin, ILP:n lämpötilan muuttamiseen ir-mikrokontrollerin avulla jne. Nuo eri lämmitysmoodit sitten laskettaisiin joka tunnille/vartille ulkolämpöön ja sähkön hintaan perustuen. Mutta tätä tosiaan vasta luonnostellaan, katsotaan millainen saadaan aikaan.

Pitäisi repiä nyt jostain pieni hetki aikaa parannella tuota dokumentointia, kun ei tuolla sivustollakaan ole vielä minkäänlaista mainintaa tästä koko Home Assistantista...

 

[tk-]

Noniin, nyt on taas yritetty päivittää dokumentointia parempaan suuntaan (https://github.com/Porssari/HomeAssistant-client), ja lisäksi tuonne Pörssäri-sivustolle tein kokonaan uuden sivun "Harrastajille" ja lisäksi sieltä löytyy nyt myös linkki tuonne Githubiin.

 

[Koelli]

Toivon, että et ota tätä nyt väärin, koska arvostan hyvinkin paljon erilaisten järjestelmien kehitystä. Ei vähiten näitä harrasteprojekteja.

En kuitenkaan ihan saa kiinni, että minkä asian pörssäri ratkoo, jos käytössä on HA ja Shellyt.

Osaatko valaista?

 

[tk-]

Toivon, että et ota tätä nyt väärin, koska arvostan hyvinkin paljon erilaisten järjestelmien kehitystä. Ei vähiten näitä harrasteprojekteja.

En kuitenkaan ihan saa kiinni, että minkä asian pörssäri ratkoo, jos käytössä on HA ja Shellyt.

Osaatko valaista?

Itse kuulun siihen ihmisryhmään joka enemmänkin innostuu jos joku kyseenalaistaa omasta mielestä hyviä ideoita! Eli en todellakaan ota väärin, ja tykkään vastailla tällaisiin kysymyksiin, koska ne avaa monesti parhaiten omaa ajatusmaailmaa.

Periaatteessa Pörssäri + Shellyt ei kaipaisi tätä Home Assistantia mihinkään. Ja HA + Shellyt ei kaipaa Pörssäriä. Tämä on fakta jota vastaan en halua edes yrittää väittää muuta.

Jos olet jo tehnyt muulla tavalla ohjauksen Shellyille, niin en keksi miksi sinun kannattaisi muuttaa ne tähän. Mutta jos olisit nyt rakentamassa järjestelmää jossa on sekä Home Assistant että Shellyt, niin olisihan ne Shellyt aika helppo automatisoida vaan vaihtamaan tilansa tuon kanavasensorin tilan mukaan.

Home Assistant on yksi tapa monesta välittää tuo ohjauslogiikka. Nykyiselläänhän se on vielä hyvinkin yksinkertainen, mutta talveen mennessä meillä on käytössä sekä aurinkosähköennuste että ulkolämmön ja sähkön hinnan mukaan säätyvä lämmityksen ohjaus tuon yksinkertaisen ohjauslogiikan kaveriksi. Ja tätä ohjaustietoa voi sitten Home Assistantin kautta välittää kaikkiin semmoisiin laitteisiin jotka siihen saa yhdistettyä ja sitä tietoa tarvitsee. Ja lisäksi Home Assistant pitää logia kaikesta mitä on tapahtunut.

Kaiken tuon logiikan voi halutessaan tehdä myös Home Assistantiin itse, tai etsiä siihen omaan tarpeeseen sopivat palikat. Tämä Pörssäri on tarkoitus olla siihen yksi vaihtoehto muiden joukossa. Ja painotan edelleen sitä, että tehdään tätä ensisijaisesti omiin tarpeisiin. Mutta esittelen sitä mielelläni täällä muillekin, koska omasta mielestä tämä on sekä helppo että luotettava tapa välittää hintaohjaus erilaisiin paikkoihin niin Shellyjen, mikrokontrollereiden kuin Home Assistantiin liitettyjen laitteiden välityksellä.

Ja lisäksi tämä pidetään aktiivisesti päivitettynä ja ajan tasalla.

 

[Koelli]

Itse kuulun siihen ihmisryhmään joka enemmänkin innostuu jos joku kyseenalaistaa omasta mielestä hyviä ideoita! Eli en todellakaan ota väärin, ja tykkään vastailla tällaisiin kysymyksiin, koska ne avaa monesti parhaiten omaa ajatusmaailmaa.

Periaatteessa Pörssäri + Shellyt ei kaipaisi tätä Home Assistantia mihinkään. Ja HA + Shellyt ei kaipaa Pörssäriä. Tämä on fakta jota vastaan en halua edes yrittää väittää muuta.

Jos olet jo tehnyt muulla tavalla ohjauksen Shellyille, niin en keksi miksi sinun kannattaisi muuttaa ne tähän. Mutta jos olisit nyt rakentamassa järjestelmää jossa on sekä Home Assistant että Shellyt, niin olisihan ne Shellyt aika helppo automatisoida vaan vaihtamaan tilansa tuon kanavasensorin tilan mukaan.

Home Assistant on yksi tapa monesta välittää tuo ohjauslogiikka. Nykyiselläänhän se on vielä hyvinkin yksinkertainen, mutta talveen mennessä meillä on käytössä sekä aurinkosähköennuste että ulkolämmön ja sähkön hinnan mukaan säätyvä lämmityksen ohjaus tuon yksinkertaisen ohjauslogiikan kaveriksi. Ja tätä ohjaustietoa voi sitten Home Assistantin kautta välittää kaikkiin semmoisiin laitteisiin jotka siihen saa yhdistettyä ja sitä tietoa tarvitsee. Ja lisäksi Home Assistant pitää logia kaikesta mitä on tapahtunut.

Kaiken tuon logiikan voi halutessaan tehdä myös Home Assistantiin itse, tai etsiä siihen omaan tarpeeseen sopivat palikat. Tämä Pörssäri on tarkoitus olla siihen yksi vaihtoehto muiden joukossa. Ja painotan edelleen sitä, että tehdään tätä ensisijaisesti omiin tarpeisiin. Mutta esittelen sitä mielelläni täällä muillekin, koska omasta mielestä tämä on sekä helppo että luotettava tapa välittää hintaohjaus erilaisiin paikkoihin niin Shellyjen, mikrokontrollereiden kuin Home Assistantiin liitettyjen laitteiden välityksellä.

Ja lisäksi tämä pidetään aktiivisesti päivitettynä ja ajan tasalla.

OK! Kiitos tästä. Näkisin, että saatte tehtyä tuon parhaiten, ehkä, soveltumaan niille, jotka haluaa a) säästää aikaa ja vaivaa b) haluaa enemmän "avaimet käteen" -tyyppisen ratkaisun, kuten Fissio (jos tuttu).


Meniköhän päin prinkkalaa?

 

[tk-]

OK! Kiitos tästä. Näkisin, että saatte tehtyä tuon parhaiten, ehkä, soveltumaan niille, jotka haluaa a) säästää aikaa ja vaivaa b) haluaa enemmän "avaimet käteen" -tyyppisen ratkaisun, kuten Fissio (jos tuttu).


Meniköhän päin prinkkalaa?

Ei kun juuri oikeaan suuntaan. Tässä on jonkinlainen kunnianhimoinen tarkoitus yksinkertaistaa monimutkaiset järjestelmät tottelemaan tuollaista melko helppoa tapaa sekä muuttaa asetuksia että ottaa ne käyttöön.

Vähän fission tapaista tosiaan, mutta onhan fissio valovuosia meitä edellä kaikessa toiminnallisuudessaan. Toki siinä on taas sitten omat kommervenkkinsä käyttöönotossa. Itse pohdin pitkään fissioa käyttöön, mutta en uskaltanut kun pelkäsin, ettei se pysy ilmaisena…

Ja en minä laita pahakseni vaikka Pörssärillä hakisi pelkät hintatiedot Home Assistantiin. Meillä on valmisteilla hintasivusto missä omat sähkönhinnat saadaan näkyviin missä tahansa selaimessa ilman mitään kirjautumista laitteella kuin laitteella, kun osoitteeseen lisätään Pörssärin käyttäjätunnus. Ehkä siinä vaiheessa voisi muuttaa tuon ha-clientin vielä niin, että voi myös jättää nuo ohjaussensorit kokonaan pois jos ei niitä tarvitse.

 

[tk-]

Nyt on Pörssärin Home Assistantiin myös saatavilla tuo Apexchart-card -hintagraafi. Lisäksi on korjattu vielä muutamia virheitä liittyen json-voimassaolon tarkistukseen, on koskenut ohjauskanavien ohjausta tilanteessa missä edellisestä onnistuneesta palvelinkyselystä alkaa olla lähemmäs se aika kun json sisältää ohjaustietoa.

Päivitetyt tiedostot tuolla Githubissa (https://github.com/Porssari/HomeAssistant-client) Teen vielä jokusen päivän erilaisia ohjaus- ja verkkokatkotestejä, niin sen jälkeen teen tuonne virallisen releasen.

Tuo Control factor -toiminnallisuus on myös mahdollista saada käyttöön, mutta en ole sitäkään toistaiseksi lisännyt tuonne Githubiin kun kaikkia eri moodeja en ole vielä ehtinyt vuorokautta testata. Tarvittaessa yksityisviestillä voin laittaa myös sen sensorikoodin.

Hintarajapintana meillä on Entso-E + Elering, joten hintatiedot on tulleet kohtalaisen ajoissa. Eleringiä käytetään vasta klo 17 alkaen jos siihen mennessä Entsosta ei ole hintoja saatu.

Spoiler: Uusi käyttöliittymä

 

[s282]

Nyt on Pörssärin Home Assistantiin myös saatavilla tuo Apexchart-card -hintagraafi. Lisäksi on korjattu vielä muutamia virheitä liittyen json-voimassaolon tarkistukseen, on koskenut ohjauskanavien ohjausta tilanteessa missä edellisestä onnistuneesta palvelinkyselystä alkaa olla lähemmäs se aika kun json sisältää ohjaustietoa.

Päivitetyt tiedostot tuolla Githubissa (https://github.com/Porssari/HomeAssistant-client) Teen vielä jokusen päivän erilaisia ohjaus- ja verkkokatkotestejä, niin sen jälkeen teen tuonne virallisen releasen.

Tuo Control factor -toiminnallisuus on myös mahdollista saada käyttöön, mutta en ole sitäkään toistaiseksi lisännyt tuonne Githubiin kun kaikkia eri moodeja en ole vielä ehtinyt vuorokautta testata. Tarvittaessa yksityisviestillä voin laittaa myös sen sensorikoodin.

Hintarajapintana meillä on Entso-E + Elering, joten hintatiedot on tulleet kohtalaisen ajoissa. Eleringiä käytetään vasta klo 17 alkaen jos siihen mennessä Entsosta ei ole hintoja saatu.

Spoiler: Uusi käyttöliittymä

katso liitettä 86971katso liitettä 86972

Minulla ei ollut siirtohintoja asetettu, niin ei osannut tuo graafi näyttää mitään palkkeja, kun oli niin alhaiset hinnat. Laitoin siirtohinnan niin nyt näkyy

 

[tk-]

Minulla ei ollut siirtohintoja asetettu, niin ei osannut tuo graafi näyttää mitään palkkeja, kun oli niin alhaiset hinnat. Laitoin siirtohinnan niin nyt näkyy

Siinä on oletuksena yamlissa y-akselin alaraja ~0 ja yläraja ~20. Jos ei käytä siirtohintoja, niin tuota ylärajaa pitänee ehkä laskea arvoon ~10 varsinkin näin halvan sähkön aikaan. Arvot löytyy sieltä custom-apexchart-cardin asetuksista.

Dokumentaation perusteella jäin käsitykseen, että jos edessä on tuo aaltoviiva niin tuon pitäisi toimia siten, että jos skaala ei mahdu tuohon esiasetetulle alueelle niin sitä venytetään tarpeen mukaan.

Täytyy jatkossa tuota graafia vielä koettaa muotoilla paremmaksi, tuo oli semmoinen muutaman tunnin opiskelun lopputulos. Jos täältä löytyy Apexchart-osaajia, niin otan mielelään muutoksia tuohon vastaan!

 

[timop]

apeixssa jos laittaa y-akselille min: auto niin se näyttää miinuksetkin, heti ei jostain syystä vaan hetken päästä.

 

[s282]

Siinä on oletuksena yamlissa y-akselin alaraja ~0 ja yläraja ~20. Jos ei käytä siirtohintoja, niin tuota ylärajaa pitänee ehkä laskea arvoon ~10 varsinkin näin halvan sähkön aikaan. Arvot löytyy sieltä custom-apexchart-cardin asetuksista.

Dokumentaation perusteella jäin käsitykseen, että jos edessä on tuo aaltoviiva niin tuon pitäisi toimia siten, että jos skaala ei mahdu tuohon esiasetetulle alueelle niin sitä venytetään tarpeen mukaan.

Täytyy jatkossa tuota graafia vielä koettaa muotoilla paremmaksi, tuo oli semmoinen muutaman tunnin opiskelun lopputulos. Jos täältä löytyy Apexchart-osaajia, niin otan mielelään muutoksia tuohon vastaan!

Omat taitoni ovat lähinnä copy ja paste, mutta tuossa spotprice chartissa se on toteutettu jotenki niin että osaa skaalata hinnan mukaan, löytyisikö siitä vinkkejä.

 

[tk-]

Omat taitoni ovat lähinnä copy ja paste, mutta tuossa spotprice chartissa se on toteutettu jotenki niin että osaa skaalata hinnan mukaan, löytyisikö siitä vinkkejä.

Kyllä sen nimenomaan pitäisi tuon aaltosulun kanssa niitä skaalata, mutta eipä tuo nyt jostain syystä näytä toimivan. Spot-hinnassakin on pelkästään määritetty tuo minimi 0.

No, josko tuo 0-20 olisi nyt jonkinmoinen hyvä kompromissi. Pitää tuota koettaa tässä saada toimimaan paremmin. Jostain syystä pelkkä auto muuttaa tuon skaalan välille 0-5 eikä sekään ole oikein hyvä vaihtoehto.

EDIT: löytyipäs tähän hotfix. Eli data generator muuttui seuraavanlaiseksi:

let res = [];
for (const [key, value] of Object.entries(entity.attributes.Prices)) {
  let d = new Date(key).getTime();
  let p = parseFloat(value.Price);
  if (d > 0)
    res.push([d, p]);
}
return res.sort((a, b) => { return a[0] - b[0] });

Vaihdan tuohon nyt oletukseksi 0-10, pitäisi skaalautua sitten ylöspäin jos arvot on sitä suurempia. Itsellä ainakin muuttui skaalaan 0-15, koska huomenna on 12snt tuntumassa olevia hintoja. Toki oletushan voisi olla myös 0-5 jos tuota useampikin käyttää ilman omia hinta-asetuksia. Sitä saa halutessaan sieltä graafin asetuksista muutettua haluamakseen, eli skaalaus toimii kunhan on se aaltosulku siinä edessä.

Githubissa löytyy tuo korjattu versio.

 

[tk-]

apeixssa jos laittaa y-akselille min: auto niin se näyttää miinuksetkin, heti ei jostain syystä vaan hetken päästä.

Tässä oli tosiaan ongelmana, että tuo auto skaalasi miten sattuu. Vika taisi olla se, että nuo jsonista luetut hinnat oli tekstimuodossa, eli korjaantui tuon oman ajatuksen mukaan toimimaan kun muutti arvot funktiolla ensin desimaaleiksi. Muistaakseni tuo min: auto saattoi johtaa siihen, että y-akseli ei välttämättä lähtenyt nollasta. Mutta tuon ~0 pitäisi nyt mahdollistaa myös miinukselle meno.

 

[tk-]

Miten tällainen templaatti olisi järkevintä parviälyn mielestä tuoda tuohon pakettiin mukaan? Eli kyseessä on templaatti, joka laskee valitun mittaisen aikajakson kokonaishinnan kuluvan vuorokauden ajalta, ja antaa vastaukseksi niistä lasketuista aikajaksoista edullisimman aloitustunnin, tarvittaessa toki lopetustunninkin, sekä kokonaishinnan.

Eli tekisikö tuosta sensorin missä on attribuutteina laskettuna valmiiksi esimerkiksi kaikki 2-10 tunnin mittaisen aikajakson arvot? Vai toimiiko tuo parhaiten niin, että saa itse valita tuon aikajakson pituuden? Toki sitten täytyy kopioida useampia sensoreita jos haluaa useamman eri aikajakson eri ohjauksiin.

Onko ominaisuus, että saa päättää millä tuntivälillä tuo aikajakso on, kuinka tärkeä?

Pitäisin tuon kuitenkin itse aina yhden vuorokauden sisällä, koska vuorokaudessa on enemmän semmoisia tunteja kun seuraavan vuorokauden tunnit ei ole saatavilla, ja se helposti sitten sekoittaa ohjauslogiikat jos tuo arvo vaihtuu useammin kuin kerran vuorokaudessa.

Koodia liitteeksi.

Spoiler: YAML

{% set timeStampList = state_attr("sensor.porssari_json_data", "Prices") | list %}
{% set ns = namespace(ts=[], price=0, cheapestprice=999999, begin=0) %}
{% set period = 3 %}
{% for item in timeStampList %}
  {% if now().day == as_datetime(item).day %}
    {% set ns.ts = ns.ts + [item] %}
  {% endif %}
{% endfor %}
{% for item in ns.ts %}
  {% set ns.price=0 %}
  {% set begin = as_datetime(item).hour %}
  {% set endTs = as_datetime(item) + timedelta( hours = period ) %}
  {% if endTs.hour > 0 %}
    {% set end = endTs.hour %}
  {% else %}
    {% set end = 24 %}
  {% endif %}
  {% if begin <= (24 - period) %}
    {% for item in range(begin, end) %}
      {% set t = ns.ts[item] | string %}
      {% set ns.price = ns.price + state_attr("sensor.porssari_json_data", "Prices")[t]['Price'] | float %}
    {% endfor %}
    {% if ns.price < ns.cheapestprice %}
      {% set ns.begin = begin %}
      {% set ns.cheapestprice = ns.price %}
    {% endif %}
  {% endif %}
{% endfor %}
{% set res = {"Begin_hour": ns.begin, "Total_price": ns.cheapestprice | round(2)} %}
{{ res }}

EDIT: Jotain tämän tyyppistä tuosta voisi tulla. 2 tunnin attribuutti on valittu osumaan välille 3-12, muut koko vuorokaudelle. Ja noita voisi sitten tehdä tuohon samaan sensoriin haluamansa määrän.

Spoiler: Sensori

 

[MK01]

Laitoin tämän kokeeksi Home Assistantiin, mutta jostain syystä porssari_request sensoria ei löydy. Ja koska sitä ei löydy, ei data myöskään päivitty automaattisesti. Käsin laukaisemalla datan saa kyllä päivitettyä. Yaml tiedostot kopioin suoraan githubista, joten ei pitäisi olla näppäilyvirhettäkään.

 

[tk-]

Laitoin tämän kokeeksi Home Assistantiin, mutta jostain syystä porssari_request sensoria ei löydy. Ja koska sitä ei löydy, ei data myöskään päivitty automaattisesti. Käsin laukaisemalla datan saa kyllä päivitettyä. Yaml tiedostot kopioin suoraan githubista, joten ei pitäisi olla näppäilyvirhettäkään.

Mikä Home Assistantin versio sinulla on? Onko sinulla pääsyä home-assistant.log -tiedostoon, eli minkälaista vikaa sinne ilmaantuu? Itsellä on tuo uusin Home Assistantin versio, ja sillä on toiminut ongelmitta.

Voin joka tapauksessa kokeilla tehdä tuohon templaattiin illemmalla sokkona jotain muutoksia. Tuo request-sensori on jouduttu tekemään curl-sensorina tuon rest-sensorin http-koodien ymmärtämättömyyden vuoksi.

Periaatteessa tuon pitäisi toimia myös pelkällä rest-sensorilla pollaten, ja datan pitäisi säilyä vaikkei uutta jsonia joka kerta palautetakaan. Pitääpä vielä tutkia tätäkin vaihtoehtoa mikäli tuo request-sensori tuottaa ongelmia. Kiitos hyvästä palautteesta!

 

[MK01]

Hassio pitäisi olla uusin versio, asennettu raspberrylle. Pitää tutkia tuo lokitiedosto illalla.

 

[MK01]

No nyt kyseinen sensori ilmestyi näkyviin ja saa oikean arvon. Alkoi toimimaan operating systemin päivityksen myötä (versio 10.2).

 

[tk-]

No nyt kyseinen sensori ilmestyi näkyviin ja saa oikean arvon. Alkoi toimimaan operating systemin päivityksen myötä (versio 10.2).

Hyvä juttu! Ehkä tämä ei sitten toimi vanhemmilla versioilla luotettavasti, eli lisään tuonne Githubiin tiedon siitä mistä versiosta eteenpäin toimii varmasti.

Tuossa command-line -sensorissa on kyllä ollut jotain kummallisuuksia, lueskelin jotain vanhoja Githubin issueita missä sitä oli joku laajaltikin testannut ja todennut, että vaikka dokumentaation perusteella templaatit on tuettu, niin eipä ne aina toimikaan... Ehkä niitä on sitten onnistuneesti korjattu näihin uudempiin versioihin.

 

[tk-]

Nyt olisi tuo ajanjaksotriggeröinti jalostumassa kuitenkin seuraavaan muotoon, eli jokaiselle triggerille luotaisiin oma sensori. Asetukset ajanjakson pituudelle tehtäisiin yamliin minkä jälkeen sitä voisi sitten käyttää automaatiotriggerinä. Ja automaatiolla sitten luotaisiin tuo päällekytkentä ja poiskytkentä seuraavaan tapaan.

Vaikuttaako toimivalle ajatukselle? Testailen tuota nyt vielä pari päivää ja sitten julkaistaan tuohon viralliseen pakettiin.

Päivittelen lähipäivinä tuon tämän ketjun ensimmäisen postauksen "infoviestiksi" missä on aina sitten kootusti senhetkinen versio kaikkine ominaisuuksineen saatavilla. Kommentteja ja testaajia otan edelleen ilolla vastaan. Pyrin tekemään muutokset niin ettei olemassaolevaa tarvitse poistaa päivittäessä, mutta aivan lopullisesti en vielä sitä uskalla luvata.

Spoiler: Sensori

Spoiler: Automaatio

Spoiler: Koodi

template:
  - sensor:
      - name: porssari_water_heating_trigger
        device_class: timestamp
        state: >
          {# Add sensor name to sensorName variable #}
          {% set sensorName = "porssari_water_heating_trigger" %}

          {# Do not edit template below this line #}
          {% if state_attr("sensor." + sensorName, "period") %}
            {% set begin = state_attr("sensor." + sensorName, "period")["Begin_timestamp"] %}
            {{ as_datetime(begin).isoformat() }}
          {% else %}
            {{ 0 }}
          {% endif %}
        attributes:
          period: >
            {% if is_state('binary_sensor.porssari_json_prices', 'on') %}

              {# Sensor settings for period length and hours in between to look for cheapest period #}
              {% set period = 4 %}
              {% set periodStartHour = 0 %}
              {% set periodEndHour = 24 %}

              {# Do not edit template below this line #}
              {% set timeStampList = state_attr("sensor.porssari_json_data", "Prices") | list %}
              {% set ns = namespace(ts=[], tsPeriod=[], price=0, cheapestprice=999999, begin=0) %}
              {% for item in timeStampList %}
                {% if now().day == as_datetime(item).day %}
                  {% set ns.ts = ns.ts + [item] %}
                {% endif %}
              {% endfor %}
              {% for item in ns.ts if as_datetime(item).hour >= periodStartHour and as_datetime(item).hour <= periodEndHour - (period - 1) %}
                {% set ns.price = 0 %}
                {% set ns.tsPeriod = [] %}
                {% set begin = as_datetime(item) %}
                {% set beginHour = begin.hour | int %}
                {% set end = as_datetime(item) + timedelta( hours = period ) %}
                {% if beginHour < (24 - period) %}
                  {% for item in ns.ts if as_datetime(item) >= begin and as_datetime(item) < end %}
                    {% set ns.tsPeriod = ns.tsPeriod + [item] %}
                  {% endfor %}
                  {% for item in ns.tsPeriod %}
                    {% set t = item | string %}
                    {% set ns.price = ns.price + state_attr("sensor.porssari_json_data", "Prices")[t]['Price'] | float %}
                  {% endfor %}
                  {% if ns.price < ns.cheapestprice %}
                    {% set ns.begin = begin.isoformat() %}
                    {% set ns.cheapestprice = ns.price %}
                  {% endif %}
                {% endif %}
              {% endfor %}
              {% set res = {"Begin_timestamp": ns.begin, "Period_length": period, "Total_price": ns.cheapestprice | round(2), "Between": periodStartHour | string + " - " + periodEndHour | string} %}
              {{ res }}
            {% else %}
              {{ 0 }}
            {% endif %}

 

[tk-]

Nyt olisi tuo ajanjaksotriggeröinti jalostumassa kuitenkin seuraavaan muotoon, eli jokaiselle triggerille luotaisiin oma sensori. Asetukset ajanjakson pituudelle tehtäisiin yamliin minkä jälkeen sitä voisi sitten käyttää automaatiotriggerinä. Ja automaatiolla sitten luotaisiin tuo päällekytkentä ja poiskytkentä seuraavaan tapaan.

Vaikuttaako toimivalle ajatukselle? Testailen tuota nyt vielä pari päivää ja sitten julkaistaan tuohon viralliseen pakettiin.

Päivittelen lähipäivinä tuon tämän ketjun ensimmäisen postauksen "infoviestiksi" missä on aina sitten kootusti senhetkinen versio kaikkine ominaisuuksineen saatavilla. Kommentteja ja testaajia otan edelleen ilolla vastaan. Pyrin tekemään muutokset niin ettei olemassaolevaa tarvitse poistaa päivittäessä, mutta aivan lopullisesti en vielä sitä uskalla luvata.

Spoiler: Sensori

katso liitettä 87016

Spoiler: Automaatio

katso liitettä 87014

Spoiler: Koodi

template:
  - sensor:
      - name: porssari_water_heating_trigger
        device_class: timestamp
        state: >
          {# Add sensor name to sensorName variable #}
          {% set sensorName = "porssari_water_heating_trigger" %}

          {# Do not edit template below this line #}
          {% if state_attr("sensor." + sensorName, "period") %}
            {% set begin = state_attr("sensor." + sensorName, "period")["Begin_timestamp"] %}
            {{ as_datetime(begin).isoformat() }}
          {% else %}
            {{ 0 }}
          {% endif %}
        attributes:
          period: >
            {% if is_state('binary_sensor.porssari_json_prices', 'on') %}

              {# Sensor settings for period length and hours in between to look for cheapest period #}
              {% set period = 4 %}
              {% set periodStartHour = 0 %}
              {% set periodEndHour = 24 %}

              {# Do not edit template below this line #}
              {% set timeStampList = state_attr("sensor.porssari_json_data", "Prices") | list %}
              {% set ns = namespace(ts=[], tsPeriod=[], price=0, cheapestprice=999999, begin=0) %}
              {% for item in timeStampList %}
                {% if now().day == as_datetime(item).day %}
                  {% set ns.ts = ns.ts + [item] %}
                {% endif %}
              {% endfor %}
              {% for item in ns.ts if as_datetime(item).hour >= periodStartHour and as_datetime(item).hour <= periodEndHour - (period - 1) %}
                {% set ns.price = 0 %}
                {% set ns.tsPeriod = [] %}
                {% set begin = as_datetime(item) %}
                {% set beginHour = begin.hour | int %}
                {% set end = as_datetime(item) + timedelta( hours = period ) %}
                {% if beginHour < (24 - period) %}
                  {% for item in ns.ts if as_datetime(item) >= begin and as_datetime(item) < end %}
                    {% set ns.tsPeriod = ns.tsPeriod + [item] %}
                  {% endfor %}
                  {% for item in ns.tsPeriod %}
                    {% set t = item | string %}
                    {% set ns.price = ns.price + state_attr("sensor.porssari_json_data", "Prices")[t]['Price'] | float %}
                  {% endfor %}
                  {% if ns.price < ns.cheapestprice %}
                    {% set ns.begin = begin.isoformat() %}
                    {% set ns.cheapestprice = ns.price %}
                  {% endif %}
                {% endif %}
              {% endfor %}
              {% set res = {"Begin_timestamp": ns.begin, "Period_length": period, "Total_price": ns.cheapestprice | round(2), "Between": periodStartHour | string + " - " + periodEndHour | string} %}
              {{ res }}
            {% else %}
              {{ 0 }}
            {% endif %}

Ainakin ensimmäisen vuorokauden vaihtumisen perusteella näyttäisi toimivan oikein. Testailen vielä pari päivää ja täytyy tuon templaattieditorin kanssa simuloida vielä kellojen kääntämisen vaikutus tuon sensorin toimintaan.

Sitä en kyllä itseasiassa varmaksi tiedä mitä tapahtuu jos tuon automaation neljän tunnin odotusajan aikana boottaa homeassistantin uudestaan. Pitää ehkä sekin vielä testata.

Ja varmuudeksi vielä totean, että tuolla Shelly Plugilla en ohjaisi itse koskaan lämminvesivaraajaa kun ei se kestä niin isoa jatkuvaa kuormaa. Eli tämä on vain testimielessä tehtyä.

 

[tk-]

No nyt kyseinen sensori ilmestyi näkyviin ja saa oikean arvon. Alkoi toimimaan operating systemin päivityksen myötä (versio 10.2).

Päivitin eilen testi-HA:n seuraavan julkaisun betaversioon, ja siellä on nyt deprekaatiovaroitus versiosta 2023.8 -lähtien tuolle curl-sensorin toteutukselle. Täytyy nyt tutkia vielä dokumentaatiot tarkkaan meneekö ihan vaan nykyisellä sensorilla pieniä muutoksia tehden, mutta alkaa äkkiseltään vaikuttaa sille, että tuosta olisi kuitenkin pitkässä juoksussa hyvä yrittää päästä eroon kokonaan.

Josko tuo rest-sensori alkaisi jossain vaiheessa tukemaan noita http-koodeja. Toki nykyisessä templaatissa ei pitäisi olla ongelma, että tuo rest-sensori pyyhkäistään attribuuteista tyhjäksi, niin tosiaan se helpoin vaihtoehto voi olla vaan poistaa tuo koko http-koodin tarkistus käytöstä ja pollata serveriä tuolla pelkällä rest-sensorilla. Se saa sitten aina kuitenkin uuden jsonin kun serveri tahtoo sen vähintään kerran tunnissa antaa, ja tuolloin se uusi palvelimelta saatu json-data päivitetään myös siihen varsinaiseen datasäilösensoriin minkä ei pitäisi tyhjentyä vaikka rest-sensori tyhjenee.

Alkaa kyllä enenevässä määrin houkuttelemaan ajatus muokata tämä jatkossa tuollaiseksi HACS-tyyppiseksi lisäosaksi ja toteuttaa tuo palvelinkysely Pythonilla samaan tapaan kuin Pico-skriptissä. Se on ainakin todettu varmatoimiseksi keinoksi.

 

[tk-]

Tulipahan ajettua tosielämän testi viikon ajan kun oltiin poissa kotoa. Hyvin näyttää tuo 4h halvimman jakson etsivä sensori Shelly Plugia ohjaavan. Ja muutenkin paketti toimii ongelmitta ja vakaasti.

Tuo uusimman version command_line -sensorin templaatin korjaus pakottaa päivittämään yamlit ennen elokuun home assistant -päivitystä, niin virallinen "julkaisuversio" tulee viimeistään heinäkuun aikana. Tosiaan jatkossa on mahdollista ottaa käyttöön joko pelkän hintatiedon hakeva paketti tai sitten sekä hintatiedon että ohjauskanavat hakeva paketti.

Spoiler: Käyttötesti

 

[tk-]

Tuossa toisessa ketjussa jo vähän asiaa sivusinkin, mutta tuo 2023.6 sitten kuitenkin "rikkoi" vähän tätä toteutusta. 2023-6-Beta -versio toimi vielä ongelmitta, mutta lopullisessa tuotantoversiossa tuo http-koodia palvelimelta haisteleva sensori lakkasikin sitten kokonaan päivittymästä minkä vuoksi myös json-sensori lakkasi päivittymästä, kun tuohon ei saatu tilakoodia 200.

En tiedä onko vika vai ominaisuus, mutta lopullinen ongelman syy oli se, että command_line -sensoria päivitettiin automaation avulla. Sepä ei sitten päivittynytkään. Ongelma ratkesi jokusen tunnin vianetsinnän myötä sillä, että laitoin tuon command_line -sensorin päivittymään 120sek välein ja json-haku triggeröidään sitten aina kun tuon anturin tila muuttuu.

Tästä viisastuneena lisään vielä pakettiin semmoisen ominaisuuden, että jos edellisestä aikaleimasta on aikaa yli 2h, niin tuo json-sensori päivitetään tuon request-sensorin tilasta riippumatta. Se saattaa aiheuttaa jokusen infovaroituksen logiin, kun rest-rajapinta saa palvelimelta tyhjän vastauksen odottaessaan jsonia. Mutta se ei vaikuta varsinaisen ohjausdataa muistissa pitävän sensorin toimintaan.

Mutta palaan edelleen tuossa pari viestiä aiemmin todetussa, että pyrin viimeistään syksyn aikana tekemään tämän tuollaiseen custom-component -muotoon jolloin palvelinkyselyt voidaan ajaa pico-skriptin tapaan Pythonilla eikä tarvitse kokoajan olla varpaillaan Home Assistantin muuttuvien ominaisuuksien kanssa. Toki mahdolliset viat pyritään korjaamaan mahdollisimman nopeasti, nyt vaan sattui ikävästi juuri viikon lomareissu tämän päivityksen kanssa päällekkäin!

 

[tk-]

Tästä paketista joudutaan kuitenkin jättämään nyt tuo sähkön hintadata kokonaan pois, koska NordPool ei salli pörssihinnan uudelleenjakelua ilman 3000€/vuosi maksavaa lisenssiä, ja käsittääkseni tuollainen hintatieto mitä on muokattu, vaatisi tuon 15000€/vuosi maksavan lisenssin.

Nordpoolista on kuitenkin nyt varmistettu, että Pörssäri semmoisenaan on luvallinen palvelu kunhan loppukäyttäjällä ei ole mitään mahdollisuutta päästä käsiksi hintadataan.

Eli toisin sanoen, nuo ohjauskanavat säilyvät. Kehittelemme niiden ominaisuuksia jatkossa entistä paremmiksi, ja mikäli tuntuu sille, että 8 erilaista ohjausmahdollisuutta ei ole riittävästi, niin siinä tapauksessa niitä on mahdollista saada itselleen lisää.

Hintatiedot sitten täytyy hakea jostain muusta palvelusta tai iframena jostain luvalliselta sivustolta. Itse en osaa varmaksi suositella mitään kun en ole täysin tietoinen miten mikäkin sivusto tai rajapinta nuo lisenssiasiat hoitaa.

 

[jalih]

Tästä paketista joudutaan kuitenkin jättämään nyt tuo sähkön hintadata kokonaan pois, koska NordPool ei salli pörssihinnan uudelleenjakelua ilman 3000€/vuosi maksavaa lisenssiä, ja käsittääkseni tuollainen hintatieto mitä on muokattu, vaatisi tuon 15000€/vuosi maksavan lisenssin.

Itseäni ihmetyttää, miten nykypäivänä voi veloittaa lisenssimaksuja datasta minkä pitäisi olla avointa ja kaikkien pörssisähköasiakkaiden saatavilla. Vähän sama kuin lähikaupassa tuotteiden hinnat olisi piilotettu.

 

[tk-]

Itseäni ihmetyttää, miten nykypäivänä voi veloittaa lisenssimaksuja datasta minkä pitäisi olla avointa ja kaikkien pörssisähköasiakkaiden saatavilla. Vähän sama kuin lähikaupassa tuotteiden hinnat olisi piilotettu.

Se tässä itsellekin tuli vähän yllätyksenä, kun ei käynyt mielessäkään, että kyseessä olisi tekijänoikeuden alainen data. Ja moni muukin palvelu näitä tietoja jakaa. Toki on mahdoton sanoa, että kuka on hankkinut lisenssin ja kuka ei. Mutta ilmeisesti entso-e:n kautta tietoja periaatteessa ei saisi konelukea koskaan, vaan sitten lisenssillä pääsee käsiksi suoraan NordPoolin apiin.

Ilmeisesti se sitten menee niin, että pörssi omistaa hintatietonsa, ja tuo entso-e on lähinnä juuri sitä läpinäkyvyyttä varten, mutta ei tietojen hyödyntämistä varten. Ja jos tietoa haluaisi hyödyntää, niin sitten on nuo lisenssituotteet sen käyttämiseksi. Onneksi tässä löytyi nyt meitä kohtaan goodwilliä, että saadaan kuitenkin ohjaustietojen osana tuota hintatietoa käyttää. Eipä oikein ilmaista harrastelupalvelua pyöritetä jos siihen tarvittaisiin 15t€ vuosilisenssi.

 

[Sukke]

Mutta ilmeisesti entso-e:n kautta tietoja periaatteessa ei saisi konelukea koskaan, vaan sitten lisenssillä pääsee käsiksi suoraan NordPoolin apiin.

ENTSO-e tarjoaa API:n, eikö se ole konelukua? Luultavasti en ymmärrä jotain.

ENTSO-e:n käyttöehdoissa varmaankin tietojen julkaisu kielletty?

 

[Mikki]

Täysin /cstä on tämä homma jota monopoli firma pyörittää. Tuossa yllä olikin hyvin todettu, että satojen tuhansien ihmisten ostaman palvelun hintoja pitäisi salata ja jakaa tiskien alta ihmisille rahaa vastaan.

Jos tämä ei ole älytöntä niin ei mikään.

Täytyy kysellä jotain Nigerialaisia pyörittämään rajapintoja jos ei muuten onnistu.

 

[tk-]

ENTSO-e tarjoaa API:n, eikö se ole konelukua? Luultavasti en ymmärrä jotain.

ENTSO-e:n käyttöehdoissa varmaankin tietojen julkaisu kielletty?

Minulle vastattiin näin Nordpoolista:

”Actually ENTSOE should not be making the market price data available for download in the first place.”

Entso-E käyttöehdoissaan kyllä kieltää loukkaamasta alkuperäisen tarjoajan ehtoja. Osa Nord poolin datasta olisi ilmeisesti vapaasti uudelleenjulkaistavissa, mutta day ahead prices ei kuulu niihin.

 

[tk-]

Testattu toimivaksi 2023.7 ensimmäisellä beta-versiolla. Toivottavasti myöhemmät ei tällä kertaa riko ominaisuuksia.

Tuo command_line -sensorin päivittäminen automaation avullakin oli sittemmin kyllä korjattu noissa 2023.6 -myöhemmissä versioissa, mutta päädyin nyt pitämään sen jatkossakin tuolla 120sek päivitysvälillä ilman automaatioa. Kaikki HA-instanssit ei kuitenkaan pollaa samalla sekunnilla palvelinta, kun laskuri lähtee aina käyntiin siitä hetkestä kun HA käynnistyy, eli ajattelisin siitä itsessään tulevan riittävästi randomointia, jopa enemmän kun mitä tulisi triggeröidä se automaatio aina parillisin tasaminuutein 30sek randomoinnilla. Ja muutenkin tuo pelkkä header-request on palvelimelle aika kevyt käsitellä.

 

[tkhyla]

Onkohan tämä ketju vielä aktiivinen?
Asentelin eilen homeassistantiin tuon pörssärin. Sain toimimaan ja hieno systeemi!

Yksi havainto, onko virhe vai feature?

Pörssärin päästä katsottuna laite "nähty viimeksi" aika päivittyy 2-3 minuutin välein ok.
Jos muutan laitteen kytkentä asetuksia pörssärin päässä vaikka klo 10:30 siten, että ko. kanavan tilan pitäisi vaihtua niin tämä päivittyy vasta klo 11:00 Home assistantissa. Vaikka pörssäri sivuilla oleva graaffipalkki näyttää oikein uuden päivitetyn säännön mukaisen tilan.

Miksi tämä muuttunut arvo ei tule HA:lle saakka heti seuraavassa "laite nähty" tapauksessa? Eikö home assistant luekaan tätä aina kun "laite nähty"? Onko tämä bugi vai ominaisuus?
käytössä uusimmat releaset:
Home Assistant 2023.8.3
Supervisor 2023.08.1
Operating System 10.5

 

[tk-]

Onkohan tämä ketju vielä aktiivinen?
Asentelin eilen homeassistantiin tuon pörssärin. Sain toimimaan ja hieno systeemi!

Yksi havainto, onko virhe vai feature?

Pörssärin päästä katsottuna laite "nähty viimeksi" aika päivittyy 2-3 minuutin välein ok.
Jos muutan laitteen kytkentä asetuksia pörssärin päässä vaikka klo 10:30 siten, että ko. kanavan tilan pitäisi vaihtua niin tämä päivittyy vasta klo 11:00 Home assistantissa. Vaikka pörssäri sivuilla oleva graaffipalkki näyttää oikein uuden päivitetyn säännön mukaisen tilan.

Miksi tämä muuttunut arvo ei tule HA:lle saakka heti seuraavassa "laite nähty" tapauksessa? Eikö home assistant luekaan tätä aina kun "laite nähty"? Onko tämä bugi vai ominaisuus?
käytössä uusimmat releaset:
Home Assistant 2023.8.3
Supervisor 2023.08.1
Operating System 10.5

On aktiivinen! Tässä on nyt ollut kädet täynnä töitä tuon huomiselle luvatun päivityksen osalta, mutta minäpäs tutkailen vähän mikä tuollaisen voisi aiheuttaa. Muutenkin tuohon on tulossa vielä pieni fiksaus, kun nykymuotoinen versio hakee turhaan 2 kertaa putkeen palvelimelta tuon ohjaustiedon.

Voi olla, että vaatii jonkun kanavasensorien pakkopäivityksen vaan tuohon automaatioon silloin kun uusi json saadaan. Kiitos hyvästä huomiosta!

Onneksi toki kyse on hyvin pienestä viilauksesta, eli muutettujen asetusten päivittymisnopeudesta, mutta kyllä ideana on saada ne käyttöön heti kun ne palvelimella on tehty. Ja kyllä se tahtotila olisi jossain vaiheessa saada noita asetuksia myös sinne HomeAssistantiin niin, että ei tarvitse käydä sivustolla kirjautumassa, mutta se vaatii jonkinlaisen autentikoinnin tuohon vielä kaveriksi sekä rajapinnan palvelimen päähän joka pystyy tietokantaan kirjoittamaan. Nyt tuo ohjauspuoli saa vain lukea tietokantaa. Ehkä ensi keväänä…

 

[tk-]

Nostellaanpas tätäkin vähän kun serverin siirtotöiltä nyt on taas aikaa kaikkeen muuhunkin (töiden ja muun elämän lisäksi, heh heh...)

Eli tarkoituksena on myös päivittää tämä HA-paketti kun rajapintakin päivittyy varttiohjauksen (tai oikeastaan 15sek tarkkuudella suorittavan ohjauksen) mukaiseen schedule-jsoniin. Pohdin sen toteuttamista tässä HA:ssa ja seuraavanlainen visio on itsellä mielessä.

Eli edelleen siellä olisi mukana nuo kanavamäärän mukaiset binäärisensorit. Todennäköisesti pidän sen fiksoituna kahdeksassa jos en keksi miten tuolla yamlilla voidaan loopissa muodostaa sensoreita. Todennäköisesti ei mitenkään. Näiden kanasensoreiden tila sitten olisi joko 0 tai 1 sen mukaan kuuluuko ohjauksen olla päällä.

Lisäksi jokaiselle kanavasensorille tekisin valmiiksi switchin mikä muuttaa tilaansa sen kanavasensorin mukaan paitsi jos käyttäjä muuttaa sitä itse toiseen suuntaan. Tämä toimisi samalla ns. pakko-ohjauskytkimenä, ja aina kun käyttäjä sitä muuttaa niin liipaistaan timer päälle minkä ajan Pörssärin ohjaus kyseiselle kanavalle ohitetaan. Sitten kun timer on lopussa, niin palataan seuraamaan Pörssärin ohjausta. Automaatiot voisi sitten seurata tuota switchin tilaa mitä käyttäjä voi itse muuttaa/Pörssäri muuttaa jos käyttäjäohjauksen timer on nollassa.

Toteutus voi vielä tästä vähän jalostua, mutta kuulostaako ideana toimivalle ja kannattaa lähteä edistämään?

Lämmitysohjauksessa tuossa tulee todennäköisesti jokin neliportainen 10-20-30-40 (pois, normaali, tehostettu, ylikapasiteetti (isompi tehostus + käyttövesi?)) ja siihen täytyy sitten miettiä tuo ohitusohjaus erikseen miten se toteutetaan. Sähkölämmityksessä tosin käytännössä 10-20, koska eipä sitä paljoa boostata siitä mikä se antoteho on ja sähkölämmitys ei yleensä myöskään jaa aikaa käyttövesiohjauksen kanssa.

 

[tk-]

Varttiaikaleimoja lukeva HA-templaatti löytyy nyt päivitettynä Githubin release -kansiosta. Kauheasti muuta kehitystyötä tuon eteen ei ole tehty, eli edelleen tilat resetoituu uudelleenkäynnistyessä jne. Mutta pitäisi olla yhteensopiva vanhan version kanssa, eli ainoastaan tuon state-sensorin tilatemplaatti on muuttunut ja toki tuo ohjaustiedon muoto.

GitHub - Porssari/HomeAssistant-client: Pörssäri Home Assistant integration

Pörssäri Home Assistant integration. Contribute to Porssari/HomeAssistant-client development by creating an account on GitHub.

github.com

 

[huugo]

Tämä on ehkä noobi kysymys, mutta kysyn kuitenkin.

Lähtötilanne: Shellyt asennettu ja home assistantissa. Pörssäri tehty ja pörssärin kanavat kohdillaan. Kanavat näkyvät HA:ssa.

Miten helpoiten yhdistän home-assistant säännöt ohjaamaan Shelly switchejä.
Ohje sanoo näin:" Näitä sensoreita voi käyttää automaatiotriggereinä Home Assistantin ohjaamien laitteiden päälle- ja poiskytkentään."

Pitääkö tuonne tehdä monta automaatiota per switch - tyyliin jos 0, niin kytke pois. Jos 1, niin kytke päälle... Vai onko helpompi keino?