MSZ-LN sulatushuijaus

[Velsku]

Yhtä sekavaa on käyrä, mitä täällä:

Kuvassa siis pyörii nyt uusin softa, uudella tilakoneella. huomenna vähemmän zoomanttuna tuo data on luettavaa ja siitä pystyy päättelemään toimiko softa halutusti. --> Nyt nukkumaan ja huomenna analysointia...

 

[iro]

Hienoa @RauskiH! Kun EspHome kilkkeet on nyt koneellasi niin voisit kokeilla kääntyykö @Velsku:n tuolla keskusteluketjun alkupuolella postaama mszlnhack.yaml koneellasi (ainakin minulla tuo kääntyy). Tämän jälkeen voit ottaa uudimman paketin gifthub:sta (myös tämä kääntyy minulla). Ehkä yksinkertaisinta on kopioda puretun paketin "platform.yaml" ja "mitsurunnes.yaml" tiedostot työhakemistoosi ja yrittää käännöstä siellä.

 

[Velsku]

@puu
En jouda nyt analysoida kovin hyvin käyriä, mutta laitan tähän kuvat käyristä, jotta voit tarkistella logiikan toimintaa .
Kuvassa selitykset, mistä muuttujasta kyse.
Vihreä viiva on DeltaT raja.

Testiajon aikarajat ovat :

/* Temperature threshold that has to be exceed long enough to start defrosting. */
const float TEMPERATURE_DELTA_TO_DEFROST = 3.0;

/* Temperature threshold that triggers defrosting even though
* MIN_HEATING_TIME would not be passed. */
const float TEMPERATURE_DELTA_TO_FORCE_DEFROST = 5.0;

/* When temperature delta has been over the threshold
* (TEMPERATURE_DELTA_TO_DEFROST) this long, defrosting is started. */
#define TEMPERATURE_DELTA_EXCESS_TIME   2   /* minutes */

/* When this time has been passed since last defrosting,
* forced defrosting will be started. */
#define MAX_HEATING_TIME                60 /* minutes */

/* The minumum time between defrosting operations. */
#define MIN_HEATING_TIME                10  /* minutes */

/* The time that the defrost hack relays is off after defrosting is started. */
#define RELAY_OFF_TIME                  5  /* minutes */

/* If defrosting is not started during this time after switching the relay off,
   state will be set back to IDLE inetead of DEFROSTING STARTED */
#define DEFROST_TIMEOUT                 10  /* minutes */

/* Delay at the reset before startting the state machine to give
* time for the sensors to be read. */
#define RESET_SENSOR_DELAY_SEC          25  /* seconds*/

 

[puu]

Kiitos, katselenpa noita jossain välissä. Ainakin tuo state näyttäisi äkkipäätä ihan järkevältä.

Kysymys vielä @Velsku Grafanasta: Mulla ainakin tulee tällä hetkellä nuo arvot stringeinä grafanalle asti. Se osaa kyllä piirtää ne, muttei esim. laskea arvoilla. Onko sulla jossain välissä tehty string ->float -konversio ja missä ja miten? Telegrafilla kun yritin vastaanottaa float-muodossa mqtt-viestejä, niin se ei ainakaan tykännyt.

 

[Velsku]

Kuten huomasit, niin kaikki mitä Grafanalla haluaa piirtää, niin pitää olla tietokantaan laitettu numeroina.

Sulla nyt tuossa joku (Telegrafi?), joka vastaanottaa MQTT viestin ja käsittelee sen, kirjoittaa ne tietokantaan numeron sijasta numeron sisältävänä stringinä, eli tekee väärän konversion joka pitäisi korjata, sen sijaan että tekee takaisin konvertoinni myöhemmin. Voisiko floatin stringiksi tulkitsemisen syy olla desimaali pisteessä? Toimiiko kokonaisluvuilla?

Minulla on vanhempi grafanan versio, se ei kykene edes tuollaista näyttämään. Uusi tieto mulle, että Grafana kykenisi...

 

[puu]

