MSZ-LN sulatushuijaus

[iro]

Uusi Mitsurunner softa-paketti on nyt ladattavissa Mitsurunner github:sta.
Teen tarvittavia muutoksia Mitsuriunner Wikiin lähipäivinä /lähiviikoina.

 

[iro]

Tein Mitsurunner Wikiin ohjeistusta uusimman softaversion käyttöönotosta, HomeAssistant/ESPHome_Builder:in osalta proseduuri on hieman "quick and dirty" mutta toimii eikä vaadi syvällisempää HomeAssistant osaamista.
Huomasin, että Wikissä on asennusohjeet myös englanniksi. Noita en ole päivittänyt, löytyiskö vapaaehtoista päivittämään tuo osuuden.

 

[iro]

Havaitsin tilanteen jossa Mitsurunner toimií muuten normaalisti mutta ei enää kommunikoi HomeAssitantin kanssa. Johtui luultavasti siitä että olen Mitsurunner koodissa disabloinut reboot-toiminnan jos HomeAssistant kommunikointi pysähtyy (reboot_timeout: 0).

Tein muutoksen platform_wemos.yaml ja paltform_elite.yaml tiedoistoihin, nyt HomeAssistant reboot-time-out on sama kun WiFi- ja MQTT-time-out (360min).

# Enable/disabe HomeAssistant
#api:                                       # !! If home Assistant in use remove comment (#)
#  reboot_timeout: $common_reboot_timeout   # !! If home Assistant in use remove comment (#)

 

[CheatTheMi]

Hey together,
I wanted to use the summer break, to make an update of my Mitsurunner.

Downloaded the updated files from Github, updated to the latest version of ESPHome and Python, wanted to compile in the shell and now it just says:

esphome: [source mitsurunner.yaml:26]

  Platform missing. You must include one of the available platform keys: bk72xx, esp32, esp8266, host, libretiny, rp2040, rtl87xx.
  name: mitsurunner
  friendly_name: Mitsurunner
  on_boot:
    - switch.turn_off: gpio_relay
    - switch.turn_on: dallas_power
    - script.execute: schedule_forced_defrosting
    - script.execute: initialize_runner

I tried already to add the platform key and used this profile for the Wemos D1 Mini, but no success: https://docs.platformio.org/en/latest/boards/espressif32/wemos_d1_mini32.html


Any ideas / updated code?

Thanks for keeping this project running!


-----------------------------------------------------------------------------------------------------------------------------------------------

Edit1:
Adding following in line 34 e.g. to the mitsurunner.yaml fixes the first error:

esp8266:           
  board: nodemcuv2

Then on compiling appears now, "Cannot resolve pin name '$relay_pin for board modemcuv2' . Still no idea and success how to fix this.

 

[iro]

Hey together,
I wanted to use the summer break, to make an update of my Mitsurunner.

Downloaded the updated files from Github, updated to the latest version of ESPHome and Python, wanted to compile in the shell and now it just says:

esphome: [source mitsurunner.yaml:26]

  Platform missing. You must include one of the available platform keys: bk72xx, esp32, esp8266, host, libretiny, rp2040, rtl87xx.
  name: mitsurunner
  friendly_name: Mitsurunner
  on_boot:
    - switch.turn_off: gpio_relay
    - switch.turn_on: dallas_power
    - script.execute: schedule_forced_defrosting
    - script.execute: initialize_runner

I tried already to add the platform key and used this profile for the Wemos D1 Mini, but no success: https://docs.platformio.org/en/latest/boards/espressif32/wemos_d1_mini32.html


Any ideas / updated code?

Thanks for keeping this project running!


-----------------------------------------------------------------------------------------------------------------------------------------------

Edit1:
Adding following in line 34 e.g. to the mitsurunner.yaml fixes the first error:

esp8266:        
  board: nodemcuv2

Then on compiling appears now, "Cannot resolve pin name '$relay_pin for board modemcuv2' . Still no idea and success how to fix this.

Nice to see some activity here — it's a good time for maintenance work.
A quick confirming question: Did you notice that the Mitsurunner software has a new structure and the compile & build must be done using the mitsu_conf.yaml file?"

MitsuRunner Wiki [MitsuRunner]

mitsurunner.com

EDIT: It looks like "platform_wemos.yaml" is not included into the build.

 

[CheatTheMi]

Nice to see some activity here — it's a good time for maintenance work.
A quick confirming question: Did you notice that the Mitsurunner software has a new structure and the compile & build must be done using the mitsu_conf.yaml file?"

MitsuRunner Wiki [MitsuRunner]

mitsurunner.com

