Getting rid of some outstanding issues

I tend to lose interest in things by the time they’re almost finished – that may sound strange (I don’t ūüėČ ), but it’s the truth and it’s a habit that’s hard to beat. Knowing that I will get something working, doesn’t always mean I will make it that far and complete the whole job. The main reason is that there’s so much more to explore and learn, and that’s the most interesting part of it all; the thrill of learning more each time you start something new, right? In a way, being able to unlock the front door with my smart phone is just a nice side effect…

So while I’m still waiting on some Z-Wave hardware for my RaZberry, I started doing those last bits on some of my earlier projects.

Security system

Getting our security system connected to the rest of my Home Automation system has always appealed to me. With RFXCOM and an Alphatronics interface I did have access to the information of the sensors, but controlling the security system can be very handy too, for example arming it when everybody has gone to bed.
I did some experiments with a Powerlink in 2011, connected the system to my LAN in 2012, tested this with some experimental code, helped others to get things working, but there is where it ended; during a re-shuffle of some Serial-to Ethernet servers our security system was disconnected and I kinda ‘forgot’ about it; however some recent ‘events’ in the neighborhood brought the job of integrating the security system higher up on the to-do list.

Someone was so kind to give me his PowerMax code which has already been tested at various locations and the last 2 weeks I’ve been busy ‘porting’ the VB code to Delphi, testing the code with my own security system and monitoring everything to see if it’s all working OK. And it is… so now it’s time to take the last step and start using that interface.¬†The biggest advantage is that my Home Automation system knows exactly the same as the security system does:

  • Panel Status (e.g. Armed, Disarmed, …);
  • Panel State (Ready, Alarm, Zones in memory, …);
  • Sensor information ( Open, Closed, Motion, Battery Low, ..).

By getting the information directly from the security system itself, it won’t matter anymore if RFXCOM or Alphatronics receiver will miss some packets – now I’ve got 100% correct information.¬†And now I also have several new things I can do with my security system:

  • Arm and disarm the security system from my Domotica system;
  • Arm the system and bypass certain zones if I want to;
  • Control the security system from anywhere and with any User Interface;
  • Disarm the Security system event-based; for example, when someone opens our Nemef Radaris RFID front door with a badge;
  • Arm the system when the front door is being locked.

This weekend I updated my system.

Done!

Nemef Radaris Evolution

Nemef Radaris Evolution

One of those other things that got disconnected some time ago in a 90%-finished-state. While working on a Plugin for the Nemef Radaris, I stopped using the Nemef RF Module from my own system to test the Plugin, and I never started using it again afterwards. A big loss? Well, the Nemef Radaris doesn’t need a HA system, it works completely autonomously (for obvious reasons), so in some way we didn’t really miss the ‘Domotica link’.. today I finished some loose ends in the code and it’s working 100% now.

Next!

Web interface

Web Interface

I’m very bad at creating nice-looking icons myself, it’s just not my cup of tea. Most of the times I try to find some icons on the web, but I’ve never been able to find an icon collection that has all the icons I need. So it becomes a mess very quickly, and ugly.. too ugly to use (and to show off..)

And my requirements are really not that high – as long as the icons speak for themselves and have a somewhat similar ‘look’ , I’m easily satisfied (I think).

After finding a new collection of icons on the domoticaforum this week, I decided to use that one. And there’s 1 big benefit with this collection: I know the person who made these icons, so if I miss some specific icon, I know I won’t be lost…

On to the next item!

So, even if the outcome of my new Z-Wave tryout with the RaZberry will be disappointing, waiting for Z-Wave has already brought some positive things, namely finishing some things that should have been done a long time ago. OTOH: waiting this long is OK Рjust once every 3 years or so, not more often please!

Visonic interface without a Powerlink

