Hi,
welcome ! You can install it via Paper UI if you’re using 2.5 M3 build and later.
Latest locally build jar’s can be found on my github here: https://github.com/theater/binaries/tree/master/ParadoxAlarm
where the -SNAPSHOT is the latest, greatest and usually most bug-free.
You copy the .jar into the addons folder of your openhab installation. More info about the manual configuration can be found here: https://www.openhab.org/addons/bindings/paradoxalarm/
In my TODO list is to change Joao’s post on top of this thread to have the common information about the binding but let’s see when I can do that…
Yeah. I think I’ve written it in the binding manual somewhere…
I could try to add support for MG5050 but without having one on site for testing this will be tremendous effort of try/error. At least it took me several weeks to figure out all the HEX stuff for EVO even thouhg the great documentation made by Jean Henning.
If someone who owns MG5050 and a little bit of development skills has the time to create an extension, I would support him in explaining the design of the binding with pleasure.
That’s very unfortunate. Now the reconnect works fine, unfortunately right after the logon process started you receive a connection timeout in the middle of the logon sequence. I don’t handle reconnect during the logon process. Only the regular refreshes. You should really try to improve your connectivity. Increasing the reconnect wait time could help but it’s more like a matter of luck.
I’ll think if I can implement same reconnect functionality for the logon sequence too…
No worry. I will increase the timing. I think sometimes I have temporary problem in wifi what takes time to recover. Than when it works connection itself is fast. I try to improve the connection bandwith paralel. Also I have a workaround. I wrote a small rule what reset the connection at certain. Binding itself is perfect now I think.
Hi,
I’ve checked the handling again into the code, because I didn’t like what I wrote. It’s not normal to handle same type of exception a different ways in the login and the normal refresh ecenarios. I can confirm from the code that I’m handling socket timeout error the same way also in login sequence. (basically it’s handled centrally)
Problem is that you receive read timeout exception, which is another type of IOException. I’m not sure when the latter happens. Maybe when the socket is OK but it’s timeout has not been reached yet… or maybe when a certain packet has been lost but the socket is working fine.
I can handle these the same way like socket time out but I’m a bit reluctant to do so because in the normal refresh scenario we’re OK in receiving read time out exceptions if they’re not too many. If there is such error during refresh we’re ignoring the currently refreshed memory page and we use the old data. If next refresh passes successfully we’re OK and we refresh the cached results.
If I handle this the same way like I do for the socket timeout exception, this means in any case when read timeout exception occurs to retrigger logout, wait certain amount of time, login with reading all EPROM data and reinitialize the model.
Hello, I just want to changes the 30 sec to 60. But as I use .thing files, I need to put into the config file and binding will recognise the data if you give me the name of the field. I do not think, that anything needs to be changed in the binding.
I believe it is reconnectWaitTime. Please check the personal messages thread as I’m out of my home city and away from any laptops. I can check it on Sunday late afternoon…
I have an idea. I have installed 13 zones. Binding goes through reading of 192 zones each time. If you put a limitation than binding will read only installed zones. This can be an option if somebody wants to use it (default is 192). This way you can reduce data flow size or probably speeds it up a little bit. Or might be my idea is useless as additional resource if reading 120 sockets are so minimal that it does not worth at all.
Yeah. That’s a good hint indeed and initially before I did the two steps login process with detection of the system and then reading the configuration data I’ve had this setting as parameters. I decided to get rid of it due to usability impact for regular users.
This idea will improve performance only during login, because then we’re reading the EPROM values from the system for each partition and zone. Afterwards what we do is we read the 16 memory pages 64 bytes each. Then we parse the RAM pages and update all 192 zones and all 8 partitions but it’s insignificant from performance perspective because the IO operations are already done.
I get a message from paradox that PMH is closing 31 of oktober, and i should upgrade to Swan.
I there any progress woth this binding in combination with the latste firmware?
