Can’t say I’m surprised. That app started out buggy and just keeps getting crappier with every release.
I have been communicating with John Costantelos on the Vista/EyezOn/ST integration. I thought I had it working but still having issues. This is what I sent to John if you have any thoughts.
Not sure where to go from here. Verified the account ID and device ID in IDE and ST against EyezOn link, all ST virtual switch settings for both away and stay switches but nothing arms with either stay or away.
What happened when I pressed Stay switch is button which was showing ON went to OFF. I then touched it again and it went to on and then immediately back to off. No arming of panel BUT panel did light up so I wonder if panel is getting some signal!
tried the same thing with AWAY switch and identical behavior as stay. Button was showing ON went to OFF. I then touched it again and it went to on and then immediately back to off. No arming of panel BUT panel did light up.
Tried STAY button again and same behavior except button was showing off initially, went to On then immediately back to OFF but panel did light!
Any thoughts? I may just give up for now but thought I was so close."
I know there are issues with the buttons showing correct status due to app limitations. Having said that the arm/disarm should still be working correctly. Given you’re getting some feedback from the panel at least it means the request is going through, so probably you have something that’s not correctly configured. Did you try both variants provided? If so, what are you seeing in the logs?
When I thought I had it working yesterday I tried variant 1 first with no results and then went to variant 2 which worked initially. When I had difficulties thinking things were out of sync, I generated a new link from the EyezOn website to try again but I didn’t think of trying variant 1 again. Are you thinking I should try that next? I don’t know where the logs are nor how to read them.
I went ahead and deleted variant 2 and copied and pasted variant 1 code and tried the STAY again. No arming but panel did light. Don’t know if the next step is to delete everything from IDE devices & device handler and generate new EyezOn link again and start over.
You said variant 2 worked initially. So what made it break after that then? I’m thinking based on that there’s no point of trying variant 1 then. But you do need to make sure you have all your settings configured correctly.
You can find the logs in the SmartThings IDE. Unfortunately parts of this setup process are quite technical and it would indeed be great if EyezOn added a stock built-in device handler for SmartThings - would’ve made everyone’s lives much easier.
It worked initially with the first link I created in eyezOn webpage but later I was on that page and inadvertantly deleted that link and so I had to create a new one and start over and from then I haven’t been able to get it to work.
Would I just need to delete everything from IDE groovy and my ST app, creat a new link in EyezOn and start creating everything again?
The way you’re describing it it really sounds like a misconfiguration somewhere in there. I suppose surest way would be to just nuke it and start over. Alternatively if you can find the logs you can try to check what’s going on there (though that’s not guaranteed to give you anything given EyezOn servers aren’t particularly good at returning useful error messages, or any error messages for that matter.
Vadim, well now I think it is working. After checking for extraneous spaces in the fields and not finding any I went into IDE edit preferences and cut and pasted and reentered all fields (account ID, device ID, partition number and label disarm code. It worked properly on arm stay and disarm stay and arm away but NOT disarm away so I’ll reenter the disarm code in the edit preferences field in IDE and try it later. You indicated IF it arms but doesn’t disarm that it must be the disarm code. Correct. If that works then it appears it MIGHT be working correctly but I never found anywhere in any fields where I had extra spaces or characters or typos and I checked it very thoroughly. Am I also correct to ignore what the ST app buttons say for these 2 switches as they may not be in sync with what is actually going on armed/disarmed vs. button ON/OFF?
Yes those buttons will not always display correct status due to the fact that EyezOn servers weren’t built for this use case and do not support a push update. So the main purpose for this handler is to provide you with virtual switches which you can then use to run all sorts of automated routines (e.g. automatically arm house when you leave, or disarm when you’re back).
And yes if it arms but doesn’t disarm it’s very very likely related to that disarm code. Sounds like you should be using the IDE to set it up seeing the issues you’ve encountered entering fields directly in the App. Make sure to check for any spaces before/after and make sure characters are correct.
Vadim, as always thanks for the help. I think it is working both stay and away, arm and disarm. I can only assume that when i followed your github instructions initially and entered all the fields via the app, that those fields had been unpopulated and all the new info I entered entered correctly. When I had to create the 2nd EyezOn link and repopulate those fields a second time in the app that something didn’t enter correctly. I tried several times to look for blanks and such but not until I reentered the fields in the IDE Edit preferences did things start working. Strange! Regarding the buttons I guess it won’t matter once I create the routines. One more question just to be sure I get this. Say I want to create a “goodnight” routine/automation which I’ll execute when I go to bed where I would want that routine to lock our front door and arm the system for stay, I would just “call” the stay routine in my automation. Likewise, if I created a “good morning” routine to unlock front door and disarm alarm I would again call the “stay” routine again. Am I correct here?
I’m glad to hear you got it all working. I’m actually using it together with Alexa myself so when I say “Alexa, Good Night” it auto-arms the alarm (along with turning off all lights, etc.). Essentially what you’ll be doing in your routines is turning on/off the virtual switches you created (in particular, the “Stay” one) - this is really analogous to how you’d turn on/off any other physical switch that turns on/off some device. Hope this helps.
Vadim, just to be sure I understand correctly if I were to create a goodnight automation say that triggered at 10pm then the then condition would be to turn “on” the armed stay switch to arm our Vista system in Stay mode and likewise if I created a good morning automation that triggered say at 6am then the then condition would be to turn “off” the armed stay switch to disarm the Vista system? Do I understand this right?
I think you meant to say the Action (under “Then”), NOT the Condition. But yes that’s the general idea.
Thanks. To test I tried setting an good bye automation to Away arm the system IF both our phones were away from home for more than 1 minute but it is not executing. Would I need to add a condition for the location mode as well?
I wouldn’t bet on the geolocation feature working (i.e. execute when phones are away/back) - I know it’s completely broken for me on iPhone 6 (thanks "Smart"Things!).
In any case I suggest you start by using some light bulb or physical switch to make sure it executes correctly, and only then once you confirm it’s triggering correctly replace the switch with the EyezOn virtual switch (assuming you already tested that switch in isolation i.e. by manually trigger arm/disarm).
Will do though it still seems the away disarm operation is intermittent. I confirmed working yesterday but when I manually execute away disarm (away arm seems to work just fine) nothing happens. I know you said it must be an issue with code I entered but I haven’t touched anything in device setting in app or on IDE since yesterday. I’ll keep watching it.
Note that if you try to arm system, then disarm right away, it may not work. Reason is that EyezOn will flip into “Busy” mode first and so the validation that this code makes will fail since it cannot guarantee that the system is in the correct state. It’s only after EyezOn goes into “Exit Delay” or “Armed” state will it be able to perform the disarm. Also note that you cannot arm using the Stay switch, then disarm using the Away switch, and vice-versa. Either way looking at the logs would go a long way to help explain what’s going on.
I waited a couple of minutes after arming away before trying disarm away and was sure not to arm using STAy and disarm using AWAY or vice versa. I’m in IDE, clicked on Eyez-on_away and then on events but not sure what all the events tell me.