EDIT: It looks like "platform_wemos.yaml" is not included into the build.

Thanks for that information, that was the issue.

I was still fixed to the "esphome run mitsurunner.yaml" ; with "esphome mitsu_conf.yaml" it worked smooth so far, I also could remove my mentioned code (esp8266: board: nodemcuv2) and still worked. So, that was my fault!

Only "issue" / information for now is:
"ERROR Found no valid options for upload/logging, please make sure relevant sections (ota, api, mqtt, ...) are in your configuration and/or the device is plugged in."

Edit: Fixing done! If you ONLY use IOTGuru:
In mqtt_Guru.yaml set a # hashtag in line 47, 48, 49, in front.

#  topic_prefix: null  
#  log_topic: null      
#  discovery: false

Looks like everything is up and running now!

 

[iro]

Thanks for that information, that was the issue.

I was still fixed to the "esphome run mitsurunner.yaml" ; with "esphome mitsu_conf.yaml" it worked smooth so far, I also could remove my mentioned code (esp8266: board: nodemcuv2) and still worked. So, that was my fault!

Only "issue" / information for now is:
"ERROR Found no valid options for upload/logging, please make sure relevant sections (ota, api, mqtt, ...) are in your configuration and/or the device is plugged in."

Edit: Fixing done! If you ONLY use IOTGuru:
In mqtt_Guru.yaml set a # hashtag in line 47, 48, 49, in front.

#  topic_prefix: null
#  log_topic: null   
#  discovery: false

Looks like everything is up and running now!

Great that you managed to update Mitsurunner.
Some clarificatios

  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

If codelines are disabled, Mitsurunner tries to send log data to the server via MQTT, and the resulting MQTT load may increase the number of Mitsurunner resets.

I can't verify this right now, but as far as I understand, including those code lines does cause an ESPTool error message, but the Mitsurunner software itself still works correctly and sends the data to IoT-Guru. Only relevant data is sent via MQTT.

EDIT:
I verified Mitsurunner Gitub code (part of MQTT-code for IoT-Guru below):
==> no ESPHome Tool-errors
==> no problems with IoT-Guru communications.

   …..

  reboot_timeout: 3600s

  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

###############################################

substitutions:

# If you use IoT Guru: Replace with your own values: uuu = user_id, ccc = client_id, nnn = node_short_identifier.
# In IoT Guru see Field > Help and copy/paste the line under 'GENERIC MQTT TOPIC'
# It should look like: 'pub/uuu/ccc/nnn'

  prefix:        'pub/tQAz8YAIt0R7Q/l4KxKX40UWQft0R7Q/rEWtD1GX1nggHMR7Q'


# MQTT topics. Notice that these are inside both single and double quotes e.g.'"xxx"'
 
  topic_heatexchanger:                  '"$prefix/kenno"'
  topic_outdoor:                        '"$prefix/ulkoilma"'

  ….

 

[CheatTheMi]

EDIT:
I verified Mitsurunner Gitub code (part of MQTT-code for IoT-Guru below):
==> no ESPHome Tool-errors
==> no problems with IoT-Guru communications.

Excellent, really looks like even with the "error" message it works.

I also updated Mitsurunner about two hours ago without the # I set before and all values are sent properly to IOTGuru.

So, conclusion seems so be, that there is no need to use #, because Mitsurunner works like charm.

Excellent and thank you so much for assistance!

 

[Nilkkakyy]

Mikähän mitsurunneriini tuli kun iotguruun ei ole ilmestynyt heinäkuun puolivälin jälkeen mitään... runneri on verkossa ja flashasin sen ota:na uusiksi varulta mutta ei muutosta...? Muilla samoja murheita? Töpseli on ollut satunnaisesti irti mutta aina se on sieltä herännyt henkiin

 

[Lape]

Mikähän mitsurunneriini tuli kun iotguruun ei ole ilmestynyt heinäkuun puolivälin jälkeen mitään... runneri on verkossa ja flashasin sen ota:na uusiksi varulta mutta ei muutosta...? Muilla samoja murheita? Töpseli on ollut satunnaisesti irti mutta aina se on sieltä herännyt henkiin

Mulla katos kans MQTT tiedot iotgurusta ja home assistantista.

