LeafDeviceId is not present in the messages which are routed to custom module.

[rajaggrawal]

Hi,

I am running iotedge as transparent gateway and successfully connected my leaf-device with iotedge. I have deployed a custom module(management-suite) at iotedge and have added following route to receive reported property of leafDevice and i am able to receive it. FROM /twinChangeNotifications INTO BrokeredEndpoint("/modules/management-suite/inputs/input1")

Issue : twinChangeNotifications received at custom module (management-suite) does not have leafDeviceId present in the message. How will my iotedge module know which device sent twinChangeNotifications ? We are blocked due to this, could you please check this on priority ?

Note : I tried to fetch ConnectionDeviceId from message, but it gives edge-device-id. I did not find any way to get leaf deviceId. Adding leaf-deviceId in each reported property does not make sense.

[vipeller]

Hi @rajaggrawal,

What you are saying is that if we have an edge device named "MyEdgeDevice" and a leaf device "MyLeafDevice", then after the management suite received the routed message, the value of the COnnectionDeviceId is "MyEdgeDevice" (instead of the expected "MyLeafDevice"?

Can you give me an edgeHub version number, and also that which protocol (amqp or mqtt) you are using? Also, can you try if you change the protocol (e.g. form amqp to mqtt), does this behavior change? (I am talking about the protocol between edgeHub and the leafdevice and between edgeHub and the management-suite, and not the protocol between edgeHub and IoTHub) - the protocol you set in the code of your device/module

[rajaggrawal]

What you are saying is that if we have an edge device named "MyEdgeDevice" and a leaf device "MyLeafDevice", then after the management suite received the routed message, the value of the COnnectionDeviceId is "MyEdgeDevice" (instead of the expected "MyLeafDevice"?

Yes the value of the COnnectionDeviceId is "MyEdgeDevice" (instead of the expected "MyLeafDevice") Can you give me an edgeHub version number, and also that which protocol (amqp or mqtt) you are using? Also, can you try if you change the protocol (e.g. form amqp to mqtt), does this behavior change? (I am talking about the protocol between edgeHub and the leafdevice and between edgeHub and the management-suite, and not the protocol between edgeHub and IoTHub) - the protocol you set in the code of your device/module.

sudo iotedge --version iotedge 1.0.9.4

I am using MQTT, will test with aqmp and update.

[rajaggrawal]

tried using AMQP as well but still not worked.

I have used following tag/release of edgeHub and edgeAgent mcr.microsoft.com/azureiotedge-hub:1.1.1 mcr.microsoft.com/azureiotedge-agent:1.1.1

[rajaggrawal]

@vipeller

We are blocked due to this. Request you to please check and update .

[vipeller]

@rajaggrawal Hello,

Sorry for the delay. The code deliberately changes the source for twin change notifications, actually this was a bug before not changing it (and caused other problems before the fix.) Here is the commit for 1.1 in case you want to take a look:

https://github.com/Azure/iotedge/commit/10dc4abbee3f7c1d9591e5438fd47e473eeba578

this also means that if you need the origin of the twin notification (vs the connected device that actually sends the message out, in this case edgeHub), today the only way to accomplish that if you include it in the reported properties. I understand how it looks awkward and I am sorry that I cannot advise something more "out-of-box".

Let me know if you need help obtaining the device name to make your code dynamic (vs hardcode it)

[rajaggrawal]

@vipeller Thanks for update. so now we need to add leafDeviceId along with reported property whenever we need to set reported property :( Is there a better way to do this , i mean send it once instead of sending leafDeviceId in each reported ?

[vipeller]

@rajaggrawal no, unfortunately no better way at this moment. We have opened a ticket to fix it, but I am afraid that it is not going to help you short term.

[github-actions[bot]]

This issue is being marked as stale because it has been open for 30 days with no activity.