Maker API not showing devices with User driver

The Maker API does not show devices that are using User driver code that I got from github. com - /hubitat/HubitatPublic.

For example, a device using this driver will not show up in Maker API app configuration's "Select Devices" list:

github. com - /hubitat/HubitatPublic/blob/9328c5908a7bdc07cb630b4d66087f3ccabb597e/examples/drivers/basicZWaveTool.groovy

Welcome to Hubitat!!

The Basic Z-wave tool doesn't have any capabilities that would be recognized by the Maker API because that's not what it is designed to do. The basic z-wave tool is used for configuring devices that are connected to hubitat and it is only intended to be assigned to a device for a short period of time. You set the device to use this driver, get the configuration report, then change any parameters you want, then swap the driver back to the one that the device should use normally.
The basic z-wave tool can't actually get reports from sensors or perform actions on actualtors.
That's what the regular drivers are for. The information that the Basic z-wave tool outputs is only accessible in the logs within HE. So, even if you did get it to work through the maker API, it wouldn't be useful at all to you because you would still have to have HE open to view the logs that you have to set. What are your trying to do with the basic Z-wave tool through the maker API?

1 Like

Thanks for the info! That does make sense. (I was just trying to learn how User device drivers are written and installed, so I picked Basic Z-wave tool simply because it seemed simple so good for learning. I'll switch to a different one to continue learning.)

Do you happen to know the specific logic Maker API is using to exclude some device drivers from the list? I was just wondering in case I write a device driver, and I want to make sure it shows up in the Maker API list.

Welcome, Pete!

Hubitat has two basic building blocks when it comes to writing code. The first is the Device Driver. Devices are distinguished from one another based on the "Capabilities" that they implement. Take a look through Hubitat's Developer Documentation to see these standard "Capabilities" defined. A device driver can implement one or many of these capabilities. Each capability defines the "Attributes" and "Commands" that must be supported within the driver's groovy code.

The second type of Hubitat basic building block is the "App". Apps implement specific logic that utilize the defined devices within a system. You could write an App, for example, that requests the user pick a Device with the Capability "Contact Sensor". The App would then 'subscribe' to events from that particular device. When an event occurs, the App could perform logic on another device, such as one with the Capability "Switch". If the contact sensor is open, turn on the switch. If closed, turn off the switch.

This is pretty high-level, and not meant to offend anyone. I just think it is very important to start with the basics if you're not familiar with writing Hubitat groovy drivers and apps. Most of us started on SmartThings, which has a very similar programming model.

The "Maker API" App, follows these same concepts and provides a mechanism for you to select devices which will be exposed via the endpoints. As long as your custom drivers comply with the standard model of implementing all of the capabilities you assign in your code, the Maker API App should be fine. It is important to note that groovy is cAsE sEnSiTiVe, so be careful.

2 Likes