Mulla on siis /etc/telegraf/telegraf.conf:ssa näin:
[[inputs.mqtt_consumer]]
servers = ["tcp://127.0.0.1:1883"]
topics = [
"telegraf/host01/cpu",
"telegraf/+/mem",
"sensors/#",
"sensors/temperature"
]
data_format = "value"
data_type = "string"

Tuon data_typen jos vaihdan "float", niin alkaa lykkäämään tällaista herjaa:
conflict: input field "value" on measurement "mqtt_consumer" is type float, already exists as type string dropped=12; discarding points

 

[Velsku]

En ole telegrafia käyttänyt koskaan. Eli tuo conffikieli on ihan vierasta.
Mutta noin sinun pitäisis tuo muuttaa, että käsittelee floatit oikein, eikä käännä niitä stringeiksi.

Pari kysymystä:
Voiko tuo johtua siitä, että telegram tunnistaa, että aikaisemmin nämä käsiteltiin stringeinä ja data menee tietokannassa "sekaisin" --> pitäisikö jotain puhdistaa?

Tai voisiko syy olla siinä, että joku noista on ihan Stringi, eli sisältää muitakin merkkejä, kuin desimaalipisteen/numeroita.
Eli voisiko tuon mqtt_consumer osaston jakaa kahteen erilliseen osaan siten, että numerot tulisi toiseen (-->float) ja muita merkkejä, kuin numeroita/desimaalipisteitä tulisi toiseen (--> string)?

 

[puu]

Tuhosin vanhat data tuolta databasesta. Se ei halunnut laittaa samaan "measurementiin" floatteja kun siellä oli jo stringejä. Nyt toimii! Eli floatiksi kun laittaa kun pystyttää, niin hyvin menee.

 

[iro]

@RauskiH, kun saat wemos:in pöydällesi kolvattavaksi niin laita DS18B20 datakarva nastaan D7, silloin on yhtenevä @puu:n raudan kanssa.

 

[iro]

@RauskiH, korjaus aiempaan EspHomeen liittyvän neuvon toisen osaan. Kun olet hakennut githubista zip-paketin, pura se EspHome:n työhakemistoosi. Sinne syntyy uusi nyt uusi hakemisto "MitsuRunner-main" (jonka alla on mitsurunner.yaml ja platform.yaml sekä constants.h ja state.h.) Kääntääksesi paketin sinun tulee siirtyä tuohon MitsuRunner-main hakemistoon tyyliin
"cd c:\users\rauskih\esphome\MitsuRunner-main" (siellä" komento esphome mirsurunner.yaml run")

 

[iro]

@puu & @Velsku , lukaisin pikaisesti uuden MitsuRunner koodin. Todella hienoa työtä, helposti hahmotettava rakenne ja muutettavat parametrit selkeästi erillään.
Yksi minor detail osui silmään... Dallas pin on oletuksena D2 pitäisikö olla D7?

 

[puu]

@puu & @Velsku , lukaisin pikaisesti uuden MitsuRunner koodin. Todella hienoa työtä, helposti hahmotettava rakenne ja muutettavat parametrit selkeästi erillään.
Yksi minor detail osui silmään... Dallas pin on oletuksena D2 pitäisikö olla D7?

Kiitos! Tuo pinnin numero on varmaan elänyt matkalla kun Velskulla se taitaa olla D2 ja mulla D7. Mutta varmaan tuo D7 on parempi oletuksena, kun WeMos D1 minissä se on tuossa mukavan lähellä 3.3V padia, joten voisin muuttaa sen takaisin. (Toisaalta D6:een taipuisi 1/4W vastus paremmin...)

 

[iro]

Minulla osui arvonnassa D5, pistin anturit ja vastuksen releyksikköön niin tarvittaessa voi wemosin napata erilleen.
@puu , tee valinta diktaattorin valtuuksin ja kerrotaan oikea pin @RauskiH :lle

 

[Velsku]

Markkinointia: Alla kuvassa osoitus, miksi tämä on parempi kuin Mitusun alkuperäinen.

