Okay - so the child device would be front door, and the event would be called "contact" because that's a standard attribute of ContactSensor?
Also - does the driver create a single child device of type contactsensor - and then I create multiple devices from that driver for each sensor? Or does the driver have to have a separate child device defined for each one in my particular system?
There is usually one Parent Driver, which would interrogate the Alarm system via an API. This would return the names of all of the alarm system’s sensors. For each sensor returned, a Child “Generic Component Contact Sensor” Device would be created. Then, any time the Parent received new data from the alarm system, it would update the status of the corresponding child device.
Hubitat already has a driver that can be used by a parent device, called “Generic Component Contact Sensor” for the children.
These are events being passed along from the Abode system. They don't map to fixed attributes. It's from one event stream to another. I passed them in as information for the user, if they wanted to see all security-related events in a single location.
Why can Maker API see the events but not use them? If Maker API is logging the events, it has access to them, right? I'm new to Maker API so forgive me.
Yes, this is what I proposed to him before-- we create a mapping of virtual devices for each type of device on the Abode system. He said he didn't want all that, so I was trying to find a way to help him get this event data directly, rather than relaying it through child devices.
Personally, I totally understand the child device model and can do that. But I'm curious why events must map to attributes to be seen. Or not seen, because Maker API can see them... but can't use them? Just thinking from a data flow perspective that seems odd.
I'm not suggesting this would be true for all events. I'm saying why can't an App say "I want to see all events from X driver" and not have every one of them map to an attribute. I would hate to change 20 attributes for a single action just to make all those fields available 
Maker API, like all Hubitat Apps is based on the architecture of "Capabilities". Capabilities define the Command and Attributes that a device has. Apps, subscribe to the events from devices. Events are generated by devices when they update an attribute with the sendEvent() call. Apps expect devices to implement standard Capabilities. This is the only way they know what to expect to receive from a device. This is how the entire platform is architected.
Right now, your events are things like "Front Door" open/close. "Front Door", while descriptive, is not a standard attribute. In the driver I looked at earlier, you have not even defined it as a custom attribute in the driver. Therefore, it will not persist. If you refresh the device details page, you'll notice the "Front Door" will disappear from the screen until the next time an event is generated. A true attribute will stick around when the page is refreshed. Also, custom attributes should not contain white space or special characters.
So, I would recommend you simply implement a Composite Device Driver (i.e. Parent/Child.) You could look at one I recently wrote that makes use of the built-in Hubitat "Generic Component Contact Sensor" driver, as this will allow you to only need to release and maintain the Parent Driver (your existing driver should be able to turned into a Parent Driver fairly easily.)
Take a look at this driver as an example, as I based on some of Mike Maxwell's example code that I pulled together from the forum threads. It is a little complicated due to the complexity of the device that I wrote it for. Pay attention to the 'fetchChild()' call, specifically this line from the parse() routine. This line of code (and the fetchChild() routine inside the driver as well) will create and update a child device using Hubitat's Generic Component Contact Sensor driver. Subsequent calls will only update the child.
//update contact sensor child device
fetchChild("Contact Sensor", index).parse([[name:"contact", value: value, descriptionText:"contact set to ${value}"]])
Hope this helps.
I understand that. If you look at the driver it already has a child device that was necessary for triggering Return from Away.
And I totally get that a huge HubConnect-style map-every-device-between-both-hubs would play better into the ecosystem. I don't doubt that. But I'm curious if there is any way to provide a data stream from a driver to an app that doesn't require creating hundreds of child devices that serve no purpose other than to relay a message?
My goal is to make the timeline events from Abode visible alongside the timeline events in HSM. That's all I intended to accomplish (and it works)
@hokfujow wanted to get to the same events from Maker API so I was curious why they wouldn't be available.
That is not how Hubitat events work. You cannot have an event for a non-declared attribute. No app will ever be able to subscribe to them.
You don't have to do that. If you only want to sync the alarm state, that is all you have to sync. But the driver shouldn't publish events that have no added value to the Hubitat system. What good are they if you can't do anything with them. Publishing an event named "Front Door" doesn't mean anything in Hubitat.
refer back to the post you replied to:
What does doing that accomplish though? What will you use it for? You can't access the events from any other apps to do anything with. If it's just to keep a record, there are much easier ways of accomplishing that that without having to publish events to Hubitat.
Hi - just to clarify. As I'm new to this, I didn't entirely understand what this meant. I thought what this meant is that I need to create individual devices myself for each and every sensor - which sounded like a lot of work. I'm still not totally clear on how this happens - but it sounds like the driver creates the child devices based on what is available - rather than my coding each one separately as I thought.
@endorphin_junkie
Yes, you can create a custom string Attribute. Let's call it 'AbodeDataStream'... so it would look like the following in the metadata section of your driver.
attribute "AbodeDataStream", "String"
Then, simply call
sendEvent(name: "AbodeDataStream", value: "FrontDoor:open")
or
sendEvent(name: "AbodeDataStream", value: "FrontDoor:closed")
You can then use a custom app to to subscribe to the events from this device, which should include the custom attribute "AbodeDataStream". Rule Machine can also use custom attributes these days.
Would that help?
Update: Just be sure to keep the standard Capability of "Sensor" and/or "Actuator" so that Apps can find this device.
As I keep saying, if there's a better way please let me know.
But even more to the point, given that Maker API logs the events generated by this driver it's clear that the data is available to Maker API. And nobody is answering why Maker API can read those events but can't use them? I get that they aren't attributes, but the data is clearly transiting the platform. It's visible to Maker API...
It's not magic. I have to write an app that reads the device list from Abode and then creates each type of device. It's not impossible, but as I've noted in many other threads Abode doesn't support this API and it could break at any time, and they don't publish all the information one might want from the API, etc etc. So the driver is 100% functional for my original goals. This app that would mirror state would always be fairly crippled
EtA: I believe that I already know everything I need to do on the Hubitat side. That's the easier part. Dealing with the limitations and reverse engineering Abode's side is the painful part.
Sure, I can do that. My only gotcha is that if I can't use type, then I'm losing two fields so I'm going to have to put a map into the event... which I think only takes Strings? Ugh.
But I'll find a way to do it.
type is typically "physical" or "digital", and is used primarily by Switch Devices to discern which 'type' of event it was. I don't recall that field being used for anything else. 
Are you just wanting it to appear in the device's event history for reference purposes? Or do you expect an App to read that value and do something with it? Just curious.
That works today.
It appears that would work, because it shows up the logs of Maker API, no?
My question is whether this violates something about the platform that will cause grief, or if type is effectively going to be "receiver must know how to interpret it"
Yes, it will. Events that are "published" for non declared attributes, like "Front Door" will not show up in any other apps. the only reason that event showed up is becuse @hokfujow queried the maker API for the device's event history. The event was not published by the Maker API's POST function because it was for an attribute that wasn't declared. So, the event was written to the database but not actually published.
The reason that's a problem is because it doesn't follow the standard so @hokfujow came on trying to figure out what was wrong. Then we spent a whole bunch of time debugging the issue only to find out that it was never going to work because of the driver.
I don't think anyone is truing to tell you what to do on your system. But if you release software to the community it has to follow a few basic standards or the user must be made aware that it doesn't follow these conventions. That way they're not making us waste out time trying to help them on something that won't work.
I understood what you are saying Ryan, but you were replying to my query about use of the type field, not the event name.
Would be great to see some documentation about those standards.
Not surprising that someone might fail to intuit them without guidance. Reference docs tend to work much better than condemnation and public shaming of people who fail to grasp a mostly undocumented API 
Download the Hubitat app
