Web interface - groups

Few post ago I have touched the zone setting in web interface. Now this lead to groups. This setting combines multiple sources into one object. Such object consists of zones, authentication units and sensors and represent them to outside world. This allow you to set different alarm settings for your house and for your garage. For example you can have your garage armed and monitored while you are sleeping in your house, just by setting corresponding zones in garage into separate group. On this page you can also see what authentication units are allowed to arm and disarm particular zones, and also you can see sensors that are attached.

The group itself does not have too much settings. You can set the group name, set it On or Off and assign a output trigger for PIR and tamper event. All other parameter are taken form their respective sources like zones, sensors and such. But group setting offers great overview of what is going on in your system. You can see the group status, if it is armed or alarm is tripped and how long we are waiting for the authentication.

There are 16 groups not only to differentiate zones, but also to distinguish location of sensors and to allow proper MQTT propagation. More on this topics soon.

Short wires II / New PCB arrived

After taking some time to figure out what components died after the bead burned, I found the only one is the Ethernet module. One of the most expensive. This led me to adding extra protection to 3V3 power rail, a Zener diode which limit the voltage to 3.9V, I hope :)

But luckily all other components can be taken to new board that I have just received from factory. Next week I will get busy :)

How to wire up PIR

Bellow is only valid for gateway versions bellow 1.6.

Main board is equipped with 7 analogue inputs that are able to measure different states on the sensors by using just one wire. Well actually you need three together with power and ground. On the right you can see the wiring schema.  It is a simple voltage divider with 22k and 10k resistor that take the input voltage and create different voltage levels based on state of PIR outputs. In this way we can use any commercially available PIR sensor module that is able to operate with 12V power supply.

There can be more sensors on one input, but that would require more than just three wires as you need to daisy chain the signal and signal inputs from PIR and TMP. Not problem for someone who is using CAT5e cable to wire the sensors, it is actually cheaper than original 4-wire cable.

To sum up possibilities with such setting.  We are able to see these states:

• normal operation
• trip
• tamper
• unknown state / damaged

In software we measure the voltage level in zone thread every 250 millisecond. 4 times a second is safe way as the PIR modules usually keep the outputs on or off for one whole second. Also the thread has highest priority. In order to compensate for different wire lengths, there are voltage  rages feedback specified for each state, rather than a single value. And because input voltage can change when switching to battery and back, the whole measurement is compensated to the input voltage as well.

New PCB for main board

After not very successful testing of main board in real life, I have put some effort and created a new version of it.

It I hope solves the problem of over current on power lines. I have put five 1206 polymer fuses on it as well as input one and over voltage protection. Also I have re-mapped the digital input pins so now it should be faster to read them in software. I have added one extra digital input and corrected the tamper. Now we have 7 analog input pins and 6 digital input pins. Another fix is reset watchdog circuit that was needed to properly start Wiz820io Ethernet module after power up. Others changes are minor, rearranged the connectors and battery. And I have deleted the 5V rail needed for the old GSM module, because now I use 12V one.

I've send the board for fabrication, fingers crossed :). New schematics are available in download area.
 

Power supply

In last post I have mention the power supply is too strong. By checking the documentation again I can say it way to strong, 60W. Originally I have designed my own power supply with transformer, rectifier and some switchers to deliver 13,8V for battery and 5V for GSM. Together with some led signalizing the status of mains and battery. But later I have considered it rather inefficient for 24/7 running.

Developing a true switching power unit is rather expensive, beside I have no previous experience, and I'm just a hobbyist. And my favourite producer of power supplies had a nice choice of 13,8V units. I have chose PSC-60-C, the one with enclosure. It has two outputs, one for battery charging and one to power for main board. It has also open collector outputs for signals when the AC is off, or the battery is reaching low level(11V). Then it also cuts of the battery when it reaches 10,5V. Just everything I wanted and it has 84% efficiency. Also it looks nice and shiny in the box :)

Short wires

