MSZ-LN sulatushuijaus

[puu]

Lisäsin wikiin sivun kehitysalustan valinnasta ja varoituksen noista regulaattoreista. Käykääpä päivittämässä tuonne kokemuksianne hyvistä kehitysalustoista, ja mielellään muutakin infoa. Oikeasta reunasta vaan kynän kuvaa "edit page" ja ei kun kirjoittelemaan.

https://mitsurunner.com/doku.php?id=fi:board_selection

 

[iro]

Nyt kun laitoin tuohon käytössäolevaan Mitsurinner-Wemokseen tuon uptime-laskurin, niin kävi yhtäjaksoisesti 78,8 tuntia, eli lähes 3 vuorokautta ja 9 tuntia. Sitten teki kaksi resetiä vartin sisään. Ulkoista syytä reseteille ei logista näy, tapahtuivat lämmitysjakson keskellä ja RSSI vakaana -65...-65 dBm.

Joskus aiemmin todettiin, että nuo satunniset resetit -kerran pari vuorokaudessa- ovat Mitsurunnerin ominaisuus/omituisuus (kosmeettinen ongelma joka ei häiritse perustoimintaa). Oletko nyt huomannut että parempi wifi-singaali tai muut tekemäsi muutokset ovat vaikuttaneet reset-taajuuteen?

Perstuntumalta arvelen, että jos käytössä on "ei-viallinen" Wemos resetit eivät suoranaisesti johdu siitä , vaan ovat jotenkin kytköksissä sovellukseen jota siinä ajetaan. Jos oikein muistan niin joskus vertasin ESPHolme:lla ja C:llä tehtyä samanlaista lämpömittaussovellusta, ESPHome-sovellus resetoitui satunnaisesti, C-sovellus ei. Minulla on myös "tuotantakäytössä" kaksi sovellusta, joista jää aikaleima jos D1 Mini resetoituu. Nuo ovat pyörineet nyt yli kaksi vuotta eikä yhtään aiheetonta resettiä ole tapahtunut. Noihin on kytketty useita DS18B20 anturia melko pitkillä johdoilla, sähkönsä ne saavat tavallisesta USB-adapterista. Toisella noista rssi taso on alle -80dBm. Koodi on tehty C:llä.

 

[puu]

Juu onhan tuota täällä pähkäilty. Ei näytä olevan vaikutusta wifi-signaalin parannuksella tai muilla viimeaikojen muutoksilla. Yhtälailla on välillä mennyt useita päiviä putkeen tai saattanut tulla useampia resettejä lähekkäin.

 

[iro]

Voitanee siis palata normaaliin päiväjärjestykseen huomioiden pari asiaa:

1) Wemos on OK ellei siinä oleva LDO-piiri ole merkinnällä "4B2K". Jos kuitenkin sinulle osuu epävakaasti toimiva Wemos jossa on joku muu LDO-merkintä kuin "4B2K", ota ylös LDO-piirin päällä oleva merkintä ja raportoi se tänne.
Allolevan linkin kuva auttaa tunnistamaan LDO-piirin
https://lampopumput.info/foorumi/threads/msz-ln-sulatushuijaus.31223/page-25#post-565217

2) Mitsurunner laitteessa on ominaisuus resetoitua satunnaisin aikavälen max muutaman kerran vuorokaudessa. Hetkellisesti tämä vaikuttaa sulatushuijauksen jaksoihin, mutta kokonaistoimintaan sillä ei ole vaikutusta.

 

[Ka11e]

Kannattaa ainakin tarkistaa että sijaintimäärittelyt on oiken. Se taitaa vaikuttaa sisälämpöanturin kompensaatioon.
Eli vasen nurkka, oikea nurkka, käytävä.
Kaukosäätimessä näkyy viivoja laitteen kuvan ympärilla (siivekkeiden sivusuuntauskuvake?) sen mukaan mikä sijainti määritelty.

Tämä asetus on oikein.

 

[CheatTheMi]

@CheatTheMi You seem to have similar looking D1 Mini Pro as these that I have problems with. Are you able to check the print on the LDO regulator, that is the 5-pin chip labeled 4B2K in the picture in the earlier message. Did you have any problems with that board?

Unfortunately no. I am yet on a long travel for business and have no physical access to the things!

 

[puu]

I copied @CheatTheMi 's good instructions as initial english HW installation instructions in the wiki page. I hope that's okay. I (or someone else) will add some details later there.

MitsuRunner hardware build instructions [MitsuRunner]

mitsurunner.com

 

[Velsku]

