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,
Related
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
I am in the process of evaluating HONO for IOT stack. We have scenarios where an intermediary device would send telemetry data for other devices. Communication through an Intermediary device is referred as a Gateway in Hono. I have found how to send messages through Gateways.
I am not sure on the following queries.
How to register the Gateway? Should it be registered as an ordinary device or anything else should eb done?
How would Hono verify if the message is indeed sent from the device whose device ID is specified? Any option to authenticate the real sender of the message?
Yes, a gateway needs to be registered as a normal device with its own device ID and credentials.
In order for a gateway to be allowed to publish data on behalf of another device, that other device needs to have its via registration property be set to include the gateway's device ID. Example: your gateway device has ID GW1 and you have a device with ID DEV1. Then the registration information for the device should look like this:
{
"via": [ "DEV1" ],
...
}
When the gateway then connects to the adapter and is successfully authenticated, it can publish data on behalf of another device by means of indicating the device ID in the URI, topic, address as described by the user guides of the adapters. The adapters then verify, if the gateway ID is listed in the device's registration information's via property and if not, rejects the data. The adapter thus delegates authentication of the device to the gateway.
Scenario
When business transactions are performed, we're supposed to make that data available to end clients.
Current Design
Our web app publishes transaction messages are added to a topic on the Azure Service Bus.
We expose APIs to clients through which they can consume the data from those transactions.
Upon calling these APIs, we read the messages from the Subscription and return it to the client.
Problem
We want a guaranteed delivery - we want to make sure the client acknowledges the delivery of the data. So we don't want to remove the message from the subscription immediately. We want to keep it until the client acknowledges it.
So we only want to do a "Peek" instead of "Receive".
So the client calls the first API, to get the data, where we do a Peek.
And once the client has received the packets, the client would call a second API, to acknowledge.
At this point, we want to remove the message from the Subscription, making it Complete.
The current design of the Service Bus Message Receiver is that, a Complete can be performed only using the same Receiver instance that performed the Peek, as per the documentation, and we also observed the same when we tried it out.
Both the APIs, are two separate APIs and we cannot do the Peek and Complete using the same instance of the Receiver.
Thinking about options to somehow make the Receiver as a Singleton, across APIs within that App Service.
However this will be a problem when the App Service scales out.
Is there a different way to achieve what we're trying to do here ?
There is an option available in Azure Service Bus to defer messages. Once a message is deferred, it can be received with the help of it's sequence number.
The first client should receive the message and instead of completing it, it should defer it and return it.
The second client (which has sequence number) can receive the message from the Subscription. Refer here for more details.
Another option would be to not use a Service Bus Client on your backend and instead your clients could directly work with Service Bus using its Service REST API (assuming they can't use the AMQP client if I am understanding your scenario correctly).
There are APIs to
Peek-Lock
Renew Lock
Unlock
Delete (Complete)
You could also proxy these requests if you'd like using your backend itself or a service like APIM if you are already using it.
PS: Cross posting the answer for the same query on the MSDN forum
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.
I would like to use Azure Notification Hubs to send push notifications to users of my app running across iOS, Android and Windows Phone.
I have managed to get the basics working but I don't know how to manage the App uninstall story.
On starting, the mobile app will call my Identity Svc to get an Auth Token.
It then calls its Platform Notification service (eg Google Cloud Messaging, APNS) to get a PNS Token.
After persisting the token to local storage it will call a back-end Contact Svc to register the customer's device. This service will create a subscription to the Azure Notification hub for the device.
This is illustrated in the following diagram:
Later on a back-end publishing service will call the Contact Service requesting a push notification for a particular user id. The contact service will lookup the Id allocated to a tag on the notification hub and send a push request.
What options are available to determine when a customer uninstalls the app? Is it just a matter of trapping errors when calling "Send" on the notification hub? I guess this could work if only sending to a single user but my intention is that certain message types are to be published to multiple subscribers. On the initial registration of a device a subscription will be created for a tag of the user id but also for a more general tag such as "New Promotion". The publishing service would later want to issue a "New Promotion" notification to all devices.
Why do you need to know app uninstalls?
Notification Hubs automatically expire registrations for devices that get uninstalled.
Also, I would avoid persisting the PNSHandles in your service at all.
The current guidelines for using hubs are the following:
store the registrationIds of the registrations associated with the device in local storage. This enables you to update tags and channel information with a single update call.
Because mobile connections are not always reliable, it is best to avoid creating a new registration without being able to store the registrationId in local storage. This can result in the device registering multiple times, causing duplicate notifications. You can achieve this by using the Create Registration ID and Create or Update Registration REST APIs.
The first API returns a registrationId without actually creating a registration. When the ID has been securely stored on the device storage, the device can call the Create or Update Registration API.
So I would have your ContactSvc expose two functionalities:
a) create registration id (just call hub to get it)
b) create or update registration given (registrationId, pnsHandle, tags?)
Then your device keeps the regId in its storage, ad after getting the handle from PNS, if as regId is not there creates a new one with endpoint a), then updates the registration with pnsHandle and tags.
Note that in this way your service does not need to persist handles or UUIDs, and does not need to worry about app uninstalls.
If you are keeping track of users, one approach is to periodically (once a month?) check in your hub if its registrations are still there...
You can reach me at #eliodamaggio if this is not clear.