Support for SP5500

[kobuki]

The script is running fine, publishing some events to the broker, but as in case of #2 or #3, there are no labels. For zone open/close events, there is no information on which zone is affected. I've also tried using the newer srcipt for SP4000 attached to #2 as well, no dice.

Here's the output of mosquitto_sub -v -t "#":

Paradox/State State Machine 4, Listening for events... Paradox/State State Machine 1, Connected to MQTT Broker Paradox/State State Machine 2, Connecting to IP Module... Paradox/State State Machine 2, Connected to IP Module, unlocking... Paradox/State State Machine 2, Logged into IP Module successfully Paradox/State State Machine 3, Reading labels from alarm Paradox/Labels/WirelessKeypads 1:;2:;3:;4:;5:;6:;7:;8: Paradox/Labels/WirelessSirens 1:;2:;3:;4: Paradox/Labels/SiteNames 1: Paradox/Labels/Partitions 1:;2: Paradox/Labels/WirelessRepeaters 1:;2: Paradox/Labels/Outputs 1:;2:;3:;4:;5:;6:;7:;8:;9:;10:;11:;12:;13:;14:;15:;16: Paradox/Labels/Zones 1:;2:;3:;4:;5:;6:;7:;8:;9:;10:;11:;12:;13:;14:;15:;16:;17:;18:;19:;20:;21:;22:;23:;24:;25:;26:;27:;28:;29:;30:;31:;32:;99:Any zone Paradox/Labels/Users 1:;2:;3:;4:;5:;6:;7:;8:;9:;10:;11:;12:;13:;14:;15:;16:;17:;18:;19:;20:;21:;22:;23:;24:;25:;26:;27:;28:;29:;30:;31:;32: Paradox/Labels/BusModules 1:;2:;3:;4:;5:;6:;7:;8:;9:;10:;11:;12:;13:;14:;15: Paradox/State State Machine 4, Listening for events... Paradox/Events Event:Zone open;SubEvent: Paradox/Events Event:Zone OK;SubEvent:

If you need more logs, I can provide them,

[Tertiush]

Hi For me to check the difference between this alarm and the ones I've been working on I'd need direct access.... I only have an MG5050 so without direct access and trying a few things (on winload) its very difficult to find the issue. If you willing to to go that route drop me a PM on the openhab community forum.

[kobuki]

Thanks for looking into this. Obviously, any acces of our alarm system to strangers is a no go. However I can log traffic for you or provide logs. Just tell me what to do and I'll try to do it to help.

One more bug with the SP5500 is that when I try to bypass a zone it just something like "response is not understood" or such a thing. I can open a new issue with the exact message if you want.

[Tertiush]

Totally understood.

Best thing is to send some wireshark traps (explained in the 2nd paragraph of the readme) of the traffic when reading the zone labels etc. from the alarm. Then I can see the commands sent and replies received in one go. Note that it must be un-encrypted. Remove the first line from the wireshark traps as it will contain you password in hex. If you want you can email me the traps rather than posting them here. I'll have a look tomorrow.

[kobuki]

OK, thanks, I'll be able to do that tomorrow. It's late night/early dawn here...

[olihb]

Hi there, I have a SP5500 system and I'm willing to help you support it. I just installed the IP150 module, but didn't try your tool yet. I will do it probably tonight or over the weekend.

Let me know what you need (wireshark logs, debug output, etc.).

Olivier

[Tertiush]

Hi Olivier

@kobuki and I had a few emails going up and down and this is one I sent:

I'm afraid this is the same issue another had. Also works with BW, not WL. I wish I could help; I've spent countless hours trying to reverse engineer the SP4000 with no luck. Somewhere on the internet is a table showing WL's support (to the functional level) for different panel types and the SP4000 is shown to not support a few things. I suspect the SP5500 is in the same boat. Not good news, sorry.

Unless you can find a way to reverse engineer the Babyware traffic, I'm afraid you're out of luck for now.

[olihb]

@Tertiush, thanks for your answer. I'll take a look. If the protocols aren't too different, it might not be too hard. In all cases, I can fallback on the web interface.

[olihb]

@Tertiush I just tried on my SP5500 and it works beautifully. The events and the arming works.

[ghost]

@olihb Hi Olivier,

That's very good news as I am installing a SP5500 + IP150 in about 1 months time. Did you have to make any changes to the code?

Cheers, Mike

[kobuki]

