search

Tertiush / ParadoxIP150v2

Python-based IP150 'middle-ware' that uses the IP module's software port for monitoring and control of the alarm via an MQTT Broker.
Eclipse Public License 1.0
73 stars 35 forks source link

EVO compatibility #5

Open mnmn2 opened 8 years ago

mnmn2 commented 8 years ago

Hello, I've got an EVO192, and tried your great code, but of course, it won't work perfectly :) (Of course it works fine at a friend of mine, who has a MG5050)

I modified the config, to skip the label-readings, because it's not a big issue to enter them manually. I've concentrated on the events. I've got the programming documents, describing the event codes (which are totally different to the MG5050). Modified the eventGroupMap array, but it still seems to work bad, the "decoded" events are not the ones, that are really happening...

Do you have some kind of SDK or other info about the EVO192? Or only the Wireshark reverse-engineering could work?

thanks, MN

Tertiush commented 8 years ago

Hi

There seems to be quite a few differences between the EVO and MG series when it comes to register locations. I found the PGM registers to also not work. Best bet would be to play with wireshark and see it you can pick up a pattern. Must be honest I did give an EVO192 a go once before and I think the labels did work. Maybe also confirm that your firmware is up to date...?

mnmn2 commented 8 years ago

Hello, the Evo192 has firmaware 2.90, and the IP150 has 1.34.00 (Strange, but after 15 mins I gave up finding the latest firmware numbers... I don't know if these are the latest...)

I'm stepping ahead quite slowly. Or very slowly. :) It seems, that my EVO is not configured to put every event on the bus, but only the arm/disarm related events are showing up. But I'm not sure, because at the moment I'm just guessing...

It seems, that the EventGroup field is message[10], and subevent group is message[11]. The worst thing, is that there is no delimiter char between 2 messages. So if there comes a "multiple data" message, then it's not decoded. Maybe I could compare the lengths, and split by a predefined length.

I'm not a real fan of WinLoad (I guess, a UFO had defined it's functionality), but it seems, that I will have to learn it in depth...

mnmn2 commented 8 years ago

Meanwhile it turned out, that message[10] and message[12] are the right fields. And also realized, that an incoming datagram can have 3 formats:

  1. simple 1 header (starts with \xaa, 16 bytes long) + 1 simple body (37 bytes long)
  2. simple 1 header (starts with \xaa, 16 bytes long) + more than 1 simple body (n*37 bytes long, no real delimiter)
  3. concatenation of the 1. and 2. type. So there can be 3 message bodies within a datagram, with 2 \xaa headers

Of course, the meanings of the event codes are totally different, but documented in Paradox tutorials.

It seems, that there are no events generated, on opening/closing Zones.

And it seems, that WinLoad also does not receive "special" datagrams. However, the keepalive message is different. It's multiplied. The sequence goes up to 16 (or 19 sometimes), and there are different values in the fields. And there are replies to these keepalive messages, sent by the IP module. The responses are almost the same (compared upon the sequences), if there is no change in the Zone/partition statuses, and there are varying fields, if there is movement for example. The "reverse engineering" of these fields and values is a nice task for the near future :)

Tertiush commented 8 years ago

That's awesome! Great work & good luck with the reverse engineering. There's a lot of guys wanting to integrate to the BW-only devices!

mnmn2 commented 8 years ago

Just let you know: I'm progressing, but slowly... Already identified the keepalive messages, which replies contains info about Zone status changes, and Partition Satuses, even about the bypassed zones. However the result-codes are not really obvious at this moment. Still need some Winload-Wireshark work...

Tertiush commented 8 years ago

Progress, great! Thanks for the update

Tertiush commented 8 years ago

@mnmn2 Are you following the discussion at https://github.com/Tertiush/ParadoxIP150v2/issues/4 ?

varaslt commented 8 years ago

@mnmn2 Could you share with the code for EVO192?

a-lurker commented 8 years ago

Tertiush - all good work. I wrote a web page scraper for Vera in Lua for the EVO given some of your inspiration: Scraper plugin I would have to say that the Paradox web page code is pretty poor. BabyWare is pretty sad too. Currently it seems I don't need to use any keep alives, which I also found strange. Maybe I'm polling sufficiently to keep it happy. However, I would prefer to use the 10,000 port as it has more control than the web page.

