Paradox EVO Binding

So you used empty pcPassword in EVO and this was the reason? I guess we need to document this if this is the case…

I tried empty and my panel password. It was same error. I did not know that there can be other password :)). It is working with y IP100.

Would be good document it or some error message about bad password :slight_smile:

Quick question, does this binding allow zone breaches to be sent to OpenHab Items with ON/OFF so that I can signal lights coming on if something in a monitored zone is detected when the alarm is armed?

Ie: is this two way

Zone open/close state is independent from partiton state armed/disarmed/alarm etc. So besides alarm warning you’ll receive witch Zone is closed.

Hi,
kovascsi pretty much answered the question. You have to have something in mind in front though… the binding polls for status the paradox alarm system with fixed intervals… that means that we do not receive a message but rather rely to “read” the event when the time comes.
If you plan to fire up lights when alarm is triggered, you can do so with rule coding but if you plan to make use of your PIR sensors to light your corridors for example, that will not be very handy as there will be substantial delay.
The other thing which is currently missing and I would like to improve but as usual no time for it and was not thought at all how to implement is, the relation between partition channel (which is item in OH) and zone channel (which is also item in OH). If we have the possibility to create relations between items or channels we may say “when an event ‘in alarm’ comes for partition X, give me all zones which are inside partition X and fire up the lights linked to zoneX, zoneY, zoneZ (or any open zone inside the alarming partition)”.
At least that’s how I imagine it but I don’t know if OH framework allows us to do something like this… Maybe core developers can give some hint here… I was thinking about a feature request to be able to configure relations between items in some way inside the configuration.

Cheers,
Konstantin

Thanks.

There wont be a delay if the PIR sensors are ZWave based, as OH will signal them immediately.

Sounds like it will indeed do what I want.

I’m not aware of Zwave PIR sensors supported by Paradox Evo systems but maybe there are. I just use much older system…

Hi everybody,
is there anyone who is using productively now the new OH3 milestone releases?
Is there a need for a migration plan for the configuration of Paradox binding?

Cheers,
Konstantin

Hello, Your binding works in OH3. I’m doing regular trials. As I use Jython helper libraries and it is not working I can’t try full functionality of OH3, but things and items are online. Binding starts etc. If you wish I can make a trace log about it over the weekend. Cheers Istvan

@polychronov
Hello Konstantin,
I am still unable to connect to my IP150. Yesterday, I stumbled on the following document in which it is mentioned that : “From what I understand, once you register your alarm on the paradoxmyhome.com website, you will loose local access to the Paradox IP150 over the LAN.”

Thus far, I have been using the “Insite Gold” app to access my panel remotely. Within the IP150, the “SWAN server” was enabled. I was hoping that this would explain why I was having a connection problem. In order to verify that, I turned off the SWAN server option in the IP150. This had the effect of block remote access to my panel through the Insite Gold app. Unfortunately, this did not appear to correct the communication problem I am experiencing with IP150 paradox.log (346.8 KB) on my local network.

I am attaching a fresh log, and your observation that the bridge is receiving unexpectd 64-byte packets in steps 6 and 7 appears to be still valid.

Do you think that some other people (João Paulo Barraca? Jean Henning?) could be able to help me?

Many thanks in advance,

Pierre

Hi,
There were certain 4.x firmwares that do not support direct communication.

I’m personally using the old firmware but some people were updating to the latest version and it’s working fine for them.

I believe in the very latest versions the system is supporting both methods.

Cheers,
K.

Hi,

Thanks for your response. The latest version is apparently 5.02.19. I will try to get a firmware update.

Cheers.

Hello, I use this one:


I had to ask Paradox service to do the upgrade. It was not succesfull at home. Success depending on several things. It works both OH3 + Paradox binding and communicate through Paradox cloud as well.

Some progress here. My IP150 firmware was updated this morning. Curent version is as shown here:

After the update, I checked that I could log on the IP150 Web page, which (as in the previous version) is only asking for my pin code:

IP150-login-page

As the login did work, I thought it was time to try my openhab paradox binding again. Upon starting openhab, I found that it was indeed working: no more error messages in the openhab log and my paradox things were reported to be online. I also confirmed that the paradox elements on the sitemap were working. Great!

