Hello Community,
I have a question regarding reserved general parameters (DataMiner Element Control Protocol) (https://docs.dataminer.services/develop/devguide/Connector/ReservedIDsElementControlProtocol.html).
I have a use case where we should do some action after the element state has been changed, in the documentation I found a reserved parameter 64502 (Name: STATE, Description: Element State).
When I try to trigger for example a QAction on this parameter I get a a major validator remarks stating that I am referencing a non existing parameter.
Interestingly, when tested for example the reserved parameter 65008 (Element Alarm state), the major validator remark is not showing up and the logic works fine.
My question is am I missing something to be able to use the reserved parameter 64502 for the element state value, and is it even possible to trigger an action after element state parameter value has been changed?
Thank you in advance.
Hi Sulejman,
I'm not sure if what you are trying to do is the best solution. If I am not mistaken, the STATE parameter changes with the element's state (start, stop, etc.). Therefore, if you are stopping and element you are also stopping the protocol logic that would be necessary to trigger the QAction.
Have you considered using the Monitors subscription (docs)? There are potentially other solutions, but I would require more information about the use case.
Hope this makes sense!
Hi Flavio,
thanks for the quick reply and suggestion, let me explain the use case in more details.
I am working on a smart-serial connector which can send messages and receive messages (SMPP Agent). To be able to send/receive the messages the user needs to "bind" a transceiver by pressing a button. After the "bind" has been established the connector can send messages and receive incoming messages.
The issue we are facing is if the element changes the state to "stopped" for example a DMA update, the "bind" stayed active and if there were any messages that came in that timeframe they are not processed and lost. We are trying to implement logic to "unbind" the transceiver (if it is possible on the element sate change). Reason being there isn't a way do execute a "GET ALL" to process all the messages since we are only able to actively listen for incoming ones. From what I found the only way to avoid this is to "unbind" the transceiver since when the bind is setup again all the messages will be pushed to the connector as they are queued after the "unbind".
Hopefully I was able to explain the use case in more details to you, if you need more information please let me know.