Mopeka Tank Sensor shows up as BBQ Temp Sensor?

[alfista2600]

Before submitting a problem please check the troubleshooting section https://docs.openmqttgateway.com/upload/troubleshoot.html

Describe the bug I just bought a couple of these sensors and upgraded to 1.6. I've searched the GitHub issues and looked at the troubleshooting and the data in one of the feature requests and my data looks very different. I can confirm the MAC address in the app.

To Reproduce Steps to reproduce the behavior:

1. Examine data in MQTT Explorer

Expected behavior Tank telemetry returned, not BBQ telemetry.

Screenshots

{"id": "A4:06:9:A6:63:5E",
"rssi": -47,
"brand": "Govee"
"model": "Bluetooth BBQ Thermometer"
"model_id": "H5055"
"type": "BBQ",
"tempc1": 0,
"tempf1": 32,
"tempc2": 449,
"tempf2": 840.2,
"batt": -110
}

Environment (please complete the following information):

• OpenMQTTGateway version used 1.6

Additional context Reasonable chance I've missed something simple, but not sure where to look...

[DigiH]

Hi @alfista2600

Could you turn on showing Advertisement and Advanced Data and post the resulting MQTT message received then?

This will allow us to see why your Mopeka has been recognised wrongly.

Could you also post a photo of your Mopeka, to show which tank sensor model you have?

[alfista2600]

Thanks for the reply! Looking forward to making these work. I think this is what you are looking for?

{"id":"A4:06:E9:A6:63:5E","mac_type":0,"adv_type":3,"manufacturerdata":"0d00000299291a48c0800507609081020e34d0400166a6635e","rssi":-44}

[DigiH]

{"id":"A4:06:E9:A6:63:5E","mac_type":0,"adv_type":3,"manufacturerdata":"0d00000299291a48c0800507609081020e34d0400166a6635e","rssi":-44}

Thanks, this is the correct data, but unfortunately it looks like it is an older model of the Mopeka sensors, for which we do not have a decoder.

Does it look like this from the front?

[alfista2600]

Sadly, it does. Is there something I can contribute to help develop a decoder (that would be fun) or do I need to go shopping for a new device?

[DigiH]

The Mopeka decoders are not easy to implement, due to the complex calculations to decode the information from the freely broadcast advertising data. So unless we can find an already implemented decoding of this data, usually supplied my Mopeka themselves, it is virtually impossible to reverse engineer it.

The fact that this model is not being sold new from Mopeka any longer, also makes it hard to find this information.

I do think however, that connecting to it, and reading the properties this way should be possible with this model.

Did you see my comment in your other issue, about connecting and READing service/characteristic from Bluetooth devices with OpenMQTTGateway? This should also be possible here.

For compatibility with Theengs Decoder and included decoding in OpemMQTTGateway, this model is supported

https://www.mopekaiot.com/product/mopeka-pro-sonar-tank-monitor

[alfista2600]

Thank you. Yes, I did see the post about sending commands with puck.js, but I decided it would be expeditions to put my M5stick in proximity to the device and use it to send IR commands. Less to sort out right now while super-busy, but do want to learn about sending commands to the puck eventually. Trying to queue up some things to implement before heading to our camper in a week for a much needed vacation.

I guess trying to be frugal didn't work out. I didn't realize these were old sensors, but they appear to work with the App so I'll deploy them that way.

I am unsure about what you are suggesting about trying to connect to this and read the values. I'm happy to try whatever you suggest, but some if it may be over my head.

[alfista2600]

I am looking at this now, to see if there is a good way of getting the data from wifi, if the sensors I have will connect to it. https://www.amazon.com/Mopeka-Bluetooth-Gateway-Propane-Sensors/dp/B07T7VRLBK?ref_=ast_sto_dp

[DigiH]

Using the same READ commands I linked to in the other issue, using the correct ble_read_service and ble_read_char, you should be able to read the different property values directly through a connection to the device.

Finding which service/char has which property, you might need to interrogate your model a bit with some phone app like nRF Connect, to have a peak at all the different service/char shown there.

I know it is a bit vague, but that's all we can currently offer, not actually having the device itself.

[alfista2600]

I consider it a great offer! This software is great so any support is greatly appreciated. I would be:

Happy to send you a device (I bought/need two but one would be a fun start). Happy to install a custom firmware if that helps with anything. Happy to install nRF connect (I had nRF toolbox) both of which I have only a vague understanding of what they are doing.

My other request was about sending more than reading, so I need to sort out some of these commands.

No worries or rush... this is just hobby stuff for me. Let me know if there is anything I can contribute!

[DigiH]

No need to send the device, as including it in Decoder will be virtually impossible without any direct kn knowledge of the BLE decoding, but let's hear what you might find with nRF Connect when back from your much needed vacation :)

Have a great time relaxing!

[alfista2600]

gotta survive another week

Is there anything interesting here:

[DigiH]

I can see Connectable: No in your screenshot :( so it seems you can't connect to see which services/characteristics the device might have.

Possibly by not having the Mopeka app active or unpairing the device from this or other phones might make it connectable, so you might want to try to see if you can get a connection with nRF Connect.

[DigiH]

Closing, as we won't be able to add this to Theengs Decoder/OpenMQTTGateway, due to lack of decodable advertising data.

If you do find you can connect and find some service/chars with nRF Connect, please post here in the closed issue.