Here is what happens when you try to connect PIR sensors to powered up main board :(. Well not really what should normally happen.

I was about to test everything in real life as the software and hardware worked fine together, but didn’t think about short wires on the other ends. I have connected 2 PIR sensors and left the board powered on. All the leds on GSM modem a Ethernet card lit up and I started to connect wires on first PIR that is just around corner. When I went back to main board there was strange light coming out of place where is no led. It was bead!  But before I was able to unplug it it died and took some other components with it. The second PIR had shorted power wires, upps.

I must say the power supply is too strong, with battery connected it can easily put few amps into any 12V rail. As you can see on the picture the power went to second PIR sensor there was shorted and came back to analogue ground that is connected to digital ground by bead. And it didn’t withstand the power that was flowing through it. As is burned it probably touched the 12V rail that is near and killed the rest of the board. So, yes I have designed the board as well as I could to handle over voltage and or short on signal wires, but I failed on power lines.

Damn, I have the input over current, over voltage on the remote board but not on the main board. A simple polymer fuse would save the board as it was able to operate like this for at least 3-4 minutes. Now I have to think if I will make new revision of the main board or just solder another one and put a fuse on the 12V input.

Wiz820io power on problem.

Some months ago I have found that the wiz820io is not recovering correctly on power failure. There is needed to reset it after power on. Sadly I have connected the reset of atmega to wiz820io. There was two possible solutions I had on mind, first to use the Ethernet INT signal that is not used as separate reset, and second to add a watchdog chip to the board.

I went first with with the watchdog variant. I have found, and bought MCP130 which is a voltage supervisory device. It is designed to keep a micro controller in reset state until the system voltage has reached the proper level and it is stabilized. By looking at the schematic I have found that the R22 resistor, 10k reset pull-up, can be replaced by MPC130. The MPC130 is available in SOT-23 package and pins matches the footprint of R22 resistor except GND signal. I have replaced it and soldered extra wire form nearest ground to watchdog.

I happy to say that the watchdog keeps the reset long enough to satisfy the wiz820io and the main board is now recovering from complete power loss without any issue. Just for completeness the wiz820io has its own 10k pull-up.

If there will be some new revision of the main board, I will replace the R22 with  MCP130 and free the INT line to wiz820io for digital input. The price of MCP130 is 0.25 EUR for 1 piece in our local shop and it is well worth it :).

Web interface - zones

Zones  are the basic monitoring elements. Currently the only zones present are the ones that are hardwired on the main board. There are physically present 7 analog zones and 4 digital ones. As you can see on the picture there is table that represents the overview of all the zones and their statuses.

The future is open for at least three possibilities that I have prepared already. One is to use shield that communicate over TWI interface. This can be either analog multi channel ADC for analog inputs or TWI port expander for digital inputs. Other would be remote zones tied to remote boards. These board are equipped with extension header to easily break out the SPI, TWI, analog or digital pins. This would also simplify wiring of the distant zones. For now I'm planning to make the second option available. Third would be radio controlled zone, or radio controlled remote board.

But current stage is just the hardwired zones. And the configuration in web interface is as follows. There is zone number witch represent the port on the board and also type of zone. Then there is a zone name which a user can modify and can span over 15 characters. This name is than used when sending SMS messages or is used when reading log over web interface to better represent it then just the zone number. Next is the switch that is turning the zone "On" or "Off" and it does exactly this.

Auto arm is telling the system to set the zone to arm status when there is no movement in the zone for specified amount of time. I will use this for garage that is attached next to our house. Next switch is open alarm, that does the opposite. It monitors the zone and when it is open for longer then specified time, it issues a message in log and sends out a SMS. It is intended more for digital zones, such as door switch, and allows the system to let you know that you forgot to close them. Again a garage door is a good example, if you forget to close it and you are already in house, system will notify you.

Authentication delay switch is telling the system, how long it should wait for the authentication if the zone is tripped. This let you easily adjust the timing mechanism of alarm. For example if some one triggers the zone in you front door, you can set the authentication time high. Because you can assume that it is normal pathway. On the other hand if someone trips the zone in your bedroom that has only window, you can set the authentication time to zero. Because you would normally not enter your house through bedroom window(too much beer probably, when yours wife is in her sister). The switch multiply the time set in authentication delay parameter present in global setting.

The last option for a group is to select its superior group. This option telling the system what zones are treated as one area. And when one zone is armed it arms all zones in group.

NTP synchronization

There is RTC circuit on the main board which is battery backed up. But it lacked the feature to set the correct time other then the compilation. As it has drifted a minute a month, or so, I guessed it is right time to make it synchronized with some NTP server.

I have put a button on the home page of the interface to get the correct time, as well as letting the service thread synchronize time when it starts.

It took me some hours to combine some examples on the net into working code, that I think is a bit optimized, and also working with the rest of threads and web-service. The changes are pushed to Git Hub.

