Oh you mean this README, I’m sorry I was looking on github.
I still can’t figure out the mapping values regarding Arm, Instant, Stay, Disarm on the sitemap file as well as the particular thing to combine.
Any suggestion would be really appreciated.
BR
Hi all,
Is there anybody wants to share that particular part of the sitemap regarding mapping Arm, Instant, Stay, Disarm.
Would be appreciated.
What is the question? What item would you like to see? Read the readme and use the examples. Or pls specify your question.
Absolutely,
I’m interesting in mapping the lay out buttons on the sitemap file so I could be able to Arm, Instant, Stay, Disarm. I tried the readme sitemap but with no luck.
It might be the Additional States item channel="paradoxalarm:partition:3426c5ae:additionalStates"
If you have read of this thread probably you would have realized that this binding only reads the statuses of the IP150 modul, EVO192 panel and its zones. It won’t change the status. It has safety reason, that despite of your OH server is hacked they can’t turn off your alarm system. There was a new discussion about this topic around 2 month ago when need of handling IP150 above 4.x FW handling popped up. But I don’t know what was the final decision about this functionality. Theoretically it is possible to add, it is a matter of safety decision.
Hi Mike,
it seems I didn’t state that clearly enough in the documentation that currently the binding is read-only, i.e. you can have states of partitions and zones and make yourself some rules based on it. For active status changes, i.e. arming, disarming I need to invest more time to see how Joao(jpbaracca) is building the packets and do the low-level logic.
I made some preparations which are on my change list so at least I will get rid of these consolidated statuses under additionalStates channel and will allow each state of this comma separated values string to be a separate channel. This could ease creation of specific rules based on specific states. This could also be used in the future to say what type of command is allowed from the panel, i.e. if one of the states is “Ready to arm” probably you’ll be allowed to send “Arm” signal. But that’s in the backlog.
What I currently will try to develop with higher priority is the encryption in order to start supporting IP150 4.x firmware.
Next if I have the time, I may start investigating what is necessary to make active communication to the system. (probably will be hidden behind a parameter in the IP150 bridge configuration, i.e. by default this should be disabled and only a user will have to enable it, because it has security risk associated with it)
Cheers,
Konstantin
1 Like
Thank you all for the replies,
My fault I didn’t realize it was read-only, (I should have to, looking at the README suggested rules).
It makes sense that is all about safety.
Hi everybody,
I’ve pushed into binaries repo one new small feature. Would be great if someone can test it (beside me). The new .jar is this one:
https://github.com/theater/binaries/blob/master/ParadoxAlarm/org.openhab.binding.paradoxalarm-2.5.1-SNAPSHOT.jar
I figured I had to stop openhab and remove /openhab/userdata/tmp/* and /openhab/userdata/cache/* in order the changes to take effect.
What is expected is… to work like before of course and also to have more read-only channels on partitions. See the screenshot below.
Meanwhile I’m also working on the encryption topic. So far I have some success but I’m still strugling in some of the phases of the login process. Will post when I have more info about that.
Cheers,
Konstantin
Hello,
I have updated the binding. I’m using 2.5.R1 and it works. paradox binding test 2.5.1.log (46.5 KB)
I have uploaded the first startup logs. I had to reboot openhab again to start the binding but as I see this is issue of openhab boot sequence and nothing to do with the binding. I will check additional options later plus I will feedback about stability. One more info that I managed to have cable connection to IP150 instead of WIFI.
Hi all,
Some good news. Finally managed to make the encryption work. Unfortunately there are some annoying things that I know in the code which I will try to fix later but the first binary is testable now. I tried that on my 1.x IP150 firmware so would be great if there is any early bird with latest 4.x to test as well.
The .jar is here again: binaries/ParadoxAlarm/org.openhab.binding.paradoxalarm-2.5.1-SNAPSHOT.jar at master · theater/binaries · GitHub
Has to be put under ./addons folder in openhab.
The bridge configuration has one new boolean parameter encrypt=true/false.
Mine looks like this:
Bridge paradoxalarm:ip150:ip150 [refresh=3, ip150Password=“MYPASSWORD”, pcPassword=“0000”, ipAddress=“addressOrHost”, port=10000, reconnectWaitTime=10, maxZones=50, maxPartitions=4, encrypt=true] {
… entities definitions…
}
Please when you have time give it a try. I did a lot of changes in the code so it could be very well buggy so more testers, better overall quality at the end. 
Cheers,
Konstantin
1 Like
Hello, I have uploaded it and it works. There are 3 restarts of the binding in the log.
1st is Openhab restart after replacement of jar file and modification of .things file. Second is remove and add back .things file means reconfigre things as 4 zones were in unkwonwn status. My suspect is that these are the 4 zones on zone extension board. Finally last restart is a complete OH restart again and after that all zones are identified and readed correctly. So it runy now. In case of any new issue I’ll report.Paradox_log_20200111.log (693.4 KB)
Thanks for testing! The unknown state is one thing I want to look into deeper, because it’s annoying. I’ve had it also before when updating the binding.
The other issue is that sometimes when communicator does not go online you need to send a reset command to the bridge in order everything to go OK (or restart the binding). I guess it’s some concurrency issue and I will look into it deeper together with other small issues that I’ve found…
Might be. I think we have still inconsistencies in the core code during the startup. That’s why usually I starts it two times. That’s why I copied the complete openhab.log from the startups that you might be separate OH Core issue and binding issue. If you want to get more trace and give me versions with built in tracking I can change it any time.
2020-01-12 07:05:28.726 [WARN ] [nal.communication.CommunicationState] - Login - Connection refused
This error means I have wrong IP150 or PC Password?
IP150: 4.42.02
Panel: EVOHD Firmware version 7.11
Openhabian: openHAB 2.5.1~20200111043336-1 (Build #12)
Hi Indrek,
could you please check the very first post of this huge thread and provide me more logs in DEBUG level?
I’ve documented there how to enable logging in separate file and how to enable DEBUG for the binding.
Thanks in advance,
Konstantin
Let me know if I need to give more information.
safeCall-6 2020-01-12 11:20:53.727 [DEBUG] [l.handlers.ParadoxIP150BridgeHandler] - Start initialize()…
safeCall-6 2020-01-12 11:20:53.731 [DEBUG] [l.handlers.ParadoxIP150BridgeHandler] - Starting creation of communicator.
safeCall-6 2020-01-12 11:20:53.734 [DEBUG] [l.handlers.ParadoxIP150BridgeHandler] - Finished initialize().
OH-thingHandler-5 2020-01-12 11:20:53.736 [DEBUG] [l.handlers.ParadoxIP150BridgeHandler] - Phase1 - Identify communicator
OH-thingHandler-5 2020-01-12 11:20:53.738 [DEBUG] [l.communication.AbstractCommunicator] - IP Address=192.168.1.56
OH-thingHandler-5 2020-01-12 11:20:53.740 [DEBUG] [l.communication.AbstractCommunicator] - TCP Port=10000
OH-thingLinkManager-9 2020-01-12 11:20:53.742 [DEBUG] [l.handlers.ParadoxIP150BridgeHandler] - Received command REFRESH
OH-thingHandler-5 2020-01-12 11:20:53.744 [DEBUG] [al.communication.GenericCommunicator] - Use encryption=true
OH-thingLinkManager-9 2020-01-12 11:20:53.744 [DEBUG] [l.handlers.ParadoxIP150BridgeHandler] - Command is instance of class org.eclipse.smarthome.core.types.RefreshType
OH-thingHandler-5 2020-01-12 11:20:53.745 [DEBUG] [al.communication.GenericCommunicator] - Login sequence started
OH-thingHandler-5 2020-01-12 11:20:53.747 [DEBUG] [nal.communication.CommunicationState] - Phase START
OH-thingLinkManager-9 2020-01-12 11:20:53.748 [DEBUG] [l.handlers.ParadoxIP150BridgeHandler] - Communicator is null or not online
OH-thingLinkManager-8 2020-01-12 11:20:53.749 [DEBUG] [l.handlers.ParadoxIP150BridgeHandler] - Received command REFRESH
OH-thingLinkManager-8 2020-01-12 11:20:53.754 [DEBUG] [l.handlers.ParadoxIP150BridgeHandler] - Command is instance of class org.eclipse.smarthome.core.types.RefreshType
OH-thingLinkManager-8 2020-01-12 11:20:53.755 [DEBUG] [l.handlers.ParadoxIP150BridgeHandler] - Communicator is null or not online
OH-thingHandler-5 2020-01-12 11:20:53.762 [WARN ] [nal.communication.CommunicationState] - Login - Connection refused
OH-thingHandler-1 2020-01-12 11:20:54.263 [DEBUG] [l.handlers.ParadoxIP150BridgeHandler] - Communicator not yet online. Rescheduling…
OH-thingHandler-2 2020-01-12 11:20:54.763 [DEBUG] [l.handlers.ParadoxIP150BridgeHandler] - Communicator not yet online. Rescheduling…
OH-thingHandler-2 2020-01-12 11:20:55.264 [DEBUG] [l.handlers.ParadoxIP150BridgeHandler] - Communicator not yet online. Rescheduling…
OH-thingHandler-5 2020-01-12 11:20:55.764 [DEBUG] [l.handlers.ParadoxIP150BridgeHandler] - Communicator not yet online. Rescheduling…
OH-thingHandler-1 2020-01-12 11:20:56.264 [DEBUG] [l.handlers.ParadoxIP150BridgeHandler] - Communicator not yet online. Rescheduling…
OH-thingHandler-1 2020-01-12 11:20:56.764 [DEBUG] [l.handlers.ParadoxIP150BridgeHandler] - Communicator not yet online. Rescheduling…
OH-thingHandler-5 2020-01-12 11:20:57.265 [DEBUG] [l.handlers.ParadoxIP150BridgeHandler] - Communicator not yet online. Rescheduling…
OH-thingHandler-4 2020-01-12 11:20:57.765 [DEBUG] [l.handlers.ParadoxIP150BridgeHandler] - Communicator not yet online. Rescheduling…
OH-thingHandler-3 2020-01-12 11:20:58.265 [DEBUG] [l.handlers.ParadoxIP150BridgeHandler] - Communicator not yet online. Rescheduling…
OH-thingHandler-2 2020-01-12 11:20:58.765 [DEBUG] [l.handlers.ParadoxIP150BridgeHandler] - Communicator not yet online. Rescheduling…
OH-thingHandler-5 2020-01-12 11:20:59.265 [DEBUG] [l.handlers.ParadoxIP150BridgeHandler] - Communicator not yet online. Rescheduling…
OH-thingHandler-3 2020-01-12 11:20:59.766 [DEBUG] [l.handlers.ParadoxIP150BridgeHandler] - Communicator not yet online. Rescheduling…
OH-thingHandler-2 2020-01-12 11:21:00.266 [DEBUG] [l.handlers.ParadoxIP150BridgeHandler] - Communicator not yet online. Rescheduling…
OH-thingHandler-2 2020-01-12 11:21:00.766 [DEBUG] [l.handlers.ParadoxIP150BridgeHandler] - Communicator not yet online. Rescheduling…
OH-thingHandler-3 2020-01-12 11:21:01.266 [DEBUG] [l.handlers.ParadoxIP150BridgeHandler] - Communicator not yet online. Rescheduling…
OH-thingHandler-5 2020-01-12 11:21:01.766 [DEBUG] [l.handlers.ParadoxIP150BridgeHandler] - Communicator not yet online. Rescheduling…
OH-thingHandler-5 2020-01-12 11:21:02.267 [DEBUG] [l.handlers.ParadoxIP150BridgeHandler] - Communicator not yet online. Rescheduling…
OH-thingHandler-3 2020-01-12 11:21:02.767 [DEBUG] [l.handlers.ParadoxIP150BridgeHandler] - Communicator not yet online. Rescheduling…
OH-thingHandler-4 2020-01-12 11:21:03.267 [DEBUG] [l.handlers.ParadoxIP150BridgeHandler] - Communicator not yet online. Rescheduling…
OH-thingHandler-3 2020-01-12 11:21:03.767 [WARN ] [l.handlers.ParadoxIP150BridgeHandler] - Initial communicator not coming up online for 10000 seconds. Probably there is something wrong with communication.
OK. I think it’s because it’s EVOHD. It seems that it does not allow even the first packet from the login sequence. I hoped that it may work with encryption but it seems not. Probably it expects other bytes packet but I don’t know what exactly.
Currently the binding supports evo48, 96, and 192 and is tested only with evo192.
@jpbarraca do you have any experience in PAI with EVOHD? Seems that it uses different protocol and does not respond even to the initial packet
Cheers,
Konstantin
1 Like
PAI works with EVOHD (https://github.com/ParadoxAlarmInterface/pai/wiki/Compatibility)
There are a few bits in the header that are unknown to us, but seem be be required. Maybe that’s it?
Analyse a communication dump from babyware. You should see what is sent in that first packet.
Same header for all EVOs?
If it’s the same I will try what PAI sends (as I installed it on my machine) on the first packet. I have Evo192 so if it’s the same should be fairly easy to change the header for all EVOs.
Thanks,
K.