Whoa, some articles I wrote about the Visonic Powerlink a couple of months ago, seem to be rather popular again the last couple of days; I can see that in the WordPress Site Stats panel. And I can also tell you why; it’s because there are a number of people that have joined forces recently to reveal the protocol that’s being used by the Powerlink to communicate with the Visonic Powermax (Plus/Pro) alarm system. And for some reason people land om my blog, although my articles are not really related to the latest progress that is being made on opening up the Visonic PowerMax alarm systems.

It all started by a user named utz who started a topic on the MiCasaVerde forum¬†and started another topic on the Domoticaforum Europe¬†some weeks later, asking for help on reverse engineering the RS232 communication between the Visonic alarm system and the Powerlink. Well, he got some help allright ūüôā A member of the Domoticaforum even started a fundraising to buy a Powerlink especially for this goal – interfacing with the Visonic system without the need for a Powerlink!

Visonic RS232 moduleYes, all you need to communicate with your Visonic alarm system is a Visonic RS232 module, which will save you around 150 Euro on the Powerlink(2) hardware. Another advantage of bypassing the Powerlink is that the RS232 method always works (haven’t read any problems so far), in contrary to the stablity issues and even complete failure to get a PowerMax Pro communicate with a Powerlink2!

By the time I came back from vacation and read about it on the Domoticaforum, some members had already joined in reverse engineering the protocol. There’s even a Wiki for documenting everything that has been discovered about the protocol. ¬†I (and lots of other people) immediately saw the big potential of this RS232 approach, and the decision to buy a RS232 module was made in a split second, cause I wanted to start doing some testing too.

Every now and then you come¬†across¬†a topic of which you think: “Wow, this is cool,¬†very cool!”¬† This is one of those rare topics… thanks to all the guys that are helping on reverse engineering and documenting the protocol, cause this is a real¬†breakthrough¬†regarding integrating a Visonic alarm system into a Home Automation system!

Since I’m currently working on some other project, I haven’t been able to spend much time on this Visonic RS232 hack yet but I will, soon..ASAP…

I’ve got some great plans with this!

 

More Powerlink2 stuff

Another “HowStuffWorks” post ūüėČ

Changing the alarm state of a Visonic Powermax Pro with the Powerlink2 was fun, but there’s more. The Powerlink web interface also shows the Control Panel status:

Visonic Control Panel status

And, if there are any sensors that prevent the alarm from being armed they’re shown here too. Wouldn’t it be nice to obtain that information in a usable form, so it can be used in our own apps?¬†(everything is called an “app” these days, right) ¬†Stuff like the current status, sensor information and such? Gotta have it! Here we go…

I started a browser, Fiddler and logged in on the Powerlink 2 mobile interface and saw these periodic calls being made:

