@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.
@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.
@Scott: That's weird. I do have sound here and double checked the video directly and all seems fine. can you confirm you still have the issue after trying different browsers/machines and or rebooting? Thanks
You always have something that needs to be flashed on the device (firmware, bootstrap) that will have the code to connect to the DPS service. But this code will be the exact same on all devices coming out of the production line. When we say zero-touch provisioning in the device management space, that means that you don't need to have manual intervention on every single device to provision them with unique credentials and code.
You will ask "but how will DPS identify and differentiate devices from one another if they all have the same code running on them?". Well, this is where HSMs solutions like TPM are used. HSMs usually have unique secret seeds flashed in factory by chip makers which are used by our bootstrap code to authenticate when connecting to DPS. in the case of the MXChip devkit, there is an ST-Safe chip in there. Check out this sample that shows how to provision an MXChip devkit with DPS: https://microsoft.github.io/azure-iot-developer-kit/docs/projects/dps/