Open tony-fav opened 2 years ago
I have been testing this today and it seems like the client is sending 50% of the OTA firmware very quickly and the device cannot keep up and eventually times out the watchdog when it gets stuck. No solution as of yet but this issue should be moved to the main ESPHome issue tracker.
The only difference I can think of so far compared to other boards I have is the ethernet driver
Thanks for the confirmation and move!
Following on from https://github.com/esphome/bluetooth-proxies/issues/39, even if safe boot is used, I cannot update the GL-S10 using OTA.
I have a revision 2.1 board. I have flashed the initial firmware using the webflash tool and now trying to adopt the device into ESPHome and do the initial OTA. The process will not get beyond single-digit percentage without timing out.
Steps to reproduce: Flash with intitial binary Attempt to adopt into ESPHome OTA times out Repeat using the safe boot button in HA OTA times out
INFO Uploading /data/gl-s10-bt-proxy-9ad9b0/.pioenvs/gl-s10-bt-proxy-9ad9b0/firmware.bin (1493552 bytes) Uploading: [=== ] 5% ERROR Error sending data: timed out
I've seen OTA fail on other ESPHome projects due to the flash size being too high to allow the OTA binary - do these stats look ok in that respect;
RAM: [== ] 16.7% (used 54592 bytes from 327680 bytes) Flash: [======== ] 81.4% (used 1493450 bytes from 1835008 bytes)
To add another data point, OTA is incredibly flakey for me as well, but will eventually succeed after numerous retries. The device won't hold a stable API connection to HA though with frequent drops.
If you would ping the device, you could see the issue. I very sure that the new IDF/Arduino framework version would fix it
Because I'm incredibly lazy and don't want to get the device back out for a reflash, I've just been pounding the OTA with a loop until it seems to work:
from esphome import espota2
while True:
out = espota2.run_ota('192.168.4.111', 3232, '', 'gl-s10-bt-proxy-111111.bin')
if out == 1:
continue
else:
break
Hope this helps someone else. Latest versions of ESPHome seem to be more stable so the upgrade is worth it, but I just didn't want to mess with the hardware again.
Interestingly enough manually setting my switch port that was connected to the device to 10Mb rather than 100Mb autoneg. allowed me to OTA with no issue.
The device is also causing CRC errors on the switch. Ive tried different cables and it does not change anything.
Interestingly enough manually setting my switch port that was connected to the device to 10Mb rather than 100Mb autoneg. allowed me to OTA with no issue.
The device is also causing CRC errors on the switch. Ive tried different cables and it does not change anything.
Same, after setting 10FDX manually, OTA worked on first attempt.
The device is also causing CRC errors on the switch. Ive tried different cables and it does not change anything.
Yeah I had to actually disable RSTP on my UniFi switch port to which my GL-S10 was connected or it would block the port thinking it was looping.
I also cannot OTA, and it seems to reboot itself every 15 seconds or so. Not sure if Bluetooth or Ethernet related, but I do have a lot of advertisements nearby so the LED flashes very rapidly.
Hardware revision v2.1
I had a bit of mess about a couple of weeks ago and have had my 2.1 revision device running fine since (OTA and availability) by:
esp-idf
)on_ble_advertise
automation)esp32_ble_tracker
scan parameters (comment out interval
and window
)I've not spent any time since digging into exactly what impact each of those changes has individually but hopefully this information can help the overall investigation/resolution.
Thanks for the update @trvrnrth. Can you share a bit information how we can compile from your Github? Can we use external_components for that? Or should we use source under the framework?
Having similar trouble. Tried setting 10FDX manually.... Haven't tried the compiled version above, but with defaults getting massive packet loss, connection drops, etc.
@trvrnrth Can you post your yaml?
@gerard33 I'm guessing you're using the home assistant add-on. If you install the dev version you should be able to specify an esphome_fork
of trvrnrth:gls10
but I've never actually tried as I just compile locally for dev testing.
@efaden The only changes are as I describe but here you go.
@gerard33 I'm guessing you're using the home assistant add-on. If you install the dev version you should be able to specify an
esphome_fork
oftrvrnrth:gls10
but I've never actually tried as I just compile locally for dev testing.@efaden The only changes are as I describe but here you go.
Thanks. Is there a way to specify the fork on only the few devices? Can you change the fork in the yaml? Can't seem to find a way.
@trvrnrth I indeed use the HA add-on. I have installed the dev version and specified your fork. I got an error during compiling, so I forked the latest dev branch from esphome github and made your changes there. Then compiling went okay.
When changing the framework to esp-idf
in the yaml code however I get an error that the ethernet feature is only available for Arduino. How did you handle this?
@trvrnrth Upgraded to what you suggested.... seems to hold connection with HA better, but still getting tons of loss if I ping it. And it also won't OTA. Gets part way and fails.
@gerard33 The dev branch in your fork does not appear to include all the changes in the branch I tested with. At a glance you seem to have only pulled in a single commit to bump versions.
Thanks, I will have a look at your other commits and update my branch accordingly.
Update: I missed the Enable ethernet for esp-idf
commit indeed 😏
After adding that the yaml is valid and I will update it now.
Mine is still barely reliable. Getting the bluetooth data, but can't get OTA or ping stability or anything.
Was having exactly the same proble, ping packet loss about 20-25% and unable to flash OTA. I followed a tip in this thread and set the switchport fixed to 10/full. This extremely reduces packet loss (now 1-2%) and I able to do an OTA flash. So I would guess there is something with the ethernet driver ?
This device is referred to as "The Best Home Assistant Bluetooth Proxy" ! How can that be, when everyone seems to have nothing but trouble to get it working?
Isn't there a single success story out there?
I'm with you there.... I have mine out of service until there is a fix
On Tue, Dec 6, 2022, 16:02 oywino @.***> wrote:
This device is referred to as "The Best Home Assistant Bluetooth Proxy" ! How can that be, when everyone seems to have nothing but trouble to get it working?
Isn't there a single success story out there?
— Reply to this email directly, view it on GitHub https://github.com/esphome/issues/issues/3682#issuecomment-1340000720, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADAEABBHVY3RROD7GI5ASLDWL6SUXANCNFSM6AAAAAARC4C77Y . You are receiving this because you were mentioned.Message ID: @.***>
Just to shift the odds. Mine has been working like a charm ever since i set speed and duplex to fixed as suggested earlier on in the comments.
Looking for success stories on an issue tracker sounds very counterproductive.
Just to shift the odds. Mine has been working like a charm ever since i set speed and duplex to fixed as suggested earlier on in the comments.
Looking for success stories on an issue tracker sounds very counterproductive.
Likewise, I've set the port on my UniFi switch to 10 meg and it's been solid since.
Powering with Poe or USB?
On Wed, Dec 7, 2022, 09:14 DJBenson @.***> wrote:
Just to shift the odds. Mine has been working like a charm ever since i set speed and duplex to fixed as suggested earlier on in the comments.
Looking for success stories on an issue tracker sounds very counterproductive.
Likewise, I've set the port on my UniFi switch to 10 meg and it's been solid since.
— Reply to this email directly, view it on GitHub https://github.com/esphome/issues/issues/3682#issuecomment-1341029913, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADAEABDGVUHNEJ2ET3MHVGTWMCLVNANCNFSM6AAAAAARC4C77Y . You are receiving this because you were mentioned.Message ID: @.***>
PoE
Interesting. I'll try that again. But didn't seem to change anything.
10 full or half duplex?
On Wed, Dec 7, 2022, 09:29 DJBenson @.***> wrote:
PoE
— Reply to this email directly, view it on GitHub https://github.com/esphome/issues/issues/3682#issuecomment-1341048830, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADAEABCR2OTZWZMI7SCWCBLWMCNLBANCNFSM6AAAAAARC4C77Y . You are receiving this because you were mentioned.Message ID: @.***>
Alright.... I'll try that again.
On Wed, Dec 7, 2022, 09:38 DJBenson @.***> wrote:
[image: image] https://user-images.githubusercontent.com/1013909/206207775-62eaf929-daca-4ca1-82c5-c1cbb7f77221.png
— Reply to this email directly, view it on GitHub https://github.com/esphome/issues/issues/3682#issuecomment-1341062510, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADAEABAVVKLHLRW7BT4MP6TWMCOPJANCNFSM6AAAAAARC4C77Y . You are receiving this because you were mentioned.Message ID: @.***>
Prior to this, I could not flash the device OTA - now it succeds every time.
I decided to give it a try. Flashing the GL-S10 and connecting to HA was easy. By trial'n'error I finally managed to sucessfully omplete OTA by setting not only the connected Ethernet port to 10MF, but I also changed the port to the PC running ESPHome as well as the master port feeding into the switch from the LAN router. With all three set to 10MF, packet loss disappeared and I could successfully OTA. Here's my validation log:
INFO Reading configuration /config/gl-s10-bt-proxy-1e66cc.yaml...
WARNING GPIO12 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
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
INFO Configuration is valid!
substitutions:
name: gl-s10-bt-proxy-1e66cc
esphome:
name: gl-s10-bt-proxy-1e66cc
name_add_mac_suffix: false
project:
name: esphome.bluetooth-proxy
version: '1.0'
on_boot:
- then:
- output.turn_on:
id: power_led
priority: 600.0
build_path: .esphome/build/gl-s10-bt-proxy-1e66cc
platformio_options: {}
includes: []
libraries: []
min_version: 2022.11.5
esp32:
board: esp32doit-devkit-v1
framework:
version: 1.0.6
source: ~3.10006.0
platform_version: platformio/espressif32 @ 3.5.0
type: arduino
variant: ESP32
ethernet:
type: IP101
mdc_pin: 23
mdio_pin: 18
clk_mode: GPIO17_OUT
phy_addr: 1
power_pin:
number: 5
mode:
output: true
input: false
open_drain: false
pullup: false
pulldown: false
inverted: false
domain: .local
use_address: gl-s10-bt-proxy-1e66cc.local
api:
port: 6053
password: ''
reboot_timeout: 15min
logger:
baud_rate: 115200
tx_buffer_size: 512
deassert_rts_dtr: false
hardware_uart: UART0
level: DEBUG
logs: {}
ota:
safe_mode: true
port: 3232
reboot_timeout: 5min
num_attempts: 10
dashboard_import:
package_import_url: github://esphome/bluetooth-proxies/gl-s10.yaml@main
esp32_ble_tracker:
scan_parameters:
interval: 1100ms
window: 1100ms
active: true
duration: 5min
continuous: true
on_ble_advertise:
- then:
- output.turn_on:
id: bluetooth_led
- delay: 500ms
- output.turn_off:
id: bluetooth_led
bluetooth_proxy:
active: true
connections:
- {}
- {}
- {}
button:
- platform: safe_mode
name: Safe Mode Boot
entity_category: diagnostic
disabled_by_default: false
icon: mdi:restart-alert
device_class: restart
status_led:
pin:
number: 32
inverted: true
mode:
output: true
input: false
open_drain: false
pullup: false
pulldown: false
binary_sensor:
- platform: gpio
pin:
number: 33
inverted: true
mode:
input: true
output: false
open_drain: false
pullup: false
pulldown: false
name: Reset Button
disabled_by_default: false
output:
- platform: gpio
pin:
number: 14
mode:
output: true
input: false
open_drain: false
pullup: false
pulldown: false
inverted: false
inverted: true
id: power_led
- platform: gpio
pin:
number: 12
mode:
output: true
input: false
open_drain: false
pullup: false
pulldown: false
inverted: false
inverted: true
id: bluetooth_led
i2c:
- sda: 15
scl: 13
scan: true
frequency: 50000.0
Next step now is: So what? How do I verify that Blutetooth is on and active? No devices shows up i HA. Is it possible to use Bluetooth in my Galaxy phone to connect and test the Proxy ?
Please try 2022.12(Beta), Ethernet driver has been rewritten.
Please try 2022.12(Beta), Ethernet driver has been rewritten.
Link please ?
I installed the ESP home (Beta) add-on. Changed the YAML to the YAML below and flashed the device with serial connecton. Flash went fine, device is accessible. After this I tried OTA updates. Pressed the 'safe boot' button for the device and tried OTA multiple times. This unfortionately results in a time out. Hope this input might help:
# Instructions on opening and wiring for flashing on https://blakadder.com/gl-s10!
esphome:
name: gl-s10-bt-testunit
name_add_mac_suffix: false
project:
name: esphome.bluetooth-proxy
version: "1.0"
# turn on Power LED when esphome boots!
on_boot:
then:
- output.turn_on: power_led
esp32:
board: esp32doit-devkit-v1
framework:
type: esp-idf
# # Configuration fo V2.3 hardware revision
ethernet:
type: IP101
mdc_pin: GPIO23
mdio_pin: GPIO18
clk_mode: GPIO17_OUT
phy_addr: 1
power_pin: GPIO5
# Comment the above and use this instead for V1.0 revision of the hardware
#ethernet:
# type: LAN8720
# mdc_pin: GPIO23
# mdio_pin: GPIO18
# clk_mode: GPIO17_OUT
# phy_addr: 1
api:
logger:
ota:
# dashboard_import:
# package_import_url: github://esphome/bluetooth-proxies/gl-s10.yaml@main
esp32_ble_tracker:
# Bluetooth LED blinks when receiving Bluetooth advertising
# on_ble_advertise:
# then:
# - output.turn_on: bluetooth_led
# - delay: 0.5s
# - output.turn_off: bluetooth_led
bluetooth_proxy:
active: true
button:
- platform: safe_mode
name: Safe Mode Boot
entity_category: diagnostic
sensor:
- platform: uptime
name: Uptime Sensor
## DEVICE SPECIFIC CONFIGURATION
# network LED (white one) configured as status led
# button on the side labeled RESET
binary_sensor:
- platform: gpio
pin:
number: GPIO33
inverted: true
name: "Reset Button"
# output settings for LED's marked Power and Bluetooth
# power LED use: see code line 12
# bluetooth LED use: see code line 41
output:
- platform: gpio
pin: GPIO14
inverted: true
id: power_led
- platform: gpio
pin: GPIO12
inverted: true
id: bluetooth_led
# # since these pins are broken out inside and labeled as I2C pins they're configured here
# i2c:
# sda: 15
# scl: 13
# scan: true
logs:
`INFO Reading configuration /config/esphome/gl-s10-bt-proxy-d628bc.yaml...
WARNING GPIO12 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
INFO Generating C++ source...
INFO Compiling app...
Processing gl-s10-bt-testunit (board: esp32doit-devkit-v1; framework: espidf; platform: platformio/espressif32 @ 5.2.0)
--------------------------------------------------------------------------------
HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash
- framework-espidf @ 3.40402.0 (4.4.2)
- tool-cmake @ 3.16.4
- tool-ninja @ 1.7.1
- toolchain-esp32ulp @ 2.35.0-20220830
- toolchain-xtensa-esp32 @ 8.4.0+2021r2-patch3
Reading CMake configuration...
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
No dependencies
RAM: [== ] 15.8% (used 51888 bytes from 327680 bytes)
Flash: [====== ] 56.0% (used 1028137 bytes from 1835008 bytes)
Building /data/gl-s10-bt-testunit/.pioenvs/gl-s10-bt-testunit/firmware.bin
Creating esp32 image...
Successfully created esp32 image.
esp32_create_combined_bin(["/data/gl-s10-bt-testunit/.pioenvs/gl-s10-bt-testunit/firmware.bin"], ["/data/gl-s10-bt-testunit/.pioenvs/gl-s10-bt-testunit/firmware.elf"])
Wrote 0x10c6b0 bytes to file /data/gl-s10-bt-testunit/.pioenvs/gl-s10-bt-testunit/firmware-factory.bin, ready to flash to offset 0x0
========================= [SUCCESS] Took 24.59 seconds =========================
INFO Successfully compiled program.
INFO Resolving IP address of gl-s10-bt-testunit.local
INFO -> 192.168.1.41
INFO Uploading /data/gl-s10-bt-testunit/.pioenvs/gl-s10-bt-testunit/firmware.bin (1033904 bytes)
Uploading: [= ] 2%
ERROR Error sending data: timed out
`
Please try 2022.12(Beta), Ethernet driver has been rewritten.
Link please ?
RTFM: https://esphome.io/guides/faq.html#how-do-i-update-to-the-latest-beta-release
After a while, the GL-S10 began behaving very strange. No matter what I do in ESPHome, I always get only this in the log:
Failed config
ethernet: [source /config/.esphome/packages/f8744889/gl-s10.yaml:24]
This feature is only available with frameworks ['arduino'].
type: IP101
mdc_pin: GPIO23
mdio_pin: GPIO18
clk_mode: GPIO17_OUT
phy_addr: 1
power_pin: GPIO5
I tried to reboot (power cycle) and I tried SafeBoot, Nothing seems to help. What could have happened? How do I solve this problem?
Did you use the beta addon? You should for now when using idf instead of Arduino. Some more info like the YAML would help
Did you use the beta addon? You should for now when using idf instead of Arduino. Some more info like the YAML would help
If that's an answer/question to me @phaeton82 - I appreciate your support, but I do not understand what you mean? The beta that @nagyrobi linked to seems to me to be a beta of the ESPHome docker container (Web GUI), while I was looking for a beta firmware for the GL-S10 My problem is that I can no longer access the device at all through the Web GUI
Please read the documentation carefully. With the Beta add-on you create beta firmware. With the Dev addon, you create dev firmware.
no longer access the device at all through the Web GUI
You shouldn't use bluetooth-proxy
and webserver
on the same node, they are too much together for an ESP32 under arduino
platform. webserver
is not available (yet) under esp-idf
platform.
Sorry for my ignorance, but you can see that I need guidance. What exactly do you mean by "add-on" ? I didn't "add" anything "on" anywhere. All I did was to install a self conitained docker container after successfully flashing the device. and everything seemed ok - until this morning when nothing seems ok.
I suggest to start reading from the beginning: https://esphome.io/guides/getting_started_hassio.html
Using ESPHome the most straightforward way is to have it installed as a Home Assistant Add-on. There are 3 possible ESPHome Add-ons you can choose from: normal, beta, and dev. You can install beta and dev if you set yourself as an advanced user in Home Assistant. You can have all of them installed in parallel if you want to.
I cannot install anything as a Home Assistant "add-on" as I am not running Home Assistant Supervised (or Hassio as used to be known as). I think my problem is that everybody automatically assumes that everyone - including me - is running Home Assistant Supervised. But I'm not. So, that's why I installed ESPHome as a self-contained Docker image. It has no connection at all to Home Assistant.
everybody automatically assumes that everyone - including me - is running Home Assistant Supervised
Yes because that's the supported way to use Home Assistant, and that's how the big majority uses it. Of course it can be deployed by other means, but that's another story.
You should research then how to install ESPHome Beta as a self-contained Docker image, with that, you'd be able to compile the beta firmware releases.
Exactly, and that's the link I was hoping someone could pass me. Cause all the DOC's and everything else is pretty useless to me as I'm not running Supervised. Where can I find a container image of ESPHome beta?
It has been passed to you just above.
If you can't find your way based on that, for more adequate questions please join to the Discord support channel. This is now offtopic here.
Sorry for the inconvenience. I did manage to install v2022.12.0b2 by creating a docker compose file as follows:
version: '3'
services:
homeass:
image: esphome/esphome:beta
restart: "no"
network_mode: host
environment:
LANG: nb_NO.UTF-8
TZ: Europe/Oslo
volumes:
- /share/Public/ESPHome/beta:/config
I flashed the new beta version using esp-idf instead of arduino. The unit seems more stable at 100Mb but Im unable to OTA any longer either on 10Mb or 100Mb. Seems some good progress was made, but we are not all there quite yet. Code below, using Esphome v2022.12.0b2. Seems Ill need to take the unit apart to get any newer versions on it again.
`substitutions: name: "gl-s10-bt-proxy-1341dc"
esphome: name: ${name} project: name: esphome.bluetooth-proxy version: "1.0"
on_boot: then:
esp32: board: esp32doit-devkit-v1 framework: type: esp-idf
ethernet: type: IP101 mdc_pin: GPIO23 mdio_pin: GPIO18 clk_mode: GPIO17_OUT phy_addr: 1 power_pin: GPIO5
api: logger: ota:
dashboard_import: package_import_url: github://esphome/bluetooth-proxies/gl-s10.yaml@main
esp32_ble_tracker: scan_parameters: interval: 1100ms window: 1100ms active: true
bluetooth_proxy: active: true
button:
status_led: pin: number: GPIO32 inverted: true
binary_sensor:
platform: gpio pin: number: GPIO33 inverted: true name: "Reset Button"
output:
i2c: sda: 15 scl: 13 scan: true
sensor:
I'm having the same OTA issue using ethernet. Setting the port to 10mbps fails immediately, setting the port to 100mbps allows a partial upload before timing out. Running 2022.12.1
Without Safe Boot:
With Safe Boot: