MSZ-LN sulatushuijaus

[HeTi]

Olen käyttänyt Dallasin antureita erilaisissa projekteissa ja ne toimivat yllättävän hyvin.
Olikin melkoinen yllätys kun Esphomen kirjastoissa oli jossain versiossa vikaa ja osa antureista lakkasi toimimasta/ toimi huonosti.
Muutama paine-ero anturi meni myös "not found"-tilaan.
Onneksi en ehtinyt kaikkia laitteita päivittää, muuten muutama lämpötilaohjaus olisi lakannut toimimasta.
Esphomen versio näyttää nyt olevan 2024.2.1

 

[wannabe]

Väliaikatietoa oman Mitsurunnerin reset-tilanteeseen. Kahdeksas vuorokausi menossa ilman resetin resettiä
Alustana Wemos (aito Lolin), jossa mitsurunner_r.yaml pienellä muutoksella, eli muutos kohdassa:
# Temperature sensor (Dallas DS18B20) and its update/measurement interval
dallas:

Tohon laitoin tän vähän vanhemman version:

- id: "DS18B20_a"
pin: $dallas_pin
update_interval: never
- id: "DS18B20_b"
pin: $dallas_pin
update_interval: never

Ihan mutulla vaihdoin ton käyttöön kun edellinen pisin ilman resettiä ollut veto tuli tolla.

Secrets.yaml osiossa käytössä tämä:

#mqtt message prefix, change this to what you want
topic_prefix: non
keepalive: 10s
discovery: false
log_topic: null

Noista dallasin virheistä mulla kans huomio, että sää vaikuttaa virheiden määrään, tai sitten ei juurikaan... jep jep?!?! Kun on selkeästi vaikuttanut, niin päinvastoin kuin helmertillä, eli pakkasella vähemmän ja suojakelillä enemmän . Ihmeelliset ovat virheiden tiet, kuin naisen mieli. Tuo sään vaikutus oli havaittavissa, kun virheitä tuli paljon. Ulkoyksikkö on mulla eteläseinällä, joten aurinko + pilvet saa aikaan aika reipasta lämpötilavaihtelua seinustalla. Jos lämpötilassa oli nopeita muutoksia, niin virheiden määrä kasvoi oli sitten pakkasta tai nollakeliä. Nyt mulla tulee virheitä kennon anturiltan 6 -7/h ja ulkoanturilta hiukan vähemmän. Nuilla määrillä sään vaikutus hukkuu "taustakohinaan". Mitsurunnerin virtalähteen laadulla näyttäs (ehkä - heh heh) olevan vaikutusta virheiden määrään. Ainakin mulla virheiden määrä tippui dramaattisesti vaihtamalla virtalähde. Tolla paremmalla laturilla virheitä tuli aiemmin n. 3/h ja nyt toi 6 - 7/h. Oisko laturi menny pistorasiaan eripäin ku aiemminoli, kun virheet tuplaantui?? Mitsurunner on mulla vaatehuoneessa, niin toi on helppo kokeilla jossain kohtaa onko vaikutusta. Henkimaailman hommia noi virheet, mutta onneksi ne ei vaikuta runnerin toimintaan, toimii erinomaisesti niistä välittämättä.

 

[iro]

Väliaikatietoa oman Mitsurunnerin reset-tilanteeseen. Kahdeksas vuorokausi menossa ilman resetin resettiä
Alustana Wemos (aito Lolin), jossa mitsurunner_r.yaml pienellä muutoksella, eli muutos kohdassa:
# Temperature sensor (Dallas DS18B20) and its update/measurement interval
dallas:

Tohon laitoin tän vähän vanhemman version:

- id: "DS18B20_a"
pin: $dallas_pin
update_interval: never
- id: "DS18B20_b"
pin: $dallas_pin
update_interval: never

Ihan mutulla vaihdoin ton käyttöön kun edellinen pisin ilman resettiä ollut veto tuli tolla.

Mitsurunner_r:yaml:ssä Dallas määrittely on muutettu koska uusin ESPHome-kääntäjä ei hyväksy vanhemmassa versiossa olevaa määrittelyä. Toimintaan sillä ei ole vaikutusta.

Voisiko testauksesi perusteella todeta:
* muutos ei täysin poista restettejä, mutta vähentää huomattavasti niiden esiintymistä
* Dallas lukuvirheiden määrään muutoksella ei ole vaikutusta

 

[wannabe]

Mitsurunner_r:yaml:ssä Dallas määrittely on muutettu koska uusin ESPHome-kääntäjä ei hyväksy vanhemmassa versiossa olevaa määrittelyä. Toimintaan sillä ei ole vaikutusta.

Voisiko testauksesi perusteella todeta:
* muutos ei täysin poista restettejä, mutta vähentää huomattavasti niiden esiintymistä
* Dallas lukuvirheiden määrään muutoksella ei ole vaikutusta

Reseteistä voi kyllä noin todeta. Dallasin lukuvirheiden määrään sanoisin, että jos vaikuttaa, niin niin vähän, että hukkuu soppaan, jonka muut tekijät keittää.

On tullu aika tarkkaan seurattua runnerin toimintaa ja koskaan ei ole menny ilman resettejä näin kauan. Kohta tulee 8 vrk:ta täyteen. Jo noilla aiemmilla muutoksilla resetit väheni ja tää mitsurunner_r sen kun betraa. Hienoa työtä ja kiitos siitä

 

[Raspi]

Näyttää resetit johtuvan myös wifin huonosta tasosta (perstuntuma). Saako runneri jonkun ACKin iotgurulta sanomista ja jos jää puuttumaan niin wmossi resetoituu.
Itselläni ei ole dallas antureiden virheitä himassa eikä mökillä.
Ongelmien välttämiseksi voisi olla hyvä laittaa muutamansadan ESR-lyytti käytettyiden kännylatureiden perään
niistä kun tahtoo tulla hakkurin piikit lävitse.
Himassa korjauksia tehty wifin osalta ja mökillä ajettu sisään päivitetty versio (ei ihan viimeistä korjausta, pitäisikö jo päivittää noi githubin versiot, sai hetken hakea kaikki korjaukset).
Nyt taas seurataan miten hommat pelaa. Ja onhan ne pelannut tähänkin saakka hienosti, asymptoottisesti lähestytään täydellisyyttä

Mökillä uuden sw:n jakelussa tuli virheet, pitisikö olla huolissaan? Vai onko versio ongelma kun pyysi päivittää:

There is a new version 6.1.13 of PlatformIO available.
Please upgrade it via `platformio upgrade` or `pip install -U platformio` command.
Changes: https://docs.platformio.org/en/latest/history.html
*****************************************************************************************

errors:

esp8266_copy_factory_bin([".pioenvs\mitsurunner\firmware.bin"], [".pioenvs\mitsurunner\firmware.elf"])
========================================================================== [SUCCESS] Took 21.48 seconds ==========================================================================
INFO Successfully compiled program.
INFO Connecting to 10.0.0.10
INFO Uploading .esphome/build/mitsurunner\.pioenvs\mitsurunner\firmware.bin (450064 bytes)
INFO Compressed to 310583 bytes
Uploading: [============================================================] 100% Done...

