Here’s an idea I got after some successful hardware tests: to write the ultimate, the most important script of all scripts that will, hopefully, never run its course. This may sound preposterous, but that’s what you get when the sole purpose of this script is to inform you that you’re about to lose your equipment/office/house or even your life(!) to a fire that has, supposedly, just started at your router’s location.
But first, let me get back to the aforementioned hardware tests. I’ve recently bought some cheap (~$10 including battery) optical smoke detectors for my house and, naturally, dismantled one to see what makes them tick (except for an empty battery, that is). What I found inside was quite simple: a single 16-pin SOIC chip, piezo speaker, LED, TEST button, optical smoke-detection chamber and - what piqued my interest - some hints at additional capabilities. This later made me open a few more, each of a slightly different board design but, as it turned out, they all seemed to share almost exactly the same MC145010-based schematics, even though most chips were actually marked quite differently. The main characteristics of this design are: 6-12V power supply, very low current consumption (common 9V battery lasts for a year) and an I/O pin for wired-or common alarm signaling of up to 40 detectors (meaning you can simply tie this pins from multiple detectors together and get them all sound the alarm at the same time).
To me, it looked pretty much like this devices were invented for serial-port powered use and I decided to test this theory in practice. So, instead of the battery, I used serial port DTR and RTS output pins for power source (connected through two 1N4148 small-signal diodes to a 100uF/25V capacitor) and also connected the aforementioned smoke detector’s I/O pin to the serial port RI(ng) input pin through a 330 ohm resistor. The I/O pin connection was already clearly marked on the detector board, but the resistor was missing so I just soldered one into the appropriate vacant spot. I also connected serial CTS input pin to RTS to be able to detect presence/absence of the circuit from my future script.
The x86-based router (an old Pentium III) I used for testing was equipped with only one serial port, which was thus automatically used for MikroTik console. This made it active right from the start without any additional configuration, so I just connected my simple circuit and measured almost 11V over the capacitor pins - quite sufficient, probably even for multiple detectors (I plan to use three). The LED on the smoke detector worked as usual, blinking every 40 or so seconds. Next, I issued the following command to the router:
/port print stats
0 name="serial0" line-state=dtr,rts,cts
Obviously, everything worked as expected, including CTS indication of smoke detector’s presence. After I pressed (and held) “TEST” button on the detector, it entered its normal alarm-testing state (fast blinking LED, loud beeps) and the repeated router command resulted with this:
/port print stats
0 name="serial0" line-state=dtr,rts,cts,ri
…for as long as the “TEST” button was held, after which it returned to the previous no-alarm state (dtr,rts,cts). The exact same thing should also happen in case of an actual alarm: the RI(ng) signal should go active and stay that way, indicating presence of smoke in detector’s optical chamber. I selected the RI pin for this purpose because most BIOSes can be configured to also recognize it as a power-on signal in case if the router is shut down.
After unplugging the detector from serial port, expectedly its state changed into the following:
/port print stats
0 name="serial0" line-state=dtr,rts
And that’s all I need so far. Next, I’m about to delve into development of the script which will use the described hardware and inform me instantly through all available means of communication (via SMS/e-mail and, hopefully, by dialing all the phone numbers I have) in case of the RI signal going active. In case of the CTS signal going inactive (i.e. if someone “pulls the plug”), I suppose just an SMS/e-mail alert should suffice. My idea is to use tools/sigwatch to monitor the port and start the appropriate actions - which is also the only way I know of how this could be done with MikroTik. I couldn’t find it, but please let me know if a script of the similar purpose already exists.
Sorry for the long post, however in case someone is interested I will publish everything in even more detail once I finish this project. I would also very much appreciate any help and/or suggestions, not to mention corrections of the eventual flaws in my reasoning here.
Cheers.