MitsuRunnerilla varustettu pumppu olisi tänäänkin toiminut tehokkaampana lämmityslaitteena, mutta silti säästänyt sähköä, jopa verrattuna täysin toimivaan ja optimoituun pumppuun. (Saati sitten toimivaan, mutta eristämättömään tai vanhasoftaiseen, hullunkiertoiseen...)


Sulatushuijaus ei ole minulla ohjaamassa laitetta, mutta ottaa laitteesta kaikki datat ja piirtää logiikkansa käyriin.
--> Laite toimi täysin oman logiikkansa mukaan. Testaan uutta refactoroitua tilakonetta, jotta saadan se 100% luotettavaksi.

Allaolevassa käyrässä keltainen viiva alkaa nousta ylöspäin, osoituksena kennon tukkoon menosta.
Mitsubishin logiikalla pumppu jatkaa silti lämittämistä aivan tukossa olevalla pumpulla. Kävin juuri varmistamassa asian, todella paksu kuurakerros kauttaaltaan tukkien kennon. Lämpöä ei siirry tehokkaasti enää sisälle, laite lähestyy COP:ltansa suoraa sähkölämmitystä koko ajan.

MitsuRunner olisi aloittanut sulatuksen oikea-aikaisesti punaisten nuolten kohdalla ja pumppu olisi toiminut tehokkaampana lämmityslaitteena, tuottaen lämpöä paremmin sähköä säästäen. Siitä indikoi alemman punaisen nuolen osoittama violetin logiikkakäyrän nousu toiselle tasolle. Tuossa kohtaa tukossa oleva kenno oltaisiin sulatettu ja vältetty tämä huonolla hyötysuhteella lämmittäminen.

Päivitys: Pumpun oma logiikka veti 45min liian pitkän lämmitysjakson, ennen omalla logiikallansa tehtyä sulatusta. Kenno näytti ennemminkin lumipallolta ennen tätä sulatusta, kuin kennolta. Ja sähköä kului aivan turhaan, eikä pumppu enää lämmittänyt tehokkaasti...

 

[puu]

Tässä eräs case, mikä pitäisi softassa vielä hanskata. Nyt kävi niin, että sulatusrele vapautettiin (aloita sulatus), mutta pumppu ei lähtenyt vielä sulattamaan. Sitten se lähtikin juuri siinä vaiheessa sulattamaan, kun sulatuksen aloituksen timeout laukesi. Eli huijaussofta tulkitsi että sulatus ei alkanutkaan, vaikka se alkoikin juuri tarkastuksen jälkeen. Nyt softa piti sulatusrelettä päällä (ei saa sulattaa), jolloin 33k vastuksen kautta pumppu tulkitsi että ei koskaan saavuteta haluttua sulatuksen loppulämpötilaa je teki 10min sulatuksen.

Tämä bugi voi ilmetä hyvin pienessä aikaikkunassa, mutta nyt se sattumalta tuli ilmi. Sinänsä tuosta ei muuta haittaa ole kuin yksi ylipitkä sulatus. Huomatkaa ulkokennon loppulämpötila yli 50 astetta.

 

[puu]

Uskoakseni tuossa kävi niin, että kerrankin sulatushuijaus olisi halunnut lyhemmän lämmitysjakson kuin Mitsun logiikka. Tuossahan oli ollut kaksi 50min lämmitysjaksoa takana ja nyt sulatus lähti 60min lämmityksen jälkeen. Olisikohan tällä kertaa Mitsun logiikka kerrankin päättänyt pidentää lämmitysjaksoa. Ihan tarkkaan en logeistani näe ilman tehologia, mutta edellinen sulatus saattoi jäädä juuri alle 2min.

Olisikohan järkevää tehdä niin, että jos ulkokennon lämpötila on riittävästi yli ulkoilman, niin mennään aina (tai vähintään idle-moodissa) sulatusmoodiin, sillä silloinhan pumppu on sulattamassa, näin saadaan synkattua huijaussofta ja mitsun "fuzzy logic" keskenään?

 

[iro]

