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
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.
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'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.
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:
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.
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.
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:
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
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
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.
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.
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.
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 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:
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?
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
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.
