Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[paradoxalarm] Add access to the different Alarm States (Armed, Armed in Stay, Was Is in Alarm) #14608

Closed
Mark-VG opened this issue Mar 15, 2023 · 22 comments · Fixed by #14618
Closed

[paradoxalarm] Add access to the different Alarm States (Armed, Armed in Stay, Was Is in Alarm) #14608

Mark-VG opened this issue Mar 15, 2023 · 22 comments · Fixed by #14618
Assignees
@theater
Labels
enhancement An enhancement or new feature for an existing add-on

Comments

@Mark-VG
Copy link

Mark-VG commented Mar 15, 2023

The current version of the Binding seems to groups the different Armed states into the general Armed state, so it is not possible to see what type of Arm in the partition is in.

Armed - is usually used to arm all zones and exit the partition/area
Armed Stay - allows arming selected Zones so that you can "Stay" in the area, but certain selected Zones are "bypassed/ignored". This allows movement in select areas.

It would be really nice to have access to the additional states, either as distinct "switches" such as:

Armed Exit - On/Off
Armed Stay - On/Off
Armed Instant - On/Off
Was Is in Alarm - On/Off

The other option would be to Just Have a String in the Current State String to denote the current state, but as you mentioned that would require:

The other issue is that in any rules that we have we need to have "if (armed || armed in stay || armed in other way) do ...."

I think the separate Channel option would be easier to work with, though both have there pros and cons.

The Caddx binding which I used to use had separate channels for each Armed state
@Mark-VG Mark-VG added the enhancement An enhancement or new feature for an existing add-on label Mar 15, 2023
@theater theater self-assigned this Mar 15, 2023
@theater
Copy link
Contributor

theater commented Mar 15, 2023 •
edited

Hi Mark,
we could implement a consolidated status but we need to define the priority (i.e. if multiple states are present, which one to take into account). Have you thought about this because I can implement something but it may not be the right one. :)

For example: If we have "was in alarm", "armed in stay" and "armed", which one to take into consideration?
Currently the main state of the partition is calculated like this - "In alarm" is with highest priority, then all the "armed" states are treated as "Armed", all the others consider "disarmed".

See the coding:
public String getMainState() {
if (isInAlarm) {
return "InAlarm";
} else {
return isArmed || isArmedInAway || isArmedInStay || isArmedInNoEntry ? "Armed" : "Disarmed";
}
}

Cheers,
Konstantin

P.S. I don't know how to format it properly

@Mark-VG
Copy link
Author

Mark-VG commented Mar 15, 2023

Hi Konstantin

If you did a consolidated status, would you be able to distinguish between the different status and return the correct string?

From what I know you cannot be ArmedInStay as well as ArmedInAway or ArmedInNoEntry at the same time. But you might get be able to be Armed?

Maybe (not my area)???

public String getMainState() {
if (isInAlarm) {
return "InAlarm";
} else {
if (isArmedInAway) {
return "Armed Away";
} else {
if (isArmedInStay) {
return "Armed Stay";
} else {
if (isArmedInNoEntry ) {
return "Armed No Entry";
}
}

But a more flexible option might be to Have the Overall Status Being In Alarm or Armed or Disarmed - could even add the extra one) with a more detailed channel for each state being

InAlarm On/Off
ArmedAway On/Off
ArmedStay On/Off
ArmedNoEntry On/Off

Then you can choose which works better for the scenario?

@theater
Copy link
Contributor

theater commented Mar 15, 2023

Yes.
These are the two feasible options.
If if these statuses are exclusive (i.e. if you can be either Armed or Armed in stay or Armed in no entry), maybe it's better to put it in the overall state because we will have the most exact state in the overall state.
I think I'm leaning towards this solution because otherwise you have to assign the channels to a separate items and then check each item's status, if you want to use them in some rules for example. (or maybe you can check thing's channels... I'm not sure about this).

@theater
Copy link
Contributor

theater commented Mar 15, 2023

OK... in order to still keep this backwards compatible, I think what we can do is the following:
in case of isInAlarm or isInSilentAlarm or isInAudibleAlarm or isInFireAlarm => main state = In Alarm
in case of isArmed or isArmedInAway or isArmedInStay or isArmedInNoEntry => main state = Armed / Disarmed (if none of these is set)

Implement additional channel (only one) which returns calculated sub-state (or "exact state") of all these which is the exact state, i.e. one of these 8 or "disarmed" if none of these 8 bits is set.
With this approach whoever has rules based on the main state will still be able to use them, whoever needs exact states, can use the sub-state (or exact state) channel.

What do you think?

@theater
Copy link
Contributor

theater commented Mar 15, 2023

You can try the new channel using this release: https://github.com/theater/openhab-addons/releases/tag/v4.0.0-alpha6

@Mark-VG
Copy link
Author

Mark-VG commented Mar 15, 2023

Thank you. Having a quick test run. Will let you know.

One quick thing I noticed first off is that Both Channels have the same name and description which cause some confusion.

image

I am going out shortly and will test the state report when I arm the system and when I am back.

@Mark-VG
Copy link
Author

Mark-VG commented Mar 15, 2023

I am getting Armed and Disarmed only. When Armed Stay I just get Armed.

@theater
Copy link
Contributor

theater commented Mar 15, 2023 via email

@Mark-VG
Copy link
Author

Mark-VG commented Mar 15, 2023

Hi. Hope this is enough. Partition 4 is Armed STAY
paradox.log

@theater
Copy link
Contributor

theater commented Mar 16, 2023

Hi, I've uploaded a new version in the same release. No fix but more logging. I need to see what happens in the parsing. Hopefully now we will have the full state like in the zones for better debugging. Sorry for the inconvenience but no time to test locally...

@Mark-VG
Copy link
Author

Mark-VG commented Mar 16, 2023

Thank you... I have installed an running. Logs as follows:
paradox1.log

I did notice the build seems to be the same as yesterday? Is that correct?

260 │ Active │  80 │ 4.0.0.202303151448     │ openHAB Add-ons :: Bundles :: ParadoxAlarm Binding
263 │ Active │  80 │ 4.0.0.202303151448     │ openHAB Add-ons :: Bundles :: ParadoxAlarm Binding

@theater
Copy link
Contributor

theater commented Mar 17, 2023

Hi,
the new version with fixes is here: https://github.com/theater/openhab-addons/releases/tag/v4.0.0-alpha7
If you are interested to see what to expect (maybe it's good to document this), the logic can be seen in the getDetailedState() method in this file/branch: https://github.com/theater/openhab-addons/blob/implemen_exact_partition_states/bundles/org.openhab.binding.paradoxalarm/src/main/java/org/openhab/binding/paradoxalarm/internal/model/PartitionState.java

Cheers,
K.

@theater
Copy link
Contributor

theater commented Mar 17, 2023

OK. Added also a new table with the possible detailed state values in the README.

@theater theater mentioned this issue Mar 17, 2023
Merged
@Mark-VG
Copy link
Author

Mark-VG commented Mar 17, 2023

Hi

That looks really great. Have done a basic test and reports the Armed Stay well. Have removed and readded all the Things and shows up great

One small comment regarding the default naming:
image

Just the Case of the partition in the name:

Partition_House_Detailed_partition_State

In the other examples all the words are Upper Case for each Word. But not this one. Not sure if you want to make it the same?

I could not find the modified README though.

Thanks again.

@Mark-VG
Copy link
Author

Mark-VG commented Mar 17, 2023

All these additions are working really well. Thank you so much.

Do you think there is still an opportunity to make a cosmetic change since you have submitted the PR already?

To match the Keypad display for the details States, could the String be changed? I know these will not be changed once released as they would affect anyone who is using them.

image

Maybe to

Away Armed
Stay Armed
NoEntry Armed

and Also Possibly :
Silent Alarm
Audible Alarm
Fire Alarm

I am trying to make my widget reflect the Keypad as best I can - not always possible:

Statuses

Just something you could consider - most certainly not the end of the world. Couldn't be happier with what you have managed to add already.

@theater
Copy link
Contributor

theater commented Mar 18, 2023 via email

@theater
Copy link
Contributor

theater commented Mar 18, 2023

https://github.com/theater/openhab-addons/releases/tag/v4.0.0-beta1

@Mark-VG
Copy link
Author

Mark-VG commented Mar 18, 2023

Thank you. Looks good. Will continue to work with the latest one and let you know.

Did you decide to leave the default Linked Item Name as is?

Partition_Beams_Detailed_partition_State

vs

Partition_Beams_Detailed_**P**artition_State

Just asking because the the Widget I am working on will relay on the names of all the Channel Items, so trying to match the defaults as far as I can, and this one is a bit different to the others because of the lowercase p for Partiton.

Hope you have a good week-end.

@theater
Copy link
Contributor

theater commented Mar 18, 2023 via email

@Mark-VG
Copy link
Author

Mark-VG commented Mar 18, 2023

I have deleted and re-added the Partition THING, and now the default is all CAPS for first letters:

image

I have noticed that most of the linked ITEM defaults have also changed to have _ between each word. I have just recreted to match that.

Maybe 4.0.0 does something different.

It is a pity that openHAB requires a delete and re-add to pick these changes.

Thank yous o much

@theater
Copy link
Contributor

theater commented Mar 18, 2023 via email

@Mark-VG
Copy link
Author

Mark-VG commented Mar 18, 2023

Yes. All great. Hopefully reviewed and merged soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@theater theater

Labels
enhancement An enhancement or new feature for an existing add-on
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

[paradoxalarm] Implement detailed partition state theater/openhab-addons
2 participants
@theater @Mark-VG