Check this out. He is syncing shm to alarmserver. That might be handy
i can look into it, i’m sure if he’s found a way to do it i can get this doing something similar. oh wow the code he posted looks super duper simple. I can probably get something similar done easily…OK its totally do-able, i found a few other threads with some more information on how to do it and i’m pretty confident i know what i need to do now, just need a minute to get this done
part of the question is - what modes do we want to be mapped to SHM states? Like, instantaway / away to away, stay/instantstay to stay…disarm/ready to off? What about exitdelay…entrydelay…alarming…just gonna ignore em for now and see how it works.
OK cool right now i’ve got the part where it syncs the alarm to SHM working. I’ve pushed that code up now.
I’ve got some initial code for tracking the SHM state to sync that to the DS, but i think i’m gonna have to read the status off a stay/away panel and compare it to the shm stuff before i have it do anything…i can just see there being weird contentions where it’s fighting itself on/off and that could be bad. i’ll keep playing with it though
Okay…it’s done. Give it a try. I made it so that it’s an option in the settings panel, so it won’t do it by default, just in case someone doesn’t have SHM enabled or what-not, you can turn off the logic.
I think it’s all working so far. I make it ignore exit/entry delay - because it has no way to know if those are stay or away until they activate. However, when you change the SHM mode, it applies to SHM immediately, so SHM thinks it’s armed stay even though it’s in exit delay, however when it takes action, it checks that it’s a valid mode, so if you are still in exitdelay mode despite SHM thinking it’s say, stay, it will still disarm correctly…sooooo it kind of just is working so far…I hope there’s not some weird scenario where all hell breaks loose and it starts trying to fight the alarm to set a certain mode…i’ve tried my best to make sure that can’t happen, but we just need more testing.
2 Likes
ok i’ve pushed it to my repo and my ST. i’ll start testing. thanks!
make sure you enable the new sync setting in the dsc integration options
otherwise i’m hoping it’s all good news? let me know.
Can we arm and disarm from shm?
Nevermind I didn’t have it enabled
yup, just make sure you enable the option or nothing will happen in either direction…
once enabled, it will sync in both directions. but since SHM only supports “away, stay, off” i am limited to how many modes i can push to it - right now you can see the mapping is here:
‘away’:‘away’,
‘forceready’:‘off’,
‘instantaway’:‘away’,
‘instantstay’:‘stay’,
‘notready’:‘off’,
‘ready’:‘off’,
‘stay’:‘stay’,
thigns like entrydelay/exitdelay, alarm, etc, are simply not sent at all, so if you are in those states, it won’t be able to show it. However, it will be able to still handle button presses for any mode that it’s valid to do so in:
'alarm': 'on',
'away':'away',
'entrydelay': 'on',
'exitdelay': 'on',
'forceready':'off',
'instantaway':'away',
'instantstay':'stay',
'ready':'off',
'stay':'stay',
Given that i’m hard-defining both lists - i’ve hopefully prevented any crazy runaway situations but we’ll see. it won’t ever try to send a mode that SHM can’t represent, but it will try to handle buttons for all states they’d be valid in…Basically,
an “off” event is valid for "on, stay, away"
a “stay” event is valid for "away, off"
an “away” event is valid for “stay, off”
so basically it only tries to handle SHM button presses according to that 2nd mapping, but it only sends updates to the SHM panel according to the 1st mapping…if that makes sense.
However, we might get bitten in the ass again by that DSC bug. Where the DSC panel never actually sends “stay” if you don’t have any zone type 05/37…seems people are running into that same issue again in the other thread
Ok opening an entry door fires off intrusion. Wonder how ST handles entry doors.
did you actually select all your DSC contacts/motions as SHM devices? I’d probably…not do that. haha. and just use the push notifications in the dsc integration app instead…
i’m not sure that SHM has a smart way to handle “entry delay” door scenarios…they might expect you to just disarm ahead of time since or use presense sensing cause you know it’s all ideal hahaha…
Well I didn’t add the zone 26 doors I just did front back and Windows. Opening the front door triggered the intrusion.
haha it’s working a little too well huh
Yea but it’s very nice so far. Wife wil use it more now lol
yeah i mean - even if you don’t add all those devices - the Away/stay/off syncing part is mostly working fine i think.
see my post in that other thread for some funniness that might happen if you’re don’t have any stay/away zones defined (it’s that same bug from ages ago - where the DSC panel will always arm to “away” even if you press “stay”, if you don’t have any interior/stay away zones like type 05,37, etc on your DSC system)
if that’s the case - the DSC sync will try to set SHM to away when you hit “arm stay” which is kind of problematic if you had a Z-wave motion but not a DSC motion, hahaha…but i mean this is kind of why it’s probably a bad idea to do that…it’d be more sensible to just add a motion to the DSC system imho…but if you were already stuck with one - you could always add a new zone, or make a dummy zone, or whatnot, to get around the DSC limitation. Otherwise, just turn off the SHM sync I guess? I could also maybe make an option to turn on/off the SHM sync for one direction or the other - so you could make it so that SHM button presses get sent to DSC - but DSC events never get sent to SHM - that way you wouldn’t have the issue of it trying to force it to the wrong mode. Or we could maybe make an option to always fake a “stay arm” from the DSC panel regardless of what it actually sent - that’d work for people with no real stay mode anyway…basically if, its armed just leave it in whatever mode but dont update it…
I think we need to push for shm to implement entry and exit delay and then this would work well.
you’d think it’d be something on their roadmap - no idea though. it’s definitely a common feature with normal alarm systems. but they might also be assuming everyone’s using presence sensing and/or disarming via their phone before entering their house, or something. I mean, that is one of the nice things about this stuff, but it’s also kind of against the normal habits of most alarm systems.
i can say this though it seems they put their focus on new integrations and whatnot more so than small timers like us - i can’t imagine they’d add the feature just for us, haha, but i could see them adding a door entry delay kinda thing as an overall feature for SMH eventually…
I think i may have a workaround for the stay/away issue. If you’re someone who has no zone type 05/37 on your DSC panel and your system never arms into “Stay” mode, only “Away”, then for the SMH sync - i need to add an option to make it only care about “Armed” vs “disarmed”. so if you hit SHM stay button, and then DSC panel comes back and says “I’m away now”, it won’t do anything. it would only care if it went from “armed” to “disarmed” but it doesn’t care if its “stay arm” vs “Away arm”. this should make it work “good enough” for those people, they won’t ever have the full detail that they would if their system had some stay/away zones on it though…
OK, i added that stay/away bypass mode for people who don’t have any motion or interior stay/away zones…anyone who has a properly functioning stay mode should leave the option off, as it supports fully syncing in both directions when it’s off…most people should leave the option off, or anyone with a motion detector.
But if you don’t have any stay/away zones or interior motion detectors, and your DSC system never arms in “stay” mode even if you hit stay on your panel, then you need this option or SHM will start changing to away mode even if you had hit the SHM Stay button…Which might be a problem if you have different smartthings behaviors for stay/away in SHM. And it should be noted, this will prevent the panel from breaking SHM, but it’s only for one direction, you’d still not be able to arm SHM to stay mode from the actual alarm panel, it will always arm to “away” mode no matter what. It will arm SHM as away mode if you arm from a disarmed state. But if SHM arms the system as “stay” and the DSC alarm panel later says “we’re away” , it won’t send an “away” update to a “SHM” already armed in “stay”, as it doesn’t know any difference between them, and so this prevents it from totally clobbering SHM’s stay status when it itself can’t support stay. Again, this is only if you don’t have any stay/away zones on your system…
When you don’t have any stay/away zones on your DSC panel - it will simply never report stay mode, so there’s no way to make the panel sync that correctly to SHM. The only way to fix it is to add some stay/away zones to your DSC alarm system, or even just a dummy zone that’s just shorted closed…as long as it’s type 05…then the panel would send the right signals when you arm stay and you wouldn’t need this bypass-mode…since most people have these already it’s only a small percentage of people this might effect…most people can leave it off and enjoy the full functionality.
@isriam - Have you been able to get your IDE to update automatically from Git yet? If so, what parameters do you use when adding the path to the IDE? Thanks.
No not yet.i do it all manually so far
that wont work unless i re-organize the repo with namedspaced folders and stuff, even then i had trouble getting it to work consistently, maybe i should try again now that the whole app has been namespaced under ‘dsc’ as part of the recent auto device creaiton update…hmmm…i might look into it more later tonight
1 Like
ok i fixed it. its based on your smartapp/devices namespace so the best/easiest way to do this is to upload a commit, and then look at the directory structure and move all your files to it. my latest github updates include the right structure from your devicetypes and smartapp.
basically set up git, set the namespace to my github, and you should be able to update smartapp and devicetypes whenever. i’m still working on it, but seems to work ok.
IDE direct link into your (@isriam) working for me now. Thanks.