Closed AlexKusnezov closed 2 months ago
Hi Alex,
first, this is wrong...
ota:
- platform: esphome
password: "some-ota-pw"
It must be:
ota:
platform: esphome
password: "some-ota-pw"
I think, it should not matter, if you leave the module in the Buderus, but since you need to take it out to change the jumper, why put it back in during the update?
Regards, Daniel
Hi Alex,
first, this is wrong...
ota: - platform: esphome password: "some-ota-pw"
It must be:
ota: platform: esphome password: "some-ota-pw"
nope, it's a breaking chnage of 2024.6, look it up: https://esphome.io/components/ota/esphome.html
I think, it should not matter, if you leave the module in the Buderus, but since you need to take it out to change the jumper, why put it back in during the update?
Regards, Daniel
Do I really need to take out the module to change the jumper? I have to look at it again. Also I have to use the pins, right? Seems like usb connector delivers just power.
btw, did yopu had this error on ota?
[Errno 104] Connection reset by peer
btw, did yopu had this error on ota?
[Errno 104] Connection reset by peer
Hi Alex, I observed a similar issue when I tried an OTA update some weeks ago after running the module for half a year without resets. The device stopped responding. I did a power cycle by turning the whole Buderus of and on again. Afterwards OTA worked fine. Maybe there's an issue with doing an OTA update when the device has been running for quite some time.
Does a reset help to get rid of the error?
btw, did yopu had this error on ota?
[Errno 104] Connection reset by peer
Hi Alex, I observed a similar issue when I tried an OTA update some weeks ago after running the module for half a year without resets. The device stopped responding. I did a power cycle by turning the whole Buderus of and on again. Afterwards OTA worked fine. Maybe there's an issue with doing an OTA update when the device has been running for quite some time.
Does a reset help to get rid of the error?
thanks for how long did you had Buderus powered off? I tried it maybe about 5 times. tjis is my power graph of the esp32:
I turned it off for just about a minute and it worked on the second attempt. So it seems you are encountering a different issue.
If nothing works, avoid a WiFi connection (shutting down your access point or moving the module away and supply it through USB. After some time, you should be able to access the fallback hotspot and do a FW upgrade through the web UI. Other option is to flash it through serial.
guys,I'ver got a bit further with this. I bacically spun up an esphome server on a laptop and moved it to the module so that is connected to the same mesh repeater and this is what I got:
Linking .pioenvs/buderus-heizung/firmware.elf
RAM: [== ] 16.4% (used 53672 bytes from 327680 bytes)
Flash: [========= ] 90.5% (used 1660321 bytes from 1835008 bytes)
Building .pioenvs/buderus-heizung/firmware.bin
Creating esp32 image...
Successfully created esp32 image.
esp32_create_combined_bin([".pioenvs/buderus-heizung/firmware.bin"], [".pioenvs/buderus-heizung/firmware.elf"])
Wrote 0x1a6c50 bytes to file /config/.esphome/build/buderus-heizung/.pioenvs/buderus-heizung/firmware.factory.bin, ready to flash to offset 0x0
esp32_copy_ota_bin([".pioenvs/buderus-heizung/firmware.bin"], [".pioenvs/buderus-heizung/firmware.elf"])
======================== [SUCCESS] Took 1130.59 seconds ========================
INFO Successfully compiled program.
INFO Connecting to 192.168.2.63
INFO Uploading /config/.esphome/build/buderus-heizung/.pioenvs/buderus-heizung/firmware.bin (1666128 bytes)
Traceback (most recent call last):
File "/usr/local/bin/esphome", line 8, in <module>
sys.exit(main())
^^^^^^
File "/esphome/esphome/__main__.py", line 1079, in main
return run_esphome(sys.argv)
^^^^^^^^^^^^^^^^^^^^^
File "/esphome/esphome/__main__.py", line 1066, in run_esphome
rc = POST_CONFIG_ACTIONS[args.command](args, config)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/esphome/esphome/__main__.py", line 508, in command_run
exit_code = upload_program(config, args, port)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/esphome/esphome/__main__.py", line 365, in upload_program
return espota2.run_ota(host, remote_port, password, CORE.firmware_bin)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/esphome/esphome/espota2.py", line 356, in run_ota
return run_ota_impl_(remote_host, remote_port, password, filename)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/esphome/esphome/espota2.py", line 344, in run_ota_impl_
perform_ota(sock, password, file_handle, filename)
File "/esphome/esphome/espota2.py", line 289, in perform_ota
receive_exactly(sock, 1, "chunk OK", RESPONSE_CHUNK_OK)
File "/esphome/esphome/espota2.py", line 102, in receive_exactly
check_error(data, expect)
File "/esphome/esphome/espota2.py", line 118, in check_error
dat = data[0]
~~~~^^^
IndexError: list index out of range
I'm not sure what's happening here. my yaml is valid. DId somebody had this before? Attaching my yaml in case you want to take a look. buderus-heizung_red.yaml.zip
I believe, that it is the OTA platfrom setting, introduced in the last esphome update, but I could be wrong:
ota:
- platform: esphome
Please check, if the platform line is in your YAML...
I believe, that it is the OTA platfrom setting, introduced in the last esphome update, but I could be wrong:
ota: - platform: esphome
Please check, if the platform line is in your YAML...
yes, it is.
It looks like this problem is somewhere hidden in the esphome itself: https://github.com/esphome/esphome I really have no clue, why this happens.
It looks like this problem is somewhere hidden in the esphome itself: https://github.com/esphome/esphome I really have no clue, why this happens.
got you, are you still on lower than 2024.6, too?
I'm currently on 2024.6.2, so I integrated the esphome platform statement in my YAML and it works. But did not update to 2024.6.6 yet.
ok, I'm still on 2024.5. I'll give it a try next week
guys, I finally managed to update my untit to 2024.8.1.
What I did was shutting down Home Assistant, putting the Logamatic 2107 M into maintenance mode, so it would heat all the time (this way current goes up) and then try for like 20+ times to upload the firmware. Often it would just cancel on approx 20% upload progress.
2024.8.3 - update worked seamless👍
That sounds great. I had this wired issues with FW OTA a looooong time ago (at least one year) and it seems, that is was mostly related to software, more precisely the Arduina-OTA package. I tried many times, but it did not work. Then I just forgot about it and some weeks later, it magically worked.
Hey guys,
since 2024.6 is out now I wanted to give it a shot and update my module. So I went and adopted the config to:
However, since 2024.5.0 (last succesfull update) it would compile, then try to upload and then resulting in:
[Errno 104] Connection reset by peer
with the module just restart and stay on 2024.5.0I'm assuming that since I'm powering from buderus unit, the power it delivers isn't enugh, so I have to hook it up via usb and the perform the update, right? The wifi signal is pretty good, so it shouldn't be that:
Signal strength: -55 dB
If so, then I'm assuming that this would be the steps (correct me if I'm wrong):
my questions would be: