Azure IoT hub Direct Method connect timeout - azure

I am trying to use Direct Method to invoke device OTA
The device I am using is Quectel EC21 and subscribe to the topic "$iothub/methods/POST/#"
When I Invoke the method in Azure IoT explorer,I always get the time out fail message that "message":"Timed out waiting for device to connect."
enter image description here
This error message confused me since I expect my device receive the method payload through MQTT from topic "$iothub/methods/POST/#" but I received nothing.
But at he same time, I can receive normal cloud to device MQTT message through topic "devices/deviceID/messages/devicebound/#"
So, is the Direct method connection and Iot hub connection are different connection?

After searching online and hint from Matthijs.
To make the direct method work, I found need to add api version in username field as below
For the Username field, use {iothubhostname}/{device_id}/?api-version=2018-06-30

Related

Azure Notification Hub not sending notifications randomly

For a few weeks there is an issue with Azure Notification Hub - we have a backend service that registers devices & schedules notifications. When one of the notifications is triggered, then we send it to Azure based on the device type (create the payload and all of that).
The response we get from azure is positive, the notification has been enqueued and is ready to be sent. However, it seems that Azure does not send them all. No error is thrown but only a small percentage is sent. It also does not seem to depend on the device type.
There are no logs to read - or none tha I can find and I cannot pin point the issue.
We have an endpoint that triggers the sending of a notification - we did a test run with 30 notifications (similar and different payloads for the same device) and it all went well.
Not sure how to troubleshoot this or what might cause this. I understood from the documentation that the device might be inactive and then the notification is deleted from the queue after a while. But it seems that the said device receives 1 out of 3 notifications (sent at the same time).
Any feedback would be appreciated.
Edit update:
After upgrading to the Standard plan, we managed to get some more information and it looks like Azure gives back a "Success" with a count of "1" but the device does not receive the notification - the problem is, this happens randomly. It's not always the same device that does or does not receive the notification.
Sorry this isn't a super helpful answer, but could you please open a support ticket in the Azure Portal for us to investigate your particular case? This does not seem like expected behavior so the team will have to look into the logs for your namespace and hub.
One immediate thought - there is de-duplication logic when sending notifications. So within a period of time (something like 15 minutes) if the same notification payload is being sent to the same device, Notification Hubs will automatically drop that duplicate notification.

Is there any option to get a copy of D2C message sent by IOT hub using c#

I'm working on an IOT project, my hardware device is not able to read message header. So not able to send feedback to IOT hub, because i don't have the ETag. Is there any way to get a copy of the message that sent to the device from IOT hub., so that i can save the etag and and can provide to the device when it requests.
Or is there any other way to solve my issue.

Azure Iot Rest API Message from cloud to device

Get : https://myiot.azure-devices.net/devices/mydevice/messages/devicebound?api-version=2016-02-03
Authorization: SAS key
i am getting 204 No content response from above api while receiving message using postman request maker from cloud to device.When i send messages from device to cloud it is appearing in my iot hub but giving error 204 while receiving messages from cloud.
First, if you haven't sent Cloud-To-Device messages and you get No content response(error code:204) from calling the GET api(https://myiot.azure-devices.net/devices/mydevice/messages/devicebound?api-version=2016-02-03). It is expected. It means the server has fulfilled the request, but there is no new information to send back.
Second, you want to receive the Device-To-Cloud message you have sent. It is unreachable. Because this GET api is used to receive Cloud-To-Device messages.
In short, Device-To-Cloud and Cloud-To-Device are different messaging primitives that Azure IoT hub provides to communicate with a device. And Device-To-Device communication that you want is not supported natively with Azure IoT Hub.
Finally, how to send Cloud-To-Device message?
For test purpose, you can send Cloud-To-Device message from Device Explorer. More detailed information you can reference here.
Yes, you can send cloud-to-device message
POST : https://[iotHubName].azure-devices.net/devices/[deviceId]/messages/deviceBound?api-version=2020-09-30
Header must include Authorization like :
SharedAccessSignature sr=webchatIOTHub.azure-devices.net&sig=lc7seNnczkq7Xj0IDSdFHshTTHEJUDt4y98e9Eoj%2B18%3D&se=1655587178&skn=iothubowner
For SAS (sharedAccessSignature) you have to run PowerShell CLI :
az iot hub generate-sas-token -n [iotHubName]--du 3600000000
Also, you can view the RestAPI when you use the browser to send message to device
enter image description here

Fiware: context registration's providingApplication attribute - IDAS UltraLight

Each time that a new device connects to an IoT agent, the IoT agent sends an updateContext to the context broker and a new context entity is created. And if this device has some lazy attribute the IoT agent will send a contextentityRegistration in order to create a context registration, to indicate to the context broker how can connect to the device.
But when the Context Registration is created, I'm not sure about the value that will be assigned to the providingApplication attribute.
It is used the ip:port of the IoT agent where it listens to the context broker requests?
or should it be the URL of the device?
Although I'm not sure, I believe the correct one it's the first option, because the device normally won't understand the NGSI protocol, and the IoT agent should translate the request before sending it to the device. If that's the case, then:
It is necessary some initial configuration, or when the IoT agent creates a new context Registration automatically establishes itself as the context provider?
Regarding the property "commands" used when a new device is registered by the IoT agent, what's their functionality? Are they used by the IoT agent to translate any request from the context broker addressed to the device?
Thanks in advance, any help would be grateful.
2) The property "commands" is used to define attributes of the ContextBroker entity that will actually tirgger a command to the device if they are updated using the NGSI API. This means tahta developers are able to read observations and also send commands just using one API (NGSI) with no knowledge of the specific device technology or protocol.
1) In UL2.0 lazy attributes are not supported so far. Please refer to the other IoT Agents for that.
Normally the IoT Agent IP:Port should be used for that.
Cheers,

Send IoT Message to Azure Event Hub by URL

I am now using a Beacon Reveiver to get the iBeacon Information.
Here is the problem:
the receiver platform server only allow me to type a url.
How should I do to send the information to azure eventhub??
I found this API:
https://NAMESPACE.servicebus.windows.net/EVENTHUB-NAME/publishers/PUBLISHER-NAME/messages
I tried it ,but it seems doesn't work.
Do i miss anything?? or Can anyone teach me how to add the authentication in url? What should I do now?
Thanks
You must set an authentication HTTP header in order to send events to Event Hubs. You can't include authentication information in the request URL.
Even though you can't send messages directly to Event Hubs, you can develop a custom Web API that uses your own URL-based authentication mechanism and forwards the requests to Event Hubs (or another service). That defeats the purpose of using Event Hubs to some degree but gives you more flexibility.

Resources