Govee H5074 / OpenMQTTGateway v1.7.0 - esp32dev-ble often not getting Temp/humidity readings

TLDR: I would like to be able to get the temperature/humidity readings from the Govee H5074 thermometers more consistently/frequently instead of the other unneeded data I don’t really need.

I just started using OpenMQTTGateway v1.7.0 (esp32dev-ble / PlatformIO) recently for reading my Bluetooth Govee thermometers as a replacement for the tony-fav / tasmota blerry esp method which is no longer supported as there are now several other BLE to MQTT choices available. It seems most people are leaning toward the Home Assistant options but I have never gone down that rabbit hole as I developing systems for my son-in-law’s hydroponics greenhouse and store as well as his friend’s planned storage container mushroom grow operation and now using Mycodo as a platform.

I’m excited to have found the OMG project and looking forward to exploring it more. Be forewarned I don’t have a lot of experience with working with BLE data or coding. I’ve only been tinkering with microcontrollers and Pis a couple of years and mostly just use other people’s work, so may need more explanation than many.

One Mycodo dashboard at the store will be monitoring the walk-in cooler and freezer temperatures, among several other things, so my s-i-l can see the current readings as he glances at the monitor. The problem I’m having is about a quarter of the time one or the other of the temperature readings will show ‘no data’ as the MQTT broker hasn’t gotten temperature topic data in the past five minutes. I could cut down on the ‘No Data’ messages by increasing the ‘keep alive’ setting from the 300 seconds I now have it set for but I’d rather not.

I see that the information transmitted by Govee thermometers don’t always contain temperature and humidity data (see MQTT messages below) though always send RSSI info. The graph below shows one instance where there is about six minutes between temperature readings with four readings with RSSI in between (which I don’t need to track). In the past several days I’ve seen periods of up to 12 minutes without temperature data being sent to the MQTT broker.

If possible, I’d like to be able to get the temp/humidity readings more quickly and really don’t know where to start.

Three different MQTT messages received from Govee H5074 using OMG (all have “rssi”):

The useful one with temp/humidity data


The one with nothing I care to track


And the one with only the first three fields


For comparison, the following is the MQTT info is received when using ’Blerry’ instead of ‘OMG’. All messages contain the same fields.


Welcome @BillJuv

Could you tell us your interval, intervalacts and scanduration settings of your esp32dev-ble gateway? Visible in the BTtoMQTT JSON with MQTT Explorer.


Thanks, not being too sure how often the H5074 send out its advertising data which actually contains decodable data, I would suggest for you to adjust the settings like this to see if it improves the situation for you to an acceptable level.

You can publish these changes with the Publish section of MQTT Explorer, or through the WebUI of your gateway.
In MQTT Explorer the topic needs to be
with OpenMQTTGateway being replaced with the actual name of your gateway, and this JSON as the payload

I would assume that then you should get correctly decoded published messages with temperature and humidity every 30 seconds.

If you’re using PlatformIO you also might want to use the latest development version of OpenMQTTGateway, instead of the 1.7.0 release, as there have been many changes and improvements, all very stable and running here nicely, which will be coming in the next official release.

Thanks for your quick reply and concise answer.

I made the changes and I’m getting readings much quicker, though I still get the “junk” ones in between the temperature readings. It should solve my issue with not frequent enough readings.

I’ll spend some time looking through what you actually changed and what it means so I can learn something. Thanks again

1 Like

One thing I forgot above is to also set

which at least will get rid of the RSSI only junk messages, but not the iBeacon ones, as iBeacon is also a valid sensor decoder.

If you also set
without a save, only to have this set until the next gateway restart, and then post a message with properly decoded data and an iBeacon message which was published close to the previous decoded data, I can also see if the iBeacon messages might also contain decodable data, so that these broadcasts would also show as decoded messages.

Sorry, got called away and also had to re-add my white list as I didn’t think about that getting overwritten (I have about a dozen Govees around here + other BT).
I didn’t quite follow your last paragraph… do I set {"pubadvdata":true} through the webUI console or in MQTT Explorer, as I did the other? If Explorer, what topic? I’ll wait to post the two messages till I hear back.

Still learning…

You can do it all either way, with the topic in MQTT Explorer needing to be the full topic as stated above, while the WebUI already knows the home/yourOMGName/ part of that particular gateway, as described here

the same as for the other BT setting commands.

I. e. any setting you want to change in BTtoMQTT will need the topic

whereas if you would want to change a SYStoMQTT setting, you would send the relevant command to

With the white-list make sure that it is being sent with the RETAIN flag set, then it won’t get overwritten by any other non-retained commands, and it will also be persistent across restarts, as stated in the TIP here - BUT DO NOT send any of the other commands with the RETAIN flag! :wink:

And no rush with the advertising data included messages, as I’m close to bed time here :wink: but I will look at whatever you post tomorrow.

I’m sure once you get to know OpenMQTTGateway a bit better with all its options and settings possibilities, you will have a Bluetooth to MQTT decoding set up just how you need it :slight_smile:

No rush on getting back to me… goodnight!
I really appreciate your explanations and the links. I’ll read through the links later. When first venturing into a new platform it’s a bit overwhelming and your specific guidance is quite helpful!