@puu, kuten totesit kuvaamasi tilanne lienee harvemmin esiintyvä poikkeustapaus, josta toivutaan ongelmitta. Mutta tuota voidaa pähkätä hieman tarkemmin. Root cause tilanteeseen oli siis se, ettei pumppu alkanut sulattaa... osaatko tulkita miksi ei ? Tapahtuiko sulatuksen liipaisu liian aikaisin , onko sinulla COP-käyrää tuosta tilanteesta , olisiko lämmitysveto voinut olla pitempi?

Nyt varoitus: Älkää ottako seuraavaa hahmotelmaa liian vakavasti, laitoin hetkeksi proppellihatun päähäni ja tämmöistä sieltä löytyi,

Yleisesti ottaen deltaT käyttäyttyy siten, että se kasvaa melko jyrkästi kun kenno alkaa tukkeutua,. Nykyinen liipaisuehto "deltaT (4C) on riittävän suuri tietyn ajan (5min)" on "flat" eikä siis hyödynnä tätä piirrettä kovinkkaan tehokkaasti. Paremmin toimisi painotettu keskiarvo, jossa uusimpia lukemia painotetaan asteittain isommilla kertoimilla (lieneekö termi "tappikerroin" teille tuttu?) Jos näytteitä on viisi kappaletta näytteenottoväli voisi olla hieman pidempi (2 min?) eli tarkastelujakso 10 min.

Ruokahalu kasvaa syödessä mutta kannattaa muistaa ettei toteutuksesta tule liian monimutkaista!

 

[iro]

@puu, ehdit vastata kysymykseeni jo ennen kun sen postasin. KISS-tyyppinen ratkaisu on varmaan riittävä tähän.

 

[puu]

Kyllähän tuonne ylipäätään joku filtteri kannattaa toteuttaa. Rinnalla voi vaikka koko ajan juosta suodatetut arvot läpmötiloista. Tuo viimeisiin arvoihin painotettu suodatus kuulostaisi järkevältä, niin reagoidaan vähän nopeammin kuin esim pelkällä keskiarvoistuksella.

Tämä voi mennä jo turhan monimutksieksi (muista KISS), mutta sellaistakin mietin jossain välissä, että integroitaisiin rajan ylittävää deltaa. Tällöin isompi deltan ylitys laukaisisi sulatuksen nopeammin.

Tuonne grafanaankin pystyy ilmeisesti kirjoittelemaan kaikenlaista matematiikkaa, voisi koittaa sinne piirtää filtteröityä käyrää ja katsoa miltä näyttäisi.

Edit: Mutta tosiaan mitään liian eksoottista logiikkaa tuonne ei parane laittaa. Pitää olla sellainen, että ilman tekniikan tohtorin tutkintoa pystyy logeista arvioimaan, toimiiko logiikka kuten pitää.

 

[puu]

Markkinointisegmentin graafisen suunnittelun osasto sai logonkin valmiiksi:

 

[Velsku]

Markkinointisegmentin graafisen suunnittelun osasto sai logonkin valmiiksi:

Loistava oivallus @puu tehdä logo, jolla hakkeroi tuon keskellä olevan Mitsubishin logon älykkäällä teknologialla paremmaksi (eikä millään sumealla).

Loistava värivalinta myös poistaa hälyyttävän punainen "pysy näistä laitteista erossa" varoitusväri logosta ja toteuttaa se neutraalilla mustavalkoisella teemalla, joka kuvaa MitsuRunnerin toimintavarmuutta ja luotettavuutta.

 

[puu]

Todellisuudessa en uskaltanut oikeusjuttujen pelossa tehdä tuosta punaista. Tuon tekstinkin tein vähän tummemmalla punaisella varmuuden vuoksi...

 

[RauskiH]

Uskoakseni tuossa kävi niin, että kerrankin sulatushuijaus olisi halunnut lyhemmän lämmitysjakson kuin Mitsun logiikka. Tuossahan oli ollut kaksi 50min lämmitysjaksoa takana ja nyt sulatus lähti 60min lämmityksen jälkeen. Olisikohan tällä kertaa Mitsun logiikka kerrankin päättänyt pidentää lämmitysjaksoa. Ihan tarkkaan en logeistani näe ilman tehologia, mutta edellinen sulatus saattoi jäädä juuri alle 2min.

