Support for self hosted API

[hipitihop]

I want to integrate Meater with my home automation system and voice assistant, but I want to do this completely offline for privacy, performance and to not be dependant on a internet connection. I'm prepared to self host and don't want to depend on the phone app.

Can I self host the cloud service and use this API or is the Bluetooth protocol to Meater sensor open ?, such that I can have e.g. a Raspberry Pi replace the phone app. I'm prepared to contribute and write the code and open source it for others.

[simonmaddox]

Hi @hipitihop. Great idea - I completely get the appeal of a self hosted solution like this.

Unfortunately this isn't something on our roadmap at the moment - our public Cloud API is considered "stable", whereas the Bluetooth protocol that the apps use may change without notice.

There are third party libraries (like this one) that claim to have reverse engineered the MEATER BLE protocol, but I can't speak to how they work, or how reliable they are.

Please keep us updated with how this goes though - we'd love to hear about your progress!

[Minxster]

I want to integrate Meater with my home automation system and voice assistant, but I want to do this completely offline for privacy, performance and to not be dependant on a internet connection. I'm prepared to self host and don't want to depend on the phone app.

Can I self host the cloud service and use this API or is the Bluetooth protocol to Meater sensor open ?, such that I can have e.g. a Raspberry Pi replace the phone app. I'm prepared to contribute and write the code and open source it for others.

The link that @simonmaddox has mentioned, does point to an old bit of code for reading BLE info via ESP(32). I've done some trial work with this and it does indeed work; it currently only read one probe at a time. You just have to be sure not to turn on the Block while using it. As the probe can only connect to one client at a time.

[hipitihop]

@simonmaddox and @Minxster Thanks, I'll take a look at https://github.com/nathanfaber/meaterble

[geiseri]

@simonmaddox since there is no desire for a selfhosted server, could the BT protocol spec be supplied instead? It's a neat device but so far IoT companies have not had a great track record when it comes to bricking devices that are no longer economicly interesting to their shareholders.

[Minxster]

I'd just add, it's not just the Bluetooth that can ben opened up, but WiFi/IP for the block also would be nice.

I recently found Ive lost all my previous cooks (history), so if I had better Comms locally stored, I'd not be in this pickle 😿

[simonmaddox]

@geiseri I understand your concern here. I can say that we'll always try and be better than other IoT companies, but being realistic I can't see 5-10-20 years into the future. We have no plans to deprecate any MEATER devices available right now, and I hope if that ever were the case we'd do the right thing here.

As I mentioned above, the Bluetooth protocol is currently subject to change without notice. We changed it in a recent app release to support new app functionality, and may need to change it again in future. It's a hard sell to the management team that we should keep our Bluetooth protocol static, or add a multiple-month delay while we give notice of change, only for our Customer Support team to inevitably receive emails because a Home Assistant plugin that we don't manage no longer works.

That said, the more people that ask for this feature the more likely it is to be heard. All I'd ask is that developers ask here, rather than inundating our Customer Support team with these requests - it slows down responding to emails that they can actually help with.

[simonmaddox]

I recently found Ive lost all my previous cooks (history), so if I had better Comms locally stored, I'd not be in this pickle 😿

This is a bug in our internal API not returning all cooks. It's being worked on as I type this, but no current ETA for a fix. Soon, we hope. To confirm, no cooks have been lost - it's just the API not giving them to the apps. The cooks should just reappear for you in the app once this is fixed.

[Minxster]

This is a bug in our internal API not returning all cooks.

Thanks @simonmaddox for posting back on the missing Previous Cooks. I could originally work around the temperature data being off/wrong as I could manually recalculate the values, but the "cooking time" can be even more important sometimes, so it's not good at all that we're missing data without being notified.

But just to add, I know this is not the right place to discuss this, only as this is the Open API bit. So thanks for helping/talking about other services here.

[geiseri]

@simonmaddox that is why I would be more interested in just a document. I know full well getting your devs to document code is hard enough, but ideally there is a text with annotations. After all most people who would read it are battle hardened after slogging through random pdfs and word documents that are in various stages of translation from Chinese ;)