Maker API is an app (really something anyone could have written), not part of Hubitat's development environment per se, so those docs won't help you. The app itself gives you several examples in app (as you seem to have found above), otherwise the documentation for this app should also:
You can find the commands any particular device supports under "Commands" on the device detail page. Optional and required parameters, if any, will also be displayed. There is some standardization here in that device capabilities require specific commands (and attributes). So pretty much any switch is going to implement the "Switch" capability, then you know it supports the on() and off() commands. Maker API can help you see some of this too. For locks, the plain "Lock" capability requires lock() and unlock(). Maker API can show you both capabilities and commands for a particular device depending on what you're after.
I don't believe these are exposed via Maker API. You can get them in app (and I think driver...) code via the location object: Location Object | Hubitat Documentation (though it's not common to need this information).
It may be helpful to take a step back and share what you are actually trying to do. Do you need Maker API, or are you trying to write a custom app or driver on the hub itself?
I may misunderstand the Maker API then, I thought I needed it to get an access_token as well as authorize what devices my app can control? (Allow Endpoint to Control These Devices)
I'm building a custom app (actually migrating my app from a different hub to Hubitat's). It's a C# app with a responsive web UI that I've used for years.
Here's a screenshot of the device dashboard for example.
You do; I don't think I said anything above that contracts this, so let me know if there's a specific point of confusion. Maker API (like any Hubitat app) can only control the devices you've authorized for it.
Maker API generates the access token for you, though you do need to retrieve it for your use somehow.
Seems like a good use of Maker API, then! I should clarify that by "app" above, I meant in the context of Hubitat, where apps are sort of little applets that (typically...Maker API is a bit different) perform automations -- in case that caused any confusion.
Thanks. Re: Maker API, is there a better approach then? Do I still need an access token and need to authorize end points? Or, is there a better approach when creating a custom app like mine?
Maker API seems like a good choice; the alternative is writing your own app on the hub as well to handle this communication (but Maker API was created so you don't have to).
You need to authorize devices in Maker API on the hub. This control what gets exposed and is controllable via the app.
You don't need to generate an access token (in case you read about that in the developer docs; Maker API takes care of that for you). However, you do need to use the access token in the HTTP requests, per the Maker API examples and docs. How you get this to your C# app is up to you. Copy and paste is a typical way.
Take a look at @thebearmay 's hub information driver HERE.
He uses many of the api calls available from hubitat to obtain various hub details.
VERY useful.
One of the device fields returned is type. For example, a plug in outlet returns:
"type": "Aeotec Smart Switch 7 US",
Is this field the only way to determine a device's type? There might be dozens of different switches, lights etc., each with a unique name (vs. a general category such as "switch").
Let's say I want to query the hub and group all the lights together. Going through every light "type" seems incredibly inefficient if these devices don't have a "parent" / "class" type.
Seems like you are really looking for the capabilities instead? "Type" in this context means the specific driver that the device is using. This is necessary to know in some cases (e.g., if you have an app targeted towards a specific brand and model of device with a dedicated driver) but is generally not what you are looking for.
Thanks. It sounds like that's what I'll have to use.
Capabilities though are different than a type. For example, a plug-in switch, an outlet, and outdoor module all have a "switch" capability, but are all different types. If I wanted to group them by type, it does not appear there is any easy way to do that , especially as there are so many "types".
There iscapability "Outlet" that is functionally identical to capability "Switch" (which is far more common) that some drivers may implement, or some may do both -- but, yes, this is tricky. Normally that difference doesn't mater to an app, just the fact that it reports a switch attribute and has on() and off() commands. If you want to get more nuanced, you'll either need to make your own inferences based on other data (device name, driver, etc.) or something else, like offering the user to select different categories of devices on their own based on what they know.
One last question as you're so helpful... is there a method to determine if the hub has lost contact with a device? (Perhaps the battery died, or there was a network issue, etc.) Other hubs I've used have an attribute (unreachable for example).
At any standardized level, no -- in no small part due to the fact that for many kinds of devices, this is impossible to know (e.g., battery powered Z-Wave devices are normally sleeping and not listening for commands from the hub). Some LAN devices offer a networkStatus attribute (as many such devices have a better way to know; not all), and there is an informal effort among some community drivers to offer a healthStatus attribute for their drivers if it makes sense (and perhaps sometimes even when it doesn't ).
The only one I'm familiar with is SmartThings, which people made fun of for being inaccurate and causing problems. I know the platform has changed since then, but I'm not sure about this particular part. I've also seen it in Zigbee2MQTT, again, often not quite accurate since not all devices are awake all the time. For many devices, there just isn't a good way to know.
I don't believe this is available in Maker API. Maker API is not a complete implementation of the development environment over HTTP; it's just an app (on the hub) that someone wrote using this development environment to allow things like device control over HTTP using a simple API -- without you needing to write anything on the hub to do so yourself. If you need more/different information or finer control, you might want to consider writing your own app on the hub to handle this communication instead of using Maker API. That being said, it's built-in, easy and should work if it does what you need.
I've also seen it in Zigbee2MQTT, again, often not quite accurate since not all devices are awake all the time. For many devices, there just isn't a good way to know.
