Olivier Bloch

Hi @Deepak
the scenario you want to implement is most likely doable. There are several ways you can implement this depending on your application specifics such as throughput expected, latency,...
Azure IoT Hub will allow you to route incoming messages based on message properties as well as content to specific endpoint. If you want to apply a deviation on all inbound devices telemetry then the simplest way is to attach an Azure Function to the default endpoint of IoT Hub, then apply your deviation in the Function and output result. Depending on how you want to store then expose results, you have several options for the output of the Function such as blob storage, Time Series Insights Data Lake... once again the best way to implement this will depend on your scenario and application specifics. I recommend you check out our learning material on https://aka.ms/iotschool as well as docs.microsoft.com to identify the best solution suited to your needs.
Happy coding!

@Cholm321: The feature is still in preview and free to use during the preview period. The actual pricing has not been announced yet but will be on the page Reza pointed you to when we announce the General Availability. For now there is the following message in the Q&A section of the IoT Hub pricing page:

What is the price for the Device Streams feature (currently in preview)?

@Aydin Gencler: All the setup instructions are on this one ReadMe . Install steps are not as trivial as a one click deploy at this point in time, but that is very likely something the team will make simpler in the future

 

@Matt: This article should help you further: https://docs.microsoft.com/en-us/azure/iot-hub/tutorial-firmware-update

 

@RipinA: Nice catch! We have indeed not used the same buildings in the demo... which is using simulated data. But you can try the sample out for yourself and explore the capabilities of Azure Digital Twins on your own real data

@Geert Depickere:I knew this one would come back right at me!! :P

We are working at fixing this. Try again later today or tomorrow and the download link should work. Thanks

@diagramics:I think we are the ones not using it properly as it happens so that the voice is captured as well without having to bend over to the device (funny habit humans have to try and get closer to a microphone :)). Also the placement is practical to swipe the badge.

@RipinA:It actually does!

@Mark:You are spot on! The use of the MXChip board is just meant to illustrate the use case and the Chirp SDK is usable on other hardware

@Barrett: you can find all the service client samples (including code that shows how to add a device to the registry) in the Python SDK repo: https://github.com/Azure/azure-iot-sdk-python/tree/master/service/samples

 

@Steven McNeese: this is a great question. It's a bit of a chicken and egg question as a device won't have any sort of access to the cloud if it doesn't have an actual network connection. And for this reason, the Azure IoT platform itself cannot provide such a feature. 

As you might have noticed on most consumer IoT devices connecting to the Web, the user has to setup the Wifi connection at first use. This is one way to do this. Another way is to flash Wifi credentials on devices at production time, but this means you have to know where the devices will go.