Saturday 30 May 2015

Marmitek/Haibrain SC9000 X10 alarm system

* Updated 02/06/2015 (See end of post)

When we moved into our new house a year ago, I decided to go for an alarm system that I'd be able to integrate with, and use with my home automation that I keep trying to build upon and improve. I already had various X10 home modules (lights and appliances) and whilst some of these modules are poor quality and fail quickly, it is a good system that has worked for me. I have the CM11a conneted via serial to my server in the house so it can monitor all X10 codes and also send them for turning outside lights on, living room lights, etc.

So I looked into it and went with the SC9000 home alarm system from Marmitek (Who are now called Haibrain) as it was a fully integrated X10 alarm system, it could send and receive X10 signals over the home powerline and also used wireless door and motion sensors in the house for triggers.
The above is a stock image, but it's similar to what I got, I added more sensors and an external bell box. I fitted the unit into the hallway in the house, cut a hole in the wall and fed it to be supplied by a mains socket. This was the first challenge. The PSU looks like this:
Which is kinda tricky to install for an alarm system! You want things like that hidden (So burglar doesn't unplug the alarm!) and that huge power brick and hard-wired plug was a pain. I also did a bit more reading and found that power brick isn't just a step-down transformer. Since it has to send and receive X10 signals it actually has a lot of the X10 circuitry built into it.
So my plan was, install the front facing alarm unit somewhere public, then run cables away somewhere hidden. The house lent itself to this so I got it fitted and sorted. The alarm had backup batteries internally, so it was protected even if the power was cut.
Registering the wireless motion sensors and door sensors was easy and the remotes to arm and disarm the unit, etc.
The unit wasn't as flexible as I'd hoped, you couldn't specify which zones you wanted for "home set" and "away set". I.e. when "home set" it will only activate the door sensors, no motion sensors. And "away set" activates all sensors, no option to exclude. This was a bit annoying, but the unit didn't have much flexibility in it's programming.

Anyway, I lived with all of that, and now almost a year later the unit has stopped working in quite a critical way. It won't alarm! It sets, it will do the exit timer chimes, and notify when people open doors, but critically if it's triggered it would sound the main alarm sounder. It is also not sending or receiving the X10 signals.

Again, reading up, it appears the PSU on these units is particularly sensitive and will 'blow' in a partial way quite easily. My PSU has always run pretty hot, this seems common with X10 stuff, and it looks like after around a year it's given up. It still supplies the correct voltage, etc, so the alarm is on but critically it won't send or receive the X10 commands (So can't send the 'ALARM ARMED', 'disarmed', etc) and it also won't trigger it's main alarm siren.

I've contacted Marmitek in the hope of finding a solution, as I am also not 100% sure this is a faulty PSU, or some other fault that has been developed. Either way I want an answer as surely it has a longer life than a year on it. If it does indeed turn out to be the problem, I think an alternative is needed as I'm not going to keep replacing these every year for an alarm system, seems excessive that, as electronics should be more capable than that.

* Update 02/06/2015

I've had a reply back from a UK reseller of the Marmitek equipment regarding this issue, and they do indeed state that it was likely a brownout or power spike caused the PSU X10 electronics to fail causing the situation I've got. They've recommended their replacement power supply at £13. I've contacted them back asking if anything can be done to protect the supply, as my understanding is I could buy a new one, plug it in and if I get another surge next week that one will blow. And putting it behind a surge protection multiway I suspect would stop the X10 signals. I'll post back if/when I get a reply, but in the meantime it doesn't look a very good solution to me.


Friday 29 May 2015

w1-gpio w1-therm In openelec

Well, I'm really pleased to announce, something I wanted has been implemented into the Openelec build tree and will be in future releases.
A while ago I wanted to do 1-wire temperature sensing using my raspberry pi's around the house running openelec. Seemed a good use of hardware that was low power, small and generally always on.
In my quest for this I found what was needed (addition of modules to the kernel build) and set about testing and using it myself. And it works great, for a while now I've been logging temperature around my house and slowly building my own thermostatic control system for the house heating. Truly intelligent heating control!
And now the kind developers at Openelec have seen my feature request :
https://github.com/OpenELEC/OpenELEC.tv/issues/3975
And given it the green light, it's now implemented in change:
https://github.com/OpenELEC/OpenELEC.tv/commit/413817a9d765c49014baed1d9224c86022ce7b12
Sad as it is, this gives me a huge self confidence boost and a big pride boost! (told you it was sad!) I love open source, and dedicate a lot of my spare time to developing projects using open source, and returning things to the community (breakinguard, kodi scripts and plugins, and my contributions in the past to Tvheadend) and when something I wanted implemented has been done and will be available to all future users gives me something to smile about!
To all those that contacted me via my blog about using this, compiling themselves, etc, here you go, problem solved!

-- Update 10/08/2015

Thanks to Jo (https://www.blogger.com/profile/09579014828121678108) he confirms the action to get the module loaded on the PI as follows:

mount -o remount,rw /flash (To get the flash filesystem into rw mode)
echo "dtoverlay=w1-gpio" >> /flash/config.txt

Then reboot and you should be good to go!

Thursday 21 May 2015

asterisk and the RTP timeout

This was an interesting one after a new install of Asterisk (using freepbx) and one I wanted to document and log for future.
We had users on a new phonesystem (Part of an existing one, but using a new call server, running latest Freepbx 6.12.65-26 and asterisk 11.16.0) and finding that putting people on hold, the calls would get cutoff at times.

Doing some investigations, I could see:
[2015-05-21 10:18:44] NOTICE[3336] chan_sip.c: Disconnecting call 'SIP/5011-00000e0e' for lack of RTP activity in 301 seconds
[2015-05-21 10:57:34] NOTICE[3336] chan_sip.c: Disconnecting call 'SIP/5049-00000e33' for lack of RTP activity in 301 seconds
Appearing in the logs. Doing some reading, what was happening was the user placed a call on hold and dealt with the issue, during this time no rtp data passed to the handset (the onhold was passed back to the voip server to play nice music to caller), and after a while asterisk thought the phone handset had given up (i.e. rtp stream timeout) and so disconnected the call.

The apparent fix here is to  add in an RTP keep alive, which is in "Settings > Asterisk SIP settings > Chan SIP" and in the "rtpkeepalive" value I've added in 10 initially to test.
This bit of gui-ification adds in:
rtptimeout=190
rtpholdtimeout=600
rtpkeepalive=10
To the sip_general_additional.conf file (and so forms part of the global [sip] configuration for asterisk)

Will keep monitoring this, but suspect this was the issue.

Monday 18 May 2015

UPSs tinkering

Doing a bit of tinkering with UPSs (Uninterruptible Power Supplies) for the FM station I help out at, and been discovering some interesting fact and details that I'm making note of, again more for my benefit that others probably!

Firstly, the problem. Several old UPS units well past their prime have been in use to smooth the power out and keep the equipment going for all those little blips in power, this is to provide power to an FM transmitter, audio processor and RDS encoder. All together they don't draw a huge amount of power (approx 130 watts), but I need them protected against surges and other nasties, also the power in our particular location isn't very good, drops out often and suffers from surges, brownouts and all sorts, so protecting this sensitive and expensive equipment is a must.

I've used a variety of APC, Belkin and no-name UPSs for this job, mainly ones I've salvaged and either got working enough by cycle charging them or pure luck, and they hold up for at least a few minutes in a power failure which smoothes out most of the dips we get. Now I had a chance to properly replace a couple, the first was my old ALC Smart-UPS sc420 which is a reasonably new model (4 years approx), and I didn't use as it was alarming about battery failure. So looking to purchase a new battery, hit the APC website and they wanted me to trade the whole UPS in for a replacement. This seems excessive, it only needs a new battery. So, all of these units are able to be replaced, taking the battery out, it's a regular sealed lead-acid (or gel, I'm not sure) battery. Looking it up, APC call it the RBC2 which is a single unit 12v battery. You can get replacements relatively cheap, in this case around the £25 mark including delivery, so that was a no-brainer, order that, swap the battery and off we go. Went well, and now using it's monitoring on my linux server (apcupsd) it's currently showing it's at 55% load capacity, battery at 100% and approx 16 minutes of run-time available. Excellent, so that solves the immediate problem.

I therefore now have a 'spare' UPS to tinker with, and this one has a bit more power behind it. This one is the APC smart-ups 1500, and after looking it up this can deal with 980 watts at max, so this is a pretty decent size unit (It's also quite heavy!), so again pulling it apart to see what batteries it has, and this one has two joined together. The pic below shows what configuration it has:

These are considerable larger batteries than the RBC2 units, and you can see there are two joined together. On the right terminals (the blue block) is a large fuse joining the terminals together, and on the left you see the cables that are connected into the UPS itself (the yellow marks are the adhesive that had covers over all the exciting bits). Taking it all apart, I'm expecting two 12v batteries again, so joining them in series like this would give a 24v pack. Each battery was registering around 2v on their own, and so seem pretty dead to me (This ups is probably more like 10 years old, and in my use it died probably 2yrs ago and has been left unplugged ever since, so I suspect sulphurisation has occurred and completely ruined them), so onto the next thing, identifying so I can replace. This isn't easy.
APC batteries are completely generic, no markings, or anything. I suspect they either burn, scrub or simply cover all markings showing voltage, current, etc, which makes it harder. Luckily most websites have direct lookups for these batteries, just put in the ups product and it'll tell you what size, etc. So that looks like the next plan, to order a couple, wire them up and get this UPS back on the road!


Friday 8 May 2015

Chrysler Grand Voyager - Sound System quandry

So, I'm back trying to add in my Parrot bluetooth phone kit into my Chrysler Grand Voyager (2004). This has hit upon several big obstacles, the first of which, nobody online (Manufacturers, suppliers, etc) can decide on what the correct kit is needed for this car, some say SOT-046 some say SOT-086 and others say SOT-948. So I checked, and in the past I'd bought the SOT-046 (For my last Chrysler Grand Voyager 2004) so bought another one the same.
However this time it didn't work out, connecting it in, all went well, however the unit when trying to play audio through the speakers simply slightly muted the audio and no phone/Parrot audio at all.

I did a lot of digging, checking wiring diagrams, cabling, etc, and came to the conclusion it must be the wrong cable, so went and tried others, but all gave the same problem, that it didn't fully mute the radio and no audio at all went through.

Next step, I cut the cables on one of the SOT-046 cables and started to do my own testing, firstly by trying a manual connection from the radio to the car audio harness. This is when I started to find something strange. Disconnecting all the audio output cables (Verifying the wiring diagram online and on the Parrot wiring diagrams, so at least these added up) from the radio, and trying by connecting just one (Driver side right) pair. This didn't result in any audio output at all. Strange! I then tried each of the other pairs, checking polarity (Front left, Rear left, Rear Right) and none of them worked. I was now really confused. So connected them all back up again and they all started working. So it wasn't a fault, but almost by design. This makes me think (I already suspected this) that there is an amplifier somewhere in the car to drive all the speakers (8 speakers in total!) which is sometimes referred to as the Infinity sound system. I then tried connecting all speaker pairs up again and then disconnected a single one whilst the system was still on, and strangely that speaker didn't totally go quiet, it lost a little volume but not totally. Swapping which wires were connected or not seemed to produce similar results, but again disconnecting a single pair didn't stop a speaker from working. This confirmed what I suspected, these aren't true line-level outputs to an amp, they are more a digital output per channel.
This is my assumption anyway, and if this is truly the case then I'm going to struggle to feed in the analogue audio from the Parrot phone system.

Therefore a bit more investigation is needed I suspect, but that's my findings so far!