INFO Waiting for result...
INFO OTA successful
INFO Successfully uploaded program.
Traceback (most recent call last):
File "<frozen runpy>", line 198, in _run_module_as_main
File "<frozen runpy>", line 88, in _run_code
File "C:\Users\ile\AppData\Local\Programs\Python\Python311\Scripts\esphome.exe\__main__.py", line 7, in <module>
File "C:\Users\ile\AppData\Local\Programs\Python\Python311\Lib\site-packages\esphome\__main__.py", line 963, in main
return run_esphome(sys.argv)
^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\ile\AppData\Local\Programs\Python\Python311\Lib\site-packages\esphome\__main__.py", line 950, in run_esphome
rc = POST_CONFIG_ACTIONS[args.command](args, config)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\ile\AppData\Local\Programs\Python\Python311\Lib\site-packages\esphome\__main__.py", line 422, in command_run
return show_logs(config, args, port)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\ile\AppData\Local\Programs\Python\Python311\Lib\site-packages\esphome\__main__.py", line 317, in show_logs
return mqtt.show_logs(
^^^^^^^^^^^^^^^
File "C:\Users\ile\AppData\Local\Programs\Python\Python311\Lib\site-packages\esphome\mqtt.py", line 105, in show_logs
topic = config[CONF_MQTT][CONF_LOG_TOPIC][CONF_TOPIC]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^
TypeError: 'NoneType' object is not subscriptable

C:\Users\

 

[iro]

Näyttää resetit johtuvan myös wifin huonosta tasosta (perstuntuma). Saako runneri jonkun ACKin iotgurulta sanomista ja jos jää puuttumaan niin wmossi resetoituu.
Itselläni ei ole dallas antureiden virheitä himassa eikä mökillä.
Ongelmien välttämiseksi voisi olla hyvä laittaa muutamansadan ESR-lyytti käytettyiden kännylatureiden perään
niistä kun tahtoo tulla hakkurin piikit lävitse.
Himassa korjauksia tehty wifin osalta ja mökillä ajettu sisään päivitetty versio (ei ihan viimeistä korjausta, pitäisikö jo päivittää noi githubin versiot, sai hetken hakea kaikki korjaukset).
Nyt taas seurataan miten hommat pelaa. Ja onhan ne pelannut tähänkin saakka hienosti, asymptoottisesti lähestytään täydellisyyttä

Mökillä uuden sw:n jakelussa tuli virheet, pitisikö olla huolissaan? Vai onko versio ongelma kun pyysi päivittää:

There is a new version 6.1.13 of PlatformIO available.
Please upgrade it via `platformio upgrade` or `pip install -U platformio` command.
Changes: https://docs.platformio.org/en/latest/history.html
*****************************************************************************************

errors:

esp8266_copy_factory_bin([".pioenvs\mitsurunner\firmware.bin"], [".pioenvs\mitsurunner\firmware.elf"])
========================================================================== [SUCCESS] Took 21.48 seconds ==========================================================================
INFO Successfully compiled program.
INFO Connecting to 10.0.0.10
INFO Uploading .esphome/build/mitsurunner\.pioenvs\mitsurunner\firmware.bin (450064 bytes)
INFO Compressed to 310583 bytes
Uploading: [============================================================] 100% Done...

INFO Waiting for result...
INFO OTA successful
INFO Successfully uploaded program.
Traceback (most recent call last):
File "<frozen runpy>", line 198, in _run_module_as_main
File "<frozen runpy>", line 88, in _run_code
File "C:\Users\ile\AppData\Local\Programs\Python\Python311\Scripts\esphome.exe\__main__.py", line 7, in <module>
File "C:\Users\ile\AppData\Local\Programs\Python\Python311\Lib\site-packages\esphome\__main__.py", line 963, in main
return run_esphome(sys.argv)
^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\ile\AppData\Local\Programs\Python\Python311\Lib\site-packages\esphome\__main__.py", line 950, in run_esphome
rc = POST_CONFIG_ACTIONS[args.command](args, config)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\ile\AppData\Local\Programs\Python\Python311\Lib\site-packages\esphome\__main__.py", line 422, in command_run
return show_logs(config, args, port)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\ile\AppData\Local\Programs\Python\Python311\Lib\site-packages\esphome\__main__.py", line 317, in show_logs
return mqtt.show_logs(
^^^^^^^^^^^^^^^
File "C:\Users\ile\AppData\Local\Programs\Python\Python311\Lib\site-packages\esphome\mqtt.py", line 105, in show_logs
topic = config[CONF_MQTT][CONF_LOG_TOPIC][CONF_TOPIC]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^
TypeError: 'NoneType' object is not subscriptable

C:\Users\

Oletusarvoisesti Wemos resetoituu jos WiFi-tai MQTT-yhteys on poikki yli 15min. En sitten tiedä tuleeko resettejä myös jos/kun lähetyspuskurit täyttyvät WiFi- tai MQTT-yhteyksien pätkiessä.

Käsittääkseni nuo mainitsemasi virheilmoitukset johtuvat siitä että ESPHome-sovellus yrittää hakea MQTT-trace-logeja, mutta niitä ei löydy koska niiden lähetys on poistettu. Eli ei "oikea" ongelma, mutta tuo hämäävä virheilmoitus kyllä pitäisi saada pois.

@puu , onko sinulla ajausta millaisia versioita GitHub:iin kannattaisi viedä ?

 

[Raspi]

Virittelin reset-testiversion viidelle Dallasille. Heat_exchanger- ja Outdoor-antureita luetaan viiden sekunnin välein, muita antureita 15 sekunnin välein. Minulla hetimiten käynnistyksen jälkeen tuli yksi reset, sitten pysynyt pystyssä kolmisen vuorokautta

Kaikki muutokset ennen tätä ovat testien mukaan parantaneet luotettavuutta, eli nyt voisi luoda seuraavan stabiilin sw:n.
katsotaan siitä taas sitten etiäppäin....

 

[puu]

Mergesin GitHubissa nyt tuon viimeisimmän pull requestini (lisää manuaalisen sulatuksen ja pitkän sulatuksen) ja lisäsin siihen @iro :n ehdottamat muutokset tuohon secrets.yamliin.

Jos joku haluaa tehdä noille dallaseille (resettien suhteen) jotain, niin saa suorittaa. Itselläni ei ole nyt aikaa oikein aikaa sen ihmettelyyn sen enempää, kuin että mielelläni katselmoin, jos siihen joku tekee muutoksia.

 

[iro]

Mergesin GitHubissa nyt tuon viimeisimmän pull requestini (lisää manuaalisen sulatuksen ja pitkän sulatuksen) ja lisäsin siihen @iro :n ehdottamat muutokset tuohon secrets.yamliin.

Jos joku haluaa tehdä noille dallaseille (resettien suhteen) jotain, niin saa suorittaa. Itselläni ei ole nyt aikaa oikein aikaa sen ihmettelyyn sen enempää, kuin että mielelläni katselmoin, jos siihen joku tekee muutoksia.

Yritän lähipäivinä lisätä manuaalisen sulatusosuuden myös Sonoff Elite haaraan.

Mitä mieltä olet, voisiko dallas/ reset virityksen lisätä perusversioon vai pitäiskö sille tehdä oma haara ? ( Kahdella Dallasilla tuo toimii kuten perusversio mutta lisä-Dallasen liitäminen vaatii hieman askartelua).

 

[puu]

Mieluiten joka tapauksessa oma haara. Jos se todetaan hyväksi ja tarpeelliseksi suurimmalle osalle, voi siitä tehdä pull requestin päähaaraan.

Itselläni on tosiaan 5-6 dallas-anturia käytössä, niin se ei vastaa ihan tuota perustapausta ja muutenkin koodini on omassa repossaan githubissa, niin en tiedä jaksanko itse ottaa tuota käyttöön kun eivät ole resetit varsinaisesti haitaksi asti riivanneet.

 

[iro]

Olen värkkäämässä GitHubiin uutta Mitsurunner_Elite versiota @puu :n uusimman Wemos-version päälle. Onko Elite-käyttäjillä toiveita lisämuutoksista. (Wemos-päivityksessä on jo mukana mahdollisuus saada logi näkyviin MQTT-yhteyden yli myös IoT-Guru käyttäjille) ?

Missä määrin Eliteen tule resettejä ja onko joku kokeillut vaikuttaako aiemmin palstalla esitetty Dallas-antureiden erilainen käsittely muutosta reset-tiheyteen Elite-ympäristössä ?

 

[wannabe]

Väliaikatietoa oman Mitsurunnerin reset-tilanteeseen. Kahdeksas vuorokausi menossa ilman resetin resettiä
Alustana Wemos (aito Lolin), jossa mitsurunner_r.yaml pienellä muutoksella, eli muutos kohdassa:
# Temperature sensor (Dallas DS18B20) and its update/measurement interval
dallas:

Tohon laitoin tän vähän vanhemman version:

- id: "DS18B20_a"
pin: $dallas_pin
update_interval: never
- id: "DS18B20_b"
pin: $dallas_pin
update_interval: never

Ihan mutulla vaihdoin ton käyttöön kun edellinen pisin ilman resettiä ollut veto tuli tolla.

Secrets.yaml osiossa käytössä tämä:

#mqtt message prefix, change this to what you want
topic_prefix: non
keepalive: 10s
discovery: false
log_topic: null

Hyvin menee, mutta menköön! 10 vrk täynnä viimeisimmästä resetistä ja kohti yhdettätoista jne.... Edellinen resettien väli oli himpan päälle 8 vrk. Tylsäksi menee Mitsun kyttääminen ku pelaa ku unelma, eikä edes resettejä tahdo tulla

 

[akarkkai]

Olen värkkäämässä GitHubiin uutta Mitsurunner_Elite versiota @puu :n uusimman Wemos-version päälle. Onko Elite-käyttäjillä toiveita lisämuutoksista. (Wemos-päivityksessä on jo mukana mahdollisuus saada logi näkyviin MQTT-yhteyden yli myös IoT-Guru käyttäjille) ?

Missä määrin Eliteen tule resettejä ja onko joku kokeillut vaikuttaako aiemmin palstalla esitetty Dallas-antureiden erilainen käsittely muutosta reset-tiheyteen Elite-ympäristössä ?

Minulla ei ole vieläkään tullut yhtään resettiä eliteen, mutta dallas säätö on ollut alusta asti ja en käytä MQTT-yhteyttä. Vaihdoin nyt testimielessä dallasit yhden 'hubin' alle.

 

[iro]

Minulla ei ole vieläkään tullut yhtään resettiä eliteen, mutta dallas säätö on ollut alusta asti ja en käytä MQTT-yhteyttä. Vaihdoin nyt testimielessä dallasit yhden 'hubin' alle.

Elitessä resetoitumista tapahtuu harvemmin kuin Wemos-pohjaisessa laitteessa, mutta vaikuttaa siltä, että sinulla resettejä ei tule lainkaan.
Muistaakseni käytät MQTT:n sijasta Home AssistantAPIa, siinä kommunikointi taitaa kulkea HTTP-viesteinä?
Meneekö sinulla Home Assesiant serverille samat tiedot mitä lähetetään MQTT-serverille, myös degug-logi?
Mielenkiintoista nähdä onko Dallas-muutoskella vaikutusta toimintaan.

 

[Kidov]

Huomasin jokin aika sitten, että ESPHome tukee Home Assistant API:n ja MQTT:n käyttämistä samaan aikaan. Home Assistant API mahdollistaa esim. sulatuksen pakkokäynnistyksen sekä maksimipituisen sulatuksen liipaisut suoraan Home Assistantista.

Ohessa liitteenä kuvaruutukaappaus Mitsurunnerin näkymästä Home Assistantissa. (Käytän erillisiä Wemos D1 minejä sisäyksiköiden puhalluslämpötilojen mittaukseen.)

Edit. Lisäyksenä, että käytän edelleen IoT Gurua lämpötilaseurantaan kotiverkon ulkopuolella. Home Assistant toistaiseksi käytössä ainoastaan sisäverkossa. Home Assistant API:n saa otettua käyttöön lisäämällä platform.yaml tiedostoon:
#Enable Home Assistant API
api:
Lisäksi secrets.yaml tiedostossa MQTT määritysten yhteydessä on hyvä olla käytössä discovery: false. (Home Assistant voi muutoin nähdä Mitsurunnerin tuplana.)

 

[akarkkai]

Elitessä resetoitumista tapahtuu harvemmin kuin Wemos-pohjaisessa laitteessa, mutta vaikuttaa siltä, että sinulla resettejä ei tule lainkaan.
Muistaakseni käytät MQTT:n sijasta Home AssistantAPIa, siinä kommunikointi taitaa kulkea HTTP-viesteinä?
Meneekö sinulla Home Assesiant serverille samat tiedot mitä lähetetään MQTT-serverille, myös degug-logi?
Mielenkiintoista nähdä onko Dallas-muutoskella vaikutusta toimintaan.

Juu - käytän home assistantin apia. report_timer_status ei ole käytössä. Muut arvot siirtyvät automaattisesti home assistanttiin. ESPHomen HA APIssa taitaa muuten olla sama 15min resetti kuin MQTTssä.
ESPHome toimii kätevästi supervised home assistantin kanssa pluginissa jolloin se pitää myös esphomen sekä kaikki clientit päivitettyinä.

Dallasin virheitä tulee runsaasti. Näillä ei näyttäisi olevan yhteyttä resetoitumiseen.

 

[wannabe]

Hyvin menee, mutta menköön! 10 vrk täynnä viimeisimmästä resetistä ja kohti yhdettätoista jne.... Edellinen resettien väli oli himpan päälle 8 vrk. Tylsäksi menee Mitsun kyttääminen ku pelaa ku unelma, eikä edes resettejä tahdo tulla

Päivitystä tuohon edelliseen viestiini. Wemos oli yöllä räpänny resetin, joten rapia 13 vuorokautta ilman resettiä. Käytössä kaikki viimeisimmät softamuunnokset.

 

[iro]

@puu, liittessä muuttuneet fileet mitsurunner-versioiden yhdistämiseen.

Tiedoksi muille Mitsurunner-harrastajille: Ylläpidon helpottamiseski GitHubissa erilliset Wemos ja Sonoff-Elite haarat yhdistetään, ja Wikin Mitsurunnert.com ohjeistus tuolta osin päivitetään. Kun peruversio on yhdistetty GitHubiin tehdään myös veriso jossa resetoitumista on pyritty vähentämään.

 

[Raspi]

Laitoin reilu viikko sitten mökille uutta softaaa ja kuvasta näkee, että muutos on ressujen suhteen huomattava.

 

[iro]

Laitoin reilu viikko sitten mökille uutta softaaa ja kuvasta näkee, että muutos on ressujen suhteen huomattava.

Millainen verkkoyhteys sinulla on mökillä ? Jos MQTT_trace-login lähetys on nyt pois niin Dallas-muutosten lisäksi myös MQTT-kuorma on merkittävästi aiempaa piemempi.

 

[Raspi]

4G yhteys, ja masto näkyy tontille sekä mitsurunneri n. 2m wifi antennista hirsiseinän takana, eli RF-puoli lähes erinomainen.

 

[puu]

Tein nyt pull requestin tuosta @iro :n zipistä.

Kääntäessä huomasin, että nyt kun tuolla secrets.yaml:ssa on mqtt:n alla:

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

Tulee käännöksessä virheet, kun ei tykkää noista null-arvoista:

string value is None.
  topic_prefix:
  log_topic:
  discovery: False

Kommenttien perusteella ymmärtäisin, että Guru haluaisi nuo nulliksi, mutta ei kuitenkaan käänny noin. Miten tämän pitäisi olla? Itse en Gurua käytä, niin en osaa sanoa.

 

[puu]

Sonoff Eliten käännöksessä tulee varoitukset kahdesta GPIO-pinnistä, joita käytetään strap-pinneinä. Ovatko Sonoffin käyttäjät tutkineet, että näitä pinnejä on turvallista käyttää kuten MitsuRunnnerissa niitä käytetään?

WARNING GPIO4 is a Strapping PIN and should be avoided.
Attaching external pullup/down resistors to strapping pins can cause unexpected failures.
See https://esphome.io/guides/faq.html#why-am-i-getting-a-warning-about-strapping-pins
WARNING GPIO15 is a Strapping PIN and should be avoided.
Attaching external pullup/down resistors to strapping pins can cause unexpected failures.
See https://esphome.io/guides/faq.html#why-am-i-getting-a-warning-about-strapping-pins

Tuolla warningin linkkaamalla sivulla sanotaan: "Strapping pins should be safe to use as outputs if they are only connected to other devices that have hi-impedance inputs with no pull-up or pull-down resistors. Note that I2C clock and data lines do have pull-up resistors and are not safe on strapping pins."

Käytetäänkö tuota GPIO15 eli yellow_led edes mihinkään, näyttäisi että ei? Ainakin kääntyy, vaikka poistan sen määrittelyn. Sen poistamalla saisi toisen yhden warningin poistettua.

GPIO4 taas käytetään huijausreleelle, se on oletettavasti suhteellisen korkeaimpedanssinen, kun siellä on oletettavasti joku FET kytkemässä relettä. Toki joku pull-up/down silläkin täytyy olla, mutta ehkä sekin on riittävän korkealla resistanssila (impedanssilla).

Tuolla ohjeessahan on myös kommentti: "If you are absolutely sure that your use of strapping pins is safe, and want to suppress the warning, you can add ignore_strapping_warning: true to the relevant pin configurations." Eli jos tosiaan ollaan täysin varmoja, että tuon GPIO4 käyttö relettä ajavan transistorin ohjaukselle on turvallista, niin voidaan ehkä sitten laittaa tuo ignore-määritys sinne. On aina siistimpää, jos ei ole warningeja käännöksessä.

 

[iro]

Sonoff Eliten käännöksessä tulee varoitukset kahdesta GPIO-pinnistä, joita käytetään strap-pinneinä. Ovatko Sonoffin käyttäjät tutkineet, että näitä pinnejä on turvallista käyttää kuten MitsuRunnnerissa niitä käytetään?

WARNING GPIO4 is a Strapping PIN and should be avoided.
Attaching external pullup/down resistors to strapping pins can cause unexpected failures.
See https://esphome.io/guides/faq.html#why-am-i-getting-a-warning-about-strapping-pins
WARNING GPIO15 is a Strapping PIN and should be avoided.
Attaching external pullup/down resistors to strapping pins can cause unexpected failures.
See https://esphome.io/guides/faq.html#why-am-i-getting-a-warning-about-strapping-pins

Tuolla warningin linkkaamalla sivulla sanotaan: "Strapping pins should be safe to use as outputs if they are only connected to other devices that have hi-impedance inputs with no pull-up or pull-down resistors. Note that I2C clock and data lines do have pull-up resistors and are not safe on strapping pins."

Käytetäänkö tuota GPIO15 eli yellow_led edes mihinkään, näyttäisi että ei? Ainakin kääntyy, vaikka poistan sen määrittelyn. Sen poistamalla saisi toisen yhden warningin poistettua.

GPIO4 taas käytetään huijausreleelle, se on oletettavasti suhteellisen korkeaimpedanssinen, kun siellä on oletettavasti joku FET kytkemässä relettä. Toki joku pull-up/down silläkin täytyy olla, mutta ehkä sekin on riittävän korkealla resistanssila (impedanssilla).

Tuolla ohjeessahan on myös kommentti: "If you are absolutely sure that your use of strapping pins is safe, and want to suppress the warning, you can add ignore_strapping_warning: true to the relevant pin configurations." Eli jos tosiaan ollaan täysin varmoja, että tuon GPIO4 käyttö relettä ajavan transistorin ohjaukselle on turvallista, niin voidaan ehkä sitten laittaa tuo ignore-määritys sinne. On aina siistimpää, jos ei ole warningeja käännöksessä.

Hyviä havaintoja.

MQTT-logien osalta Esphome Python sovellus ei osaa huomioida "log_tropic: null" parametria . Käännös ja flashays menevät oiken mutta sen jälkeen Esphome MQTT-client konfigurointi ei onnistu. Ylimääräiset herjat saa pois tekemällä käännöksen komennolla esphome run --no-logs mitsurunner.yaml. Ajattelin ohjeistaa tuon Mitsurunner.com Wiki ohjeistuksessa.

Sonoff_Eliten PIN-herjat (platform_elite.yaml)
* GPIO15-PIN määrittelyn otin mukaan jotta yellow-LED olisi helppo ottaa käyttöön myöhemmin jos sille ilmenee tarvetta. Jätetään tuo pois.
* GPIO4-PIN (huijausrele) ei aiheuta ongelmia
* GPIO5-PIN on näytön data-PIN, näyttön ohjauskoodi on kopioitu esphome TM1621_display ohjeesta. Tuolle voi laittta ignore_strapping_warning: true
==> herja jäävät pois
Alla muutos paltform_elite_ymal display-osioon.

display:
  platform: tm1621
  id: tm1621_display
  update_interval: 5s
  cs_pin: GPIO17
  data_pin:
    number: GPIO5
    ignore_strapping_warning: true
  read_pin: GPIO23
  write_pin: GPIO18

 

[iro]

MQTT-logien osalta Esphome Python sovellus ei osaa huomioida "log_tropic: null" parametria . Käännös ja flashays menevät oiken mutta sen jälkeen Esphome MQTT-client konfigurointi ei onnistu. Ylimääräiset herjat saa pois tekemällä käännöksen komennolla esphome run --no-logs mitsurunner.yaml. Ajattelin ohjeistaa tuon Mitsurunner.com Wiki ohjeistuksessa.

@puu , koska käyttöohjeet kuitenkin jäävät lukematta niin ohjerivin voisi lisätä secrets.yaml IoT-Guru MQTT-osioon

############## IoT-Guru ##################################################
# In case of you use IoT Guru ( https://iotguru.cloud ), uncomment and use data below.
# Check correct values from your IoT Guru account
# NOTE1: IoT Guru does not support trace-log over MQTT, eg. USB-connection is needed for trace log.
# NOTE2: When using IoT-Guru and OTA, use compile-command "esphome run --no-logs mitsurunner.yaml" (instead of "esphome run mitsurunner.yaml")

 

[puu]

Sonoff_Eliten PIN-herjat (platform_elite.yaml)
* GPIO15-PIN määrittelyn otin mukaan jotta yellow-LED olisi helppo ottaa käyttöön myöhemmin jos sille ilmenee tarvetta. Jätetään tuo pois.
* GPIO4-PIN (huijausrele) ei aiheuta ongelmia
* GPIO5-PIN on näytön data-PIN, näyttön ohjauskoodi on kopioitu esphome TM1621_display ohjeesta. Tuolle voi laittta ignore_strapping_warning: true
==> herja jäävät pois

Ihmettelin, miksi mulla herjaa tuosta GPIO4 mutta GPIO5 ei. Myöskään tuo ignore_strapping_warning ei toiminut. Sitten huomasin, että ESPHome:n versio on 2022.9. Sepä ei tahtonut päivittyä, ja syyksi totesin, että Python-versio oli vanha 3.8, jota ilmeisesti uudemmat ESPHomen versiot eivät tue. No, käärmeelle päivitys ja sitten espikodille, niin alkoi rullaamaan. Myös noi null-arvot menivät sitten läpi.

Päivitin nyt tuota pull requestia @iro :n kommenttien perusteella: https://github.com/VeliML/MitsuRunner/pull/37
Kun saadaan tuo mergettyä ja todettua, että kaikki on OK, voisi ehkä olla aika vihdoin julkaista release v1.0.

 

[iro]

Ihmettelin, miksi mulla herjaa tuosta GPIO4 mutta GPIO5 ei. Myöskään tuo ignore_strapping_warning ei toiminut. Sitten huomasin, että ESPHome:n versio on 2022.9. Sepä ei tahtonut päivittyä, ja syyksi totesin, että Python-versio oli vanha 3.8, jota ilmeisesti uudemmat ESPHomen versiot eivät tue. No, käärmeelle päivitys ja sitten espikodille, niin alkoi rullaamaan. Myös noi null-arvot menivät sitten läpi.

Päivitin nyt tuota pull requestia @iro :n kommenttien perusteella: https://github.com/VeliML/MitsuRunner/pull/37
Kun saadaan tuo mergettyä ja todettua, että kaikki on OK, voisi ehkä olla aika vihdoin julkaista release v1.0.

Laitoin muutoksille OK merkinnän dithubiin

 

[puu]

Mergesin. Nyt vaan sitten jotkut nohevat MitsuRunner-taistelijat voisivat testata, että tuorein versio tomii Sonoffilla ja Wemoksella.

 

[iro]

Mergesin. Nyt vaan sitten jotkut nohevat MitsuRunner-taistelijat voisivat testata, että tuorein versio tomii Sonoffilla ja Wemoksella.

Tässä pikaohjeet Mitsurunneri päivittämiseen (ennekuin saan tehtyä päivityksen Mitsurunner Wikiin)

1) Hae uusin Mitsurunner-versio Githubista ja päivitä .yaml tiedostoja seuraavasti:

2) Mitsurunner.yaml: käyttämäsi ympäristön mukaisesti valitse sopiva include tiedosto
#<<: !include platform_wemos.yaml
<<: !include platform_elite.yaml

