Elk M1 Polling PC Connection via XEP

[sixburg]

Is there a way to poll a LAN connected PC?  I have critical programs running on network computer and communicating via XEP to the Elk M1.  If the PC goes down for whatever reason (power, BSD, etc) I need rules to take specific actions (turn things off, for example).  I hope this is something basic that I just don't know about because I'm a new user. 
 
Thanks for your help!

 

[RAL]

I think you probably can do this as follows.
 
Write rules to create a count down watch dog timer using an M1 counter.
 
Whenever the counter becomes 0, it means the PC is dead, so take whatever actions you need to shut things off.
 
Whenever an "I'm alive" ASCI text string is received from the PC, the PC is ok, so reset the watch dog timer and restart the count.
 
You'll need to write a small program or script to run on the PC to send the "I'm alive" message to the M1.
 
It's a good idea to send the "I'm alive" message to the PC 2 or 3 times more frequently than the value of the watch dog timer.  That will allow for some asynchonisity between the PC and the M1,  as well as the possibility of a lost or missed message.
 
Another way to do this would be to add a hardware watchdog timer, like this one, to the PC, with a relay output that you could connect to a zone input on the M1.

 

[pete_c]

Here I utilize a few commercial type motherboards with built in watch dog timers that can be connected to stuff external to the mother board and you can also do "out of band" management for a just in case scenerio these days  
 
My currently utilize Leviton HAI OPII panel can also be still controlled via a POTs line if I want it to be used in that fashion.
 
As RAL states above it is easy peasey stuff with your Elk M1 panel and just involves a bit of programming a inexpensive hardware.
 
My NAS boxes and Firewall run in BSD which never abends ...just keeps ticking forever....I can't break the stuff no matter what I do...where as and its been years ago I could sneeze and create a BSOD if I was in the vicinity of said box.

 

[sixburg]

RAL and Pete_C...
Thanks to you both.  You've hit on exactly what I need.  I like the approach of using "I'm Alive" code on the "host", but without introducing additional hardware.  Seems just running this loop on the host would suffice...if it stops running then it's likely the host is hosed.  Now given this simple but elegant solution, I need to figure out how to write the code to talk to the Elk...
 
Looks like Perl scripts can be used to control the Elk.  Seems like this might be a way to send messages through an Elk port...if that message stops coming, then bingo!  We have a problem. 
 
***
 
The host is running critical weather related equipment and communicates detailed weather information to the Elk.  Weather conditions trigger various rules and tasks.  If the host goes down then there is a potential for significant data loss.  Although it has never happened just talking about it has probably stirred some quantum-level gremlins who are now headed my way...
 
it is inevitable that the host goes down and the Elk would have no clue about critical weather events...we'd miss everything!   I need to know when the Elk is "blind" so human and automatetd backups can do their jobs.  The best insurance is always there, but never used.

 

[pete_c]

Like that weather stuff here.
 
Currently switched over to an RPi2 to my CumulusMX in mono on the Wheezy OS base on the RPi2.  With a beefy security panel power supply I could put the RPi2 inside of the alarm panel and you can do some Perl scripting and com to the ELK direct.  The RPi2 doesn't use much power.  The new fast microSD cards seem a bit better than the older generation ones.  I do temp writes to memory these days.  I do that today with a modded microrouter that uses wireless, wired and a 3G connection.  All this too has is using the panel batteries should a power failure occur.  Faster still would be a little Intel quad core Bay Trail CPU running 64bit Ubuntu Server.  I have one the size of a thin paper back.  It'll clock its quad core to over 2 Ghz and stock memory is 2Gb with OS on MMC.  It is entirely solid state with no moving parts.  The old weather server was using Windows server and a bigger box with the aforementioned commercial style mITX motherboard.  This little RPi2 box uploads to a mySQL DB, WUN, CWOP and a personal on the internet web server.  There is also a twitter plugin for updating a twitter account....and barely breaks a sweat.
 
