Missing PNP and Thermostats.py

[Addepalli-b]

There is a closed issue with the same, but there still seems to be missing files, I just wanted to know if there is a workaround to this. In this learn Microsoft tutorial links

we are meant to navigate to cd azure-iot-sdk-python/azure-iot-device/samples/pnp and run python3 temp_controller_with_thermostats.py

Both of which do not exist in the original git anymore. Is there a workaround for this?

[hhoswaldo]

I have the same issue

[lev-i]

Hi @Addepalli-b

Thanks for the heads up! We'll need to get that MS doc updated.

Due to the restructuring of the Python SDK for v3, the old temp_controller sample no longer works. You can still view it here: https://github.com/Azure/azure-iot-sdk-python/blob/744a896e0b4d94f024cf2eb820462739e1c2858d/azure-iot-device/samples/pnp/temp_controller_with_thermostats.py

As you can see, it uses pnp_helper which we no longer use, and references several parks of the SDK that have been reworked.

I took a look at the tutorial linked, and was able to confirm that all steps still work with the telemetry sample located at azure-iot-sdk-python/samples/iothub_simple_telemetry.py

So you can still start up the iothub_simple_telemetry sample, input your Hub connection string into the Azure IoT Explorer, select your device, go to Telemetry in the left menu, and hit Start to view the telemetry.

Let me know if that works for you, or if you have any other issues!

[lev-i]

@hhoswaldo

Same thing, if you have any issues with the above feel free to let me know

[robrennie]

@lev-i

The original sample showed how to send messages that were compatible with the digital twin - i.e. that's what pnp_helper.py did. It would convert a dictionary object to a properly formatted device message.

The new sample has none of that - no dtmi either. Completely different.

Hopefully after beta the pnp_helper is ported, or something else that shows referencing a dtmi and propertly formatting a pnp message, that was kind of the most important part of the whole sample.

[ryanwinter]

Hi @robrennie,

Most customers aren't using PNP so we have been focused on delivering these samples. Can you explain your PNP scenario so we can make sure we prioritize this in our future roadmap?

Questions:

1. Do you have a PNP model you can share?
2. What tools/services do you plan to use to communicate via PNP with the device?
3. Is this something you are prototyping, or something already in production?

[robrennie]

Hi @ryanwinter,

Thanks for the reply. I'm at a startup with a proprietary device and I'm trying to navigate through all the Azure IoT tools to determine whether we can/should use them. It is fantastic to learn (thank you) that at least PNP is not commonly used - so that's one thing to check off our list. I actually can't figure out what PNP is (exactly) from Microsoft documentation.

If most customers aren't using PNP, does that mean most customers are not creating "digital twins" (using DTML) that define their device? Are they instead just using IoT Hubs to send proprietary message formats, without referencing any dtmi?

Here is the Plug-and-Play repo with device twin definitions - it appears there are many and there have been updates as of last week. Are these essentially old tech?

https://github.com/Azure/iot-plugandplay-models

Thanks again for your guidance!

[ryanwinter]

Hi @robrennie,

PNP (Plug and Play) is a way to model the interface between the device and the cloud, such as what telemetry to expect and what commands is should respond to. It can make devices more discoverable would announce the model it is implementing at connection (the dtmi part) and the cloud side could lie up the model from the model repository. It was geared towards an ecosystem where devices could be developed and sold independently of the customers implementing the cloud solutions.

However we found out that most customers control both the devices and the cloud side making this interface mostly irrelevant as the customer already knows the interface for the device and this just adds some level of overhead. Also the same primatives (telemetry, commands, twin) are available without PNP, as PNP was built on top of an existing system.

Device twins are independent of PNP. Each device that is created in IoT Hub has a device twin associated with it and this device twin will interact with the device regardless of PNP, there is just some slightly different terminology, such as a PNP "writeable property" is very similar to the non-PNP "desired property".

I'm sorry this is such a confusing space, I think there is work we (Microsoft) need to do to further clarify this as I see the documentation is quite confusing. When PNP was conceptualized, I believe we thought there would be more use cases for it and customers should use this be default. At this point I think its the opposite and only use PNP if this adds value to your scenario.

[robrennie]

Hi @ryanwinter ,

Thank you, that is making much more sense and I had some inkling that might be the case. When experimenting with IoT Hub (as opposed to IoT Central) I realized it automatically creates device twins even if you don't create one yourself.

Last question, I'm looking at the v3 samples now, in particular iothub_multi_feature.py. I'm assuming this is the best example of a fully functioning Python device. Things I don't see (regardless of PNP) are the dtmi (the id of the digital twin) nor where property updates are handled. Maybe since it's a closed loop between device and cloud, there is no dtmi needed, and desired property updates just come through via messages?

I'm wondering what the point of the digital twin is at all if the device and cloud are exchanging custom messages that only they know about?

Thanks again for the help - I realize this is probably beyond normal "issue" conversation.

[ryanwinter]

Sorry I think I was a bit confusing above, the DTMI is the Digital Twin Model Identifier, which is referring to its PNP model id, this is different from the device twin. If you aren't using PNP, then you dont need to set the DTMI for your device.

It looks like we are missing device twin in the multi sample, this is something we will add for rc3. In the mean time you could look at the migration doc which outlines incoming message and there is a table showing the new function is .desired_property_updates().

So lastly, one thing to note is that a "digital twin" is different from a "device twin" :D But there are a few useful features on a device twin which are outlined more here. For reported properties, the device itself could report say the state of a switch (on/off) and the cloud could therefor simply look at the device twin to know the state of the switch rather than having to look through past logs, or interrogate the device itself. I have also used the device twin in the past to store configuration data for the device, so if the device is ever reset or replaced, it can pull all its configuration back from the twin.

Hope that helps!

[robrennie]

@ryanwinter - thanks for your help. This is great.

In IoT Central there are "device templates". So, there are "device templates", "digital twins" and "device twins" - what could possibly be confusing? ;-)

At least they're all the "DT" acronym!

Thanks again.

[lev-i]

Closing this out, feel free to re-open or file a new issue if you run into problems!