Few questions: I see that one can use the COM.ini file to control the encoding used by WinLoad. I tried this on BabyWare and failed. It has a COM.ini file located under folder In-Field. This ends up in a virtual store at C:\Users\user\AppData\Local\VirtualStore. In either case, making changes to this file of any of its variables has no effect. Since it's in folder In-Field, I suspect its only used by the in field firmware updating tool or maybe I'm doing it wrong.

So does any one know how to control the encoding used by BabyWare?

Does WinLoad require an account or is stand alone? Last thing I want is another account? But I might have to resort to that?

I had a go decrypting the IP150 login - thought it might be using similar methods to the web page login but have failed so far to decode. Get's tricky; the programmer could be using their home phone number for salt. Who knows? Regardless, it certainly returns some sort of session key, each time you login, to further frustrate things.

Tertiush commented 8 years ago

Hi, I just popped a post here, have a look: https://community.openhab.org/t/help-build-binding-for-paradox-alarm-panel-with-ip150/1712/94?u=tertius_hyman

I've replicated paradox's rc4 and md5 hashing in code, by basically rewriting their functions (in commun.js i think) to python. The rev3 version should be able to do most functions however, not sure if you can use that via MQTT in micasaverde (I don't know the platform/framework).

Regarding the encryption, I haven't used babyware as I only have an MG5050. Winload can however perform bypasses and PGM (only 1->5) controls via winload, so I'm not too sure what babyware adds to the mix.

regards, Tertius

On Sun, 23 Oct 2016 at 08:30 a-lurker notifications@github.com wrote:

Tertiush - all good work. I wrote a web page scraper for Vera in Lua for the EVO given some of your inspiration: Scraper plugin http://forum.micasaverde.com/index.php/topic,38854.0.html I would have to say that the Paradox web page code is pretty poor. BabyWare is pretty sad too. Currently it seems I don't need to use any keep alives, which I also found strange. Maybe I'm polling sufficiently to keep it happy. However, I would prefer to use the 10,000 port as it has more control than the web page.

Few questions: I see that one can use the COM.ini file to control the encoding used by WinLoad. I tried this on BabyWare and failed. It has a COM.ini file located under folder In-Field. This ends up in a virtual store at C:\Users\user\AppData\Local\VirtualStore. In either case, making changes to this file of any of its variables has no effect. Since it's in folder In-Field, I suspect its only used by the in field firmware updating tool or maybe I'm doing it wrong.

So does any one know how to control the encoding used by BabyWare?

Does WinLoad require an account or is stand alone? Last thing I want is another account? But I might have to resort to that?

I had a go decrypting the IP150 login - thought it might be using similar methods to the web page login but have failed so far to decode. Get's tricky; the programmer could be using their home phone number for salt. Who knows? Regardless, it certainly returns some sort of session key, each time you login, to further frustrate things.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/Tertiush/ParadoxIP150v2/issues/5#issuecomment-255572226, or mute the thread https://github.com/notifications/unsubscribe-auth/ALGOjOz_Sr1wuQLXijeR-FqzFCmlsNIsks5q2v8ZgaJpZM4JpjXB .

mnmn2 commented 8 years ago

@varaslt of course, I can. BUT meanwhile I had to stop the development (for a while) so the current code is a "mess", and not a code, what I could be proud of... And only the status-reading is covered. The control processes (arm/disarm, etc) are not implemented yet.

if it still interests you, let me know, how can I send the code.

varaslt commented 8 years ago

@mnmn2 Yes I'm interested in and I do not need arm/disarm functionality so far. So please share your code if you can :) Have you the code in some repository? If not and you do not want to show it in public please send it by mail - varas@ambernet.lt

mnmn2 commented 8 years ago

@varaslt I have sent you the code by email best regards,

andrasj commented 8 years ago

Hello, This weekend I started to implement openHAB (also my first practical mqtt experience), and since I have a Paradox EVO192, I came acros this project. Currently I'm running the http/v1/polling solution but would like to switch to v2 and use the direct connection. I can test and report if needed (depending on free time it can take a couple of days).

I tested the Arm/Disarm functionality with v1 and it seems to work, but the 'Disarmed' status is reported as 8 and 9. These states are switching every couple of minutes. Maybe it has something to do with a 'Low Battery' trouble in one of my wireless detectors. Any documentation where I can verify the available states?

Also I read somewhere there is a .Net SDK, I'm very familiar with (.net) managed code decompiling, anyone tried this path to reverse engineer the protocol?

a-lurker commented 8 years ago

@andrasj I got these values for the EVO 192, via the IP150 web page decode. I don't have battery devices, so I'm interested in what 4 and 8 represent. I assume 'Stay' is the same thing as 'Sleep'?

[0] = 'Area not in use'
[1] = 'Instant'
[2] = 'Armed'
[3] = 'Alarm triggered'
[4] = '4'
[5] = 'Stay'
[6] = 'Entry Delay'
[7] = 'Exit delay'
[8] = '8'
[9] = 'Disarmed'

I also found that the Zone Status was not just a case of 0 or 1. That may be an issue for Tertius's code? It was for mine. I get this so far:

closed           0
open             1
bypass           ??
trouble          ??
in alarm         ??
memory & closed  5
memory & open    6
memory & open   & not an alarm trigger 2
memory & closed & not an alarm trigger 5
Tertiush commented 8 years ago

@a-lurker I had a quick look at the Android app's code and got these for alarm states: 1 = Disarmed 2 = Armed 3 = In alarm 4 = Armed in sleep (not applicable to EVO) 5 = Armed in stay 6 = Entry delay 7 = Exit delay 8 = Ready to arm 9 = Not ready to arm 10 = Instant

And for zone statuses: 0 = Closed 1 = Opened 2 = In alarm 3 = Closed with trouble 4 = Open with trouble 5 = Closed with alarm in memory 6 = Open with alarm in memory 7 = Bypassed 8 = Closed with trouble (duplicate?) 9 = Open with trouble (duplicate?)

My plan is still to port the core code of the Alarmin app into a standalone nodejs script with MQTT support, much the same as for v2 but with support for everything the app can do. Just haven't got the time to do it yet...

andrasj commented 7 years ago

Alarm stades described by @a-lurker seem to be correct, but on my EVO I never see state '1-Disarmed', only 'Ready to arm' and 'Not ready to arm' (the last is shown when one of the motion sensors is 'open')

For zone status, I only get 0 and 1, the sensor with 'low battery trouble' just reports 0/1.

larryl79 commented 7 years ago

My system when get armed after exit time countdown, I seen this message by script (may helps) I edited nothing yet on the script. this is a raw output just some dot lines deleted. I haven't got wireless devices

Larry = Username Building = Partition label

Attempting connection to MQTT Broker: 127.0.0.1:1883
1481738963: New connection from 127.0.0.1 on port 1883.
1481738963: New client connected from 127.0.0.1 as paho/0E81CF47655FD9F1FC (c1, k60).
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: '', 2: '', 3: '', 4: '', 5: '', 6: '', 7: '', 8: '\x14\x10\x0c\x0e\x12\t-\x05'}
Labels detected for wirelessSirenLabel:
{1: '', 2: '', 3: '', 4: ''}
Labels detected for siteNameLabel:
{1: ''}
Labels detected for partitionLabel:
{1: '', 2: ''}
Labels detected for wirelessRepeaterLabel:
{1: '', 2: ''}
Labels detected for outputLabel:
{1: '', 2: '', 3: '', 4: '', 5: '', 6: '', 7: '', 8: '', 9: '', 10: '', 11: '', 12: '', 13: '', 14: '', 15: '', 16: ''}
Labels detected for zoneLabel:
{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'}
Labels detected for userLabel:
{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: ''}
Labels detected for busModuleLabel:
{1: '', 2: '', 3: '', 4: '', 5: '', 6: '', 7: '', 8: '', 9: '', 10: '', 11: '', 12: '', 13: '', 14: '', 15: ''}
Listening for events...
.
Event:Bypass programming;SubEvent:
.
Event:Bypass programming;SubEvent:
.
Event:Bypass programming;SubEvent:
.
Event:Bypass programming;SubEvent:
.
Event:Bypass programming;SubEvent:
.
Multiple data: ['\xe0\xffWt\x14\x10\x0c\x0e\x12\r\x0c\x01\x04\x00\x00\x00\x00\x00\x04Buliding        \x00J\xe0\xffWu\x14\x10\x0c\x0e\x12\r\t\x01\x02\x00\x00\x00\x00\x00\x01                                                                 Larry           \x00\x7f', '\xe0\xffWs\x14\x10\x0c\x0e\x12\r\x04\x01\x03\x00\x00\x00\x00\x00\x04Buliding        \x00@']
Event:Bypass programming;SubEvent:
Event:Bypass programming;SubEvent:
.

if stay armed, and moving in a stay zone: Kitchen, Office (Z3,Z4), Warehouse (Z6), Upstair Corridor(Z5) is a Zone labels, strange thing is some zone names dosen't came trough.

Event:User code activated output (Partition 1);SubEvent:
.
Event:User code activated output (Partition 1);SubEvent:
.
Event:User code activated output (Partition 1);SubEvent:
.
Event:User code activated output (Partition 1);SubEvent:
.
Event:User code activated output (Partition 1);SubEvent:
.
Multiple data: ['\xe0\xffW\xc0\x14\x10\x0c\x0f\x01"\x01\x01\x04\x00\x00\x00\x00\x00\x02Kitchen         \x00F', '\xe0\xffW\xbf\x14\x10\x0c\x0f\x01"\x00\x01\x04\x00\x00\x00\x00\x00\x02Kitchen         \x00D']
Event:User code activated output (Partition 1);SubEvent:
Event:User code activated output (Partition 1);SubEvent:
.
Event:User code activated output (Partition 1);SubEvent:
.
Event:User code activated output (Partition 1);SubEvent:
.
Multiple data: ['\xe0\xffW\xc4\x14\x10\x0c\x0f\x01"\x00\x01\x04\x00\x00\x00\x00\x00\x02Kitchen         \x00I', '\xe0\xffW\xc3\x14\x10\x0c\x0f\x01"\x01\x01\x03\x00\x00\x00\x00\x00\x02Office          \x00\xee']
Event:User code activated output (Partition 1);SubEvent:
Event:User code activated output (Partition 1);SubEvent:
.
Multiple data: ['\xe0\xffW\xc6\x14\x10\x0c\x0f\x01"\x01\x01\x03\x00\x00\x00\x00\x00\x02Office          \x00\xf1', '\xe0\xffW\xc5\x14\x10\x0c\x0f\x01"\x00\x01\x03\x00\x00\x00\x00\x00\x02Office          \x00\xef']
.
Event:User code activated output (Partition 1);SubEvent:
.
Multiple data: ['\xe0\xffW\xd7\x14\x10\x0c\x0f\x01*\x00\x01\x07\x00\x00\x00\x00\x00\x02Warehouse       \x00\x14', '\xe0\xffW\xd6\x14\x10\x0c\x0f\x01*\x00\x01\x05\x00\x00\x00\x00\x00\x02Upstair Corridor\x00\xca']
Event:User code activated output (Partition 1);SubEvent:
Event:User code activated output (Partition 1);SubEvent:
.
rferenc commented 7 years ago

@Tertiush Very big thank you for this project and all of your efforts! Of course I had and EVO192, that's why I interested to include your code into my project. Did you had a chance to work on "v3" based on NodeJS what you mentioned?

@mnmn2 Can you please inform us if any progress do you have recently? Or can you share with me also your current code?

and finaly @andrasj If I'm guessing correctly we are from a same country :) maybe we can help each other?

Tertiush commented 7 years ago

Hi, unfortunately not yet. Life has become somewhat busy and I just haven't had the chance to finish it. It's still a very rough port of the Alarmin app's code and not yet in a running state. To be honest I probably won't get this done in the next few months. It's still something I want to complete as I also want to use it in that form, and decommission the other versions. So it will happen eventually.

rferenc commented 7 years ago

@Tertiush Any EVO specific code what you could share would be really appreciated!

From my perspective it can be Android, Python, NodeJS or any other language! :) My basic goal to "transfer" EVO events to MQ.