On the Arduino forum is a good post about choosing the right NTP server, which is a valuable resource to read. Especially the attached link to Flawed Routers Flood University of Wisconsin Internet Time Server.

Software

I have created a git for the main board source code, and I will be pushing all the libraries needed for compile there as well. Link to GitHub will be always located on the right panel for fast access.
This is my first git, so be nice on me :).

RFM12B Radio

The radio part was left out a bit since beginning of the project. I believe in wires in such way that they are more reliable, and also can carry the power for the remote nodes. But the radio is important for future expansions as well. It can be used for remote self-powered PIR sensors, authorization nodes or for data gathering.
Yesterday I have decided to give them a try, because I had two RFM12B at home along with one bought antenna for the main station. Main station is build in metal enclosure and connected to earth that would block the radio waves. I put together one node with ATMega168 and soldered a radio on it. Then the 1/4 wave length antenna made out of single wire:

Wire lengths:

433 1/4 wave = 164.7mm
433 1/2 wave = 329.4mm
433 full wave = 692.7mm

868 1/4 wave = 82.2mm
868 1/2 wave = 164.3mm
868 full wave = 345.5mm

915 1/4 wave = 77.9mm
915 1/2 wave = 155.9mm
915 full wave = 327.8mm

And went for a search for library. I have found this library from LowPowerLab that looked good and suitable to my needs. Radios didn't work out of the box, but I had suspected it because my wiring are not using the ports the library expect. Main Board uses different pin for radio interrupt.

#elif defined(__AVR_ATmega644P__) || defined(__AVR_ATmega1284P__)
  #define RFM_IRQ     10    // PCINT 10 / INT2

Allowing the PINCHG_IRQ instead of attachInterrupt did not work as well. But luckily changing the attachInterrupt form 0 to 2:

#else
  if (nodeID != 0)
    #if defined(__AVR_ATmega644P__) || defined(__AVR_ATmega1284P__)
      attachInterrupt(2, RFM12B::InterruptHandler, LOW);
    #else
      attachInterrupt(0, RFM12B::InterruptHandler, LOW);
    #endif 
  else
    #if defined(__AVR_ATmega644P__) || defined(__AVR_ATmega1284P__)
      detachInterrupt(2);
    #else
      detachInterrupt(0);
    #endif 
#endif

And packets started for flow through. For a short while, or they would go on on the main board, but the Ethernet stopped working. They both work on the SPI and the RTOS has no direct driver for it. A solution  worked fine:

#elif defined(__AVR_ATmega1284P__)
  #warning W5200 for AlarmBoard only!
  inline static void initSS()    { DDRB  |=  _BV(1); };
  inline static void setSS()     { cli(); PORTB &= ~_BV(1); };  // no interrupt while the SPI bus is busy
  inline static void resetSS()   { PORTB |=  _BV(1); sei();};   // no interrupt while the SPI bus is busy

Edit the Arduino Ethernet library file W5100.h so that it doesn’t allow RFM12b to interrupt while the SPI bus is busy handling Wiznet5100. Just add a cli(); and sei();. I will publish the modified libraies to GitHub.

The project.

Why I have started the project? Simply because I wanted protect my house from burglars.

Some years ago we've started build a house and the idea sparked in me that I can actually create a security and monitoring system my-self. I've been playing with Arduino and Atmega uCPUs and I wanted to use it for some real project. In the house I have put all the wires for PIR sensors, smoke alarms and entry panels. And along with it I've started researching wire and wireless protocols and possibilities. Step by step I've become more and more interested in the idea and the project started.

What it should do? It should replace standard home security alarms, and in future gather statistics from various sensors and do some home automation.

Some of the functions are already there. I have RS485 nodes connected to main board and talking with it over one twisted pair. I have library created that works with the half duplex receiver/transmitter, handles the communication, packets, and is able to detect contention and errors during transmission. Then I have the hardware ready for widely used and reliable RFM12B radio which will be used for cases where wires are not possible or more preferred. There is also Ethernet module working that can serve web pages for communication and configuration.

What is the mission? I must say I'm happy with this project. It is working well and brings me a lot of joy. I went through several version of software, hardware and design and still I'm not discouraged by all the little pitfalls it has brought along. And because I'm reader of hackaday I've decided to enter the TheHackadayPrize and started to post some project news. This just led me into idea that someone else can benefit from my project or better someone can join and add new features or hardware. In the future I will be posting here the project logs, schematic, source code and documentation.