GET  HTTP/1.1 Accept: */* Accept-Language: nl
Referer:
Content-Type: application/octet-stream
Accept-Encoding: gzip, deflate
User-Agent: blabla
Host: xx.xx.xx.200
Connection: Keep-Alive
Cookie: PowerLink=43e66dc8f6485151c9179d40b0e1831f; mobile=802fece964ec8e77ca2e533d479cc93f

Quite easy to mimic. So I did and logged the responses:

{ "id": "1", "js": { "reply": { "index": "24", "configuration": { "sensors": [ { "name": "Sensor", "index": "1", "type": "Delay 1", "location": "Front Door" }, { "name": "Sensor", "index": "2", "type": "Perimeter-Follow" , "location": "Hall" } ], "system": { "name": "Control Panel", "disarm": [  ], "status": "Ready", "arm": "0", "latchkey_enable": "Latchkey Enable", "ip_mode": "dynamic", "ip": "xx.xx.xx.200", "subnet": "255.255.255.0", "gateway": "xx.xx.xx.60", "dns1": "xx.xx.xx.1" } }, "alarms": [  ], "alarmframetimes": [  ] } }, "text": "" }

This is the ‘initial’ response, as in the first response we get to the request shown above. Here we see the sensors, their index number (needed later on), type and location and we also see the Control Panel status: Ready. OK; lets see what the response is made of when we repeat the same request a few times:

{ "id": "1", "js": { "reply": [  ] }, "text": "" }

Few seconds later another request, response is still the same:

{ "id": "1", "js": { "reply": [  ] }, "text": "" }

Nothing changes. Let’s open the Hall sensor (no, not this one, but a regular MCT-302) :

{ "id": "1", "js": { "reply": { "index": "25", "update": { "sensors": [ { "index": "1" }, { "index": "2", "status": "Open" } ], "system": { "not_ready": [  ], "disarm": [  ], "status": "Not Ready", "arm": "0" } } } }, "text": "" }

Aha! The sensor with index 2 changed to status “Open” and the Control Panel Status changed to “Not ready”. On the Powermax LCD display I see: HALL OPEN. Yep, the Control Panel is showing the right text; it’s working ūüėČ

Next response, with the Hall sensor still open:

{ "id": "1", "js": { "reply": [  ] }, "text": "" }

And again…

{ "id": "1", "js": { "reply": [  ] }, "text": "" }

Time to close the sensor again, now I get this:

{ "id": "1", "js": { "reply": { "index": "26", "update": { "sensors": [ { "index": "1" }, { "index": "2" } ], "system": { "disarm": [  ], "status": "Ready", "arm": "0" } } } }, "text": "" }

No more “problem sensors” and the Control Panel is back to “Ready”. Also notice this index number increasing with every change (24, 25, 26…). Track this one in your software and use it in the subsequent requests you do. If you don’t, you’re gonna miss all the information you want…

And as expected, the next responses are:

{ "id": "1", "js": { "reply": [  ] }, "text": "" }
{ "id": "1", "js": { "reply": [  ] }, "text": "" }

With this information it should be relatively easy to create a driver for it and use the provided information for whatever you want.

I also added the quick&dirty example code I used while playing with the Powerlink 2. Now I’m gonna find me a large firm cardboard box, put the Powermax Pro in it and send it back to Pieter. I’m sure he’ll want to start using it by now!

Next!

Hacking the Visonic Powerlink 2

Yesterday a friend of mine,¬†Pieter Knuvers, paid us a visit. We have a lot in common of which passion for Domotica is one, and we also think alike on a lot of other related subjects and on how to deal with them. We discussed several projects we’re (both) working on and what we can do do to make the best of it all nearly the whole afternoon.

He also brought his Visonic PowerMax Pro with him. Inside this Powermax there’s a Powerlink2 module, with which it’s possible to Ethernet-enable the Visonic Powermax Pro. Now wouldn’t it be great if we could find a way to control this Powermax from our Domotica systems? Of course! I see a lot of benefits to this, total integration of an alarm system into a Home Automation solution. In a secure way of course. Pieters idea to let his Domotica system decide when his alarm system can be disarmed is a very logical step, especially when you’ve already let your Domotica system know who you are by means of another secure subsystem…

And since we both created our own Domotica systems from scratch ourselves, it would just be a matter of finding out how, and integration would just be a matter of adding some extra code to our systems and we would be good to go! On the other hand, I also thought about the implications of being able to control an alarm system by its web interface; it would actually be a good thing if this wasn’t too easy… ¬†Nevertheless, let’s see if we can get this alarm system to obey our commands ūüėČ

OK, here we go. We plugged in a UTP cable, started a browser and entered the IP address of the Visonic Powerlink2: x.x.x.200. The Powerlink module automatically assigns itself the .200 address of your local subnet. We started with our good friend Wireshark again to do some research, but later that evening I switched to Fiddler, cause while going through the Wireshark output, I had the feeling that Fiddler would be a better choice this time. I logged in on the Powerlink2 web interface and pushed the DISARM button. This resulted in the following HTTP request:

GET .../mobile/dam/arm/mode/disarm_state?JsHttpRequest=129823770199311-xml HTTP/1.1
Host: xxx.xxx.xxx.200
Connection: keep-alive
Referer:
Content-Type: application/octet-stream
Accept: */*
User-Agent: blabla
Accept-Encoding: gzip,deflate,sdch
Accept-Language: nl-NL,nl;q=0.8,en-US;q=0.6,en;q=0.4
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: PowerLink=85a0bab15d60db242cc73c717aa46f7c; mobile=636f92fd8f357d0b10a2f70a845e2305

