Ruuvi Gateway and Azure IoT Hub connection with MQTT

has anyone connected Ruuvi Gateway to Azure IoT hub using MQTT? I followed instructions (Understand Azure IoT Hub MQTT support | Microsoft Docs) “Using the MQTT protocol directly (as a device)” but with no data streaming to Azure.

Is it even possible to get connection working or do I just have incorrect parameters?


It seems like it should be doable in Gateway firmware version 1.9 which adds MQTTS support. The release is not ready yet, but if you’re comfortable with installing binaries over USB you can try our latest development builds available at Jenkins.

This screenshot is about our internal testing on older version, but it should be possible to configure all the fields required by Azure IoT hub:

Please let us know how it goes if you give it a try

I updated the firmware to support MQTT over TLS/SSL but now I have new problem. Have you limited the length of Username and Password on the Gateway’s MQTT configuration?

According to Microsoft documentation the username must be something like “” and the password “SharedAccessSignature sig={signature-string}&se={expiry}&sr={URL-encoded-resourceURI}”. It seems that username is limited to 50 characters. I’m not sure about password because it is not visible when MQTT configuration is done again.

I’m not sure about what the limitation is right now, but it’s likely limited to something shorter than Azure requires. I opened an issue about this so longer fields will make it to the release. @Alexey_Skvortsov FYI


For your information, Azure username can be easily 100 characters and password 200 depending on IoT hub and devices names.

The limits were increased to 128 and 256 in Close #386: MQTT: Username and password need to support long values (128 for username and 256 for password) by TheSomeMan · Pull Request #390 · ruuvi/ruuvi.gateway_esp.c · GitHub.

You can give it a try with binaries at ruuvi_gateway_esp-PR #414 [Jenkins]

now the username and password fields are ok.

When using domain name as a server, log shows:
“TRANS_TCP: DNS lookup failed err=202 res=0x0”.

This is fixable with IP address.

The next problem was message format. Azure docs says that message should be “devices/{device_id}/messages/events/” or “devices/{device_id}/messages/events/{property_bag}”.

I tried to make custom topic prefic “devices/RuuviGateway3DB6/messages/events” but Gateway stores only first two parts of the prefix as you can see on logs?
MQTT: [mqtt_task] esp_mqtt_client_publish: topic:‘devices/RuuviGateway3DB6/gw_status’, message:’{“state”: “online”}’
MQTT: [mqtt_task] “esp_mqtt_client_publish: message_id=18416”
MQTT_CLIENT: mqtt_message_receive: transport_read() error: errno=128
MQTT_CLIENT: mqtt_process_receive: mqtt_message_receive() returned -1

Finally I tried to add slash at the end of prefix and it caused the actual message to have two slashes.
MQTT: [http_server] esp_mqtt_client_publish: topic:‘devices/RuuviGateway3DB6/messages/events//gw_status’, message:’{“state”: “offline”}’

Now when I removed the slash from the prefix, everything finally started to work!

Thank you for testing.

@Marko Please test the MQTT prefix settings, let’s find out what causes the prefix to lose parts of it.

I have a questions about MQTT message format. At the moment sensor MAC is added to the message body e.g. devices/RuuviGateway3DB6/messages/events/<SENSOR_MAC_ADDRESS>. This way the MAC is added to the property bag of the message. At the Azure end this looks like

“body”: {
“gw_mac”: “XX:XX:XX:XX:XX:XX”,
“rssi”: -30,
“aoa”: [],
“gwts”: “1634641960”,
“ts”: “1634641960”,
“data”: “0201061BFF9904050F882365C5CD04040054FFD4AD366C8690FE9C…”,
“coords”: “”
“enqueuedTime”: “Tue Oct 19 2021 14:12:40 GMT+0300 (Eastern European Summer Time)”,
“properties”: {

So the MAC address is the name of the property, not the property value.

Could it be possible to change the prefix in order to have MAC as property value, not as property name? It would be like
devices/RuuviGateway3DB6/messages/events/mac=<SENSOR_MAC_ADDRESS>. If the last slash is removed then the prefix can have right format. Now the slash before MAC address is automatically added.

“properties”: {
"mac": "YY:YY:YY:YY:YY:YY"

It makes sense to me to let users control the custom prefix exactly, i.e. without forcing a slash. This also sounds like an easy change.

I am a bit worried about update changing the prefix, it might break existing installations. @Alexey_Skvortsov Your thoughts on this one? How the prefix is now stored in gateway, is a custom prefix stored as a whole string? Can we remove the forced trailing slash in html and not break existing installations?

any updates for this issue?

I would say that the need to alter topic freely and to add e.g. property_bag would enable the actual integration to Azure. At the moment I cannot figure out how the add sensor id (mac) to messages stored to database so only identifier is gw_mac i.e. all data is under single gw, not under sensors.


This should now be doable with custom prefixes:

So you have already fixed that. great!

Thanks for quick response!