I did the following through MQTT Explorer before your reply, but set all as ‘retained’ since I figured I would want to keep those settings as I would the white list.
Your statement above suggests I shouldn’t have?


As for the {“pubadvdata”:true}, I saw no response in the console when I entered it so I wasn’t sure it took. Once I read about using the console, I got a response…
‘commands/MQTTtoSYS/config {“pubadvdata”:true}’
‘N: [ MQTT->OMG ]: {“pubadvdata”:true}’
though I saw no additional information in the iBeacon message.

Here are the requested messages:



I don’t know how, I don’t know why, but RETAIN definitely is the new black - recently everybody seems to want to wear use it with every single command they send to a gateway :wink:

Joking aside - please DON’T!

Maybe it is because of the tip in the white/black-list section, and we need t make it clearer there, that setting a white-list or black-list is the only time a command should be sent with a RETAIN flag, all other commands must not have the RETAIN flag.

The internet is full of detailed articles about the MQTT standard, including RETAIN, but suffice to say here
• There can only ever be one single retained message per unique full topic
• Sending a whie-list or black-list to a BLE gateway is the only time in the whole OpenMQTTGateway eco-system when RETAIN should be set.
• Setting a white-list or black-list retained also means this list should be sent as a single command, not mixed with any other settings you might want to change.
• The only time you set the RETAIN flag again is only when you want to overwrite the existing white-list with an extended white-list which includes more MAC addresses of your additional Govees or other BT devices.

This is also why your mixed white-list and the other commands being sent together didn’t work.

To clear things up again you should sent the white-list separately with the RETAIn flag.

If you want to make sure that all other settings you want to change will persist over restarts, you use “save”:true when sending these commands, to save them into the flash memory on the ESP32. All detailed at

And for the “pubadvdata”:true to take it needs to be sent to the topic it actually is in, so not MQTTtoSYS but MQTTtoBT :wink:

Then it would be good to get the two example messages again, now including the additional advertising data :slight_smile:

Would be a good idea to put that line somewhere in the website instructions for OpenMQTT. I think it probably explains a couple of issues, the only ones I’ve had, with an otherwise excellent product.

Already done and submitted in a PR :wink:

But since this is not at all unique to OpenMQTTGateway, but a general MQTT standard feature, I suppose we assumed so far that anyone using MQTT would also read up a bit about its plumbings. Admittedly, when the first and only contact with MQTT is through OpenMQTTGateway and Theengs, then it might be an issue.

Exactly the case of people like myself who arrive here from Node-red, Smartthings, HA etc :ok_hand:

We really so far assumed that the fact that RETAIN is only mentioned in the white/black-list section, but not with any of the other settings commands at all, but them having a completely separate section about saving, erasing and initialising them in the gateway’s flash, would have been clear.

But as much as new users have to learn about all the workings of OpenMQTTGateway and Theengs, we also have to learn about how some documentation we find perfectly clear might be confusing to users :wink: and this RETAIN issue only really became very apparent with some recent forum threads.

Do not look at some of my old postings here, when I first started using OpenMQTTGateway, and was very confused myself about some things :stuck_out_tongue_winking_eye:

1 Like

So much to respond to…

Duh, I knew that. :roll_eyes: I really wasn’t giving it much (any?) thought when I thought combining the white list with the commands may solve my disappearing white-list. I didn’t notice I had the retain box checked when I sent the commands, then lost my white-list and wondered why… I should have gone to bed earlier.

If I’d only read that earlier, and remembered it.

This hobbyist tends to learn just enough about things to get what I need at the time then jump down the next rabbit hole. I’ve been using MQTT for a couple of years but, honestly, the white list was the first time I’ve ever used the publish section of MQTT Explorer. I came to MQTT through Node-Red and pre-written code by others. I learn as needed, which I’m sure I’m not the only one. Again, your patience is greatly appreciated.

Glad I could help. :upside_down_face: OMG does so much, and there is already so much documentation, it is almost overwhelming. Good documentation is likely harder than the coding. Good luck pleasing everyone. If you want I could point out some sections that had be really scratching my head to figure out.

But back to the initial subject:



1 Like

Instead of only pointing out the sections, and use having to figure out how to best phrase any changes aimed at users, it would likely be best for you, or anyone else thinking parts of the documentation could be extended or improved, to actually write up the changes in your own words, and as OpenMQTTGateway and all Things Theengs are open source, freely submit these documentation changes as pull requests in GitHub :wink:

While the advertising data is now included in the iBeacon message, it is still missing for the decoded message, otherwise it would also have “manufacturerdata”:"xxxxxxxx". This is likely due to it being copied before setting “pubadvdata”:true or using the general or a wrong copy button when getting the message. It’s usually best to use the copy button at the right of every individual message in the message history in MQTT Explorer.

But no worries, the duplicate identical iBeacon message made it pretty clear that there isn’t any decodable data in these iBeacon messages. I’m suspecting that they are some kind of beacon message to allow for a quick and easy pairing with the Govee app.

Could it be that you haven’t got this particular thermometer paired with the Govee app? It’s just a guess, but it could well be that the iBeacon messages stop after a pairing, but even if they don’t they should not really matter as they do not interfere with you using the properly decoded messages.