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.
1 Like
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 is capability "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.
Thank you.
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).
Does Hubitat have such a thing?
1 Like
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 
).
This is one of the reasons I wrote this app, since there isn't a good way to know for many devices except whether they've had "activity" recently: [RELEASE] Device Activity Check - Get notifications for "inactive" devices. But that won't help you with this particular question.
3 Likes
Thanks. That's unfortunate. I wonder how the other hub manufacturers implement it then... it's nice to know what a device has stopped responding.
How about getting the lat/long from the hub? Can that be done? (I see the getLocation object in the docs, but is there a RESTful API call?)
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.
1 Like
Thanks. I was hoping I could do what I needed via a REST API (not have to write an on-hub Groovy app). Sounds like that won't be possible.
Are there any plans to release a complete RESTful API?
Not available from MakerAPI by itself, but if you add the Hub Information Device you could use MakerAPI to request from there.
1 Like
Thanks. Can you elaborate? (I'm new to Hubitat). When you say "add the Hub Information Device", what do you mean?
It looks like I need to create my own version of the Maker API app that exposes more internal methods.
Is there any source available for that app, or any pointers I can start with?
Even a basic API "hello world" would be sufficient.
This won't be simple if you are new to Hubitat development, as it requires the use of Oauth and endpoints to serve this data. There are snippets the docs but no fully functional app you can copy and paste to use.
An alternative approach would be using a device that offers this information, then can use that over Maker API like any device, as suggested above. If you are writing this app for others, the trick would be getting them to do this (and choose the device), which could be part of your install instructions.
I have code for a MakerAPI work alike that i was writing for another effort that came to an abrupt end that I can make available to you. Should be 1 for 1 on the Maker functions and I believe has a couple additional.
1 Like
It sounds like I won't be able to interact with the Hubitat hub in any meaningful way via my own app then? That's unfortunate. I was hoping this would be a good solution to do that.
It looks like all the methods are there, but only exposed via local Groovy apps.
A RESTful API would really extend the functionally of this platform. It would allow third parties to write apps in any language.
Is the source code to the Maker API available? I'm comfortable with OAuth, endpoints, etc., and it sounds like it's 90% there, just needs more methods exposed...
Thanks. If you can share, I'd be grateful. If nothing else, it will let me get a feel for what it would take to create a more complete (Maker API) solution.
Hubitat looks like a competent platform, but is missing a key component IMO.
Go to the Drivers Code tab and Select Create a new driver and import from https://raw.githubusercontent.com/thebearmay/hubitat/main/hubInfoV3.groovy. Then go the Device tab, create a new virtual device from the entry labeled Hub Information Driver v3, save go back into the device, modify the preferences and save the preferences.
Thank you. Much appreciated. I have it installed.
Do you have an example of calling the app?
Is it similar to the Maker API call such as:
http://192.168.1.69/apps/api/6/devices/[Device ID]?access_token=xxx
Should be the identical format as the intent was to provided an extended version of the original.
