MSZ-LN sulatushuijaus

  • Viestiketjun aloittaja Viestiketjun aloittaja iro
  • Aloituspäivämäärä Aloituspäivämäärä
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
 
Väliaikatietoa oman Mitsurunnerin reset-tilanteeseen. Kahdeksas vuorokausi menossa ilman resetin resettiä :bileet:
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 :rolleyes:. 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ä.
 
wannabe sanoi:
Väliaikatietoa oman Mitsurunnerin reset-tilanteeseen. Kahdeksas vuorokausi menossa ilman resetin resettiä :bileet:
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.
Klikkaa laajentaaksesi...
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
 
iro sanoi:
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
Klikkaa laajentaaksesi...

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ä :hattu:
 
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\
 
Raspi sanoi:
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\
Klikkaa laajentaaksesi...
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ä ?
 
iro sanoi:
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
Klikkaa laajentaaksesi...
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....
 
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.
 
puu sanoi:
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.
Klikkaa laajentaaksesi...
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).
 
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.
 
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 sanoi:
Väliaikatietoa oman Mitsurunnerin reset-tilanteeseen. Kahdeksas vuorokausi menossa ilman resetin resettiä :bileet:
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
Klikkaa laajentaaksesi...

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 :cool:
 
iro sanoi:
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ä ?
Klikkaa laajentaaksesi...
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.
 
akarkkai sanoi:
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.
Klikkaa laajentaaksesi...
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.
 
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.)
 

Liitetiedostot

  • Screenshot_20240310_093108.png
    Screenshot_20240310_093108.png
    93,7 KB · Lukukerrat: 130
Viimeksi muokattu:
iro sanoi:
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.
Klikkaa laajentaaksesi...
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ä.
Näyttökuva 2024-03-10 205257.png

Dallasin virheitä tulee runsaasti. Näillä ei näyttäisi olevan yhteyttä resetoitumiseen.
 
wannabe sanoi:
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 :cool:
Klikkaa laajentaaksesi...

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.
 
  • Tykkää
Reaktiot: 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.
 

Liitetiedostot

Raspi sanoi:
Laitoin reilu viikko sitten mökille uutta softaaa ja kuvasta näkee, että muutos on ressujen suhteen huomattava. :)
Klikkaa laajentaaksesi...
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.
 
Tein nyt pull requestin tuosta @iro :n zipistä.

Kääntäessä huomasin, että nyt kun tuolla secrets.yaml:ssa on mqtt:n alla:
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 used

Tulee käännöksessä virheet, kun ei tykkää noista null-arvoista:
Koodi: 
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.
 
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?

Koodi: 
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ä.
 
puu sanoi:
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?

Koodi: 
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ä.
Klikkaa laajentaaksesi...
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.

Koodi: 
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 sanoi:
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.
Klikkaa laajentaaksesi...
@puu , koska käyttöohjeet kuitenkin jäävät lukematta :hmm: niin ohjerivin voisi lisätä secrets.yaml IoT-Guru MQTT-osioon
Koodi: 
############## 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")
 
iro sanoi:
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
Klikkaa laajentaaksesi...
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.
 
puu sanoi:
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.
Klikkaa laajentaaksesi...
Laitoin muutoksille OK merkinnän dithubiin
 
puu sanoi:
Mergesin. Nyt vaan sitten jotkut nohevat MitsuRunner-taistelijat voisivat testata, että tuorein versio tomii Sonoffilla ja Wemoksella.
Klikkaa laajentaaksesi...
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).
 

Liitetiedostot

Viimeksi muokattu:
iro sanoi:
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.
Klikkaa laajentaaksesi...
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.
Koodi: 
esp-idf-public/components/libsodium/libsodium/src/libsodium/crypto_pwhash/argon2/argon2-core.c:477: multiple definition of `initialize';
 
akarkkai sanoi:
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.
Koodi: 
esp-idf-public/components/libsodium/libsodium/src/libsodium/crypto_pwhash/argon2/argon2-core.c:477: multiple definition of `initialize';
Klikkaa laajentaaksesi...
Erikoista, tuolta libsodium-reposta ei löydy (ainakaan masterista) tuota initialize-nimeä suoraan:
github.com

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 github.com
 
akarkkai sanoi:
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.
Koodi: 
esp-idf-public/components/libsodium/libsodium/src/libsodium/crypto_pwhash/argon2/argon2-core.c:477: multiple definition of `initialize';
Klikkaa laajentaaksesi...
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ä.
 
puu sanoi:
Erikoista, tuolta libsodium-reposta ei löydy (ainakaan masterista) tuota initialize-nimeä suoraan:
github.com

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 github.com
Klikkaa laajentaaksesi...

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:
Koodi: 
/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';
 
@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.
 

Liitetiedostot

iro sanoi:
@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.
Klikkaa laajentaaksesi...
Nyt on pull requesti tästä: https://github.com/VeliML/MitsuRunner/pull/39
Käykää (ainakin @iro) vilkaisemassa, että on OK.
 
iro sanoi:
Muistaaksen minäkin havaitsin että Elitelssä (esp32-patform) resettejä esiiintyy selvästi vähemmän kuin Wemos (esp8266-platform)-laitteissa.
Klikkaa laajentaaksesi...

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.
 
wannabe sanoi:
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.
Klikkaa laajentaaksesi...
@puu , @Raspi , @wannabe ja muut mitsurunner aktivistit, hienoa että olette ollut mukana viemään hommaa eteenpäin :sille:.

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))

Koodi: 
<<: !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.
Koodi: 
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
 
Viimeksi muokattu:
  • Tykkää
Reaktiot: puu
Sinun täytyy kirjautua sisään tai rekisteröityä voidaksesi vastata viestiin.
Takaisin
Ylös Bottom