@olihb are you sure you're using the v2 code? You're claiming you're seeing the labels for the events?

[olihb]

Yep, I just tested it again. Let me know if you want other output or for me to test something:

olihb@olihb-VirtualBox ~/ParadoxIP150v2 $ python IP150-MQTTv2.py Reading config.ini file... config.ini file read successfully Attempting connection to MQTT Broker: 127.0.0.1:1883 MQTT client subscribed to control messages on topic: Paradox/C/# Connected to MQTT broker with result code 0 Logging into alarm system... Login to alarm panel successful Updating all labels from alarm Labels detected for wirelessKeypadLabel: {1: 'Wireless Keyp 1', 2: 'Wireless Keyp 2', 3: 'Wireless Keyp 3', 4: 'Wireless Keyp 4', 5: 'Wireless Keyp 5', 6: 'Wireless Keyp 6', 7: 'Wireless Keyp 7', 8: 'Wireless Keyp 8'} Labels detected for wirelessSirenLabel: {1: 'Wireless Siren 1', 2: 'Wireless Siren 2', 3: 'Wireless Siren 3', 4: 'Wireless Siren 4'} Labels detected for siteNameLabel: {1: 'Your Alarm Site'} Labels detected for partitionLabel: {1: ' Area 1', 2: ' Area 2'} Labels detected for wirelessRepeaterLabel: {1: 'Repeater 1', 2: 'Repeater 2'} Labels detected for outputLabel: {1: 'Output 01', 2: 'Output 02', 3: 'Output 03', 4: 'Output 04', 5: 'Output 05', 6: 'Output 06', 7: 'Output 07', 8: 'Output 08', 9: 'Output 09', 10: 'Output 10', 11: 'Output 11', 12: 'Output 12', 13: 'Output 13', 14: 'Output 14', 15: 'Output 15', 16: 'Output 16'} Labels detected for zoneLabel: {1: 'PORTEENTREE', 2: 'IRENTREE', 3: 'IRAVANT', 4: 'PORTEETAGE', 5: 'Zone05', 6: 'Zone 06', 7: 'Zone 07', 8: 'Zone 08', 9: 'Zone 09', 10: 'Zone 10', 11: 'Zone 11', 12: 'Zone 12', 13: 'Zone 13', 14: 'Zone 14', 15: 'Zone 15', 16: 'Zone 16', 17: 'Zone 17', 18: 'Zone 18', 19: 'Zone 19', 20: 'Zone 20', 21: 'Zone 21', 22: 'Zone 22', 23: 'Zone 23', 24: 'Zone 24', 25: 'Zone 25', 26: 'Zone 26', 27: 'Zone 27', 28: 'Zone 28', 29: 'Zone 29', 30: 'Zone 30', 31: 'Zone 31', 32: 'Zone 32', 99: 'Any zone'} Labels detected for userLabel: {1: 'System Master', 2: 'Master 1', 3: 'Master 2', 4: 'User 04', 5: 'User 05', 6: 'User 06', 7: 'User 07', 8: 'User 08', 9: 'User 09', 10: 'User 10', 11: 'User 11', 12: 'User 12', 13: 'User 13', 14: 'User 14', 15: 'User 15', 16: 'User 16', 17: 'User 17', 18: 'User 18', 19: 'User 19', 20: 'User 20', 21: 'User 21', 22: 'User 22', 23: 'User 23', 24: 'User 24', 25: 'User 25', 26: 'User 26', 27: 'User 27', 28: 'User 28', 29: 'User 29', 30: 'User 30', 31: 'User 31', 32: 'User 32'} Labels detected for busModuleLabel: {1: 'Bus Module 01', 2: 'Bus Module 02', 3: 'Bus Module 03', 4: 'Bus Module 04', 5: 'Bus Module 05', 6: 'Bus Module 06', 7: 'Bus Module 07', 8: 'Bus Module 08', 9: 'Bus Module 09', 10: 'Bus Module 10', 11: 'Bus Module 11', 12: 'Bus Module 12', 13: 'Bus Module 13', 14: 'Bus Module 14', 15: 'Bus Module 15'} Listening for events... . . . . Event:Zone open;SubEvent:IRENTREE . Event:Zone OK;SubEvent:IRENTREE . Event:Zone open;SubEvent:IRAVANT . Event:Zone OK;SubEvent:IRAVANT . Event:Zone open;SubEvent:IRENTREE . Event:Zone OK;SubEvent:IRENTREE .

