I’m setting up an imp002 to run my home security system. I have the magnetic sensors on the doors tied to input pins and ground, and the input pins set to (DIGITAL_IN_PULLUP). The switches are normally closed, so they pull the pins to ground unless they are opened. This works flawlessly with pin callbacks, even without any hardware or software debouncing, when I open and close the doors. However, if the device sits on, and the doors stay closed, I get random random callback that read the sensors to be closed, as they are. So, a callback is being generated somehow, but the switches are closed. Is my configuration wrong for this? Code below. Oh yes, and any advice on more elegant code is definitely appreciated.
`//Home Security System
// Set local variables
systemArmed <- 0; //systemArmed = systemArmed?0:1;
sirenArmed <- 0;
alertArmed <- 0;
// Set up the functions
function soundSiren() {
server.log(“Sounding Siren!”)
}
function silenceSiren() {
server.log(“Siren silenced.”)
}
function sendAlert() {
server.log(“Sending alerts”)
}
function pinAchanged() {
if (hardware.pinA.read() == 1) {
server.log(“The Front Door has been opened.”);
if (systemArmed == 1) {
sendAlert();
if (sirenArmed == 1) {
soundSiren();
}
}
}
else if (hardware.pinA.read() == 0) {
server.log(“The Front Door has been closed.”)
}
}
function pinBchanged() {
if (hardware.pinB.read() == 1) {
server.log(“The Bedroom Door has been opened.”);
if (systemArmed == 1) {
sendAlert();
if (sirenArmed == 1) {
soundSiren();
}
}
}
else if (hardware.pinB.read() == 0) {
server.log(“The Bedroom Door has been closed.”)
}
}
function pinCchanged() {
if (hardware.pinC.read() == 1) {
server.log(“The Fireplace Room Door has been opened.”);
if (systemArmed == 1) {
sendAlert();
if (sirenArmed == 1) {
soundSiren();
}
}
}
else if (hardware.pinC.read() == 0) {
server.log(“The Fireplace Room Door has been closed.”)
}
}
function pinDchanged() {
if (hardware.pinD.read() == 1) {
server.log(“A Basement Window has been opened.”);
if (systemArmed == 1) {
sendAlert();
if (sirenArmed == 1) {
soundSiren();
}
}
}
else if (hardware.pinD.read() == 0) {
server.log(“The Basement windows are closed.”)
}
}
function pinEchanged() {
if (hardware.pinE.read() == 1) {
server.log(“The Sunroom Door has been opened.”);
if (systemArmed == 1) {
sendAlert();
if (sirenArmed == 1) {
soundSiren();
}
}
}
else if (hardware.pinE.read() == 0) {
server.log(“The Sunroom Door has been closed.”)
}
}
// Configure pins
hardware.pinA.configure(DIGITAL_IN_PULLUP, pinAchanged);
hardware.pinB.configure(DIGITAL_IN_PULLUP, pinBchanged);
hardware.pinC.configure(DIGITAL_IN_PULLUP, pinCchanged);
hardware.pinD.configure(DIGITAL_IN_PULLUP, pinDchanged);
hardware.pinE.configure(DIGITAL_IN_PULLUP, pinEchanged);
// Register with the server
imp.configure(“Home Security System”, [], []);
server.log(“Home Security System Online”);`
Are there long wires attached to these pins, by any chance? If so, you may be getting coupled noise into the wires that are causing triggers. The reason they are reading high is that the glitches are likely so short that by the time the callback enters, the line has gone high again.
The way to avoid this is to use a stronger pullup on the lines than the imp can provide internally - maybe put 4k7 pullups on there?
They are very long lines. The system was installed with the house. If I add pullup resistors between 3.3v and the pin, does that look like an additional resistor in series with Imp’s pullup resistor to the circuit? I’ll toss some 47k ohm resistors in and monitor.
This morning, I added 47k resistors between 3.3v and the pin. (I think that is correct?), but still seeing the callback. Here is the log, and it shows callbacks to several pins simultaneously according to the date/time stamp.
Wed Jul 31 2013 07:52:13 GMT-0400 (EDT): Home Security System Online
Wed Jul 31 2013 07:53:18 GMT-0400 (EDT): The Sunroom Door has been closed.
Wed Jul 31 2013 07:53:18 GMT-0400 (EDT): The Basement windows are closed.
Wed Jul 31 2013 07:53:18 GMT-0400 (EDT): The Fireplace Room Door has been closed.
Wed Jul 31 2013 07:53:18 GMT-0400 (EDT): The Bedroom Door has been closed.
Wed Jul 31 2013 07:53:18 GMT-0400 (EDT): The Front Door has been closed.
Wed Jul 31 2013 07:57:08 GMT-0400 (EDT): The Sunroom Door has been closed.
Wed Jul 31 2013 07:57:08 GMT-0400 (EDT): The Front Door has been closed.
Wed Jul 31 2013 08:13:20 GMT-0400 (EDT): The Sunroom Door has been closed.
Wed Jul 31 2013 08:13:20 GMT-0400 (EDT): The Fireplace Room Door has been closed.
I said 4k7 (4.7k) vs 47k, but still. Can you describe your wiring here? If the ground is “bouncing” then you will see this too. This tends to become a problem with long wires.
The other way to fix this is to add more capacitance to the pins (cap between pin and ground) which will slow down the response to fast transients. eg, 4.7k pull-up and 100nF to ground.
The runs to the sensors are between 15’ and up to probably 75’. The original circuitry was a12v system and used 3k3 resistors inline with the sensors. I think the sensor voltage was 5v though. BTW, I really appreciate answers that don’t technically have anything to do with the Imp.
I swapped out the 47k for 4k7, and it doesn’t seem to make a difference. I think I’ll try using a variable to hold the state and then check it with every callback, like you mentioned. I’ll monitor that for a while, and if it handles all the false positives for a few days, I’ll go with it, otherwise I think I’ll be setting up an RC filter.
The problem is, the imp is really seeing transients - hence the callbacks… how is the imp powered in this setup? Given the high capacitance of the wires attached to the inputs, if the imp’s ground moved “upward” then you’d see this as a low glitch on all the imps pins, with respect to the high capacitance pins…
The imp002 running the system is being powered by a Sparkfun April breakout that I accidentally broke the SD holder on. I’m using a wall wort with a Mini-USB plug.
I just added a state value for the callback to check against transients. So far so good.
Another question: My system would be susceptible to my wireless internet connection going down. What would be an efficient way for the Agent to poll the device on a regular basis, to ensure that it could talk to it? If the agent couldn’t talk to the device, it could SMS me and I could trouble shoot why, like a thief potentially snipping my cable internet connection, or a power outage, or wireless router malfunction, or the MOST likely, a Comcast outage.
Thanks peter. The agent-device combo actually makes the Imp a perfect match for a security system. I don’t need a call center, I have an agent. Time to hook device:ondisconnect up to Twilio.
Also, how often does the agent check on the device?
Right, and I’ll have the agent SMS me so that I know I need to resolve the connection issue. If the device is still running it can still sound its siren if a sensor is tripped for alerts in the home. The system has a 12v battery backup, so power shouldn’t ever be a problem.
ok, but are we sure that the imp acts that well, when it’s offline.
I suppose that’s a whole new science.
I am still surprised, how the imp sometimes reacts. I know it has always a logic reason, it is not always that transparent.
It checks every ~9 minutes right now. If you want quicker than that, then you can just send a heartbeat from the imp to the agent regularly, and if one is missed then raise the alarm (literally).
I will want to check more often. I’m finishing up the code, and the system is working really well! Just wired up the relay that sounds the alarm, which is insanely loud. The sensors are working perfectly with the new state checking code, and the agent is talking nicely to Twilio for SMS.