13:46:12	[D]	[esp-idf:000][1;31m[mqtt_task][0;36m	E (1678199 esp-tls: [sock=49] delayed connect error: Connection reset by peer
13:46:12	[D]	[esp-idf:000][1;31m[mqtt_task][0;36m
13:46:12	[D]	[esp-idf:000][1;31m[mqtt_task][0;36m	E (16782014) TRANSPORT_BASE: Failed to open a new connection: 32772
13:46:12	[D]	[esp-idf:000][1;31m[mqtt_task][0;36m
13:46:12	[D]	[esp-idf:000][1;31m[mqtt_task][0;36m	E (16782017) MQTT_CLIENT: Error transport connect
13:46:12	[D]	[esp-idf:000][1;31m[mqtt_task][0;36m
13:46:12	[E]	[mqtt.idf:162]	MQTT_EVENT_ERROR
13:46:12	[E]	[mqtt.idf:164]	Last error code reported from esp-tls: 0x8004
13:46:12	[E]	[mqtt.idf:165]	Last tls stack error number: 0x0
13:46:12	[E]	[mqtt.idf:167]	Last captured errno : 104 (Connection reset by peer)
13:46:12	[W]	[mqtt:335]	MQTT Disconnected: TCP disconnected.

 

[wannabe]

Sama täällä. Jos nyt oikein muistan, niin 19. päivä klo 14:00

 

[jkoljo]

Suoran HA API yhteyden kautta toimii hienosti.

 

[iro]

Mikähän mitsurunneriini tuli kun iotguruun ei ole ilmestynyt heinäkuun puolivälin jälkeen mitään... runneri on verkossa ja flashasin sen ota:na uusiksi varulta mutta ei muutosta...? Muilla samoja murheita? Töpseli on ollut satunnaisesti irti mutta aina se on sieltä herännyt henkiin

Minulla IoT-Guru näyttäisi toimivan normaalisti (toisessa sovelluksessa kuin Mitsurunner). Pystyykö joku Mitsurunner&IoT-Guru käyttäjä toteamaan että hänellä systeemi pelittää normaalisti.?

 

[iro]

Mikähän mitsurunneriini tuli kun iotguruun ei ole ilmestynyt heinäkuun puolivälin jälkeen mitään... runneri on verkossa ja flashasin sen ota:na uusiksi varulta mutta ei muutosta...? Muilla samoja murheita? Töpseli on ollut satunnaisesti irti mutta aina se on sieltä herännyt henkiin

Mikä Mitsurunnerin versio sinulla on käytössä? Jos Mitsurunerin web-serveri on käytössä mitä logitietoja siellä näkyy?

 

[yOlt]

Täällä ainakin mitsurunner + IoTGuru toimii normaalisti. Oma asennukseni ja kaikki versiot ovat elokuulta 2024. Onko tarvetta tai mitään syytä päivittää jos kaikki toimii?

 

[Nilkkakyy]

Mikä Mitsurunnerin versio sinulla on käytössä? Jos Mitsurunerin web-serveri on käytössä mitä logitietoja siellä näkyy?

En löytänyt versioita mutta näkyy olevan loppuvuodelta 23, silloinhan ei ollut sitä webserveriä vielä käytössä...

 

[Nilkkakyy]

No niin tämä selvisi, vanhassa mitsurunnerissa mqtt brokerina on ip-osoite, uudessa iotguru.cloud, lisäsin manual ip-osastoon dns:n ja vaihdoin brokeriksi tuon iotguru.cloudin ja johan ilmestyi arvot intternettiin!

 

[iro]

No niin tämä selvisi, vanhassa mitsurunnerissa mqtt brokerina on ip-osoite, uudessa iotguru.cloud, lisäsin manual ip-osastoon dns:n ja vaihdoin brokeriksi tuon iotguru.cloudin ja johan ilmestyi arvot intternettiin!

Hyvä että ongelman syy selvisi. Vanhemmissa Mitsurunnerin versioissa käytettiin kiinteää IoT_Gurun ip-osoitetta, ja nyt tuo kiinteä osoite on vaihtunut.
Vanhan version saa toimimaan lisäämällä nykyiseen manual_ip määritykseen dns määrityksen

 manual_ip:  
    static_ip: 192.168.x.yyy
    subnet: 255.255.255.0
    gateway: 192.168.x.1
    dns1: 8.8.8.8        #needed if MQTT-Broker hostname is used instead of IP-adderss

  reboot_timeout: 180min  #WiFi-timeout 180min

ja vaihtamalla IoT-Gurun mqtt-osoite

mqtt:
  broker: iotguru.cloud    # known IPs of iotguru.cloud 116.203.207.226, 195.201.219.208
  id: mqtt_client
  username: ....           # user short identifier
  client_id: ....          # device short identifier
  password: ....           # device key

  reboot_timeout: 180min   #mqtt timeout 180min

NOTE: ESPHome ympäristöä ei kannata päivittää jos haluaa kääntää vanhempia Mitsurunner-versioita. (ESPHome-kääntäjään on matkan varrella tehty muutoksia eivätkä kaikka vanhat YAML-koodit enää käänny).

 

[iro]

Täällä ainakin mitsurunner + IoTGuru toimii normaalisti. Oma asennukseni ja kaikki versiot ovat elokuulta 2024. Onko tarvetta tai mitään syytä päivittää jos kaikki toimii?

Jos/kun kaikki toimii ei kannata päivittää. Uusimmassa versiossa ei ole merkittäviä toiminnallisia muutoksia, siinä on parennettu konfiguroitavuutta erilaisiin ympäristöihin ja yhteensopivuutta uusimpien ESPHome-versioiden kanssa.

 

[iro]

Hyvä että ongelman syy selvisi. Vanhemmissa Mitsurunnerin versioissa käytettiin kiinteää IoT_Gurun ip-osoitetta, ja nyt tuo kiinteä osoite on vaihtunut.
Vanhan version saa toimimaan lisäämällä nykyiseen manual_ip määritykseen dns määrityksen

 manual_ip: 
    static_ip: 192.168.x.yyy
    subnet: 255.255.255.0
    gateway: 192.168.x.1
    dns1: 8.8.8.8        #needed if MQTT-Broker hostname is used instead of IP-adderss

  reboot_timeout: 180min  #WiFi-timeout 180min

ja vaihtamalla IoT-Gurun mqtt-osoite

mqtt:
  broker: iotguru.cloud    # known IPs of iotguru.cloud 116.203.207.226, 195.201.219.208
  id: mqtt_client
  username: ....           # user short identifier
  client_id: ....          # device short identifier
  password: ....           # device key

  reboot_timeout: 180min   #mqtt timeout 180min

NOTE: ESPHome ympäristöä ei kannata päivittää jos haluaa kääntää vanhempia Mitsurunner-versioita. (ESPHome-kääntäjään on matkan varrella tehty muutoksia eivätkä kaikka vanhat YAML-koodit enää käänny).

Samalla kun muutat WiFi- ja MQTT-osuuttaa kannattaa myös pidentää niiden oletusarvoisia 15min timeoutteja.
Jos Wifi- tai MQTT- yhteys puuttuu ja timeout on 15min noin usein tapahtuva resetoituminen sekoittaa Mitsurunnerin toimintaa. Kolmen tunnein resetointivälillä toiminta on huomattavasti parempaa.

Olen editoinut tarvittavat muutokset aiempaan viestiini.

 

[Skibidi Weinau]

Sama täällä. Jos nyt oikein muistan, niin 19. päivä klo 14:00

Täällä kans ollu rapia 11 päivää näköjään IOTguru toimimattomana

 

[Skibidi Weinau]

Hyvä että ongelman syy selvisi. Vanhemmissa Mitsurunnerin versioissa käytettiin kiinteää IoT_Gurun ip-osoitetta, ja nyt tuo kiinteä osoite on vaihtunut.
Vanhan version saa toimimaan lisäämällä nykyiseen manual_ip määritykseen dns määrityksen

 manual_ip:
    static_ip: 192.168.x.yyy
    subnet: 255.255.255.0
    gateway: 192.168.x.1
    dns1: 8.8.8.8        #needed if MQTT-Broker hostname is used instead of IP-adderss

  reboot_timeout: 180min  #WiFi-timeout 180min

ja vaihtamalla IoT-Gurun mqtt-osoite

mqtt:
  broker: iotguru.cloud    # known IPs of iotguru.cloud 116.203.207.226, 195.201.219.208
  id: mqtt_client
  username: ....           # user short identifier
  client_id: ....          # device short identifier
  password: ....           # device key

  reboot_timeout: 180min   #mqtt timeout 180min

NOTE: ESPHome ympäristöä ei kannata päivittää jos haluaa kääntää vanhempia Mitsurunner-versioita. (ESPHome-kääntäjään on matkan varrella tehty muutoksia eivätkä kaikka vanhat YAML-koodit enää käänny).

Hyvin on pelittäny MitsuRunner enkä ole tainnut vuoden 2023 jälkeen päivittää. Hyvä tietää millä muutoksella saa vanhan pelittään. Toisaalta vois päivittää nyt kesäaikaan uusimpaan tulevaa lämmityskautta varten

 

[helmert]

Mullakin tuo tammi-/helmikuussa 2024 asennettu Mitsurunneri alkoi heinäkuussa kitisemään siitä IoT Gurun yhteydestä. On toiminut aivan älyttömän vakaasti (Sonoff Elite) etten mielelläni koskisi tuohon, mutta forcetti buuttausta tuon vuoksi, joten ajoin nyt uusimman sisään ja jätin MQTT:n kokonaan pois. Web serveri taitaa riittää mulle, eikä ainakaan tuolla vanhalla versiolla aiheuttanut mitään vakaushäikkää, vaikka jossain ESPHomen omassa dokumentaatiossa varoiteltiin sen ryöstävän naapurinkin muistit.

Oli vähän taas ihmettelemistä, että miten tätä ajetaan, kun ei ole ihan omaa maaperää tämä tekninen toimintaympäristö ja viimeksi tarvinut koskea puolitoista vuotta sitten. Välissä konekin vaihtunut, joten Pythonit, ESPHomet yms. täytyi asennella uusiksi ja perinteisesti PATHit ja kaikki vituillaan kun sitä ampuu komentoja ennen kuin miettii paria sekuntia

Tähän mennessä käytetty 4 h maksimivetoa ja 4,5 delta-arvoa hyvällä menestyksellä. Pidin deltan nyt samana, mutta nostin maksimijakson viiteen tuntiin.

Mikä tuo web serveriin uutena ilmestynyt "force maximum length" -namiska on? Pahoittelut jos se on tässä ketjussa jo käyty läpi, en äkkiseltään löytänyt ja tuosta koodista tajusin vain sen verran, että nykyisessä on eri statet pitkälle ja normaalille sulatuksella.

 

[puu]

Mikä tuo web serveriin uutena ilmestynyt "force maximum length" -namiska on? Pahoittelut jos se on tässä ketjussa jo käyty läpi, en äkkiseltään löytänyt ja tuosta koodista tajusin vain sen verran, että nykyisessä on eri statet pitkälle ja normaalille sulatuksella.

Pakottaa seuraavasta sulatuksesta maksimipituisen (oliko se nyt 11 minuuttia). Tämä voi olla joskus hyödyllinen ulkokennon sulatukseen.

 

[iro]

Mullakin tuo tammi-/helmikuussa 2024 asennettu Mitsurunneri alkoi heinäkuussa kitisemään siitä IoT Gurun yhteydestä. On toiminut aivan älyttömän vakaasti (Sonoff Elite) etten mielelläni koskisi tuohon, mutta forcetti buuttausta tuon vuoksi, joten ajoin nyt uusimman sisään ja jätin MQTT:n kokonaan pois. Web serveri taitaa riittää mulle, eikä ainakaan tuolla vanhalla versiolla aiheuttanut mitään vakaushäikkää, vaikka jossain ESPHomen omassa dokumentaatiossa varoiteltiin sen ryöstävän naapurinkin muistit.

Oli vähän taas ihmettelemistä, että miten tätä ajetaan, kun ei ole ihan omaa maaperää tämä tekninen toimintaympäristö ja viimeksi tarvinut koskea puolitoista vuotta sitten. Välissä konekin vaihtunut, joten Pythonit, ESPHomet yms. täytyi asennella uusiksi ja perinteisesti PATHit ja kaikki vituillaan kun sitä ampuu komentoja ennen kuin miettii paria sekuntia

Tähän mennessä käytetty 4 h maksimivetoa ja 4,5 delta-arvoa hyvällä menestyksellä. Pidin deltan nyt samana, mutta nostin maksimijakson viiteen tuntiin.

Mikä tuo web serveriin uutena ilmestynyt "force maximum length" -namiska on? Pahoittelut jos se on tässä ketjussa jo käyty läpi, en äkkiseltään löytänyt ja tuosta koodista tajusin vain sen verran, että nykyisessä on eri statet pitkälle ja normaalille sulatuksella.

Mukava tietää että olet tyytyväinen Mitsurunneriin ja sait sen päivitettyä uuteen ESPHome ympäristöön. Kun perus-setup nyt kääntyy ja toimii niin tarvittaessa IoT_Guru on helppo ottaa käyttöön ottamalla käännökseen mukaan mqtt_Guru.yaml tiedosto ja päivittämällä siihen tarvittavat MQTT-parametrit.

 

[helmert]

Jeps, kiitokset vinkistä! Aiempikin setup oli kaltaiselleni tumpelolle kohtuullinen, mutta nyt tuosta conffitiedostosta kun lähtee pläräämään, niin se toimii itsessäänkin jo aika hyvänä asennusohjeena. Tällä hetkellä tuntuu, ettei käppyröiden seuraamiselle ole tarvetta/kiinnostusta, joten riittää kun web serveriltä näkee, että kötöstys toimii ja voi seurata senhetkistä tilaa.

Oma Sonoff vaikuttaa hyvin vakaalta ja se söi tämän uusimman versionkin mukisematta. Nyt uptimeä vasta tältä päivältä 534 min, mutta aiemmin veteli tosiaan niin pitkiä uptimejä, että se IoT Gurun counteri ehti aina nollaantua, joten en jaksanut edes enää seurata. Dallaksiin taas kertyi jännästi ulkolämpötilan funktiona virheitä rajustikin, muttei ole vaikuttanut toimintaan. Nyt kesäkelillä em. muutaman tunnin uptimen aikana 6 virhettä lämmönvaihtimeen ja 0 outdooriin, aiemmasta viestistäni luntaten "kovemmalla pakkasella ehkä se tuhat kappaletta päivässä-parissa ja nollakelillä samat abaut viikossa".

Kaiken kaikkiaan erinomainen viritys ja ei voi olla kuin kiitollinen. Oon eri projekteissa nähnyt jtn Buy Me a Coffee -palveluita ja itselleni hyödyllisiä projekteja mielelläni tukenutkin, joten tarttettais tohon teidän projektisivun kylkeen sellanen Tarjoa Kaljat -nappi


Edit: Tuosta fläshäyksestä asti menty samoilla virroilla, eli reilu 11 vrk. Eiköhän tälläkin päästellä taas ainakin juhannukseen saakka.

 

[juu]

Vinkki Iotgurun käyttäjille: Hälytys sähköpostiin. Huom. nämä hälytykset tieten tulee perille vain jos data kulkee Iotguruun, elikä kaikki toimii normaalisti.

Ei Mitsurunner-esimerkki: Sähkön kulutuksen seuranta - vaiheen kulutus lähentelee maksimia 25A -> hox hox aika tehdä manuaalista kuormanhallintaa.

Kuvassa: Jos arvo on yli 21 niin sähköpostiin tulee hälytys-viesti kerran vuorokaudessa (86 400 sekuntia).

 

[ThingWizard]

Hyvä että ongelman syy selvisi. Vanhemmissa Mitsurunnerin versioissa käytettiin kiinteää IoT_Gurun ip-osoitetta, ja nyt tuo kiinteä osoite on vaihtunut.
Vanhan version saa toimimaan lisäämällä nykyiseen manual_ip määritykseen dns määrityksen

 manual_ip: 
    static_ip: 192.168.x.yyy
    subnet: 255.255.255.0
    gateway: 192.168.x.1
    dns1: 8.8.8.8        #needed if MQTT-Broker hostname is used instead of IP-adderss

  reboot_timeout: 180min  #WiFi-timeout 180min

ja vaihtamalla IoT-Gurun mqtt-osoite

mqtt:
  broker: iotguru.cloud    # known IPs of iotguru.cloud 116.203.207.226, 195.201.219.208
  id: mqtt_client
  username: ....           # user short identifier
  client_id: ....          # device short identifier
  password: ....           # device key

  reboot_timeout: 180min   #mqtt timeout 180min

NOTE: ESPHome ympäristöä ei kannata päivittää jos haluaa kääntää vanhempia Mitsurunner-versioita. (ESPHome-kääntäjään on matkan varrella tehty muutoksia eivätkä kaikka vanhat YAML-koodit enää käänny).

Awesome, yeah as it's getting colder and I started looking at my nodered graphs i realized mitsurunner had been offline for 70 days or something. Need to check my IP. It's just that now my brain has totally forgotten how to program/update mitsurunner I need to go back to the original instructions. Burnout brain, lovely thing...

 

[ThingWizard]

Found my mitsurunner files, Updated broker IP to iotguru.cloud in secrets.yaml and updated. Works! THANK YOU!

In case someone else has forgotten:

1. Find your mitsurunner folder
2. Edit secrets.yaml and change mqtt broker to iotguru.cloud
3. open command prompt and enter esphome run mitsu_conf.yaml
4. The system should update mitsurunner and restart it, as long as the unit is on the network.

 

[Kidov]

Alakerran lämpöpumpussa oleva Mitsurunner on alkanut kesän aikana tippua satunnaisesti linjoilta. Se on ollut käytössä nyt noin kaksi vuotta ja toiminut tähän asti varsin hyvin. Kesällä alkoi satunnaiset katkoset: joskus se oli kateissa tunnin, toisinaan päivän. Tällä hetkellä jälleen katkos meneillään...

Mitsurunner on asennettu lämpöpumpun sisälle ja saman kotelon sisällä on myös puhelimen laturi Wemod d1 minin virtalähteenä. En vielä tiedä onko laturi vai wemos hajonnut/hajoamassa, mutta haluaisin hankkia osat valmiiksi ennen lämpöpumpun avaamista. Pystynkö asentamaan Mitsurunnerin esp32 alustalle, vai pitääkö olla esp8266?

 

[wannabe]

Mulla toisen pumpun runner puksuttaa esp32 laudalla. Runnerin versio nykyistä hiukan vanhempi, mutta tokkopa sillä väliä. Ja onhan Sonoff Eliten alusta esp32. Kun vaihdoin D1 Ministä tuohon 32:een, niin satunnaiset resetit loppui siihen.

 

[iro]

Alakerran lämpöpumpussa oleva Mitsurunner on alkanut kesän aikana tippua satunnaisesti linjoilta. Se on ollut käytössä nyt noin kaksi vuotta ja toiminut tähän asti varsin hyvin. Kesällä alkoi satunnaiset katkoset: joskus se oli kateissa tunnin, toisinaan päivän. Tällä hetkellä jälleen katkos meneillään...

Mitsurunner on asennettu lämpöpumpun sisälle ja saman kotelon sisällä on myös puhelimen laturi Wemod d1 minin virtalähteenä. En vielä tiedä onko laturi vai wemos hajonnut/hajoamassa, mutta haluaisin hankkia osat valmiiksi ennen lämpöpumpun avaamista. Pystynkö asentamaan Mitsurunnerin esp32 alustalle, vai pitääkö olla esp8266?

Näin äkkiseltään en keski syitä miksi Mitsurunneria ei voisi portata esp32-alustalle. Itse asiassa jo nyt Mitsurunnerin Sonoff versio toimii juurinkin ESP32-alustalla.
Porttaaminen ei mielestäni vaadi muuta kuin määritteele käytetyn alustan/kortin ja käytetyt GPIO-nastat "Platform_wemos"-tiedostoon. Käännöksen läpimenon voi helposti varmentaa jo ilman rautaa.

P.S. Kaikille Mitsurunnerin käyttäjille. Nyt on hyvä aika tsekata että Mitsurunner toimii edelleen halutulla tavalla !

 

[akarkkai]

Käänsin Mitsurunnerin Sonoffiin ESP-IDF frameworkillä ja ainakin asentui ilman koodimuutoksia (ESPHome 2025.10.2). IDF tulee oletukseksi ensi vuoden alussa. https://esphome.io/guides/esp32_arduino_to_idf/

Sen saa käyttöön lisäämällä frameworkin platform_elite.yaml tiedostoon

esp32:
  board: nodemcu-32s
  framework:
    type: esp-idf

 

[Kidov]

Kirjoittelin aikaisemmin Wemos D1 minin toimintaongelmista. Muokkasin eilen kytkentää ja siirsin D1 minin talon sisälle. Wemos sijaitsee nyt kellarissa, serverin vieressä hyllyllä, ja saa virtansa serverin usb-portista. Ilmeisesti vika oli virtalähteessä, sillä Wemos toimii jälleen normaalisti.

Lämpöpumpun alapuolella sattui sopivasti kellarin ilmanvaihtoreikä, josta vedin 5m pitkän cat6 kaapelin. Rele jäi edelleen pumpun sisälle, jotta ei tarvitsisi vetää mahdollisesti jännitteistä piuhaa pumpun ulkopuolelle. Vanhalla kytkennällä dallas ds18b20 lämpöantureista kertyi logiin virhelukemia lähes minuutin välein. Muutoksen myötä lukuvirheitä ei ole tullut yhtään. (Uptime nyt 25h.) Noudatin tekoälyn kytkentäohjetta, joka ilmeisesti osui varsin oikeaan: "Paras tapa vähentää häiriöitä on käyttää yhtä paria aina signaalille ja maalle (GND). Koska tarvitsemme 5 johtoa (3.3V, 5V, GND, DS18B20_Data, Relay_Signal), voimme optimoida kytkennän näin:"

 

[wannabe]

Tollasta uptimea. Wifi-signaali heikko ja yhteys pätkii. Pakkosulatukset 480min välein ja noi bootit sotkee välin kellotuksen. Common reboot time on ton 360min ja aattelin, että jos secrets.yaml tiedostosta kommunikois sen pois. Onko isoa haittaa ja jos on, niin millasta? Käppyröitä tulee lämmityskaudella kateltua päivittäin, niin jos jotain häikkää on, niin varsin pian paljastuis. Harkinnassa hommata Mesh-purkki vahvistamaan wifiä, mutta secretin käpelöiminen houkuttaa edullisuutensa vuoksi.

 

[iro]

katso liitettä 110235

Tollasta uptimea. Wifi-signaali heikko ja yhteys pätkii. Pakkosulatukset 480min välein ja noi bootit sotkee välin kellotuksen. Common reboot time on ton 360min ja aattelin, että jos secrets.yaml tiedostosta kommunikois sen pois. Onko isoa haittaa ja jos on, niin millasta? Käppyröitä tulee lämmityskaudella kateltua päivittäin, niin jos jotain häikkää on, niin varsin pian paljastuis. Harkinnassa hommata Mesh-purkki vahvistamaan wifiä, mutta secretin käpelöiminen houkuttaa edullisuutensa vuoksi.

Ennen kun poistat time-out rebootin selvitetään hieman mikä vahtikoira puraisee.

Reboot-timeout vahtii WiFi-yhteyttä sekä MQTT- ja HomeAssistant-yhteyksiä mikäli ne on otettu mukaan Mitsurunner_conf tiedostossa. Jos/kun jakamasi kuvaajan tiedot ovat tulleet WiFi:n kautta WiFi ei aiheuttane reboottia (käsittääksen reboot laukeaa vasta kun WiFi yhteys on ollut yhtäjaksoiseti alkaalla asetetun time-out ajan).

Lähetatkö nyt tiedot IoT-Guru MQTT:lle vai HomeAssistantille ?
* jos MQTT:lle niin HA-base: !include homeassistant.yaml rivi pitää kommentoida pois mitsu_conf.yaml tiedostosta,
* jos HomeAssitantille niin mqtt_base: !include mqtt_disabled.yaml rivi pitää valita mitsu_conf.yaml tiedoston MQTT-osoista.

 

[wannabe]

Sä oot nopee

Some other (local) liene viittaa siihen, jos esim. HA:lle lähtee tiedot, kun ei ole tuota mainitsemaasi HA base....

platform_wemos tiedostossa on:

# Enable/disabe HomeAssistant
api: # !! If home Assistant in use remove comment (#)

Onko tää syyllinen, kun ko. runnerista ei lähetetä tietoa HA:lle (runner on toisaalla, ei mun torpassa)

 

[iro]

Sä oot nopee

katso liitettä 110236

Some other (local) liene viittaa siihen, jos esim. HA:lle lähtee tiedot, kun ei ole tuota mainitsemaasi HA base....

platform_wemos tiedostossa on:

# Enable/disabe HomeAssistant
api: # !! If home Assistant in use remove comment (#)

Onko tää syyllinen, kun ko. runnerista ei lähetetä tietoa HA:lle (runner on toisaalla, ei mun torpassa)

Olinkin toteuttanut tuon toisin kuin muistin. Eli HomeAssistant API käyttö määritellään platform_wemos.yaml tiedostossa. Jos APIa ei käytetä allaoalevat rivit täytyy olla kommentoitu pois käytöstä.

# api:                                       # !! If Home Assistant API is not used delete this line
#   reboot_timeout: 0s                       # !! If Home Assistant API is not used delete this line

Huomasin myös että ohjeistus (myös Mitsurunner Wikissä) on harhaanjohtava, puhutaan HomeAssistantista kun pitäisi puhua HomeAssistant APIsta. Jos käyttää HomeAssistanttia MQTT:n kautta Mitsurunnerissa konfiguroidaan vain MQTT-käyttö.

Jos haluaa priorisoida Mitsurunnerin toimintaa (raportoinnin suhteen) voi platform_wemos.yaml tiedostossa laitaa time-out aikaa pidemmäksi (esim 600min).

substitutions:

# Common reboot timeout for WiFi, MQTT and HomeAssiant. Change value if needed.
  common_reboot_timeout: '360min'

 

[Nimismies]

Moikka!

Ajattelin täältäkin vielä kysellä, kun kiinnostaisi tosiaankin tämä Mitsurunnerin asennus omaan LN-25:een, joka sulattelee tiheästi, mutta osaaminen asennukseen sekä softa- että sähköpuolelta puuttuu kyllä lähes kokonaan. Pahoittelut, jos tätä on jo kyselty, mutta googlailun perusteella ei ainakaan tullut mitään keskustelua asiasta.

Onko näitä kukaan käynyt asentamassa muille korvausta vastaan? Vaatiiko tuo jotenkin jatkuvaa säätämistä asentamisen jälkeenkin? Keski-Suomen suunnalta kyselen.

 

[wannabe]

# api:                                       # !! If Home Assistant API is not used delete this line
#   reboot_timeout: 0s                       # !! If Home Assistant API is not used delete this line

substitutions:

# Common reboot timeout for WiFi, MQTT and HomeAssiant. Change value if needed.
  common_reboot_timeout: '360min'

Kiitos iro