Component updates break existing configs

[miguelangel-nubla]

I don't know if you know about the following since it is in dev:

If I upgrade the device from esphome-tesla-ble/dev, it sucessfully compiles and works for a minute but then the device crashes and reboots without a helpful log message.

The culprit seems changes like https://github.com/PedroKTFC/esphome-tesla-ble/commit/8341a6f0417ef0692e474abde30032882d804976 in the config for the component, and me not updating the client.yml with the new sensors added.

I believe the internal component code just tries to write the state to those missing sensors and crashes.

This should not happen because the user is expected to only include yaml config for the sensors needed.
The component should check if the sensor is configured before trying to write to it.

[top-gun]

I think your approach is a bit off the standard. Most people use the example-yaml and that will load the latest client.yml from Github, so they have all the needed entities. Why would you not want the new entities, if I may ask? If you feel you don't need them, you can simply deactivate them and stay compatible with the standard codebase.

[miguelangel-nubla]

I do want them, but that is beyond the point.
This is just how esphome components work, not a quirk of my approach.

Either the option (entity config) is mandatory, in which case a compilation error must be thrown and compilation not succeed
Or it is not mandatory, in which case it should work fine without it.

Currently the behavior does not fit either.

I am just raising this up as I don't know if PedroKTFC is aware of this, and may be interested in incorporating this information to the development decisions.

[top-gun]

I do want them, but that is beyond the point. This is just how esphome components work, not a quirk of my approach.

Either the option (entity config) is mandatory, in which case a compilation error must be thrown and compilation not succeed Or it is not mandatory, in which case it should work fine without it.

Currently the behavior does not fit either.

I am just raising this up as I don't know if PedroKTFC is aware of this, and may be interested in incorporating this information to the development decisions.

Actually, if you use his example, the latest client.yaml is automatically applied and all new entities are automatically created. I use his example yaml and never had to resolve any missing entities, they always appear after the first boot of the new release.

[miguelangel-nubla]

No, that is a example esphome config provided as guidance.
You are the one out of the standard and clearly don't understand dependencies.

This is the only thing that should be imported, and someday might even be merged into esphome.

external_components:
  - components: [tesla_ble_vehicle, tesla_ble_listener]
    source: github://PedroKTFC/esphome-tesla-ble@dev
esphome:
  libraries:
    - https://github.com/PedroKTFC/tesla-ble.git

The rest is my own config which I control and modify to my needs.
If you want to use the example -as is- in you device go ahead, but other people like myself have more advanced use cases which inevitably result in the issue at hand.

[top-gun]

I commend you on your level of experience. Personally, I will continue to benefit from automatic configuration and wish you all the best.

[PedroKTFC]

I will look at this at some point but I confess it will be a lower priority at the moment, especially as my home broadband is currently down so I'm very limited what I can do. My immediate thoughts, without any further analysis, is that it would be a real pain in the code to check if a sensor exists so I'm likely to want to make it a compilation requirement.