[Tertiush]

Interesting. Can you try to control a PGM output? Also which firmware version is your panel on, perhaps the others can try with a similar firmware.

[kobuki]

I'm leaving here mine too, it might behave differently.

Panel Type SP5500 Firmware version 4.94

IP module Firmware version 1.34.00 Hardware 020 ECO N009 Serial boot N/A IP boot 2.12

[kobuki]

Now, this is interesting. I've logged in the IP150 using the master account and while logged in, the labels were then properly collected and displayed when starting the Python V2 app. I logged out - old problem with no labels collected when starting it again. However, as addendum to my original report, it seems that regardless of login state, some events are displayed like this:

Multiple data: ['\xe0\x14\x10\x08\x1f\x0b2\x00\x02\x00\x00\x00\x00\x00\x00Redacted\x00Redac\x00\x00\x00\x00\x00\x00\x00\x98', '\xe0\x14\x10\x08\x1f\x0b2\x00\x03\x00\x00\x00\x00\x00\x00Redacted02\x00Redac\x00\x00\x00\x00\x00\x1b']

(Replaced real labels with RedactedXX using the same number of characters.) It looks as if the separate login changes some mode setting in the module?

[Tertiush]

I wonder if the IP module 'primes' the link to the alarm panel to be in a certain state, i.e. the state the IP module needs for collecting the web-required data.....? And this state is also what the MG5050 and other panel usually see. I'd love to get to the bottom of this as it might mean support for a host of other panel types! Does your PGM control work?

[kobuki]

I've no facility for write ops on MQTT (unless there's a simple cline tool?) and you took the possibility out from the beta app I've installed so I can't test now.

[Tertiush]

There's quite a few MQTT clients out there based on JAVA that's relatively light to run (no install needed, just run the .jar). Then connect to your broker and send the message for a PGM control.

Can't get to the name of the one I used now.....

[kobuki]

While logged in the IP150 via its web interface, I sent a command: Paradox/C/P1/Disarm - the panel beeped as a sign of accepting the command, so it seems to work. Logged out of the web GUI, the command seems to be accepted but the panel did NOT beep, so the command failed.

In both cases the output was the same:

MQTT Message: Paradox/C/P1/Disarm Alarm control partition: 1 Alarm control state: Disarm . Logging into alarm system... Login to alarm panel successful Sending generic Alarm Control: Partition: 1, State: DISARM Listening for events...

PS: using mqtt-spy

[olihb]

Hi all, I'm at work right now, I'll take a look tonight. btw, sp5500 seems to work with winload.

[kobuki]

I remember having to use BabyWare with my system, since Winload also had problems correctly displaying labels and other data. BW works fine. Maybe that could shed some more light on the issue. I suspect newer firmware communicates differently, like mandating stronger encryption which WL probably doesn't support (or supports only older encryption methods). @olihb, when you get to it, could you post your own version numbers, too?

[mnmn2]

Hi, there is definitely some kind of limitation on the number of connections to the IP150 module. If you try to log in on the WEB interface, it will fail if there is a session opened. Also, if you start a connection from iParadox (the mobile app of Paradox, which uses the port 10000 also), then Winload can not connect. Neither the python script! Winload also takes full control, no other access can be made if that's connected. If you exit from iParadox(or Winload), then python can connect. But that's true only at startup, where the python takes care about the connection.

If I connect with python first, and then iParadox, then both can connect and work. strange... However, when python connects, and then starts listening, and uses the "original" keepalive message, (which does not generate any reply), then about 4-5 sec after the listening started, I always receive an event telling me, that Winload exited. I guess, the script is handled as a Winload session by the IP150, and there is a quite short "timeout" for that connection, and IP150 thinks that user had gone. When I use the 19 pcs keepAlive messages, then there is no Winload logoff event.

[Tertiush]

