Failing to connect

[jcallaghan]

Great work here. What are your plans for the project?

I'd like to get involved and perhaps get this reporting over MQTT so Home Assistant can make use of the data.

Right now though I'm not off to a great start. I've just got the Meater+ and the scan script is able to see both the probe and the block but I'm not able to connect to either of the addresses using the readMeater.py 00:00:00:00:00:00 script.

Any chance you might be able to propel me into the long weekend so I can have some fun with this, please?

[nathanfaber]

Is your app/block/meater+ definitely powered down/disabled? You can’t connect to a meater+ right now and the fact that you see it suggests that it is still powered on. Can you try only connecting to the meater with everything else powered down/disables?

[jcallaghan]

If I place my phone in flight mode and use run.sh with the thermometer docked in the block, then undock it, run.sh can see both devices and fails to connect still.

[nathanfaber]

You are still showing the MEATER+ in the scan though. Can you try to remove the battery of the MEATER+ and then see if you can connect to the MEATER?

[jcallaghan]

AWESOME! I didn't realise I had to disconnect the Meater+ block. Does that mean block isn't required? Happy days. Thank you for your help. Do you have any plans to perform any more work on this project?

[nathanfaber]

I do, right now it is just a PoC. As you saw, it needs a bunch of work. I’ve been caught up with other work so haven’t been able to devote much more time yet.

[nathanfaber]

To answer your question, my original PoC was to remove the Meater+ and the Block and talk directly to the probes. So no, you don’t need either block other than for charging with this project right now.

[haklein]

From my tests with an ESP the connection to the meater+ was the same as to the meater. It's just that the meater+ consumes the single connection that the meater can handle. So if the scan shows a meater+, that should be used instead of the meater. Apparently the meater+ gives some range enhancement over the meater.

[nathanfaber]

Yes, I agree. The code can be easily adapted to work with Meater+. I believe it is actually just a version string (expecting _ for probe id). I just haven’t had a chance to take a closer look. Ideally, the code would be able to talk to all of the Meater BLE forms.

[jcallaghan]

An update from me. I have this integrated with Home Assistant now. It is POC right now but I'd like to look at getting this to run on an ESP32 with ESPHome or have this run as a service and constantly look for Meater probes. What do you think? Thoughts? Would you like me to contribute to your work or fork this project for that?

[codahq]

An update from me. I have this integrated with Home Assistant now. It is POC right now but I'd like to look at getting this to run on an ESP32 with ESPHome or have this run as a service and constantly look for Meater probes. What do you think? Thoughts? Would you like me to contribute to your work or fork this project for that?

This may be my end goal as well and the reason I'm watching this repository. I am integrating the block into Hubitat eventually. If I can't get what I need from the cloud integration that the app uses for remote communication I will go the ESP32 route running a REST API that I can query from Hubitat. I was planning on using Tasmota but ESPHome is fine too as long as the project is already running a web server or the bin is small enough that I can add a web server.

I haven't had time to reverse engineer the cloud API yet so I don't know if I'll need the ESP. @jcallaghan I think a good deal of the user base will be spread out so if you do start building support into ESPHome or Tasmota or something else, please consider making it generic enough to use on Hubitat, SmartThings and all the other platforms.

[jcallaghan]

@codahq would MQTT be enough for those other platforms you have suggested?

If so I have a working solution for this and have also created a service for this project so it starts on boot and continuously looks for known (rather than hijack your neighbours) Meater probes.

[codahq]

I'm assuming your solution can only play the role of MQTT client but not server? If so, it wouldn't work for Hubitat or SmartThings without another component to hold the MQTT server. And I think that's great. I don't think you should be hosting a MQTT server on a ESP32 for your whole home.

What you've done is great for a lot of other developers and tinkerer's because a lot of people will already have a MQTT server. I'm catering to a slightly different skill set and group of people though. That's why (when I finally break free with some free time) I will be more pursuing the cloud integration. The SmartThings and Hubitat hubs have the ability to talk HTTP/S and Hubitat even has a MQTT client but neither have a server. A cloud based integration would let me create something so simple that a user just puts their Meater credentials, selects their device and then it's working.

If for some reason I can't succeed at doing that then your MQTT solution will be good or an implementation that provides a REST API would be even better. I would have to help users setup a MQTT server and an ESP32 with MQTT. If the ESP had something I could talk to directly with the Hubitat/SmartThings hub they would only have to setup the ESP. Either way, it doesn't matter. I would be able to leverage a lot of what you would have done and if I end up using it... a big thank you in advance.

I'll know more once I try a MITM with their app. I just need more time and to finish a few higher priority items first.