My firmware is at 01.00.104 even though their forum says the latest is 01.00.102. Mine updated when I installed it a couple weeks ago but nothing since then. The reboot link, not a button, works fine and I have verified that it does indeed reboot.
I suppose you force updated your firmware in order to try out the syslog feature?
Hi @TAustin, Thanks for responding. That was it. I pinged “Envisalink” and did not find it. I am running Ubuntu within virtualbox and maybe that is why it cannot find “Envisalink”. However, when I pinged the IP address, i got the response. So, i changed the cfg file to I address. and it WORKED when i started the alarmserver. Thank you very much for your help !!!.
Finally I got this to work with 47 zones. What I did was not to create all zones at the same time in the alarmserver.cfg
I started creating 5 zones then run the alarmserver.py observe 5 zones created correctly in my phone, stop alarmserver.py, edit alarmserver.cfg add another 5 zones, run the alarmserver.py observe 10 zones created correctly in my phone, stop alarmserver.py, edit alarmserver.cfgg add another 5 zones, and so on… at the end I now have 47 zones working.
Only standing issue is with the partition No. 2. (as mentioned in thread 1100) it still is not working, so please if somebody has worked with 2 partitions, please let me know how to do it.
Hey guys,
Still looking to control the chime a little better. Anyone know how to control the variable?
standardTile(“chime”, “device.chime”, width: 2, height: 2, title: “Chime”, decoration:“flat”){
state “togglechime”, label: ‘Toggling Chime’, action: “togglechime”, icon: "st.alarm.beep.beep"
state “chime”, label: ‘Chime’, action: “togglechime”, icon: "st.custom.sonos.unmuted"
state “nochime”, label: ‘No Chime’, action: “togglechime”, icon: “st.custom.sonos.muted”
def chimeList = [‘chime’,‘nochime’]
if (onList.contains(state)) {
sendEvent (name: “switch”, value: “on”)
} else if (!(chimeList.contains(state) || troubleMap[state] || state.startsWith(‘led’) || state.startsWith(‘key’))) {
sendEvent (name: “switch”, value: “off”)
Hi, I have created the alarmserver/smartthings using @lXXero’s direction. The arming/disarming door contacts and One motion (zone3) works great. However, from motion 4, 5 and 6 i do not get any “read” or activity within Smartthings. I checked the alarmserver within python and the activities are registered.
Seems issue with device creation within Smarthings.
I have defined Zone 3 as:
Name DSC Zone 03 Motion Sensor
Label DSC Zone 03 Motion Sensor
Type DSC Zone Motion
Version Published
Device Network Id dsczone3
Status INACTIVE
and zone 4 as:
Name DSC Zone 04 Motion Sensor
Label DSC Zone 04 Motion Sensor
Type DSC Zone Motion
Version Published
Device Network Id dsczone4
Status ACTIVE
did i miss a step somewhere?
Any suggestions?
there’s not really a variable to control. it’s receiving a status update called “chime” or “nochime” and it’s setting the tile to show the chime enabled/disabled icon accordingly. The togglechime is the only “switch” and it is indeed an actual toggle, not an on/off setting. The alarm sends a status update after it’s toggled, indicating which state it’s in. That’s what the chimeList is doing - it’s receiving that update and passing it to the tile so that the chime tile shows whether it’s on or off.
The only switch that’s exposed is the switch that turns the stay or away panel on/off, which is basically your stay/away switches.
I think i mentioned this in another thread, but if you wanted an actual switch device that can, at least in smart things, show what state it’s in, and toggle it accordingly, it would probably require creating a new device entirely just to expose a chime “switch”. I don’t think you can have more than one “switch” per device so I don’t know that there’s a way to do this with the existing devices, although someone can correct me if i’m wrong - it’s been a while since i’ve dug into that stuff.
first thing i’d do is check your config file for syntax errors and make sure you didn’t use some sort of funky names or characters in there anywhere.
I’m wondering if a sort of “feature” to solve some of these switching requests as well as the old long issue of stay/away switching and the whole separate panels, might be to create a configurable “switch” device.
It might actually mean we could finally do away with the stay/away panels entirely, just go back to a single panel for everything, and if you need to switch stay/away separately, you’d have a new device which simply functions as a switch for various things, and you’d be able to create multiple of said device, so you could have different switches. Stay/away switches, chime toggle switches, you name it, and it would be a proper switch that updates it’s status in smartthings, can be used by other apps, etc…
I’d have to look into how difficult it would be, it would likely need to behave differently depending on which way it was configured, so i imagine it’ll need a ton of conditions and what not, so it’s definitely gonna take some work to do it right, but I bet it’s possible.
curious how many people would be interested in such a thing? it would definitely be a pretty cool thing, I think.
I also think I should play around with core/piston some more and kinda see what’s changed and what’s new in smartthings in general as i’ve admittedly fallen out of it the past few months, since my stuff is mostly working well for me, haha.
I’d definitely be interested in upgrading this to one panel and having me control of things like chimes. Anything I can do to help I’ll do although I must admit I’m pretty rudimentary. I can suggest some things from core if its helpful
I had installed mine just last week, so firmware probably got updated when I set up the device in EyezOn.
So moving my RPI to the .1 subnet seems to have solved my connection problem. Thanks to you, Mitch, for helping diagnose this. I still don’t know if it was a problem with the router config, or EVL4 just doesn’t like being connected to a server on a different subnet.
I have not had any success getting the syslog feature working. I installed and configured rsyslog, but frankly don’t know if it’s functioning.
I still maintain that the alarmserver code needs to be improved to ensure the connection with EVL is alive and well. I’m brushing up on Python so I can add a secondary thread to poll every couple minutes. Then I suppose I’m going to need a way to get a message to the ST app if the connection is lost 
I don’t love how it works today in the app. It’s not intuitive how to turn OFF bypass for a device (toggle the bypass button again?; that doesn’t seem to work for me).
Also - would it be doable to modify the Open / Close status of each device to indicate if it’s bypassed right there on the things list, without having to click on the device? Something like “Open (by)” and “Closed (by)” Or maybe just use a unique font color.
Yes, I just learned from reading the EyezOn forum that only new EVL’s registrations would get the latest firmware pushed out unless they decided that features or fixes made it worth a ‘global’ push-out. One can, however, email support and have them push out the latest firmware to an EVL. I might have this done so that I can experiment with the syslog client feature, as well. Let me look into that and, if I have any luck, I’ll let you know.
I’m happy that you got your ‘dropped connections’ issue resolved. It might have even been a flaky network port on the router. Hard to say without trial and error troubleshooting.
Regards!
@Chris_Schoepp has been trying to figure out the toggle chime thingy. I am curious, if the status can be pushed to ST, then why can’t it be pushed to CoRE? CoRE can toggle it now but I am not understanding why it can’t read if it’s on or off?
Disclaimer: I have no idea how you guys write such awesome apps. I am just an End User.
ah it has syslog now? I definitely should get them to update me, lol. If there’s a way to make syslog work i’m sure i can, i’m fairly handy with rsyslog.
Yes, the code needs to be improved to reconnect on disconnect failures - i don’t know if it truly needs another loop, rather it may just need better error handling. As it is now, the app gets into a funky state on certain types of disconnects, so without that error handling improvement to identify that state - your secondary loop wouldn’t know the difference of whether it died or not! This is why i keep asking people to give me the errors it spews when it disconnects, as I want to track down where it’s dying in all these cases so we can handle it better. If you have had disconnect errors, please post them here so I can try to help.
That’s not a bad idea regarding showing the bypass in the text, that might be possible, but the device states in smartthings are a royal pain in the ass, and i can tell you haven’t dug into it much, let me show you something. basically, if i call something a contact or motion device in ST - it expects the states to match the capabilities of a contact device or motion, for example, look up a motion device here:
http://docs.smartthings.com/en/latest/capabilities-reference.html#motion-sensor
so it expects “active” and “inactive” as device states for a motion device. If I start trying to add states for “Active but bypassed” or “inactive but bypassed” then my device no longer is following the standard capabilities, and while it might show those statuses on the main page, it’s going to break any other apps that expect them to work according to those capabilities. while it may be a limitation to some respects, “bypassing” alarm sensors isn’t a feature that smart things really has built in, so one way or another we’re jamming it in there. likewise, smartthings also doesn’t handle entrance/exit delays, among other such features that most real alarm systems have. This method at least allows it to function with the correct capabilities, for the most part. it may not matter for a lot of things, but if you want something like smarttiles to show the sensors correctly, it does actually matter, as it will not work if they aren’t matching the capabilities of the device type. this is already an issue with the “alarm” state of the device - i don’t think it would show up correctly if the device was in that state to other apps. fortunately it’s not usually in that state without a bunch of other stuff also going crazy, so it doesn’t matter as much.
also can you go into more details about what exactly isn’t working with toggling the bypass? It should most definitely work when you hit the bypass button again.
the way it works is this: you hit the toggle button, it sends a command to the DSC. The DSC then sends an update out when this is done indicating the bypass states of all the devices. alarmserver needs to send that update to the ST app in order to update the bypass states for all the devices. so basically, it takes a few seconds before you’ll see it update. it is not instant. but it should work.
I mean, i can make the text on the button change depending on the bypass state easily enough, if that’s what you’re asking, but it sounded like it just wasn’t working at all?
How do I change the log level? I get no log messages when mine disconnects.
it might be logging them on the command line, rather than to the log file, unfortunately. See if you can run alarmserver with the output redirected to a file, like, “./alarmserver.py >cmdline.log >2&1” and reproduce the error, then you should have a file with the error in it once it happens.
Admittedly, there’s just issues all over with the logging and error handling in that regard, and it’s all pre-existing from before I ever made my improvements to alarmserver.
When I was having problems with dropped connections from having EVL and server on 2 different subnets, I wasn’t getting any error messages at all. At some point I realized that alarmserver stopped getting updates from EVL presumably due to a dropped connection. If alarmserver is in fact getting some kind of error when that happens, that’s a good thing! We just need to add the error handling. I thought it was just blissfully unaware the connection had dropped until it tried initiating something from a ST action and THEN got an error and THEN it would reconnect. That’s what the log messages showed anyway. That’s why I was going down the path of thinking a polling thread was needed.
I see what you mean about the problems with messing around with device status. You’d be forced down the path of a new custom device handler type and then that would causes other problems.
I hope you or Mitch have some success getting rsyslog working. No luck here. It would really help in debugging.
More than likely it did spew an error, on the command line, but not in the log file. Yet more crap that should be fixed, lol. But if you run alarmserver and redirect the output to a log file - hopefully you can capture the errors and we can add the handling you need!
Yeah, if we start making non-standard device types, then we basically lose the ability for other apps to “see” what the DSC app is doing, since none of them will support those types.
I’m curious to try it for sure, I will have to follow up on the EVL forum about that firmware update.