Serialization of CQC SMS Serial Interface Driver

[gReatAutomation]

Great thanks. Will try it out.

[gReatAutomation]

This is a no go as well.. Driver is in an error state when trying to send message.



Driver details:

[Dean Roddey]

Ugh... To get rid of the warning message about unitialized fields, I set them to error state until such time as they get a value stored. But apparently the driver isn't storing values up front, and some that should be write only (and hence not affected by this) are read/write.

Let me take one more shot at it and I think we'll be OK.

[Dean Roddey]

OK, one more time...

[gReatAutomation]

Thanks.. set up another test of four consecutive SMS messages. Before each one I use WaitFieldValue to ensure SMSGateway.Busy is False before sending the message.



Only the first message is sent out, then this error:



I then upped the wait time to 10000 in WaitFieldValue and ran the same commands in scheduled action test so that I could see the actual number of milliseconds of wait time. The change to 10000 did the trick as I see that your changes changed the amount of wait time. Driver is busy for about 6500 milliseconds after sending a message whereas before it was about 2500 milliseconds.

[Dean Roddey]

Before it wasn't imposing any inter-send delay. So it would make sense it was shorter before. That's why you had to do it. Now it's imposing that. Of course one reason for WaitFieldValue() is that you can put a conservatively large time in, but won't wait any longer than is really required. So you can account for a worst case, but only ever pay for what really happens.

Oh, and another reason for the slight increase is that it's not just setting Busy back to false before returning from the SendMessage, it's doing it later during the driver's poll callback after the minimum time has expired. But the poll interval is a couple seconds. So there will also tend to be on average a couple seconds extra. I could now lower that poll interval since the stuff that the poll method does is controlled by time stamps now. So it won't do things too fast. That would let it more quickly get Busy back to false, if that would matter much.

[gReatAutomation]

Before it wasn't imposing any inter-send delay. So it would make sense it was shorter before. That's why you had to do it. Now it's imposing that. Of course one reason for WaitFieldValue() is that you can put a conservatively large time in, but won't wait any longer than is really required. So you can account for a worst case, but only ever pay for what really happens.

Oh, and another reason for the slight increase is that it's not just setting Busy back to false before returning from the SendMessage, it's doing it later during the driver's poll callback after the minimum time has expired. But the poll interval is a couple seconds. So there will also tend to be on average a couple seconds extra. I could now lower that poll interval since the stuff that the poll method does is controlled by time stamps now. So it won't do things too fast. That would let it more quickly get Busy back to false, if that would matter much.

Great change. Thanks. My particular CQC implementation makes heavy use of SMS.

[rhamer]

Hi all, I was contacted by Chris to help with this, but I don’t think I can offer much.
My only thought was to check if the AT command set supports a completed indicator of some sort.

The other (possibly dumb) idea was some form of generic async to sync driver that could generally queue action requests and feed them out sequentially.

Anyway, I am a long time out of it and I’m sure there are probably better ways these days.

Cheers

Rohan

[gReatAutomation]

My only thought was to check if the AT command set supports a completed indicator of some sort.

Sending SMS is the AT+CMGS command which, after sending a message, provides response of OK after message is send

Here: https://www.diafaan.com/sms-tutorials/gsm-modem-tutorial/at-cmgs-text-mode/

And

Page 120: https://www.elecrow.com/wiki/images/2/20..._V1.09.pdf

[Dean Roddey]

It could be made async queuing them up and spooling them out. It would just be tricky to implement by eye.