Tuossa on varmaan käynyt juuri noin niin kuin pähkäilit. Jotain hämärää tuossa nyt kuitenkin on koska mitsun oma logiikka on kyllä konservatiivinen jatkamaan jaksoja. Lisäksi graafeista ihmettelen että mikä dt on ylös saanut. pumpun antoteho ollu pieni ja ei ole ennen sulatusta ollut tukkoon menossa vaan päin vastoin dt ollut laskussa vaikka pumpun antoteho pysynyt samana. Tukkoon menevässä kennossa pitäisi kyllä dt kasvaa kiihtyvällä tahdilla kun ollaan jo reilusti yli viidessä asteessa. Myöskään sulatuksesta päätellen kenno ei ole ollut tukossa kun sen lämpötila on kahdessa minuutissa kiipaissut yli kymmenen asteen eikä käyrässä ole minkäänlaista flat kohtaa nollan tuntumassa. Ulkolämpötila ei myöskään jourua että olisi tapahtunut äkillisiä säätilan muutoksia joka olisi voinut aiheuttaa kennon tukkeutumisen?

Voiko kennon lämpötilan mittauksessa olla jotain ongelmaa, kannatta seurailla että käyttääkö loogisesti. Toinen anturi rinnalle mittaamaan?

Varsinaista ongelmaa pidän itse harvinaisena/lähes mahdottomana ja en näe että sille kannattasi tehdä ainakaan tässä vaiheessa mitään, korkeintaan seurata ja varmistaa että mittaukset pelaavat. Jos kuitenkin tätä tapahtuu niin puun esimerkkitapauksessa ongelma tavallaan korjaa itse itseään sillä maksimisulatus lyhentää seuraavaa mitsun oman logiikan lämmitysaikaa. Ongelman esiintymisen todennäköisyyttä voi myös pienentää sillä että asettaa mitsurunnerin huijaus pois ajan lähelle mitsun oman logiikan minimilämmitysaikaa (+sulatusaika) eli 35-40 min

 

[puu]

Voit hyvinkin olla oikeassa, että on ehkä tarpeetonta ruveta korjaamaan tätä ongelmaa, koska todennäköisyys on tosiaan melko pieni eikä vahinko suuri vaikka tapahtuisikin joskus. Tuollainen supersulatus voi jopa tehdä välillä ihan hyvääkin(?) Noihin aikoihin taisi alkaa satelemaan kevyesti lunta, olisiko ilmankosteus sitten noussut aiheuttaen tuon.

Toisaalta tuon jälkeen veti sitten täyden 2,5h lämmitysjakson:

 

[iro]

Tässä olisi yksi suht yksinkertainen tapa filtrata. Muuttujaan ka kerätään tarkkailujakson deltaT keskiarvoa "vuotava integraattori" menetelmällä. Oletetaan että halutaan seurata 10min aikaikkunaa ja näytteitä otetaan 1 min välein.
1) Kun sulatushuijaus-tilan siirrytään,
ka =10*deltaT
tämän jälkeen minuutin välein
if ((ka/10 >= dTraja-1) && (uusi deltaT >= dTraja) || (uusi deltaT >= dTraja+1)) aloita sulatus
else ka = 9/10*ka + uusi dettaT.

Edelleolevasta puuttu säälisulatus.
Tässä nyt heitin että sulatuksen liipaisu edellyttää 1C deltaT nousua keskiarvosta, ja varmuuden vuokis liipaisu keskiarvosta välittämättä jos deltaT 1 asete yli dTraja..

Vaikea sanoa parantaako tämä triggausta, huonoa tässä on se että saadaan taas lisää parametreja

 

[RauskiH]

