Thanks for this. I will just keep track of the mode instead of asking the hub for it. Should be an easy fix for my app but I still think this type of workaround hack should not be needed.
I understand why you feel a work around should not be needed. My work history is serialized business code for Mainframe batch, Mainframe Online, then websites. When I first began coding in ST, I bumped into timing issues, also bumped into a timing issue a few days ago while working on an HE app.
HE is a real time system, likely with multi threading, perhaps multiple cores, not serial. So that SendLocationEvent once executed is not instantaneous, it first has to be queued, then processed, and removed from the queue, meanwhile your app continues processing. In this environment it's entirely possible that your request receives the previous state, or perhaps not. I've also never figured out if there is an Enq/Deque Groovy method for a resource, and even if there is such a method, we don't have access to the internal resource name.
1 Like
I still don't understand what is not working for you, or why. Haven't had a lot of time. Have you looked at Location Events?
RM is using this same interface and works as expected. After sending "hsmSetArm" with "armAway", HSM responds with a bunch of events (not sure why the duplicates -- worth looking into, but a separate matter).
The first event above (the bottom one) was from RM setting armAway. The other 4 are from HSM (as shown by "hsmEvent".
And after this sequence, location.hsmStatus is correct:
log.debug "hsmStatus=$location.hsmStatus"
debug hsmStatus=armedAway
And, HSM UI shows the correct state:
Try this in your test app, while your system is disarmed
sendLocationEvent(name: "hsmSetArm", value: "armAway")
def arm2=location.hsmStatus
log.debug "arm2: $arm2"
result is always disarmed (on my system)
Glad it is working in RM but it isn’t working for me. The sequence that @arnb describes matches what I see. I will fiddle with it again but I think it is an issue with my latest hub update. This behavior didn’t happen before I updated recently.
I reported that issue with a suggested system solution a few days ago.
This all arose from a developer request many months ago. I don't recall the specific reasons involved, and haven't had time to dig into it.
Your suggestion of not issuing armAway when state is armingAway makes no sense, as it must transition from armingAway to armedAway.
Revisiting this is not high on our list right now.
I found the easiest way (for me) to handle this was with atomicState, tried state but was surprised when it did not work as expected. Likely due to state not being saved to app ends and atomicState is instant update. Looking at the hsmStatus queue worked but due to multiple armingAway events I was forced to use time on the compare. Decided to use atomicState instead.
Sample code
def alarmStatusHandler(evt)
{
def theAlarm = evt.value as String //curent alarm state
def lastAlarm = atomicState?.hsmstate
atomicState.hsmstate=theAlarm
then to dump the dup armingAway/Night/Home events
if (theAlarm == lastAlarm)
return false
My situation occurs when issuing a Mode change to Away, which in turn issues the armAway when HSM is set to adjust State from Mode.
I'm suggesting suppressing the armAway in this situation, not when a armAway is issued directly by code.
Meanwhile I have a simple workaround that will work even if this is changed.
But there could be other listeners for the armAway event, so it has to be thrown.
If it occurs while in state armingAway, and I also change the mode to Away, it creates a immediate duplicate armingAway event. Makes no sense to me. 
In my case, using armingAway to trigger a TTS message, created double speak without the workaround.
I change the mode to keep it in sync with the state.
Yes, I know, but I don't yet know why yet.
1 Like
Oh my, just went to work on this, and now it won't duplicate the armingAway event for me. Sending armAway from another app results in these events:
That looks correct. What sequence gives the duplicate armingAway event?
Sending a private message with code and github
Where did you see the HSM UI 
I see nothing like that in my system. All I see is the following which isn't very useful:
Okay - I get it. My setup isn't working because I'm not actively using HSM. I thought HSM had its own internal settings for away, home, night as ST does but I see that was a bad assumption. Within ST I also don't use SHM but I can still set the SHM status to away, home, and stay. I was trying to do the same here. At least now I know what I need to do. For what it's worth seems to me you would want to have a generic capability to set HSM to away even if you don't have any sensor tied to this mode. Anyway, i understand your design language now and I will adapt my app accordingly.
How does it make sense to Arm Away if you have nothing to trigger it and nothing to alert with it? What does that accomplish?
One person sets "Arm Away" and it shows on the panel. Second person arrives home and sees this set. Tells them the intent of the first person who left. Another perhaps more practical use is if a third party app reads the status of Arm Away that Hubitat doesn't know about. The more practical scenario is for future expansion of HSM use - allowing the intent to be implemented even before the practical application is active. All that said, I get why you did what you did and I'm not even asking it to change. I just found it confusing that it was different than what I expected from how ST works. I know there isn't any love there but my app has to play nice with both and I bounce back and forth so when I find random inconsistencies like this it confuses me. Thanks again for giving me some of your precious time on this. I know how busy you are. I now have what I need to fix my HousePanel app.
I use an App to sync my Hubitat's status with my ADT system. I created virtual sensors for this.