I just modified the android app to not disconnect the web connection (which it uses 90% of the time) and do a PGM and bypass (which uses the separate software 10000 port) and it actually works. Previously I disconnected the web to make 'space' for the software connection but it turns out they can work together. How the hell I missed that before is astonishing.... Anywho I just sent it to one of the beta tester who has a lot of alarms to play with (think he's an installer/distributor). Will report back with his findings. @mnmn2 I think what you are seeing is why I previously disconnected the web connection - Winload clearly takes precedence over anything else. Also regarding the keep-alives, I had to check the code now but see line 898:

myAlarm.keepAlive(Debug_Mode)

does actually send a keep-alive. This keep-alice also sequentially increases a counter (part of payload) which mimics a winload connection. Not sure though why my sessions get's logged off. I re-login before every control action because of this automated logoff...

[kobuki]

@Tertiush could you add your fix to the Python script too? I think we could test it for you if it helps even there.

[Tertiush]

Can be done, but it will require me to join parts of the v1 code into v2, which is going to be a bit of an undertaking. Let's first see what I can get going with the android app seeing as it can already make both types of connections. If the beta tester comes back showing promise I will release that version as a new beta on the play store. If that then works I'll make a plan to update the script.

[mnmn2]

@Tertiush I know that keepAlive msg, I referenced to that as "original" keepalive message. Using that: it happens, that IP150 tell me, that Winload is out. However, your keepalive message is "too short" :), it does not receive any reply... I've got a friend, who has a Spectra (I'm not sure about the exact type) with IP100, and he told me, that using Winload, he saw a longer keepalive message. AFAIK, he use this "longer" message, and he do receive a reply at every ~3.-4. request. And that reply contains status info about the zones and partitions...

    header = "\xaa\x25\x00\x04\x08\x00\x00\x14\xee\xee\xee\xee\xee\xee\xee\xee"

    message = "\x50\x00\x80"

    message += bytes(bytearray([self.aliveSeq]))

    message += "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"

**message += "\xd1\xee\xee\xee\xee\xee\xee\xee\xee\xee\xee\xee"** 

I think, that's the magic :)

[mnmn2]

Not sure though why my sessions get's logged off. I re-login before every control action because of this automated logoff

the strange part, is that despite the "Winload out" event arrives (before everything else), everything is working fine after that :) events are arriving perfectly. However, I can't say anything about the control actions, because they don't work at all with the EVO192. I started to find the commands, but still beeing in the dark :) Focusing on the statuses first.

[Tertiush]

@mnmn2 Strange, I would've copied the exact same winload sequence. Maybe the IP module sends different keep-alives to different alarm panel types. Nevertheless its something to keep an eye out for. I will re-look at that when I merge the two version (hopeful thinking it will work :) )

On your next comment: Yes the events are always broadcast. That's why I only do a re-login when a PGM/alarm control is needed.

[Tertiush]

Here's a quick and dirty hack I did on the Alarmin app. It will now not disconnect (and ignore an EVO when it sees it) from the web connection and 'interleave' the software port connection . See if anyone can control the PGM or bypass a zone with this. Noting that you must first connect with the blueish button (web) and then do the PGM / bypass that uses the software port. If this works we have grounds to change the script and include the web connection.

https://dl.dropboxusercontent.com/u/70190585/android-release.apk

[kobuki]

@Tertiush right, when made the comment I didn't realize v2 only uses port 10000.

[kobuki]

I tried the APK, great work! It reads all labels and I can also control the PGM outputs (checked the state on the IP150 web page after logout). While the app is running and my site is opened, I can't login on the web interface, but at this state I think it's normal. For a general use app, probably it shouldn't block all the time, only when updating.

EDIT: tried to use bypass but in this APK there is no bypass function - did you by chance forget to enable it?

[Tertiush]

The app would only prove that the PGM works whilst the web is logged in. The labels and so on uses the web port (so not v2). With all this now somewhat known (and needing a few more users to confirm), then next step is one of two:

1. V1 will always correctly read labels, but cannot do PGM or Bypass. Bring the relevant V2 code in there to perform these functions. Noting that V1 will shotgun the web port permanently.
2. V2 can do PGM control, but lacks good label-reading support. Bring the relevant V1 code into V2 but only to read the labels then disconnect the web port. The software port remains open to catch events and do controls (alarm & PGM), but would require a temporary web connection each time to perform the controls.

Either way its going to be quite a bit of coding and before I do anything I need to be 100% sure its repeatable, stable and supported on 'most' panels currently not working on V2. So let's wait for some more test results...

[kobuki]

Your aim is to avoid dealing with port 10k encryption, right? Since using the web interface is somehow able to circumvent that. The port 10k API can manage everything without the aid of the web interface. But if your "interleaving" solution would prove to wok reliably, that still would be a big leap ahead.

[Tertiush]

Not actually. I still use the software port (10000 typically) but with encryption switched off. Also the api is actually a SDK for Windows only so wouldn't be portable to other operating systems (been there tried that). The interleaving is just the Web port working in conjunction with the software port, as a temporary measure of sorts.