Nyt seurannut mitsurunnerin logeja ja huomannut, että ei tämäkään systeemi ole täydellinen, vaikka likellä hipookin. Sitä voi vielä optimoida ottamalla pumpun toimintaa huomioon enemmän.

Mitsurunner mittaa käytännössä kennon kautta nesteeseen siirtyvän energian määrää. Eli ulkolämpötilan ja kennon läpi virtaavan nesteen lämpötilojen erotusta. Kun kompressori puskee kylmää nestettä kennoon, kenno joko kykenee lämmittämään sen ilmavirralla. (Tai sitten ei enää)

Koska lämmittäminen tapahtuu ilmavirralla, niin kennon jäätyminen tukkii kennoa, eikä ilmavirta enää riitä lämmittämään nestettä.
--> Tästä johtuu DeltaT:n kasvaminen. Kennosta tulee kylmempää ja kylmempää nestettä läpi. "Kenno on jäätynyt tukkoon". Ja kun DeltaT on riittävän kauan ylitse tresholdin, niin silloin liipaistaan sulatus, koska "kenno on jäässä".

Tämä ei ihan täydellinen ole joka tilanteessa ja johtaa ylimääräisiin sulatuksiin joskus:
Lämmitettäessä (kun pumpun tuottama energia riittää), niin pumppu säätää lämmitystehoa. Lämmön noustessa korkeammalle sisällä, pumppu pudottaa tehoa ja HIDASTAA ulkoyksikön kennon flektiä.
--> Tehokäyrässä näkyy "Tehon lasku" (ei pumpata enää niin paljon, kompressori vie vähemmän).

Samalla pumppu myös laskee ulkoyksikön puhaltimen nopeutta. (Koska kennon ei tarvitse siirtää niin paljoa lämpöä.)
--> Tämä johtaa pienemmän ilmavirran menemisen kennon läpi (vrt. jäätyminen) joka taas johtaa kennon läpi menevän nesteen kylmenemiseen. Mutta rootcause ei olekaan nyt kertynyt jää, vaan flektin pienentyneet kierrokset.

Riippuen mitsurunnerin parametreistä, ulkolämpötilasta, tehontarpeesta, säästä, auringonpilkuista... Tuo johtaa joskus tilanteisiin, joissa tehontarve pienenee ja mitsurunner triggeröi kasvaneen DeltaT:n takia sulatuksen... Eli tekee sulatuksen, vaikka kennossa ei ole jäätä, vaan ilmavirtaa hidastaa pumpun ulkoyksikön logiikka, jolla se pienentää puhaltimen nopeutta. Eli ilmaa menee tarkoituksella vähemmän kennon läpi.

Toki pumppu ei ole kokonaisuutena niin tyhmä, kuin tehdastekoinen sulatusalgoritmi. Pumppu seuraa myös itse omilla antureillaan, kennon lämmönsiirtokykyä ja tilanteissa, joissa hidastettu tuuletin vähentää liikaa kennosta saatavaa tehoa (näkyy DeltaT kasvamisena) se lähtee nostamaan uudelleen kierroksia. Eli DeltaT nousee vain tilapäisesti, jos kenno on yhä kykenevä siirtämään lämpöä.
--> Tuo tilapäisyys joskus sitten ylittää tresholdit mitsurunnerissa, mutta sitä voidaan käyttää myös optimoimaan toimintaa.

Kaksi ajatusta:

1. Flektin anturointi, eli aistitaan johtuuko DeltaT kasvamisen aiheuttanut ilmavirran hidastuminen
   • Flektin kierrosnopeuden pienemisestä johtumisesta ilmavirran hidastumisesta vai
   • Kennon jäätymisestä estäen ilmavirtaa
   • Vaatii laitteen avaamisen ja uuden anturin asentelun... yms.
     
     • "Täydellinen ratkaisu", mutta tämä on iso miinus
2. Seuraamalla käyrää ja päättelemällä siitä asioita:
   • Kenno jäätyy, koska tilanne huononee koko ajan --> DeltaT kasvaa selkeästi ajanyli
     • Flektin nopeutuksella ei pumppu onnistu saamaan DeltaT:tä enää alas
   • Laite säätää flektin nopeutta, koska DeltaT ei toimikaan, kuten jäätyessä (eli kasva koko ajan)
     • DeltaT:n kasvaessa, laite siis lisää puhallusnopeutta itse ja saa DeltaT:n pienenemään takaisin hyväksytyksi
       • Mikäli kenno tukossa, tuokaan ei auta, vaan DeltaT jatkaa kasvuaan, eli laite lisää puhallusnopeutta kunnes ei voi enää lisätä ja DeltaT jatkaa kasvua.
     • Derivoimalla DeltaT:tä saadaan tieto, onko DeltaT kasvamassa, vai oliko tilanne vain pumpun omaa säätölogiikkaa
       • Ei vaadi mitään aturointia, algoritmia vain päivitettävä
       • Lisäilen tämän omaan pumppuuni ja optimoin algoritmia

