ByTheBook-toteutus olisi tietysti ohjata relettä vain muutostilanteessa. Päädyin kuitenkin tähän ratkaisuun jotta bistabiili rele ohjautuu oikeaan tilaan (myös bootin jälkeen) ilman muutoksia muualle koodiin.
MSZ-LN sulatushuijaus
- Viestiketjun aloittaja iro
- Aloituspäivämäärä
Oma mitsurunneri tuli tiensä päähän. Releen kelan takapotkut tappoivat pinnin ESP:stä.
Tähän kannattaisi miettiä fettiä ajaan vaikka voltista ja diodia suojaan noilta potkuilta.
Oikea ongelmani on kuitenkin toinen. Minulla on kaksi yksikköä pihalla vierekkäin ja ajattelin jos huijaisi niitä samalla laitteella.
Raudan puolesta tulisi toinen ohjausliitin ja rele.
Ainoa mitä en vielä keksinyt, tapiuisiko tuo mitsurunneri helposti kahteen instanssiin? Osaisiko joku perehtyneempi valistaa?
Tähän kannattaisi miettiä fettiä ajaan vaikka voltista ja diodia suojaan noilta potkuilta.
Oikea ongelmani on kuitenkin toinen. Minulla on kaksi yksikköä pihalla vierekkäin ja ajattelin jos huijaisi niitä samalla laitteella.
Raudan puolesta tulisi toinen ohjausliitin ja rele.
Ainoa mitä en vielä keksinyt, tapiuisiko tuo mitsurunneri helposti kahteen instanssiin? Osaisiko joku perehtyneempi valistaa?
Wemos:in päälle pinottavassa releessä on MOSFET ohjaamassa relettä.
https://www.wemos.cc/en/latest/_static/files/sch_relay_v2.0.0.pdf
Varmaankin tuo koodia puukottamalla olisi tehtävissä mutta näppituntumalta sanoisin että ei kannata. Yhteinen Mitsurunner myös yhdistäisi molempien pumppujen elektroniikan maa-tasot (GND) toisiinsa, tuostakin saattaa tulla häiriöitä tai muuta trabelia.
puu
Aktiivinen jäsen
Ja tuo 2N7002 sisältää suojadiodin:
Mikä on ideana ajaa kahta pumppua samalla Mitsurunnerilla? Hyötynä voisi ehkä olla se, että voisi ajoittaa niiden sulatukset eri aikaan. Tämänkin tekisin kuitenkin itse kahdella eri Mitsurunnerilla jotka viestisivät keskenään.
Sinänsähän Mitsurunner on galvaanisesti erotettu pumpun elektroniikan maasta, joten mielestäni tuota mainittua maaongelmaa ei pitäisi olla.
Joo, tuli joku ajatyskäpy,...ajattelin että pumppujen maat yhdistyvät huijausreleellä, mutta näinhän ei käy koska molemmille tulisi omat releet.
Tuo FETin mukana tuleva diodi on parasiittinen. Sitä kannattaa ajatella nähdessään, että älä nyt kytke tätä niin, että tämä johtaa.
Ja verratessani kuollutta relekorttiani tuohon kytkikseen voin todeta, että kortini on ottanut yhden kiinan kierroksen liikaa kun on säästetty kaikki muut pois paitsi hilan alasveto.
Taidan tosiaan jättää integraation välistä ja tilata uudet palikat ja keksiä sitten sopivan kokoisen kotelon. Voi olla ehkä mukavampi ratkaisu.
Ja verratessani kuollutta relekorttiani tuohon kytkikseen voin todeta, että kortini on ottanut yhden kiinan kierroksen liikaa kun on säästetty kaikki muut pois paitsi hilan alasveto.
Taidan tosiaan jättää integraation välistä ja tilata uudet palikat ja keksiä sitten sopivan kokoisen kotelon. Voi olla ehkä mukavampi ratkaisu.
puu
Aktiivinen jäsen
Seison korjattuna. Ei siis välttämättä huono idea lisätä tuohon flyback-diodi.
puu
Aktiivinen jäsen
Äh, niinhän se näkyy tuossa skemassakin ja näin nyt muistelen itsekin aikanaan todenneeni. Mitähän olen sekoillut aiemmissa kommenteissani.
Onnistuin katkaisemaan yhden DS18B20, ulkosensorin pinneisä kun putsailin äskön lumia pois.. Huonosti tähänkin asti tuo minun anturi tuolla on ollut, ihan ajankysymys ollut että koska näin käy.
Miten nyt eteenpäin, vaihtoehto1: Koitan jotenkin kolvailla tuon anturin pinnin takaisin kiinni siihen nysään, jos sieltä semmoista vielä löytyy, en ehitynyt nyt tuolla myräkässä asiaa tutkimaan tarkemmin.
Tai vaihtoehto2 vaihdan kokonaan uuden anturin. Jos joudun anturin vaihtamaan, miten sen saan tehtyä vähimmäillä vaivalla? Saanko jotenkin OTA yhteydellä kaivettua anturin osoitteen talteen kun olen sen kolvannut paikoilleen ja sitten muokattua softaa uudella koodilla? Toki saan tarvittaessa tökättyä tuon anturin johonkin muuhun vekottimeen täällä sisällä ja kaivettua sen osoitteen talteen..
btw, tulee bad gateway kun yritin mitsurunnerin sivuille mennä ohjeistusta lukemaan.
Miten nyt eteenpäin, vaihtoehto1: Koitan jotenkin kolvailla tuon anturin pinnin takaisin kiinni siihen nysään, jos sieltä semmoista vielä löytyy, en ehitynyt nyt tuolla myräkässä asiaa tutkimaan tarkemmin.
Tai vaihtoehto2 vaihdan kokonaan uuden anturin. Jos joudun anturin vaihtamaan, miten sen saan tehtyä vähimmäillä vaivalla? Saanko jotenkin OTA yhteydellä kaivettua anturin osoitteen talteen kun olen sen kolvannut paikoilleen ja sitten muokattua softaa uudella koodilla? Toki saan tarvittaessa tökättyä tuon anturin johonkin muuhun vekottimeen täällä sisällä ja kaivettua sen osoitteen talteen..
btw, tulee bad gateway kun yritin mitsurunnerin sivuille mennä ohjeistusta lukemaan.
Koitas tota: https://mitsurunner.com/doku.php?id=fi:start
Vanhan anturin korjaaminen tuskin onnistuu... uutta kehiin.
Jos käytät IoT_Gurua niin ID:n kaivaminen OTA-päivityksen jälkeen on hieman vaikeaa, mutta voit väliaikaisesti käyttää test.mosquitto.org -serveriä IoT-Gurun sijasta ==> saat Dallasin ID:n näytölle heti OTA-päivityksen jälkeen.
Alla tarvittava "comment" ja "uncomment# muutokset Secrets.yaml fileen.
Koodi:
#mqtt:
# broker: iotguru.cloud # known IPs of iotguru.cloud 116.203.207.226, 195.201.219.208
# id: mqtt_client
# username: t.....Q
# client_id: v......Q
# password: o...g
#
# topic_prefix: null # trace log is not send to IoT Guru server
# log_topic: null # no trace-logs over MQTT (function is not supported in IoT-Guru)
# discovery: false # HomeAssistant is not used
##### Mosquito MQTT for getting trace log without USB-connection ########
# Note: Only for testing
mqtt:
broker: test.mosquitto.org # known IP of test.mosquitto.org 91.121.93.94
id: mqtt_client
topic_prefix: $topic_heatexchanger
discovery: false # HomeAssistant is not usedEi oo Iot guru käytössä, mutta oma mqtt servu on joten näen kyllä nuo kaikki mitsurunnerin topicit.
Eli prosessi menee sitten seuraavasti: Uusi anturi paikalleen, sitten OTA update? Sen jälkeen pitäisi löytyä uusi osoite tästä nuolen osoittamasta kohdasta? Sen jälkeen sitten platform.yaml:liin muutos osoitteeseen kohtaan dallas_address_outdoor_temp ja OTA update uudestaan perään ?
Eli prosessi menee sitten seuraavasti: Uusi anturi paikalleen, sitten OTA update? Sen jälkeen pitäisi löytyä uusi osoite tästä nuolen osoittamasta kohdasta? Sen jälkeen sitten platform.yaml:liin muutos osoitteeseen kohtaan dallas_address_outdoor_temp ja OTA update uudestaan perään ?
En ole aivan varma mitä serverille menee jos anturille määriteltyä ID:tä ei löydy. Itse katson löydettyjen antureiden IDt näytöltä bootin logitiedoista OTA-flashayksen jälkeen. Tuo tieto kiertää MQTT-serverin kautta, joten se näkyy myös serverillä logi-topicissa.
Koodi:
[21:20:46][C][gpio.one_wire:021]: Pin: GPIO25
[21:20:47][C][gpio.one_wire:080]: Found devices:
[21:20:47][C][gpio.one_wire:082]: 0x8501191438ccd428 (DS18B20)
[21:20:47][C][gpio.one_wire:082]: 0x2dd4e3391e64ff28 (DS18B20)
[21:20:47][C][template.sensor:022]: Template Sensor 'State'
[21:20:47][C][template.sensor:022]: State Class: ''Jos/kun anturi-ID löytyvät MQTT-serverilta (joko anturi - tai logi-topikeista) niin niiden pitäisi näkyä anturivaihdon ja bootin jälkeen tarvitsematta OTA-flashaysta ==> uusi ID platform-fileen, OTA-flashays ja homma pelittää.
Korjatkaa jos olen väärässä, tuolla ei ole vaikutusta Mitsurunner-softaan.
En tiedä onko korjaamista, mutta minä ymmärsin muutoksen näin:
esphome:
name: mitsurunner
...
includes:
- constants.h
- state.h
Pitäisi muuttaa muotoon
external_components:
- source: components (riippuen polusta missä tiedostot sijaitsevat)
Ja tiedostot tuonne.
OK, kiitos vihjeestä. Helpoin tapa testata tuo lienee odottaa 2051.1.0 release ja kokeilla meneekö Mitsurunner käännös läpi. Yritän muistaa tehdä tuon.
veijolainen
Tulokas
Olen seuraillut tätä mitsurunner-keskustelua ja kehitystä pidemmän aikaa taustalla. Nyt ajattelin rohkaistua ja itsekin viritellä pumppua tehokkaammaksi tämän avulla. Softapuolelta on esphomesta jonkun verran kokemusta mutta rautapuoli on vieraampaa. Siihen liittyen pari kysymystä kun en ihan koko ketjua alkuajoista saakka kuitenkaan ole kahlannut läpi:
1. Vieläkö @puu tai joku muu täällä tekee adaptereita myyntiin? Jos kyllä niin voisin yhden ostaa.
2. Itsellä on Mitsun FH25 pumppu. Sopiiko adapteri (liittimet) FH25:een suoraan vai onko ne eri kuin LN:ssä? Entä adapterin 33k vastus, vai vaatiiko FH eri kokoisen vastuksen?
Kiitos jo etukäteen vastauksista ja pahoittelut jos kyselen tyhmiä..
1. Vieläkö @puu tai joku muu täällä tekee adaptereita myyntiin? Jos kyllä niin voisin yhden ostaa.
2. Itsellä on Mitsun FH25 pumppu. Sopiiko adapteri (liittimet) FH25:een suoraan vai onko ne eri kuin LN:ssä? Entä adapterin 33k vastus, vai vaatiiko FH eri kokoisen vastuksen?
Kiitos jo etukäteen vastauksista ja pahoittelut jos kyselen tyhmiä..
FH ja LN ovat identtiset tarvittavien komponenttien suhteen. Itsellänikin Puun adapteri käytössä sekä LN25 että FH35 pumpuissa.
Tämä on ehkä tyhmä kysymys mutta toimiihan mitsurunner standalonena eli ilman wifiä? Minulle on tulossa yksi mitsu ja yksi daikin. Onnistuuhan mitsurunnerin konffaus myös Linux-alustalla, windowsista pääsin eroon 20v sitten ja siihen en enää koske 
Komppaan muiden tulokkaiden kommentteja, ohjeet ja vinkit on ripoteltu ympäri keskusteluketjuja ja basic-jutut jotka täällä kauemmin olleille on päivänselviä on pitkien viestiketjujen selailun takana.
Komppaan muiden tulokkaiden kommentteja, ohjeet ja vinkit on ripoteltu ympäri keskusteluketjuja ja basic-jutut jotka täällä kauemmin olleille on päivänselviä on pitkien viestiketjujen selailun takana.
Viimeksi muokattu:
Ootko tuolla käväissy?
Linux-tietämykseni on tasoa tiedän sellaisen olevan ja kuka sen takana on, mutta uskoisin konffauksen siinä jollakin keinoin onnistuvan. Tietävämmät varmaan varmistaa tämän.
Mitsurunnerin perusversiossa on time-outit jotka resetoivat laitteen jos Wifi tai MQTT puuttuu yli 15 min ajan. Nuo on kyllä mahdollista disabloida, mutta takeita Mitsurunnerin luotettavasta toiminasta ei ole.Tämä on ehkä tyhmä kysymys mutta toimiihan mitsurunner standalonena eli ilman wifiä? Minulle on tulossa yksi mitsu ja yksi daikin. Onnistuuhan mitsurunnerin konffaus myös Linux-alustalla, windowsista pääsin eroon 20v sitten ja siihen en enää koske
Pienellä koodipuukotuksella Wifi-, ota- ja Web_server- ja MQTT-komponentit voidaan konfigurointivaiheessa jättää pois, hiukan enempi työtä vaatii poistaa muualta koodista kaikki MQTT-pyynnöt. Käsitykseni mukaan tuolloin Mitsurunnerin toiminnallisuus säilyy mutta ainoa tapa seurata toimintaa on USB-liitäntä.
Linux-ympäristöön ei osaa ottaa kantaa.
Ohjeita on pyritty kokoamaan Mitsurunner wikiin
MitsuRunner wiki page [MitsuRunner]
mitsurunner.com
Kiitos vastauksesta iro! Haluan mitsurunnerin standaloneksi koska wifi joka lämmityskohteessa on, tulee poistumaan. Jatkossa siis wifiä ei ole eikä tule.
Asennukseni tulee siis olemaan tyyliin kytke ja unohda. Laminoitu ohje laitteesta koteloon tai lähistölle. Luin että mitsurunner on toiminut vuosia murheitta niin siinä ajassa unohtuu paljon asioita, siksi laminoitu ohje. mitsurunnereita on tarkoitukseni tehdä 2kpl, toinen on varalla. Sähkönsyöttö on hämärä'n peitossa, saako ulkoyksiköstä ESP32:lle (minulla on noita useampi) käyttöjännitteen?
EDIT: Ahh, wikistä löytyikin vastaus poweriin
Asennukseni tulee siis olemaan tyyliin kytke ja unohda. Laminoitu ohje laitteesta koteloon tai lähistölle. Luin että mitsurunner on toiminut vuosia murheitta niin siinä ajassa unohtuu paljon asioita, siksi laminoitu ohje. mitsurunnereita on tarkoitukseni tehdä 2kpl, toinen on varalla. Sähkönsyöttö on hämärä'n peitossa, saako ulkoyksiköstä ESP32:lle (minulla on noita useampi) käyttöjännitteen?
EDIT: Ahh, wikistä löytyikin vastaus poweriin
Viimeksi muokattu:
puu
Aktiivinen jäsen
Itsehän kokeilin ensin ESPhomea Windowsissa, mutta totesin Linuxin helpommaksi. Olen käyttänyt sekä Ubuntulla että Raspberry Pi:n Debianilla. Raspilla teen käännöksen Dockerissa: https://esphome.io/guides/getting_started_command_line.html
Itselläni Dockerin kanssa ajokomento on seuraavanlainen:
Itselläni on Mitsurunnerin lähdekoodit RasPilla, mihin saan otettua SSH:lla etäyhteyden. Pääsen tällätavoin kätevästi etänä päivittämään Mitsurunnerin aina tarvittaessa.
Itselläni Dockerin kanssa ajokomento on seuraavanlainen:
docker run --rm -v /home/puu/mitsurunner:/config -it --privileged esphome/esphome run mitsurunner.yamlItselläni on Mitsurunnerin lähdekoodit RasPilla, mihin saan otettua SSH:lla etäyhteyden. Pääsen tällätavoin kätevästi etänä päivittämään Mitsurunnerin aina tarvittaessa.
Ohessa nopeasti väsätty Mitsurunner Stand-Alone versio. Tuosta siis poistettu Wifi-, MQTT, ota- ja Web-Server toiminnallisuudet.
Lisätty "monitor"-toiminnallisuus (onnistunut "heat_exchanger_temp" luku sytyttää Wemos on-board-LEDin, onnistunut "outdoor_temp" luku sammuttaa sen).
==> Oikein toimiessaan Mitsurunnerin LED vilkkuu (2,5 sek OFF/2,5 sek ON), virhetilassa LED on pysyvästi ON tai OFF tai vilkkuu epämääräisesti.
Testausvaihetta varten koodissa on mahdollisuus ottaa mukaan Wifi ja Web-server sekä Home Assitant poistamalla #-merkit ko. rivien alusta.
!! Koodi kääntyy ja pöytätestissä vaikuttaa toimivan, mutta en pysty testaamaan sitä todellisessa ympäristössä.
Varmista toiminnallisuus ennen kuin "unohdat".
PS, Kiitos Wiki-toteutuksesta kuuluu @puu :lle
puu
Aktiivinen jäsen
Olisi kätevä, jos tuon standalone-version saisi jollain yhdellä vivulla päälle pois käännöksestä. En vaan tiedä, miten sen saisi tehtyä näppärästi YAML:lla.
Talvi on selvästi tulossa, kun adapteritilauksia alkaa ripotella hiljaisemman jakson jälkeen. Tällä viikolla koitan saada taas erän tehtyä, niin että niitä jää joitakin myös varastoon.
Talvi on selvästi tulossa, kun adapteritilauksia alkaa ripotella hiljaisemman jakson jälkeen. Tällä viikolla koitan saada taas erän tehtyä, niin että niitä jää joitakin myös varastoon.
Mahtava juttu! Minulla on asennettuna RockPi4B:lle esphome ja muut kilkkeet. MitsuRunneriin tarvittavat komponentit on postipaten kyydissä tulossa joten vielä en pääse testaamaan. @puu :lta tilasinkin jo 2kpl adaptereita. Raportoin kyllä heti kun on HW:n osalta valmista ja kytkettynä RockPi:lle
Mitsurunnerista voisi (ehkä) pienellä työllä erottaa MQTT-osion erilleen kokoamalla raportoitavat tiedot muuttujin ja keskittämällä kaikki MQTT-jutut yhteen tiedostoon joka voidaan includata mukaa tai jättää pois. Myös HomeAssistant käyttäjät voisivat jättää tuo osoin pois. Samalla periaatteella Wifi jää pois kun secrets tiedoston jättää pois. Pohdin tuota hieman lisää...
Katselin tarvittavia muutoksia kuinka standalone versio saadaan mukaan perusversioon.
Kysymys @puu :lle allaolevassa koodissa samalle topicille lähetetään peräkkäin eri sanomat. Tuota on vaikea toteuttaa jos MQTT-sanomat lähetetään keskitetysti esim 60sek välein.
Koodi:
- id: schedule_forced_defrosting
mode: restart #timer will be restarted from the beginning allways when called --> starts always again
then:
- lambda: !lambda |-
id(mqtt_client).publish(id(G_TOPIC_FORCE_DEFROST_TIMER_STATE), to_string(TMR_NOT_PASSED)); // #To indicate restarts
id(mqtt_client).publish(id(G_TOPIC_FORCE_DEFROST_TIMER_STATE), to_string(TMR_RUNNING));
id(G_max_heating_time_passed) = false;
- delay: !lambda "return MAX_HEATING_TIME * 60000;"
- lambda: !lambda |-
id(mqtt_client).publish(id(G_TOPIC_FORCE_DEFROST_TIMER_STATE), to_string(TMR_PASSED));
id(G_max_heating_time_passed) = true;puu
Aktiivinen jäsen
60sek väli kuulostaa aika pitkältä, jos halutaan esimerkiksi tarkkailla sulatuksen pituutta, mitä itse harrastan. Tuon force defrost timerin seuraaminen on ehkä muutenkin vähän debug-tason kamaa, että normikäyttäjä ei sen logitusta tarvitse ollenkaan. Lähinnä sitä ovat varmaan käyttäneet minä ja @Velsku kun verifioimme tuon pakkosulatuksen toimintaa. Ei välttämättä olisi suuri menetys ihmiskunnalle, vaikka se jäisi kokonaan pois MQTT-julkaisuista.
Hienohan olisi toki jos tuossa olisi mahdollisuus helposti määrittää millä tasolla noita MQTT viestejä tulee, tyyliin debug, info, warning, error... Mutta hommansa siinä taas koodata.
Uskoisin että normikäyttäjälle oletusarvoinen 60sek päivitysväli on riittävä, päivitysväliä on helppo muuttaa muuttamalla update_interval aikaa. Ajattelin myös tehdä toteutuksen siten, että kommentoin pois joitakin tilakoneen debug-käyttöön tehdyistä mqtt-sanomista. Jos noita tarvitsee niin ne on helppo ottaa uudestaan käyttöön.
Protoversio pyörii nyt testipenkissä. Tuossa on sellainen kauneusvirhe että lähetettäessä MQTT-sanoma komennolla
"id(mqtt_client).publish($topic_outdoor, to_string(id(outdoor_temp).state));"
tulee mukaan turhan paljon desimaaleja (esim. ulkolämpö = 20.683722).
En tuota ole vielä ehtinyt yhtään selvitellä, olisiko jollakin tarjota valmista ratkaisua ?
puu
Aktiivinen jäsen
Noista RuuviTageista, normaali (ei-Pro) sekoaa kondensoivissa olosuhteissa ja näyttää väärin. Kun raportoi kosteuden olevan 100%:ssa niin siitä tietää että lämpötilalukemiin ei ole enää luottamista, Kuvassa Ruuvitag ja RuuviTag Pro 2in1, fyysistä välimatkaa tageilla 10cm. Kun tagin kuivaa niin rokkaa taas. En suosittele normitageja ulkolämpötilojen mittaukseen.
Liitetiedostot
Kun mietin standalone Mitsurunneri toteusta päädyin lisäämään nykysoftan päälle uuden konfigurointi-tason.
Alla Mitsu_confg .yaml-file.
Siihen käyttäjä valitsee haluamansa toiminnallisuuden ja lisäksi päivittää WiFi- ja MQTT-parametrit ko.tiedostoihin.
Tämän jälkeen tarvitsee vain kääntää Mitsu_confg .yaml.
@puu ja muut Mitsurunner käyttäjät, miltä tämä ratkaisu vaikuttaa ?
Alla Mitsu_confg .yaml-file.
Siihen käyttäjä valitsee haluamansa toiminnallisuuden ja lisäksi päivittää WiFi- ja MQTT-parametrit ko.tiedostoihin.
Tämän jälkeen tarvitsee vain kääntää Mitsu_confg .yaml.
@puu ja muut Mitsurunner käyttäjät, miltä tämä ratkaisu vaikuttaa ?
Koodi:
################################################
#### Update WiFi-details to the file ####
#### Standalone case comment file out ####
################################################
<<: !include secrets.yaml
#####################################################################
#### Select HW related file and check/update details to the file ####
#####################################################################
<<: !include platform_wemos.yaml
#<<: !include platform_elite.yaml
###############################################
packages:
################################################
#### Select configuration of Dallas sensors ####
#### no need to modify selected file ####
################################################
# dallas_base: !include Dallas_basic_u.yaml ## basic-configuration
dallas_base: !include Dallas_hub_u.yaml ## separate Dallas-hubs for minimize restarts
############################################################################
#### Select/enable used MQTT-server and update MQTT-details to the file ####
#### Comment all out if MQTT is not used ####
############################################################################
mqtt_base: !include mqtt_local.yaml ## Some other (local) MQTT-server
# mqtt_base: !include mqtt_Guru.yaml ## IoT-Guru server
# mqtt_base: !include mqtt_test ## Test MQTT-server for testing only
############################################################################
#### HomeAssistant issues
#### Homea ####
############################################################################
# HA-base: !iunclude jotakin
######################################################
#### Mitsurunner core code, do not Do not touch!! ####
######################################################
core_base: !include mitsurunner_core.yaml