Things did look fine for a while, but unfortunately my paradox things soon went offline without being asked to. What I found is that my paradox communication only works in the following circumstance:

  1. Before starting openhab, I have logged in on the ip150 by entering my pin code on its web page.
  2. I have not yet been inactive on that page for more than a couple of minutes, because then I get automatically logged out and openhab communication stops working.

Moreover, if I try to start openhab, before I login on the IP150 Web page, that login is getting bloceked and the following message gets posted on the login page: “Software currently connected - Please wait while requesting your connection to the software”.

Thus, it looks as if there is still one obstacle in the way before I can enjoy the benefits of the paradox binding. I hope someone can help me get over it. Thanks in advance.

I can not helop in connection issues. But one thing is important. If you log in to IP150 through the browser Openhab cannot connect as IP150 handles only one login and both uses same interface. Paradox Mobileapp Insight works paralel as it connect in a different route. So this behaviour is natural. Connecting your zones and loosing connection without you logged in is a problem, but it is not clear from your description. Binding uses the same login creditentals what you need to log in the web interface. So if you can’t log in there can be problem with the settings. You can fix it through InField application or direct on your board.

Thanks for your response, but your statement that “if you log in to IP150 through the browser Openhab cannot connect” is at odds with the experience that I reported in my previous message. The fact is that in the present state, Openhab can connect with the IP150 IF AND ONLY IF I am connected to the IP150 with my browser.

Note that there must be differences between the way the browser and OH connect to IP150: the web interface requests my pin code but not the ip150 password (see picture in my previous post), while OH does the opposite (I don’t see any way to provide a pin code through the OH interface). One possible rationalization of that situation would be that in the current state of my IP150/EVO 192, both the pin code and the paradox password are needed for a successful OH connection. The browser login provides the PiN code and OH the IP150 password. Does that make sense?

Hello,
I have installed EVO binding on OH3 but it periodically stops poling. All zones and the bridge are always online, only data is not updated. Last time the binding worked about 12 hours and then stopped. In the OH log I see:

[WARN ] [ommon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.IllegalArgumentException: 22 > 18
        at java.util.Arrays.copyOfRange(Arrays.java:4029) ~[?:?]
        at org.openhab.binding.paradoxalarm.internal.communication.Response.parsePacket(Response.java:110) ~[?:?]
        at org.openhab.binding.paradoxalarm.internal.communication.Response.<init>(Response.java:44) ~[?:?]
        at org.openhab.binding.paradoxalarm.internal.communication.AbstractCommunicator.receivePacket(AbstractCommunicator.java:144) ~[?:?]
        at org.openhab.binding.paradoxalarm.internal.communication.AbstractCommunicator.communicateToParadox(AbstractCommunicator.java:103) ~[?:?]
        at org.openhab.binding.paradoxalarm.internal.communication.AbstractCommunicator.communicateToParadox(AbstractCommunicator.java:110) ~[?:?]
        at org.openhab.binding.paradoxalarm.internal.communication.AbstractCommunicator.submitRequest(AbstractCommunicator.java:96) ~[?:?]
        at org.openhab.binding.paradoxalarm.internal.communication.EvoCommunicator.submitRamRequest(EvoCommunicator.java:246) ~[?:?]
        at org.openhab.binding.paradoxalarm.internal.communication.EvoCommunicator.refreshMemoryMap(EvoCommunicator.java:235) ~[?:?]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) ~[?:?]
        at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) ~[?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) ~[?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
        at java.lang.Thread.run(Thread.java:834) [?:?]

At the moment I have configured only zones and date polling. I also have old IP150 fw version (1.40). Should I stay with the old version or is it better to upgrade to verion 4?

Update: PROBLEM RESOLVED!

It turns out that my installer had provided me with an incorrect pcpassword! With version 5.02.09 and the corrected pcpassword, my paradox binding is now working fine.
Thanks to the community for all the help.

1 Like

Hi,
I have open an issue for an EVOHD with IP150:
here is the link: Paradox EVOHD zone parsing fail · Issue #10572 · openhab/openhab-addons · GitHub

OH3 is well connected; Partition status are well but impossible to have Pael voltage or Zone status.