Thanks!
So what remains is to find out what firmware version of my SP65 has been verified to work with IP150S and to stick with it.
I’ll give it a try and post back.
Hi guys,
to give you another update I have finalized the initial scope of the standalone java application.
If anyone has evo192 or lower versions I would be very happy if you can test and provide feedback.
I have some concerns that currently I do not distinguish evo48, 96 and 192 and probably we can get some out of memory exceptions when reading the RAM but that has to be tested as I have only evo192 at home.
I will now start to move the code into openhab binding and hopefully will have initial version soon.
EVO and SP panels are not compatible. They use different memory layouts, different serial protocols, etc. I know people are eager to have their own panels working, but EVO and MG/SP are two completely different streams of development.
While the login/logout sequence to the IP150 is standard, as soon as you start issuing serial commands to the panel you’re already boxed into one type of panel.
Isn’t it possible to have a “modular” design that can be extended later on?
Meaning: Publish a v2 binding for Paradox Alarm systems that works with EVO at version 2.0 and extend its functionality to support MG/SP later on at version 2.1 ? (since as you say some of the code will be shared)
Id be happy to have a look at your code again. Regarding panel identification - There is a sheet in my Excel document on the EVO about “Panel Identification” that uses the 0x72 response’s ProductID and FamilyID. Unfortunately this only distinguishes between EVO48, EVO192 & EVOHD, however EVO96 & EVO192 is virtually the same in most aspects (zone count, partition count, module count, etc). I would use that panel identification method and use the response in command 0x00 as final way of identifying between EVO48 & EVO96. See “ProductID” in bytes 04 of the 0x00 reponse.
I’m working on a EEPROM map that does just that. It differentiates between EVO versions as later versions of EVO has more features. Ultimately this format can be used on the MG/SP too as I have the EEPROM map for those panels too. Since we have the serial commands for MG/SP we are sorted there too. The only thing that is lacking is MG/SP RAM map. But given the work done on MG/SP we might have success too.
Hi,
the code design is OOP which means that if someone owns MG/SP, and has basic Java knowledge, can get the binding/program and can implement his own calls to the alarm system.
I’ll try to do the coding as much generic as possible and will extract the common logic in absract class. What I designed so far is an interface, called IParadoxCommunicator which has the most common methods:
loginSequence()
logoutSequence()
refreshMemoryMap() - the idea is to keep the RAM map in local object cache and when doing parse of information from RAM, to use this object instead of doing calls to the alarm system everytime.
readPartitionFlags() - this reads partitions data from MemoryMap and provides them as byte arrays to the model.
readZoneFlags() - does the same but for zones.
This means that if someone wants to make support for MG/SP he needs to have the necessary memory model(for both EPROM and RAM) and implement the interface (or extend the abstract class with common logic for the IP150 that will probably come later on with some methods to be overriden for MG/SP).
The model has one object of type ParadoxSecuritySystem which has lists of zones and partitions. Currently when you pass byte array with zone or partition data to the Zone or Partition classes, they parse them to Java objects and will be able to provide them to the binding calls later on. That’s pretty much the design.
There is a pitfall I see here now when talking different paradox systems…probably the byte arrays will not be the same for Paradox and MG/SP which is a problem when parsing byte arrays directly in the model but worse case scenario we can extract this logic outside in another class or util so it can be implemented based on version of the alarm system.
What I have currently is still a very early development. Probably is full of bugs, not checked exceptions, not very clean design/code but I think it’s a good starting point for discussions and further development. If someone would like to review the code and give feedback I’ve pasted the github place in one of my comments above. If you can’t find it please let me know and I will reshare.
When I migrate this into binding the development will move to the repo of openhab.
One final but very important remark - this coudln’t be possible without the guys who did the initial reverse engineering of protocol - the guys who developed initially with python in the beginning of the thread and Jean with his wonderful excel sheet with all the data for the Evo so cudos and part of beer should go to these guys !
Hi Joao,
Here is the repo of my standalone application:
I’ve started to migrate it here as OH binding but there is no code populated yet. Only the binding skeleton.
having struggles to run as a standalone application because it cannot find the logger it seems…
Will open a new thread in dev community for this issue.
I have uploaded my first attempt at documenting the EVO memory map. This sheet will ultimately become a generic map for all products, so look for “Paradox Security Memory Maps.xlsx” in the root folder. I will also soon convert this to JSON and share some code on how I plan to use this in a generic way.
I have also uploaded the EVO EEPROM map as a JSON file.
WARNING:It goes without saying that you need to be careful with anything you write to the panels. Reading is fine, but exercise caution when writing values to your panel. If any address is wrong by any chance and you end up writing bad values to the panel you might end up corrupting data on the panel. Be careful with write operations!
Hi guys,
I think I can provide initial binding version with support of partition states so far. It’s completely read-only and can be used only on Evo systems.
Please use the ParadoxAlarm branch of my fork of openhab2-addons repo:
For easier consumption I have added in folder target the latest build of the addon itself.
Disclaimer: Probably it has a lot of bugs and code is not very clean but I think we can use it as a starting point to develop further. As a start would be nice if you can test on your own so I can be sure that I don’t have any hard-coded values somewhere inside the byte-code which I forgot to extract as parameters. I’ve given example things and items files in the README.md
just a quick update. I have also added support for zones in the binding so now you should be able to present your zones and partitions in OpenHab as items.