On Wed, 31 Aug 2016, 22:35 kobuki notifications@github.com wrote:

Your aim is to avoid dealing with port 10k encryption, right? Since using the web interface is somehow able to circumvent that. The port 10k API can manage everything without the aid of the web interface. But if your "interleaving" solution would prove to wok reliably, that still would be a big leap ahead.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/Tertiush/ParadoxIP150v2/issues/4#issuecomment-243892610, or mute the thread https://github.com/notifications/unsubscribe-auth/ALGOjEXQy33FnckbasiJpZHusui-ixACks5qleWCgaJpZM4JeYq9 .

[kobuki]

I was referring to the 10k "API" as a binary one, not the windows-only .net joke. I sent you a cap earlier that contained undecipherable messages where the labels should have been. We concluded it must be encrypted. That's why I thought that this interleaving might turn that encryption off - it might work completely differently, though.

[olihb]

Here's my version numbers for the panel and the IP module:

Panel Type SP5500 Firmware version 4.94

IP module Firmware version 1.39.02 Hardware 020 ECO N009 Serial boot N/A IP boot 2.12

I removed the serial numbers, but I can send them to you by email if needed.

I tried to trigger PGM but I don't have anything connected to them so I can't know if it's working for real but I got this output: Listening for events... . . MQTT Message: Paradox/C/PO/1 On Output pulse control number: 1 Output pulse control state: On . Logging into alarm system... Login to alarm panel successful Sending generic Output Control: Output: 1, State: ON Sending generic Output Control: Output: 1, State: OFF Listening for events...

[Tertiush]

@mnmn2 You are right about the keepalives, mine is wrong (thanks!). Did a quick wireshark now, I need to add a checksum and pad with 0xee till 48 bytes. Your example of xd1 xee xee, etc start with the checksum, that goes to 0xd2, 0xd3, etc as the keel-alive's counter increases and thus the checksum. No idea how I missed that. If I have time over the weekend I'll try it on the Alarmin app as a test.

The beta tester did come back and could only test on an EVO, for which this multiple connections didn't work. Other than that only @kobuki somewhat confirmed it working, Would like to know for which other SP models it also improves functionality before implementing.

[kobuki]

@Tertiush I couldn't test bypass since the APK you linked here doesn't have the function enabled. I won't go and hook up something on the pgm outputs, so if you have a good idea for a better test other than checking the status with the official app, shoot.

[psyciknz]

Anyone have any pointers for what is required for a SP5500? I get no values in the subevent fields 2017-03-11 15:34:21,475 INFO {1: '', 2: '', 3: '', 4: '', 5: '', 6: '', 7: '', 8: '', 9: '', 10: '', 11: '', 12: '', 13: '', 14: '', 15: '', 16: ''} 2017-03-11 15:34:21,475 INFO updateAllLabels: Topic being published Paradox/Labels/Outputs1:;2:;3:;4:;5:;6:;7:;8:;9:;10:;11:;12:;13:;14:;15:;16: 2017-03-11 15:34:21,475 DEBUG updateAllLabels: Reading from alarm: zoneLabel 2017-03-11 15:34:21,476 DEBUG updateAllLabels: Amount of numeric items in dictionary to read: 32

....but I have managed to make changes to the code to publish specific topics by pulling the zone label from the zone event received by the code.

[kobuki]

I also have a 5500 with similar problems. It looks to me this project has been abandoned in spite of the closed source Android app. Sad.

[powerwade]

Not sure why the script fails if others with SP5500 reports some results

MQTT client subscribed to control messages on topic: Paradox/C/# Connected to MQTT broker with result code 0 Logging into alarm system... Error attempting connection to IP module (3: IndexError('string index out of range',) Logging into alarm system... Unknown error on socket connection, retrying... error(104, 'Connection reset by peer') Unknown error on socket connection, retrying... error(32, 'Broken pipe') Unknown error on socket connection, retrying... error(32, 'Broken pipe') Failure, disconnected.

Any ideas?

[ArcadeMachinist]

My SP5500 works perfectly with V2 (it reads all the labels too), except one small issue. It is impossible to disarm from pre-alarm state.

It is when you open front door and alarm begins NN seconds countdown for you to enter the code. From this state it ignores disarm command. If it is not in pre-alarm - disarms ok.

SP5500 v 4.78

IP modue Software 5.10.06 Hardware 3.E0