I adapted LeeFL's original SmartThings code to operate with Hubitat, and posted my code on github: GitHub - michaelvandam/Hubitat.
This is still a work in progress and doesn't yet have a nice installation/setup GUI, but this is something I may work on if there is interest. In the meantime, I have included detailed setup instructions in the README file. I have tested this code and regularly use it myself.
Please feel free to contact me if you have any questions or suggestions!
Grateful for the work you've done here, M. I'm stating migration from ST to HE and the Alarm Bridge is my first device. Unfortunately, I haven't been successful in creating the individual zone devices in HE. My ST interface with LeeFL's bridge has been working flawlessly for over a year so I'm pretty certain that component is ok. I'm using the procedure in your GitHub Readme. All works ok until "Go to Devices and check that all of your zones have been created." Mine aren't. All I see in my device list is the "original" Alarm System Interlogix. I looked at the App log and Dev log and I don't see any errors. In the Dev Debug log I see the correct IP address (from Configure). I see "getAction(uri=/getzonenames)" and the "About to call the actual hubAction", so the call seems to be going to the Bridge. But there's no subsequent proliferation of individual zones. My only deviation from the Readme procedure (that I can uncover) is the bridge firmware version. I'm using 0.02.10 versus your 0.02.04. Do you think that's causing my failure? (I don't have a copy FW 0.02.04, else I'd roll back to see the problem is solved.) If firmware isn't the likely issue, any other suggestions?
Hi Schooner, thanks for your interest in this. Certainly happy to try to help.
I've also used the 0.02.10 firmware and am currently using 0.02.13, and in my logs I'm seeing the right handlers get called in my setup, so I suspect this is not the issue.
After you see the debug message "About to call the actual hubAction", do you see another message "Inside handleCreateZones(zones)"?
Another thing to try is go to http://<your_bridge_device_ip>/getzonenames, and you should get back a JSON structure listing of your zones with the "update_type" of "zone_names". Are you seeing that occur?
Also, this is probably a silly question and you've already done it, but on the Device preferences, did you enter and save the password for the bridge device?
Thx for the quick reply, Mike. Good to know that everything works with f/w 0.02.13. I've updated my bridge to .13. Your hints solved my problems! Works perfectly. (I'm kinda embarrassed to tell you which hint solved it. Let's just say that your next revision of the Github readme could include: "Special instruction to idiots: Enter your password.").
Thanks so much!!
Sorry for the late response, but I'm very happy to hear that you got it sorted out! Let me know if you run into any other issues or have any questions or suggestions.
I very much appreciate your feedback about the installation experience - I wrote the install docs quite a while ago and realize there is a lot of room for improvement! The next time I update it, I will definitely add some more specifics in various places, include which Device parameters need to be configured.
The installation docs were fine. I don't think many, if any, changes are required. I was able to follow along pretty easily.
New subject (sort of): I noticed alot of hsmSetArm = disarm events in my System Events so I poked around a bit. I discovered that the sendLocationEvent(name: "hsmSetArm", value: "disarm") at line 365 was triggering it. I'm not sure why I'm having so many "'notready' status found" cases, but each time it does occur Line 365 sends the disarm command (and triggers a system event). My solution was to comment out that one line. I don't understand the logic well enough to know if eliminating this line of code will negatively affect the operation of the app. In my case, I use the app mostly just to fetch the status of the zones, so I think I'll be ok.
Just wanted to give you a heads up in case you haven't noticed it. Again, thanks for all your work!
Lee's device handler is based on a fork of my original code for the Visonic alarm system, and I have been discussing some merges with him in PM - so a single handler should support multiple alarm bridge devices.
Would fully support all the latest changes in ST and firmware.
I'm aiming to release some code for it this weekend, subject to testing, but would be good to hear what interface tweaks you have made, and can see if I can merge them in.
Thank you Schooner... appreciate the info about the disarm events, I will make sure to correct that in future updates, but glad you found a solution already. I'll have to look into a bit to see exactly what is going on. I've found the Networx/Interlogix system not to be very predictable in the states that it transitions though, and so the app code currently overcommunicates to the HSM to update its status. But it should be possible to for me to better keep track of previous state and avoid sending out duplicate events. I'll keep in mind for a future set of code updates.
As for the impact, I think in the worst case you might find the HSM status doesn't update properly (or not quickly), if you happen to be using HSM to observe the alarm system status. If you're not doing that, there should be no impact for you.
Hi cjcharles,
I'm not sure if you intended to post this over on the SmartThings discussion rather than this Hubitat thread...
But since this Hubitat port was based on Lee's code which is based on your code, I would certainly be interested in having a look at the updates you make and happy to share any ideas. (I don't have a ST hub to test, but I should be able to follow along the code and see what has changed.)
And I should say thanks for your original work on the Visonic alarm system that led to Lee's developments which I have relied on extensively
I'm actually testing Hubitat for myself, so once the device handlers are merged on the ST end (done) then I'd like to release it over here with some tweaks (some I've done already to get a simplified version working). I'm keen to see the changes you've made and then release a single DTH that will support Networx, Visonic and Elk (through my original implementation, aware there is another here already, but just keen to standardise all).
Sounds good, standardization always seems like a good thing, and maybe there is some commonality that at some point will make sense to consider merging?...
You can see my code in the github link at the top of this thread -- it follows pretty closely Lee's version, but I did have to do some pretty major reorganization to work smoothly in hubitat. The biggest change was to separate the single file into separate device code and app code. The bulk of functionality is still in the device code (plus I added some Virtual Sensor devices so I could support the ability to bypass zones). The app is mostly for installation and setup (though incomplete) of the device, creating buttons to control the alarm, and also does a few things like set up some subscriptions to notify the Hubitat Safety Monitor (HSM) about status changes in the alarm system.
I finally found the time to release a version of my device handler to support my own alarm, it should work seamlessly with the latest version of Lee's firmware (though I can't test this as I dont own an Elk).
It is all built with a single parent device handler (no app) that creates a child for each zone/output and one for each of armaway/armhome/disarm (any of which can be disabled). It has attributes clearly broken out so they can be added to a dashboard easily. Its also got a setting in the parent to enable/disable syncing with HSM. Its the first proper device handler Ive built for Hubitat, so would love to hear your thoughts and feedback on it, and can hopefully improve it further. Currently doesnt support your Bypass features.
Hello all!
Just wanted to say that I am jumping ship from ST to Hubitat, primarily because the transition from the Classic ST app to the new ST app essentially broke the LeeF integration for me rendering the Alarm bridge useless. After spending 5+ hours trying to fix it, I gave up and ordered a Hubitat.
Looking forward to making this work and learning Hubitat!
The next time I update it, I will definitely add some more specifics in various places, include which Device parameters need to be configured.
