Paradox EVO Binding

I was able to get your code to work on my IP150 module. I did the following:

  • Made sure byte 01 is the same as my password length
  • Set byte 04 to 0x08.
  • I disabled any encryption you attempted to do (that wont work)
  • The final packet I’m seding is this:
    byte[] packet = concatenateByteArrays(IpMessages.loginHeader, Arrays.copyOf(passwordAsBytes, 16));

Technically you should pad the remainder of the bytes in the password with 0xEE but it seems to work without that.

I received a property response.

Also - which version of the IP150 module?

1 Like

Hi,
the reason for difference in password length is that I didn’t want to expose my original password on the internet. :slight_smile:
Thanks for playing with it. I’ve started initially with all static call in one byte array, also filled the gaps with 0xEE as you mention in your document. It still replied with wrong password. Will send you the requests I send later today when I get home.
Evo192 v.4.63.2, IP150 v.3.0.1, hardware 0.20

Cheers,
K.

Ok that is weird. Yeah send me whatever you have. I’m happy to help.

I’m on EVO192 v3.20, IP150 v1.34 Hardware 0.20.

The EVO192 version doesnt matter for the IP150 login step 1. So the only difference I see is your IP150 version where yours is a lot newer than mine, however anything under version 4.00 should behave the same as mine where it does not use the SiteID but rather allows direct connections.

Hi Jean,

Forget about my problem. I’m an idiot. I cannot count to 10. My password length is 10 and I don’t know why I decided it’s 8.
Now all is good. I received proper response - 0x38 :slight_smile:
Encryption does not work with cipher. For now I will test everything without encryption and if need arises I will copy/paste the encrypt method from the python provided by Joao.

Thanks a lot for support and sorry for confusion !

Hi Jean,
so the first stage looks OK now with steps 1-3. Now Step4 refers to serial communication.
Does that mean that I need to switch to sheet “Serial protocol” and start sending in sequence top to bottom starting with filled up 37 bytes payload?
From what I see IDX 01-09 should be filled up from the response in step1, is that right?
I don’t get completely the IDX 10-11. This states it’s a PC password but PC password does not fit into 2 bytes. Do you have any advice here?

Thanks in advance,
K.

Um… nevermind. I’ve read the code shared by David. Seems to answer my questions.
Need to test it after work and see how to make it more user-friendly in Java. :slight_smile:

I updated my document (EVO_Technical_Info_v1_0_5.xlsx). It contains some updated info on how to identify a panel by using the FamilyID & ProductID returned by the (0x72 0xFF …) serial command. It allows you to identify most of the EVO, SP & MG panels.

I also added info on the IP150 message header byte 09. In requests this is the cryptor type.

Hi All,

I’ve read once again some of the postings here which lead me to Jean’s tester, written in C#. This code is far easier for me to understand and looking at it I think it’s doable to create a native OH binding for Evo192, even with my limited time (mostly couple of hours during the weekends and ocasional hours after work).

There are couple of topics I’d like to discuss before I start with the real binding and I need here your feedback:

  1. What features you would expect such binding to provide? My initial scope would be read-only mode to look the states of zones and partitions.
  2. The things modeling. From my current experience I would model the following things:
  • Panel (or IP150 in this case) which will be configurable with all input data from the user (panel codes, IP150 codes, IP address, refresh interval in seconds etc). This thing will update a runtime cache which will keep the runtime state of all other items. They will make refresh requests from this cache.
  • Partition - haven’t read the data yet but I would expect to have channels like State, last change time, user who triggerred the change. (maybe also last alarm?)
  • Zone - pretty much the same but with zones.
  • PGM - same as zones… we may decide to allow commands to PGM here so probably some of PGM channels may be of type switch/contact.

Other things which I consider now… Maybe it would be good to extract all static information like start/length of memory areas where items got stored into separate class/resource file so if anyone would like to adapt this for other Paradox system, can change only these parameters and not touch the overall binding code logic.

Cheers,
Konstantin

1 Like