Voit hyvinkin olla oikeassa, että on ehkä tarpeetonta ruveta korjaamaan tätä ongelmaa, koska todennäköisyys on tosiaan melko pieni eikä vahinko suuri vaikka tapahtuisikin joskus. Tuollainen supersulatus voi jopa tehdä välillä ihan hyvääkin(?) Noihin aikoihin taisi alkaa satelemaan kevyesti lunta, olisiko ilmankosteus sitten noussut aiheuttaen tuon.

Toisaalta tuon jälkeen veti sitten täyden 2,5h lämmitysjakson:

On tuo edeltävä lämmitysjakso vain jotenkin hämärä kun dt oli tulossa omia aikojaan pois sulatusalueelta... mikä lie aiheuttanut ja sulatuksessa kennon lämpötila noussut pystysuoraan...

Varmaan kannattee logeista seurailla ja odottaa milloin tulee seuraava... veikkaan vain että saattaa kyllä käydä aika pitkäksikin

Parissa muussa dt liipaisemassa sulatuksessa dt kyllä käyttäytyy juuri niin kuin sen oletankin käyttäytyvän

Onko muuten pienentyt lämmitystarve rauhoittanut sinulla tehojen pumppaamista vai joko se satianen kurkkii kirjahyllyn sivulla?

 

[puu]

Ei kurki satiaiset vielä. Lämmitystarve vaan on nyt vähentynyt, etenkin päivisin kun aurinko lämmittää taloa (ja aamulla vähän pumppuakin). Sisäyksikkö puhaltelee alle 40-asteista melkeiin koko ajan.

Seuraava lämmitysjakso oli n. 1,5h. Siinäkin välillä laski dT, mutta johtui selvästi siitä, että lämmöntuotto laski samalla.

 

[Velsku]

Tässä eräs case, mikä pitäisi softassa vielä hanskata. Nyt kävi niin, että sulatusrele vapautettiin (aloita sulatus), mutta pumppu ei lähtenyt vielä sulattamaan. Sitten se lähtikin juuri siinä vaiheessa sulattamaan, kun sulatuksen aloituksen timeout laukesi. Eli huijaussofta tulkitsi että sulatus ei alkanutkaan, vaikka se alkoikin juuri tarkastuksen jälkeen. Nyt softa piti sulatusrelettä päällä (ei saa sulattaa), jolloin 33k vastuksen kautta pumppu tulkitsi että ei koskaan saavuteta haluttua sulatuksen loppulämpötilaa je teki 10min sulatuksen.

Tämä bugi voi ilmetä hyvin pienessä aikaikkunassa, mutta nyt se sattumalta tuli ilmi. Sinänsä tuosta ei muuta haittaa ole kuin yksi ylipitkä sulatus. Huomatkaa ulkokennon loppulämpötila yli 50 astetta.

katso liitettä 70424

Korjataan tämä laittamalla lämmitystilaan seuranta, jossa resetoidaan tila, jos lämmitysvaiheessa kenno menee kuumemmaksi, mitä ulkoilma. Se voi tapahtua vain, jos lämmityksestä huolimatta sulatus kytkeytyy. Ja resetoimalla tilan tehdään samat logiikat, mitä laitteen virrankytkennän yhteydessä (tutkitaan onko sulatus meneillään ja jatketaan toimintaa sen mukaisesti)

 

[puu]

Korjataan tämä laittamalla lämmitystilaan seuranta, jossa resetoidaan tila, jos lämmitysvaiheessa kenno menee kuumemmaksi, mitä ulkoilma. Se voi tapahtua vain, jos lämmityksestä huolimatta sulatus kytkeytyy. Ja resetoimalla tilan tehdään samat logiikat, mitä laitteen virrankytkennän yhteydessä (tutkitaan onko sulatus meneillään ja jatketaan toimintaa sen mukaisesti)

Tämä voisi olla sikälikin hyvä, että jos resetissä tulkitaan väärin, niin tällä se korjaantuisi hetikohta, kun huomattaisiin että hups, siellä olikin sulatus päällä vaikka ensin luultiin muuta.

 

[jmki]

