I'm trying to create an Identity Translation Gateway as described in here.
I have also read lot of Microsoft Documentation about their IoT solution.
I have :
leaf devices (A) connected to my gateway by a custom protocol without direct connection to the hub.
gateway devices (B) acting as a IoT Edge device connected to A and to the
IoT Hub.
My IoT Hub.
As far as I understand:
my IoT Edge has to register each device on the IoT Hub this way each
A device will be represented on my hub and we will be able to send
message via its ID directly.
I can send message and listen them on my gateway via the route
/devices/{deviceId}/messages
For the example let's say I have:
an IoTEdge device with Id : "Edge1"
an IoTEdge device with Id : "Edge2"
a device with Id : "DeviceA" connected to "Edge1"
a device with Id : "DeviceB" connected to "Edge2"
What I don't understand since there is no connection between hub and leaf devices is how, when i'll send a message to "DeviceA" with "/devices/DeviceA/messages", the hub will know which gateway address and how to listen it from my gateway. Doing the (un)multiplexing process, in short
Is there a way to handle it automatically with IoT Hub that I don't see ? The GatewayHostName inside the connection-string does the trick ?
Must I handle it manualy, sending all my messages to my gateways ID instead (i.e devices/Edge1/messages) and sending the final targetted device ID inside my message body ? If yes, i don't understand the benefit of registering each device on the HuB
Must I listen each connected device route inside my gateway (i.e
/devices/DeviceA/messages for Edge1) ?
thanks for helping.
Based on what I understand about your scenario, you are trying to send a message from the cloud to a module running on the Edge device and then have the module send the message to the downstream device. C2D (cloud to device) messages are not supported for Edge devices and modules. You can use C2D methods provided by the ServiceClient in the following package https://www.nuget.org/packages/Microsoft.Azure.Devices/1.16.0-preview-001 and call a method on the module. The module can then pass on relevant data to its downstream device.
Related
I have been trying to simulate a device communicating with the MQTT protocol, when I send the command to the orion from postman
{
"on":{
"type":"command",
"value":""
}
}
I create this service
{
"services":[
{
"apikey":"4jggokgpepnvsb2uv4s40d59ov",
"cbroker":"http://orion:1026",
"entity_type":"IoT-PublicServices",
"resource":""
}
]
}
I suscribe to this topic '/+/streetLight001/cmd', i use the wildcard '+', In the place of the '+' it is supposed to be the apikey but it does not work, could someone tell me what could be wrong?
According to the documentation MQTT commands are sent to the following MQTT topic when using an MQTT binding: /<apiKey>/<deviceId>/cmd
Note Measures and commands are sent over different MQTT topics:
Measures are sent northbound on the /<protocol>/<api-key>/<device-id>/attrs topic,
Commands are sent southbound on the /<api-key>/<device-id>/cmd topic
The reasoning behind this is that when sending measures northbound from device to IoT Agent, it is necessary to explicitly identify which IoT Agent is needed to parse the data. This is done by prefixing the relevant MQTT topic with a protocol, otherwise there is no way to define which agent is processing the measure. This mechanism allows smart systems to connect different devices to different IoT Agents according to need.
For southbound commands, this distinction is unnecessary since the correct IoT Agent has already registered itself for the command during the device provisioning step and the device will always receive commands in an appropriate format
We have an IoT based application device which is configured to communication with our Dashboard via MQTT bridge from Various service providers like Google, AWS and Azure.
So the flow is:
Device start TLS session with service provider.
Subscribe to a particular topic and wait for messages from the
service provider with 5 second timeout.
Dashboard publishes messages to same topic periodically.
IoT service provider broadcast it to all devices subscribed.
Publish and subscribe messages are with MQTT QOS 1 services.
Observation:
AWS and Azure works fine with above flow, but device stop receiving messages from Google MQTT bridge after 3-5 successful iterations even though our dashboard is publishing messages to Google IoT MQTT bridge.
For Google, we have identified that control flow is different when compared with Azure and AWS.
For Google, we need to subscribe and un-subscribe for a given topic every-time before waiting to receive message while for AWS and Azure we need to subscribe once during opening a MQTT connection.
Issue:
Sometime 5 sec device timeout occurs as it could not receive messages for subscribed topic from Google MQTT bridge. Adding multiple retries to overcome timeout issue was unsuccessful as issue still persist as device could not receive message from Google MQTT bridge after 45-60sec of device operation after powering on.
Is there is constraint with Google MQTT bridge to receive messages periodically without subscribing it every-time?
How can device receive messages without timing out (5 sec) from Google MQTT bridge?
Is there any workaround to recover a device once it got timed out with establishing MQTT reconnection?
I am using google iot core as well,the device side code for the mqtt client is golang while using paho mqtt package. this client package support OnConnect handler which while using this handler I achieve the recovery which I think you are looking for.
Via this handler I am re-subscribing to the "config" topic.
I think that google does not save the subscriptions which the clients are subscribed to and therefore the client needs to re-subscribe upon successful connection
Here's the golang code I've used (inspired by gingi007's answer, thank you!)
var onConn MQTT.OnConnectHandler
onConn = func(client MQTT.Client) {
fmt.Println("connected")
client.Subscribe(topic.Config, 1, handlerFunc)
}
mqttOpts.SetOnConnectHandler(onConn)
client := MQTT.NewClient(mqttOpts)
this way config updates keep flowing to my device, while if you subscribe outside of the onConnectHandler you'll just receive one config update when you connect.
If my device is offline, and sending event messages that are destined for $upstream -- how long will the local $edgeHub hold on to those events? In short, what's the max amount of time that the device can be offline before events start rotting away?
It is important to note that Edge hub provides at-least-once
guarantees, which means that messages are stored locally in case a
route cannot deliver the message to its sink, for example, the Edge
hub cannot connect to IoT Hub, or the target module is not connected.
Edge hub stores the messages up to the time specified in the
storeAndForwardConfiguration.timeToLiveSecs property of the Edge
hub desired properties.
You can set this property in portal like this:
As we know the device can only run one single connection by same client id, based on that. A physical device opens a connection with the device implementation to subscribe to the AWS IoT Shadow. I was wondering how it that will work based on the jobs implementation seems to create another new MQTT client
You use the same connection you already have for your device to use jobs. Jobs are used through publish and subscribe to specific topics. You can read more about jobs MQTT API here: https://docs.aws.amazon.com/iot/latest/developerguide/jobs-api.html#mqtt-describejobexecution
I already implemented the first 4 steps of the push initiator for blackberry
Send a push request
BlackBerry service returns a response
BlackBerry service pushes data to an assigned, specific port on device
Device returns response to BlackBerry service
Now I am working on the following two steps but nothing has happened yet:
5. BlackBerry service forwards acknowledgement to content provider
6. Read notification is returned to the BlackBerry service
Does anyone know how to implement that? I provided a domain when filling out the request but how do I achieve connection between me and the blackberry servers and how long do I have to wait for their response?
Actually your content provider send message to blackberry server and also specified the pin number of the device to which content provider want to send the message.
Your device automatically register with bb server if you have bb data service.
Your application is listening in the background on a particular port and your application also has particular app id that is provided by the rim.
So when content provider send message to bb server it also specify the app id and bb server has info about the port corresponding to this app id.and send message to the port of device whose pin is specified by the content provider.