Suggestion: Include barebones template for adoption in ESPHome

[Algid]

As I'm sure a lot of us power users have slightly custom network setups and already have plenty of other custom ESPHome devices it would be nice to have an official option for a adopted version of the HA Voice PE where custom config is required.

I have included below the minimal template I came up with in order to support doing this, this doesn't include some of the Improv BLE code as I didn't deem this necessary considering the device was being flashed directly with the firmware and WiFi details. I also have a section (disabled by default) for supporting self-signed certs as this was part of my reason for doing this. Updates can be performed by simply re-flashing the device over OTA via ESPHome.

I think considering the goals of this device being open and bringing choice to users having a section in the documentation or at least in this repo with a barebones example (that is kept supported when future changes are made) like the below would be very beneficial for power users, I hope if nothing else this helps someone wishing to do the same!

Either way thanks for all of the work on this device, it's great we now have a nicely packaged option for local voice and look forward to seeing it evolve more with time.

packages:
  home-assistant-voice: github://esphome/home-assistant-voice-pe/home-assistant-voice.yaml

esphome:
  name: ha-voice-pe-1
  friendly_name: HA Voice PE 1
  name_add_mac_suffix: false

# Enable Home Assistant API
api:
  encryption:
    key: "xxxxxxxx"

ota:
  - platform: esphome
    password: "xxxxxxxx"

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

# Enable for self-signed certs
# http_request:
#  verify_ssl: false

[jlpouffier]

I am not sure I understand the issue
The firmware is already split in two files, one that is not required anymore after taking control on the ESPHome Builder.

So even if technically the binary on the device out of the box is based on the factory,
the firmware after taking control is based on this firmware itself.

And thus you do not have Improv BLE, abd updates.

I think what you propose is already there. Correct?

[Algid]

Yes I agree - the current format works great as it stands.

My suggestion is simply that a solution for adopting the device with ESPHome is officially documented (even if it's not suggested for most) so that users who wish (or need) to make adjustments to fit the device into their setup can do so as currently documentation for doing this is lacking - unless I missed it somewhere!

Some users might not be familiar enough with ESPHome to realize this approach is an option and they could end up with a problematic solution leading to a poor experience. I don't claim to be an expert either but knew enough to make it work for me and thought it may save others time or solve their problems if something similar was offered.

Adopting helped me avoid issues with my IoT network not allowing internet access and my self-signed certs but I assume there would probably be other reasons someone may want to adopt their device too, without this solution I would have been a bit stuck.

[jlpouffier]

I do agree with you, unfortunately, I do not think we have a way to include a barebone file when taking control a device into ESPHome builder.

When you take control, the file is generated automatically, and points to the package we specify in this line

dashboard_import:
  package_import_url: github://esphome/home-assistant-voice-pe/home-assistant-voice.yaml

That is pretty much it.
What we could do is add a few substitutions for common case of taking control

[Algid]

Understood, my particular case may be a bit unique in that I didn't adopt my device within ESPHome but rather I simply created a new device in ESPHome and then compiled the firmware based on the above template to flash the device over USB. I took this approach as I couldn't get ESPHome to detect/adopt my device even though HA did (probably due to flaky mDNS or firewall rules between my subnets...) so I suppose I'm approaching this from that standpoint which is maybe pretty uncommon!

Maybe the existing solution/documentation is perfectly fine as it stands, I just thought it might be something worth raising in case others have experienced similar issues and thought it might be helpful to them.

I'm all for any further customisability though especially around device adoption for tinkerers!