[OBSOLETE] DSC -> EVL-3(4) -> Alarmserver -> Smartthings

oh yeah that makes sense, just enabling it creates the right symlink.

I added a comment to the request - should we just drop screen entirely? there’s really no point anymore i feel like it’s just adding complication if anything

I like to use screen as I display the log on a small LCD screen connected to the Odroid C2 but also want to see the log when I log in remotely via SSH. When I log in I get a menu asking me whether I want to reconnect to the screen session or just go to CLI.

you could still use journalctl to do that even if we drop screen…thus why i am not seeing much reason anymore to keep it around.

something like “journalctl -u alarmserver@user -xf” would “tail” the command line output of a service running in systemd directly

Yeah, “screen” causes another issue that it is hard to see why alarmserver failed to start because the error message is lost along with the screen session. I vote for removing “screen”.

@Xero I have updated the pull request to get rid of ‘screen’ and updated installation location.

@Xero @aruffell

b.t.w. This is why Alarm Server fails to start on my Raspberry Pi. Getting this log is now much easier with my new change:

-- Logs begin at Thu 2016-11-03 10:16:43 PDT, end at Sat 2017-10-21 01:05:14 PDT. --
Oct 21 01:03:58 raspberrypi systemd[1]: Started alarmserver.
Oct 21 01:04:07 raspberrypi alarmserver.py[384]: Using configuration file /usr/lib/alarmserver/alarmserver.cfg
Oct 21 01:04:07 raspberrypi alarmserver.py[384]: 2017-10-21 01:04:07 Alarm Server Starting
Oct 21 01:04:07 raspberrypi alarmserver.py[384]: 2017-10-21 01:04:07 Currently Supporting Envisalink 2DS/3 only
Oct 21 01:04:07 raspberrypi alarmserver.py[384]: 2017-10-21 01:04:07 Tested on a DSC-1616 + EVL-3
Oct 21 01:04:07 raspberrypi alarmserver.py[384]: 2017-10-21 01:04:07 and on a DSC-1832 + EVL-2DS
Oct 21 01:04:07 raspberrypi alarmserver.py[384]: 2017-10-21 01:04:07 and on a DSC-1864 v4.6 + EVL-3
Oct 21 01:04:07 raspberrypi alarmserver.py[384]: 2017-10-21 01:04:07 myURL: https://graph-na04-useast2.api.smartthings.com:443/api/smartapps/installations/1531ffff-48c0-4
Oct 21 01:04:07 raspberrypi alarmserver.py[384]: Traceback (most recent call last):
Oct 21 01:04:07 raspberrypi alarmserver.py[384]:   File "/usr/lib/alarmserver/alarmserver.py", line 867, in <module>
Oct 21 01:04:07 raspberrypi alarmserver.py[384]:     DeviceSetup(config)
Oct 21 01:04:07 raspberrypi alarmserver.py[384]:   File "/usr/lib/alarmserver/alarmserver.py", line 174, in __init__
Oct 21 01:04:07 raspberrypi alarmserver.py[384]:     requests.post(myURL, data=zonejson, headers=headers)
Oct 21 01:04:07 raspberrypi alarmserver.py[384]:   File "/usr/lib/python2.7/dist-packages/requests/api.py", line 110, in post
Oct 21 01:04:07 raspberrypi alarmserver.py[384]:     return request('post', url, data=data, json=json, **kwargs)
Oct 21 01:04:07 raspberrypi alarmserver.py[384]:   File "/usr/lib/python2.7/dist-packages/requests/api.py", line 56, in request
Oct 21 01:04:07 raspberrypi alarmserver.py[384]:     return session.request(method=method, url=url, **kwargs)
Oct 21 01:04:07 raspberrypi alarmserver.py[384]:   File "/usr/lib/python2.7/dist-packages/requests/sessions.py", line 488, in request
Oct 21 01:04:07 raspberrypi alarmserver.py[384]:     resp = self.send(prep, **send_kwargs)
Oct 21 01:04:07 raspberrypi alarmserver.py[384]:   File "/usr/lib/python2.7/dist-packages/requests/sessions.py", line 609, in send
Oct 21 01:04:07 raspberrypi alarmserver.py[384]:     r = adapter.send(request, **kwargs)
Oct 21 01:04:07 raspberrypi alarmserver.py[384]:   File "/usr/lib/python2.7/dist-packages/requests/adapters.py", line 487, in send
Oct 21 01:04:07 raspberrypi alarmserver.py[384]:     raise ConnectionError(e, request=request)
Oct 21 01:04:07 raspberrypi alarmserver.py[384]: requests.exceptions.ConnectionError: HTTPSConnectionPool(host='graph-na04-useast2.api.smartthings.com', port=443): Max re
Oct 21 01:04:07 raspberrypi systemd[1]: alarmserver.service: Main process exited, code=exited, status=1/FAILURE
Oct 21 01:04:07 raspberrypi systemd[1]: alarmserver.service: Unit entered failed state.
Oct 21 01:04:07 raspberrypi systemd[1]: alarmserver.service: Failed with result 'exit-code'.
Oct 21 01:04:10 raspberrypi systemd[1]: alarmserver.service: Service hold-off time over, scheduling restart.
Oct 21 01:04:10 raspberrypi systemd[1]: Stopped alarmserver.
Oct 21 01:04:10 raspberrypi systemd[1]: Started alarmserver.

