Hi,
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:
Hi,
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 “contoso.azure-devices.net/MyDevice01/?api-version=2018-06-30” 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_Skvortsov2 FYI
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] MQTT_EVENT_CONNECTED
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: [mqtt_task] MQTT_EVENT_ERROR
MQTT_CLIENT: mqtt_process_receive: mqtt_message_receive() returned -1
MQTT: [mqtt_task] MQTT_EVENT_DISCONNECTED
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!
Hi,
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
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.
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_Skvortsov2 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?
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.