I wish I could say this will be easier, but there are a number of steps involved and it may seem a bit daunting as well, but I’m here if you need help.
The only change to alarmserver is a minor one in its config file, so it will be simple enough to revert back if needed. All new devices on the mobile app, so you won’t touch your existing setup.
The benefit of all the effort is that you’ll be free of the IDE, DTHs, and Groovy, and no need for a SmartApp for alarmserver. Beyond that, you can then write your own device apps to run on your own Pi to do just about anything you want.
Make sure you have a Pi model 3 or later, upgrade it to the latest O/S (Raspbian Buster) and get yourself a Developer Workspace account.
So - looking at the instructions this afternoon, but my immediate thoughts go to - couldn’t we just build the whole shebang including appropriate versions of Python, the SmartThings directConnect, AlarmServer and such into a Docker Container?
Possibly! I thought about eliminating the core SDK pre-req altogether and just providing the executables, but not sure how portable that would be across OS versions and Pi models. The one catch is the need to generate device serial numbers and device QR codes (for onboarding) using a couple SDK tools, but they’re just python scripts, so that could probably be easily packaged up without the rest of the SDK. In fact those tools are the only reason for the Python pre-req at all.
If you have experience in this area, let’s work together to explore that option. I’d say go ahead and install as-is and get a feel for all the elements, then it might become obvious what the possibilities are regarding containers, or generally simplifying things.
I appreciate the fact that many if not most alarmserver users just want the thing installed and working, and may not be interested in any further device app development, therefore no need or interest in all the SDK gorp.
Also new news: automations is evidently starting to work now for custom capabilities, so that’s positive and I can make sure my device configs are fully functional in that respect.
I have a Honeywell Vista 20p. I spun up MattTW’s version of alarmserver on a Pi 4 last night. I was able to get it running succesfully for api calls. I have not yet integrated into smartthings. It got pretty confusing keeping track of all the different options, and I’m not sure which options are compatible with the honeywell version of alarmserver. As I’m starting fresh, which integration option can I use for Smartthings?
Coincidently, I just heard from someone who is working getting the direct connect package (not yet alarmserver stuff) working inside a docker container! We’re working through some issues he’s having so far, but I’ll get some learnings from that.
I had some free time this weekend so I did some updates to the DSC panel devices. With custom capabilities now working with automations, I managed to fix my capabilities used by the DSC panel devices to have working automations. This should made it also easier to sync the STH panel. I also added an animated lock icon for the dashboard, and fixed the sending of a double Arm Stay, which was resulting in an annoying long beep…
I also have been running newer version of AlarmServer for the past while on my systems, and added it to the repo also.
Correct, all the calls to AlarmServer are the same.
The new one I upload does a bit more error checking, fixes some minor problems, and has a new TIMETOWAIT variable in case you want/need to change the amount of time AlarmServer waits for a response from SmartThings after sending a POST (it will then try again if SmartThings does not acknowledge it received the command).
I’ve testing this version on both my Windows and Ubuntu systems for the past few weeks with no problems.
Just to add, I updated all the devices now so that bypass now works (yeah, SmartThings fixed the switch finally), and trouble status also now working better. Also, automations (conditions) can be used.
My smartthings DSC Alarm part stops working recently. I can’t arm/disarm from smartthings: if I use STHM panel buttons to arm/disarm, the highlight will move from one to another but does nothing to the alarm; if I use the virtual switches (DSC Away Panel & DSC Stay Panel), they simply won’t turn on. However, when I physically use alarm keypad to arm/disarm the alarm system, the alarm status will change accordingly in STHM. Looks like it syncs from physical keypad to smartthings but not other way around.
I checked alarmserver running on my Pi and it reports all the sensor activities correctly. Checked Webcore logs and seems no issues either. The only thing I changed recently is my actiontiles password, I have since changed it back.
Any idea what can be the problem? Thanks in advance for any help.
I’m using the latest version of the smart app and it has sync with Smartthings but I still think it’s only one way. IIRC, if you change state in STHM, it will set the panel, but you need automations to have changes at the panel reflected in STHM.
Check your smart app setting to ensure that STHM sync is enabled and make sure your automations are still enabled
Thanks a lot for your response. I did have STHM sync setup (I believe 6 of them) and it’s been working great for a while. I had to setup those automations since Samsung retired the old ST app. I have been using the alarm status and sensors for a lot of automations (lights/switches/TVs/sonos) but now all won’t trigger.
It suddenly stopped working a couple of days ago and I couldn’t figure out why. I only changed actiontiles password (I remember AT needs to be there for the sync) but have changed back since.
I tried other ways such as “EyezOn ST Switches” to work around without success.
If you are using automations for everything then start there. Add a virtual switch in IDE and make it an additional trigger for the automations. Then add it to each automation individually and test manually triggering them.
Most of the time I see something in the automation that is preventing a trigger like mode checking or time of day checking.
@rtorch Need your help. With the new updates to the SmartApp and Devices Handlers, my STHM in the ST ios app is going wacky:
If I hit one button it will actually turn on the others. i.e if I hit “ARM Stay” it will go to "Arm Stay "and then a second later to “Arm Away”, then few seconds later it will go to “Disarmed”. The panel seems to be going to the first button I selected, but STHM goes wacky and cycles through those other buttons.
I have reset my Hub, but no change. Last working was the Oct 2020 version and hasn’t had problems until I upgraded these. I tried going back to those older version but this problem still exists
Yes @rtorch
I have the same automations that update STHM when the alarm is turned on/off from the DSC itself. I’ve tried turn those off and still the same issue.
Chabge thr virtual switches involved in these automations form the ‘virtual switch’ DTH to ‘Simulated Switch’ short version, the behavior of virtual switch is different in newapp and can cause a race condition when theres a loop like a two way sync.