andrasj commented 7 years ago

@rferenc Sure we all can help each other. Even if you're not from Belgium ;-) Currently I'm busy too, but trying to reorganize to have more time for personal projects. If your goal is to publish your events to MQ, I can confirm that V1 (python) does work for EVO192. Just the translations of the error codes are not complete (but could be fixed with the descriptions of @a-lurker ) (I'm using it in openHAB through MQTT binding) However I agree, a more event driven solution would be preferred. (I think it is better to start describing the communication protocol, if that's clear, implementing will be easy)

Tertiush commented 7 years ago

The problem with the EVO code is that it's not the same as for the MG/SP series, specifically the initial connection/startup code. In my app I have a branch in said code that splits into either of the two depending on the alarm type. I will share this (below).

Regarding events (zone and alarm changes), the V1 code is the most stable and interoperable, with v2 adding PGM and bypass (also working for EVO in the Alarmin app). The fact that PGM and bypass only work in the Alarmin app is still odd to me, but as pointed out before when both connections (web & software) is made at the same time it just works..... So all in all, its just a matter of merging V1 and V2. V1 does statuses and V2 the PGM and bypass. There's not much more code that I can contribute other than everything rewritten in nodeJS.

Here's the MG/SP and EVO code that branches:

FigJam23 commented 7 years ago