It would be great! However I think which will make it more simple and easier to configure and use (besides the python scripts which are available now):

  • Not just read-only mode, but have the ability to configure such things through this binding. For example: override zones, trigger alarm modes (arm, stay, etc…), and maybe read the alarm memory (where alarms stored until you delete it from the panel).

@polychronov I have a massive set of static information regarding a variety of devices (MG/SP/EVO). Memory addresses, lengths, etc. I’d be happy to share that.

@Jean_Henning Please share! :slight_smile:

@polychronov I implemented the encryption method in python. Just convert/adapt the code: https://github.com/jpbarraca/pai/blob/master/paradox/lib/crypto.py

It works with firmware v3 and V4.

I’m busy putting them into a JSON format. As soon as I’m done I’ll share that.

1 Like

Hi guys,
to give you some update. I managed to code Jean’s tester into Java with few changes.
@Jean_Henning I’ve used pretty much the same method names and comments that you’ve had where applicable. Hope you don’t have anything against that plagiarism, since this is a heavy matter with all these hex values and stuff and would be easier to read probably also for you …
So far what I have is - still main method as standalone java application (not OH binding), which connects to IP150 and retrieves all partition labels, all zone labels and have preparation with method that reads RAM (the real states).
The goal for easier troubleshooting is to keep main method inside the code of the binding so you can do quicker debugging by executing in CLI instead of OpenHab but I’m not sure if I’ll be able to keep such promise.

Next to come is to read the RAM states of the entities and map them to human readable state.

Thanks in advance,
K.

I’m still working on the memory map… it’s taking a LOT of time, but i’m about 80% there. This would be for basically the majority of EEPROM addresses. Then we will have a very comprehensive map of how the EVO’s memory works. I’m not sure how many people want EVO support but I only have access to EVO. I do have info on the MG (think SP applies too) but require EVO to be finished first.

I plan to use your excel for the mapping.
Is what we have in RAM Map and RAM Map detail sheet correct and confirmed?

Cheers,
K.

For the RAM - Yes. For the EEPROM - The EEPROM Map is not that comprehensive. I have a MUCH more detailed map that i’m working on. But for the RAM yes you can use that. I dont know whether that has changed for the EVOHD or across versions. That’s the official Paradox EVO Map, but i’m sure it’s quite old. So you’ll have to do it by trial and error. I have no other source for the RAM info, however what’s there has worked for my EVO192 v3.20 so far.

Isn’t the focus the to get zones reporting state and arm/disarm state and control?

Pulling the labels seems to be standard across models. And from that most people only want all their zone names. But these also come out in events (motion etc). You only need the labels for the cyclical messages that come out (there’s 5 messages that come out on an so panel). With zone states, partition states and power states and a few other things.

Hi,
Focus is to get as much information as available from EPROM and RAM so we have in thing channels all the info out of the box. For events to be honest haven’t thought how to represent them in OH yet or also how to model them. Let’s do the initial implementation with only states and we can discuss further improvements.

How would you prefer to identify the zones in OH thing definitions?
By index or by label?
Not sure which one is more convenient…
Index should be very exact and has less chance to make error in identification but on the other hand I personally use labels for identification which is more human readable.

Cheers,
K.

I use labels personally. especially as I feed MQTT, so using label as part of the topic means there’s no translation needed for any messages to users. Or in the sitemap.

Dears,
I spent a couple of hours going through this thread and I’m still figuring out if I’m the right place, please be gentle

  • looking for a way to get status updates, possibly arm/disarm and communicate from off-prem to my home alarm system securely (so at least vpn/certificates); iOS/web browser access would be nice
  • will try to avoid proprietary/lock-in schemes requiring opening my firewall to the wide world
  • Paradox is a de facto monopolist where I come from, so I’m already stuck with a Magellan SP65
  • my disti offered an IP150 (communication via swan) and an ‘older’ IP150S when I requested an on-prem solution; I still didn’t get any of those
  • I have no experience with python, but this doesn’t scare me, done reasonably complex automation projects via i.e. nodered in the past
    Should I go with an IP150* and risk a software update to block all my efforts or is there any other vendor with a communication module out there that’s worth exploring?
    Thanks in advance