Currently I’ve limited the code to only Evo systems so we do not break something with others … thus it will not work.
If you’re really interested to test that, I can add SP7000 as supported but as per other guys responses it should not work (aside from the initial logon procedure and gathering system type, versions, etc).
1 Like
Yeah I second that 
I know people are desperate to get their own panels working, but I think we have to say this one last time:
While the login procedure to the IP150 seems similar for the most part between MG/SP & EVO, anything after that login process is different. Memory maps, serial protocols, etc, etc. The EVO & MG/SP share virtually nothing in common coding/programming wise. Unless someone has specifically coded to support both panels, testing EVO code on MG/SP and visa versa is pointless. They are not compatible. Open the serial protocol for MG/SP (I’ve uploaded that a while back) and start coding 
1 Like
will do 
By the way: Maybe it’s better for you guys to open up a new thread and focus on the EVO Binding integration to avoid extra noise. We can move selected posts from here to that new thread with the help of a mod.
Yeah agreed - I think this thread has been taken over by us newcomers and I dont think it was initially meant for EVO 
1 Like
Hi,
I think as we have now layed down the “binding framework” for it we can use same binding for all types, no?
For the binding to work I expect the model to be filled with the correct object-represented data (not byte code) and if anyone is interested to develop “connector” to SP/MG I’m willing to help identifying the necessary tasks to be included in the same code base.
I have more features to add meanwhile though…
- Suppport for external commands (reset/login/logout for the connector, arm, forced arm, etc for the panel)
- Auto logout/login detection
- Extending the model and maybe extracting the login procedure so we can use factory to create objects based on the initial logon finding, i.e. if I detect Evo I should create Evo-class objects everywhere.
- Support for doors - not sure how these should be modelled as I have none at home. (of course I have doors but they’re not in the paradox system :D)
- Probably would be best to develop the communication part as a bridge and not a thing. Need to see how this is done in OH.
Cheers,
K.
Hi all,
to give you some update … I have implemented the following:
-
Extracted the communication in a bridge and now all other things are dependent on the IP150 bridge.
-
Implemented sample commands for the communication bridge - LOGIN, LOGOUT, RESET. They allow you to temporarily stop the communication to the Paradox system so you can logon with babyware or other tool without disabling the whole binding.
-
Implemented auto-detection during login procedure and extracted the communicator creation in factory so if we create more implementations for other panels only an interface has to be implemented and factory will be able to provide different implementations for the different panel types with the same backend logic.
-
Changed the README.md to reflect the changes
Just wonder if anyone has tested the binding and if this binding is of anyone’s interest still?
Cheers,
K.
Hi !
I have done some tests using Paradox SDK. I created a .net Core project with a wrapper to access Paradox API but my problem is that the compiled Paradox Api is 32 bits so it works well on my WIndows 10 devlopment device if I use .Net Core x86 for Windows but there is no x86 version of dotnet core for linux (and my server is on ubuntu).
Is there a 64 bits version of Paradox SDK ?
Thanks !
Hey Jean (@Jean_Henning),
As I’d like to start implementing some more commands just wondered if you have any success in understanding the commands process?
If so can you point me to the right place in the excel with the protocol dump so I can do some tests with it?
Mostly interested in
- changing the PGM states
- Activating Armed state on partitions / the whole system
As per our discussion you’ve said that I need to do some keep-alive in order not the connection to time-out. What I do so far and runs smooth is to check RAM state (read the whole RAM in my communicator cache) each 5 seconds. This ensures up2date info and also it seems that it works like a keep-alive. Do you think this is OK approach?
Thanks in advance,
Konstantin
Hey there,
I have not yet played around with arming, but looking at the protocol this should be command 0x40 in my spreadsheet. For PGM state changes this seems to be command 0xAx. Check the “General command sub command: PGM override”. Unfortunately it doesnt seem to be documented well in the original documentation, so you’ll have to play around with these commands to see what works. If you do find anything that works please let me know so that I can update my document.
From what I can see you would need to specify the PGM status commands (01-04) for the corresponding PGM. There are four commands from the document:
0: No change on PGM
01: Override PGM OFF
02: Override PGM ON
03: Release PGM OFF
04: Release PGM ON (my spreadsheet has a typo, it is missing the “ON”)
However I dont know what the difference between override and release is. Let me know your findings!
Regards,
Jean
As far as I know there isn’t a 64 bit version. I have focused my energy on trying to create my own API using raw TCP commands (with some good success so far) due to the lack of support on the Paradox SDK. However I’ve taken a break from this as I’m currently on vacation.
Hi,
you also mentioned that you use a lot of doors in your Evo192 at work.
How should the doors be modelled in this case?
What is the difference between door and zone?
Cheers,
K.
Hey there,
Basically a door is an access control module where you typically have some access card to open it. In our case we have two access control modules per physical door, e.g:
Door 1: Main office door OUTSIDE
Door 2: Main office door INSIDE
Door 3: Secondary office door OUTSIDE
Door 4: Secondary office door INSIDE
etc.
So basically at a physical door we’d have two access control modules so that you have a tagging system inside and outside the door for entry and exit. We record employees’ entry and exit times.
I would recommend you play around with the Doors section in Babyware to get a feel for what they are and what they can accomplish. But the simplest would be to see a door as a single access control unit and I think Babyware refers to the tags/cards that you use to swipe at the door unit as an “Access Card”. You can program an access card per user in the system and they can do a variety of things, including automatically disarming the alarm once the card is swiped. I think for your purpose you probably just need the labels for doors to identify them and then the normal buffered events in the system (or live events) will show you when a door is accessed. You will also often see more than one event logged per user when the user accesses a door. I’m not always sure why that is, but I have seen those.
Regards,
Jean
Can you share me a JAR file what I can copy into the addon folder and try this binding? I’m still struggle with config eclipse and create the JAR file.
Hi,
Sure. Of course…
It is posted on my github repo under target folder of the branch ParadoxAlarm. You can find it here:
https://github.com/theater/openhab2-addons/tree/ParadoxAlarm/addons/binding/org.openhab.binding.paradoxalarm/target
Cheers,
K.
1 Like
Many thanks. I will try and let you know the result or if I face to any set up problem.
Finally I was able to set up the binding and all zones are working now. I will check how can I change status etc. in rules. But I was not able to configure things and bridge through config files, and items had to be set up through config files.
In your example in Github the Bridge word is missing from the very beginning. 2nd, 3rd and 4th lines are confusing. I don’t understand thing: “Panel Panel”. in 3rd and 4th lines syntax of Partition is different. In the Cahnnels of the Zones: Type is boolean but is should be Contact. So that’s why Items are configured manually where I changed it to Contact. This is a kind of workaround but it works. This is where I am with the configuartion. So in summary this binding works well but there are several small things needs to be corrected than it will wok smoothly in my oppinion.
Hi,
Thanks for testing !
Your feedback is the first I got for the binding and I very, very highly appreciate it.
I will give examples based on latest build that you have bellow. Probably missed to fix the README. It made me crazy while attempting to format it properly. 
Very sorry about the confusion !
Before the examples I just want to clarify your feedback about the zones state type. I will change the states type to “contact” but I do not understand about the manual configuration.
Do you mean that you can skip creation of items if the type is proper or just that you will not type explicit type? Sorry if it’s a dumb question. My understanding is that each thing channel should have related item for it. Maybe I misunderstood the architecture…
About Panel type - this is the general type which represents different information related to the panel itself, i.e. type, serial number, different firmware versions.
Please let me know if this explains the meaning. Here the examples.
Example things file:
Bridge paradoxalarm:ip150:ip150 [refresh=5, panelType=“EVO192”, ip150Password=“asdfasdf”, pcPassword=“1234”, ipAddress=“192.168.100.100”, port=10000 ] {
Thing panel panel
Thing partition partition1 [id=1]
Thing partition partition2 [id=2]
Thing partition partition3 [id=3]
Thing partition partition4 [id=4]
Thing zone CorridorFl1_PIR [id=1]
Thing zone CorridorFl1_MUC [id=2]
Thing zone LivingRoom_PIR [id=3]
Thing zone LivingRoomWindow1_MUC [id=4]
…
}
Example items file:
//Groups
Group Paradox “Paradox security group”
Group Partitions “Paradox partitions” (Paradox)
Group Floor1MUC “Magnetic sensors - Floor 1” (Paradox)
Group PIRSensors “Motion sensors” (Paradox)
//COMMUNICATOR BRIDGE
String paradoxSendCommand “Send command to IP150” {channel=“paradoxalarm:ip150:ip150:communicationCommand”}
//PANEL
String panelState “Paradox panel state: [%s]” (Paradox) { channel = “paradoxalarm:panel:ip150:panel:state” }
String panelType “Paradox panel type: [%s]” (Paradox) { channel = “paradoxalarm:panel:ip150:panel:panelType” }
String serialNumber “Paradox Serial number: [%s]” (Paradox) { channel = “paradoxalarm:panel:ip150:panel:serialNumber” }
String hardwareVersion “Paradox HW version: [%s]” (Paradox) { channel = “paradoxalarm:panel:ip150:panel:hardwareVersion” }
String applicationVersion “Paradox Application version: [%s]” (Paradox) { channel = “paradoxalarm:panel:ip150:panel:applicationVersion” }
String bootloaderVersion “Paradox Bootloader version: [%s]” (Paradox) { channel = “paradoxalarm:panel:ip150:panel:bootloaderVersion” }
//PARTITIONS
String partition1State “Magnetic sensors - Floor 1: [%s]” (Partitions) { channel = “paradoxalarm:partition:ip150:partition1:state” }
String partition1AdditionalStates “Floor1 MUC additional states: [%s]” (Partitions) { channel = “paradoxalarm:partition:ip150:partition1:additionalStates” }
//ZONES
Contact CorridorFl1_PIR_state “Corridor Fl1 motion: [%s]” (PIRSensors) { channel = “paradoxalarm:zone:ip150:CorridorFl1_PIR:isOpened” }
Contact CorridorFl1_MUC_state “Corridor Fl1 window: [%s]” (Floor1MUC) { channel = “paradoxalarm:zone:ip150:CorridorFl1_MUC:isOpened” }
Sitemap:
Text label=“Security” icon=“lock”{
Frame label=“Panel”{
Text item=panelState valuecolor=[panelState==“Online”=“green”, panelState==“Offline”=“red”]
Text item=panelType
Text item=serialNumber
Text item=hardwareVersion
Text item=applicationVersion
Text item=bootloaderVersion
}
Frame label=“IP150 communication” {
Switch item=paradoxSendCommand mappings=[“LOGOUT”=“Logout”, “LOGIN”=“Login”, “RESET”=“Reset”]
}
Frame label=“Partitions” {
Text item=partition1State valuecolor=[partition1State==“Disarmed”=“green”, partition1State==“Armed”=“red”]
Text item=partition1AdditionalStates valuecolor=[partition1AdditionalStates==“Disarmed”=“green”, partition1AdditionalStates==“Armed”=“red”]
Text item=partition2State valuecolor=[partition2State==“Disarmed”=“green”, partition2State==“Armed”=“red”]
Text item=partition2AdditionalStates valuecolor=[partition2AdditionalStates==“Disarmed”=“green”, partition2AdditionalStates==“Armed”=“red”]
Text item=partition3State valuecolor=[partition3State==“Disarmed”=“green”, partition3State==“Armed”=“red”]
Text item=partition3AdditionalStates valuecolor=[partition3AdditionalStates==“Disarmed”=“green”, partition3AdditionalStates==“Armed”=“red”]
Text item=partition4State valuecolor=[partition4State==“Disarmed”=“green”, partition4State==“Armed”=“red”]
Text item=partition4AdditionalStates valuecolor=[partition4AdditionalStates==“Disarmed”=“green”, partition4AdditionalStates==“Armed”=“red”]
}
Frame label=“Zones” {
Group item=Floor1MUC
Group item=Floor2MUC
Group item=Floor3MUC
Group item=PIRSensors
}
}
} Text label=“Security” icon=“lock”{
Frame label=“Panel”{
Text item=panelState valuecolor=[panelState==“Online”=“green”, panelState==“Offline”=“red”]
Text item=panelType
Text item=serialNumber
Text item=hardwareVersion
Text item=applicationVersion
Text item=bootloaderVersion
}
Frame label=“IP150 communication” {
Switch item=paradoxSendCommand mappings=[“LOGOUT”=“Logout”, “LOGIN”=“Login”, “RESET”=“Reset”]
}
Frame label=“Partitions” {
Text item=partition1State valuecolor=[partition1State==“Disarmed”=“green”, partition1State==“Armed”=“red”]
Text item=partition1AdditionalStates valuecolor=[partition1AdditionalStates==“Disarmed”=“green”, partition1AdditionalStates==“Armed”=“red”]
Text item=partition2State valuecolor=[partition2State==“Disarmed”=“green”, partition2State==“Armed”=“red”]
Text item=partition2AdditionalStates valuecolor=[partition2AdditionalStates==“Disarmed”=“green”, partition2AdditionalStates==“Armed”=“red”]
Text item=partition3State valuecolor=[partition3State==“Disarmed”=“green”, partition3State==“Armed”=“red”]
Text item=partition3AdditionalStates valuecolor=[partition3AdditionalStates==“Disarmed”=“green”, partition3AdditionalStates==“Armed”=“red”]
Text item=partition4State valuecolor=[partition4State==“Disarmed”=“green”, partition4State==“Armed”=“red”]
Text item=partition4AdditionalStates valuecolor=[partition4AdditionalStates==“Disarmed”=“green”, partition4AdditionalStates==“Armed”=“red”]
}
Frame label=“Zones” {
Group item=Floor1MUC
Group item=Floor2MUC
Group item=Floor3MUC
Group item=PIRSensors
}
}
}
One more thing I forgot to mention. Please be advised that currently the communicator automatically detects the panel type and only if cannot detect it, it falls back to what is in the configuration of the bridge in panelType=“EVO192”.
Probably it would be wise to get rid of this parameter for good but I still keep it just in case…
1 Like
Many thanks for your reply. I configured the Bridge and partitions through PaperUI. I made items file for the items and that way I could manually set up the contact instead of boolean. You can not set items through PaperUI as it does not allow to correct the boolean to Contact. I will try to make full file configuration again based on this information. Also I have started to find more information about IP150 communication protocol that we have set up for arming and unarming through rule files. I hope that I will be successful. Will see.
The file based config works now completely based on that. Many thanks. I keep you posted with my set up.