Tuon data_typen jos vaihdan "float", niin alkaa lykkäämään tällaista herjaa:
conflict: input field "value" on measurement "mqtt_consumer" is type float, already exists as type string dropped=12; discarding points

Tuo tulee luultavasti siitä, että Infludb:ssa on jo ko. mittaukselle arvoja stringeinä eikä floateja hyväksytä sarjan jatkoksi. Tee siis uusi mittaussarja Influxdb:lle tai hävitä vanha. MQTT-sanoman sisältö (payload) on teknisesti "dataa" eikä protokolla ota kantaa siihen missä muodossa tieto kulkee. Usein lähettävässä päässä data paketoidaan pitkään stringiin, oli muoto sitten json:a tai jotain muuta. Vastaanottajan pitää tietää missä muodossa data kulkee ja purkaa sanoma haluttuun muotoon. Tässä sen tekee Telegraf.

 

[puu]

Tuo tulee luultavasti siitä, että Infludb:ssa on jo ko. mittaukselle arvoja stringeinä eikä floateja hyväksytä sarjan jatkoksi. Tee siis uusi mittaussarja Influxdb:lle tai hävitä vanha. MQTT-sanoman sisältö (payload) on teknisesti "dataa" eikä protokolla ota kantaa siihen missä muodossa tieto kulkee. Usein lähettävässä päässä data paketoidaan pitkään stringiin, oli muoto sitten json:a tai jotain muuta. Vastaanottajan pitää tietää missä muodossa data kulkee ja purkaa sanoma haluttuun muotoon. Tässä sen tekee Telegraf.

Kyse oli juurikin tästä, ja asia on nyt jo korjattu. Poistin kaikki vanhat mittausdatat, niin lähti toimimaan. Hyvä tarkennus kuitenkin tähän, kiitos.

 

[puu]

ESPHomehan tarjoaa antureille suoraan mm. sliding_window_moving_average ja exponential_moving_average -filttereitä:

Sensor Component

Instructions for setting up sensor components in ESPHome.

esphome.io

 

[iro]

Pääsin isomman näytön ääreen, noita kuvia on turha tiirata kännykän näytöstä... Voisiko tuo deltaT:n pieneneminen kesken lämmitysvaiheen johtua siitä, että lämmitystarve on pienetynyt ==> pumppu on pienentänyt ottotehoa. ==> kenno kykenee lämmittämään kiertoa tehokkaammin ==>deltaT pienenee. Kenties nollan paikkeilla oleva ulkolämpö puolestaan tekee sen että sulatus ei käynnisty heti.
Saatko talletettua pumpun ottotehoa niin voisi katsoa ottotehon ja deltaT:n suhdetta ?

 

[RauskiH]

Voisiko tuo deltaT:n pieneneminen kesken lämmitysvaiheen johtua siitä, että lämmitystarve on pienetynyt ==> pumppu on pienentänyt ottotehoa. ==> kenno kykenee lämmittämään kiertoa tehokkaammin ==>deltaT pienenee. Kenties nollan paikkeilla oleva ulkolämpö puolestaan tekee sen että sulatus ei käynnisty heti.
Saatko talletettua pumpun ottotehoa niin voisi katsoa ottotehon ja deltaT:n suhdetta ?

Hyvä tarkistaa...puhalluslämmön tasaisuudesta voisi olettaa ettei ottoteho paljoa piikkaile.

Vahva veikkaus että ln ulkolämpötilan raja sulatusluvalle sama +3 C niin kuin edeltäjissä

Omien kokemusten perusteella kenno ei ole kevyessä huurussa vaan tasaisen valkoinen ja tosi paksussa kuurassa/lumessa jos dt on 7 c ja ottoteho pieni

Sulatus myös todella nopea ollakseen tukkoisen kennon sulatus

 

[puu]

Ihan olematon määrä on viime päivinä ollut kennossa kuuraa pakkasenkin puolella. Koitan taas logitella tehoa jossain vaiheessa.