Nice my Evo Alarm is now fully functional Arm Disarm all PIRs working Siren Exit delay and I've got 3 PGMS working all integrated into home Assistant Thanks for doing the ground work for this Took a lot of work for me to make it work for the EVO but couldn't comprehend the time the development took Thanks Guys

FigJam23 commented 7 years ago

This is some real basic vidoeo operations on my test rig alarm panel I made using the v1 code modified. These test videos are running on my EVO48 With no PGM control as it just using the web interface did have some luck firing the Ip150 PGM but was not stable.

https://youtu.be/S2BSCECVr4w

https://youtu.be/_1TH44O2LhY

https://youtu.be/9rvtPuZD-vs

I will do some videos of the v2 code with both EVO48 and the 192 using PGMs as there are some small differences I've found

juzzmoore commented 7 years ago

@mydakota, is there any chance you could share the modified v2 code you are using with V2? I'm desperate to get the same working and the latest firmware for the IP150 removes direct web control so V1 cannot work :-(

MorpheusRO commented 7 years ago

@Tertiush: Do you have any time-frame for the V3 script? I'm only asking because I want to integrate my EVO192 and if your script will be released in the foreseeable future, I'll stay away from reverse engineering and implement it for V2 :) Thanks for your hard work to these great scripts!

@mydakota: If you could share the V2 code you have, compatible with the EVO192, would be a lifesaver for me.

