And this is AFTER you’ve selected and saved a Partition Status value?
Does the routine appear to be working regardless?
I’m pretty sure I had exit delay in there previously- but not entry delay.
EDIT: And Disarmed was also newly added.
Looks like you are running on the 2.0 version. This latest (2.1) was released as separate, new driver, meaning it doesn’t update the older 2.0 version. This was done to minimize disruption and give you control over when you wanted to move to the new driver.
If you are ready to do that now, what you’ll have to do is refer to this original announcement post, but note that the latest driver version is now 2022-03-21T20:58:20.227208
FYI @TAustin - After auto updating to the latest driver I had to go through a few steps to get things working again. I’m not 100pct sure which step was the resolution but here is what I did. (I was already on driver v2.1 prior to the auto update yesterday).
- Late last night after recognizing that all devices had been offline for 4 hours, starting at exactly the same time. I checked to see if the new driver had been installed. It had.
- I rebooted the hub. This did not start the data flowing.
- I changed the envisalink LAN IP address in the driver config to an address that is not used on my network… Let it sit for a while… and then moved the IP address back to the real envisalink device.
- I rebooted the hub again.
- Things started working.
I’m not sure if step 4 was actually needed … it was late and I was rushing though my debug.
Thanks for reporting that. It is probably the case that for some reason the new driver was not connecting to the Envisalink and you did the right thing resetting the IP to force it to reestablish the link.
Hi @TAustin I’m running into the same problem as @Delgreco007 when I tried to update from the beta to the latest 2.1 driver. I followed the instructions and deleted the old beta driver and all the devices. I’ve confirmed via CLI that there are no Edge driver installed.
Using CLI, I then loaded the latest Edge driver, which CLI confirmed was installed. When I go into the Mobile app to scan/discover the new panel, it finds a DSC Primary Panel. I then exit out the device discovery/scan page. But when I go to the unassigned room and tried to click on the new DSC Primary Panel, it says “Can’t connect to device. Check device and try again.” When I hold the panel down and click “Edit”, it doesn’t seem to give me any way to configure the device (no three dots at the top right corner).
No, that was after the driver had updated, so I just edited the routine, and yes it does work.
I’m going crazy, Driver update and firmware update at the same time = Crazy LOL
@nayelyz can you please look at this post and share any thoughts you might have? I have recently released an update to one of my drivers and there appears to be a lot of issues - this being only one of them, but to me this definitely sounded like a SmartThings platform issue and not a driver problem. What do you think?
So, currently, there are only two users with this issue, or is it in general?
I’ve seen that error when I make tests, even for other integration types so it could be caused by different reasons.
@rvs007, have you tried the following?
- Rebooting your Hub
- Clear the SmartThings app cache
If that doesn’t solve the issue, please, I need your help to send me over DM the following:
- Email account you’re using
- Log of the complete discovery process of the device
- Device ID (the one that says “can’t connect”)
- Channel ID
- Driver ID
- When you replicate the error, send the Hub logs through the IDE (this has more information that is useful to the team). You can do this following these steps:
- Go to the IDE
- Select “My Hubs” and enter the corresponding one
- Go to the bottom of the list where there’s an option reading “View Utilities”
- Enter that option and inside, there’s an option to send the Hub logs.
Thanks for your assistance. He’s the only one I’ve seen with this particular issue.
The others are experience problems at the point where the driver is supposed to be creating additional devices. The initial ‘creator’ device gets created just fine when they do Add device/Scan nearby. But when they are using that device (through Settings) to create additional devices, they aren’t getting created. It seems to take multiple attempts and driver uninstalls & reboots to get it to work. Once person said it worked fine on one hub, but had this problem on another.
Whenever I see issues with devices not getting created, it’s usually because there’s a conflict with the device_network_id. So I always advise making sure any ‘old’ devices have been deleted. The other reason may be something wrong with the profile, but as these issues don’t always occur, I don’t think that would be the problem. Of course I have tested numerous scenarios and don’t have a problem on my hub. I haven’t yet gotten a log from anyone showing exactly what is happening as they don’t always have the CLI available.
Before I remove the devices and the beta Edge driver to try installing v2.1 again, can you tell me how to clear the ST app cache (I’m using iOS). Thank you.
Ooh sorry, that option is only available for Android devices. What others do to force a refresh is to reinstall the SmartThings app…
Hi
This driver is quite life changing so thank you. However in the past few days it has started failing. I get a
ERROR Envisalink 2.1 Socket Receive Error occured: closed
2022-06-12T18:52:21.139240473+00:00 WARN Envisalink 2.1 Envisalink has disconnected
When I reboot the Envisalink board it works momentarily then once again fails.
I have reinstalled the Edge driver from scratch with no improvement 
I’m sorry you are having problems. Has there been any change to your hub firmware lately? There have been some reported issues related to that.
Is there any other way you can test your Envisalink connection to make sure you don’t have a failing board? Can you connect to it with your browser OK?
@TAustin I installed v2.1 several weeks ago - I’ve been waiting for this functionality for a long time so thank you! Everything was working great until a couple of weeks ago. I created a few basic automations - one using the panel and a few using sensors. Two of the sensor automations no longer run:
Motion Sensor: If some preconditions are met, motion sensor ‘On Motion’ will change location status to Home. I can see the status changing in real-time on the room/group UI card, but when I tap on the device, the status permanently shows ‘Alarm!’. I was testing the alarm around the time this stopped working (triggered it with the motion sensor). I’m wondering if this has something to do with it?
Contact Sensor: When status is ‘Open’, send notification. Interestingly, I have another automation that will send a notification/text if left open for 2 minutes - this still works.
I haven’t tried any significant resolution steps yet, but since this is till somewhat “beta” I wanted to report it for you or others who may have similar issues. I’m thinking I may try the IP change to see if that will “refresh” the status with Envisalink. Any other thoughts?
Hi there. If you tripped the alarm then the device that caused the alarm will show “ALARM!” status until the next time you rearm the system. Once you arm the system, Zone Status should clear and show normal active/inactive or open/closed status.
This is to allow you to see which zone caused an alarm - analogous to the DSC panel ‘memory’ function.
Ahh, that seemed to do the trick - Thank you!! Are there two different “statuses” then? What attribute does the device card use to show the status? Because I could see it changing to motion/no motion, but tapping on the card the zone status showed “Alarm!”. Seems like the automation is using whatever status is tied to the “Zone Status” shown after tapping on the card.
As far as the contact sensor, I made some changes in the automation so the ‘save’ button became available and that seems to have restarted the notifications.
Thanks again!!
The ‘Zone Status’ attribute is kind of a hybrid status of the device capability (e.g. motion or contact) and additional DSC-related states. What you are seeing on the device card is purely the capability state, so that’s why you can continue to see it changing even if the Zone Status attribute is showing some DSC-specific value (e.g. Alarm!). So yes, your automations are going to be keying off the value of Zone Status, so need to take into account the possible additional values.
I’m not sure what you mean by this.
For everyone’s awareness, a recent change in the SmartThings platform has broken a lot of the custom switches that are used in Edge driver devices, and unfortunately this affects this driver as well - specifically the arm stay and arm away switches on the device Controls screen. I am going to have to release a new driver to fix this, so expect that in the next week or so. Unfortunately it cannot be fixed for existing devices, so the driver will not be an update to the existing one, but rather a new driver and will require you to recreate your devices. I say this just to warn you not to build too many automation routines that you will have to redo.