Adopted POE proxy remains in Dashboard as 'Discovered', and doesnt do 'Active'

[Mariusthvdb]

Originally posted by @Mariusthvdb in #320 (comment)

thought it best to post this as a separate issue, as it contains new info after initial succes

thx for the fix. Updated the Add-on to 2022.9.4 and refreshed the firmware on https://esphome.github.io/bluetooth-proxies/

I can see the devices being discovered:

so, I click on Adopt on the 277564, change the name to something nicer, bluetooth-proxy-centraal and that seems to fare well. I do notice it still compiles Wifi related lines, and an error scrolls by:

/data/cache/platformio/packages/framework-arduinoespressif32/cores/esp32/esp32-hal-spi.c: In function 'spiTransferBytesNL':
/data/cache/platformio/packages/framework-arduinoespressif32/cores/esp32/esp32-hal-spi.c:922:39: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types]
                 uint8_t * last_out8 = &result[c_longs-1];
                                       ^
/data/cache/platformio/packages/framework-arduinoespressif32/cores/esp32/esp32-hal-spi.c:923:40: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types]
                 uint8_t * last_data8 = &last_data;
                                        ^

no matter that, there is success reported, and the board is online. hurray.

however, in the dashboard the discovered device is still showing after successful adoption:

reading the process for the M5stack board does in fact take away the 'discovered' device:

finally, this is repeated in the homeassistant.log:

Logger: homeassistant.components.esphome
Source: components/esphome/__init__.py:263 
Integration: ESPHome (documentation, issues) 
First occurred: 10:53:09 (20 occurrences) 
Last logged: 11:08:21

Name of device olimex-bluetooth-proxy-277564 changed to bluetooth-proxy-centraal, potentially due to IP reassignment

and

Logger: aioesphomeapi.reconnect_logic
Source: runner.py:119 
First occurred: 12:30:15 (1 occurrences) 
Last logged: 12:30:15

Can't connect to ESPHome API for olimex-bluetooth-proxy-277564 @ 192.168.1.221: Server sent a different name 'bluetooth-proxy-centraal'

which ofc isnt the fact and seems another bug?

[Mariusthvdb]

right, so after some time, and having adopted all of my 3 boards, the discovered ones are gone. However, the Olimex boards seem no to communicate with actual devices, whihc now all show a dBm of lower than -90... while the boards are actually next to them.

My M5 stack does this better, and actually makes the connection stronger when moving towards it.

opening the Esphome dashboard now shows this, the board is re Discovered yet again...:

also, when clicking the edit button, the yaml is nowhere near what the yaml files contain in the Esphome repo for these devices:

substitutions:
  name: "bluetooth-proxy-aanbouw"
packages:
  esphome.bluetooth-proxy: github://esphome/bluetooth-proxies/olimex-esp32-poe-iso.yaml@main
esphome:
  name: ${name}
  name_add_mac_suffix: false

and the wifi board has:

substitutions:
  name: bluetooth-proxy-dining
packages:
  esphome.bluetooth-proxy: github://esphome/bluetooth-proxies/m5stack-atom-lite.yaml@main
esphome:
  name: ${name}
  name_add_mac_suffix: false


wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

shouldn't there at least be something on the 'active: true'?

so what is going on here?
btw, did restart the add-on too (figured restarting HA wouldn't do that) but still the same happening, and also this:

Logger: homeassistant.components.esphome
Source: components/esphome/__init__.py:263 
Integration: ESPHome (documentation, issues) 
First occurred: 14:21:07 (68 occurrences) 
Last logged: 14:49:22

Name of device olimex-bluetooth-proxy-288d84 changed to bluetooth-proxy-aanbouw, potentially due to IP reassignment
Name of device olimex-bluetooth-proxy-277564 changed to bluetooth-proxy-centraal, potentially due to IP reassignment

[balloob]

The Home Assistant issue is unrelated to here. That is due to Home Assistant using the configuration name as unique ID, and so the unique ID changes. This needs to be updated to use the mac address to seamlessly allow renaming.

For discovered, I think that's a backend bug @jesserockz. The problem is that the output of ping contains cached devices. We should either clear that output after a rename, or have a better way of cleaning up stale devices.

Easy step to reproduce is to hit "rename" in a dropdown menu in ESPHome dashboard.

[Mariusthvdb]

can close now, seems to be fixed and no longer happening
thx.

or should that backend bug still be considered?

[balloob]

That was already addressed.