Hi,
Found issue with not updating channels and fixed it. Now it works with manually created items but I still see issues with dynamic items from the UI.
Please try this latest release:
Cheers,
K.
Wow, that was quick. Seems to work perfectly but will test more thoroughly ASAP. I really appreciate you still looking at this when I understand you are busy.
Just checking the correct status (just seems counter intuitive to me, but REALLY not a problem. Just worried it may cause confusion in the future). I will change the logic in my widget to match:
CLOSED (On)- Not Bypassed
OPEN (Off)- Bypassed
Do you think that same issue could be what affects the Partition and Zone labels also being NULL?
SO cool. Thank you
Yes. I use a channel type “contact” which has open/closed state, so open is bypassed, closed is normal (like the open/closed state of the sensors. With that you can use proper icons to show the state (I use the “lock” icon for these). If you have better idea what type to use, we can change it. Maybe a simple text is best but then we cannot use the changing icon functionality (or I’m not aware how).
Hi
I set up my rules before teh state was working and used CLOSED (on) for Bypassed and OPEN (off) for Not Bypassed, just because that seemed to be the intuitive way.
I have however swapped back to the way you have it, so all good.
REALLY appreciate your effort. Thank you.
Well… I’m open to discuss this logic. My approach was that the “not default, every day” state is the OPEN state, i.e. the bypassed, shutdown, intellizone but if you think the opposite is more intuitive, I could change that and I see the logic in that…
Really don’t want to make more work and be a pain. I guess both make sense. I just looked at it from the “switch” point of vie - On is enabled, Off is disabled. But in the end it is not an issue once you know which way round it is.
OK. You’re not a pain.
I think your logic is correct, so now is the time to fix this, before it goes to production. I will do that. Will let you know when I publish a new version.
Also, to ensure there are no issues with understanding I will document it in the channels documentation, to be more precise and to ensure that no misunderstanding occurs with future users.
1 Like
OK. I checked the coding again. Problem is that everywhere in the code I treat the “true” state of the contact (i.e. is zone opened for example), as OPEN, and false as CLOSED.
I think it’s better to change the overall type to “switch” and set the true to ON, and false to OFF. With this it will be more intuitive. What do you think?
Yeah. I did it like this, so please switch the type of channels to switch. This makes much more sense and also I used the same approach for the channel “tamperedState”. It’s of type switch and if it’s tampered the channel is ON.
New version here:
Sounds good. Checked out 1 and look sgood. Busy with others. Will let you know.
Thank you. Works perfectly. Quick to change the items to switches and it then just shows ON/OFF which makes perfect sense.
Thank you so much
Do you think that same issue could be what affects the Partition and Zone labels also being NULL?
Found the bug and fixed it. New release below. Please test and confirm.
With this I will stop pushing new changes in the PR as it become a bit big already and I don’t know when someone will have the time to review and merge it in the main branch.
https://github.com/theater/openhab-addons/releases/tag/v4.0.0-alpha5
Cheers,
Konstantin
Thank you once again. Will download and test asap.
Do you by any chance have the details of how the partition status etc are determined?
Trying to see how to determine difference between armed and armed stay etc.
Did a packet capture but could not see anything immediately so looking fir a starting point.
The excel you referred to before seems to no longer be available
EDIT: Works great - thanks. And thanks for the excel - will try work them out 
Hello, Something happened with the new release.
2023-07-02 221516.666 [DEBUG].txt (14.3 KB)
Communication failes between the modul and the binding. I have tired to download binding release from 13 march but same issue. I have updated to openHAB 4.0.0
Build #3523
Binding was working with 4.0.0.M2. Can you check it?
Strange. Currently there are two open PRs for the request above but they are not yet in the master branch and I’m not aware of any related changes.
Can you try with the binary from the latest dev-release that I did for Mark?
Release Support for zone bypass · theater/openhab-addons · GitHub
Cheers,
K.
Hello,
I havie tried it with M4. Same as yesterday. + I have tried this one but same result:
I tried with buildt in binding, then first one what you have suggested, then last version what I have linked.
Here is the result:
Paradox debug 20230703.txt (371.1 KB)
I do not have any issue with M2 built in version. But with these new release something become wrong.
Looks like some concurrency issue. Could you enable thread logging. I think it was described how to do so in the very first post. If not, I’ll try to setup M04 on my docker and reproduce / debug it…
Have you tried if it’s still reproducible with the latest snapshot ?
Cheers,
K.
Thread logging is to change logging mode to trace? No problem, I can do. I will download latest snapshot in the night and give a try. But pls bear in mind that M4 just has been released over the weekend so it is almost the latest version.
hm… sorry. It is not there it seems… I’ll see what I can do myself. I guess for now just use M02.
Just FYI I upgraded my test systemt o OH 4.0.0.M4 with the dev binding:
237 │ Active │ 80 │ 4.0.0.202303180843 │ openHAB Add-ons :: Bundles :: ParadoxAlarm Binding
Did some quick tests and all seems to work fine. No errors etc either.