Kyseessä on siis pumpun optimointi. Logiikka toimii jo tosi hyvin, mutta turhat sulatuksen on aina turhia. Ja tuolla algoritmin muutoksella pyrin paremmin arvioimaan DeltaT:n kasvun juurisyyn, "Umpeenjäätyminen" vai "Puhalluksen pienentyminen".

 

[janti]

Oliko tuolle DeltaT jotain "viivästysehtoa" nyt? Esim. 3 min DeltaT > 8 C
Aikaa pidentämällä pystyisi varmaankin no turhat sulatukset välttää.

Esimerkkiä voisi ottaa vanhan Panan sulatusalgoritmista, toisaalta tuossa ei ollut muuttuvanopeuksista ulkoyksikön puhallinta.

E9DKE/E12DKE Sulatuslogiikka

Tutkin hieman tarkemmin Service Manuaalia tuon sulatuslogiikan osalta. Tästä sulatuksen anatomiasta on silloin tällöin poimintoja ollutkin täällä, mutta koitan tähän kirjata sulatukseen johtavat syyt ja sulatuksen kulun mahd. tarkkaan. Suomennos on omani ja en takaa 100% sen oikeellisuutta...

lampopumput.info

 

[Velsku]

On aika, mutta juuri tuon muuttuvanopeuksisen ulkoyksikön mukaan mikä tahansa "aika tai lämpötilaraja" ei ota huomioon DeltaT kasvun juurisyytä. Joka voi olla jäätyminen tai puhaltimen hidastuminen.

 

[iro]

Niksi_Pirkka vihje.Asentamalla ja konfiguroimalla Android-laitteeseen mqtt-client sovellus (esim. IoT MQTT Panel ) voit helposti seurata Mitsurunnerin IoT-Gurulle lähettämiä tietoja (nykytila, ei historiaa) ilman että tarvitsee kirjautua Web-selaimella IoT-Guru sivuille.

 

[iro]

Jatkoidea edelliseen... mqtt-serverin kautta olisi mahdollista säätää Mitsurunnerin parametreja "lennosta" ja/tai lähettää sille muita ohjauskomentoja. Tuolle ei taida kuitenkaan olla niin suurta tarvetta että kannattaisi alkaa toteuttamaan.

 

[Velsku]

Jatkoidea edelliseen... mqtt-serverin kautta olisi mahdollista säätää Mitsurunnerin parametreja "lennosta" ja/tai lähettää sille muita ohjauskomentoja. Tuolle ei taida kuitenkaan olla niin suurta tarvetta että kannattaisi alkaa toteuttamaan.

Samaa tässä algoritmin toimintaa käyriä katsoessa mietin. Ehkä tätä kautta joskus tullaan toteuttamaan "pakkosulatus", saapa nähdä... Hyvin toimii jo nyt ja mulla on jo pumppu varustettu logiikalla, joka ottaa huomioon ulkoyksikön kierrosnopeuden vaihteluita tällä logiikalla:

Kun DeltaT lämpötila ylittää rajan (kenno ei siirrä lämpöä enää riittävästi, tukossa tai puhallus pienemmällä)
--> Käynnistyy ajastin, joka laukaisee sulatuksen jos lämpötila ei putoa takaisin ajastimen aikana.

Ajastimen päättyessä, tarkistetaan, onko viimeisin mitattu DeltaT (kennon läpivirtaavan nesteen vs. Ulkolämpötila) pienempi kuin yksikään viimeisen Y min (2.5min nyt) aikana mitattu DeltaT (säädettävä aika). --> Eli onko lämpötila on menossa alaspäin

