I’m playing arounf a little bit with this interface:
It seems to be able to send commands for arming/disarming as well so we could probably try to “be inspired” by this code or seek some advices from authors. It was developed starting from jpbarraca work (who owns an SP panel I think) and integrated to communicate to EVO as well.
Up to now I was able to have it connecting and reading my panel/partition/zones and sends status updates on Mosquito, so now I want to send a command to see if it can ARM the system, in case of success I will try to understand what they do and report.
Not sure this is gonna be quick, I’m not a programmer I just wrote few lines of basic in my life so all this is a little bit complicated!
PAI works with EVO, MG and SP, allowing a wide set of actions (including arm/disarm). You can install the software and use the MQTT interface to control the panel and to receive updates about all properties. If you enable debug, all message payloads can be logged for further analysis.
I’ve uploaded the API that I have here: https://files.fm/f/4v5zmnug
Not sure how safe this place is. Hope they do not touch the original .rar I’ve made…
From what I see it will be deleted January 2020.
Hello Joao,
Thanks for the link. I’ve looked at the parsers and I think I’ve got the main idea but I will need to make much more thorough investigation before I start any development in Java.
I wonder if you guys ever had any attempts/success in reverse engineering the IP receiver packets? The service where you configure your paradox to send events to an IP receiver which is somewhere else. What I currently do in the openhab binding is to poll on every 3-5-etc seconds the state of Paradox RAM and based on the memory map that Jean provided I parse the results.
Probably it would be even better if Paradox posts states to such a binding and the binding only listens for such packets. Then we will have an on-demand listener which will respond to certain events which will be more intelligent approach.
Of course if we want to have active communication (i.e. partition arming/disarming) we will need the other approach as well.
Hi,
I’m not sure what is STUN access.
In my Paradox settings, in Babyware there is a section where you can define “IP receiver”. The security company that I use has such a server which listens for live events from Paradox. From what I understand the Paradox sends events to the receiver which have more context than the regular radio events that they have. What I guess is that these are just a regular IP packets but reverse engineering such stuff is not my best skill.
I guess this functionality is closely coupled to IP150 interface in Paradox because you should not be able to do it via serial or some other way…
PAI supports 3 methods: Serial Port, Direct IP connection to the IP150, and Indirect connection through the Paradox servers (the STUN method using a SiteID). It’s this last one? is there another one?
Hi,
I think it’s another one. Maybe this stuff here: https://www.paradox.com/Products/default.asp?PID=423
I guess that’s an option for security service providers. This is used from the service provider I pay for. I own my security system and I administer it but I connect it to their receivers in order they to be able to receive and react on events from my system. Additionally they use a radio module which provides them basic information (in alarm, trouble, etc)
Does that make any sense? I guess sooner or later this kind of devices may get deprecated in favour of their cloud service…
Hi Istvan,
I remember you’ve had a feature request in mind related to limiting zones that are to be retrieved from the system. Can you elaborate the feature?
How I see it we implement additional configuration values - maxZones, maxPartitions and we will read the information from 1 to maxZones and maxPartitions. Is that what you mean?
For example if you have configured zone 50-90 you will not be able to provide starting zone. (not sure if that’s really an option in Paradox systems)
Does that make sense to have also startingZone, startingPartition?
Hi Konstantin,
Openhab works for family homes 99,9% I think. I want to say with that average home installations consists of a few door sensors, motion sensors etc. Usually they are programmed from 1 to 20-50 zones max. If we are able to limit maximum range from 0 is far enough. I would not complicate it more as comparing benefit and difficulty of modification it does not worth. When you will enable a range limitation e.g. 5 to 15 what if somebody has two ranges and next one goes from 100 to 140. It never ends. I think when somebody wants to use this binding he can make the compromise to start it from 1 and he can make a setpoint of maximum zone. Many thanks Istvan
I have my Paradox with latest firmware:
EVO192 256K 7.11.006
IP150 4.42.002
This version of IP150 firmware allow you to connect from in-Field using direct connect (this function was removed in previous firmware). but to connect I need to provide also panel ID. in your plugin i can’t setup panel ID, as result I can’t connect.
Hi,
sorry for the delay but I had too much other stuff recently.
I never used in-field, I use babyware. As far as I remember there is no such need there. Have you tried it?
Please check the very first post here. Can you enable debug as mentioned there and try without panel ID and provide me the logs so I can verify what happens with this firmware version. If direct connect is indeed possible, maybe it worths to try to adapt the binding for this latest version…
Hello,
Hex stream sniffing from openhab to paradox and back (login error):
to IP150: aa07000308f0000aeeeeeeeeeeeeeeee70617261646f78
from IP150 aa1b000128f0000003eeeeeeeeee990d0036313234453537333534423438303635002004427104f7e16ca9
hex stream sniffing from babyware to paradox (successful):
to IP150: aa07000309f000000001eeeeeeee2e0c3a62e8127909db980f51850ace578683
from IP150: aa1b000129f0000003eeeeeeeeee93152a73a337db1a4bf316268975f84240e37a3e513591e939be23a853d09356f95b
Maybe thats helps, and possible you can have new version of plugin for last firmware.
hm… OK. It looks like they have changed a lot
I have no idea what to change but we may need different communicator for newer firmwares if someone is able to parse the protocol.
Edvard I see you have some sniffing skills, do you have also programming knowledge? Maybe I can help you to build something on top of my implementation for 4.x firmware?
Hi Istvan,
I’ve implemented two new parameters maxZones and maxPartitions.
New binary uploaded on the binaries github.
I’ve tested it and it works fine for my system. I don’t expect to have any issues but whenever possible please test as well before I open a PR.
PR will make it probably in 2.6.x milestones as 2.5 is closed for new functionality and only major bugs are allowed.
Yes, I have programming skills in 1988 I start with Cobol a& Fortran 77 :smiley, then switch to assembler. I have access to Paradox support, and can share with firmware. (mine is newest)
