Serialization of CQC SMS Serial Interface Driver

[gReatAutomation]

Is it possible to look in to serializing the SMS driver? Specifically, you cannot throw multiple SendMessage commands at the driver and have it process them.

Because of the way GSM modems work using AT commands you have to wait for the command to process before sending it another command.

Would be nice if in the CQC driver, the SMS SendCommand commands were serialized, objects then stored in the CQC database as a BLOB (or whatever is used), and then processed.

If I have a scheduled action that send an SMS message to more than one phone I currently have to put a System.Pause(5000) in between the sending of the SMS message. If a triggered event happens to run at the same time, one of the SMS messages will get dropped on the floor.

If not serializing the command/driver, perhaps adding a "Ready" boolean variable to the driver so that we could at least check that before issuing new SendCommand commands.

[Dean Roddey]

Yeh, a busy or ready flag would be a good idea.

[Dean Roddey]

Import this pack, and reconfigure the driver to pick up the change. I had to do this buy eye, but it's pretty straightforward so probably I got it right. It should set a Busy flag to true while the message is being sent.

[Dean Roddey]

Did you get a chance to try the tweak above?

[gReatAutomation]

Trying it now.

[gReatAutomation]

I can see the field, but now have to think through how to use it effectively.

Basically:

If Busy, wait, then check again and repeat. When not busy, send message

[Dean Roddey]

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.

[kfly]

A little off topic but just started moving my sms and all SMTP forwarding to this service after noticing that IFTTT has a built in service for them also...
https://developers.clicksend.com/docs/
(Note: you may need to ask for a free short code to send from if you want to send to AT&T in the US. Guess carriers are trying to reduce spam... finally)

May be worth creating some kind of interface in CQC to send an SMS using clicksend via one of their api's?

thx 
Kevin

[gReatAutomation]

Thanks ClickSend looks ok but I do not want anything remotely dependent on an Internet connection. SMS works when the Internet connection is down and when there is a power outage.

[gReatAutomation]

Dean Roddey

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.

Thanks. 

This seems to work. I've placed the WaitFieldValue off of the new Busy flag you added before each SMS command. I'll have to do this everywhere I am sending SMS messages. When testing one of my scheduled messages, I can see that the WaitFieldValue is between 2 - 3 seconds before it moves on to the next message.