[BETA] Abode Alarm system driver

The Abode driver I've been working on has reached what I believe is a viable and useful feature set. I'm soliciting more users to confirm stability of this before v1.0 release.

You can control Abode alarm status from Hubitat, as well as act on real-time updates of Abode status changes, CUE automations, and actions from Mobile clients.

2020-04-04T07:00:00Z Version 0.7.0 features

  • Login to the API Portal -- supports MFA auth
  • Arm/disarm Abode from Hubitat driver page or Rule Machine
  • Synchronize Abode-initiated mode changes with Hubitat Mode / HSM
  • Copy Abode timeline events to Hubitat device events

Follow the instructions at hubitat-abode/wiki - Getting Started

Preferences allow you to sync Abode mode changes to Hubitat Mode.

Optional event synchronization makes Abode gateway timeline events available for automation.

More details at GitHub - jorhett/hubitat-abode: A Hubitat driver to interface with an Abode alarm system. Make sure you install the v0 release and not whatever is currently on master :wink:

1 Like

There's now a logging improvement, mode management minor cleanup release at

https://raw.githubusercontent.com/jorhett/hubitat-abode/v0.6.1/AbodeAlarm.groovy

I've added documentation for getting started, plus how-to walkthroughs for setting up automation that controls or responds to Abode events.

Version 0.6.2 came out today because I finally had let it run past the purported login expiration and found that this wasn't a concern. Hubitat remained logged in, but a new access token was required. Easy fix, and it appears that this is working as desired.

v1 Release will go out one week from today, barring any new bugs found.

https://raw.githubusercontent.com/jorhett/hubitat-abode/v0.6.2/AbodeAlarm.groovy

Hi - first, thank you SO much for doing this. Awesome.
I've read all your instructions and set it up as you specified. Everything looks right - shows logged in, responds to changes in Abode state, able to change abode state from hubitat. All good.
But I can't seem to access any events other than alarm system state for use in Rules.
I see the events coming in the device as expected. I've turned on the options to copy events (all kinds) to hubitat events. However, they don't seem to be available as triggers in Rules engine. Have tried every trigger I could find - custom attributes for Abode device only has system state. Can't seem to find where to access the events that are being received - they don't show up in the System events.
Is there something I'm missing?

I'll check that now. I had this working but I'm not actually using it now that I built the ability to change the Mode into the driver. Gimme a bit.

Got my own set of events today (false alarm thankfully) that I wish I'd had alerts for:

I'm sorry, I may have confused you (and myself!) with my feature notes. Driver-provided custom Hubitat Events are available for Apps to subscribe to, but there's no way for Rule Machine trigger on custom event text. It can trigger based on custom attribute change, or it could be triggered by creating a child device that it knows how to read events from.

For example of using child devices to mirror Abode, the -isArmed device is a switch that you can use as a trigger for Rule Machine.

If you're willing to explain what you'd like to do, I'll see what the best path to solve that is.

FWIW, I'm thinking that I'll likely be creating an Abode application which would have the smarts to look for devices on the Abode side and mirror their state into Virtual devices of the same type in Hubitat. Not this week or next, but sometime soon.

Sorry, I overlooked this question. The events received by the Abode driver are available by clicking Events on the driver page, just above Arm Away

Screen Shot 2020-03-30 at 12.46.41 AM

Thank you for all your responses! If I understood the situation, the events created by things like contacts closing are visible in Events list - but not currently accessible to use as triggers in Rules Machine. Is that correct?
And you're considering creating some kind of App to make use of these - soonish but not real soon?
:slight_smile:

As far as what I'm trying to do - I'd like to be able to use events such as motion detected, door/window opened closed, and other such events in my automation software - Home Control Assistant. HCA receives events from hubitat via HTTP posts from Maker API App. I see that Abode is available in Maker API, so if I could grab the events that way - I wouldn't necessarily have to have them available in Hubitat triggers (although that would still be helpful).

But....I see now that Abode in hubitat is getting authentication errors - I know you talked about needing to reauthenticate but I wasn't clear on how that ended up.

So - summary:

  1. I'd like to be able to get access to Abode events in my automation software. If Maker API could pass them via HTTP post from hubitat, that would do what I need.
  2. If the above doesn't work, if they were available as triggers to Rules, I could use Triggers and virtual devices in hubitat - those events definitely make it to my software. It would be nice to not have to create and control virtual devices for every object - so if the events could be passed directly via Maker API, that would be preferable.
  3. I'm unclear on what the current situation is regarding re-authentication.

Thank you very much for your help and effort!
Michael

Just a little more info if helpful. Logged back in to Abode via your device. Then checked Maker API app. I enabled the Abode System (but not the isarmed trigger). I checked the URL shown at the bottom of Maker API page and saw that events from the Abode contact sensors were indeed visible (but not Motion detected - but you may not have included that).
However, for some reason, those events are not getting passed to my software via the Post command the same way that other devices in hubitat do.
Then I went into Maker API settings and saw this, suggesting that it isn't subscribed to any events except gateway mode:

Is there a way to change event subscriptions? Not sure if that's coming from your driver or Maker API or something else.

Yes, that is my understanding based on @bravenel's responses in some other threads.

