Serialization of CQC SMS Serial Interface Driver

[Dean Roddey]

In that case I wouldn't set the time to 20 seconds. Set it to something more reasonable and log an error if it fails to complete in that time. WaitFieldValue returns a status you can use in an If statement. So If it works, write the next message. Else, log an error and end the action. That would just be cleaner.

[gReatAutomation]

Thanks. Reason I am waiting 20 seconds is because I have numerous triggered events and some scheduled events that send out SMS messages.

Ideally, one would send the SMS driver a message and it would queue it and then send it. An SMS message queue.

[Dean Roddey]

That could be done, it was just too much to do by eye at the moment. And of course we can't just let those messages queue up without limit, so even then there would have to be a busy flag (or it just returns an error when you try to send another because too many are backed up.)

[gReatAutomation]

Use the Devices::WaitFieldValue (I think that's it.) It allows you to wait on a field to reach a value, or time out. That way you don't have to wait any longer than actually required.

Hey Dean. for Some reason the WaitFieldValue is not working even though running a test in action editor says it's working.

Setup in Action Editor:


Running a test:

End result is "Success" but I only receive the first message, not the second one:


I never receive the second text message even though the above notes "Success." The only thing that does work is placing a System:ause(5000) in between each message sent. Then I actually receive both text messages.



SMS Messaging is at the core of my automation system and I'd really like to find out how to resolve this.

[gReatAutomation]

So a single SMS has a character limit of 160 characters. If you send more than 160 characters, those messages are transmitted by a process called concatenation that splits up the message into smaller parts, which are sent as individual SMS messages and recombined on the recipient's handset.

This may explain the amount of time needed to send some messages, however, the WaitFieldValue should account for this, no? That is, if the modem is not done sending a long message, then the WaitFieldValue should wait the prescribed time before moving onward.

[Dean Roddey]

Oh, one thing I didn't probably get right is that I need to reset the field upon the next write to the send message field. I'm probably not, so it's not making you wait and hence failing. Always a risk doing these things by eye. Let me do that and I'll post you another driver pack to try.

[Dean Roddey]

Oh, wait, this is all meaningless. I wasn't thinking straight. You write to the field. The driver does a call right there and sends the message. It doesn't return until the message it sent. So there's no point in having a busy field in this sort of scheme. You won't come back from the field write until the message is sent. A busy field would only be useful in an async/queued type of scheme. So that was sort of a brain failure on my part.

So that must mean that either the time limit isn't in the actual sending of the message, but some inter-message limit imposed by the target service, which we'd have to know in order to deal with. Or, there's something else that has to be done to wait for the message to be sent completely, which I have no idea about.

If you look in the logs, are seeing errors from the driver about trying to send messages? I.e. is the send to the SMS server failing because it's timing out, or is the send working, but the SMS server is maybe rejecting it in a way that we aren't seeing.

It would be worth setting up a simple button on a test template to do a send of two messages in a row. Flush the logs, hit the button, and see what happens both do you get an error back, and does anything show up in the logs. That would help us know where to look to move forward.

[gReatAutomation]

So, I made up 4 buttons and then pushed them all sequentially and then a single button that sent 4 sequential messages.



Individual button action:

Single button sending all texts.

Pushing the individual buttons (Test1, Test2, etc.) all messages were sent although if I could click on them fast enough, not all messages are sent.

Pushing the single button (Test1234) that sent all messages.. Not all messages were sent.

[Dean Roddey]

If you didn't see any errors in the logs, or get any error popups from the actions invoked, then it has to be some limit that the server is imposing, and it's just rejecting the messages (or the modem thinging we are talking to maybe is imposing it.) If so, we may need to remember the last time we sent one, and use that to prevent the next one from being sent within some minimum time.

If you start putting sleeps between the events on the four message one, maybe starting at 10 seconds, and start cranking it down at second at a time, at what point does the work/not-work crossover happen?

[gReatAutomation]

If you start putting sleeps between the events on the four message one, maybe starting at 10 seconds, and start cranking it down at second at a time, at what point does the work/not-work crossover happen?

5000 milliseconds pauses in between messages does the trick. Problem is that I have several triggered events that send SMS message. So, in each triggered event, I need a way to ensure that when it sends, that the message will not get dropped because some other triggered event it sending a different message.