Hi Guys,

In a typical alarm system scenario there are numerous alarm panels spread in a different armed premises.
Those premises  are often spread in a very different geographical locations within a town or even country.
The best practice is to collect all the 'alarm events' from all alarm panels in a single central station.
So the question is what is the best communication media and protocol used for this.
Thanking into account the old infrastructure heritage it is not a surprise that the POTS analog telephone lines
have been widely used in the past and even now. And the protocol is Contact ID invented by a company called
Ademco which become de-facto a standard for this kind of alarm panel <-> central station communication.
It uses based on a sequence of DTMF tones with handshake and a control sum incorporated.
Here we go we have AlarmSender() Asterisk application implemented in Switchfin. (Note that AlarmReceiver()
supporting Contact ID protocol is available in Asterisk mainstream since Asterisk 1.2)

To test please build Switchfin with AlarmSender enabled in the Switchfin menuconfig.
Then in Asterisk CLI you can do

switchfini1*CLI> originate DAHDI/g1/phone_number application AlarmSender 111118162601000

-- Executing AlarmSender("DAHDI/phone_number", "111118162601000") in new stack
> AlarmSender: Setting read and write formats to u-law
> AlarmSender: Sending ademco contact ID
> AlarmSender: Determining protocol ademco contact ID...
> AlarmSender: Protocol ademco contact ID determined !
> AlarmSender: Trying to send for 1 time (max 4)
> AlarmSender : digits_to_send : 1111181626010006 with checksum : 6
> AlarmSender: Verifying 1400Hz 100ms burst (ACK)
> AlarmSender : Launching receving loop
> AlarmSender: Verifying 2300Hz 100ms burst (ACK)
> AlarmSender : Launching receving loop
AlarmSender: Sending DTMF digits successful !!
> AlarmSender : Launching receving loop
> AlarmSender : Not a Voice frame, trying with next frame
> AlarmSender: Ademco Contact ID sent successfully !
-- Executing [DAHDI@alarm:3] Hangup("DAHDI/phone_number", "") in new stack

You should have AlarmReceiver (either commercial alarm central station or Asterisk box with AlarmReceiver application)
listening on the phone_number side. The message is actually the last 15 digits. 
For more information about the protocol itself please check Contact ID recommendation

The Asterisk AlarmReceiver application from the remote side responds:

switchfini2*CLI>
-- Executing [6000@alarm:4] AlarmReceiver("DAHDI/Channel 1", "") in new stack
> AlarmReceiver: Answering channel
> AlarmReceiver: Waiting for connection to stabilize
> AlarmReceiver: Waiting for first event from panel...
> AlarmReceiver: Sending 1400Hz 100ms burst (ACK)
> AlarmReceiver: Waiting for first event from panel...
> AlarmReceiver: Sending 1400Hz 100ms burst (ACK)
> AlarmReceiver: Sending 2300Hz 100ms burst (ACK)
> AlarmMonitoring: Detected format ADEMCO_CONTACT_ID.
== AlarmReceiver: Received Event 1111181626010006

This open the door for a few interesting applications based on IP0x as a component in the smart alarm systems.

PPP over serial link

PPP is a data link layer protocol mainly intended to establish point to point connection over the serial link like the console port we have on our Switchfin targets.
Let's see how we can demonstrate this.

In the latest Switchfin we have PPP option in the menuconfig. Please enable it and build the image.

Connect the serial port of a PC with PPP support with the PR1 Appliance console port.
Establish the ssh sessian with the PR1 Appliance.

On the PR1 Appliance set the PPP configuration file
#/etc/ppp/options
lock
nocrtscts
10.0.0.209:10.0.0.2
linkname ppp0
local
nodefaultroute
/dev/ttyBF0
115200
-detach

Those lines say:

• PR1 Appliance will use /dev/ttyBF0 device for the PPP
• PR1 Appliance will get address 10.0.0.209 and the other end will be 10.0.0.2
• The PR1 Appliance console has no flow control signals wired (RTS,CTS, DTR, DSR, etc.) so we say nocrtscts
• we will give name ppp0 to the link
  

On the host we may have configuration like this:
#/etc/ppp/options
lock
nocrtscts
10.0.0.2:10.0.0.209
linkname ppp0
local
nodefaultroute
/dev/ttyS0
115200
-detach

Finally let's load the ppp over serial link module
root@pr1:~> modprobe ppp_async

and we will get the link up

root@pr1:~> ifconfig
.....
ppp0      Link encap:Point-to-Point Protocol 
inet addr:10.0.0.2  P-t-P:10.0.0.209  Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
RX packets:6 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3

and we may ping PR1 Appliance from the PC (or vice versa) like this:

[root@Switchfin ~]# ping 10.0.0.209
PING 10.0.0.209 (10.0.0.209) 56(84) bytes of data.
64 bytes from 10.0.0.209: icmp_seq=1 ttl=64 time=26.7 ms
64 bytes from 10.0.0.209: icmp_seq=2 ttl=64 time=25.9 ms
64 bytes from 10.0.0.209: icmp_seq=3 ttl=64 time=25.9 ms

Similarly you may ssh the PR1 Appliance thru the new ppp0 interface.

Point-to-Point Tunneling Protocol and VPN

PPP can work not only over serial link. Let's see how it can be used to create VPN over the Ethernet.
In addition we will test the MPPE (Microsoft Point-to-Point Encryption/Compression) support built in as kernel module.

Let's use one of the Linux PC in the network as PPPoE server.
PPPoE is a simple protocol and basically it is pretty much like the DHCP negotiation.
Description how to do PPPoE server can be found at PPPoE Server Under Ubuntu/Debian
The necessary configuration at the PC are

#/etc/ppp/pppoe-server-options
# PPP options for the PPPoE server
# LIC: GPL
lcp-echo-interval 10
lcp-echo-failure 2
debug
auth
# MPPE requires mschap-v2
require-mschap-v2
require-mppe
refuse-pap
refuse-chap
refuse-mschap



#/etc/ppp/chap-secrets
# Secrets for authentication using CHAP
# client        server  secret                  IP addresses
# allow any client, any server, any IP addr
* * "" *

CHAP is an authentication schema.
To prevent exchanging the username/password (as it is in the other popular authentication PAP) this method sends random number (challenge) which is processed by both PPP ends using hash function.
The results of the hash is compared.

Let's load the MPPE module and start the server

root@switchfin:~# modprobe ppp-mppe
root@switchfin:~#/usr/sbin/pppoe-server -T 60 -I eth0 -N 250 -R 192.168.0.1

Now let's go to the PR1 Appliance side. We use the same image with the built PPP option.

The required configuration files are:
# /etc/ppp/peers/mylink
plugin rp-pppoe.so eth0
mtu 1492
mru 1492
require-mppe
debug

PPPoE we will start using pppd plugin rp-pppoe.so.
We will use eth0 as carrier interface.
We will use Microsoft Point-to-Point Encryption MPPE

# /etc/ppp/chap-secret
# Secrets for authentication using CHAP
# client server secret IP addresses
# allow any client, any server, any IP addr
* * "" *

Some of the PPP stuff is compiled as modules. We don't need ppp_async now but we need few others:

root@pr1:~>modprobe sha1_generic
root@pr1:~>modprobe ppp_mppe
root@pr1:~>modprobe pppoe

Now we have the following modules loaded in PR1 Appliance:

root@pr1:~> lsmod
pppoe 6973 2 - Live 0x043e4000
pppox 1123 1 pppoe, Live 0x04607800
ecb 1141 2 - Live 0x04606000
ppp_mppe 4733 2 - Live 0x043e2000
ppp_generic 13111 7 pppoe,pppox,ppp_mppe, Live 0x05b9c000
slhc 3685 1 ppp_generic, Live 0x04411000
sha1_generic 1309 4 - Live 0x0460c000
wpr1 16852 62 - Live 0x04730000
dahdi 165436 65 wpr1, Live 0x04780000
crc_ccitt 953 1 dahdi, Live 0x042f8000
mmc_block 6180 2 - Live 0x0408e000
mmc_spi 6493 0 - Live 0x0408c000
crc7 711 1 mmc_spi, Live 0x042f5000
crc_itu_t 980 1 mmc_spi, Live 0x042f4c00
mmc_core 36905 2 mmc_block,mmc_spi, Live 0x043f0000

and we can start the PPP link

root@pr1:~> pppd call mylink &
[1] 478 pppd call mylink
root@pr1:~> Plugin rp-pppoe.so loaded.
RP-PPPoE plugin version 3.3 compiled against pppd 2.4.4

On the PR1 Appliance we see that the ppp is established

root@pr1:~> ifconfig
...
ppp0      Link encap:Point-to-Point Protocol 
inet addr:192.168.0.14  P-t-P:10.0.0.1  Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1488  Metric:1
RX packets:10 errors:0 dropped:0 overruns:0 frame:0
TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3

on the host we have

root@switchfin:~# ifconfig
...
ppp0      Link encap:Point-to-Point Protocol 
inet addr:10.0.0.1  P-t-P:192.168.0.14  Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1488  Metric:1
RX packets:10 errors:0 dropped:0 overruns:0 frame:0
TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:322 (322.0 B)  TX bytes:322 (322.0 B)

and we can ssh the PR1 Appliance over ppp

root@yni:~# ssh 192.168.0.14

