I've recently started playing around with Arduino Uno Rev3. and I'm considering developing a personal alarm system for my house.
Basically, I'll run everything on batteries, and I will use a central unit and several sensor units that will communicate via RF modules.
As far as I've already thought, I'll need to work with Keypads, LCD's, RF-Links, Buzzers, Sensors (motion, sound, etc...), GSM shield and so on.
Because I'm new to all this, I'm starting with small individual projects to learn and master each individual component before trying the big deal.
And this is where I need your help in 3 ways:
As Uno does not have multithread, I can't wait for a key to be pressed and hang the entire thing. So, I need to have a way of handling things kinda "all at the same time". Could you please take a look to the pseudo-sketch below and let me know if this is the way to implement things or if I'm far way from reality?
If I can know the way I will work in the complete project, I can have my code adapted for that situation and save time. By replying to 1. you will give me the chance to perform on 2.
Multitasking/Multithreading is making me confused... How can I have my Uno to play a song (void playSong() { ... }) and keep interacting with keypad and LCD?
void loop()
{
getKeyPressed; // read the key from the matrix keypad
processKey; // process the key action, if any
updateDisplay; // update the LCD display
systemArming: // when system is arming
wakeUpSensors; // wake up remote sensors
armSensors; // set sensors to armed status
confirmSensorState; // wait for confirmation on new status
systemArmed: // when system is armed
getAlarmFromSensors; // read sensors info
statusNone: // when no alarm is set
doNothing; // good. do nothing
statusAlarm: // when an alarm is set
processAlarm; // process the alarm
systemDisarming: // when system is disarming
disarmSensors; // inform remote sensors to disarm
putSensorsToSleep; // instruct remote sensors to sleep
confirmSensorState; // wait for confirmation on new status
systemDisarmed: // when system is disarmed
doNothing; // do nothing
systemPeriodics: // tasks to perform on time intervals
every120minutes: // every 2 hours
checkBatteryLevel; // check battery level
every1Day: // every day
checkSensorsState; // check if all sensors are reporting ok
every1week: // every week
testSensors; // perform a complete test on sensors
testGSMshield // test the GSM shield and send sms report
checkTimeOut: // if system is not armed and user is away
sleep; // enters sleep mode for until a key is pressed
}
There was another thread on alarms in the last few weeks.
In my opinion a box on the outside of your house with a flashing led driven by a 555 timer is likely to give you every bit as much protection as a sophisticated alarm.
It does sound like a lot of batteries to me.
An external flashing light, some taser landmines, and then inside a webcam that sends pictures on motion detect ?
As Uno does not have multithread, I can't wait for a key to be pressed and hang the entire thing. So, I need to have a way of handling things kinda "all at the same time". Could you please take a look to the pseudo-sketch below and let me know if this is the way to implement things or if I'm far way from reality?
Multitasking/Multithreading is making me confused... How can I have my Uno to play a song (void playSong() { ... }) and keep interacting with keypad and LCD?
You've got the right idea, yes. What you want to do is write non-blocking code -- that is, check for things, and do things, but don't use delay() and don't do large tasks all in one go. If something needs to happen in the future, schedule it, and then watch the "clock" (millis()) to see when you need to take the scheduled action. If you have a particularly large task, split it into sub-functions and do each sub-function at a time.
For example, to play a song and keep the keypad/LCD interactive: start playing a note, schedule a time to stop playing the note, then check the keypad -- if there's a keypress, update the LCD. Now check the clock and see if it's time to stop the note. If it's time, start the next note and schedule a new stop time for it. Then loop back to the check for keypress bit.
If I can know the way I will work in the complete project, I can have my code adapted for that situation and save time.
Your psueodo-code is actually quite good for a newbie -- it looks a lot like a Finite State Machine, and a FSM is an excellent framework to build your project on.
@radman
I know this comes with a lot of learning and that's why I'm interested. I have 1 goal that will have me learn so many things.
Just for an idea, remote sensors are running from my hand made PCB on ATTiny85 at 1MHz on internal clock with 2.5v constantly sleeping until the motion sensor triggers an interrupt, and central module has now 2 shift registers as I run out of IO pins. Half the words in my last sentence were unknown to me a couple of months ago. And battery won't be a problem I think as remote sensors are using 94uA 99.999% of the time and about 20mA to send the TrigerAlarm signal for 5 secconds.
@Robin2
I would agree with you in the past. But I'm now tired of blinking leds and pretending stuff even though you are right in terms of protection it would make not much of a difference. I've been there in the past and I'm now moving on. I need to spend time somehow now that I've stopped smoking.
As for a more productive project, in the end this alarm main console will be a central point for an automation system for home. I'm feeling ashamed on having an old phone and an broken apart bluetooth headset actuating a relay to open and close my sun-blinds during holidays...
It seems that timing and millis() have a lot to learn from as I can see on google and I'm sure this can solve the multi-tasking problem I was facing.
tylernt:
Your psueodo-code is actually quite good for a newbie -- it looks a lot like a Finite State Machine, and a FSM is an excellent framework to build your project on.
I honestly don't know what FSM is but I'll be checking on it. And even I'm a newbie on Arduino and electronics I've been a software programmer for 20 years in my free time and maybe that helps.
dreasi0n:
I honestly don't know what FSM is but I'll be checking on it.
There is a FSM library for Arduino, but I have not tried it so I don't know if I can recommend it. Personally, I like just using a currentState variable and a switch/case construct to hold my code for each state.
An FSM isn't the only way to do the job, of course. It's a matter of personal preference. But, I think it makes it easier to simulate code in your head before running it in hardware. And easier to debug. You might think of each state as kind of like a thread -- IF you make sure all of your code is non-blocking. This tends to lead to a lot of global variables, but that's the price you pay with a microcontroller.
And even I'm a newbie on Arduino and electronics I've been a software programmer for 20 years in my free time and maybe that helps.
If you are intent on developing an alarm system what about using a PIR to detect if there is a person in a room? One detector should cover a whole room no matter how many windows or doors it has and it should be impossible to reach the detector to disable it before it triggers the alarm. And you could probably site the detector in a convenient location for wiring.
PIR is great for an unoccupied house, but tends to false-alarm on residents getting up to go to the bathroom or getting a drink etc. Whereas the window and door sensors can be armed at bedtime and residents can still move around.
I'm considering using both PIR sensors and hall/magnetic sensors to trigger the alarm.
The alarm is on the way to be possible to arm completely or to arm just a "partition" that user can define with just a few sensors. This will make it possible to arm just the doors/windows and still be inside the house.
In the future I'm also planning to have non arming sensors that will always be working like smoke detectors, gas detectors, water leakage detectors, and so on...
Regarding the wires, I can't/won't use them. I'll have everything wireless with RF-Links. I know this will use some battery power but I'm running the sensor modules on ATtiny85 @ 1MHz under 100uA in sleep mode and 20mA on alarm transmissions (only when the alarm is triggered). For the central module I can hold 16xAA batteries inside if needed.
I also have an hidden GSM shield (I don't have this yet but it's planned and will be running from AC power if needed) that will pick up the signal and inform via SMS even if the sensor module is jammed.
Right now I'm waiting for some more shift registers and port multipliers as I keep running out of IO pins and will change a few things over I2C.
I'm also planning to standby this project for a couple of weeks to build a "devboard". I need some base/structure to hold my project breadboards, power supply, batteries, arduino, sensors (still on mini breadboards) as moving things around is getting more and more complicated.
tylernt:
make sure all of your code is non-blocking. This tends to lead to a lot of global variables, but that's the price you pay with a microcontroller.
