Olimex web flashing fine, but not really


I tried several time to flash Olimex Gateway with BLE and ETH. Flashing goes ok, but the gateway doesn’t start.
The same hardware is flashable with tasmota webflash tool on the same port. Any suggestions?


With v1.6.0 and ethernet board you have to do a custom build with the mqtt credential to make it work.
On the next release you will be able to onboard with wifi manager and use Ethernet after.
You can try the test version below:

Thanks! This works, but unfortunately the attributes of LYWSD03MMC are misused - the temp on the screen and in xiaomi integration is 23.3 C, while in OMG is shown on mqtt as voltage (23,36).
Humidity is 41%, while OMG shows 39%.

After refreshing mqtt devices in ha, the sensors loose their values and bceome unknown state.

Strange, are you using a special firmware on the Lywsd03mmc? Or the stock one?


Could you also set Advertisement and Advanced Data to true and post some sample MQTT messages from MQTT Explorer here, so we can analyse which raw advertising data might cause these erroneous messages?


Now I see that actually that might be the right data but not real time, so by coincidence numbers were similar.

Anyway I have problem with refreshing data from Lywsd03mmc. Stock firmware.
OMG identifies them and adds to MQTT, but the sensors are either empty or updated within a long threshold. There are some that are identified but never get values. I will check distance - maybe they are too far.
But the close ones are updated too seldom.

The stock firmware is not actually supported for the LYWSD03MMC, as it uses encrypted advertising messages, with OpenMQTTGateway not currently supporting decryption.

Could it be that you are using unencrypted ATC/PVVX firmware on these devices?

Or it could be that you are not actually picking up your stock firmware LYWSD03MMC devices, but some neighbour’s ones, which might also explain the intermittent receptions you are seeing, due to possible distance issues.

Another question - as I only have 1 Olimex gateway, but several ESP-32S (HW573 v1.3.1) I would like to test it as well. Trying different firmwares. Until now, I didn’t succeeded. Which one could I use?

Could you actually post some MQTT message for your devices, as can easily be viewed and copied and pasted here from MQTT Explorer?

My bad above, the stock firmware for the LYWSD03MMC is actually supported, but only by connection in OpenMQTTGateway, so any intermittent receptions you are seeing is likely due to the connection interval time set on your gateway.

Have a look at the BTtoMQTT messages and especially the “intervalcnct” key. The connection is only made in this interval, in ms, so setting it to a lower value will give you more frequent updates.

{“stat_t”:“home/OMG_ESP32_OLM_GTWW/BTtoMQTT”,“avty_t”:“home/OMG_ESP32_OLM_GTWW/LWT”,“unit_of_meas”:“min”,“name”:“BT: Connect interval”,“uniq_id”:“30C6F7F39A7C-intervalcnct”,“val_tpl”:“{{ value_json.intervalcnct/60000 }}”,“cmd_tpl”:“{"intervalcnct":{{value*60000}},"save":true}”,“pl_avail”:“online”,“pl_not_avail”:“offline”,“cmd_t”:“home/OMG_ESP32_OLM_GTWW/commands/MQTTtoBT/config”,“device”:{“ids”:[“30C6F7F39A7C”],“name”:“OMG_ESP32_OLM_GTWW”,“mdl”:“["WebUI","BT"]”,“mf”:“OMG_community”,“cu”:“",“sw”:"fb4229”}}


So I assume intervalcnct”:1980000 is far too large…

Yes, so the connection is only ever done every 33 minutes (1980000 ms) . Best to reduce this, but also keep in mind that an active connection is the worst scenario for the battery life of the LYWSD03MMC.

My advice though would be for you to look into the alternative PVVX firmware, to easily flash your LYWSD03MMC with the Telink Flasher. Then the temperature and humidity can easily be received by passive scanning, with no actual load on the battery life.

Best to try it with one and see how it improves your reception, which should then be every 55 seconds (“interval”:55555)

1 Like

And what if I would still like to keep the original firmware? Is there any good way?

Not really a goods way, to keep the stock firmware and still receive updates regularly you would have to set “intervalcnct” quite low, but then replace the batteries a lot more frequently.

Any reason why you want to keep the stock firmware? Most users seem very happy with the alternative firmware options,

I have 3 gateways from Xiaomi and they will be useless if I move to another firmware.
Then I would need to have another 3 to keep the signal quality on expected level.


How about ESP-32S (HW573 v1.3.1)?

Is it a good hardware for OMG?

True, that is an awkward situation if you want to keep your Xiaomi gateways as well at the same time. You only option then is to set “intervalcnct” lower, low enough to get decent regular updates, but not too low, as not to deplete the LYWSD03MMC batteries too quickly.

Or you get all your LYWSD03MMC on PVVX firmware and use 2 or 3 cheap ESP32 based OpenMQTTGateway gateways to get all the LYWSD03MMC’s temperature and humidity.

Or you wait for a future update of OpenMQTTGateway which includes decryption of encrypted advertising messages.

I don’t have LYWSD03MMC myself, but AFAIK it would be possible to go back to the stock firmware, if you wanted to try one LYWSD03MMC with the PVVX firmware, but best if someone with more LYWSD03MMC confirms this or not.

I have just tried with 1 out of 15 that I have. And there is an option to return to stock firmware.
So I would probably even try with all of them at once, but I need to have reliable solution as it is quite cold outside and I’m using all of them to control heating in my house and I need it very stable theese days.

So I actually need to get a bin for the hardware I have (ESP-32S HW573 v1.3.1) and I;m ready to go.

It might not be supported by the plain default esp32dev-ble binary, as the board definition should be
nodemcu-32s, according to the documentation


but a custom environment and build with PlatformIO with the relevant adjustment to the esp32dev-ble environment should work - not able to test here without any ESP-32S.

The seller says this is nodemcu.