A new hardware target has been added in Switchfin. It is four ports  BRI Appliance. It goes in an aluminum enclosure more stable hardware and software design bigger memory capacity and supports TE/NT software selection out of the box.

BR4 Appliance+

Quad ISDN BRI port PBX. The specification of the PBX are shown below:

Application:

• Cost-effective ISDN BRI solution for SOHO & SMB market.

Hardware:

• ADSP-BF537 600MHz CPU
• 128MB SDRAM
• 1 Ethernet port with high performance PHY
• Quad BRI based on Cologne silicon
• SD card interface with a dedicated bus
• 1GB flash for voicemail and prompts.
• Optional, hardware based echo cancellation (LEC-64-BRI).
• Software selectable NT/TE mode (NEW)
• Switchfin with Asterisk 1.4.x, mISDN

Features

• Interfaces & protocols: IAX, SIP, ISDN-2, H323
• Codecs: a-law, u-law, Speex, GSM.
• Monitor active channels & calls
• Voicemail, Voicemail to e-mail
• IVR menu's
• Conference bridges
• Follow-me
• Music on Hold
• Timebased rules
• Call parking and transfer
• Backup options
• Firmware update thru the webGUI
  
  The hardware can be purchased from Switchvoice Ltd.

Hi Guys,

Command line

• In case you have WLTC module plugged in your IP02/IP08 PBX and if you use Switchfin image with home automation support included you should see something like
  wltc_init: WLTC module found at port 1
  in your system log

• To get the list of the all available MAC addresses of the remote devices one can do

root@ip0x:~> home-auto /dev/wltc get_address_list
55:44:33:fe:ff:22:00:02
55:44:33:fe:ff:22:00:03
55:44:33:fe:ff:22:00:07
55:44:33:fe:ff:22:00:01

• To switch on the relay of one of the remote unit (WLRR) please enter

root@ip0x:~> home-auto /dev/wltc set_device 55:44:33:fe:ff:22:00:02 1
OK

• To check the state of given WLRR unit please enter the following command. Note that WLRR has local button for toggling of the relay state.
  The command below is retrieving the correct current state.

root@ip0x:~> home-auto /dev/wltc get_device 55:44:33:fe:ff:22:00:03
1

• To switch off the relay of one of the remote unit please enther

root@ip0x:~> home-auto /dev/wltc set_device 55:44:33:fe:ff:22:00:02 0
OK

Graphical User Interface (GUI)

Thanks to Jason we got home automation integrated in the GUI.
Let's describe how one can setup a simple IVR (DTMF control) using the two WLRR to control the Air Conditioner and the Cooker.

If you have WLTC inserted in your IP02/IP08 and two WLRR end devices plugged in the mains socket you will get them automatically recognized by the GUI.
The first step is to prepare an SIP extension so you can record some voice prompts (Extensions)

Hi Guys,

WLTC support was added in Switchfin trunk.
WireLess Tele Controller (WLTC) manufactured by Switchvoice Ltd. is a ZigBee module for IP0x
intended to be used as home automation controller.
Currently WLTC supports WireLess remote Relay (WLRR) end device (shown on the picture above),
capable to control 220V/16A Appliance.
Very soon we will see released family of other end devices like temperature sensors,
current senses, light switches etc.

For more information about the hardware please read the link

The technology is 6LowPAN enabled.

Let's make a dedicated sub forum for Home Automation.

Hi Guys,

Switchfin was updated to uClinux 2010R1-RC5 (based on Linux kernel 2.6.34.7) for all supported hardware targets.
All the targets have passed our main test suite.

For the known issues please check the forum topics IP0x, BR4 Appliance, PR1 Appliance

Volunteers to do further testing of the update are very very welcome.

Cheers

Hi Guys,

Due to the hard work of our main WEB developer Jason Kenah we have fully working multilingual support in the Switchfin GUI now.
Apart of the default English language now we can select also French. The selection is done in the System Setup -> Options -> Language Settings.
In the same menu you can also download the corresponding sounds prompts if you would like to.
Adding new languages now means just translation of the string array in a single place and should be pretty easy job.
If there is a volunteer to do this please don't hesitate to contact us ;-)

All comments/suggestions/remarks are invited!
Cheers

Hi Guys,

Asterisk has been updated to version 1.4.40

Comments invited!
Cheers

Hi Guys,

Now Switchfin uses the latest Asterisk  1.4.39.1
Feedback is welcome.

Cheers!

Hi Guys,

In case your IP02 or IP08 is equipped with GSM1 module you can send and receive SMS.
Now you can do it directly from the GUI. Our WEB developer Jason has implemented an intuitive SMS Manager.

To test it you will have to put the latest Switchfin software from SVN

Comments invited
Cheers