Tertiush commented 7 years ago

@MorpheusRO I'm afraid not. I really wish I had the time to work on it but its just not happening. If anyone want to do it please do. I will share whatever code is needed from the Alarmin app, just drop me a line. Sorry for this and taking so long to reply.

danbba1 commented 6 years ago

@mydakota: could you please share your v2 code modified for EVO192? Thanks.

jphenning commented 6 years ago

@mydakota Would you be able to share your v2 code for the EVO192? Thanks!

jphenning commented 6 years ago

I have two documents that could be worth while from both a SP/MG & EVO perspective. It seems Tertius' code using the serial communication protocol. I happened to track down two documents (the URLs are no longer active but I do have them on my computer) that documents both the SP/MG & EVO serial communication protocol. It seems Tertius' code typically has a Header and a Message. The Message part is documented in the documents I have, however the Header part isnt. I suspect the header part is something specific to the IP150 module. If anybody is interested in these documents let me know. Also if anybody has any idea on how the Header part works (starting with 0xAA and 16 bytes long) please let me know.

yozik04 commented 6 years ago

I am interested in all this stuff. I have EVO192. Can you upload it somewhere and share a link? Thank you.

jphenning commented 6 years ago

Sure thing: https://www.dropbox.com/sh/dztab03vwdmw8ya/AABNac4VglpRPQMMHVh5myCea?dl=0

Since Tertius' code mostly supports the SP/MG I used the document "SPXXXX-Serial-Port-Protocol.doc" to figure out what his code meant. I then look at the "EVO_UDSProtocol.pdf" to see how the EVO does it.

As mentioned previously this doesnt explain how the IP150 handles communication (the header part) but only the message part (part that follows the header). However I found it extremely useful. If we can figure out how the headers work for the IP150 i think the remaining info is all in the documents in the above URL.

FigJam23 commented 6 years ago

