The format should be:
smartthings edge:drivers:logcat --hub-address=192.168.1.11
Make your selection when the prompt pops up.
1 Like
That worked thxā¦appreciate you breaking that down for this big ole dummy:)
Ran the log and it appears I am getting a bad password:
2022-10-26T14:35:04.346262192+00:00 INFO Honeywell-Ademco Envisalink Attempting to reconnect to EnvisaLink
2022-10-26T14:35:04.444868067+00:00 INFO Honeywell-Ademco Envisalink Re-connected to Envisalink
2022-10-26T14:35:04.450750108+00:00 DEBUG Honeywell-Ademco Envisalink driver device thread event handled
2022-10-26T14:35:04.457480983+00:00 TRACE Honeywell-Ademco Envisalink Received event with handler _resync
2022-10-26T14:35:04.468380067+00:00 DEBUG Honeywell-Ademco Envisalink driver device thread event handled
2022-10-26T14:35:04.472039108+00:00 DEBUG Honeywell-Ademco Envisalink driver device thread event handled
2022-10-26T14:35:04.475923358+00:00 TRACE Honeywell-Ademco Envisalink RX < Login:
2022-10-26T14:35:04.478886567+00:00 INFO Honeywell-Ademco Envisalink Received login password request; sending password
2022-10-26T14:35:04.481792692+00:00 TRACE Honeywell-Ademco Envisalink TX > **********
2022-10-26T14:35:04.492500817+00:00 TRACE Honeywell-Ademco Envisalink RX < FAILED
2022-10-26T14:35:04.495480608+00:00 ERROR Honeywell-Ademco Envisalink Envisalink login failed - incorrect password
2022-10-26T14:35:04.502779400+00:00 DEBUG Honeywell-Ademco Envisalink Receive status = closed
2022-10-26T14:35:04.505750317+00:00 ERROR Honeywell-Ademco Envisalink Socket Receive Error occured: closed
2022-10-26T14:35:04.508709733+00:00 WARN Honeywell-Ademco Envisalink Envisalink has disconnected
2022-10-26T14:35:04.643103983+00:00 DEBUG Honeywell-Ademco Envisalink driver device thread event handled
2022-10-26T14:35:19.656274443+00:00 INFO Honeywell-Ademco Envisalink Attempting to reconnect to EnvisaLink
2022-10-26T14:35:19.744471318+00:00 INFO Honeywell-Ademco Envisalink Re-connected to Envisalink
This is a bit odd considering that same password I currently use to connect to Envisalink website to log into my account successfully?
1 Like
Itās not the website password. Itās the password you use for the local Envisalink interface that comes up if you type 192.168.1.11 (or whatever the Envisalinkās local IP is) into a browser. I believe default password is user.
Oh okā¦this time I did leave the default as āuserā just to try and it appears to be working. One thing I noticed is that I do not have āArm Maxā as a virtual switch under the No room assigned category. The only ones I see are HW Switch armStay|1 and HW Switch armInstant|1?
I believe I would need the Arm Max as a switch that way I can create a āroutineā to automatically turn on / off at a certain time like I did before. We always use Arm Max at bedtimeā¦am I missing something?
The virtual switches are only necessary for third party integrations like Alexa/Google. You can create native ST routines for arming/disarming using the partition device - no virtual switches required.
You do need to make sure that that arm mode is enabled for it to show as an option. Go into settings on Partition 1 and make sure the Display 'Arm Max' mode option is turned on.
If you do want the virtual switch for that mode, it needs to be enabled for display as noted above. If itās still not showing up, try toggling the Add Virtual Switches option to trigger it to try to add them again.
Looks like the remaining virtual switches finally showed up on the āNo Room Assignedā screen. I like having all of them anyway in case I want to arm / disarm using Alexa.
Everything appears to be up and stable now that I got the password issue straightened out. Thx everyone for your assistance and sorry I was such a ānewbā during the t-shooting process:)
2 Likes
No worries! We were all once newbies with all this!
1 Like
This integration works EXTREMELY WELL. Iāve been able to use it to replay my Honeywell Tuxedo automation with SmartThings.
I originally tried to do this with Konnected - which worked - but required wiring as well as did everything through āthe cloudā. This allows Smartthings to locally get status from Envisalink.
Iāve encountered two small āglitchesā in the course of unwiring the Konnected and updating to Envisalink.
1.) I had to turn off the alarm panel. Smartthings ceased to work with the Envisalink until I rebooted the Smartthings hub
2.) Similarly for some reason I found a sensor out-of-synch and rebooted Envisalink. Smartthings again ceased to work until the Smartthings hub was rebooted.
These were minor issues, easily fixed by the reboot. Not being driver savvy Iām not sure if something could be done by in the driver ( @philh30 ) or if thatās just part of the Smartthings architecture that is a limitation.
Regardless - itās an AMAZINGLY WONDERFUL thing. Love it!
2 Likes
I moved to this device driver from redloreās. Had to reboot hub and toggle āadd zonesā several times to detect all 37 sensors. Seems like the highest wired zone is for which are not battery powered devices. Or perhaps how many devices to search for.
@jonj Iām glad itās working out for you! Iāll take a look at the reconnect logic to see what can be improved. For now, a workaround to try to force an attempt to reconnect is to change the Envisalink IP address in the settings menu, then change it back to the correct value.
Iāve seen other developers have trouble when creating too many devices at once. I didnāt run into that myself, but itās been a while since I set up my own alarm system. It might be best to just list a few zones at a time for creation.
This is correct. Any zone # above whatās set as the highest wired zone is assumed to be a battery powered sensor and assigned to a profile that includes the battery capability. The profile can always be swapped later though through the zoneās settings menu.
1 Like
Just as a data pointā¦this usually seems to happen when the system is armed. āThisā being the zone shows āopenā even though it is closed and, hence, the controlled device stays on.
The other night it happened, the zone was stuck āopenā again even though closed. I changed the IP address to toggle things on/offline and it had no change. The closed zone still showed opened - and controlled fan on. However I toggled the system out of STAY mode into DISARMED. The zone status IMMEDIATELY changed and became normal (closed) and the controlled fan went off.
So toggling from armed to disarmed seems to correct it.
Does that give you any clues? Curious, eh?
One other experiment. I armed the system. Turned up the temperature which triggered the zone from closed to open. The driver did NOT report it open, it remained closed. Ditto if it was open when I put the system into armed state.
So it seems that the contact sensors arenāt getting updated properly if the system is in armed/stay at least.
Hope that helps!
j
Youāre running into some of the limitations of the data that the Vista provides to the Envisalink. The Vista wasnāt designed to support home automation, and the data that the Envisalink gets is limited to what you see on one of the custom alpha keypads. I can rant at length about how challenging the data is, but the two things that are primarily impacting you:
-
When the Vista is armed in stay mode, interior zones are treated as if they were bypassed. The Vista stops reporting whether theyāre faulted.
-
The Vista never actually reports when a faulted zone clears. The only data that the Envisalink (and therefore this driver) gets is what you see on a custom alpha keypad - a continuously cycling list of the currently faulted zones. The driver has to infer when a zone has cleared, either by seeing enough keypad updates come through without another report that the zone is open or by seeing that the partition has been reported as disarmed with no faults.
So, in your case, the zone is reported as faulted prior to arming. Once the system is armed, thereās no data to indicate whether or not the zone has been cleared. Absent any data, the driver leaves the zone in whatever status it was in.
Something Iāve done with my own system that could help in your case is that Iāve moved all of my interior zones to partition 2. That way, theyāre still actively reporting status when I arm stay partition 1 since 2 is still disarmed. Partition 2 also has its own queue for faulted zones, so an added bonus is that zones clear quicker and more accurately on both partitions than they would if they were combined. The one challenge with this setup is if youāre wanting to arm both partitions and have the siren sound for both - I have big dogs that trip my interiors all the time so thatās not something Iāve bothered to figure out.
By the ways, changing IP address is only a workaround if you have ST disconnected from Envisalink and it isnāt reconnecting. For a zone out of sync, restore the partition to disarmed/ready, and then if the zone still shows open swipe down on the device in the ST app and it should clear the fault.
1 Like
Thanks so very much for explaining that. It makes sense from a system point of view to minimize overhead and not track āinteriorā stuff if youāre monitoring for threats. But, as you say, in the context of a home automation system, not so much.
Iām going to look at moving those things to Partition 2. That seems reasonable. Iāve only got two of them and it should be easy to experiment without me melting down the system or the monitoring company. (grin)
Iām using zone type 23 - non-reporting zone. So I guess it treats that as āinteriorā when armed and doesnāt actively report status.
I also was wondering if programming a custom zone may work too. Will have to look at that option. The custom zone option has 10 entries. It would be nice if the standard zone types showed how they would be represented as ācustom zonesā to use as a template to tweak.
Again, thanks very much for explaining that! Makes perfect sense.
REgards,
j
1 Like
I donāt think that a custom zone type would get you around this limitation, though Iāve never experimented with them. I used the term āinteriorā since thatās what applies in my set up, but to be more exact I think that when the system arms it stops reporting on anything that wonāt sound the alarm. I could be wrong though!
The only other drawback I can think to mention with partition 2 is that each keypad has to be assigned to a partition (though you can swap between) and will only display faults related to that partition. Maybe not something you care about though depending on how youāre using those zones.
Phil:
Your suggestion worked well so far. (nothing blew up!)
The steps were:
1.) On the VISTA 20P - Enter programming mode +800
2.) *56 to enter zone programming
3.) Access zones and change from partition 1 to 2
4.) Select a keypad address, in my case I used 20, and change it to Partition 2 using the *19x menu
5.) *99 to exit alarm programming
6.) Login locally to Envisalink and use the keypad address (20) to report partition 2
In Smartthings Android interface
7.) Delete the sensors that I moved to Partition 2
8.) Access the Panel and SETTINGS of Panel to enable Partition 2
9.) Make sure āautomatically add zonesā in SETTINGS of Panel is enabled
10.) Toggle the IP address of PANEL to something junk, wait for it to go offline, then toggle it back to refresh everything
At that point, the new sensors should appear. Rename them, add them to routines.
Finally, login to TOTALCONNECT and RESYNCH PANEL since zones have changed!
A lot of small steps that really werenāt too bad.
Just wanted to document the above for others who may want to try this.
Again, thanks so very much!
Jon D.
1 Like
Be sure to go into settings in the app for each of those zones and change the Partition option to 2. The driver uses that setting in the logic to determine when zones should be considered clear.
i need to redo or rethink my automations and virtual switch syncing for security states. anyone have a solid system they are using for that?
edit:
as a baseline, this is what I was originally using.
in the previous integration, the virtual switches and webcore pistons were needed to update STHM which couldnāt interact with STNP. virtual switches were also needed to work with Alexa.
i spent some time this evening reworking the routines a bit, and i think theyāre mostly ready and functional, though i do need to do more testing. Using the STHM ā Partition Integration option in the settings helps simplify things a bit, however while messing around in the Alexa app I remembered that I had installed the Eyez-On Skill which directly set up my Panel as a device within Alexa. Routines can even arm the system (but not disarm). Given that, I may be able to get rid of most of these routines altogether and possibly even the virtual switches. gonna play around some more
so i just tried testing my smoke and CO alarms again and today neither of them triggered in ST. they work fine on my panel, in the envisalink, and my door sensors are working properly too including in ST. anything else i should troubleshoot on my end?
I assume youāve done the same test previously and they worked in the past? And by not working, you mean nothing is happening in ST on the device for that zone (as opposed to a failure to trigger a routine or STHM)?
The best troubleshooting would be to capture hub logs when you test your smoke sensors. If you havenāt used logging with the CLI before, I have basic instructions here. When a zone is tripped you should see the raw message received for m the Envisalink followed by a few lines indicating the events the driver is generating in response.