So in short, yes... That's normal, and in my experience shouldn't be an issue.
tl;dr version: Since there is no true API and I had to use the web app calls, the app is bound to the web app behavior; Which is to expire a session after 10 minutes of inactivity. Now, if you set your polling to < 10 minutes, you in theory could continue to reuse the same auth token without a problem. However, us developers are a lazy bunch, and I wrote a single routine that just goes ahead and grabs a new session for every call (because someone could set polling to > 10 minutes and I didn't feel like coding out the two scenarios).
If you're concerned about the frequency of the polling, that's why I added the preference. And if you're like me, and you almost exclusively use your HE hub for panel interaction rather than the panel itself, you can set polling to a much less frequent value without much impact.
However, my concern on polling was more specifically on the performance impact to the hub than the integrated service itself. My old hub (ST) and app polled in a similar manner, and it never caused any issues in the 2+ years I used it. So I would be surprised if my method caused any service issues.
I have my poll setting at five minutes, and I may eventually back it off to 30 so the hub isn't unnecessarily stressing to fetch a status it almost certainly already has.
** EDIT: I also forgot to mention the auth tokens have a 24 hour expiration. So coding around that as well as the polling frequency is just unnecessary complexity over simply fetching a new auth token for every call. **
Oh I wasn't critiquing your method of polling or your app.
I was correcting your statement that polling didn't cause any issues on ST for the 2+ years you used it; therefore, you would be surprised if your method caused service issues.
Ok, but I think I noted my concern was on the HE hub performance, and that I hadn't seen any impacts on the service itself in my 2+ years of using one that polled (regardless of its source) in a similar fashion. Unless I'm mistaken, @steelz1 was asking about the ADC service impact and not hub compute.
Either way, I think we're speaking the same language here.
Been playing with this app a few days. IMHO setting the polling to 30min or even several hours if option was available shouldn't be an issue.
Unless your having really terrible service with your ISP.
In my 10yrs with alarm.com I've never seen there service skip a beat unless I was having internet connection issues on my end. I use cellular for everything living in BFE and traveling constantly.
I have a few zwave relays set to work off arm/disarm and this app should be the key to moving them off my alarm system. In fact one controls my well and water heater. Had a pipe break last night. It kept the cleanup to a few gallons instead of ankle deep water.
To that end, I've updated the app with additional polling options. You can now choose to poll as infrequently as every three hours.
I've altered my own to every 30 minutes, which should be sufficient enough for me.
** EDIT: I should note that I updated the option values (e.g. "30 Minutes" instead of "30") so they were easier to understand. This will, however, require you to re-submit your polling preference when you update the app. **
:). I had already added an option in my hub for 120 min... :).
Not sure it can be done but integration to all the sensors would be AWESOME. Although retrieving that information would probably need to be done differently.
This was the first thing I searched for when I got my Hubitat last year.
Again thanks. The arm/disarm abilities within the app really open up alot of potential for the HE.
I installed app and drivers fine.
Switches are created and visible in DEVICES.
I can add a tile that control the switch for ARM STAY.
I can activate it and deactivate it.
However it doesn't actually work.
I tried using a new login set to LIMITED ACCESS and allowed to only view and control one device the main panel called PANEL.
I tried with both my main login and then with the new login.
Any tips?
I get this in logs:
app:5452020-06-14 10:36:29.338 pm debugADC-App.updateSwitch(): Setting null-armaway to off
app:5452020-06-14 10:36:29.313 pm debugADC-App.updateSwitch(): Setting null-disarm to off
app:5452020-06-14 10:36:29.279 pm debugADC-App.toggleOtherSwitchesTo(): Toggling all switches that are not armstay to off
app:5452020-06-14 10:36:29.276 pm errorADC ERROR (setSystemStatus): groovyx.net.http.HttpResponseException: Forbidden
app:5452020-06-14 10:36:28.905 pm debugADC-App.setSystemStatus(): Attempting to set a panel status of: armstay
app:5452020-06-14 10:36:28.901 pm debugADC-App.getSystemAuthID(): Received sessionID (hsmqzbypq05mqq5dfyn1dsju) and afg (null)
That's weird... It looks like it's failing when attempting to retrieve your panel ID, which is required for interacting with the service. Alarm.com itself is returning an HTTP response code of 409... A very uncommon one, and not typically associated with get calls.
While I normally hate the "reboot" method for resolving an issue, have you tried uninstalling/reinstalling the app? I'd recommend trying that (again), and you may have to manually delete the switches the app created, since the IDs weren't properly set.
When you create a fresh install of the app, make sure you use your "full" account. I'm wondering if your limited account was a little too limited when you first tried to install the app, it failed to pull the panel ID, and things just went south from there.
I want to add that when I log into Alarm.com, if I log into it from a new device it does a 2 factor authentication where it asked to send me a code to my mobile phone and then asks me to save the new device (more like the browser) so it will be recognized the next time.
When I deleted the app, the switches got deleted too or at least they were no longer visible in DEVICES.
I was monitoring the logs as I created the app again. Here's what they showed after I pressed DONE:
app:5462020-06-15 10:29:18.055 am errorADC ERROR (getSystemStatus): groovyx.net.http.HttpResponseException: Conflict
app:5462020-06-15 10:29:17.689 am errorADC ERROR (getPanelID:GettingPanelID): groovyx.net.http.HttpResponseException: Conflict
app:5462020-06-15 10:29:17.086 am debugADC-App.getPanelID(): Received accountID (5374861)
app:5462020-06-15 10:29:16.227 am debugADC-App.getSystemAuthID(): Received sessionID (htjkzxnrpbl3vg2kte2tqf0i) and afg (psk8ApjDLPI65JeOAoNdOg==)
app:5462020-06-15 10:29:15.362 am debugADC-App.getSystemAuthID(): Getting refreshed authentication credentials
app:5462020-06-15 10:29:15.358 am debugADC-App.getSystemAuthID(): Received sessionID (bo3vfkep24tz5nm4qimo04fb) and afg (0up4QJI/0KI+YqEVSWsyfQ==)
app:5462020-06-15 10:29:14.444 am debugADC-App.getSystemAuthID(): Getting refreshed authentication credentials
app:5462020-06-15 10:29:14.392 am debugADC-App.initialize(): Panel polling set for every 1 minute
app:5462020-06-15 10:29:14.383 am debugADC-App.initialize(): Initializing Alarm.com Manager
app:5462020-06-15 10:29:14.380 am debugADC-App.createChildDevice(): Child device null-armaway created
dev:6462020-06-15 10:29:14.347 am debugADC-Device.updated(): Switch updated
dev:6462020-06-15 10:29:14.334 am debugADC-Device.updated(): Switch installed
app:5462020-06-15 10:29:14.273 am debugADC-App.createChildDevices(): Creating child device: null-armaway
app:5462020-06-15 10:29:14.266 am debugADC-App.createChildDevice(): Child device null-armstay created
dev:6452020-06-15 10:29:14.232 am debugADC-Device.updated(): Switch updated
dev:6452020-06-15 10:29:14.219 am debugADC-Device.updated(): Switch installed
app:5462020-06-15 10:29:14.156 am debugADC-App.createChildDevices(): Creating child device: null-armstay
app:5462020-06-15 10:29:14.150 am debugADC-App.createChildDevice(): Child device null-disarm created
dev:6442020-06-15 10:29:14.099 am debugADC-Device.updated(): Switch updated
dev:6442020-06-15 10:29:14.086 am debugADC-Device.updated(): Switch installed
app:5462020-06-15 10:29:13.984 am debugADC-App.createChildDevices(): Creating child device: null-disarm
app:5462020-06-15 10:29:13.975 am errorADC ERROR (getPanelID:GettingPanelID): groovyx.net.http.HttpResponseException: Conflict
app:5462020-06-15 10:29:13.626 am debugADC-App.getPanelID(): Received accountID (5374861)
app:5462020-06-15 10:29:12.725 am debugADC-App.getSystemAuthID(): Received sessionID (ov12hydnyytbfzwdb5nkv4gj) and afg (a5cgyqtPYUsKkFFr5WkmaA==)
app:5462020-06-15 10:29:11.862 am debugADC-App.getSystemAuthID(): Getting refreshed authentication credentials
app:5462020-06-15 10:29:11.858 am debugADC-App.installed(): Installed with settings: [password:, disarmOff:Do Nothing, encryptPassword:true, debugMode:true, pollEvery:1 Minute, username:user_email, encryptedPassword:0E6J4xd6Vlf557gwrGzj6Q==]
app:5462020-06-15 10:29:11.844 am debugADC-App: Password encryption requested, and successfully completed
OK I got it, see logs at bottom. Here's what I did to get it running.
Create new login within Alarm.com (Users-->Manage Logins)
Set this user to Limited Device Access and then Arming setting should be the name of your panel. Mine was literally "Panel"
This Login must have a unique username and email address. Hint: If you do not want to create a new email just for this, GMAIL allows your email to have additional periods and still be received. For example username@gmail.com is the same as user.name@gmail.com. You still need to set that login's password which is weirdly missing from the Alarm.com interface.