Hey guys just seen a few people wanting me to upload a copy of my v2 of the code I had working with my evo48 . Unfortunately after having multiple issues with the v2 being stable I moved back to the V1 code . The cloud drive I had my files on has died hopefully some good recovery software I’ll extract it. Basically what I did to get it working on the Evo 48 was using a combination of wireshark dumps and matching the differentials between the programming locations from the MG5050 and the evo48 . My v2 mods were far from perfect but the headers can be revealed using wireshark and disabling encryption on your winload software can’t rember how you do that but think there’s a unencrypted config.text file in winload

yozik04 commented 6 years ago

By the way. Did anybody managed to connect with this ParadoxIP150v2 to IP150 V4.10 internet module? Or it is dead end? I see that port 10000 does not respond to commands. Not sure if password is wrong or interface has changed.

ghost commented 6 years ago

To disable the encryption, change the IPEncrypted to False in the file COM.ini: C:\Program files\Paradox Security Systems\WinLoad\COM.ini

Has anyone tried decompiling WinLoad program ?

jphenning commented 6 years ago

All Paradox’s products appear to be done in Delphi, including Winload. In fact the file ParadoxNetwork.dll seems common accross Winload, Babyware, NEware and their API. But since its in Delphi you cant reverse engineer more than UIs. Ive started messing around with Winload and Wireshark. I noticed some small differences in the log in/initialization part so will give that a go to see if i can connect properly when altering the bytes.

jphenning commented 6 years ago

Does anybody on here have Paradox distributor access to their website? The documents "SPXXXX-Serial-Port-Protocol.doc" and "EVO_UDSProtocol.pdf" has been invaluable at understanding the communication protocol together with tracing the packets by Winload (and the awesome work Tertius has done with ParadoxIP150v2). I'm wondering if there isn't updated versions of these documents on Paradox's website. I initially found these documents on a local security company's website but they have subsequently disabled that access. I'm pretty sure they must have gotten those documents from Paradox's website using a distributor login.

jphenning commented 6 years ago

If anyone is struggling with memory map for the EVO192, i've started compiling some info on this. Not quite ready in a shareable format, but I have done some digging of my own to found out where most labels sit in the EVO192. Some info I pulled from the documentation I had on the EVO memory map, but some I found through my own discovery, e.g. the memory map I have of the EVO didnt show where the labels of zones 97-192 are. I wrote a small program that read the eeprom memory into a binary file and dug through it to find the location.

At this time I have the memory locations of Zone Labels, Area Labels, User Labels, Door Labels, Module Labels & Zone Definitions. I also have some info on the RAM of the EVO that stores the status of the system.

I'm still trying to figure out the keep alive sequence, but right now it seems it just reads the EVO RAM in a loop to get the system status. I'll share my findings once i have it in a nice document.

