[BETA] Abode Alarm system driver

[endorphin_junkie]

@hokfujow

Can't seem to find where to access the events that are being received

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

[hokfujow]

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?

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

[hokfujow]

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.

[endorphin_junkie]

@hokfujow

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?

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

@hokfujow

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.
...
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.

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.

@hokfujow

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.

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

[endorphin_junkie]

@hokfujow

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).

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

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.

@hokfujow

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.

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

I'm just learning about this stuff myself, sorry Based on what I've seen before, I suspect that this is the basic documentation https://docs.smartthings.com/en/latest/smartapp-developers-guide/simple-event-handler-smartapps.html

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.

[endorphin_junkie]

@hokfujow

Is there a way to change event subscriptions?

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 - #19 by Ryan780

But the nutshell answer comes down to this:

@chuck.schwer

There is currently no way to subscribe to all events of a device. We discovered this recently and have a ticket open to get it added.

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...

[endorphin_junkie]

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

[hokfujow]

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.

[hokfujow]

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

[hokfujow]

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?

[hokfujow]

@endorphin_junkie

isStateChange: true

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?

[endorphin_junkie]

@hokfujow

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'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)

@hokfujow

Do I need to delete the Abode system device and re-create it from the updated driver?

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

@hokfujow

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

Fixed.

[endorphin_junkie]

Moving from a PM back to the public chat:

@hokfujow

Created a new device based on the modified driver - and the events show up as states now:

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

@hokfujow

Looking at log for the device , I see this: (note one error)

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

@hokfujow

This is what is showing up Maker API right now, at the same time as the events were seen in Abode System device:

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.

[endorphin_junkie]

@hokfujow

Had a separate question for you - I see that the Abode device saves password - when I go to login, it shows up in the field when I click there with characters shown rather than obscured. Unless this is the browser saving it and not Abode driver? Seems like a bad thing to have available in unencrypted format. I'll check if the issue is a setting in chrome.

Fixed in https://raw.githubusercontent.com/jorhett/hubitat-abode/v0.6.3/AbodeAlarm.groovy

[hokfujow]

So we've had a lot of back and forth - want to make sure we're synchronized. Last thing I found was that maker api subscribes to events based on capabilities - I don't know if that's as simple as adding the ContactSensor capability to the driver, or something more than that.
I'm also not clear on how specific events are associated with that capability - that is- the driver sends events that are of that type - but I'm not clear on how the App knows that those go with that capability.

[hokfujow]

A little more progress - adding capability contactsensor to driver makes contact events show up as subscribed events in the Maker API setting. However, despite confirming that I added isStateChange : true, to the SendEvent lines, still showing up as null .

So the log you need to see is trace log for Maker API or for Abode System or both? And is that appropriate to post here ?
Thanks!

[endorphin_junkie]

@hokfujow

So we've had a lot of back and forth - want to make sure we're synchronized. Last thing I found was that maker api subscribes to events based on capabilities - I don't know if that's as simple as adding the ContactSensor capability to the driver, or something more than that.

Capabilities contain attributes and commands. That's just another way to say you can only subscribe to an attribute. Driver Capability List - Hubitat Documentation

@hokfujow

A little more progress - adding capability contactsensor to driver makes contact events show up as subscribed events in the Maker API setting.

You can add any capability to the driver then see things to subscribe to... but that driver isn't generating events for those capabilities so there's no data source. This is like putting wheels on a house, without a motor and steering wheel you can't drive it

I don't think this is the problem. And if this is the solution, then my plan to create virtual devices of the appropriate type will solve it, because then you'll have a virtual child device that is a contact sensor, and stores changes in the attributes relevant for contact sensors (which are part of the capability)

@hokfujow

However, despite confirming that I added isStateChange : true, to the SendEvent lines, still showing up as null .

Agreed, and as I said before--you should engage Hubitat support on this. The logs prove that the driver is supplying the data. Why MakerAPI can see it, log it, but not use it is a platform issue or a MakerAPI issue, neither of which I can support.

@hokfujow

So the log you need to see is trace log for Maker API or for Abode System or both? And is that appropriate to post here ?

Abode-- I can't help you with MakerAPI.

You saw an integer out of range error in the Abode device logs. I need you to collect trace logs when you do the thing which causes that error so I can figure out what's wrong. I don't see that error when I log in, so I need the trace logs to compare. Send them to me by PM, as they will contain your personal details. Or scrub your personal details--I need to see the fields returned, the data in the values is unlikely to be important

[hokfujow]

Hi - I posted this regarding Maker API and got back this response regarding suggestions for modifying the driver:

Maker API New Features

I believe Maker API is going to work best with Standard Capabilities (I.e. attributes and commands.) If the drivers you are using are not implementing standard capabilities fully, the it is unlikely to work well with Maker API. It appears you’re trying to add a standard capability, but the question remains, has it been properly implemented in the driver to raise the correct events? “alert_name” is not a standard attribute of a Contact Sensor. “contact” is the correct attribute for a Contact …

[Ryan780]

Actually, the problem is in your driver. You are using sendEvent incorrectly. The name parameter in the sendEvent corresponds to the attribute name, not the device name. A device can only send events for itself. If you have something with multiple devices to support, you should create a parent/child device.

Maker API New Features

It appears that's because the driver isn't publishing an event for an attribute titled alert_name, it's publishing an event for "Front Door" That should be a string of "alert_name" or "contact" not the name of the device that is opened or closed. If the device is intended to monitor multiple contact sensors, then it should have child devices for each sensor. That's the only way you're going to get it to work right. The name is in reference to the attribute, not the device that is opening …

In this example, you send the event as follows:
{"device_id":"[device ID]","label":"Abode System","name":"Front Door","value":"Closed","date":"2020-04-01T14:52:45+0000","unit":null,"isStateChange":null,"source":"DEVICE"}

That means that the name of the attribute is "Front Door"? That's not correct.

Also, in order for events to work, the attribute name must be declared in the metadata. You don't declare anything in the metadata for the events you are generating.

Also, your type is incorrect. Type can either be digital or physical. You are setting it equal to some other value. And "displayed" doesn't do anything in Hubitat, whether it's true or false. So, don't bother putting it in unless the driver is also intended for ST.

[hokfujow]

Thanks @Ryan780.
@endorphin_junkie, there were some more helpful comments on the thread I referenced regarding using child devices. I get this conceptually, but don't yet understand enough of the guts to work this out myself.