Charmed Quark Systems, Ltd. - Support Forums and Community

Dean, still having issues with the SMS driver, particularly with any Triggered Event or Scheduled Event.

Here is a Scheduled Event that I have that sends out the weather, daily. The event runs fine, however, only the first SMS message is sent, the second is never sent. As with above, running the Test on the action, the SMS is sent to both numbers. Additionally, if I have a test IV that has a button that sends two messages, both are sent.

Here is one of my Triggered Events that fires when the Garage OH door zone is opened. As with the above, only the first message is sent.



Here is the action:

We may need to make it longer than 5 seconds. Ultimately, without some sort of indicator of when it's legal to send another, it's going to be hard to do this accurately.

One other thing to consider is that if events go off near each other, they can both be sending msgs. In theory, as long as we have a long enough wait in the driver, that should still work though.

I'll post another here in a bit with a nice long time, and let's see if this is really timing related or maybe something else. Maybe ten seconds between messages.

Of course, for the short term, set all these events up to log invocations, so that you can go back later and see how often they are triggering and such, so we can be sure they aren't doing anything crazy.

As an FYI.. SMS driver is logging numerous events even with debugging disabled.

Seeing these errors

If you saw that, then the Busy field still must have been set. Though somewhat unrelated, you probably should do it like:

[codpe]
If Devices::WaitFieldVvalue(....)
// Send the message
Else
System::LogMsg(....., "Could not send SMS message");
EndIf;
[/code]

Or something along those lines, so that if it doesn't ever get the false busy, it will log something instead of trying to send the message anyway.

But, anyhoo, if you waited 30 seconds and still got that error that it's busy, that's not sounding right. I can't see how the busy flag could be left True, but I'll take another look at it.

If you want to set up the serial port server, and give me some temporary info I need to send some messages, then I can debug the driver form here against the actual hardware and see what's happening.

(09-17-2019, 05:27 PM)Dean Roddey Wrote: [ -> ]If you saw that, then the Busy field still must have been set. Though somewhat unrelated, you probably should do it like:

[codpe]
If Devices::WaitFieldVvalue(....)
    // Send the message
Else
    System::LogMsg(....., "Could not send SMS message");
EndIf;
[/code]

Or something along those lines, so that if it doesn't ever get the false busy, it will log something instead of trying to send the message anyway.

But, anyhoo, if you waited 30 seconds and still got that error that it's busy, that's not sounding right. I can't see how the busy flag could be left True, but I'll take another look at it.

If you want to set up the serial port server, and give me some temporary info I need to send some messages, then I can debug the driver form here against the actual hardware and see what's happening.

Thanks, I'll PM you the details.

As an FYI, WaitFieldValue is only available from the Cmd action.



WaitFieldValue is not available from the If/Else or If actions.

Oh sorry. SafeWaitFieldValue is the version that returns a result. So use that guy. It should be the same otherwise I think. I had to create a separate one because there wasn't a parameter left for a 'fail if not' type flag.

(09-18-2019, 02:10 PM)Dean Roddey Wrote: [ -> ]Oh sorry. SafeWaitFieldValue is the version that returns a result. So use that guy. It should be the same otherwise I think. I had to create a separate one because there wasn't a parameter left for a 'fail if not' type flag.

Hey Dean, any update on troubleshooting this driver?

I need to get some changes done before I have a working system again, then we can do it. Tomorrow should be OK if you are around.