Closed akalderon closed 6 years ago
Thank you for fixing this! I too am having an issue with the refresh button sending the disarm command. I also noticed if there is an alarm dot com login id that has limited access this will not allow user to arm or disarm but they can thru the website. Any idea why it won’t work thru smart app?
On Mar 3, 2018, at 5:43 PM, akalderon notifications@github.com<mailto:notifications@github.com> wrote:
Thanks so much for fixing the integration and a bunch of us want to send you money for your time and hard work.
Bug in the latest fix - Refreshing the switch (Arm Away or Arm Stay) causes a disarm event vs. updating true status of the switch. This worked in the prior version fine and was very useful as I was triggering a refresh based on several events to inquire if the alarm is armed away, stay or disarmed.
Seems like a typo / cut+ paste in the code line below?
'STATUS': ['params': ['command':'# disarm', 'silent': silent?'true':'false',...
I tried to update the command to: status and even to blank - seems like refresh does not update the switches. Please advise?
Thank you.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fschwark%2Fsmartthings-alarmcom%2Fissues%2F13&data=02%7C01%7C%7Cc107b777b72a437b1aa608d581608164%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636557173841348468&sdata=gZLQI5%2FfsNLjLM0jFSZunq3Uo%2FT0NDPVECdxRPELxgc%3D&reserved=0, or mute the threadhttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAZAwzrrPoabzSxpTbiDfHyGohsIjWTvAks5tayqEgaJpZM4SbIUa&data=02%7C01%7C%7Cc107b777b72a437b1aa608d581608164%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636557173841348468&sdata=9PVjHsYtbfOsnB5OZ%2FjQA371Ri8Nn1HTg%2BlT1eKpzF4%3D&reserved=0.
Changing:
'STATUS': ['params': ['command':'disarm', 'silent': silent?'true':'false', 'nodelay': nodelay?'true':'false'], 'name': 'Status', button: false]
To: (From original script)
'STATUS': ['params': [], 'name': 'Status', button: false]
Worked for me.
@ralphieq - This fix just subdues the 'disarm' active on refresh but does not restore the desired functionality to what refresh is supposed to be doing which is querying alarm.com to the status.
This is particularly of importance for the use case where you arm / disarm at the panel and want ST to poll and update status accordingly. I have a relay that does that in a hardwired manner (updates ST of arm/disarm status) but knowing if alarm.com is in away or stay mode required a status inquiry which was the way the old script was handling.
I am sure it is a small update for Schwark to figure out the new API and will await his response.
@akalderon Yes. I didn't catch the problem with refreshing the system state. Found out this was a problem when there was a desync between my mqtt bridge and the alarm state when arming through the alarm.com android app. Glad you posted as I thought I might have broken something in my config. Trying the latest push to see if everything is working now.
No dice as @adrian97c and others have posted. System status still not reporting.
It is a little iffy - I see socket timeouts on some calls. I have added some caching of some ids that I don't think change much to reduce the number of network calls - this should speed it up some and also make it more reliable.
Arm Stay doesn't work for me, shows successful web login but no command.
Looks like it is refreshing but somewhat inconsistently as per @schwark above. I'll do some more testing tomorrow as well. Thank you all for all your efforts!
Quick question - is there a way to switch to the ST git integration you just initiated without having to delete the current switches and smartapp? Basically link the repo version with the current instances on the backend? I have quite a few automation dependencies on the switches that I wouldn't want to recreate again if it can be avoided, yet, I'd like to leverage the git integration moving forward vs. the copy-paste.
Thanks again
Recent build (9:30a eastern) still requires tapping switches few times (sometimes it works perfectly)before command is successfully triggered. I’ll continue to test during next hour to test for accuracy/consistency.
Confirming inconsistent behavior on switch actuation registering with alarm.com on this end as well.
On the flip side, in this version the switches refresh status within 10 seconds of changes made in the panel without requiring an explicit refresh method to be called for each switch which is awesome :-)
By the way, answering my own question a few items above, i just published on the community page, a small tutorial on how to move existing code to git-based given that many of us may have several integration dependencies that would be a pain to recreate if we were to completely remove and redo.
I hope it is ok, @schwark and @bumpaneer - it is posted here.
Wife was so used to Alarm being disarmed with my ‘Good morning’ ST routine, but it didn’t send command due to the timeout bug, so when she opened the door alarm went off. Yikes that woke me up!
@adrian97c You're not alone on that one. WIfe has triggered the alarm three times in the past couple of weeks. Had the alarm on a schedule in ST to shut off in the morning. She leaves before me to work so it makes for one crazy alarm clock :).
@schwark Haven't seen any posts recently so not sure if fix is 100% but I wanted to point this thread out in case it wasn't. https://github.com/home-assistant/home-assistant/issues/12694
will not have time to look at it till the weekend - but I would recommend that you add a second scheduled event shortly after the first to try the operation again - it will probably work 100% of the time with two tries.
The issue is not the protocol - I have it working perfectly in python. The issue seems like the http implementation in smartthings and alarm.com new server are causing sockets to time out for some reason.
@schwark Gotcha. I'll give that a shot. Thanks much!
Thx for the updates @schwark hopefully this weekend will uncover the mystery with time-outs. Cheers!
Its still missing commands. I added backup commands as backup, but I tried taking off backup to see if it started working on its own again.. but sadly nope.
New update pushed, thx @schwark . I will start testing 👍🏽
Thanks @schwark - at first blush seems like it works reliably but i haven't tested heavily yet. Appreciate the hard work and attention
AND - at one point you cannot avoid the question anymore. A bunch of us want to send you money for your efforts - would you share your paypal or other means for doing so? No strings attached, promise!
agreed, after initial testing all 3 buttons are working reliably. I’ve added them back to my routines so we’ll see how it goes over the next few days!
thanks @schwark
“No strings attached, promise!”
*Until the next time it breaks...
j/k - ready to send some cash!!!
:-) ain't that the truth
@ryant80 look in here
Thanks so much for fixing the integration and a bunch of us want to send you money for your time and hard work.
Bug in the latest fix - Refreshing the switch (Arm Away or Arm Stay) causes a disarm event vs. updating true status of the switch. This worked in the prior version fine and was very useful as I was triggering a refresh based on several events to inquire if the alarm is armed away, stay or disarmed.
Seems like a typo / cut+ paste in the code line below?
I tried to update the command to: status and even to blank - seems like refresh does not update the switches. Please advise?
Thank you.