is there a command to get all of the existing modes
Is there a command or method to set hsmAlert to "intrusion", and if true, will it create an intrusion when hsmStatus is disarmed. (I know how to do it with a dummy device, want something that's more straight forward)
Is it possible to get HSM settings, such as delayArm and delayHome
Failed to find anything in the documentation and forum prior to posting.
Have a look here:
Andy
location.modes
That gives you a list of all the modes.
location.mode
That gives the current mode as text.
location.currentMode
That gives the current mode as a pair[id, name];
location.modes also gives the same pair, in case you want the id.
No, there is no way to put HSM into an intrusion alert other than by one of the sensors involved going into the right state.
No, there is no direct access to these values. They could be obtained with a virtual keypad device, as HSM sends them to keypads.
You could always use a virtual contact sensor added to HSM and then control that virtual sensor to put HSM into Intrusion.
That's how I do it in SHM Delay on ST, and how it will be done here on HE.
Yep, I remember it!
Hello Andy
Appreciate your response. I found and reviewed that information prior to posting my questions. With some of the system's documentation not yet finished, the only way to get info on some things is to ask, then share it with other developers.
Arn
Bruce
Thank you for the infomation.
I have one additional question.
In ST to get the date and timestamp of the last system alarm change I used the following
def alarm = location.currentState("alarmSystemStatus")
def lastupdt = alarm?.date.time
What is the HE equivalent?
I'm not sure. I don't think we implement location.currentState, but I can check. The other thing I'll have to check on is how to get a past location event. If you can get the last location event with a certain value, the event would have the time stamp.
Please remind me again about this....
Let me know. Using the following would be ideal
location.currentState("hsmStatus")
Edit: The above statement failed as follows
groovy.lang.MissingMethodException: No signature of method: com.hubitat.hub.domain.Location.currentState() is applicable for argument types: (java.lang.String) values: [hsmStatus] on line 31
If the location event table is accessible, that should be a simple loop until a hsmEvent is found.
How is it displayed in System Events->Location Events?
List<Event> getLocationEventsSince(String attributeName, Date startDate, Map options = null)
possible options is max number of results, otherwise it defaults to 10. ie getLocationEventsSince(attribute, startDate, [max:20])
Thank you Bruce.
If the startDate is omitted does the result begin with the latest event in the table. If startDate is required, is it the standard date time format and will it allow something that is a bit in the future to insure getting the latest events.
startDate is required, and it would be standard Date format.
You can do something like this:
myEvents = getLocationEventsSince("hsmStatus", new Date() - 1)
That would give you the hsmStatus events since yesterday.
Without the max parameter the command failed for me.
Initial successful test used max:20. The result is a LIFO event list which is exactly what I wanted, but based on the command name and date expected a FIFO list. Changed the count to 1, giving just the last hsmEvent.
*Wondered: what would occur if the latest hsmStatus occurred prior to the "startdate" would it be returned?
The answer is NO. I tried startDate of newDate without the -1, nothing was returned because my last event was prior to the Start datetime.
@bravenel Does using newDate() - 30 on the command, insuring something is ususally returned, create a bunch of overhead even when the max value is 1?
Useful Properties
Code
def myEvents1 = getLocationEventsSince("hsmStatus", new Date() - 1, [max:1])
myEvents1.each
{
log.debug "${it}"
it.properties.each
{ k, v ->log.debug "${k}=${v}"
}
}
Debug Log
2019-04-12 14:22:14.894 debugdisplayName=null
2019-04-12 14:22:14.893 debugsource=LOCATION
2019-04-12 14:22:14.892 debuglinkText=null
2019-04-12 14:22:14.890 debugdescription=null
2019-04-12 14:22:14.889 debugdata=null
2019-04-12 14:22:14.888 debugintegerValue=0
2019-04-12 14:22:14.887 debugdisplayed=true
2019-04-12 14:22:14.886 debugnumericValue=null
2019-04-12 14:22:14.884 debuglongValue=0
2019-04-12 14:22:14.883 debugisStateChange=null
2019-04-12 14:22:14.882 debugclass=class com.hubitat.hub.domain.Ev
2019-04-12 14:22:14.881 debuginstalledAppId=null
2019-04-12 14:22:14.880 debugunit=null
2019-04-12 14:22:14.878 debugtype=null
2019-04-12 14:22:14.877 debugtranslatable=false
2019-04-12 14:22:14.876 debugvalue=disarmed
2019-04-12 14:22:14.875 debugdevice=null
2019-04-12 14:22:14.874 debugarchivable=true
2019-04-12 14:22:14.873 debugphysical=false
2019-04-12 14:22:14.872 debugname=hsmStatus
2019-04-12 14:22:14.870 debugdescriptionText=hsmEvent
2019-04-12 14:22:14.869 debuglocation=null
2019-04-12 14:22:14.868 debugdoubleValue=0.0
2019-04-12 14:22:14.867 debughubId=null
2019-04-12 14:22:14.866 debugnumberValue=null
2019-04-12 14:22:14.864 debugid=470894
2019-04-12 14:22:14.863 debugdateValue=null
2019-04-12 14:22:14.862 debugdate=2019-04-12 13:14:36.062
2019-04-12 14:22:14.861 debuglocationId=null
2019-04-12 14:22:14.860 debugjsonData=null
2019-04-12 14:22:14.859 debugdeviceId=null
2019-04-12 14:22:14.857 debugunixTime=1555089276062
2019-04-12 14:22:14.846 debugdigital=false
2019-04-12 14:22:14.845 debugfloatValue=0.0
2019-04-12 14:22:14.839 debugcom.hubitat.hub.domain.Event@33587366
I don't know, but I doubt it. It's a db search, so I would imagine that the search ends when it's found the max number of values, and that the date is a qualifier tested to stop the search.
If the DB is defined with the datetime or unixdate as primary or alternate key and the search is ordered descending, the date is a where clause, and the max:1 is a limit, then the DB's optimizer should fetch one row, then stop.
At any rate, I'm going with -30 and putting in some code error code just in case nothing is returned.
Thank you once again for your assistance.
Easy enough to test this. Just take before and after time stamps.
I don't understand. Take timestamps of what?
The time, to measure how long it takes to run. Could just be log.debug... Try with Date() - 1 and Date() - 100.
Or
def stamp1 = now() get the events def stamp2 = now() log.debug "took ${stamp2 - stamp1} msecs"
Forgot about that simple timing technique. 
Ran each test -1, -30, and -100 on its own 3 times. Based upon the results it's my opinion that the startDate does not impact the DB fetch time in my situation, max: 1 event returned
2019-04-12 15:51:36.693 debugtestapp done
2019-04-12 15:51:36.692 debugdate - 100 took 37 msecs
2019-04-12 15:51:36.653 debugtestapp init
2019-04-12 15:51:15.137 debugtestapp done
2019-04-12 15:51:15.135 debugdate - 100 took 23 msecs
2019-04-12 15:51:15.112 debugtestapp init
2019-04-12 15:50:57.059 debugtestapp done
2019-04-12 15:50:57.057 debugdate - 100 took 47 msecs
2019-04-12 15:50:57.009 debugtestapp init
2019-04-12 15:49:25.222 debugtestapp done
2019-04-12 15:49:25.220 debugdate - 30 took 26 msecs
2019-04-12 15:49:25.195 debugtestapp init
2019-04-12 15:49:08.614 debugtestapp done
2019-04-12 15:49:08.613 debugdate - 30 took 33 msecs
2019-04-12 15:49:08.580 debugtestapp init
2019-04-12 15:48:51.131 debugtestapp done
2019-04-12 15:48:51.129 debugdate - 30 took 19 msecs
2019-04-12 15:48:51.109 debugtestapp init
2019-04-12 15:58:38.540 debugtestapp done
2019-04-12 15:58:38.538 debugdate - 1 took 32 msecs
2019-04-12 15:58:38.505 debugtestapp init
2019-04-12 15:58:18.770 debugtestapp done
2019-04-12 15:58:18.768 debugdate - 1 took 31 msecs
2019-04-12 15:58:18.736 debugtestapp init
2019-04-12 15:57:59.662 debugtestapp done
2019-04-12 15:57:59.660 debugdate - 1 took 33 msecs
2019-04-12 15:57:59.625 debugtestapp init
Download the Hubitat app
