So, here is what I have setup as a test for using a “personal cloud”:
Node.js + express on my home server (“Server”) running a script for a SmartApp (I used their “Let There Be Light” as the model for the script)
Server running and listening on port 3000, with certificate and private key for https connections (since I have a dynamic IP, I am using a dynamic DNS).
Developer workspace project for the SmartApp setup for webhooks
Everything deployed and verified! So I was able to create a SmartApp this way, so this is possible. Now I don’t like javascript, and would much prefer to use python, but I don’t think there is a smartthings sdk for it.
On the topic of direct connection, the biggest issue, for myself, is that it is all specific for certain IoT hardware and for using C language. Besides not knowing C, it seems like a herculean effort to get a Pi to act as a IoT device for smartthings.
BUT, we shouldn’t dismiss anything currently, as it seems the API is still developing and things can change.
Terrific progress! Have you tried provisioning and handling device commands? That’s probably a separate API/SDK ?
I guess that does still leave the dynamic vs. static IP / URL issue. I know that can be addressed using something like NOIP service, but it does entail some additional setup.
I haven’t played with device creation from a SmartApp yet. I’m still playing with the new SmartApp flow of lifecycles and how it all works. I’m also attempting to learn JavaScript better at the same time, all in my spare time. It’s fun and challenging, so I don’t mind.
The whole dynamic IP and DNS can be a challenge for some people to set up as it would entail more work. The easiest I’ve found is using DuckDNS and get a certificate from Let’s Except, both free services. Then using Open SSL or KeyStore Explorer to expert the keys/certificate to where you need them.
Update on my Direct Connection work: Got it working from PI! Once I got all wifi config requirements sorted out, I was able to configure my Pi and write some code, and with some help via Github from ST, now have an operational example device humming away. Response time looks pretty good when turning the test switch on and off from the mobile app.
I’ve got some more work to handle errors, automate the wifi provisioning, and make sure I can have multiple devices going simultaneously. I plan to ultimately document and package this up for general use, and will post something on this community’s direct connected device topic when I’m ready for beta volunteers.
As you flush out the cloud-based Smartapp, it would be ideal if you could make it modular so that (1) users can decide for themselves whether to run locally on a pi or lamda server, and (2) the device part can either use direct connect devices or cloud-provisioned devices. We’ll have to look more closely at the Alarmserver code regarding the latter to see what’s doable. I’m sure I could do a version for direct connect and you could do a version for cloud connect, but if we do it right, we can minimize duplication of code and keep it flexible.
Awesome! I’d love to help out with the efforts. Is there an architecture diagram or some place where I can get a quick summary of the infrastructure or what we know so far? Or pointers to links? Just too much reading that I don’t have time for.
That is amazing! I guess I may have to breakdown and finally get a Pi, as opposed to running everything off of Windows server.
I haven’t been able to work much on any code, as I have been very busy with work. I have been thinking though about how to get things moving quicker, as I’m sure the deadline for the end of the groovy IDE is approaching. I have had an idea of just re-writing the current groovy SmartApp that interfaces with Alarmserver, to javascript/node.js so that at least this part would be up and running on the new ST framework. Then slowly move the alarmserver functions into the smartapp running all under javascript. This should then be able to run under node.js locally, or on some other server or even Glitch.
In the meantime (in my “spare” time at the office), I’ll do some reading on direct connected devices to see how it may be different from the cloud connected devices.
Start with the overview of directly connected devices here.
Then read through Jody’s original announcement post for the SDK here.
Beyond that, here is a rough outline of how things work in a PI configuration:
The device definition is done in the developer workplace per Jody’s instructions.
The SDK C code is compiled on the PI with my PI module replacing their ‘POSIX’ one, and linked with your own device driver code that uses the ST APIs to send/receive commands and attributes to ST. Also critical to be included are 2 json files that are created through the developer workplace that contain device and onboarding info.
The PI has to be set up to mimic the wifi provisioning behavior of a typical microcontroller. If you’ve ever provisioned a wifi IOT device (like a Ring cam) you’ll know that it’s a convoluted process of connecting your phone’s wifi to the device’s own wifi access point temporarily to configure it and tell it what access point (usually your home’s wireless router) you want it to normally communicate with. Then you finish that and reconnect your phone back to your wireless router. Then hopefully the device connects successfully to your home’s wifi. This is called Soft AP and it’s derided in the industry as being very user-unfriendly and causes endless customer calls because it’s very confusing to most people. But it’s the only solution there is right now to provision new wifi-based devices. Anyway, that’s really the main hurdle there was to making this all work on the PI. I use two modules: hostapd and dnsmasq that can turn your PI into it’s own access point so that the provisioning process can be completed, because this is what the ST mobile app requires in the add-device process (see next).
Once your PI-based device app is successfully compiled and linked to the SDK, you fire it up and it then starts demanding to be put in either access point mode or station (normal) mode depending on what it’s doing. You then go through the add-device process on the ST mobile app and it attempts to find a wireless AP with the SSID containing your device name & serial number. Once it finds it, it’s now talking to your PI and exchanges device info and the PI is given the info it needs to go and connect to ST’s MQTT server.
At this point provisioning is complete, and the PI operates in regular station mode and connects to the ST server via MQTT protocol. (And frankly I don’t think it really needs wireless at all at this point - it could happily communicate over wired ethernet once provisioning is complete).
The PI device app implements callbacks to capture device commands and updates from ST, and uses API calls to update the same back to ST. It’s a very simple API set and all the MQTT communication is done under the covers.
Luckily the direct connect SDK was designed to accommodate additional device platforms to what they currently support. It just requires some coding to create the platform-specific modules it needs. For the PI, I only needed to take care of the wireless module. They already had POSIX versions for the rest of the required ones, which work as-is on Raspbian.
Overall, even though it took me a while to figure this all out and do the necessary system config and coding to get it to work, once that is all done, it’s actually super simple. It’s really just the provisioning part that’s a pain.
Very little of the above is documented anywhere. There is a porting guide on the SDK github here but it doesn’t explain anything, just lists the functions you need to write. But now that I’ve already done the work for PI, you don’t really need to know that level of detail unless you want to create one for another platform.
My other items like motion sensors are all fine and show the latest status ok, its just those stay/away zones not reporting anything and thus I cannot use Webcore to automate from them.
If I change the device type to a simple version I seem to get the states populated (but they still dont update), not sure what the difference between normal and simple versions is?
The last updated date on the first images is 3 days ago when I installed the latest code. Since changing it to simple it has changed the last updated date but it doesnt seem to change the status for stay or away panels even though the alarm is currently armed, here is the line from the AlarmServer.log saying it had changed it to armed but the screenshot shows otherwise:
I’ve installed 3.8 instead and redone all of the config and files again from scratch and its working now so one of those things fixed it, I’m just not sure which, thanks for your help!
Hey all. Glad to see this thread is around still. So with the IDE being retired in the not too distant future I’ve been wondering if this amazing integration is going to work in the future. Locally I’m running the alarm server on a vm with som other smart home stuff. I don’t know what to think about the upcoming changes. Certainly been debating jumping the smartthings ship. I have been using it for about 4 years and it was the one thing to control dsc, arlo, plex integrations, etc and then my lighting.
Hi again Denis, I’ve just about got a package ready for beta testing. Let me know if you’d would like to volunteer! It includes a much more detailed install/config guide but I’ve tried to automate some of the steps with scripts. Looking forward to have someone else try things out!
Hello all. I just found this thread as I was looking for options integrating my DSC Power 632 (PC1555MX) into SmartThings. I see that this can be accomplished with the EnvisaLink 4 module and Alarmserver according to instructions in this thread… however, I’m curious how is this better (different) than using the konnected.io Alarm Panel Pro (interface or conversion kit)? Seems like the latter integrates directly with SmartThings without the need for Alarmserver.
What I am ideally hoping to find is a solution to use SmartThings SHM with professionally monitored alarm service (will cellular backup) that ideally can interface with the DSC … but not sure this exists.
The short answer is alarmserver and envisalink were created long before konnected was developed. Yes, konnected is a viable alternative and in many cases is a better option.
I believe Konnected now supports your keypads whereas the first version you cut the wires and used them exclusively. This makes Konnected a better choice, it just costs a fair amount in my case. I have a DSC832 so I run Alarmserver as the cost for 32 zones is too high.
Once I got all wifi config requirements sorted out, I was able to configure my Pi and write some code, and with some help via Github from ST, now have an operational example device humming away. Response time looks pretty good when turning the test switch on and off from the mobile app.