I have no experience with Maker API. I'm curious too, and happy to help work on this--but my evenings are spoken for over the next few weeks. I probably have time for small patches, but not to soak Maker API into my head for instance.

I recently fixed an error around auth. Make sure you have the latest driver. If you have any problems, get me logs or at least events history. Show me what you're seeing :+1:

Yeah I suppressed it. I'm willing to expose it, but I'm not sure how useful it will be since it doesn't provide any clear value. It's just a name without a value--which I only know means it saw motion because it's named PIR (a type of motion sensor) and it happens when I walk across the room. There's no apparent "clear" or stop, so you're going to have to decide that motion stopped based on some data they aren't providing.

Here's a sample of the logs we get. The trace log is actually every single character we receive on the websocket. There's nothing more :frowning:

dev:556 2020-03-30 09:12:39.398 pm debug Ignoring Event device.update SR:PIR
dev:556 2020-03-30 09:12:39.394 pm trace webSocket event raw: 42["com.goabode.device.update","SR:PIR"]
dev:556 2020-03-30 09:12:15.207 pm debug Ignoring Event device.update SR:PIR
dev:556 2020-03-30 09:12:15.202 pm trace webSocket event raw: 42["com.goabode.device.update","SR:PIR"]

If this matters to you, turn on trace logging and spend some time gathering information by testing the sensor. If you can make reasonable sense of the data so that we can expose it usefully I'm happy to do so. But with just the mention of the PIR, there's nothing to do work it.

So it would appear that it only sees the values for custom attributes.

I'm just learning about this stuff myself, sorry :frowning: Based on what I've seen before, I suspect that this is the basic documentation Events and Subscriptions — SmartThings Classic Developer Documentation

Hubitat does have their own brief thing, which does indicate a filter ability they've apparently added App Status - Hubitat Documentation

I think that we're just going to have to poke around and see if we can get the other event data without storing it in custom attributes. Best thing is to try.

If you can't figure it out, I'm sure I'll be learning the same stuff when I crack open trying to make an app for this.

Okay, I have found the full answer to your question. FWIW, this entire thread is good reading Can you subscribe to ALL events of a device in an app

But the nutshell answer comes down to this:

I still don't know if it will be all events tied to attributes, or all events period, so unless @chuck.schwer is willing to answer that...

I don't have time to test this tonight, mostly because I don't have an App to receive it... but if this document note is correct, perhaps if we add isStateChange: true to the sendEvent parameters it might be relayed through the system and visible to MakerAPI.

https://docs.smartthings.com/en/latest/device-type-developers-guide/parse.html#parse-events-and-attributes

I would suggest adding it to the sendEvent invocations on these lines: hubitat-abode/AbodeAlarm.groovy at v0.6.2 · jorhett/hubitat-abode · GitHub

Hi - thanks for staying on this.
I realized that Abode doesn't capture anything from motion detectors except when it's armed Away - so they aren't useful for general motion detection anyway, so not worth doing anything with that.

I haven't learned groovy (though I've been meaning to) - so probably won't attempt to mess with the sendEvent stuff myself, unless you decide not to do anything with it at all. Totally understand it may not be for a while. I'll take a look at what you linked to though - if it doesn't require understanding a lot about the code, I'll take a shot at it at some point.

I think you already realize this - but the attached photo shows the misleading or mistaken instructions.

Making some progress - Maker API does not seem to be passing events via Post. When I looked at device info for the Abode System device, I got this:

{"id":"xxx","name":"Abode System","label":"Abode System","attributes":[{"name":"gatewayMode","currentValue":"standby","dataType":"STRING"},{"name":"isLoggedIn","currentValue":"true","dataType":"STRING"}],"capabilities":["Refresh","Actuator"],"commands":["armAway","armHome","disarm","logout","refresh"]}

I also turned on debug logging and none of the Abode contact events show up. So it appears this device is only for Gateway mode (which may be what you intended) - but it's not clear to me where the device events are going. The contact sensor events show up on the events tab of device abode system - and they show up at this URL:

http://[hubitat IP]/apps/api/x/devices/[device ID]/events?access_token=xxx

but somehow, they are not associated with this device in the same way that events for a switch are. So Maker API does not send them via Post. I don't know what the distinction is - is this determined by the set of attributes?

Okay - realized this wasn't as complicated as I thought (making the change). Added the parameter to those SendEvent lines - so far, no obvious difference. Do I need to delete the Abode system device and re-create it from the updated driver?

I'm absolutely sure you can handle this. Change this:

sendEvent(name: alert_name, value: alert_value, descriptionText: message, type: alert_type, displayed: true)

To this:

sendEvent(name: alert_name, value: alert_value, descriptionText: message, type: alert_type, displayed: true, isStateChange: true)

Nope, just save the changes to the driver then go generate some Contact events.

Fixed.

Moving from a PM back to the public chat:

That's not a change--they always do, until you reload the page. Only the events with named attributes stay.

I need trace logs to debug what that is. Debug logs are for you, trace logs are for me :wink:

I'm assuming app:4 is MakerAPI on your hub? If so that log proves that the events are there. I think unfortunately you're going to have to ask Hubitat why you can't see them, as the driver is clearly passing them along for an app to log them.

P.S. I noticed that your log shows isStateChange: null which might mean your change didn't take effect.