Unfortunately the current implementation has no control over the PGMs. Essentially everything you see on the ip module’s web page is what I can get a hold of.
I’m still very busy with the software port implementation, with which I already can control the PGMs. The only downside is the sheer amount of reverse engineering of everything required. I’m also going to need some help testing as I don’t know what’s unique and what common between the different panel types (MG5050 / EVO / etc) regarding the protocol… If you keen to help out with this.
I’ve published a new version of the code that uses the software port. In addition to v1 of the script the new version supports just about all events the alarm can publish and can also control the PGMs. Currently the MG5050 V4 should work fine with it. The script is extendible to support other alarm type, see the intro-comment in the ParadoxMap.py file.
(I’ve also did a quick test with an EVOHD which unfortunately doesn’t use the same registry mappings as the MG5050. The event maps should however work just fine for basic things. Again support can always be added by someone that has such or another alarm model.)
Awesome! I’ve already taken a look. Right away I can say that the mapping don’t work for the Evo192 panel. Not surprised I guess. The login was successful though, just none of the mappings were correct and when it started polling for events nothing was registered. Looks like I’ll have to break out wireshark.
In the interim you can disable the updating of labels in the config file. They will then have generic names (up to 32 as for MG5050). Or, change the MQTT messages to publish numeric values rather than names ones, so the script is less reliant on the dictionary (also in config file). Would like to know if this gets you going somewhat, knowing though that no controls will likely work until the correct registers are referenced.
On PEP-8: Lol, no I’m more of a utilitarian; so get it to work then make it work better. Had to google what PEP-8 is and kinda like it. (I’m not a programmer by day-job, but do enjoy some coding in my spare time.)
I must admit I still plan to clean up the code and add comments for others to know what’s going on, might as well fix the layout also. Out of curiosity is all the labels updating correctly and the alarms outputs and PGMs working? The MG and SP series share a manual to I suspect that why its also working for you.
Tracstarr, if you set the debug mode to 2 you should see the raw data. Trigger some zones and see if you get anything. If you post the result here or pm me I will have a look.
I found I couldn’t get any result appearing in OpenHab with the topic path: Paradox/Events. Once I changed it to Paradox/Evnts I started getting data in OpenHab.
Yes. That’s where I changed the topic name. Once I made change data came through to OpenHab. I plan to do some more testing with the default topic and just confirm what I am seeing because it really surprised me.
On a side note I made a small change yesterday to control the alarm based on the MQTT payload, rather than topic name. The former still works though. This allows for better openhab integration by using a single item with Selections in your sitemap (using it in rotini now with a scene widget).
Thanks for your nice script. I was able to make this working… and I’m a newbie
I connected my alarm system.
I’ m able to Arm / Disarm without problem.
My system is a SP6000 with IP150 module.
There is the 2 thing I need help with;
I would like to have the status of the Alarm system. I copied the following string
String Alarm_State “House Status [%s]” {mqtt="<[mymosquitto:Paradox/AS/P1:state:default]"}
But it do not working…
the toggle switch not showing the real state of the alarm system. Is persistence have something to do with this?
For example, the light bulb (in the app) still on if I disarm using the KeyPad.
Regarding your first question, the item you defined looks fine to me. I’d suggest you connect to your MQTT broker with another tool where you can subscribe to the topic and ensure the reply is actually sent. If it is then the problem is likely somewhere in your openhab setup.
On your 2nd question, how is the toggle switch defined, using regex to change to on/off based on the string reply?
Sorry I can’t be of any more help right now; my setup has been running without issues for quite some time so I kinda forgot how it’s all stitched together…
I thought I had more, but apparently I’m still using my old solution (which I still need to port over to use the new script). Perhaps cross-check again your config with the item definitions earlier in this thread, mkent shared all his.
This approach ends up getting all the zone messages for an item.
The downside it doesn’t work well as just a sensor (Open/Closed). I am figuring I will create a new map and maybe a duplicate set of items to try and get a item that is just a binary (open/closed).
This is the idea: String Sensor_Door_Front "Front Door [MAP(ip150-zone-contact.map):%s]" (gAlarm,gAlarmDoor) {mqtt="<[mqtt-pi75:Paradox/Events:state:REGEX(.*\\:(.*);.*):.*SubEvent.Zone 1]"}
The map would then be simplified to: Zone\ OK=CLOSED Zone\ open=OPEN
I think for this to work I need to work on the filtering of the messages to just take the message for
Event:Zone OK:SubEvent: Zone 1 or Event:Zone open:SubEvent: Zone 1.
@speedmax: Looked at bit more closely at your question, I realized I didn’t really address your issue - Sorry. I haven’t looked at arming and disarming yet. I’ll still leave my notes, in case it helps someone else.
great initiative.
Is there perhaps a step-by-step tutorial available to configure OpenHab with the Paradox binding?
I’m running OpenHab on a Rasperry Pi.
PEP-8 is something that you don’t like or you are not a Python guy:)