Hmm, that shouldn’t be too hard… first thing I looked at was that big number in the GET. It wasn’t random, cause with every GET it only seemed to get higher. Some time related number perhaps? OK, let’s look inside a /web/js/powerlink.js file I downloaded from the Visonic Powerlink2. Well what do we have here (sometimes 1 line of code is enough to ‘know’ what’s going on, I wouldn’t try to try to understand the complete script):

JsHttpRequest.extend(<blabla>, id:(new Date().getTime())+""+JsHttpRequest.COUNT++,hash:_a,span:null});

Ahhh.. getTime() returns the number of milliseconds since midnight of January 1, 1970, aka Unix epoch. That’s not hard to reproduce. The rest of this HTTP request should not be too hard to create either. Now let’s focus on the login process. I thought this would be much more complex. Let’s have a look at what Fiddler is showing me when I enter username & password and hit the LOGIN button:

POST .../mobile/login/index/?JsHttpRequest=12982287732070-xml HTTP/1.1
Accept: */*
Accept-Language: nl
Referer:
Content-Type: application/octet-stream
Accept-Encoding: gzip, deflate
User-Agent: blabla
Host: xxx.xxx.xxx.200
Content-Length: 42
Connection: Keep-Alive
Pragma: no-cache
Cookie: PowerLink=077d58c208ef9aaef1fe8d464015d929; mobile=e6efb2eae139ca6fe327b603d6c23e76
login=admin&password=admin&time=1298228773

Actually, I didn’t like what I saw.. do I really see my username and password being sent, unencrypted? Oh no… come on, Visonic.. ¬†But that’s an issue for another blog post; let’s stay focused ūüôā The response was:

HTTP/1.1 200 OK
Date: Sat, 01 Jan 2000 16:47:48 GMT
Server: Apache/1.3.31 (Unix) PHP/4.3.9 mod_ssl/2.8.20 OpenSSL/0.9.7e
X-Powered-By: PHP/4.3.9
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: private, max-age=1200, pre-check=1200
Last-Modified: Thu, 10 Jun 2010 02:27:30 GMT
Content-Type: text/plain; charset=utf-8
X-Cache: MISS from xxx.xxx.xxx.200
Connection: close
Transfer-Encoding: chunked

40
{ "id": "12982287732070", "js": { "result": "ok" }, "text": "" }
0
OK, this tells me that the result is ok, and I get that big number returned in the response… high level of rocket-science involved here…
I had seen enough, it was time to mimic this conversation from a small app, starting with performing a¬†successful¬†login. Done … Now the first difference I saw was that the response from the Visonic contained the following header:
Set-Cookie: mobile=353bbda17768c82ba9aa5331efc7157a; path=/
Yeah, right. ¬†My app is not a browser so there’s no cookie, so my app is asked to set one. OK, I will simulate that. I extracted the bold part from this header and used it in the next HTTP call, in which I wanted to disarm the alarm:
GET .../mobile/dam/arm/mode/disarm_state?JsHttpRequest=12982439146581-xml HTTP/1.1
Cookie: mobile=353bbda17768c82ba9aa5331efc7157a Host: xxx.xxx.xxx.200

Yeeha! Some female voice said to me: “Disarm. Ready to arm”. Was I dreaming? Again.¬†“Disarm. Ready to arm”. Hmm, that’s not bad… I’m getting all excited just by listening to a female “computer voice” !?

OK; now let’s arm this thing:

GET .../mobile/dam/arm/mode/away_state?JsHttpRequest=12982439148311-xml HTTP/1.1

“Arming away. Please exit now.'”¬†I did it !?!¬†Actually, I can’t believe I did…it’s too easy !!! But it works, time after time after time… I know Ethernet enabled thermostats and DSL modems that do a better job here…