Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
rajaggrawal opened this issue Mar 25, 2021 · 8 comments
Open

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

rajaggrawal opened this issue Mar 25, 2021 · 8 comments
Assignees
@vipeller
Labels
1.0.9 Targeted for 1.0.9 release customer-reported iotedge no-issue-activity

Comments

@rajaggrawal
Copy link

rajaggrawal commented Mar 25, 2021 •
edited
Loading

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 vipeller self-assigned this Mar 26, 2021
@vipeller
Copy link
Contributor

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
Copy link
Author

rajaggrawal commented Mar 27, 2021 •
edited
Loading

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
Copy link
Author

rajaggrawal commented Mar 29, 2021 •
edited
Loading

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
Copy link
Author

@vipeller

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

@vipeller
Copy link
Contributor

@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:

10dc4ab

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
Copy link
Author

rajaggrawal commented Mar 30, 2021 •
edited
Loading

@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
Copy link
Contributor

vipeller commented Apr 1, 2021

@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.

@varunpuranik varunpuranik mentioned this issue Apr 1, 2021
Merged
kodiakhq bot pushed a commit that referenced this issue Apr 2, 2021
@varunpuranik
Send connection device Id information on twin change notifications (#…
fa60e52 
…4762)

Issue: EdgeHub supports routing twin change notifications, which basically includes routing RP updates to other modules. The message that gets routed should have information about the device that sent the RP update. 
But because of a recent change in EH, this information got dropped. 
#4689

Fix: Fix is to route the information about the device/module that sent the RP update to the receiving module.
varunpuranik added a commit to varunpuranik/iotedge that referenced this issue Apr 22, 2021
@varunpuranik
Send connection device Id information on twin change notifications (A…
d7307a4 
…zure#4762)

Issue: EdgeHub supports routing twin change notifications, which basically includes routing RP updates to other modules. The message that gets routed should have information about the device that sent the RP update. 
But because of a recent change in EH, this information got dropped. 
Azure#4689

Fix: Fix is to route the information about the device/module that sent the RP update to the receiving module.
@varunpuranik varunpuranik mentioned this issue Apr 22, 2021
Merged
kodiakhq bot pushed a commit that referenced this issue May 1, 2021
@varunpuranik
Send connection device Id information on twin change notifications #4762
cd39064 
 (#4888)

Cherry-pick: fa60e52

Issue: EdgeHub supports routing twin change notifications, which basically includes routing RP updates to other modules. The message that gets routed should have information about the device that sent the RP update.
But because of a recent change in EH, this information got dropped.
#4689

Fix: Fix is to route the information about the device/module that sent the RP update to the receiving module.
@github-actions
Copy link

github-actions bot commented May 2, 2021

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

ggjjj pushed a commit to ggjjj/iotedge that referenced this issue Jul 22, 2021
@varunpuranik
Send connection device Id information on twin change notifications Az…
f0b7435 
…ure#4762 (Azure#4888)

Cherry-pick: Azure@fa60e52

Issue: EdgeHub supports routing twin change notifications, which basically includes routing RP updates to other modules. The message that gets routed should have information about the device that sent the RP update.
But because of a recent change in EH, this information got dropped.
Azure#4689

Fix: Fix is to route the information about the device/module that sent the RP update to the receiving module.
@pmzara pmzara added the 1.0.9 Targeted for 1.0.9 release label Sep 27, 2021
damonbarry pushed a commit to damonbarry/iotedge that referenced this issue Apr 15, 2022
@varunpuranik @damonbarry
Send connection device Id information on twin change notifications Az…
cd8549c 
…ure#4762 (Azure#4888)

Cherry-pick: Azure@fa60e52

Issue: EdgeHub supports routing twin change notifications, which basically includes routing RP updates to other modules. The message that gets routed should have information about the device that sent the RP update.
But because of a recent change in EH, this information got dropped.
Azure#4689

Fix: Fix is to route the information about the device/module that sent the RP update to the receiving module.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@vipeller vipeller

Labels
1.0.9 Targeted for 1.0.9 release customer-reported iotedge no-issue-activity
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@pmzara @rajaggrawal @vipeller