Closed jtonk closed 2 years ago
Thanks, looks great!
by the way, I've created a new branche for the override.
I still don't know (if even possible) how to create a temporary variable that survives a second run of the automation. However I found out that you can hide the pin from the recorder so it's not logged. This is a solution but not so elegant.
There is one way that I'm going to look into and would prevent the whole necessity to create a temporary variable. A wait for trigger
that watches the Alarm event for failed to arm directly after the initial arming. So basically merge the two flows into a single long flow. This way you can use the normal blueprint variables.
That sounds like a great way to approach it -- nothing additional for the user to configure, and no extra leaking sensitive information. If you've got time to play with it, that would be awesome. Otherwise, I'm happy to take a crack at it over the weekend.
I tried to set it up, but got stuck because I can't get the alarmo event listener to pick up the response right after the initial arm request. I think there is a timing issue, the alarmo response is sent out before I can start the event listener.
I have a semi working version, but this always kicks in the override function and omits false passwords feedback, which is not acceptable. I need to rethink the strategy.
note... I was struggling with the .DS_Store a bit as you can see :)