handleTriggerMessageRequest does not support the proper order of operations specified in the spec.

[zcweisman]

OCPP 1.6 specifies that a TriggerMessage.req must respond with a TriggerMessage.conf before the client send the message that was requested. The ClientRemoteTriggerHandler supports no method of being able to tell that handleTriggerMessageRequest has been called by the JSONAPI, or that it has returned, leaving the programmer unable to know when to send the requested message.

The only solution I can think of is to spawn a thread that sends the message before handleTriggerMessageRequest has returned and delay its execution some arbitrary amount of time. I prefer not to use this solution because it does not guarantee that the confirmation has been sent first. It would be nice to have a way to know that the handler method has run, built into ClientRemoteTriggerProfile.

[TVolden]

Hi @zcweisman

Thank you for writing.

Let me see if I have it right. You receive an trigger message request, and while you're in the handler for this request want to send an other request back? This would screw up the sequence of events dictated by the specification, am I onto something?

Sincerly
Thomas

[zcweisman]

I receive a trigger message request, I want to process it and return a confirmation that I will in fact send the message that the server is requesting. However, I do not believe the API provides no mechanism for me to know that I have sent that confirmation, or that handleTriggerMessageRequest has been called so that I can then proceed to send the message that the server is trying to trigger.

[TVolden]

Hi @zcweisman,

You are right, it's a dilemma. I haven't figured out how to solve it yet.
I have to look at the code some more. Just wanted to let you know I haven't forgotten.

Thomas