ParadoxIP150v2
ParadoxIP150v2 copied to clipboard
Tertiush
Support for SP5500
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,
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.
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.
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.
OK, thanks, I'll be able to do that tomorrow. It's late night/early dawn here...
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
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.
@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.
@Tertiush I just tried on my SP5500 and it works beautifully. The events and the arming works.
@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
@olihb are you sure you're using the v2 code? You're claiming you're seeing the labels for the events?
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 .
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.
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
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?
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?
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.
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.....
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
Hi all, I'm at work right now, I'll take a look tonight. btw, sp5500 seems to work with winload.
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?
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.
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...
@Tertiush could you add your fix to the Python script too? I think we could test it for you if it helps even there.
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.
@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 :)
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.
@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.
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
@Tertiush right, when made the comment I didn't realize v2 only uses port 10000.
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?