You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
c8y-mapper ignores any bridge status updates after the initial registration for the services of bridge status is done.
c8y-mapper reports the status "up" although the reported bridge status is 0 at registration.
thin-edge supports multi clouds. If both c8y and az bridges are configured, but c8y-bridge is up and az-bridge is down, still c8y-mapper should report the az-bridge service status "down" in the c8y tenant. However, due to the issue 1), after the initial 102 message for the az-bridge service, even though the az-bridge status changed, the change status won't be reported to c8y tenant.
Then, you can see these messages on the console running tedge mqtt sub "#". These messages are the proof that the new service mosquitto-az-bridge is registered in the entity store and the service is created in c8y.
Then you see nothing in the cosole tedge mqtt sub "#". This is the issue 1). 102 message should be created for mosquitto-az-bridge.
Expected behavior
At least other bridges (az, aws, ...) status updates messages from mosquitto should be converted to either SmartREST 102 or 104, and reported to c8y.
If the payload of the first bridge status message arrived in c8y-mapper is 0, it should be translated to "down". So, 102 service creation message should have the status down.
Screenshots
Environment (please complete the following information):
Additional context
I'm not sure if using 102 service creation messages always even to update the service status. This works like HTTP PUT. There is another SmartREST message 104, which is intended to update the service status only.
The text was updated successfully, but these errors were encountered:
Describe the bug
There are two issues.
0
at registration.thin-edge supports multi clouds. If both c8y and az bridges are configured, but c8y-bridge is up and az-bridge is down, still c8y-mapper should report the az-bridge service status "down" in the c8y tenant. However, due to the issue 1), after the initial
102
message for the az-bridge service, even though the az-bridge status changed, the change status won't be reported to c8y tenant.To Reproduce
[in the versions 1.0.0 and 1.0.1]
Then, you can see these messages on the console running
tedge mqtt sub "#"
. These messages are the proof that the new servicemosquitto-az-bridge
is registered in the entity store and the service is created in c8y.The last message should be
down
. This is the issue 2).3. Publish the status up message.
Then you see nothing in the cosole
tedge mqtt sub "#"
. This is the issue 1). 102 message should be created formosquitto-az-bridge
.Expected behavior
0
, it should be translated to "down". So,102
service creation message should have the statusdown
.Screenshots
Environment (please complete the following information):
Additional context
I'm not sure if using
102
service creation messages always even to update the service status. This works like HTTPPUT
. There is another SmartREST message104
, which is intended to update the service status only.The text was updated successfully, but these errors were encountered: