MSZ-LN sulatushuijaus
- Keskustelun aloittaja iro
- Aloitettu
- Keskustelun aloittaja
- #2 042
Alla muutos noin koodattuna (ehto piti lisätä myös RESET-tilaan). Nopea testauksen perusteella asetettu tila säilyy sekä resetin että sähkökatkon yli, samoin jos koodi flashataan uudelleen. Tyhjälle chipille flashattynä oletusarvo on "Mitsurunner enabled".
Tilakoneen koodinuutos:
Koodi:
switch(id(G_state)) {
// This state is executed only in reset
case ST_RESET:
// Wait first that sensors has read some values.
if (G_state_time_passed) {
// If outdoor temperature average exceeds the threshold or Mitsurunner is disabled, switch off the defrost hack logic
if (id(heat_exchanger_temp).state > HEAT_EXCHANGER_MAX_TEMPERATURE ||
id(outdoor_temp).state > OUTDOOR_TEMPERATURE_TO_ENTER_OFF_STATE ||
id(G_Runner_ON) == false) {
id(enter_Off).execute();
}
// If defrosting is going on
else if (temperature_delta <= TEMPERATURE_DELTA_DEFROSTING_STARTED) {
id(enter_DefrostingStarted).execute();
}
else {
id(enter_Idle).execute();
}
}
break;
case ST_IDLE:
// If outdoor temperature average exceeds the threshold or Mitsurunner is disabled, switch off the defrost hack logic
if (id(heat_exchanger_temp).state > HEAT_EXCHANGER_MAX_TEMPERATURE ||
id(outdoor_temp).state > OUTDOOR_TEMPERATURE_TO_ENTER_OFF_STATE ||
id(G_Runner_ON) == false) {
id(enter_Off).execute();
}
// If maximum heating time exceeded, start defrosting immediately
else if (id(G_max_heating_time_passed) || id(G_manual_defrosting)) {
id(enter_StartDefrosting).execute();
}
// Wait for the temperature delta threshold to be exceeded.
else if (temperature_delta >= TEMPERATURE_DELTA_TO_DEFROST) {
id(enter_TempExceeded).execute();
}
break;
case ST_OFF:
// Enter normal defrost hack mode if outside temperature is low enough and Mitsurunner is enabled
if(id(heat_exchanger_temp).state < HEAT_EXCHANGER_MAX_TEMPERATURE &&
id(outdoor_temp).state < OUTDOOR_TEMPERATURE_TO_EXIT_OFF_STATE &&
id(G_Runner_ON) == true){
id(schedule_forced_defrosting).execute();
id(enter_Idle).execute();
}
break;
case ST_TEMP_EXCEEDED:Switch-osioon lisätää tämä
Koodi:
switch:
#### Enable/Disable Mitsurunner
- platform: template
name: "Runner_ON"
id: Runner_ON
restore_mode: RESTORE_DEFAULT_ON
lambda: "return id(G_Runner_ON);"
turn_on_action:
then:
lambda: !lambda |-
id(G_Runner_ON) = true;
turn_off_action:
then:
- lambda: !lambda |-
id(G_Runner_ON) = false;Ja globals-osuuteen tämä:
Koodi:
globals:
- id: G_Runner_ON
type: bool
initial_value: 'true'- Keskustelun aloittaja
- #2 043
More guessing...
If I interpret the characteristic curve of heat exchanger's NTC correctly recistance @ 0°C is about 33kohm. It is about the same as the Mitsurunner's cheating resistor. It's hard to believe that such small resistance-difference would have so big impact on operations.
Or is it, maybe Mitsu is checking temperature change of exchanger and when missing puts more power...
Can you measure the voltage that goes to Mitsubishi when
a) Mitsubishi own NTC is connected (relay open)
b) the cheat resistor is connected (relay closed)
The values should be about the same.
Viimeksi muokattu:
- Keskustelun aloittaja
- #2 045
Tein tuosta pull requestin.
Mitenhän kannattaisi edetä minulla olevan uuden Mitsurunner-softaversion kanssa ?
Siinä konfigurointi määritellään erillisessä Mitsuconf.yaml tiedostossa jossa valitaan mitä toiminnallisia -yaml tiedostoja otetaan mukaan.
Eri kokoonpanojen konfigurointi on näin helpompaa ja siinä on valmis setup niin Home-Assistant kuin Stand-Alone versioille.
Jotakin pientä fiilausta lukuunottamatta toiminnallisia muutoksia ei ole, mutta tiedostorakenteessa on muutoksia (= uusia vaihtoehtoisia *.yaml tiedostoja).
Paketti on testattu ja toimivaksi todettu, mutta olen odotellut että pääsisin testaaman yhtyeensopivuutta tämän vuoden EspHome-version kanssa. Tuo on edelleen vaiheessa sillä uusin EspHome versio on yhä 2024.12.4.
Kannattaisiko tuosta tehdä uusiMitsurunner release ?
- Keskustelun aloittaja
- #2 047
Nykyinen viritelmä kuitenkin toimii ja on yhteensopiva ainakin EspHome-version 2024.12.4. kanssa sekä kommiunikoi HA.n kanssa,
Edellenkehittämisessä heitän pallon niille joilla on siihen osaamista, aikaa ja innostusta.
puu
Aktiivinen jäsen
Miten tuossa yhden yamlin mallissa hanskataan eri versiot, mitkä on nykyisellään toteutettu siten, että includoidaan oikea yaml, esim platform_wemos.yaml/platform_elite.yaml? Itsehän jakaisin mieluummin mitsurunner.yamlin jopa vielä useampaan tiedostoon, jos se kävisi jotenkin järkevästi, mutta tämä esphome+yaml-kombinaatio näyttäisi taipuvan siihen huonosti.
Opensource kun on kyseessä, niin tuota saa vapaasti muokata haluamakseen, ja jos on hyvä parannusehdotus, niin ei muuta kun pull requestia tuonne GitHubiin.
puu
Aktiivinen jäsen
Tsekkasin, näytti hyvältä, ainoastaan laitoin kommentin tuosta web-GUI:ssa näkyvästä nimestä Runner_ON -> Runner ON (ilman alaviivaa), kun muutkin nimet ovat välilyönnillä alaviivan sijaan.
Kannatan uutta relasea, kunhan tuota on testattu tuoreella EspHomella. Itselläni on sen verran erilainen setuppi, etten tuota pysty testaamaan ja käytän vanhempaa EspHomea luultavasti jatkossakin.
- Keskustelun aloittaja
- #2 051
Tein tuolle uudelle versiolle branchin omaan Github'iini ja laitoin koodit sinne talteen. Jos uusi EspHome-versio vaatii muutoksia teen ne tuolle ennen julkaisua.
- Keskustelun aloittaja
- #2 052
Nimeksi oli jäänyt työnimi, vaihdoin nimeksi " Mitsurunner enabled". Laitoin nimen alkuun välilyönnin niin tuo näkyy Web_GUI:ssa ylimmäisenä. Pitäsikö minun tehdä tehdä jotakin github:ssa ?
Liitteet
- Keskustelun aloittaja
- #2 053
Pari havaintoa Mitsurunnerin häiriöistä.
Minulla Mitsurunner-Pana sovellus on toteutettu siten että Wemos on sisäyksikön vieressä ja huijausvastus ja sitä ohjaava opto on ulkoyksikössä. Sisäyksiköltä menee kaksi audiokaaplia seinän läpivienin ja putkikourun kautta ulkoyksikölle. Toisessa kaapelissa on ulkoyksikön DS18B20 anturit, sisällä samaan kaapeliin on liitetty kolme muuta DS18B20-anturia, toinen kaapeli on huijausvastuksen ohjaukseen.
Testausvaiheessa opto ja huijausvastus oli sisällä ja toiseen yksiköiden väliseen kaapeliin oli haaroitettu ulkoyksikön kennoanturin johtimet. Tuolloin molempien DS18B20-antureiden mittauksista noin puolet epäonnistui (silti Mitsurunner toimi oikein!), sisäyksikön antureilta virheitä ei esiintynyt. Kun sitten myöhemmin siirsin opton ja huijausvastuksen ulkoyksikköön, DS18B20 virheitä ei tule lainkaan. Eli herkästi DS18B20-mittaukset häiriintyvät jos johtimet ovat lähellä ulkoyksikön johtimia.
Ohjaan optoa suoraan Wemos D1 nastan 8mA virralla. Havaitsin että Wemos resetoituu silloin tällöin juuri kun D1 menee ON-tilaan. Ongelma poistui lisäämällä 3,3 uF konkka Wemosin GND ja 3,3V nastojen väliin.
Minulla Mitsurunner-Pana sovellus on toteutettu siten että Wemos on sisäyksikön vieressä ja huijausvastus ja sitä ohjaava opto on ulkoyksikössä. Sisäyksiköltä menee kaksi audiokaaplia seinän läpivienin ja putkikourun kautta ulkoyksikölle. Toisessa kaapelissa on ulkoyksikön DS18B20 anturit, sisällä samaan kaapeliin on liitetty kolme muuta DS18B20-anturia, toinen kaapeli on huijausvastuksen ohjaukseen.
Testausvaiheessa opto ja huijausvastus oli sisällä ja toiseen yksiköiden väliseen kaapeliin oli haaroitettu ulkoyksikön kennoanturin johtimet. Tuolloin molempien DS18B20-antureiden mittauksista noin puolet epäonnistui (silti Mitsurunner toimi oikein!), sisäyksikön antureilta virheitä ei esiintynyt. Kun sitten myöhemmin siirsin opton ja huijausvastuksen ulkoyksikköön, DS18B20 virheitä ei tule lainkaan. Eli herkästi DS18B20-mittaukset häiriintyvät jos johtimet ovat lähellä ulkoyksikön johtimia.
Ohjaan optoa suoraan Wemos D1 nastan 8mA virralla. Havaitsin että Wemos resetoituu silloin tällöin juuri kun D1 menee ON-tilaan. Ongelma poistui lisäämällä 3,3 uF konkka Wemosin GND ja 3,3V nastojen väliin.
puu
Aktiivinen jäsen
Mergesin muutoksen main-haaraan. Tuossahan tuli samalla korjaus tuohon initialize-skriptin nimen aiheuttamaan ongelmaan, hyvä juttu, saan yhden issuen merkattua korjatuksi. Pitäisi varmaan nuo muutkin issuet käydä joskus läpi...
puu
Aktiivinen jäsen
Hmm, näköjään tätä asiaa on ihmetelty jo aiemminkin, sillä olen tehyt GitHubiin issuen viime vuoden huhtikuussa. Ainakin Dashboardin osalta olen itse esittänyt (ehkä jonkun toisen keksimäksi) ratkaisuksi siirtää muut yaml-tiedostot omaan hakemistoonsa. Osaatko @jkoljo sanoa, auttaisiko tuo myös tuon Home Assistantin add-onin kanssa?
Move other yaml files than mitsurunner.yaml to a separate directory · Issue #41 · VeliML/MitsuRunner
This is because Dashboard sees every yaml as a separate device.
github.com
- Keskustelun aloittaja
- #2 056
HA-osuudesta en mitään ymmärä, mutta helpottaako/vaikeuttaako tilannetta se että mitsu_conf.yaml kokoaa halutun paketin käyttäen "package"-metodia ?Hmm, näköjään tätä asiaa on ihmetelty jo aiemminkin, sillä olen tehyt GitHubiin issuen viime vuoden huhtikuussa. Ainakin Dashboardin osalta olen itse esittänyt (ehkä jonkun toisen keksimäksi) ratkaisuksi siirtää muut yaml-tiedostot omaan hakemistoonsa. Osaatko @jkoljo sanoa, auttaisiko tuo myös tuon Home Assistantin add-onin kanssa?
Move other yaml files than mitsurunner.yaml to a separate directory · Issue #41 · VeliML/MitsuRunner
This is because Dashboard sees every yaml as a separate device.
Mitsu_conf.yaml
Koodi:
<<: !include platform_pana.yaml
packages:
wifi_base: !include secrets_pana.yaml ## WifI needed
dallas_base: !include dallas_hub_pana.yaml ## minimize restarts, no more than 2 Dallas-sensor
mqtt_base: !include mqtt_disabled.yaml ## NOTE! This must be included if MQTT is not used
HA-base: !include homeassistant.yaml ## Enable if HomeAssistanty in use
core_base: !include panarunner_core.yaml ## MUST be included
- Keskustelun aloittaja
- #2 058
Hmm, näköjään tätä asiaa on ihmetelty jo aiemminkin, sillä olen tehyt GitHubiin issuen viime vuoden huhtikuussa. Ainakin Dashboardin osalta olen itse esittänyt (ehkä jonkun toisen keksimäksi) ratkaisuksi siirtää muut yaml-tiedostot omaan hakemistoonsa. Osaatko @jkoljo sanoa, auttaisiko tuo myös tuon Home Assistantin add-onin kanssa?
Move other yaml files than mitsurunner.yaml to a separate directory · Issue #41 · VeliML/MitsuRunner
This is because Dashboard sees every yaml as a separate device.
Sijoitin Mitsurunner-koodipaketin C:\Users\ilkka\Mitsurunner\Mitsu0225 hakemistoon ja päivitin mitsurunner.yaml include määritykset. Kun tuon hakemiston osoitteen määrittelee Mitsu_conf.yaml tiedostoon voi Mitsu_cong.yaml sijaita eri paikassa hakemistorakenteessa. Tuo menee ongelmitta läpi EspHome-kääntäjästä.
HA-tuntijat: toimisiko tämä HA:n add-on tapauksessa.
Koodi:
### Mitsu_conf.yaml tiedosto joka rakentaa halutun Mitsurunner variantin
##############################################################
<<: !include C:\Users\ilkka\Mitsurunner\Mitsu0225\platform_wemos.yaml
packages:
wifi_base: !include C:\Users\Mitsurunner\Mitsu0225\secrets.yaml
dallas_base: !include C:\Users\iMitsurunner\Mitsu0225\dallas_hub.yaml
mqtt_base: !include C:\Users\Mitsurunner\Mitsu0225\mqtt_local.yaml
core_base: !include C:\Users\iMitsurunner\Mitsu0225\mitsurunner.yamlMitsurunner.yaml includes osion tarvitsemat muutokset
Koodi:
includes:
- C:\Users\Mitsurunner\Mitsu0225\constants.h
- C:\Users\Mitsurunner\Mitsu0225\state.h
# global variables and their initial values
globals:Liitteessä Mitsurunner0225 paketti
Viimeksi muokattu:
Kävin viikko sitten mökillä vähän säätämässä antureiden paikkaa ja kytkemässä puu-adapterin kiinni. MitsuRunner on nyt viikon ajan vastannut AP25-pumpun sulatuksesta.
Otin mallia iron vinkistä, ja siirsin kennoanturin kennon vasempaan reunaan putkeen, joka huurtuu / sulaa viimeisenä. Piti tehdä yksi läpivienti peltiin anturin kaapelia varten, joka ei pidempää reittiä pitkin olisi riittänyt oikeaan kohtaan. Seurailin arvoja parin sulatuksen verran, jonka jälkeen uskalsin jättää MitsuRunnerin puikkoihin. "TEMPERATURE_DELTA_TO_DEFROST" jätin vakioarvoon 5.0.
Outdoor-anturi oli sijoitettu ihan oikeaan paikkaan, mutta tajusin että pumpun päällä oleva ovikatos (tämän tyyppinen) aiheutti sen, että ilma ei kierrä kunnolla pumpun takana, vaan jää pyörimään pumpun taakse. Tämän takia sulatuksen aikana kennosta säteillyt lämmin ilma näkyi nousupiikkinä myös ulkolämpötilassa ja vastaavasti kennon huurtumisesta säteillyt kylmä ilma näkyi myös arvoissa. Tempaisin katoksen mäkeen, jonka jälkeen outdoor-anturi alkoi näyttämään tasaisemmin lukemia.
Ulkoilman nopea lauhtuminen (etenkin merenrannassa) aiheuttaa ymmärrettävästi tarvetta tiheämmälle sulatukselle, mutta muutoin käytös on viikon perusteella vaikuttanut järkevämmältä kuin aikaisemmin. Vielä kun IoT Gurun saisi vaihdettua johonkin järkevämpään ratkaisuun, jossa pääsisi seuraamaan lukuja tarkalla tasolla pitkältä ajalta. Muut ilmaiset brokerit vaikuttaisi vaativan SSL/TLS-yhteyden käyttämistä, joka taas esphomen & ESP8266 alustan yhdistelmällä ei tällä hetkellä onnistu.
Pumpun puhaltaman ilman lämpötila:
Ulkoilman lämpö:
Kenno:
Delta:
Hey there Martin! Im using @puu s adapter with a smaller mxz 53…something with very good results since 2 years or so. Actually before mitsurunner my units went full on after defrost and then park for a while after which back full on, but now lowering power after initial heating after defrost and running constantly until next defrost. I think i posted some graphs and pics when installed, dunno if you can find them with my user name?
- Keskustelun aloittaja
- #2 061
Tein Mitsurunner-ohjelmarakenteeseen vielä pieniä muutoksia niin että sen pystyy nyt kääntämään ja lataamaan myös Home Assistantin ESPHome Builderilla.
Olen täysin noviisi HomeAssiatant-asioissa joten alla kuvattu prosessi on luultavasti täysin vastoin hyviä käytäntöjä, HA-tuntijat voisivat kertoa kuinka tuo oikeasti pitäisi tehdä.
Kuitenkin tuo toimii.
EDIT-lisäys: OTA-päivitys toimii myös ESPHome-tool:lla tehtyyn Mitsurunneriin kunhan WiFi-asetukset ja OTA-password ovat samoja.
1) Hakemiston homeassistant/esphome alle luodaan hakemisto mitsu ja sinne ladataan tarvittavat Mitsurunnerin x.yaml ja x.h tiedostot
2) ESPHome builderiin luodaan uusi device ja sille kopioidaan Mitsu_conf.yaml tiedosto
3) Save / Install / Manual_Dovwload tekee .bin tiedoston. Tiedosto talletetaan.
4) Ensimmäinen flashays pitää tehdä USB:n kautta, Install /Plug into this Computer / Open ESPHome Web / Connect / Install
==> Mitsurunner on asennettu ja seuraavat flashaykset voidaan tehdä OTA:na
Olen täysin noviisi HomeAssiatant-asioissa joten alla kuvattu prosessi on luultavasti täysin vastoin hyviä käytäntöjä, HA-tuntijat voisivat kertoa kuinka tuo oikeasti pitäisi tehdä.
Kuitenkin tuo toimii.EDIT-lisäys: OTA-päivitys toimii myös ESPHome-tool:lla tehtyyn Mitsurunneriin kunhan WiFi-asetukset ja OTA-password ovat samoja.
1) Hakemiston homeassistant/esphome alle luodaan hakemisto mitsu ja sinne ladataan tarvittavat Mitsurunnerin x.yaml ja x.h tiedostot
2) ESPHome builderiin luodaan uusi device ja sille kopioidaan Mitsu_conf.yaml tiedosto
3) Save / Install / Manual_Dovwload tekee .bin tiedoston. Tiedosto talletetaan.
4) Ensimmäinen flashays pitää tehdä USB:n kautta, Install /Plug into this Computer / Open ESPHome Web / Connect / Install
==> Mitsurunner on asennettu ja seuraavat flashaykset voidaan tehdä OTA:na
Liitteet
Viimeksi muokattu:
Keikhaus
Jäsen
Nyt kun mitsurunner on pyörinyt meikäläisen LN25 :ssa tammikuusta alkaen ongelmitta oletus säälisulatuksella, tuli mieleen että onko tämä 180 minuuttia testauksen kautta löytynyt optimaalinen arvo?
Eli kannattaako minun suurentaa arvoa vaikkapa 600 minuuttiin ja onko tästä saavutettavaa kannattavaa laskennallista hyötyä paitsi että harvenee tuo valaan pieraisu millaiseksi eräs tuttavani kuvasi joskus tuota mitsun sulatusta...
Eli kannattaako minun suurentaa arvoa vaikkapa 600 minuuttiin ja onko tästä saavutettavaa kannattavaa laskennallista hyötyä paitsi että harvenee tuo valaan pieraisu millaiseksi eräs tuttavani kuvasi joskus tuota mitsun sulatusta...
- Keskustelun aloittaja
- #2 063
ESPHome versio 2025.2.0 on nyt käytettävissä sekä ESPHome-toolissa että HomeAssistantant ESPHome Builderissa.
Vaati joitakin muutoksia Mitsurunnerin softaan. Ohessa päivitetty Mitsurunnerin softapaketti joka toimii sekä uudella että edeltävillä ESPHome versiolla. Enjoy!
EDIT: Paketti päivitetty. WiFi-sensori siirretty mitsurunner.yaml tiedostoon.
Vaati joitakin muutoksia Mitsurunnerin softaan. Ohessa päivitetty Mitsurunnerin softapaketti joka toimii sekä uudella että edeltävillä ESPHome versiolla. Enjoy!
EDIT: Paketti päivitetty. WiFi-sensori siirretty mitsurunner.yaml tiedostoon.
Viimeksi muokattu:
- Keskustelun aloittaja
- #2 064
Tuolla vanhassa ketussa on pohdiskeltu säälisulatuksen tarvetta.
Panasonicin sulatushuijaus
Vs: Panasonicin sulatushuijaus Otatko pumpun sisältä sähköt vai miten? Laita vaan kuvia jahka jaksat. Sähköt tuohon "ilmamassa" anturoinnin lämmitys vastuksillekko ? Tällä hetkellä asennus vielä mallia "väliaikainen", kun luottoa ei ollut tuohon toimintaan. Tässä väliaikaisversiossa...
180 minuutin tuplaaminen ei merkittävästi paranna tehokkuutta mutta tietysti vähentää sulatuksen aiheittamaa häiriötä.
Minulla FD25 on toiminut 7 tunnin säälisulatuksella jo lähes kymmenen vuotta. Myös Pana kesti kymmenisen vuotta, sitten elektroniikka petti.
Keikhaus
Jäsen
Jep, tällaiseen käsitykseen olen itsekin tullut kun olen näitä ketjuja lueskellut
Saapi olla tälleen ainakin tämän lämmityskauden.
Kiitos vinkeistä!
https://thingspeak.mathworks.com/prices/thingspeak_home tarjoaa ilmaista pilvitallennusta
https://thingspeak.mathworks.com/pages/license_faq lisätietoa
- Keskeisin ero lienee se että Thingspeakissa on noi channelit (vrt. Iotgurussa on devicet ja niiden alle nodet) ja kunkin channelin alle enintään 8 fieldiä = arvoa - vrt. Iotgurussa rajaton määrä devicejä, nodeja ja fieldejä.
- Graafit on pienempiä ja kämäisempiä.
- Thingspeakin oma koodikieli on aivan hirveä (ja/tai dokumentaatio tosi huono) ja nettieditori vielä hirveämpi (ihan siitä alkaen että copypaste puuttuu), mutta näitä tarvii vain jos haluaa prosessoida tai visualisoida paremmin tiertoja suoraan Thingspeakissa.
Onkohan joku syy miksi mqtt:topic_prefix on 'null' ja topic_prefix määritetään kohta erikseen?
Nykyinen koodi:
Koodi:
mqtt:
topic_prefix: null # trace log is not send to IoT Guru server
substitutions:
# "prefix" = topic of IoT-Guru node e.g 'pub/user_id/client_id/node_short_identifier'.
# Can be found from IoT Guru Field/Help under 'GENERIC MQTT TOPIC'
# It should look like: 'pub/tQAz8YAINFNft0R7Q/l4xFwCiKxKUWQft0R7Q/rEWtD1fYqnggHMR7Q'
prefix: 'pub/.../.../...'
# MQTT topics. Notice that these are inside both single and double quotes e.g.'"xxx"'
topic_heatexchanger: '"$prefix/kenno"'
topic_outdoor: '"$prefix/ulkoilma"'Luulisin että toimisi myös jotenkin näin:
Koodi:
mqtt:
# "prefix" = topic of IoT-Guru node e.g 'pub/user_id/client_id/node_short_identifier'.
# Can be found from IoT Guru Field/Help under 'GENERIC MQTT TOPIC'
# It should look like: 'pub/tQAz8YAINFNft0R7Q/l4xFwCiKxKUWQft0R7Q/rEWtD1fYqnggHMR7Q'
topic_prefix: 'pub/.../.../...'
# MQTT topics
topic_heatexchanger: 'kenno'
topic_outdoor: 'ulkoilma'- Keskustelun aloittaja
- #2 068
Jos oikien muistan tuon logiikan niin;
Koska IoT_Gurua käytettäessä MQTT_logeja ei voi hyödyntää, estetään hyödytön logien lähetys MQTT-serverille "topic_prefix: null"-komennolla (=ei turhaa MQTT-kuormaa).
prefix: 'pub/.../.../...'n on Substitutio. (kieltämättä hieman hämäävä nimeäminen).
Ellei "release-kanditaatissa" ole toiminnallisia ongelmia julkaistaan se ja tehdään parannuksia seuraavaan versioon .
- Keskustelun aloittaja
- #2 070
Varmaankin on noin. Ja toteutuksessa lienee monta muutakin kohtaa jotka voisi toteuttaa tyylikkäämmin.
Kuten edellisessä viestissä mainitsin minulle ykköstavoite on saada uusi versio julkaistua toimivana. Muutokset vaativat enemmän tai vähemmän uutta testausta eikä minulla ole siihen nyt aikaa
Viimeksi muokattu:
- Keskustelun aloittaja
- #2 071
@juu , Nostan käden ylös virheen merkiksi, kiitos havainnosta. Tuon kohdan pitäisi olla kuten edellisessä versiossa
ESPHome.kääntäjän antamien varoitusten välttämiseksi kannataa koodi kääntää komennolla
esphome run --no-logs mitsurunner.yaml
Teen tuon muutoksen mutta muutoin jätän prefix osuuden ennalleen. (En pysty nyt testaamaan tuollaista muutosta.) Jos teet ja pystyt testaamaamasn prefix-muutoksen omassa ympäristössä niin otan testatun yaml- tiedoston mielihyvin mukaan.
EDIT: Määrittelyt ovat jo mukana mqtt_guru.yaml tiedostossa. Epähuomiossa katsoin mqtt_local.yaml tiedostoa jossa logien lähetys saa olla mukana.
Koodi:
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 usedESPHome.kääntäjän antamien varoitusten välttämiseksi kannataa koodi kääntää komennolla
esphome run --no-logs mitsurunner.yaml
Teen tuon muutoksen mutta muutoin jätän prefix osuuden ennalleen. (En pysty nyt testaamaan tuollaista muutosta.) Jos teet ja pystyt testaamaamasn prefix-muutoksen omassa ympäristössä niin otan testatun yaml- tiedoston mielihyvin mukaan.
EDIT: Määrittelyt ovat jo mukana mqtt_guru.yaml tiedostossa. Epähuomiossa katsoin mqtt_local.yaml tiedostoa jossa logien lähetys saa olla mukana.
Viimeksi muokattu:
Tein Mitsurunner-ohjelmarakenteeseen vielä pieniä muutoksia niin että sen pystyy nyt kääntämään ja lataamaan myös Home Assistantin ESPHome Builderilla.
Olen täysin noviisi HomeAssiatant-asioissa joten alla kuvattu prosessi on luultavasti täysin vastoin hyviä käytäntöjä, HA-tuntijat voisivat kertoa kuinka tuo oikeasti pitäisi tehdä.
EDIT-lisäys: OTA-päivitys toimii myös ESPHome-tool:lla tehtyyn Mitsurunneriin kunhan WiFi-asetukset ja OTA-password ovat samoja.
1) Hakemiston homeassistant/esphome alle luodaan hakemisto mitsu ja sinne ladataan tarvittavat Mitsurunnerin x.yaml ja x.h tiedostot
2) ESPHome builderiin luodaan uusi device ja sille kopioidaan Mitsu_conf.yaml tiedosto
3) Save / Install / Manual_Dovwload tekee .bin tiedoston. Tiedosto talletetaan.
4) Ensimmäinen flashays pitää tehdä USB:n kautta, Install /Plug into this Computer / Open ESPHome Web / Connect / Install
==> Mitsurunner on asennettu ja seuraavat flashaykset voidaan tehdä OTA:na
Moi iro,
Kiitokset 2025.2.0 versiosta. Lisäsin myös kaikki tarvitsemani muutokset esphomen päähakemiston yamliin. Voin siis teoriassa purkaa uuden version suoraan mitsurunner hakemistoon ja painaa install.
Koodi:
<<: !include mitsurunner/platform_elite.yaml
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
use_address: 192.168.100.38
reboot_timeout: 360min
ota:
platform: esphome
password: !secret ota_password
api:
reboot_timeout: 0s
encryption:
key: !secret api_key
sensor:
- platform: wifi_signal
name: "WiFi Signal dBm"
id: wifi_signal_dbm
accuracy_decimals: 0
update_interval: 15s
filters:
- sliding_window_moving_average:
window_size: 8
send_every: 8
#web_server:
# port: 80
packages:
dallas_base: !include
file: mitsurunner/dallas_basic.yaml
vars:
dallas_address_heat_exchanger_temp: '0x0f012112d2a6ea28'
dallas_address_outdoor_temp: '0x20012112a89ddd28'
mqtt_base: !include mitsurunner/mqtt_disabled.yaml
core_base: !include mitsurunner/mitsurunner.yaml
esphome:
includes:
- mitsurunner/constants.h
- mitsurunner/state.h- Keskustelun aloittaja
- #2 073
Tuohan on varsin tyylikäs ratkaisu purkaa secrets-tiedot suoraan conf-tiedostoon. Ei-HA versiossa pitäisi määritellä manual-ip kokonaisuudessaan.
WiFi-sensori on nyt secrets-osiossa koska muutoin se aiheuttaa ongelmia StandAone-versiossa. Voisin miettiä vielä miten StandAlonen voisi hoitaa jos WiFi-sensori on mitsurunner.yaml tiedostossa.
HA:ssa ei tarvita MQTT:tä, mutta toimisikohan mqtt-tiedostoissa sama menetelmä (määritellä substitutions) kuin sinulla dallas-tiedostossa.
jos haluaa kirjoittaa uusiksi määrittelyiden käsittelyn, ne voisi kerätä conf tiedostoon substitutions tai defaults elementteihin joista ne siirtyisivät paketeille ilman vars elementtejä. tavallaan se voisi olla selkeämpää vaikka näkyvissä olisi turhia muuttujia ja ainakin koodin päivittäminen helpottuisi. makuasia miten tuon haluaa toteuttaa ja pääasia on että itse logiikka toimii hienosti nykyiselläänkin.
- Keskustelun aloittaja
- #2 075
OK. Ehkä turvallisinta ja nopeinta on julkaista nykyinen paketti ja tehdä fiilauksia seuraavaan. Kun paketti saadaan julkasitua niin voisitko tehdä Mitsrunner Wikiin ohjeistuksen sen käyttöönotosta HomeAssistant ympäristössä (eli dokumentoida edellisessä viestissä tekemäsi toteutuksen) ?
- Keskustelun aloittaja
- #2 076
Laitoin WiFi-sensorin mitsurunner.yaml tiedostoon, mutta nyt en pysty testaamaan sen toimivuuta. Pystytkö sinä testaamaan tuon, eli poista Wifi-sensori päähakemistosta ja käytä alla olevaan mitsurunner_w.yaml tiedostoa ?
Ei ole pakko määrittää ip:tä ollenkaan. Mulla pelittää hyvin ilman ip:tä, yhteys löytyy osoitteella mitsurunner.local
- Keskustelun aloittaja
- #2 078
Sama havainto minulla. Dynaamista ip:tä käytettäessä OTA-päivitys epäonnistuu sillon tällöin.
Kiinteän ip:n käyttö tuli mukaan ESPHome suosituksesta
It’s recommended to provide a static IP for your node, as it can dramatically improve connection times.
Toimii oikein myös tällä.