How do I send a "Power Cycled" e-mail?


I have a script for handling alarms, and one of them is triggered when power is turned on.
The problem is that a POST command is triggered when the eWON is OFFLINE.
As such, the POST command is never received.

Is there a way to hold off a script-generated POST command until after the eWON establishes a connection to Talk2M?



I would check for the VPN IP and then do a post.

For example, you can initialize a timer then post the data using an IF statement. Once the data is posted, close the timer so the eWON no longer checks.

INIT Section:
    TSET 1, 5
    ONTIMER 1, "GOTO initialize"

Initialize Section:
    a$ = GETSYS  INF, "VPNIP"
    IF(a$ <> "") THEN
        PRINT "eWON is online"
        // Add POST command here
        TSET 1,0 // Disables Timer

Let me know if this helps!


This suggestion was a good one. It gave me a couple of things to try.
However, it has a couple of flaws in my particular application.

The POST commands I send out in my script are generated by ONALARM commands.
If I hold off on setting up my ONALARM commands, I still miss the fault conditions.

Looking at my entire system, it made more sense for me to simply pass the “online status” of the eWON back to the PLC, and have the PLC wait until the internet connection is re-established before telling the eWON about any alarms it needs to report.

Broadening my horizons a bit, I realized that this isn’t just on powerup, but this scenario would apply any time my eWON is offline. (So far… so good.)

At this point, I figured I could just set a Boolean tag up in the eWON to pass along a online/offline status to the PLC, and just let the timer (TSET 1, 5) run all the time. However, the delay of 5 seconds means I might still miss messages, and the continuous checking 24/7 seems like a waste of processing power.

Is there a way to check the online/offline status of the eWON with something similar to an ONALARM command, where it is event driven rather than polled?



We have an ONVPN listener that may be beneficial here.

  INIT Section:
  ONVPN "goto CheckOnline"

  CheckOnline Section:
      i% = GETSYS PRG, "EVTINFO"
      IF i% = 1 THEN
         print "VPN ONLINE"
         My_Bit@ = 1 // toggle a bit in the PLC to represent online status
         print "VPN Going Offline"
         My_Bit@ = 0


PERFECT! (Almost…)
This event driven check does not properly set the VPN Active flag (My_Bit@) if the script is stopped and restarted. It reads as OFFLINE, when in fact it is ONLINE.

So, by combining your two code examples, I wound up with the following, which seems to work pretty well. There’s still a delay for the Offline event after I unplug the WAN cable of up to 30 seconds… however, that’s better than what I had.

INIT Section:
IF(a$ <> “”) THEN
PRINT “eWON is online”
eWON_Online@ = 1
PRINT “eWON is offline”
eWON_Online@ = 0

IF w% = 1 THEN
eWON_Online@ = 1
eWON_Online@ = 0

Thanks for your help!


Hello again!

Well, this solution has worked well for the last few months, but I’m back with a slight bug that maybe you can help me with.

From time to time, we will have a power outage that resets our eWON, but does NOT power cycle the PLC or vice versa. As a result, we may have a case where the PUTHTTP command in our script fails a POST command transmission. It looks like that PUTHTTP command will return a fault value in the status code.

Do you have some sort of retry sample code written to show how to wait a while and then execute that PUTHTTP command again… and what to do if it fails over and over?


Hey Mitchell,

How long do you want to wait before it sends out the PUTHTTP command?


In many cases, the internet connection comes back within 3-5 minutes. In other cases, it might be down for an hour.

Our thought was we would wait one minute for the first retry, and if that failed we would rebroadcast every five minutes until connectivity was restored. We have a local tag that tells us if the VPN is Offline, so there’s no need to rebroadcast in that condition.

This re-broadcasting would only be needed when the VPN is showing as ONLINE, but the PUTHTTP message fails.


I think I can write up something for a case like this, I’ll just need a little time to put it together

You’re saying that you have a tag that lets you know if you’re connected to your plc though right?


Take your time… I’m sure you could come up with it better and quicker than I could.

As far as the tag, no… we have a PLC tag that tells us if the eWON loses the VPN.
We could always add a new tag to determine eWON connectivity to the PLC, but I’m not sure how we’d do that either.

Is there a GETSYS read that would tell me if the PLC is connected to the eWON??


I had written something earlier that would send out an email if the ewon stopped reading a device’s heartbeat. Do you know if there’s a heartbeat on this PLC that I could use and just modify that old code?


I could certainly add a tag with a heartbeat (watchdog). What time period should it be?


I guess it doesn’t really matter how fast the heartbeat is, but the way it worked was it was a binary heartbeat and would send out an email if it didn’t see a change in value of either a 1 or 0 over the course of a time period. For the example I did, I think it would go off if it was idle for 5 minutes


We might have gotten a little off track here.

Our current system copies all of our alarm variables over to the eWON’s registers ONLY if the eWON tells us that the VPN is active. The watchdog part wouldn’t hurt but is a secondary concern.

If the VPN is active and the PLC successfully passes the alarm registers over to the eWON, and some alarm bits have changed state, then the script sends out POST commands to our web server.

The part we’re having issues with is that if we try to send the POST commands and the SETHTTP instruction faults, there is no retry mechanism… so the message never makes it to the web server and is lost forever. We would like to retry until successful (and temporarily suspend retry attempts while the VPN is offline).


Hey Mitchell,

Could you give me a call at 312 893 5636 tomorrow morning? I just want to make sure we both have an idea on what we’re planning on doing.



Just as a heads up,

This was the code I was planning on basing the code for you on.



Hey Mitchell,

I think that this should work

sendtomitch.txt (1.8 KB)


Hey Mitchell,

Just wanted to do a follow up on this ticket to see if that code worked for you



My boss gave me a different (more urgent) task to complete, and I have not had a chance to get back on this issue. I do appreciate how quickly you put this together. I will certainly get back on this in the next week or so and let you know.


Hi Tim,

To adapt your code example to our own application, the script command we are looking to check in our existing program is :
PUTHTTP “”,"/post_ewon.php",z$,"","POSTERROR"

In the event that this command returns a fault, I assume that the string “POSTERROR” would be returned somehow? If so, what line(s) of code would make this an actionable trigger? I’m guessing that I’d need to do something like this:
in order to acquire the “was it faulted” flag???

If that’s correct…
Could I use e% = “POSTERROR” to trigger a fault event?
What would e% be in the case of no fault? A null string?

If so, I then assume that:
TSET 1,120
ONTIMER 1,"@Retry()"
…would be a way to activate a timer to define a timer and resend the failed command after 120 seconds? …or do I not want to keep doing TSET commands for each new instance of an error?

If this is all good, then I assume that we’d need to do the test backwards and disable the timer if there was NO error. So… something like this?

Function Retry()
PUTHTTP “”,"/post_ewon.php",z$,"","POSTERROR"
(How do you turn off a timer??)

Let me know if I’m in the neighborhood or out in the suburbs.