The Paradox documents I have is also not perfect. I discovered a bug in the EVO_UDSProtocol.pdf document with the 0x5x command (Upload/Read module's EEprom/RAM data). The documentation states that for reponses byte 2 is Bus Address & byte 3 is the control byte but it's actually the other way around. It's in the same order as the request bytes. Similarly I found bugs in their documentation that details how the user options are stored, all through self-discovery.

danbba1 commented 6 years ago

@jphenning Will you share the code for EVO192? Did you change paradoxmap.py file or the actual script? Your above description sounds promising.

zebulon30 commented 6 years ago

Hi all, I'm working on reverse engeeneriing the EVO192. You all use the IP150 but I'm communicating with the EVO192 through the serial port. I founded that 0x50 was for reading and 0x60 for writing. So it seems the hex code are the same using the IP150 or the serial port. I own a PCS250 that would never be able to send SMS and an IP150 that is sadly in v4.10 :-( and I don't want to buy the f..k..g android app. So, my goal is to make an arduino project that can send me SMS about the states of the EVO192 (arm, disarm, alarm, ...) I can make some test to help if you need. I know wireshark, serial port monitor and so on ... Thank you to jphenning for sharing the documentation that will greatly help me in my investigation. Sorry for my poor english. Hope you understand me. I stay on this thread ... See you soon.

yozik04 commented 6 years ago

@zebulon30 I exactly same situation as you. I planned to use some ESP to forward serial commands to my home server via UDP. Did not had time to start it yet.

zebulon30 commented 6 years ago

@yozik04 Thanks to you. Yes, I saw it, that's why I removed my question ;-) Sorry for the disturbance.

maragelis commented 6 years ago

@yozik04 I just completed a project using ESP paradox serial to mqtt works great check it out if you are interested. I am using it with node-red and getting every event on my home controller. https://github.com/maragelis/ParadoxRs232toMqtt

jphenning commented 6 years ago

@danbba1 I currently haven't touched the Python code that Tertius wrote. I'm actually attempting to write my own library in C# to communicate with the IP150 & EVO192 (similar to this project). My goal is to get away completely from using the Paradox supplied API as it's not updated often enough (there's a bug in the user updating functions that I need for a project I'm doing) and trying to get hold of people with knowledge about this API or at least to indicate when new versions are available has proven virtually impossible. My general sense from Paradox is a lack of interest, even from Paradox distributors.

Having said that I have gained some knowledge of the EVO's login sequence, the keep alive sequence, and a map for many labels. So if you get stuck somewhere send me a message and I'll see if I have possibly touched that area yet and have knowledge about it. I have Winload with software (similar to Wireshark) that I use to sniff the packets. Apologies if you thought I had updated the Python code. I'm more interested at present in knowledge sharing than getting the actual Python code to work (since my primary language is C#). However I dont think i'll struggling updating it, it just hasnt been a priority yet. :)

yozik04 commented 6 years ago

Winload does not work with latest firmware for IP150. Do you plan to interface the control panel via serial port?

jphenning commented 6 years ago

The IP150 I'm using isn't using the latest firmware, so I've not encountered that issue. I plan to only interact with the IP150 module. Odd that Winload doesnt support it. Maybe in an upcoming release? You sure you have the latest version of Winload (WL_571_05.exe)?

yozik04 commented 6 years ago

Only Babyware worked for me and that connects via swan or Site ID only. I think I've tried the last one.

The IP150 does not support local connection anymore from firmware 4.0 and on as I know...

zebulon30 commented 6 years ago

Hi all, I did some investigation on the serial port and it seems that the initialisation sent from the EVO192 to the PC differs from what is written in the PDF file DIGIPLEX NE UPLOAD/DOWNLOAD PROTOCOL. I use 'serial port monitor' to look at what is sent from the PC by babyware and what is reply by the EVO. At first, Babyware send : 72 00 00 00 ..... 00 00 00 72 (a total of 37 bytes) To witch the EVO reply : 00000000 72 ff 04 02 00 00 a1 5a 01 04 63 02 05 07 0d 35 00000016 00 10 01 00 0f 27 10 20 10 30 ff 57 45 56 4f 31 00000032 39 32 00 00 bd

05070D35 is the serial number of my EVO192 ( bytes 12-15 ) 04.63 is the version (bytes 9-10)

They are not at the same position as in the protocol description. The protocol says respectively bytes 17-20 for serial number and bytes 15-16 for the firmware build. And I don't understand the coding of bytes 21-35, but perhaps are they at a different place too ....

Has anybody some info about that ?

FigJam23 commented 6 years ago

The new FW version for the IP150 has been done to force you into a monthly subscription contract with Swann/Paradox this move by Paradox is a dirty move and if you have upgraded you can not roll back by memory as long as your FW is under version 4.0 you can upgrade downgrade use winload or what ever you like . I have had a few test rigs on one of them I ripped out my EVO 192 main board and replaced it with a arduino mega with network shield and 8 way relay card seemed more reliable and less resources hungry than the python method. And the best part is you can totally customise your alarm system to do what ever using HASS manual alarm or mqtt version

Sent from my iPhone

On 2 Feb 2018, at 2:04 am, jphenning notifications@github.com<mailto:notifications@github.com> wrote:

The IP150 I'm using isn't using the latest firmware, so I've not encountered that issue. I plan to only interact with the IP150 module. Odd that Winload doesnt support it. Maybe in an upcoming release? You sure you have the latest version of Winload (WL_571_05.exe)?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Tertiush/ParadoxIP150v2/issues/5#issuecomment-362312763, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AcB8Wl-DB0Cw1EHJ1lHBi6r8jKhmK2MYks5tQeB9gaJpZM4JpjXB.