Weather stations here are Davis Vantage Pro 2 and Vantage vue. (well it's not thousand dollar weather stations though)  I mix in a variety of 1-wire sensors in to the mix.  (lightning for one).  You can also add a Geophone sensor to get some thunder measurements.  Using a GPS/PPS for NTP which works out.  I also added a battery backed up RTC clock to the RPi2.  OS is fast and the box is a miniature device.  You can have two with one on standby to take over should something happen the first box.
 
Also have an analog trigger from a weather radio plugged in to the Alarm panel which triggers chimes and a text to speech alert with specifics about the NOAA alert (via configured stuff there).  I am polling the NOAA alerts site based on the weather radio alert with certain verbiage.  That said also mix in SD radio downloaded NOAA satellite maps.  The weather alert stuff  / hardware status is texted and emailed to whatever.
 
Here I utilize the weather data for irrigation which uses software and hardware to calculate ET and watering is based on % soil moisture metrics.

 

[sixburg]

Pete_C....very cool stuff!  For my application I have found an easy solution:  There's a driver involved that is already sending an ASCII text to the Elk every 45 seconds.   I didn't know about this, so the solution is totally simple.  I've set up rules to give 3 minutes grace or null polling results...if the Elk hasn't seen this text then the PC and/or driver is down which is bad for me.  After that phones and emails go crazy and people scramble! 
 
The weather application on my end is atmospheric and astronomical.  Rain is the enemy in my case!

 

[TurboSam]

I, for one, would love to know more about the driver... and the specifics. 
 
Is it something that is unique to the "critical programs" you mentioned you have running or something that can be used independently so I (and others) could monitor network computers using a similar solution?

 

[sixburg]

TurboSam...
 
There may be something you can use conceptually, but my sense is that the driver is very specifc. The driver is part of an astronomical observatory control system which is built around the M1.  It has all the standard controls and abilities (alarms, emails, voice, etc), but is tailored to the needs of a remote observatory like opening and closing roofs / dome shutters, controlling telescope piers, monitoring cloud sensors, etc.  The issue I've been working on involves redundancies to protect equipment from rainfall.  We use the system at a remote observatory called Deep Sky West at elevation (7,400 ft) in New Mexico.
 
The first line of defense against rain is an infrared cloud sensor which will trigger closure given a specific difference between the sky and ambient temperature that is indicative of excessive cloud cover.  Closure occurs well before actual rainfall.  If the cloud sensors fail we have 2nd and 3rd lines of rain defense automated via Hydreon optical rain sensors and a standard Rain Clik (a real last resort) -- each will trigger closure rules/tasks if needed.  Only in testing has the 1st line ever failed.  But there's a possibility of failure on the PC that monitors the equipment and sends signals to the M1.  To guard against this the solution I implemented takes advantage of the periodic polling already in place between the driver and the M1. And of course, we have on- and near-site staff for true emergency situations. 
 
The observatory is a large steel quonset hut (25x35 feet, 3,800 lbs).  It is actuated by an electric motor.  The entire building is on wheels and moves along tracks.  It is fully autonomous.  Each evening the M1 checks the status of the weather (cloud cover in particular), Internet and power.  If all is well, the building is retracted and exposes 10 telescopes to the night sky.  If at anytime the weather becomes unsafe, AC fails, or the WAN fails, closure is triggered automatically.  Aside from that, shortly after sunrise the roof/building is moved back into place and the cycle starts over the next evening. 
 
The telescopes inside are all set for  long-expsoure astrophotography.  They are themselves automated with the ability to point, focus, track, and take long-exposure images of multiple targets throughout the night.  Our user / members are from all over the globe and operate their systems remotely.  Some engage in research, but most of us just take "pretty pictures".  The telescopes we host are "escapees" from urban light pollution and other locations with poor atmospheric conditions.  We host and protect them...
 
You can see more about the observatory at www.deepskywest.com. 
Some "pretty pictures" all taken by me (all from about 2,000 miles away from the observatory):  http://www.astrobin.com/users/sixburg/
The driver is described at www.backyardobservatories.com/m1oasys.htm. 
 
Hope this helps. 

 

[pete_c]

Very neato.  BTW welcome to Cocoontech sixburg!
 
I almost dropped my coffee reading on the web site this morning and reading about your use of the Elk M1 for the observatory.

 

[sixburg]

Thanks!  It really is a pretty cool set up.  We have to build redundancy after redundancy, but the Elk M1 is definitely the star of the show.   

 

[RAL]

Thanks!  It really is a pretty cool set up.  We have to build redundancy after redundancy, but the Elk M1 is definitely the star of the show.   

 
Do you have a way to reboot the PC if and when it hangs up? 

 

[RAL]

You can see more about the observatory at www.deepskywest.com. 

Some "pretty pictures" all taken by me (all from about 2,000 miles away from the observatory):  http://www.astrobin.com/users/sixburg/
The driver is described at www.backyardobservatories.com/m1oasys.htm. 

 
I was looking at some of the pictures you took, and they are really fantastic. 

 

[TurboSam]

sixburg, thanks.  
 
Very impressive!  
 
It's always interesting and educational to see the things others are doing with automation (in general) or the Elk (in particular).

 

[sixburg]

We rely on the BIOS settings to reboot on power loss and restore.  I can do a power off reset via Digital Loggers IP Power Switch. 
 
Glad you got to take a look at the images.  They are purely "pretty pictures" and zero science.  Rarely it happens that an amateur imager discovers a new planetary nebula or asteroid or something.