I upgraded to the latest version today. Once again, thank you very much for all the effort that went into this app.

It seems that we are still only able to bypass zones in the first partition?

I see there are some plans to move to a better startup script. I’d love to see a freebsd rs.d style script included in the project for those of us running FreeBSD (or FreeNAS).

A question on how bypass functionality works. Often we leave an upstairs window open, bypass it and use stay armed.

In the Smart app, I can choose to bypass the window (and it works) and then arm the system. The issue I have is that Smartthings will send me alerts indicating “Smart Home Monitor is armed by upstairs window is open”.

Is that how it works or did I miss something in config that allows Smarthings to know the current bypass state?

If I look at the window device, it doesn’t show as bypassed.

I also have a question regarding the bypass function - does it still only work for the first partition? It seems that it is not possible to bypass zones which are part of partitions other than the first partition.

the bypass stuff should work in other partitions with the latest version…what doesn’t always work is the status updates for those other partitions, meaning it won’t actually update to show it as bypassed in the device. although hitting refresh in that partition’s panel should fix that. it should also probably still update and show as “ready” even though the device isn’t showing bypassed, assuming it’s working correctly anyway. You do need to update all the device panels as well as the alarm panels though.

smart home monitor has no notion of bypass as far as i’m aware, probably not much you can do about this.

the window device for the DSC doesn’t show as bypassed? It should… is it in a partition other than 1?

Thanks for your reply.
I updated the app and all DH’s. Removed all devices ass well.
Anu suggestion what I should look for since I’m definitely not able to bypass devices in partitions other than the first partition.

The window is in partition 1 and the button works when I click bypass (I can cycle it on or off), but there is nothing that indicates it is bypassed. I saw someone post this view previously, which seems to show the status. Mine is below.

image

This is exactly the projecti want, for Honeywell.
Does anyone know where to go for this?

you’ll need to get us some alarmserver logs (remove the keys of course from any URLs) while you press the bypass button

get me logs from alarmserver when you’re bypassing zones…

Here is what I see (with keys removed)

2017-11-04 16:12:20 Web request: GET /api/alarm/bypass?zone=5
2017-11-04 16:12:20 request to bypass zone 05 on partition 1
2017-11-04 16:12:20 TX > 0711*105#AC
2017-11-04 16:12:22 RX < 500 - 071 - Command Acknowledge
2017-11-04 16:12:22 RX < 510 - 80 - Keypad Led State - Partition 1
2017-11-04 16:12:22 myURL: https://graph-na02-useast1.api.smartthings.com/api/smartapps/installations//update?access_token=
2017-11-04 16:12:23 RX < 511 - 08 - Keypad Led Flash State - Partition 1
2017-11-04 16:12:23 myURL: https://graph-na02-useast1.api.smartthings.com/api/smartapps/installations/update?access_token=
2017-11-04 16:12:24 RX < 511 - 00 - Keypad Led Flash State - Partition 1
2017-11-04 16:12:24 myURL: https://graph-na02-useast1.api.smartthings.com/api/smartapps/installations/update?access_token=
2017-11-04 16:12:25 RX < 510 - 89 - Keypad Led State - Partition 1
2017-11-04 16:12:25 myURL: https://graph-na02-useast1.api.smartthings.com/api/smartapps/installations//update?access_token=
2017-11-04 16:12:25 RX < 650 - 1 - Partition Home Ready
2017-11-04 16:12:25 myURL: https://graph-na02-useast1.api.smartthings.com/api/smartapps/installations//update?access_token=

Is this all you need? (I took out the first part of each entry as I’m not sure if the code contains sensitive info)
35-f01fa66f2fa2 8:35:24 AM: debug partition: Away Panel device: Alarm Beams Away at b35-f01fa66f2fa2 8:35:24 AM: debug partition: Stay Panel device: Alarm Beams Stay at dscstay2 is forceready
b35-f01fa66f2fa2 8:35:24 AM: debug partition: 2 is forceready
b35-f01fa66f2fa2 8:35:24 AM: debug getChildDevices(false), children=20
-8b35-f01fa66f2fa2 8:35:24 AM: debug sending smart home monitor: off for status: forceready
4-8b35-f01fa66f2fa2 8:35:19 AM: debug [response:Request to send url: bypass?zone=9 received]
5-f01fa66f2fa2 8:34:45 AM: debug partition: Away Panel device: Alarm Beams Away at dscaway2 is ready
-8b35-f01fa66f2fa2 8:34:45 AM: debug partition: Stay Panel device: Alarm Beams Stay at dscstay2 is ready
-4474-8b35-f01fa66f2fa2 8:34:45 AM: debug partition: 2 is ready
66f2fa2 8:34:45 AM: debug getChildDevices(false), children=20
-8b35-f01fa66f2fa2 8:34:45 AM: debug sending smart home monitor: off for status: ready
8b35-f01fa66f2fa2 8:34:41 AM: debug [response:Request to send url: bypass?zone=9 received]

I think this will boil down to how complex you want your logic to be, bypassing can be done with webcore and virtual devices. Basically the idea is to introduce a virtual open/close device, catch real open/close in webcore, add a logic that checks whether the alarm is armed or not and device should be bypassed and based on it, set the virtual device state. Add this virtual device to the SHM and enjoy the result.

Got nothing to do with the actual alarmserver though :smiley: