How to adopt the Olimex POE board without wifi credentials

[Mariusthvdb (Marius)]

Ive managed the whole procedure as demonstrated in the release party Home Assistant 9th Birthday Release Party (2022.9) - YouTube and I have 2 devices in the integration panel for my Olimex bluetooth proxy sticks.

( I do believe I bought them in vain, because I had hoped they would track my phones to be able to use that for presence detection, which they apparently dont, but thats besides this question/post for now)

Ive had a long and frustrating procedure yesterday, trying to adopt these boards in the ESPHome dashboard, and on Discord was helped (thanks again!) and advised to settle for not installing the ESPHome Add-on / Dashboard, because these devices do their job without.

However, If I want to use some other wifi esp devices, I will need that anyways, and will be confronted with the green ‘Discovered’ devices, ready to adopt.

Clicking Adopt takes us to:

which can not be (remember the device has been flashed to use Lan POE, see ESPHome Bluetooth Proxy and

if one defies that, and enters the wifi credentials, one can continue alright, and a secondary devices pops up

which errors because it can Not use both wifi and Lan (also reflected in the red 'offline variant of that same device a few seconds later):

But, during that procedure, a yaml file has been created in the config, we now can edit with the reference yaml in the GitHub repo: bluetooth-proxies/olimex-esp32-poe-iso.yaml at 3d4b712885cd43f20d69d482d1d0ccc735ed5d34 · esphome/bluetooth-proxies · GitHub

the Discord discussion yought us we need to add a static IP address for the router to talk to the device, (even with MDNS enabled on the router, and working fine) so I changed that to the fixed IP address I had also set in the router on the device:

substitutions:
  name: olimex-bluetooth-proxy-1

esphome:
  name: ${name}
  name_add_mac_suffix: true
  project:
    name: esphome.bluetooth-proxy
    version: "1.0"

esp32:
  board: esp32-poe-iso
  framework:
    type: arduino

ethernet:
  type: LAN8720
  mdc_pin: GPIO23
  mdio_pin: GPIO18
  clk_mode: GPIO17_OUT
  phy_addr: 0
  power_pin: GPIO12

###### this is required additionally
  manual_ip:
    static_ip: 192.168.1.135
    gateway: 192.168.1.1
    subnet: 255.255.255.0
########

api:
logger:
ota:

dashboard_import:
  package_import_url: github://esphome/bluetooth-proxies/olimex-esp32-poe-iso.yaml@main

esp32_ble_tracker:
  scan_parameters:
    interval: 1100ms
    window: 1100ms
    active: true

bluetooth_proxy:

button:
- platform: safe_mode
  name: Safe Mode Boot
  entity_category: diagnostic

and we can click save, and install. Hooray one thinks, because there’s an initial succes reported, and the device starts logging traffic. So, close that window.

Only to find this left:

repeating the sequence makes it even worse:

so, I settled for the integration only yesterday, but would love to fix this once and for all, for future’s sake.

bottomline: How to adopt the Olimex POE board without wifi credentials…

I did try this with both bluetooth: enabled and disabled in configuration.yaml, and have correctly recognized Bluetooth hardware in my MiniPC as reflected in:

---

side note: afterwards, I noticed a serious increase in Processor usage with the Olimex attached to the POE/system, so I checked the history of that sensor. Lo and behold, this is what happened during all of those efforts to try to adopt in Esphome:

% touching 100% a few times, and being extremely high as never noted before. That cant be right…

[vincen (Vincèn)]

I don’t know which Olimex PoE board you have but it should not be a problem ! You create a new sketch for ESPHome in HA (don’t use the wizard that is only designed for Wifi devices) but use the File editor or through Samba share if activated on your HA. Then flash the Olimex first time by connecting it by USB on your computer or HA host and you should be good
I don’t use myself the ESPHome wizard for new devices, it’s too annoying and too restricted ! and unable to handle devices without Wifi for now !

[Mariusthvdb (Marius)]

So I added the yaml file back I the /esphome folder, and restarted the add-on. the discovered devices is gone, and now this is appearing:

I validated the yaml (get the warning on the pin power) and now what do I click? Should I Update? the device has been flashed with the official Olimex files from the esp home repo after all. Or should I click Install directly.

btw this is the update, but what is that:

[bdraco (J. Nick Koston)]

The high cpu usage is a known issue.

The local Bluetooth adapters have been optimized as of 2022.9.3 and haos 9.x so be sure you have both updates.

The remote esphome ones are using the pure python protobuf library which is quite slow. Switching to the cpp version will reduce the cpu usage by about 80% (ymmv)

[Mariusthvdb (Marius)]

yes, running 2022.9.4 (just now) and OS 9 release, yesterdays 100% was on 2022.9.2 and OS 9 rc2

I’ve just ordered a Switchbot Thermometer Hygrometer, Bluetooth Digital Temperature Humidity Sensor and a VOCOlinc Intelligent contact sensor for doors and windows to check your showoff

now only thing left is how to adopt the device in Dashboard safely (without wifi)

[bdraco (J. Nick Koston)]

That will take care of the local ones but the esphome remotes need the cpp protobuf

If you have at least 1.5gib of ram free and can afford to wait 20m for a source build you can use GitHub - bdraco/fast_protobuf: Build the cpp protobuf if the pure python one is installed as a custom component to build the cpp version.

Don’t try this if you don’t have at least 1.5gib of ram free as it could overload the system

Just be sure to remove it when home assistant switches over to the cpp version in the future.

You’ll need to restart once the build is done (it’s in the logs only)

[Mariusthvdb (Marius)]

ehm, with remote, you mean the proxies, like the olimex?

[bdraco (J. Nick Koston)]

Yes. Remote proxies

[Mariusthvdb (Marius)]

memory shouldn’t be a problem:

btw that memory is only used during build and will be released afterwards?

so, I install this CC, and restart. All will be handled automatically then, no manual building or downloading anything else? Remember I am using HA OS, so can only install a CC in the custom_components folder

[bdraco (J. Nick Koston)]

It will only use the memory and cpu time while it’s building the cpp version. If your system is fast it may only take a few minutes. If it’s slow it could take much longer.

Once you restart it will use the new cpp version

It will automatically rebuild if hass is updated with a newer version of protobuf

You’ll still need to restart after an update for it to load the newly built version.

There is also a HACS file in that repo so you can use it as a custom repo

[Mariusthvdb (Marius)]

so I restarted with the CC. Do I simply wait, or do I need to install this manually:

[bdraco (J. Nick Koston)]

Watch the logs for when the build is done and restart

[Mariusthvdb (Marius)]

sure, but how does that build start? automatically after having restarted the HA instance, or do we need to Set up the new Integration Fast protobuf …

sorry for being stupid here, simply dont want to break things…

[bdraco (J. Nick Koston)]

As soon as you add the integration the build will start

[Mariusthvdb (Marius)]

ok thx, got it:

2022-09-14 15:01:48.540 WARNING (MainThread) [custom_components.fast_protobuf] Building protobuf 3.20.2 cpp version in the background, this will be cpu intensive

fingerscrossed this wont break anything…

right, pfff, that worked out fine.

2022-09-14 15:10:57.775 WARNING (SyncWorker_4) [custom_components.fast_protobuf] Restart Home Assistant to use the new wheel

restarted.
Seems to be fine, no idea how I can see this had any effect though. On the contrary I fear, I hardly ever see the CPU go below 10/12% though, even touches the 20-30 regularly, where before, the average was about 7-8, and minimum 3%.

[bdraco (J. Nick Koston)]

Does it show it is using the cpp version when it restarts in the log?

You may need to enable debug logging to see it.

If its still not performant, will need a py-spy and a profile

[Mariusthvdb (Marius)]

no, it shows nothing like that, only that the CC is found, and later on, is setup.

do I use:

custom_components.fast_protobuf: debug

?

btw, not sure if this would currently not be handled gracefully yet: I have 2 Olimex devices registered, but only 1 connected now, so I see the

2022-09-14 16:38:38.143 WARNING (MainThread) [aioesphomeapi.reconnect_logic] Can't connect to ESPHome API for olimex-bluetooth-proxy-277564 @ 192.168.1.221: Error connecting to ('192.168.1.221', 6053): [Errno 113] Connect call failed ('192.168.1.221', 6053)

Warning on the disconnected device. Not sure if this is trying to reconnect constantly in the background and cause inefficiency. Ill disable the integration for now.

Edit:

2022-09-14 16:45:52.985 INFO (MainThread) [custom_components.fast_protobuf] Already using 3.20.2 C++ implementation of protobuf, enjoy :)```

[Mariusthvdb (Marius)]

O dear. Horror is back.
getting back to the original question here, we shouldn’t click Update… because that results in:

uninstalling add-on, this is maddening. An experience definitely Not in accordance with ‘we all do it for you automatically’ from the Release party I am saddened to have to conclude.

And even that wont work as expected, after Uninstall, the add-on remains in the Installed add-on listing, albeit not installed… please go away.

[Mariusthvdb (Marius)]

@bdraco

If its still not performant, will need a py-spy and a profile

Will post those py-spy’s, but this is quite obvious already, I highlighted the moment I disabled the ESPhome integration for the Olimex adapter, but probably more important, the integration Bluetooth itself. An immediate drop in processor usage (note this is With the cpp you had me compile):

[bdraco (J. Nick Koston)]

It is possible it is not using the cpp version or something else is going on. Its not really possible to tell without the py-spy and profile though.