Security Sensor Options beyond GC100

[OctDev]

There seems to be two general opinions on security systems with LinuxMCE; either tie an alarm panel to a global cache, or tie your contacts directly to the server.  I lean towards the later and am hoping someone can explain to me how this is cost effective.  I'm looking at an install encompassing 20 wired zones and 5-10 wireless zones.  That many global cache boxes seems ridiculous.  Are there any cheaper IO interfaces available (rs-232 not needed)?  Or would it be better to just hook into an Elk or a DSC for an install with that many zones?

[MarcoZan]

my 0,02 ...

I'm in the process to set up my alarm system by connecting all sensor to a Weeder I/O board.
They are 14 channel digital I/O boards, driven via RS232 and stackable also. They are also cheap (they cost 59$ each + shipping), surely cheaper compared to GC100.

I assume that when you say 20 wired zones you refer to 20 sensors (door/window sensors and similar), and this leads to the fact that you need 20 digital input channels.

If all of your wiring converge to a single point (as in my case) you may find Weeder boards very cost effective. If not, probably you better stick with GC100 as they offer an ethernet interface that make them easily to distribute around the house.

No real idea for wireless zones, maybe some one else can give a hint on this.

HTH

Regards
Marco

[hari]

you can also use Z-Wave for PIR devices and door/window contatcs. I'm sure there is some stuff for X10 and insteon, too.

best regards,
Hari

[OctDev]

Thanks all.  The weeder board is exactly what I was looking for, and coupled with Zwave it should work fine.  Much appreciated.

[tschak909]

we need a DCE device for the Weeder board.

-Thom

[darrenmason]

For an even cheaper option and maybe more open, try an arduino board. You can have up to 20 digital I/Os which could be hooked up to security sensors.

I have just bought a couple an attended a workshop on them more with the intention of using the analog inputs (sensors) rather than the digital I/O. The good thing about them is they use USB/Serial converter chip so appear as a serial port which can then use the generic serial device quite easily.

There is a bunch of shields (daughter boards) that can be purchased to neatly interface with things like XBee modules (Zigbee). I also bought a couple of these to have a play with.

Other options are the phidgets i/o boards. I have interfaced one of these with linuxMCE as well, although this used a C++ device rather than GSD. They are a bit more expensive though and seem to be catering more for analog sensors rather than control and switching (although they are capable of both)

Pretty much and of the USB microcontroller boards that are available will be quite easy to interface with linuxMCE.

It would be worthwhile getting a development thread going on coming up with a standard way of working with them perhaps.

regards
Darren

[MarcoZan]

Hi Darren

the arduino boards sound really interesting. The only drawback I see (obviously from my point of view) is that they are sold "naked", i.e with no particular firmware on board. From what I've read they come with just  a bootloader, but after that you are supposed to write your own control sw although they offer a free SDK.

Did you have any experience with their SDK? Is there any library with working sample?
This is just to get a rough idea on how complex could be to put in place a simple sw that monitors the digital I/O and sends related data via serial/USB.

TIA

Marco

[darrenmason]

Hi Marco,

yes they would need programming to do what we want. I am currently doing a bit of research as to whether there is a standard protocol that could be implemented.
There are a few options as I see it;

1. Just create a simple program using the SDK and talking serial. It is a vary easy language and the bootloader simplifies the loading. The program would look similar to this;
<code>loop()
{
     bool value  = digitalRead(PIN);
     serial.write(value)
}</code>
- Syntax might be slightly out - but you get the idea. There are serial libraries built in

2. Implement a protocol like xAP or something similar and then create a xAP device for linuxmce (if we don't already have it). This sounds feasible and would enable better reuse and interoperability. Haven't estimated the amount of work.

3. Make it a DCE device directly. Have it generate events and react to commands directly in the microcontroller software with the DCE stuff serialized for transport. This might be more conceivable than it sounds as from my understanding  this is how the Bluetooth Device works with mobile orbiters (albeit serializing over bluetooth).

I think I am most likely to implement option 1 to start with. I want to also investigate Zigbee as well and the Home Automation profile that is available for that.

Regards
Darren

[phenigma]

bump

Has there been any activity or progress with the Arduino?