Fixed in https://raw.githubusercontent.com/jorhett/hubitat-abode/v0.6.3/AbodeAlarm.groovy
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.
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!
Capabilities contain attributes and commands. That's just another way to say you can only subscribe to an attribute. Driver Capability List - Hubitat Documentation
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)
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.
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 
Hi - I posted this regarding Maker API and got back this response regarding suggestions for modifying the driver:
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.
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.
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.
My goal in writing the driver was to sync the unit's alarm state, not to mirror the state of all devices. I am using it correctly to adjust the gatewayMode attribute.
I understand that you are objecting to my use of Event to sync over timeline data from Abode so that all security history can be seen in Hubitat. If you have a better implementation I'm happy to address it.
I understand that you feel that I should mirror every single device ala HubConnect, but that was never my intention and I have no personal need for that. I may or may not do it just to learn, but that would be a separate App that I have no intention of using myself.
Ah sorry. Saw the field was available, and lacking any documentation to describe its use to me... interesting that it accepts any value, though.
Good to know! Thank you.
Long and short, the only model people are saying will work is what I mentioned earlier in this thread:
My caveat is that I'm really busy, and I don't personally want or need this feature. I am thinking of this as being something fun as an exercise to learn more about creating Hubitat apps, but it's just not going to be a priority for me.
You are not sending events correctly. You cannot send an event if the attribute is not declared in your metadata, either directly of through a capability. If you do, the event will go into the database but no app will ever be able to subscribe to it, making your driver completely worthless. But hey, if you wanna do all this work for nothing, then have at it.
As said previously, the events which don't map to attributes are stored and can be retrieved, which gives me the ability to see a coherent timeline of events across both hubs. That was my goal, and it works.
If there's a better way to do this, great. But I don't think that creating 40 child devices that are completely un-actionable, dumb posts used only to relay state changes, has value to me.
Based on @ogiewon's suggestion and @Ryan780's advice about displayed , I've pushed a revision to the master branch. It seems to work in a basic sense,
https://github.com/jorhett/hubitat-abode/blob/master/AbodeAlarm.groovy
I'd like you to hammer on it before I cut a release. It seems you should be able to subscribe to events from abodeTimeline
I'm using the Type field to indicate the source device, which is possibly bad TBD. Let me know if you can see this field.
Also feel free to comment on placement of the data. I pretty much detest all of the code involved in formatting these messages because it's crazy bespoke. Abode is utterly inconsistent about what data goes in which fields, so the event formatting is basically a hell of if/else on different event types 
Anyone who thinks they have a better idea, I'm all ears
1 Like
Quick test - it looks like this did the trick for my purposes - which is to enable Maker API to send it to my automation software via HTTP Post.
Here's the key part of what gets passed through Maker API and posted:
{"content":{"name":"abodeTimeline","value":"Fam Rm Rear Rt Opened","displayName":"Abode System","deviceId":"xxx","descriptionText":"Fam Rm Rear Rt Opened","unit":null,"data":null}}"
I can parse this in Home Control Assistant and pull out Opened/Closed and the device name - that gets me what I need - can't thank you enough!
I'm not doing anything to subscribe - I just needed Maker API to be able to recognize the events and post them.
Happy to test more though if it's helpful.
Okay so it looks like the type field isn't available in the event, so I'll need to add that to the message.
Just to follow from what I understood the earlier discussion to be regarding child devices, etc. If there were devices created by the driver in such a way that they were visible to Maker API similar to the way your "isArmed" child device is created - i could import those directly into Home Control Assistant (HCA), and it would create mapped devices and be able to get device state updates directly from the Maker API posts.
RIght now, what I'll do is create devices in HCA manually for each sensor and put code in the HCA event handler to recognize the posts and update status that way. .
However, I totally understand that the child device approach that was discussed earlier is a bunch of work. The critical part for me was being able to get the information out of HE and posted - and that now works. If you do ever decide to do the rest, I'm more than happy to help with testing.
I believe there is a feature request to the Hubitat team to add "type" to the Maker API's output. It should be coming in an upcoming release.
2 Likes
Version 0.7.0 has been posted with a number of minor improvements. The most important is that all com.goabode.gateway.timeline events can now be subscribed to from other apps, or used as Trigger events by Rule Manager.
@hokfujow The name of the attribute has changed to gatewayTimeline based on some feedback, a desire for consistency with both the Abode event class and the existing mode attribute.
Great - thanks for the heads up and the improvements.
fwiw seems like there's gonna be a 0.7.1 that involves completely rewriting the message parsing. There's seriously no consistency to their messages. None. I'm gonna end up with a separate parser for every message class
Sorry they're making it so hard!
I created some rules to act on virtual devices in hubitat (it's a bit less work to create the rule in hubitat and import virtual devices into HCA than to use Maker API events and then parse it out in HCA. )
First I created a rule for Front Door Open/Close and then a second one for storm door. What was strange is that Front Door seems to remain in the rule definition in some way.
I'm not sure if it's because the first rule I created was for Front Door Closed - but when I create a rule from scratch, this is what I see.
