Sounds like what I was seeing
No clue. It was doing the same with the Off command as well (as I showed you in my logs above). I don’t think that it is the piston, exactly. I think that it is the Automation kicking off the change which fired the piston. I have already shown that the pistons are fine. It’s when the STHM automation syncs the VS (to a state that it already is in) that things get iffy.
It didn’t used to do this. This only came about in the last 3 or 4 days when SmartThings had some API and Cloud issues. Like I said, I was rock solid for 6, maybe even 8 or 9 months and never touched a thing. Out of the blue it started doing the ‘multiple’ commands.
Maybe ST made an internal change that affected how Automations are done and/or identified?
Sorry, I can sometimes help with some information on the third-party protocols, but the virtual switches are unique to the smartthings cloud platform and I honestly don’t know exactly how it all works or whether they’ve changed anything recently.
I think @orangebucket has done the most work with these. @Automated_House might have some ideas as well.
Correct and ST used to do this with the virtual switches. Now it’s doing the same to my setup with STHM and VS’s since the update/cloud issues.
Apparently they have reworked Automations and Scenes to use the Rules API so that could be a factor.
Using the Virtual Switch handler might not help because it sends the events with ‘isStateChange’ true which forces events to propagate even if the state hasn’t changed. By contrast the Simulated Switch handler sticks to the default and only propagates changes. However I’m not sure how that legacy setting interacts with ‘new’ settings where I seem to remember seeing the option on the subscribe side.
2 Likes
WebCoRE absolutely should handle this, command optimization is on by default - it doesn’t send commands that would result in no action unless command optimization is turned off on a piston.
With all of the weirdness that’s been going on the last 6 days and given that it was working before last week and suddenly wasn’t AND I’ve seen multiple reports of people having issues with the V-Switches handling STHM triggering as many as 48 times when they’re thrown… I’m inclined to think it’s related to that. Because of that fact, I’m reticent to dig in to the piston until we know the platform issues that have been happening are gone. If we were to get an all clear from ST (status.smartthings.com still lists degraded service for North America) and it continues - THEN I’d dig into it, until then I wouldn’t spend too many cycles chasing ghosts.
If someone has the green snapshot or the import code for the piston in question I’ll take a look at it to see if there’s something obvious…
1 Like
I changed the type from Virtual Switch to Simulated Switch and it worked perfectly across the board with all pistons and automations.
I changed the type back to Virtual Switch and the problem came back.
The reason why @steinauf might not have seen this issue is because he had them defined as ‘contact sensors’ I do believe. I’ll keep monitoring. Strange for sure, but it appears that Virtual Switch is the culprit and any recent changes on the ST platform might have affected it.
3 Likes
Good find. Yeah my DTH is both a switch and contact sensor so it’s visible to Alexa routines as well.
@nathancu, don’t bother digging into the pistons since it seems to definitely be caused by something else.
2 Likes
Yeah thats STRANGE… Definitely a good find.
Well, the only general difference between Virtual Switch and Simulated Switch i know of was ‘Virtual’ runs local and ‘Simulated’ runs in the cloud. I typically use Virtual just in case im including them in a Smartlighting routine to increase my chances of local execution… Ive been swapping most of my Vswitches to that effect…
Interestingly enough I hadn’t made it to switching the virtual switches controlling my STHM implementation - so they’re ‘Simulated’. (and I expect why I personally didnt hit this).
Functionally, this should be ok for now as STHM requires cloud, so you’re not losing anything because of Simulated Switches cloud execution
3 Likes
Yes, there is that, the isStateChange setting, Virtual Switch doesn’t have Health Check, and the Simulated Switch can simulate being offline (it being built to simulate a real switch).
It is diagnostic but certainly not ideal as anything other than a temporary solution.
3 Likes
This simulated switch is what I’m using. Works great for this purpose.
2 Likes
Fantastic thread. This is exactly what I need. I’m new to the platform and could use some assistance. I have my Envisalink 4 up and running. I have installed the plug-in and the smartthings apps and device handlers, but I’m not sure it’s all working correct.
-
My sensors do update in smartthings, however, not until they are triggered. Most of my sensors are infinately showing a status of “checking” - Is that normal?
-
I have a device called “Security Panel” in smartthings It has a ‘gear icon’ to change the partition status. I try and nothing happens. However, If i change the arming status at the panel it seems to update this device (one direction from panel to smartthings, not the other direction)
- I dont seem to have any of the fancier partition controls that I saw as i scrolled through the thread. I linked to the github repository, so i guess i assumed I’d have the latest?
- None of my honeywell devices (when viewed in the IDE are showing they are linked to my smartthings hub. They just have a device location.
!
- I noticed early on in this thread, that someone took a screen print of their Envisalink Network Page from they EyezOn website. There was a section for TPI that showed the proxy IP. I dont have that section on the network page (is that old, or am I missing something)
-
What is meant by device discovery? Is it just disovering what I manually created in the config file, or will it find zones that are not in the config? If it can automatically discover zones, why do i need to type them into the config?
-
I’m brand new to linux as I just got my pi over the weekend. I dont fully understand the best way to run the server as a service (and be able to see real time logs). If I start from the bash using NVM RUN START – I can see real time logging (that is nice). I created a service file and used systemctl to execute at startup. Is there a way to see real time logging? There was a script included (restart.me) with forever command. Is this mutually exclusive to running my service through systemctl? Or do these work together? Is there an advantage to the forever script (if so, How do i set it up and execute the restart.me"
-
Here is some of the logging from my screen. Does this look normal (eg the nodeproxy IP looking blank)
[2021-02-04T22:34:31.409Z] [stnp] SmartThings Node Proxy listening at http://:::8080
[2021-02-04T22:34:31.427Z] [stnp] Loaded plugin: envisalink
[2021-02-04T22:34:31.435Z] [evl3] Connected to Envisalink at 192.168.1.29:4025
[2021-02-04T22:34:38.426Z] [evl3] {“type”:“partition”,“partition”:1,“state”:“ready”,“alpha”:“DISARMED Ready to Arm”}
[2021-02-04T22:35:23.965Z] [evl3] {“type”:“partition”,“partition”:1,“state”:“notready”,“alpha”:“DISARMEDHit * for faults”}
[2021-02-04T22:35:24.774Z] [evl3] {“type”:“zone”,“partition”:1,“zone”:18,“state”:“open”}
[2021-02-04T22:35:24.777Z] [evl3] {“type”:“partition”,“partition”:1,“state”:“notready”,“alpha”:“FAULT 18 MOTION OUTSIDE FRONT”}
[2021-02-04T22:35:27.379Z] [evl3] {“type”:“zone”,“partition”:1,“zone”:“18”,“state”:“closed”}
[2021-02-04T22:35:27.382Z] [evl3] {“type”:“partition”,“partition”:1,“state”:“ready”,“alpha”:“DISARMED Ready to Arm”}
[2021-02-04T22:38:30.014Z] [evl3] {“type”:“zone”,“partition”:1,“zone”:18,“state”:“open”}
[2021-02-04T22:38:30.017Z] [evl3] {“type”:“partition”,“partition”:1,“state”:“notready”,“alpha”:“FAULT 18 MOTION OUTSIDE FRONT”
- Finally, here is my config. Is there anything I’m missing?
{
“port”: 8080,
“authCode”: “***",
“rnet”: {
“c-series”: false,
“serialPort”: “/dev/usbser”,
“sources”: [
“Sonos”,
“Airplay”,
“Apple TV”,
“Source 4”,
“Source 5”,
“Source 6”
],
“controllerConfig”: {
“type”: “discover”,
“controllers”: [
{
“controller”: 0,
“zones”: [
{
“zone”: 0,
“name”: “Family Room”
},
{
“zone”: 1,
“name”: “Kitchen”
},
{
“zone”: 2,
“name”: “Living Room”
},
{
“zone”: 3,
“name”: “Patio”
},
{
“zone”: 4,
“name”: “Dining Room”
},
{
“zone”: 5,
“name”: “Office”
}
]
}
]
}
},
“mpr6z”: {
“serialPort”: “COM2”,
“baudRate”: 9600,
“sources”: [
“Sonos”,
“Airplay”,
“Apple TV”,
“Source 4”,
“Source 5”,
“Source 6”
],
“controllerConfig”: {
“type”: “discover”,
“controllers”: [
{
“controller”: 1,
“zones”: [
{
“zone”: 1,
“name”: “Family Room”
},
{
“zone”: 2,
“name”: “Kitchen”
},
{
“zone”: 3,
“name”: “Living Room”
},
{
“zone”: 4,
“name”: “Patio”
},
{
“zone”: 5,
“name”: “Dining Room”
},
{
“zone”: 6,
“name”: “Office”
}
]
}
]
}
},
“envisalink”: {
“address”: “192.168.1.29”,
“port”: “4025”,
“password”: “user”,
“securityCode”: "”,
“dumpZoneTimer”: “0”,
“panelConfig”: {
“type”: “discover”,
“partitions”: [
{
“partition”: 1,
“name”: “Security Panel”
}
],
“zones”: [
{
“zone”: 2,
“type”: “contact”,
“name”: “GARAGE DOOR”
},
{
“zone”: 3,
“type”: “water”,
“name”: “UTILITY ROOM FLOOD”
},
{
“zone”: 4,
“type”: “water”,
“name”: “SUMP PUMP”
},
{
“zone”: 9,
“type”: “contact”,
“name”: “FRONT DOOR”
},
{
“zone”: 10,
“type”: “contact”,
“name”: “BACK DOOR”
},
{
“zone”: 11,
“type”: “contact”,
“name”: “BASEMENT DOOR”
},
{
“zone”: 12,
“type”: “contact”,
“name”: “MASTER BEDROOM DOOR”
},
{
“zone”: 13,
“type”: “contact”,
“name”: “ROOF DOOR”
},
{
“zone”: 14,
“type”: “motion”,
“name”: “1ST FLOOR MOTION”
},
{
“zone”: 15,
“type”: “motion”,
“name”: “BASEMENT MOTION”
},
{
“zone”: 16,
“type”: “contact”,
“name”: “BASEMENT GLASS”
},
{
“zone”: 17,
“type”: “contact”,
“name”: “BASEMENT BEDROOM”
},
{
“zone”: 18,
“type”: “contact”,
“name”: “MOTION OUTSIDE FRONT”
},
{
“zone”: 19,
“type”: “smoke”,
“name”: “FIRE DINING”
},
{
“zone”: 20,
“type”: “carbonMonoxide”,
“name”: “GAS DINING”
},
{
“zone”: 22,
“type”: “water”,
“name”: “BOILER FLOOD”
},
{
“zone”: 23,
“type”: “water”,
“name”: “REFRIGERATION FLOOD”
}
]
}
},
“ad2usb”: {
“mode”: “serial”,
“securityCode”: “1234”,
“clearFaults”: true,
“serialPort”: “COM2”,
“address”: “192.168.2.22”,
“port”: “9001”,
“panelConfig”: {
“type”: “discover”,
“partitions”: [
{
“partition”: 1,
“name”: “Security Panel”
}
],
“zones”: [
{
“zone”: 1,
“type”: “smoke”,
“name”: “Smoke Detector”,
“serial”: “0180036”
},
{
“zone”: 2,
“type”: “contact”,
“name”: “Front Door”,
“serial”: “0180037”
},
{
“zone”: 3,
“type”: “contact”,
“name”: “Back Door”,
“serial”: “0180038”
},
{
“zone”: 4,
“type”: “contact”,
“name”: “Kitchen Door”,
“serial”: “0180039”
},
{
“zone”: 5,
“type”: “contact”,
“name”: “Kitchen Window”,
“serial”: “0180040”
}
]
}
},
“dash”: {
“buttons”: [
“aa:bb:cc:dd:ee:f1”,
“aa:bb:cc:dd:ee:f2”
]
},
“notify”: {
“address”: “192.168.1.25”,
“port”: “39500”
}
}
Thanks Much
Doug
Welcome! SmartThings transitioned to a new app a couple months ago, which changed the way custom devices like this one behave. Screenshots of the ST app older than late 2020 will be from the old “Classic” app. What you’ve posted looks like you have things mostly working in the new app.
I don’t think the code initializes the sensor status when the sensor devices are created. The old app handled that just fine and defaulted their status - seems like the new app doesn’t handle it as well. So long as your zones are updating when tripped everything is working right. The zone DTHs just need to be updated to set an initial value.
Did you enter your alarm PIN into the smart app settings or the config file? Since you were able to get all of your zones to populate, that’s my best guess. If you can post logs (both from the Pi and from live logging in the ST IDE) when trying to arm/disarm that might help figure out what isn’t working. Just be careful to make sure you’re not posting your alarm PIN.
The fancy controls were the old app. The functionality in the new app isn’t able to duplicate it yet.
The hub should be set automatically, but if that’s not working you can edit the devices through the IDE and select your hub.
I have an Envisalink 3 and the TPI section is there. I guess they don’t show it with the 4?
Yes. Whatever you put in the config file is sent to ST to create the zone devices. If your version of the smartapp has an option in the settings to automatically add zones when faulted then you can walk around and open all your doors and windows to add them. Some zones are harder to fault though, so the config file is helpful…
I don’t think there’s a way to have it autoexec on boot and still show logs in real time on the command line. I’ve only learned enough linux to get this and a few other devices set up though, so I’m no expert.
I think the advantage of forever is that it will attempt to restart the STNP server if it crashes. I’m not sure if the method you’re currently using does that, or if so whether forever is better/worse. Here’s a step by step of one way to get it to start on boot while using forever.
I haven’t looked at logs in a while but the blank IP looks familiar. If you want to confirm that the server is running, hit <your Pi’s IP address>:8080 in a web browser.
The rnet, mpr6z, ad2usb, and dash sections of the config file could be deleted since they’re for different plugins. They aren’t hurting anything by being there though. If all your zones populated then your config file is fine.
Thanks Phil
Regarding App/Device Handler Versions…
When I started, I just read the top portions of this thread, and installed everything from the Redloro repository on GitHub.
Last night I read this thread from the bottom up (backwards). I changed to using your device handlers and JRODs app. JRODs app didn’t allow me to arm/disarm from the panel device. I went back to using everyting from Redloro, and now everyting seems to be mostly working (I can change the arming status in the app using the gear icon)…
I do notice that sometimes if I open and close a door quickly, it will register the open and not the close, and my sensor status will reflect incorrectly as “open”. Not sure if this can be fixed with a poll somehow.
What were the reasons for the new device handlers and app? I tried to read as much as I could, but it seems there were lots of different issues. Were any of them related to the above? I think everything else is working ok for me using Redloro’s code. Thanks again for your help!
Short version - the way custom UI is done in a device handler is completely different in the new app. most advanced device handlers or ones that had custom UI elements need to be updated to display/work properly.
Now why is it STILL being updated? The custom presentation tech the new UI elements are based on are still ‘beta’ and very much a moving target. As new stuff becomes available, you’ll see updates. For instance right now this one (redloro/phil30 for Honeywell) and the Xero/RTorch version for DSC Alarmserver both use selectors to pick an alarm action. When they give us custom buttons - I’m pretty sure we al would prefer that presentation (Pick a button to set your alarm instead of dropdown, make selection) it’s just not possible yet.
Alarm Keypad for Dashboard.
I am using sharptools dashboards and galaxy tab As as my front end for smart-things. I only have one alarm keypad installed in the house. Rather than pulling wire for more keypads, its better/cheaper/easier to throw up some cheap tablets by my entry/exit doors. Sharp-tools allows you to put a pin code on controls (like disarm), but I dont like this, as I want to provision extra codes for the cleaning lady, etc. and dont like having just one pin on the disarm action. Also I prefer to keep the provisioning and authentication in one spot, on the panel. I use alarm.com which has a nice GUI for this, but i can envision building some scripts to provision and unprovision user codes based on a schedule so that my nanny code is only good during daytime, etc.
I found this node-red flow Security Pin Dialog UI Template for Node-Red-Dashboard (flow) - Node-RED that creates a security pin dialog that looks like this
I can envision adding some virtual buttons to smartthings for disarm/etc, and having it call this hyperlink on my pi. Upon entering the PIN, would it be possible to call smartthings node proxy, passing the pin and command?
I’m not a coder, and dont know where to start. Here is a picture of the example flow that I imported into Node-Red from the website above. Upon hitting the button should there be an http request, tcp request, etc, and what would need to be passed? Can anyone help create a modified flow that hooks into stnp (if this is possible)?
THANKS!
I think the redloro code at the top is good to use now. Someone grabbed my changes and jrod’s and submitted a pull request.
There are some limitations to the data that the Envisalink is able to get out of the Vista panel, mostly due to shortcomings in the Vista panel. What you’re seeing could be part of that. Or, if it’s really quick, it could be a race condition where the open is processed by ST after the subsequent closed. I’ve been having issues recently with sensors staying open quite a bit. Thinking of putting a poll function in but haven’t felt like opening this project up again until ST makes more progress on the issues @nathancu mentioned.
I use ActionTiles. Similar in that it has PIN protection on controls or screens. I haven’t ever looked into sharptools, but my solution in AT would be to have a guest/maid access button that goes to a duplicate of my own alarm panel screen, but with protection set to use the guest/maid PIN.
Thanks Phil. I could do something like that, but i tend to provision different codes for family, workers etc, depending on what’s easy for them, and then deactivate them when they dont need them. I also like the peace of mind of knowing that if someone did break in, and disable the alarm, I might know the source of where the PIN leaked (versus if everyone uses the same PIN).
The idea above “looks easy” (as I guess most everything does to somone who knows little about it-- like me 
. Installing Node-Red/Node-Red-Dasboard and importing the flow above takes about 5 minutes. Importing the flow creates the sample flow and the UI PIN dialog. I dont know about action-tiles, but sharp tools allows you to launch web pages from virtual buttons. The address for the Node-Red dashboard that would containt the PIN dialog is “IP Address of Node Red Server”:1880/ui. The piece I’m missing, is what call after someone enters the PIN. I would need to select one of the following and drop in the request.
I understand I cant make a separate connection to Envisalink, as it only accepts one. Thats why I was thinking I would need to call the STNP on my PI and let it send the request to the panel. The other piece I’m fuzzy on is if this is easily doable, as based on my limited understanding NodeProxy is only looking for requests from the smartthings IP. This request would be coming from my Node-RED UI running on the PI. So I’m not sure if there is a way to spoof it as if it is coming from smartthings, or just a way to modify the Envisalink plugin to look for requests from two sources.
Doug
Alarmserver can proxy for the EVL device. (At least i think this branch can)