3) Secrets.yaml tiedostoon kopioi tarvittavat tiedot aiemmin käyttämistäsi secrets.yaml ja platform.yaml tiedostoista.

4) Käyttämäsi ympäristön mukaisesti editoi joko platform_wemos.yaml tai platform_elite.yaml tiedostoa kopioimalla sinne tarvittavat tiedot aiemmin käyttämästäsi platform.yaml tiedostosta.

5) Käännä ja flashaa, testaa toiminta.
Jos käytät IoT-Gurua ja OTA-päivitystä käännä komennolla "esphome run --no-logs mitsurunner.yaml" niin flashayksen jälkeen ei tule turhia virheilmoituksia.

Dallas-muutoksia joilla pyritään vähentämään resettejä ei ole tässä mukaan, tulevat myöhemmin Githubiin.
Ohessa kuitenkin "pöydän alta" jakoon mitsurunner.yaml versio jossa tuo on mukana (tarvittaavat muutokset on tehty uusimman mitsurunner.yaml;:n päälle). Saat fixin käyttämällä tätä alkuperäisen mitsurunner.yaml:n sijasta (myös tähän täytyy tehdä edelläkuvattu platform valinta).

 

[akarkkai]

Elitessä resetoitumista tapahtuu harvemmin kuin Wemos-pohjaisessa laitteessa, mutta vaikuttaa siltä, että sinulla resettejä ei tule lainkaan.
Muistaakseni käytät MQTT:n sijasta Home AssistantAPIa, siinä kommunikointi taitaa kulkea HTTP-viesteinä?
Meneekö sinulla Home Assesiant serverille samat tiedot mitä lähetetään MQTT-serverille, myös degug-logi?
Mielenkiintoista nähdä onko Dallas-muutoskella vaikutusta toimintaan.

