What product/components do you use and which version/fix level?
Cumulocity
Backend: 1011.0.12
UI: 1010.0.24
Are you using a free trial or a product with a customer license?
License
What are trying to achieve? Please describe in detail.
We have installed communication between machine/gateway (south) and tenant (north) by means of the thin-edge.io <–> MQTT bus <–> thin-edge-io Agent - solution.
In the gateway we need to read an Event MO from the tenant.
And we want to use SmartREST.
Further information - this Event MO gets transfered via OPC-UA channel from the machine/gateway to the tenant. In EPL it is manipulated and we need to read it back to the machine via MQTT/SmartREST (not OPC-UA!).
Is it possible?
Any input, idea how to implement this, is highly appreciated.
Thanks in advance.
BR Manfred
In order to transfer information from the platform to a device we use operations. Technically it is possible to read event data from a device but then the device needs access to the event and it also needs to know when the data will be available. I would not recommend creating a solution like this because it will become a complex mess that works around our built in functionalities and our typical domain model.
Generally events are designed as fire and forget data that is sent by devices to the platform in order to convey some sort of information to users. Semantically it contains the information that something has happened on a device. We transport commands or information to devices using operations. Operations are triggered by users (or other components) to trigger an action on the device.
In your case I could imagine a solution that creates an operation from your EPL in addition to or instead of the existing process that you mentioned. Then you can create a SmartREST response template for the created operation and receive the data on the device as it occurs.
Adding to Philipps Answer: Can you share a bit more about the use case? What do you want to achieve, what is you problem you are addressing with that? Maybe we can come up with an other solution here.
I hope I can explain our use case so you have a better understanding:
The use case:
We have a machine state EVENT MO. This is sent from the machine and can have various values from 1 - x.
In EPL we combine multiple Events of the communication channel (OPC-UA, MQTT). If the result indicates a communication problem, we set MO=0.
Like this we get
0 = offline
1 = idle
2 = setup
… and so on
Now we want to read back this MO to the machine, to test / check the last segment of the complete communication circuit. In the end, the REST Server needs to receive a machine state information that is != 0. Then communication is OK.
If machine state received = 0, there is a problem in communication northbound.
If there is a timeout reading MO, there is a communication problem southbound.
So basically I see that you use thin-edge.io and the bridged local MQTT broker for communication. In that way I would not see why you want to check north/southbound connectivity for every single child device with the platform since they all run via the same broker.
What I probably would use is the watchdog service of thin-edge.io that checks the child devices and raises alarm if the service is stopped.
For the North/southbound check I would do that only via the parent device (thin-edge.io main). If the communication via the bridged local MQTT Broker works, it does so for every child device. That could be achieved e.g. via an custom operation (e.g. Heartbeat) that is triggered via EPL from platform side and answered by the parent device.
There still could be a problem on the OPC-UA communication that is not covered by MQTT check. Or does MQTT check if the OPC UA Server is up/ok. That the connection from OPC-UA Server to OPC UA Agent is ok? Thank you.
actually the OPC UA Gateway (Agent) is establishing and monitoring the connection to OPC UA Server. Is there something wrong the OPC UA Gatway creates an alarm for the OPC UA Server managed object. I am not 100% understand your comment, why is this related to MQTT?
still do not understand the real use case, lets try to split that out:
Monitoring of communication between OPC UA Gateway Agent and OPC Server:
This is already realized via the Gateway Agent directly. If the configured OPC UA Server is not reachable, an alarm will be raised on platform side.
Monitoring that Communication of the OPC UA Gateway Agent to Platform side via thin-edge.io works (northbound):
This can be realized via the mechanism of the required interval on platform side for the OPC UA Gateway Agent.
Monitoring that Communication from Platform to thin-edge.io works (southbound):
This could be realized with a custom operation e.g. heartbeat that needs to be acknowledged once in a while.
Monitoring that other components on local network (e.g. other child device agent components):
This can be realized via the watchdog approach of thin-edge.io.
Hi again,
I just saw now, that my answer was 'humilitated'. I answered by E-Mail, it seems this is not working so well.
So please find my complete answer here....
Hi Murat
Thanks for the detailed description and analysis.
I think now I know what was missing in the communication before
You write
Monitoring of communication between OPC UA Gateway Agent and OPC Server:
This is already realized via the Gateway Agent directly. If the configured OPC UA Server is not reachable, an alarm will be raised on platform side.
I want/need to have the connection status (or the alarm, all possible causes included**) in the system controller (most south point** )
For that I have a logic
This covers all aspects of OPC-UA and (bottom most) I want to include any issue of MQTT (I am still not sure about this, maybe this is not necessary, as MQTT will transport the operations).
The resulting MO (Event) I need to transfer to the PLC. For that I want to install an interval-timer in EPL and execute an operation to transmit this MO to the system controller.
This is important, as by doing this, additionally components (in the gateway (hosts thin-edge.io) and in the system controller) get tested as well.
The endpoint in the system controller only needs to expect every “interval” information about the connection status.
If it is not receiving, there it will raise an alarm because there is a problem south bound or in EPL
If it is receiving, it may show status “OK”
Or it may show any kind of OPC UA problem
(BTW: still need to find – in other words – I am not sure what I can achieve with the thin-edge.io watchdog).
)