Support for native API

[3D-DIYde]

I just came across this component and thought it’s exactly what I was looking for. I already have an ESPhome BLE Hub running and would like to add this component to it, to support my Eglo Bulbs.
But I find it odd, that MQTT is used instead of the official HA API. Any reason for this and are there future plans to support the native API?

[fsaris]

But I find it odd, that MQTT is used instead of the official HA API.

Odd? Little bit harsh to put it that way isn't :) ?

Any reason for this

Mqtt can be used by other systems then HA.
And I couldn't find a proper example to use the HA API directly from a custom component.

and are there future plans to support the native API?

It's on my list

[oxigen-dev]

I would vote for new features (eg. effects, transition) compared to using the HA API. I don't really see any benefit at this time.

@fsaris Keep up the good work and don't let anybody demotivate you :)

[fsaris]

HA API could also be seen as a new feature 🙂

[oxigen-dev]

HA API could also be seen as a new feature 🙂

Yeah, maybe from development side it can be a new challenge, but from user point if view the added value is close to zero. A lot of users already have an MQTT broker, but if not, it can be installed and configured in 30 minutes. On the other hand with MQTT you are not forced to use HA.
Ofcourse this is just my personal opinion 😉

[oxigen-dev]

HA API could also be seen as a new feature 🙂

Yeah, maybe from development side it can be a new challenge, but from user point if view the added value is close to zero. A lot of users already have an MQTT broker, but if not, it can be installed and configured in 30 minutes. On the other hand with MQTT you are not forced to use HA.
Ofcourse this is just my personal opinion 😉

[3D-DIYde]

@fsaris sorry if you found my word offensive, Englis is not my native language and maybe odd was a bad choice. So let's call it irritating ;)

Thanks for your explanation. But it's great to hear, that native API is seen as a feature for future improvements.

And just a side note on MQTT: I've ditched my broker a while ago and tried to get everything onto native API instead of MQTT, as I sometimes hat trouble, like with disconnecting Shelly devices or delays. Since I've switched to 100% API all of these issues are gone and so I'm simply not keen on re-deploying anything MQTT. But I'll definitely keep an eye on this repo.

[danxdz]

Hi, I don't understand why we need both ESP and MQTT. I made some modifications to your code, replacing the old Leiaz Awox BLE ( Bluepy ) and updating it to Bleak.
I haven't updated all functions, but I only need the turn-on and turn-off functionalities for now.

Take a look at this, maybe we can improve it together.

https://github.com/danxdz/awox_ha_hub

[fsaris]

@danxdz I guess you saw fsaris/home-assistant-awox#110 (comment)

I updated https://github.com/fsaris/home-assistant-awox/ to use Bleak (https://github.com/fsaris/home-assistant-awox/tree/bleak).
Connecting and controlling the devices worked.
But reverted/put on hold because registering for notifications didn't work. And for me that's a requirement as that's is used to get the current state of the devices.

So that's why I switched to esphome.

[fsaris]

So that's why I switched to esphome.

Oh, and because the connection is a lot more stable :)

[danxdz]

Well, maybe you're right. I had problems with the internal Bluetooth adapter, but I'm using an external one now. It's a lot better, but a bit slower. As for the state, I didn't search more, and I cheated for my use case. I'm just wondering if we can simplify it on the hardware side.

[fsaris]

I'm just wondering if we can simplify it on the hardware side.

See it as a cheap smart Bluetooth adapter that replaces your external Bluetooth adapter 🙂

[danxdz]

well i understand, but i think my problem with ble adpt its because of range.. and i just put the question because the topic its about using ha api.
gratz for your code, and its very nice that you find a workaround :D