1. Jos Lämpötila menossa alaspäin:
   • Käynnistetään uusi timer, jolla odotetaan vielä aika X, jos lämpötila laskisi Tresholdin alle (eli pumppu saa tuulettimen kierroksia kohottamalla tehoa irti
     • Jos DeltaT laskee alle tresholdin, niin mennään takaisin idle tilaan odottamaan sen ylitystä.
     • Jos DeltaT ei laske alle tresholdin, käynnistetään sulatus joka tapauksessa timerin päätyttyä,
       • Koska vaikka pumppu lisää tuuletusta, niin se ei enää riitä huurteisesta kennosta johtuen siirtämään lämpöä nesteeseen.
2. Jos lämpötila ei ole menossa alaspäin:
   • Käynnistetään sulatus, sillä kenno on menossa tukkoon. Pumppu ei saa enää kennosta irti lämpöä vaan tilanne pahenee.

.

 

[puu]

Tällainen vertailu Wemos-klooneista tuli vastaan. Näköjään noita regulaattoreita on laitettu 150 ja 500 mA väliltä. Ilmeisesti osassa laudoissa voi toimiakin tuo heikompi regu mutta jostakin varoitellaan:

GitHub - bbqkees/Wemos-the-Clone-Wars: List of Wemos and other ESP8266 clone boards

List of Wemos and other ESP8266 clone boards. Contribute to bbqkees/Wemos-the-Clone-Wars development by creating an account on GitHub.

github.com

 

[Velsku]

Tällainen vertailu Wemos-klooneista tuli vastaan. Näköjään noita regulaattoreita on laitettu 150 ja 500 mA väliltä. Ilmeisesti osassa laudoissa voi toimiakin tuo heikompi regu mutta jostakin varoitellaan:

GitHub - bbqkees/Wemos-the-Clone-Wars: List of Wemos and other ESP8266 clone boards

List of Wemos and other ESP8266 clone boards. Contribute to bbqkees/Wemos-the-Clone-Wars development by creating an account on GitHub.

github.com

ESP8266 speksattu kulutus tietyn wifin kanssa on 170mA, joka ei ole edes piikkikulutus tai erikoisemman tilanteen vaatima kulutus, vaan "nominal". Joten 150mA regulaattori on kyllä ihan alimitoitettu ja johtunee vain käyttötapauksesta/testausympäristöstä kun näyttää toimivan. Toisessa ympäristössä/tapauksessa ei sitten toimi.

 

[puu]

ESP8266 speksattu kulutus tietyn wifin kanssa on 170mA, joka ei ole edes piikkikulutus tai erikoisemman tilanteen vaatima kulutus, vaan "nominal". Joten 150mA regulaattori on kyllä ihan alimitoitettu ja johtunee vain käyttötapauksesta/testausympäristöstä kun näyttää toimivan. Toisessa ympäristössä/tapauksessa ei sitten toimi.

Tuolla on joku noita mittaillut. "Wifi connected" -tilassa mitattu 70 - 110 mA virtoja. Joka tapauksessa se menee jo lähelle tuota 150mA, joka varmasti ylittyy piikeissä. Voi olla että joillain malleilla tulee noita resetejä helpommin huonommalla wifi-yhteydellä, kun lähetystehoa joudutaan nostamaan, niin tulee isompia virtapiikkejä.

Wemos D1 mini clones sleep mode power consumption

 

[Velsku]

Joo, tuo mittailu vastaa sitä tilannetta jossa se on mitattu sillä wifi protokollalla joka ollut käytössä. Josta syystä joku kiinassa on voinutkin päätyä johtopäätökseen; "ei haittaa vaikka laitetaankin 150mA regulaattori".

Datasheet speksaa pahimmillaan tuolle 170mA 50% duty cyclellä, joka sekin voi olla jossain tilanteessa suurempi ja kulutus isompi. Joten kyllä tuo kiinanpoikien keksintö laittaa 150mA todennäköisesti aiheuttaa epästabiliutta joissain use caseissa... ja joissain ei.

Tässä muuten ESP8266 datasheet kiinnostuneille:

• https://www.espressif.com/sites/default/files/documentation/0a-esp8266ex_datasheet_en.pdf

 

[Velsku]

Ollaan tässä taustalla kehitelty yhdessä @puu kanssa tätä vähän eteenpäin. Eli hiottu algoritmiä, koska plussakeleillä tulee ylimääräisiä sulatuksia ja on joitain erikois tilanteita, joissa ylimääräinen sulatus voi myös triggaantua. (eli delta T kasvaa, laskeakseen myöhemmin alas). Optimointia siis, eli perusalgoritmilla huijaus toimii jo riittävän hyvin, mutta se ylimääräinen sulatus on ylimääräinen... (vaikkei aiheuta talon jähtymistä, eikä juuri kuluta enempää sähköäkään).

Uusimpiin sourceihin githubissa on tehty ensimmäinen versio, jossa sulatus saa jatkoaikaa, jos DeltaT on menossa alaspäin. @puu on tehnyt omaan softahaaraansa integrointiin perustuvan päättelyn myös, joka parantaa tilannetta. Minä ajan nyt testinä algoritmia, jossa yksinkertaistettuna DeltaT:n huippu pitää ylittää uudelleen, ennenkuin sulatus käynnistyy, mikäli DeltaT on laskulla huipustansa.

 

[puu]

Nyt taas elämä hymyilee kun on aitoja Lolin D1 Mini -lautoja eikä noita susia missä oli moporegulaattori. Tässä 4.0.0 versiossa on näköjään USB-C-liitin. Muutenkin laatu huokuu ihan eri tavalla.

EDIT: Tuolta siis tilasin. Kuvaus sanoo noiden olevan 3.1.0 mutta 4.0.0 versioita tosiaan tuli. Samalta myyjältä tilasin myös nuo huonot kloonit, joista palautti rahat mukisematta. Hyvä asiakaspalvelu tuolla tuntuisi olevan. Voin suositella.

Original Lolin WeMos D1 Mini v4.0 - Arduino NodeMcu WIFI ESP8266 Dev Kit Board | eBay UK

Original 100% WEMOS LOLIN – ESP8266 D1 Mini ESP-12 Wifi Board. Das Original in Version 3.1.0 (kein China Nachbau!). Durch seine 100%ige Arduino IDE Kompatibilität ist die Programmierung super einfach und macht Spaß!

www.ebay.co.uk

LDO-regulaattorissa on merkintä "S2VD":

Myös mukana tulevat piikkirimat olivat asiallisempia (kuvassa vasemmanpuoleiset) kuin noiden kloonien mukana tulleet (kuvassa oik.). Nuo oikeanpuoleiset ovat aika ohuita toisessa suunnassa, ja tuntui etteivät saaneet kunnon kontaktia:

 

[puu]

GitHubissa on nyt ensimmäinen "virallinen" release versionumerolla v0.9. Tuolta oikealta löytyy nuo releaset kuvan mukaisesti. Eli tuo on nyt jäädytetty eikä siihen tule enää muutoksia. Tuossa ei ole mukana näitä mun ja @Velsku :n viimeisiä hienosäätämisiä, vaan yksinkertainen lämpötila-delta-rajan ylityksen aikaan perustuva sulatuksen liipaisu.

Tarkoituksena on julkaista versio 1.0. kun saadaan sopiva hienosäätö tuohon. Tuo v0.9 on siis käytännössä sama tuttu mikä siellä on ollut jo yli vuoden päivät.

 

[iro]

Tarkoituksena on julkaista versio 1.0. kun saadaan sopiva hienosäätö tuohon.

Kun viimeistelette hienosäätöjä niin käykää kokonaisuus läpi myös siitä näkövinkkelistä että toiminta sietää pumppu- ja/tai anturiontikohtaisia eroja ( ei lisää sumeaa logikkaa).

 

[Velsku]

Me lähdetään siitä, että kun ostaa esim. Dallas lämpötila-antruin, niin se näyttää riittävän oikeaa lukua (tarkkoja ovat). Eli emme ala hienosäätämään dallasantureiden (joita emme edes näe) tarkkuutta tai väärin asennusta softan kautta. Ja jos värkki asennetaan meidän ohjeilla, niin Dallas mittaa oikeasta paikasta lämpöä ja sen mukaisesti toimii sitten default asetuksessa hyvin.

Pumppu ja anturikohtaiset erot on niin pieniä, ettei niistä tarvite huolehtia kunhan seuraa ohjeita. Ja ne jotka haluavat, niin githubista ohjeet, sorsat + säätö käyntiin

ps.
1.0 versioon tulee ja toteutettu jo muutama uusi ominaisuus

• MQTT:llä aktivoitava kaksitasoinen "toivesulatus" (Pakkosulatus):
  • "Normaali sulatus", eli pumppu päättää itse milloin sulatus on valmis
  • "Maksimi sulatus", eli huijausvastuksella pidetään sulatus aktiivisena niin kauan, kuin pumpun oma maksimiaika sallii
• Parannettu sulatustarpeen päätttelyn logiikka, Tresholdin ylityksen ja maksimiajan lisäksi muutakin päättelyä
• Tapahtuneen sulatuksen keston raportointi MQTT:llä
  • Mahdollisesti myös lämmitysajan kesto.... (Saas nähdä jaksaako )

 

[iro]

Ja jos värkki asennetaan meidän ohjeilla, niin Dallas mittaa oikeasta paikasta lämpöä

DS18B20 tarkkuus epäilemättä riittää. Anturiontiin liittyvä ajatus tuli siitä kun tunnetusti eräässä toisessa säikeessä on runsaasti keskustelua pumpun oman defrost-anturin kastumisen/jäättymisen/ oikean sijoittelun vaikutuksesta sulatuksiin.

 

[Velsku]

Meillä on sensoroitu pumput aika monesta pisteestä ja jotkut mittauspisteet vaikuttaa paremmilta, kuin toiset. Tutkitaan seuraavana jos paras/soveltuva paikka anturoida olisi ihan Mitsubisin oma paikka. Ja jos vaikuttaa, että sillä saa algoritmin säädettyä toimimaan hyvin, niin sinne se ohjeistetaan. Tällöin koko mitsurunnerin asennuksesta tulee paljon helpompaa, kun ei tarvitse availla laitetta niin paljon. Etulereunaa raottaa/poistaa, johtojen suoja pois sivulta ja katto pois, niin taitaa pystyä jo täysin asentamaan. Kastuneista huovista, originaalin sulatusanturin paikasta yms. ei tarvitse välittää mitsurunnerin kanssa. (nehän johtaa liian pitkiin sulatuksiin -> mitsun logiikalla lyhenevään lämmitysaikaan ja hullunkiertoon, joka tällä estetään)

 

[RauskiH]

Kastuneista huovista, originaalin sulatusanturin paikasta yms. ei tarvitse välittää mitsurunnerin kanssa. (nehän johtaa liian pitkiin sulatuksiin -> mitsun logiikalla lyhenevään lämmitysaikaan ja hullunkiertoon, joka tällä estetään)

Tästä olen vähän eri mieltä... Jos sulatusanturi on jäässä niin pumppu tekee silloin aina maksimimittaisen sulatuksen, tarvi sitä tai ei. Tämä ei nyt itse runnerin toimintaa sinänsä pilaa mutta turha sitä on yrittää ulkoilmaa lämmittää ja samalla omaa mökkiä jäähdyttää. Ja vaikuttaahan tämä myös vähän coppiin ja maksimi lämmitystehoonkin

 

[Velsku]

@RauskiH : lähes oikeassa olet.

Tässä on muutama asia, josta syystä sanon, että originaali sulatuspaikasta ei tarvitse välittää:

1. Tavoitteena on tehdä sellainen setti, joka ei heti kättelyssä pelota 80% ongelmasta kärsijöistä pois, näitä on aivan liian vähän käytössä ihmisillä. Suurin syy, että tätä ei ole tuotteistettu ja tehty riittävän helpoksi, joten:
   • Asentamisen helppous tärkeää:
     • Muiden antureiden siirtely ja eristys tekee hommasta vaikean näköistä
     • Koko koneen purku, sähköjohtojen irroituksineen --> pelottavaa
     • Isompi työmäärä --> "tuossahan menee päivä, ei jouda"
2. Isoiten modaamaton sulatusanturi jäätyneen huovan kanssa vaikuttaa siihen että sulatuksesta tulee pidempi(ei välttämättä siis maksimisulatusta) ja se riittää ohjaamaan oman algoritmin tekemään aina vain lyhyemmän lämmitysjakson (lämmitysjakson lyhentäminen ei vaadi maksimisulatusta).
   • Tässä linkki vanhaan analyysiin, jonka tein: Analyysiä sulatusajan vaikutuksesta lämmitysjakson pituuteen
   • Valitettavasti mulla on tuhoutunut tietokanta ajalta, jolloin mulla oli huopa jäässä ja anturi orkkispaikassa, eli en tarkalleen voi sanoa kuinka paljon sulatukset piteni tapauksessa, mutta sen ne vaikutti, että ne ajoi lämmitysjaksot lyhyksi, koska mitsun algoritmi on mitä on . Varmasti täältä jostain historiasta löytyy tuo tieto, oliko sulatus aina maksimimittainen.
   • --> Huovan jäätymisellä on merkitystä, mutta ei niin dramaattista ettei Mitsurunnerista olisi jo aivan valtavaa apua.
3. Kaikilla ei ole huopa jäässä --> Heille ei edes merkitystä siirrellä
   • Anturin siirto ja eristäminen lyhentää sulatusta, mutta Mitsurunnerin kanssa : "normimittainen sulatus kuivalla huovalla, orkkispaikassa" vs. "siirretty ja eristetty" --> 120min lämmitysaika ja "minuuttia" pidempi sulatusaika optimoinnilla, joten ei laskettavaa vaikutusta mihinkään...
4. Me, joita antureiden siirtely ja eristys ei pelota ja halutaan optimoida saadaan edelleen tehdä niin.
   • Eli vaikka meidän jopa kannattaa niin tehdä, kun osataan, niin silllä haetaan optimointia, suurin osa hyödystä saavutetaan jo ilmankin.

 

[puu]

Tästä olen vähän eri mieltä... Jos sulatusanturi on jäässä niin pumppu tekee silloin aina maksimimittaisen sulatuksen, tarvi sitä tai ei. Tämä ei nyt itse runnerin toimintaa sinänsä pilaa mutta turha sitä on yrittää ulkoilmaa lämmittää ja samalla omaa mökkiä jäähdyttää. Ja vaikuttaahan tämä myös vähän coppiin ja maksimi lämmitystehoonkin

En usko että maksimaalista sulatusta tekee vaikka anturi olisi jäässä. Itselläni on välillä tuo ulkolämpötila-anturi ollut jään peittämä, eikä ole juurikaan vaikuttanut edes tuohon mittaukseen, vaikka siinä mitataan vain ympäröivän ilman lämpötilaa.

Sitten vielä kun anturi on kylmäaineputkessa kiinni, niin kyllähän se hyvin reagoi sen lämpötilojen vaihteluun. Ei varmastikaan edes minuutilla kasvata sulatusaikaa. Toki Mitsun omassa algoritmissä voi olla kyse jopa sekunneista, lähdetäänkö pidentämään vai lyhentämään sulatusaikaa.

Tuolla aikanaa kirjoittelin jo tuosta ulkolämpötila-anturin immuniteetistä jäälle:

MSZ-LN sulatushuijaus

Kiitos, kaveri suositteli tämmöistä sulatuskaapelin ohjaukseen. Oli vaikea löytää relettä 3v ohjausjännitteellä joka olisi turvallinen verkkovirralle. Normi rele sitten ohjaisi sitä huijausvastusta...

lampopumput.info

 

[puu]

Kyllähän tietyissä olosuhteissa on selvästi eroa mistä kohtaa kylmäaineputkistoa mittaa kennon lämpötilaa. Kuvassa pinkki mittaa ihan alimmasta putkesta, voletti sulatusanturin alkuperäiseltä paikalta ja punainen ylempää putkista. Täällä kuvia antureiden sijainnista.

Tuo alin putki tosiaan näyttäisi tähän mennessä sikäli parhaalta paikalta, että siinä ei tule tuollaisia ylimääräisiä notkahduksia mitä saattaa tulla pumpun laskiessa tehoja. Lämpötiladeltan liipaisuraja pitää vaan sitten säätää anturin sijoituksen mukaiseksi. Tuo on keskimäärin vähän kylmepi kuin esim. vakiosulatusanturin paikalta mitattu.

Alin putki siis tuo pystysuora (kuvaajasa pinkki), alkuperäinen sulatusanturin paikka taas on tuo vinoputki (kuvaajassa violetti).

 

[iro]

Mitsurunner /IoT-Guru

Mitsurunner ohjeissa on neuvottu IoT-Guru konfigurointi ja IoT-Guru parametrien määrittely platform.yaml-koodiin. Tuo ohje ei kuitenkaan kerro mitä pitää tehdä jos aiot laittaa useampia Mitsurunnereita (tai loggereita tai mqtt_client'eja) lähettämään/pyytämään tietoja IoT-Guruun.
On huomioitava että mqtt-protokolla vaatii jokaiselle yhteyttä muodostavalle laitteelle omaa yksilöllistä tunnusta. ==> Jokaiselle IoT-Guruun liitettävälle laitteille on IoT-Guruun määriteltävä oma "Device" ja allamainitut IoT-Gurun määrittelemät parametrit on määriteltävä (=kopioitava IoT-Gurusta) liitettävälle laitteelle.
* user short identifier ==> User name
* device short identifier ==> Client_id
* device key ==> Password


Raportoitavat kohteet määritellään IoT-Gurussa "Device"/"Node"/"Field" rakenteilla
Mitsurunner-ohjeessa (yksi Mitsurunner) on neuvottu allaoleva rakenne
Device: Mitsurunner1
..Node: Alakerta
....Field: Delta
....Field: Ulkolämpö
.........

Usemman laitteen tapauksessa täytyy jokaiselle laitteele määritellä oma "Device" IoT-Guruun.
Device: Mitsurunner2
..Node: Yläkerta
....Field: Delta
....Field: Ulkolämpö
.........

(
Device: Logger1:
..Node: Kylpyhuone
....Field: Lämpö
....Field: Kosteus
)

IoT-Guru sallii raporttien lähettämisen myös toiselle "Device"lle. Näinollen IoT-Guru rakenne voidaan tehdä myös niin että yhden "Device"n alle ei määritellä mitään ja kaikki raoprtointi tehdään toiselle "Device"lle (graafien selaaminen vaatii tällöin vähemmän klikkauksia)

Device: Mitsurunner1

Device: Mitsurunner2
..Node: Alakerta
....Field: Delta
....Field: Ulkolämpö
.......
..Node: Yläkerta
....Field: Delta
....Field: Ulkolämpö
....

 

[haraldh]

Kokeilin tuota iotgurun mqtt palvelinta. Lähetin skriptillä vähän json muotoista dataa samalla kuunnellen samaa kanavaa. Vain murtoosa viesteistä tuli läpi. Mitähän tein väärin?

 

[iro]

Miten "kuuntelit" ? Jos käytit MQTT Exploreria tai MQTT-client'ia niin noille pitää määritellä IoT-Guruun oma "Device". Jos käyttää samaa "Device"ä uudempi mqtt-yhteyspyyntö katkaisee nykyisen session.

 

[haraldh]

mosquitto_sub ohjelma. Pitää tarkastaa millä vivuilla sitä ajoin, melko varmasti samalla device:lla.

 

[iro]

Minä käytän MQTT-Exploreria, oman kokemukseni mukaan tuo on helppokäytöinen ja informatiivinen työkalu seurata ja testata mqtt-toimintoja. Lisäksi kun asentaa Androidiin mqtt-client-sovelluksen (esim IoT MQTT Panel) niin voi näppärästi simuloida viestien välitystä ilman ylimääräistä rautaa.

 

[puu]

Mitsurunner /IoT-Guru

Laita vaan mielellään suoraan tuonne wikiin näitä hyviä ohjeitasi. Sieltä ne löytyvät helpommin. Kopioin nyt tuonkin jatkoksi tuonne wikin IoT-GURU-ohjeisiin:

https://mitsurunner.com/doku.php?id=fi:iot_guru

 

[Rh-]

Yksi GuruTlogger taas lisää tulilla, pientä ihmettelyä aiheutti väärästä pussista otetut anturit, eräässä 10kpl kiinan tilauksessa tuli koko nippu antureja joilla sama id, ja enhän mää tuota muistanut.....

 

[iro]

@Rh- ,hienoa että sait ongelman ratkaistua.
Ja tässä Niksi-Pirkka vihje: Kytkemällä anturit eri nastoihin ei id:llä ole merkitystä

 

[Rh-]

@Rh- ,hienoa että sait ongelman ratkaistua.
Ja tässä Niksi-Pirkka vihje: Kytkemällä anturit eri nastoihin ei id:llä ole merkitystä

Sanoppa muuta, tuli vaan nyt noin hoidettua tuo.

 

[CheatTheMi]

"Cold" weather (0 to -3°C), snow all night long and very humid air. after three hours of heating, the cell was blocked, but defrosted completely.

Mitsurunner is working great, even in those conditions! No issues at all, due to the WiFi RSSi Topic.

Just one question / improvement idea about Mitsurunner. Is there a way, to implement an option, that it is sending of each value 1 time a month, data to IOT Guru?
If the Mitsurunner isn't in action, during summer time or just because it doesn't send any data, it is deleting those topics on IOTGuru, after one month of inactivity.

Getting sometimes those emails:
"Inactive node removed: topic_start_defrosting_t"

Then I have to create it one time a month new, flash it to the devices again etc., quite uncomfortable.

 

[iro]

Mitsurunner is working great, even in those conditions! No issues at all, due to the WiFi RSSi Topic.

Just one question / improvement idea about Mitsurunner. Is there a way, to implement an option, that it is sending of each value 1 time a month, data to IOT Guru?
If the Mitsurunner isn't in action, during summer time or just because it doesn't send any data, it is deleting those topics on IOTGuru, after one month of inactivity.

i see the problem...
Mitsurunner will send "timer-status_report" only to the mqtt topic of current status, if status is "idle", "timer-status_report" is sent . In summer-time, Mitsurunner is always "idle" ==> "timer status reports" are not sent at all ==> IoT-Guru removes inactive topics.

I am not sure if this will work, but I think it is possible to create a new identical topic (=Field) to IoT-Guru if some topic (=Field) is deleted.

 

[arimika]

Yksi GuruTlogger taas lisää tulilla, pientä ihmettelyä aiheutti väärästä pussista otetut anturit, eräässä 10kpl kiinan tilauksessa tuli koko nippu antureja joilla sama id, ja enhän mää tuota muistanut.....

Miten toteutit tuon. Ihan kysyn jos kiinnotaa muitakin .

@Rh- ,hienoa että sait ongelman ratkaistua.
Ja tässä Niksi-Pirkka vihje: Kytkemällä anturit eri nastoihin ei id:llä ole merkitystä

Täähän olis ollut vaihtoehtonen tapa