-
Notifications
You must be signed in to change notification settings - Fork 6
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
Security Arming Model - Proposal #9
Comments
Adding @digitaldan to this discussion. |
Having those distinctions available in the rules sounds like a great idea. When you say impact to driver, do you mean the binding code, or do you think changes need to be made to the jomnilink lib as well? |
I think the binding will certainly be impacted - looking at the driver code, the mode support appears to be in place already From the binding perspective, we have to decide if the user selectable modes of (Night, Away, Vacation, etc) go away and are replaced with (Arming Away, Arming Vacation)? I am not sure what is right there. I think if we keep the user selectable modes of "Night", "Away", etc it will be a problem because if the user changes the mode to "Night" it will instantly fire those rules even if the actual mode is "Arming Night". |
HI, sorry to be late to the party :-) I had to go back and read that code a few times....I think we have a SecurityMode channel, it can accept the same string modes as the 1.x version does, but that does not restrict what the state value is for the channel. So for example the supported Commands: of the channel would be: But the channel state could be:
Furthermore, would would have a different channel-type for lumina and omni so that we can define the channel commands in the XML file which would be much nicer for users as UI's like the paperUI could automatically populate the arming dropdown menu with the correct command value. @boc-tothefuture is this what you are thinking? |
Dan, Let's assume panel security state is 'Off' So by selecting a command 'Night', the state channel would transition to 'Arming Night', and then after the arming delay to 'Night' ? How does the state avoid that initial change to 'Night'? I haven't seen that mechanism before within openhab. |
What is @craigham is pointing out is my big concern. Because if it openhab fires the 'Night' or 'Away' item changed when the user changes it those rules are going to trigger early, then again after the exit delay. I am also concerned, because when I look at the jominlink code, it appears it should be picking up those additional security modes. But when I go to the panel and do a night arming it logs mode 2, not mode 10. |
Yes I see, I had incorrectly assumed this was implemented eclipse-archived/smarthome#595 , but it looks like it has stalled out.
Well, i wrote that code so long ago that I'm embarrassed when I look at it now :-) If the code is not working right we (I) can fix it. At a minimum I need to at lest run it through a code formatter! So in terms of ESH mechanics, are you proposing having a command channel and and current state channel (so 2 channels). Can you describe how your proposal would look in the ESH model? Sorry If I am not understanding your proposal. |
I think we could solve it pretty easily within sitemaps by just using a mapping. Paper is more difficult because it is driven by the xml, etc. This would result in only the one channel. But yes a command channel would probably work as well. imho expecting users to get a nice polished experience out of paper is not really realistic. If they want polish and wife acceptance they'll have to use basic or classic. |
I guess to support the 2 channel solution, we could have a command channel for the area. also have a read-only state channel, the value of which is driven entirely by the omni. Then the area handler sends commands to the omni, but reads the status. |
Yes, but I think its important to support these features as other UI's (like habpanel) could start to utilize them more. This future proofs our implementation and I think helps the overall project. But I agree, the paperUI is not what I would be building for. |
I don't know enough about the XML vs. mapping debate here to weigh in so I will abstain. The only path I see (but I am no expert) given the current constraints of openhab autoupdate functionality would be to have the two channels. If we have the two channels, we can provide the normal names for the intentions while having the state accurately reflected. Will that be confusing to the users? I am not sure how common that setup is. @digitaldan After a cursory look at the code, I am not sure where the defect could be, its simply reading a byte (I don't see any code stripping off the third bit or anything). I am starting to wonder if I am reading the protocol spec wrong. |
you can add |
Dan, Can you specify autoupdate="false" from the paper ui, or any ui? Or does this mean items will have to be specified within files? |
Unfortunately that is correct, until we have channel options for not auto updating. |
I may just be misreading this, but the protocol doc is not lining up with what I am seeing when look at what we are getting over the wire. It appears we will have to do the conversion between the modes in the binding: When I arm the system in Night mode, this comes across the wire:
60 seconds later when 'Arming Completes' This maps to:
So despite, what I see in the protocol documentation, the mode doesn't actually indicate a difference between arming and being in the actual state.
and after 60 seconds:
So, I think the logic is that if you have an exit timer value > 0, then you are in an arming mode. Otherwise you are in the actual mode. I don't know if this change belongs in jomnilink or the binding. |
The response says the mode is 1 which is Day mode, thats not correct either?
So the panel I ordered was defective and I had to send it back, i should have the new one tomorrow, so I can test as well hopefully this weekend. Since I have not touched this stuff in 3+ years it may take me a little bit to get back up to speed. |
I am actually not sure what the output is of the RX line from jomnilink, if it is doing some sort of conversion? Because the mode is actually correct when its read as an unsignedByte from jominlink. For example:
|
I'll have to play with it on Friday, but lets assume the docs are correct and I have a bug somewhere in the omnilink driver. |
I am looking forward to @digitaldan getting his omni panel. I spent about an hour looking at this and made no progress. I feel like I am on crazy pills. jomnilink is clearly working but what I am seeing over the wire isn't matching what I see in the protocol spec. Its almost like I am looking at the wrong spec. We will see what @digitaldan uncovers when he looks. But, based on my testing across a variety of modes, we can use that exit timer setting (anything > 0) to determine if we are in arming mode or in the armed state of the desired mode. |
Brian, how have you hooked in the jomnilink source debugging into eclipse? I tried adding the jomnilink project to the other projects folder, and then attaching that source to the jar, but couldn't seem to set up breakpoints and stuff. |
@craigham I wasn't running it in the eclipse debugger. I was just editing the code in atom, compiling with ant, then running it from the command line. The main method of the example jar has debug mode on and spits out all that info. |
fwiw I am seeing the same byte patterns on the wire as you are Brian. I ended up just compiling my own jomnilink with the debug flag turned on inside the connection class, and debug info into the Javac for the ant target, and I use that in my lib folder. |
Either the spec is wrong OR they have updated it and not published that publicly! You are both correct they do not send the arming modes, in fact I think those are now obsolete. I also see the exit timer value when the arming starts and again when it completes, so if I do a arm day I first get:
and then 60 seconds later I get
Correct, question is, how do we handle this? Do we keep the delayed mode that we have and do the logic in the binding (my vote)? Or do we keep this exactly to the spec/wire and let users do something with rules to tie the exit timers to mode?
The library has no concept of this, it simply reports the structures, so unless we build a new abstraction into the library, it needs to be in the binding (which is the abstraction).
Yes, I went back and cleaned up all the super ugly system.out's, you can now use logging within OH like: Note that I also moved from ant to maven, the README has build instructions now. |
I have no problem with anything you said. In particular I also agree about handling these changes in the binding, and not adding more to the lib. Nice changes to the jomnilink lib too. |
Ok, so this is now working like it should according to the docs. Next question! The arm/disarm command requires the User code number, which is not actually the the value of the code, but the codes object number (1st code, 2nd code, 3rd code ...). Right now I have it hardcoded to code 1 for testing, but thats probably not good. i think the desire should be to pass in the numeric code when arming/disarming and we will lookup the code number and use it if it exists, and error if it does not. Thats all easy, whats more difficult is how to model this as a channel in ESH. Right now we receive modes (0,1,2,3...) and when send modes (0,1,2,3). I'm open to suggestions. We could have a send only channel per mode that takes a code (arm channel, disarm channel, day channel,....) and have the current mode channel read only. This actually makes sense since the mode channel right now has states that can not be set (delayed). I'm thinking about prototyping this unless there are objections. |
no objections here. sorry, but no suggestions either. |
@digitaldan |
I also agree with this. Current mode channel is read only and the 'write' channel takes a code. |
Shall we close this issue? I think we are good on our implantation . |
Done. Nice work. |
I think we should modify the arming model we are using for the Omni because I am not sure it appropriately maps right now. This issue also exists in the V1 driver.
Right now, we have as user selectable states:
Off, Day, Night, Away, Vacation, Day Instance, Night Delay.
The issue is that Off is the only of these states that you can actually directly move an Omni into.
When you select, for example 'Away', the Omni really moves into the 'Arming Away' state and after the exit delay, then actually moves into the 'Away' state. This is an important distinction because there are rules you may want to trigger in both sets of states. For example, in the 'Away' state, I want to lock all my doors. I want that to trigger after the exit delay - not during the 'Arming Away' state because the deadbolt comes out while I am trying to close the door..
I think we will need to change the actual state representation in binding, such that the user selectable states are the arming states (besides off) and then switch over to the real state after arming.
The protocol has the appropriate support for these modes:
This has an impact to the driver, but I think its important to get this right before its released because I don't see a work around.
The text was updated successfully, but these errors were encountered: