There are x number of devices in system and y numbers of device owners. These devices are actively sending data to Azure IOT Hub - temperature, humidity, voltage, etc.
These devices have RFID chips inside them that store information about device and I'm working with Xamarin.Forms project that would allow android/iOS users to get this information.
Upon retrieving this information about the device, I want users to be able to see and monitor the device-to-cloud Azure IOT communication.
In similar fashion, I'm working on a web dashboard, where user could just select device from dropdown/selection and do the same thing.
I've tried implementing the
Azure Device Explorer approach, however here's the problem; in Azure IOT Hub, one consumer group can only have 5 clients and once, meaning, if 6 people want to monitor the live device-to-cloud communication, only 5 people will be able to do it. Furthermore, what this example does is - get all incoming IOT Hub messages, query and filter only the information that the user wants to see - which would probably put quite of a load on mobile phones.
So the question is: Is there a way to see live device-to-cloud Azure IOT Hub communication from a single device?
I'm open to adding other Azure services.
The Azure IoT Hub telemetry path (hot path) is a data stream of all devices ingested internally into the default built-in Event Hub or externally via the custom endpoint. To see a telemetry data from the single device, it is necessary to capture a telemetry stream and use a filtering technique for a specific data. In other words, the telemetry stream must flow transparently in the stream pipeline without any latency and the capture point will hold a copy of the telemetry window.
This warm path is close to the real-time (hot path) and it can be configured from 1-15 minutes.
The following screen snippet shows an example of the warm path using an Event Hub feature such as Capture. Note, that this feature is not in the Azure IoT Hub, so that's used a custom endpoint with an external Event Hub:
Once we have a telemetry warm path (stored in the Blobs, for example each minute), we can query a device messages, twin changes events and device lifecycle events based on the time, value, etc. by user request, eventing or trigger.
I am working on a similar project, we developed a web app with back end database. this db stores all the iot messages as it comes in, web app send the push notification via azure notification hub to the mobile clients interested about a device. All the business logic and operations is written in the web api project.
Mobiles directly do not communicate with IOT, they communicate via api to get the information from db, and using push notification helps to keep everything real time.
we are using azure functions for reading message from iot as it comes and process.
Related
I have a sensor that collects temperature data and sends it to my Iot Hub. This data must be evaluated. In some cases, the data must be sent to another device. Currently, I have a C# console application that does the job. It subscribes to my Iot Hub and reads the data from my partitions. As far as I understood, there must be an Azure component that should be used instead of a console application. My question is, what component can be used in order to receive data from an IoT device in order to process the data?
Thanks in advance!
Azure Functions is a serverless compute service that enables you to run code on-demand without having to explicitly provision or manage infrastructure. Use Azure Functions to run a script or piece of code in response to a variety of events.
you can utilize it instead of writing in a console app and scheduling it .
so a brief summary of what Im working with at the moment :
Im deciding whether I can do this with 1 topic vs needing N topics and both with the relevant metadata/filters.
I have 3 pieces pretty much; a socket server (worker role) of which units in the field connect to, Azure Service Bus messaging and finally a web app.
The user can queue commands to be sent to devices via the web app but we need to be able to hold messages in the queue until the device comes online of which it will then get all the messages. This is where I am confused...
I was initially working along the lines of dynamically creating 1-9999 topics (limit of 10 000 topics can be created, so using last 4 chars of serial) at the web app on messages being queued. Will then have the devices full serial within the metadata. This way as devices connect to the socket server I can create N subscriptions with specific rules and shut them down when the devices disconnect.
But now I'm wondering if I could just have 1 Topic and place all the logic within the metadata?
I am very new to SQLFilters with service bus so any help would be greatly appreciated :)
Good question! First of all, i should say that i would use IoT Hubs in your situation which is the "queue"-like service optimized for IoT scenarios, management and commanding included. Or Event Hubs, but they are less command pattern optimized.
1) Event Hubs
2) IoT Hubs
The first one is for scenarios that are more events-oriented. What i mean - to implement the management of the device from the backend will be more complex with the Event Hubs and less complex with the IoT Hubs.
I would highly recommend you to take a look at these services, because Service Bus is the great service, but the listed services are more IoT-oriented.
From the architecture standpoint, recently Microsoft published the IoT Reference Architecture whitepaper that you may download here. It has the recommendations, services, best practices etc that may be used for the Azure + IoT projects from the Microsoft point of view.
Another helpful resource could be http://azureiotsuite.com . It is the reference IoT architecture implemented. So, if you click on the Create, you will have one of two reference architectures (remote monitoring or predictive maintenance) in your Azure subscription and you will be able to review all of the flows.
So, i would recommend to consider to use IoT/Event Hubs instead of the SB Topics/Queues because in the IoT field, the service that is optimized for these workloads should perform better than non-optimized initially.
Second, you did not specify how you connect your devices to the Worker Role, so as i saw there is a good library for doing that called SuperSocket.
So, as i see your solution architecture may looks like:
Device 2 Cloud:
Devices => Gateway (SuperSocket or whatever) || IoT Hub => Device Registry (see links specified above)
Cloud 2 Device:
User Interface => IoT Hub with registered device => Device
Device Registry is more convenient way to do the IoT flows than transferring IDs or etc. Dynamic creation of entities has some downsides - imagine, if creation command will return timeout error, for example. Better to use optimized services, i believe.
When the device is offline, it will not poll the queue. Messages have some retention time before they will be stalled, that is the built-in mechanism.
I'm running Windows IoT on a Raspberry Pi.
After I turn on my Raspberry Pi and Windows IoT starts up, I want to automatically begin reading sensor data from a serial port continuously, and also send the data to a SignalR server/hub continuously. I don't need any UI.
I'm new at UWP apps. Is it best practice to use a headless background task for doing it? But how can I make sure, that the data reading and sending interval is not too long (~1-20ms)? Because I want to use a SignalR client to send the data near real-time.
First you should take care of the size of the package.
Maybe you should also think about using Azure IoT Hub. Azure IoT Hub is build exactly for scenerios like yours, receiving extrem high amount of sensor data in near real time from many devices. And it is highly scalable, and can be used from any client platform.
Here you find documentation, backgrounds and samples: https://azure.microsoft.com/en-us/documentation/services/iot-hub/
I want to send commands from one application (e.g. running on mobile device) to another application (e.g. running on embedded device) which is located in a different network.
I don't want to use VPN or something like port forwarding. So after some research I found some other ways to do that, for example via a cloud messaging service like Azure Service Bus.
Sending commands/messages from the first application to the service bus is not a problem for me. But I don't really understand how two get a connection from the cloud service to the second device? I know I can also send a message from the second device to a cloud service e.g. via HTTPS. And then the cloud service can keep that connection alive. As long as the connection is alive, I can send messages to the second device.
But there are some points I can't understand:
When I have thousands of devices, isn't that a problem to keep thousands of connections alive?
How can the second device listening the connection if there are new messages? Doesn't that needing too much ressources on the embedded device?
I also read about using "long polling" techniques and web sockets. I know too little to understand what are the advantages and disadvantages of those concepts. Which technique should I use for my problem?
To be more platform agnostic, I don't want to use services like Azure IoT Hub.
Edit:
Maybe I can use a web service and implement a MQTT Broker?
I think the mentioned MQTT Broker will get you there, especially as your usecase is exactly what MQTT and it's implementations (brokers and clients) have been built for.
The simplified story is the following:
A MQTT Client running on your Application 'publishes' a MQTT message using a 'topic' (think routing key) to the MQTT broker. A MQTT client running on your Devices have a subscription for the same 'topic' on the broker. This enables the broker to route the message from the application to the devices without the requirement that they know about each others.
As far as I understand your question your concerns are the following:
can all the devices be connected at the same time (thousands of open TCP connections) and therefore receiving messages published from your first application via the broker in 'realtime'.
assuming the devices will disconnect for whatever reasons, e.g. due to network problems or for decreasing energy consumption, how would be ensured that the devices will eventually receive the messages.
how will the devices connect to the broker.
Regarding 1. MQTT brokers are built to handle (and keeping) a massive amount of TCP connections. For example VerneMQ, a MQTT broker I can talk about, as I am one of the core devs, is able to handle over a million connections on one node (with proper server configuration it's actually mainly a matter of available RAM). However we'd only recommend such a setup if the devices are mainly sleeping. Using VerneMQ you can also add more nodes to the cluster and balance the connections among all your cluster nodes.
Regarding 2. A MQTT broker typically implements an offline storage for messages that haven't been send out to a client or haven't been acknowledged by a client. This allows your device to go offline for hours and receive the messages upon reconnect.
Regarding 3. This is specific to your usecase. In the simplest case you configure a fixed IP:Port on every device, and the MQTT client running on the device uses it to connect to the broker. Depending on the ability to reconfigure the devices it makes sense to use DNS lookups, or even to provide a 'backchannel' for reconfiguration.
For standard compliant MQTT client software have a look at Eclipse Paho. For an up-to-date list of available MQTT brokers consult the list of MQTT brokers.
I would like to automatically test my application that sends push notifications.
I would like to be able to get (or generate) a token from Apple/Google for both Android and Apple devices that will be accepted by Apple's or Google's server and making the notification sent to my tester-program.
i.e, I am running my program (lets call it A) to test some server. The tests are relatively complex and involve a lot of network communication. I am testing the server as a black box, I cannot mock anything. I want to simulate a phone with program A that opens the client application and registers for push notifications. Then, I want to be able to see these notifications received on program A. Everything should be done in code, and not depended a real device.
Is this even possible? Does Apple/Google allow this type of test? I've read that the Android simulator is capable of receiving notifications as long as it has an active Google account on it, which is fine. Can this be simulated without the overhead of an Android simulator? Can it be done for Apple's iStuff ?
Push Notifications in Mavericks iOS Simulator: It seems you can use the iOS simulator to test push notifications, but I get it that you do not want to use a the simulator nor a device.
What you are asking for should not be allowed by Apple, as it means non-Apple devices would be allowed to register for push notifications. Per https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html#//apple_ref/doc/uid/TP40008194-CH100-SW12, "APNs generates a device token using information contained in the unique device certificate. The device token contains an identifier of the device. It then encrypts the device token with a token key and returns it to the device." Thus, in order to create the desired token, you need a unique device certificate -- in other words, a real device or iOS 8 simulator. If you are trying to test on a single "device," perhaps you could forge one or copy from a real device, but I am sure that is against Apple's policies.