you shouldn’t be using port 4025 at all, that’s the EVL proxy and you don’t need that for this. you need to be using the alarmserver port, defined by the “httpsport” in the config file
WWOOP everything is working now, thx a lot for the help.
It really depends on what you are trying to achieve with stay/away status. I tie a lot of logic to it, i.e. thermostat, lighting, etc, thus having it set properly AND across multiple devices - panels and SHM is important.Thus, having a central single place to set the status, even if it doesn’t match that of the physical DSC board is a preferred way.
Basically for the EnvisaLinkClient I add another property:
# last close command
self._closecommand = ‘none’
Then in its send_command method I add the following (pardon the mess, I’m not particularly familiar with python):
# remember close command
if code==‘030’ or code==‘032’ or code==‘033’:
self._closecommand='away’
elif code==‘031’:
self._closecommand='stay’
elif code==‘040’:
self._closecommand=‘none’
Also add to the callback_url:
if str(code) == ‘655’:
self._closecommand = 'none’
self.send_command(‘071’, ‘1*1#’)
and changing reaction to 652 in the same method:
if str(code) == ‘652’:
alarmserver_logger(‘Received 652, closecommand=%s’ % self._closecommand);
if message.endswith(‘Zero Entry Away’):
update[‘status’]='instantaway’
elif message.endswith(‘Zero Entry Stay’):
update[‘status’]='instantstay’
elif message.endswith(‘Away’) and self._closecommand==‘stay’:
** update[‘status’]=‘stay’**
I would definitely love to add persisting this property to a file (maybe config file) to read it back on the startup, crosscheck with the current state of the panel and set it properly.
Now that solution doesn’t solve the problem with a physical panel is used and the alarm is armed with the intent of being “stay” - still thinking about it. The easy solution is to remember not to use the physical panel for that at all 
i have never coded before, can someone walk me through how to set up alarmserver?
I have done everything else that was necessary but i can not figure this part out
your help is appreciated
How were you arming “stay” before in a way that wasn’t working for you? From the DSC Panel devices in smartthings?
An alternative might be to make an option that amounts to “my alarm doesn’t have stay” or something and it’ll just make the DSC panel never send the “stay” in the first place, and I could move the logic of remember which command was last sent into the smart app, and only use it when that option is enabled, for the SHM Sync.
Got this up and running last night. Great work everyone involved. One question. I have a motion sensor that insists it’s a contact sensor. I know it’s the right zone (name matches) I have it set to motion type in config but still shows up as a contact sensor. Any ideas?
double check the alarmserver config for weird characters, especially around the type=motion line, make sure you are using a decent text editor which will show funky characters like that, like vi/vim, notepad+ or gvim or something
Thanks for the reply. I use Sublime Text 3. No obvious odd characters. Just in case I tried coping a pasting a line I knew worked from another zone. No luck. Then I removed device from Smartthings. No luck there either. No obvious way to get it back actually so it just remained missing. Then I changed name of zone. It showed up as a thing with new name and as motion sensor. Go figure. I wonder if it had something to do with launching the smartapp while I had the default zones? Anyway all is well. Thanks again for the great work.
One suggestion. In the sample config file change:
[envisalink]
## Connection credentials to talk to the Envisalink device
host=envisalink
port=4025
pass=user
to:
[envisalink]
## Connection credentials to talk to the Envisalink device
host=XXX.XXX.XXX.XXX ##ip of your Envisalink device.
port=4025 ##default is 4025.
pass=XXXXXXXX #your Envisalink password. User is default "user".
Something like that anyway. I was confused mainly by the pass=user line.
Last time I updated the DSC app & handlers were in July.
Is it safe to update to current revision, or do I have to expect changing the configuration/re-installing it? I probably need to update to code on the rapsberry π too right?
I have it setup as a git repo in smartthings. Was thinking just clicking update in the IDE but wanted to ask first as I saw a lot of new improvements added on
If it was july of this year - and it’s my version of the app - then I think it should be fairly safe to upgrade, just make sure you upgrade both alarmserver and the smartapp and all the device handlers too. you may need to make sure your config matches the current format, the alarmserver.cfg that is.
ahh you inspired me to clean up that whole file. I ended up making some alarmserver changes too, wonderful right? hahaha…but no it’s all for the better.I removed the event codes from the alarmserver.cfg entirely and just moved it into the alarmserver.py - this list was just silly to have there - no one was really changing it, and if i ever had to change the defaults, it meant people would have a list they could forget to update. there was also a bunch of assumptions made assuming people might “not” be using it with a “callback url” aka smartthings integration - it was all based on silly old assumptions - this alarmsever is so specific to ST/DSC integration now that there’s no longer a point in giving people some notion that it could be used otherwise haha…so yeah i simplified a bunch of the documents around that and now you don’t need to have that line in the config at all anymore.
I also cleaned up a bunch of integer/string handling that was involved around those codes - i basically failed at using integers correctly when i first wrote a bunch of this code, but it’s all fixed up now and that simplified things a little on the code side as well.
another change i made is that httpsport is now httpport. this might break some peoples configs, but unless you changed the port from 8111, it shouldn’t matter, as the app will just complain its undefined and then use 8111 anyway. basically - that should be the only gotcha to upgrading, renaming httpsport to httpport in the config. I hate making breaking changes, but that was so stupidly mislabeled that it just had to get fixed. Would be nice to be using https and authentication some day, but don’t think ST local hub communication supports that yet, heh…
4 Likes
@Xero I have sent a pull request to add retry in alarmserver systemd service so that the service automatically restarts if it fails any reason. Please take a look at it here: https://github.com/LXXero/DSCAlarm/pull/6
@mmoeini What operating system are you going to use for your alarmserver? I found Raspberry Pi works great if you don’t have any PC that is running 24x7 already.
Several things I had to do for setting up the alarmserver.
-
Update alarmserver.cfg accordingly.
-
Install “requests” python module
sudo apt-get install python-pip
pip install requests -
Upload alarmserver to /home/pi/alarmserver/ folder
I have used WinSCP to upload them in case you wonder. And I also modified the permission of the *.py files to include “x” (execute).
-
Test it by running it interactively by running below:
/home/pi/alarmserver.py
Let me know if this works for you.
1 Like
I am also new to Linux, so not sure what I suggest here is the best, but let me try. The alarmserver python script fails if network is not online. It might be possible to add a dependency to network.online.target, but I solved it differently.
Just add the following in [service] section:
Restart=always
RestartSec=3
Good thing about this approach is that it will restart if the service fails due to intermittent network glitch as well.
1 Like
@shjin - THANK YOU! I changed my service file to reflect your suggestion and it works… sort of. Your fix made it apparent that the alarmserver fails multiple times and it takes about a minute or so for it to successfully run. It has to be something related to the booting process of the Odroid C2.
Line 1216: Feb 11 10:28:07 odroid64 systemd[1]: screen@root.service: Unit entered failed state.
Line 1234: Feb 11 10:28:11 odroid64 systemd[1]: screen@root.service: Unit entered failed state.
Line 1289: Feb 11 10:28:15 odroid64 systemd[1]: screen@root.service: Unit entered failed state.
Line 1305: Feb 11 10:28:19 odroid64 systemd[1]: screen@root.service: Unit entered failed state.
Line 1313: Feb 11 10:28:23 odroid64 systemd[1]: screen@root.service: Unit entered failed state.
Line 1326: Feb 11 10:28:27 odroid64 systemd[1]: screen@root.service: Unit entered failed state.
Line 1334: Feb 11 10:28:31 odroid64 systemd[1]: screen@root.service: Unit entered failed state.
Line 1342: Feb 11 10:28:35 odroid64 systemd[1]: screen@root.service: Unit entered failed state.
Line 1355: Feb 11 10:28:39 odroid64 systemd[1]: screen@root.service: Unit entered failed state.
Line 1363: Feb 11 10:28:43 odroid64 systemd[1]: screen@root.service: Unit entered failed state.
Line 1371: Feb 11 10:28:47 odroid64 systemd[1]: screen@root.service: Unit entered failed state.
Line 1390: Feb 11 10:28:51 odroid64 systemd[1]: screen@root.service: Unit entered failed state.
Line 1398: Feb 11 10:28:55 odroid64 systemd[1]: screen@root.service: Unit entered failed state.
Line 1406: Feb 11 10:28:59 odroid64 systemd[1]: screen@root.service: Unit entered failed state.
Line 1417: Feb 11 10:29:03 odroid64 systemd[1]: screen@root.service: Unit entered failed state.
Line 1439: Feb 11 10:28:11 odroid64 systemd[1]: screen@root.service: Unit entered failed state.
Line 1494: Feb 11 10:28:15 odroid64 systemd[1]: screen@root.service: Unit entered failed state.
Line 1510: Feb 11 10:28:19 odroid64 systemd[1]: screen@root.service: Unit entered failed state.
Line 1518: Feb 11 10:28:23 odroid64 systemd[1]: screen@root.service: Unit entered failed state.
Line 1531: Feb 11 10:28:27 odroid64 systemd[1]: screen@root.service: Unit entered failed state.
Line 1539: Feb 11 10:28:31 odroid64 systemd[1]: screen@root.service: Unit entered failed state.
Line 1547: Feb 11 10:28:35 odroid64 systemd[1]: screen@root.service: Unit entered failed state.
Line 1560: Feb 11 10:28:39 odroid64 systemd[1]: screen@root.service: Unit entered failed state.
Line 1568: Feb 11 10:28:43 odroid64 systemd[1]: screen@root.service: Unit entered failed state.
Line 1576: Feb 11 10:28:47 odroid64 systemd[1]: screen@root.service: Unit entered failed state.
Line 1595: Feb 11 10:28:51 odroid64 systemd[1]: screen@root.service: Unit entered failed state.
Line 1603: Feb 11 10:28:55 odroid64 systemd[1]: screen@root.service: Unit entered failed state.
Line 1611: Feb 11 10:28:59 odroid64 systemd[1]: screen@root.service: Unit entered failed state.
Line 1622: Feb 11 10:29:03 odroid64 systemd[1]: screen@root.service: Unit entered failed state.
Line 1635: Feb 11 10:29:07 odroid64 systemd[1]: screen@root.service: Unit entered failed state.
Line 1643: Feb 11 10:29:11 odroid64 systemd[1]: screen@root.service: Unit entered failed state.
Line 1660: Feb 11 10:29:14 odroid64 systemd[1]: screen@root.service: Unit entered failed state.
Line 1676: Feb 11 10:29:18 odroid64 systemd[1]: screen@root.service: Unit entered failed state.
I am reviewing the boot log but I can’t tell what is holding up the execution of the service for so long. I knew it was a timing issue as I could run the service manually after a few minutes but until your suggestion I had not figured out how to get the system to wait long enough to automatically start the service. It currently failed over 30 times but then manages to start. I’d prefer to fix it so that it doesn’t have to do so but now I have more time to work on it, so thank you again!
It seems like Debian flavor of Lunux requires some further setup to make network-online.target work. I will try the same myself tonight, but you can read this:
If your distro is using systemd-networkd for setting up it’s networking, you can try to enable the systemd-networkd-wait-online.service which will pause the boot process until the network comes up, for up to 90 seconds.
systemctl enable systemd-networkd-wait-online.service
No guarantee that’s the problem - but it might help some people. I should add, I never had these issues on my setup, but I’m running it on my media server which is running arch linux, not a rasbpi or debian/redhat based distro, though I recently had an issue where my dhcpd server wasn’t starting and this wait-online thing fixed it for me.
I am running my setup on an Odroid C2… an awesome little SBC that seems much faster than RPI thanks to eMMC and 2GB RAM. It is running Ubuntu 16.04
http://www.hardkernel.com/main/products/prdt_info.php?g_code=G145457216438
I’ll try your suggestions above to see if it helps however I just added my router as the first NTP server the C2 should pull the time from and the failed attempts went from 30+ to about 5. This SBC doesn’t have an onboard RTC but I have one I can add… Who knows, maybe that will help as the correct time will be readily available.
Please review new pull request for systemd unit file improvements:
Improvements are:
- Fixed file name to be alarmserver@.service.
This was done because I found you do not need to re-name the file with user name according to systemd documentation. Just ending with @ symbol is enough. - Included some documentation to help people setting-up