Are you using the new app? If so, go ahead and download the SmartThings Classic app instead. I’ve gotten the zones to work with the new app by adding the appropriate vid to each device handler, but no luck yet with the partitions. I’ve never seen Checking Status on the old app, so hopefully that’s all it is.
I’m using an Envisalink, and redloro doesn’t have the serial field in the config section for it, so I’m assuming it’s something specific to the AD2USB. At any rate, no idea what to do with it.
If you haven’t added all your zones, I’d recommend you do so before you move on to creating any automations based on the zones. Every time you run the discover routine in the smartapp, it deletes all current devices related to the Vista and repopulates them. It breaks any dependencies so it’s a bit of a pain.
For the relays… arm the system in stay mode and walk in front of the motion sensors. Then check the STNP feed to see what it says. If it pops up on there with no errors, then you should be able to use the zone numbers it shows in the config file. If it’s a 4 digit zone number, there’s a chance that it’ll throw errors if any of the code is specific about wanting just 2 digits. Worth a try though to test it out.
I don’t have any relays, but that sounds like something I need to set up. Is that just programming in the Vista or is there additional hardware required?
You are absolutely right - the issue was with the new ST app. In classic, all physical zones (wired and wireless) show up fine and work. The response time is significantly slower than in HomeSeer since it is going through the proxy and I am assuming through the cloud since ST is cloud-based. Would probably not be good to use motion sensors for any lighting automation due to the delay unfortunately. Is a small delay expected?
In regards to relay - it is just panel programming. As long as you don’t have an add-on module with physical relays, you can create virtual ones that would map to other wired sensors (motion. contact, etc) and will report status regardless of the alarm state. Since these panels do not report status for wired zones in armed state - creating virtual relays will enable to do that. I have programmed it few years ago and I think I used this thread to do it.
I will have to play around with virtual relays tomorrow to see if they can be added as devices. The messages they send are a bit different from other sensors and look like this for example: !REL:13,01,00 !REL:13,01,01
Developer for the Honeywell/Ademco plugin for HomeSeer had to add code to handle those if I recall.
I am seeing several seconds in the app UI, 5-10 seconds at least. Maybe it is just app UI that is slow? I have not created any automations yet because, as you said, I want to get all sensors and relays working first. One second is great… that’s not what I am seeing though.
I just did a test on a wireless door sensor with smart lighting. I counted two seconds from opening the door to lights coming on. I think one second of that is the alarm panel reacting. My motions are worse, but the additional lag is coming from the amount of movement the sensor needs to trip.
Hey thanks so much for the ideas and speedy response! I rechecked the config file and all zones seem to be set up the same. The sensors are listed as “contact” like the windows and doors. I have a total of 24 sensors (19 contacts, 4 smoke and 1 motion) 5 are wireless contact sensors that do not show in ST. When I tried to run discovery in the app, it would not save and gave an error in red (error saving page). The ST IDE logging gave the following:
10:21:22 AM: error physicalgraph.exception.ConflictException: Device still in use. Remove from any SmartApps or Dashboards, then try again @line -1 (doCall)
You are for sure on the right track there is something that is not working! I just don’t understand what the error is saying. Should I delete all the devices that were set up initially ie windows doors etc and/or the SmartApp? Thanks so much for any other ideas you may have!
That error isn’t anything troubling. The Honeywell Security smartapp is set up to delete all existing partitions/zones when running discovery. However, ST throws that error when the smartapp tries to remove a zone that you’re using in an automation. Don’t start deleting devices and tearing automations apart yet.
Are the five that aren’t adding the last five zones in the config file? If so, it might be a time out issue, and if that’s the case I think we can get it working.
ST times out and kills anything that runs for more than 20 seconds. I think it takes around 1 second to create a device, plus there’s a built in 5 second wait, so I think it maxes out at 10-20 zones before the timeout.
Try replacing the smartapp code with the code in my repo at the link below. In the smartapp settings, set “Delete Existing Partitions/Zones During Discovery” to off and “Enable Discovery” to on. Have live logging open in a browser when you hit save and let me know what you see. If it works, it should list the zones that were already added and then start adding the others. If it adds some but still times out, run discovery again to keep adding. Let me know if it works, or send me logs if it doesn’t.
@jbjohnson77 Try my revisions to the smartapp a couple posts up. It should make it so SHM status only changes based on partition 1. I can’t test it myself since I’m only running one partition right now, so let me know if it works for you.
@jbjohnson77@nmelanson Are you using Envisalink or AD2USB? I’ve only dug into the Envisalink plugin so far, but it looks like it’s only set up to allow ST to arm/disarm partition 1 (or whichever partition is set as the Envisalink default). Is there anything else with 2 partitions that isn’t working?
@philh30 or anyone else here, I wonder if you have seen this issue before. All zones configured and working properly. However, wireless sensors produce false open once in a while. I did not have a chance to dig through logs in details yet (need to figure out how to enable detailed logging) but from what I am thinking is wireless sensors send some kind of connection/regulatory ping which the handler/smartapp interprets as “open” status when the doors are not actually opened. The alarm panel itself does not do that and the zone works properly without triggering the alarm or registering an open status; but the sensors in SmartThings report “open” even though they are not. It happens consistently with all of my wireless contact sensors, wired ones do not have this issue. Any idea? Thanks
UPDATE: So I believe this is what is causing the false “open” flag. I am seeing a status of “84” reported for the wireless sensors once in a while:
I think the true open and close values are “80” (faulted/open) and “00” (closed, no fault). Is the code “84” being interpreted as open just like “80”? I am not sure what 84 means and I can’t find any reference.
Looks like you found it. I think 84 translates to a loop 1 supervision required message (see http://www.alarmdecoder.com/wiki/index.php/Protocol#RFX). I’m not sure what that really means though. Can you try to figure out whether that code is ever used when a zone is actually faulted? Just wondering whether it should be ignored or interpreted as closed.
The logic in the AD2USB plugin is currently just evaluating whether the flag is nonzero, so 84 is handled the same as 80. Code below is where that’s happening. If 84 should be interpreted as closed, then the if statement should test msg.flags==128 as the first part of the and. If 84 should be ignored, then the else line a few down needs to be changed too.
I think you’re right that it’s a check in ping. But I think trapping 84 isn’t enough, as that’s just a loop 1 ping. It probably needs to be trapped based on that 3rd bit being flagged in case loops 2-4 give a similar report.
Ok, it all made sense but you lost me on that last statement
I can’t find any details on what the “84” status can indicate - but judging by the fact that physical panel as well as AlarmDecoder virtual panel do not interpret it as open or trouble - I think it can be safely ignored. I will try to mess around with code based on your suggestions, thank you. It’s been a while… so my coding skills are a bit rusty.
On another note, any suggestions on the best way to implement the !REL messages handling for virtual relays? I still want to add those since they allow status reporting for wired zones in armed states. Per AlarmDecoder the messages look like this which is what I am seeing in the log, just need to add handling for them so they can be added in the config.json. Not sure where it needs to be done and if additional Device Handler needs to be added in ST:
Actually, ignore my recommended fix. That’s where the issue is, but I was misinterpreting syntax (Java isn’t my language). The & in that if statement is a bitwise AND. Need to map out the bits to figure this out.
I upgraded my machine from windows 10 pro with windows Server essentials 2016 - same machine, same MAC and IP address. I copied my config.json (actually whole smartthings directory), then copied back and did the npm install and plug-in install. When I run nodeproxy, I see events form honeywell on the proxy machine. I also see events form individual zones in smartthings. BUT, I cant arm or disarm from smartthings.
Does changing servers (without changing IP address, require changing anything in the smartthings app? I did see a “no event handler” message in the IDE.
I also saw “[2019-01-28T12:04:24.003Z] [stnp] Authentication error” on the proxy, but not each time I try to arm. If followed “[2019-01-28T12:04:23.994Z] [stnp] ::ffff:192.168.0.21 GET /favicon.ico”
Any idea what is going on? I get {“status”:“SmartThings Node Proxy running”} when I http to the address from a browser.
That doesn’t sound like normal traffic related to this. I’d have to sift through the code to be sure though. Is that related at all to the timing of when you hit arm/disarm? If not, does anything show in the STNP log when you push arm/disarm? If you arm from the Vista keypad, does the partition status update in ST?