Koitinpa laittaa Mitsurunnerin lämpötila-antureille sample raten 1/s ja filtteriksi:
- exponential_moving_average:
alpha: 0.1
send_every: 10

Tuossa 21:52 paikkeilla nostin lämpötilapyynnin 31 asteeseen, puhalluksen jätin 4/5. Nyt deltaan (violetti) tuli pieni nousu yli 4°C, joka itsellä rajana sulatukselle, mutta se rauhoittui ajoissa takaisin alle rajan. Kennossa ei käytännössä kuuraa.

 

[puu]

Sain näköjään aiheutettua tilanteen, missä delta-T menee negatiiviseksi ihan lämmityksessäkin. Ensin nostin 21:52 pyyntilämmön täysille, ja sitten 22:08 tiputin 23 asteeseen. Delta-T (violetti) koukkasi selvästi niinuksen puolelle. Tuossa 22:27 paikkeilla tuli 2,5h pakkosulatus.

Tässä ottotehokäyrää. Meni tuossa välissä melkein nollille.

 

[Velsku]

Nyt on @puu :n kuvaama virhe korjattu ja logiikkaa paranneltu siten, että jos missä tahansa väärässä vaiheessa havaitaan laitteen menneen sulatukselle, logiikka resetoidaan, huijausvastus kytketään irti ja reset tilassa MitsuRunner päättelee missä tilassa laite oikein on ja toimii sen mukaisesti. Esim jos sulatus on päällä, niin se havaitsee sulatuksen päällä olon, eikä kytke huijausvastusta.

Samoin softa nyt tulostelee timereiden status tiedot, jotta voidaan päätellä toimiiko tilakone halutulla tavalla inputtejen perusteella.

Pakotettu aikasulatus oli myös rikki, jonka korjasin. Nyt sekin puskee käyrää, jotta tietää milloin se triggeroituu.

Eli kaikista ajastimista tulee nyt erillä viestillä timer tieto. Onko pois päältä, käynnissä vai suoritettu loppuun.

Muutokset vielä osittain branchissa, odottaa katselmointia. Mqtt timer status viestit mainissa.

 

[puu]

Nyt on @puu :n kuvaama virhe korjattu ja logiikkaa paranneltu siten, että jos missä tahansa väärässä vaiheessa havaitaan laitteen menneen sulatukselle, logiikka resetoidaan, huijausvastus kytketään irti ja reset tilassa MitsuRunner päättelee missä tilassa laite oikein on ja toimii sen mukaisesti. Esim jos sulatus on päällä, niin se havaitsee sulatuksen päällä olon, eikä kytke huijausvastusta.

Vaan mitenkäs juuri tuossa äskeisessä tapauksessa, missä delta meni miinukselle, vaikka oltiin lämmitysmoodissa?

 

[RauskiH]

Sain näköjään aiheutettua tilanteen, missä delta-T menee negatiiviseksi ihan lämmityksessäkin. Ensin nostin 21:52 pyyntilämmön täysille, ja sitten 22:08 tiputin 23 asteeseen. Delta-T (violetti) koukkasi selvästi niinuksen puolelle.

Tässä ottotehokäyrää. Meni tuossa välissä melkein nollille.

Meni katkolle

 

[Velsku]

Tuossa tapauksessa uudella logiikalla laite huomaa, että deltaT negatiivinen.
--> Resetoi statuksensa, vaikka on missä statuksessa.
Irroittaa sulatusvastuksen (eli jos pumppu haluaa sulattaa se sulattaa nyt, jos ei niin mitään ei tapahdu. )
Laite tutkii moodia ja jos negatiivinen edelleen käynnistää sulatusmoodin ja pitää vastuksen poissa oletetun sulatusajan ja käyttäytyy kuten sulatus olisi ollut.
Jos ei ole negatiivinen enää, niin palaa lämmitysmoodiin, kun sulatusmoodin timer on kulutunut.

Tuo voi olla vähän vaikea huomata, koska voidaan seurata vain tuota DeltaT lämpötilakäyrää.
Jotenkin siitä olisi pääteltävä virheellinen tila ja oikea sulatus.