OK. Thanks. When binding is changed TMP and Catch folders are necessary to delete. This way we force OH to build up the structure again with the new binding. I have experienece that when I had just changed the jar files in the addon folder it was not enough. Openhab was operating from catch folder and everything remained unchanged. I have made a small rule that the binding reset the connection in every each hour. Than I will switch it off as well.
Hello, Binding has been working since two days. Will see what would happen till werkend.
Can you check if you have timeouts in the log file?
If reconnect functionality works fine you may have timeouts followed by a reconnect.
Cheers,
K.
No any timeout so far. When you asked, I’d checked immediatelly but it dissapeared somehow. I haven’t restarted the server since you’d asked it last time. It will be also interesting that how it would behave after next server restart.
I have found one:
OH-thingHandler-2 2019-09-26 22:07:36.888 [DEBUG] [ing.paradoxalarm.internal.model.Zone] - Zone Zone 192 state updated to: Opened: false, Tampered: false, LowBattery: false
OH-thingHandler-3 2019-09-26 22:07:41.915 [DEBUG] [l.communication.AbstractCommunicator] - Error receiving packet after reaching the set timeout of 2000ms. Request: RamRequest [getType()=RAM, getRamBlockNumber()=1]
OH-thingHandler-3 2019-09-26 22:07:42.253 [DEBUG] [aradoxalarm.internal.model.Partition] - Partition Epulet: Disarmed, Additional:Ready to arm;Stay instant ready;Force ready;Bypass ready;Inhibit ready;All zones closed;
OH-thingHandler-3 2019-09-26 22:07:42.253 [DEBUG] [aradoxalarm.internal.model.Partition] - Partition Garazs: Disarmed, Additional:Ready to arm;Stay instant ready;Force ready;Bypass ready;Inhibit ready;All zones closed;
OH-thingHandler-3 2019-09-26 22:07:42.253 [DEBUG] [aradoxalarm.internal.model.Partition] - Partition Area 3: Disarmed, Additional:Ready to arm;
OH-thingHandler-3 2019-09-26 22:07:42.253 [DEBUG] [aradoxalarm.internal.model.Partition] - Partition Area 4: Disarmed, Additional:Ready to arm;
OH-thingHandler-3 2019-09-26 22:07:42.253 [DEBUG] [aradoxalarm.internal.model.Partition] - Partition Area 5: Disarmed, Additional:Ready to arm;
OH-thingHandler-3 2019-09-26 22:07:42.253 [DEBUG] [aradoxalarm.internal.model.Partition] - Partition Area 6: Disarmed, Additional:Ready to arm;
OH-thingHandler-3 2019-09-26 22:07:42.253 [DEBUG] [aradoxalarm.internal.model.Partition] - Partition Area 7: Disarmed, Additional:Ready to arm;
OH-thingHandler-3 2019-09-26 22:07:42.253 [DEBUG] [aradoxalarm.internal.model.Partition] - Partition Area 8: Disarmed, Additional:Ready to arm;
OH-thingHandler-3 2019-09-26 22:07:42.253 [DEBUG] [ing.paradoxalarm.internal.model.Zone] - Zone Ajto state updated to: Opened: false, Tampered: false, LowBattery: false
OH-thingHandler-3 2019-09-26 22:07:42.253 [DEBUG] [ing.paradoxalarm.internal.model.Zone] - Zone Eloszoba state updated to: Opened: false, Tampered: false, LowBattery: false
This one is fine. This is only one packet timeout. I usually skip these if the other pages get read correct.
RAM in Evo192 contains 16 pages. We read them in order from 1-16. If any of them for some reason responds wrongly or the packet gets lost in certain timeout we just skip it.
Issue would be if we cannot connect at all to the socket of Paradox. Then the “TIMEOUT !” text should appear, followed by remediation. You can try if there are timeouts by doing:
grep “TIMEOUT” /yourparadox log folder/*
Cheers,
K.
P.S. I just remembered that you’re under windows. Not sure what the grep in windows is. I guess a search in paradox.log with notepad++ or something would be sufficient.
This “Timeout !” will be in openhab.log file I guess.
Binding was stopped today see Openhab.log:
2019-09-30 11:28:59.357 [WARN ] [su.litvak.chromecast.api.v2.Channel ] - Error while reading, caused by java.net.SocketTimeoutException: Read timed out
2019-09-30 11:28:59.357 [WARN ] [su.litvak.chromecast.api.v2.Channel ] - <-- null payload in message
2019-09-30 11:29:00.234 [INFO ] [io.openhabcloud.internal.CloudClient] - Disconnected from the openHAB Cloud service (UUID = …, base URL = http://localhost:8080)
2019-09-30 11:29:00.317 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.NullPointerException: null
at org.openhab.binding.paradoxalarm.internal.handlers.ParadoxIP150BridgeHandler.onSocketTimeOutOccurred(ParadoxIP150BridgeHandler.java:294) ~[?:?]
at org.openhab.binding.paradoxalarm.internal.communication.AbstractCommunicator.receivePacket(AbstractCommunicator.java:160) ~[?:?]
at org.openhab.binding.paradoxalarm.internal.communication.AbstractCommunicator.communicateToParadox(AbstractCommunicator.java:105) ~[?:?]
at org.openhab.binding.paradoxalarm.internal.communication.AbstractCommunicator.communicateToParadox(AbstractCommunicator.java:112) ~[?:?]
at org.openhab.binding.paradoxalarm.internal.communication.AbstractCommunicator.submitRequest(AbstractCommunicator.java:98) ~[?:?]
at org.openhab.binding.paradoxalarm.internal.communication.EvoCommunicator.readRAM(EvoCommunicator.java:229) ~[?:?]
at org.openhab.binding.paradoxalarm.internal.communication.EvoCommunicator.refreshMemoryMap(EvoCommunicator.java:218) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:?]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) ~[?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) ~[?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
2019-09-30 11:29:01.635 [INFO ] [io.openhabcloud.internal.CloudClient] - Connected to the openHAB Cloud service (UUID = …, base URL = http://localhost:8080)
2019-09-30 11:29:03.131 [WARN ] [nal.protocol.MilightV6SessionManager] - Session timeout!
2019-09-30 11:29:03.185 [WARN ] [nal.protocol.MilightV6SessionManager] - Session timeout!
Loggigng was stopped two days because I switched it off accidentally.
Binding was stopped again. I attached the logs. I had an internet outage this time. IP150 connected on local network to the router through a wifi repeater. I reset the binding and will see. One thing is sure, it can run few days without stop. paradox_20191001.log (29.2 KB)
Is there anything after these two entries in the log:
OH-thingHandler-5 2019-10-01 08:09:25.736 [DEBUG] [l.communication.AbstractCommunicator] - Socket time out occurred. Informing listener. Request={}. Exception=
java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:210) ~[?:?]
at java.net.SocketInputStream.read(SocketInputStream.java:141) ~[?:?]
at java.io.DataInputStream.read(DataInputStream.java:100) ~[?:?]
at org.openhab.binding.paradoxalarm.internal.communication.AbstractCommunicator.receivePacket(AbstractCommunicator.java:141) ~[?:?]
at org.openhab.binding.paradoxalarm.internal.communication.AbstractCommunicator.communicateToParadox(AbstractCommunicator.java:105) ~[?:?]
at org.openhab.binding.paradoxalarm.internal.communication.AbstractCommunicator.communicateToParadox(AbstractCommunicator.java:112) ~[?:?]
at org.openhab.binding.paradoxalarm.internal.communication.AbstractCommunicator.submitRequest(AbstractCommunicator.java:98) ~[?:?]
at org.openhab.binding.paradoxalarm.internal.communication.EvoCommunicator.readRAM(EvoCommunicator.java:229) ~[?:?]
at org.openhab.binding.paradoxalarm.internal.communication.EvoCommunicator.refreshMemoryMap(EvoCommunicator.java:218) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
OH-thingHandler-5 2019-10-01 08:09:25.745 [TRACE] [arm.internal.communication.SyncQueue] - Removing from queue request=RamRequest [getType()=RAM, getRamBlockNumber()=9]
Anything during the same time in the openhab.log?
Nothing after that. I have copied opehnab.log in the TXT and there was no relevant line.You can see that this is the time what in paradox log as well. It is strange for me, that’s why I had mentioned that I had internet outage in that time, probably it caused mess. Normally it should not affect it, as it communicates locally. I have restated and will see next ones.
OK. Thanks.
As I don’t see this behavior locally at home and I also don’t see in the code a meaningful reason the bridge handler to be null when the timeout occurs, I will have to simulate that. I have some ideas how to do so.
Please give me some time. Hope I can have a look at it during the weekend…
Hello all,
I am rather new to openhab but I have thus far managed to get quite a few things working (Insteon, Zwave, Rachio, …).
I just started trying to use the Paradox binding to communicate with my IP150/EVO192. After installing the binding I added the following paradox.things file, based on the online doc:
Bridge paradoxalarm:ip150:ip150 [refresh=5, panelType="EVO192", ip150Password="XXX", ipAddress="192.168.0.200", port=10000 ] {
Thing panel panel
Thing partition partition1 [id=1]
Thing zone Fumee [id=1]
}
Note that for the real value of ip150Password given in my file is the same one as I need to type in the field “Panel user code” in order to do a manual login through the IP150 web page at 192.168.0.200. Perhaps this is not correct?
After restarting openhab, I found in the log that the things file has been read in. However, a bit later in the log I get the following warning:
2019-10-03 16:59:56.556 [WARN ] [l.handlers.ParadoxIP150BridgeHandler] - Initial communicator not coming up online for 10000 seconds. Probably there is something wrong with communication.
And just a bit later the following error message:
2019-10-03 17:13:07.819 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.NullPointerException: null
at org.openhab.binding.paradoxalarm.internal.model.ParadoxPanel.isPanelSupported(ParadoxPanel.java:75) ~[?:?]
at org.openhab.binding.paradoxalarm.internal.handlers.EntityBaseHandler.initializeDelayed(EntityBaseHandler.java:58) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) ~[?:?]
at java.util.concurrent.FutureTask.run(Unknown Source) ~[?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(Unknown Source) ~[?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [?:?]
at java.lang.Thread.run(Unknown Source) [?:?]
Any suggestions?
Many thanks,
Hi,
have you read the README?
Please make sure you provide both your IP150 password and the so-called PC Password which is something like a PIN from your system setup. Can be seen when entering in configuration mode from keyboard on section 3012. Default value is 0000.
Please check this: https://www.openhab.org/addons/bindings/paradoxalarm/
Cheers,
K.
Hi Konstantin,
Not sure what README you are referring to. I had read the bionding doc page but unfortunately I had no clue what “code 3012 setting” meant. Now I think I understand it is part of the programming mechanism available through the keyboard of my alarm panel. And it seems that I need the installer to help me with finding out that code. Right?
Many thanks,
Pierre
Yeah. You could always try with pcPassword=0000 which is the default. If it does not work, the installer needs to provide you the value. 
Good luck !
Hi,
I’ve made a new binary for you. Tested it locally by simulating timeout. Found the bug and now it should be fine. At least I was able to reconnect when simulating.
Please give it a try and let me know if it works so I can make a PR. Hopefully we can make it in the next milestone release.
Cheers,
K.
Hi again,
The installer provided me with a 4-digit value for “address 3012” which is different from “0000”. Unfortunately, after entering this new value for pcPassword, I am still getting the very same error messages as before.
Could it be that I also need to provide a value for ip150Password that is also known to the installer and is different from “panel user code” value that I use to login on the ip150 web page (and same as I provide on my alarm keypad)?
Thanks! I installed the new one and restarted OH including clearing TMP and Catch. This way surely binding was restarted. It works fine so far.
@kovacsi2899: Thanks for your input. However my login page on the ip150 is only requesting a panel user code, see my screen capture:
The code I need to enter at that point happens to be the same as my pin on the alarm keypad. On the IP150 log it is then reported that “user1: PIERRE” has entered his code. Thus the value I am currently providing for ip150Password is in fact my pin on the alarm keypad. I do not know whether or not I should be provided with a different value.
As explained in my latest reply to Konstantin, the installer provided me with what is apparently the correct value for pcPassword.
Unfortunately using that pair of values in paradox.things does not result in a successful login through openhab.