11vrk mennyt eikä resettiä. ESP32sella ei siis tarvitse synkronoitua dallasien lukemista, mutta eipä siitä ollut haittaakaan. Home assistant päivitti juuri esphomen versioon 2024.3 joten uptime nollautui.
Mulla alkoi jossain vaiheessa antamaan kääntäjä virhettä scriptin initialize tuplanimestä. Voi liittyä uuteen esphome versioon tai hass apiin. Korjaantui vaihtamalla scriptin nimi uniikiksi eli initialize_mitsurunner tjsp.

esp-idf-public/components/libsodium/libsodium/src/libsodium/crypto_pwhash/argon2/argon2-core.c:477: multiple definition of `initialize';

 

[puu]

Mulla alkoi jossain vaiheessa antamaan kääntäjä virhettä scriptin initialize tuplanimestä. Voi liittyä uuteen esphome versioon tai hass apiin. Korjaantui vaihtamalla scriptin nimi uniikiksi eli initialize_mitsurunner tjsp.

esp-idf-public/components/libsodium/libsodium/src/libsodium/crypto_pwhash/argon2/argon2-core.c:477: multiple definition of `initialize';

Erikoista, tuolta libsodium-reposta ei löydy (ainakaan masterista) tuota initialize-nimeä suoraan:

libsodium/src/libsodium/crypto_pwhash/argon2/argon2-core.c at master · jedisct1/libsodium

A modern, portable, easy to use crypto library. Contribute to jedisct1/libsodium development by creating an account on GitHub.

github.com

 

[iro]

11vrk mennyt eikä resettiä. ESP32sella ei siis tarvitse synkronoitua dallasien lukemista, mutta eipä siitä ollut haittaakaan. Home assistant päivitti juuri esphomen versioon 2024.3 joten uptime nollautui.
Mulla alkoi jossain vaiheessa antamaan kääntäjä virhettä scriptin initialize tuplanimestä. Voi liittyä uuteen esphome versioon tai hass apiin. Korjaantui vaihtamalla scriptin nimi uniikiksi eli initialize_mitsurunner tjsp.

esp-idf-public/components/libsodium/libsodium/src/libsodium/crypto_pwhash/argon2/argon2-core.c:477: multiple definition of `initialize';

Muistaaksen minäkin havaitsin että Elitelssä (esp32-patform) resettejä esiiintyy selvästi vähemmän kuin Wemos (esp8266-platform)-laitteissa. Paljon mahdollista että Dallas-kikkailulla ei ole merkitystä Elitessä.

 

[akarkkai]

Erikoista, tuolta libsodium-reposta ei löydy (ainakaan masterista) tuota initialize-nimeä suoraan:

libsodium/src/libsodium/crypto_pwhash/argon2/argon2-core.c at master · jedisct1/libsodium

A modern, portable, easy to use crypto library. Contribute to jedisct1/libsodium development by creating an account on GitHub.

github.com

Näköjään jo 2019 muuttaneet vähemmän geneeriseksi nimen:
https://github.com/jedisct1/libsodium/commit/9f14962388ceb795114405ba8f7af59d5bc43b1b

Tuo virhe tulee linkatessa platformio:n valmiiksi käännettyyn kirjastoon. En ole kokeillut puhtaalla esphomella, mutta hass plugin antaa:

/data/cache/platformio/packages/framework-arduinoespressif32/tools/sdk/esp32/lib/liblibsodium.a(argon2-core.c.obj): in function `initialize':
/Users/ficeto/Desktop/ESP32/ESP32S2/esp-idf-public/components/libsodium/libsodium/src/libsodium/crypto_pwhash/argon2/argon2-core.c:477: multiple definition of `initialize';

 

[iro]

@puu, löysi tavan saada myös modifioitu Dallas-antureiden käsittely mukaan mitsurunner main-haaraan.
Erotin Dallas-antureiden käsittelyn omaksi "package'ksi", includasin paketin mitasurunner.yaml tiedostoon ja poistin Dallas-koodin sieltä.
Tein erillistet Dallas-paketit "Dallas_basic" ja "Dallas_hub". Mitsurunner.yaml:ssä voidaan valita kumpi pakettii otetaan mukaan.

 

[Raspi]

Testaan pakettia kuhan toi nykyinen ohjelmistoni resetoituisi.... nyt yli 2vk ilman ressuja eikä dallas virheitä (vmossu)

 

[puu]

@puu, löysi tavan saada myös modifioitu Dallas-antureiden käsittely mukaan mitsurunner main-haaraan.
Erotin Dallas-antureiden käsittelyn omaksi "package'ksi", includasin paketin mitasurunner.yaml tiedostoon ja poistin Dallas-koodin sieltä.
Tein erillistet Dallas-paketit "Dallas_basic" ja "Dallas_hub". Mitsurunner.yaml:ssä voidaan valita kumpi pakettii otetaan mukaan.

Nyt on pull requesti tästä: https://github.com/VeliML/MitsuRunner/pull/39
Käykää (ainakin @iro) vilkaisemassa, että on OK.

 

[iro]

Nyt on pull requesti tästä: https://github.com/VeliML/MitsuRunner/pull/39
Käykää (ainakin @iro) vilkaisemassa, että on OK.

Muutokset OK, voi mergetä Olen nyt päivittänyt myös Mitsurunner Wiki ohjeet vastaaman noita muutoksia.

 

[wannabe]

Muistaaksen minäkin havaitsin että Elitelssä (esp32-patform) resettejä esiiintyy selvästi vähemmän kuin Wemos (esp8266-platform)-laitteissa.

Aiemmista viesteistä minullekin oli jäänyt sama mielikuva ja sen innoittamana viimeisimmän wemos-resetin jälkimainingeissan virittelin esp32 Mitsurunnerin. Tyrkkäsin siihen prikulleen saman ohjemiston kuin Wemoksessa oli, eli mitsurunner_r ja Secrets.yaml osiossa käytössä tämä:

#mqtt message prefix, change this to what you want
topic_prefix: non
keepalive: 10s
discovery: false
log_topic: null

Wemos jaksoi resetoitumatta tuolla softalla joitain tunteja vaille 2 viikkoa. ESP32-runnerilla mennään nyt neljättä viikkoa ilman resettiä ja usko on kova, että ilman resettejä mennään vielä juhannuksen räntäsateetkin ja ylikin.

 

[iro]

Aiemmista viesteistä minullekin oli jäänyt sama mielikuva ja sen innoittamana viimeisimmän wemos-resetin jälkimainingeissan virittelin esp32 Mitsurunnerin. Tyrkkäsin siihen prikulleen saman ohjemiston kuin Wemoksessa oli, eli mitsurunner_r ja Secrets.yaml osiossa käytössä tämä:

#mqtt message prefix, change this to what you want
topic_prefix: non
keepalive: 10s
discovery: false
log_topic: null

Wemos jaksoi resetoitumatta tuolla softalla joitain tunteja vaille 2 viikkoa. ESP32-runnerilla mennään nyt neljättä viikkoa ilman resettiä ja usko on kova, että ilman resettejä mennään vielä juhannuksen räntäsateetkin ja ylikin.

@puu , @Raspi , @wannabe ja muut mitsurunner aktivistit, hienoa että olette ollut mukana viemään hommaa eteenpäin .

Githubissa on nyt uusi Mitsurunner-versio, joka sisälttää kaikki Mitsurunner-variaatiot
https://github.com/VeliML/MitsuRunner


Mitsurunner.yaml-tiedoston "include" osoista voit valita (poistamalla #-merkin rivin alusta) haluamasi variaation
* rautaympäristön (Wemos tai Sonoff-Elite)
* Dallas antureiden käsittelytavan (perus tai dallas_hub(=minimoi resetit))

<<: !include platform_wemos.yaml
#<<: !include platform_elite.yaml

# Select configuration of Dallas sensors
packages:
#  device_base: !include dallas_basic.yaml # basic-configuration
  device_base: !include dallas_hub.yaml # separate Dallas-hubs for minimize resets

Web-serverin voit ottaa käyttöön poistamalla secrets-tiedoston web-server-osiosta #-merkkejä rivien alusta.

web_server:
  port: 80
#  auth:                #if needed enable authentication
#    username: "...."   # by uncommentig these rows
#    password: "...."   # and adding username/password
#  ota: false

Jos päivität aimpaa mitsurunner-asennusta ota käyttöön uudet secrets- ja platform_wemos/platform_elite tiedosto ja kopio niihin tarvittavat parametrit aiemmin käyttämistäsi secrets- ja platform-tiedostoista.

Jos käytät OTA-yhteyttä ja IoT-Gurua trace-log ei tulostu näytölle. Voit kuitenkin nähdä login menemällä selaimella mitsurunnerin IP-osoitteeseen. Turhien ESPHome-poikkeamailmoitusten välttämiseksi ohjelma kannatta kääntää komennolla. esphome run --no-logs mitsurunner.yaml

Mitsurunner-Wiki ohjeistusta on päivitty tehtyjen muutosten mukaisesti
https://mitsurunner.com

 

[puu]

Githubissa on nyt uusi Mitsurunner-versio, joka sisälttää kaikki Mitsurunner-variaatiot
https://github.com/VeliML/MitsuRunner/tree/separate_dallas_config

Itseasiassa mergesin tuon juuri päähaaraan. Muistin tehneeni tämän jo aiemmin, mutta muistin väärin.

Jos sitä kohta tekisi v1.0 releasen. Ehkä tätä uskaltaa jo sanoa jollain tasollla valmiiksi.