Maker API model and manufacturere fields are blank

🧰 Built-In Apps and Drivers Maker API
1

I noticed if I get full details on my Maker API devices, the returned JSON includes both a model and a manufacturer field, but they are both set to null. See example below.

How do I get my driver to fill these out?

Is it just a matter of setting a device.updateDataValue ? Presumably device.updateDataValue("XXXXX", "my model name") and device.updateDataValue("YYYYYY", "my manufacturer name") ?

[{"name":"Generic Z-Wave CentralScene Dimmer","label":"Dining 1 - Wine Room Counters","type":"[Beta 0.1.1] Almost Any Dimmer Z-wave Plus Dimmer Driver","id":"77","date":"2021-02-27T00:06:53+0000","model":null,"manufacturer":null,"capabilities":["VoltageMeasurement","Refresh","PowerMeter","HoldableButton","ReleasableButton","ChangeLevel","Initialize","SwitchLevel","Switch","PushableButton","DoubleTapableButton"],"attributes":{"held":"1","dataType":"ENUM","values":["on","off"],"numberOfButtons":"2","level":"99","pushed":"2","voltage":null,"multiTapButton":"2.1","released":"1","doubleTapped":"1","power":null,"switch":"off"},"commands":[{"command":"hold"},{"command":"stopLevelChange"},{"command":"resetState"},{"command":"refresh"},{"command":"push"},{"command":"setParameter"},{"command":"release"},{"command":"off"},{"command":"startLevelChange"},{"command":"doubleTap"},{"command":"initialize"},{"command":"multiTap"},{"command":"setLevel"},{"command":"on"}]}]
2

I have also just noticed this on all my devices, even knowing all my devices have there own model + manufacturer :frowning:

Even in the docs it's null :slight_smile:
https://docs.hubitat.com/index.php?title=Maker_API

@mike.maxwell, @bcopeland, @bobbyD
Do you guys think we could please get this fixed for the next hotfix?

3

It's null since it's not a required attribute across all device types, its primarily for internal use.
So it can't be hot fixed, and maker probably jumped the gun by including it within its schema.

4

Ok thanks for the clarification.

5

@mike.maxwell, @bcopeland, @bobbyD

By contrary there is something that could get fixed unless it's also a feature :slight_smile:

The output json format is completely different between there two API calls:

/apps/api/XXX/devices/394?access_token=YYY

image
image277×1100 34.1 KB

/apps/api/XXX/devices/all?access_token=YYY

image
image295×521 19.7 KB

If this fixable? or could we at least add the data type of each field on the /all API call?

Or add the device type / driver on the /devices/394? API call?

6

This has come up a lot...

Do devices/* instead of devices/all.

It's my opinion they should either fix, or better yet - remove, devices/all. But I'm sure it is a low priority since devices/* exists.

7

the /all is very practical and less resources intensive if we just needs to get all the devices, this prevents us from making multiple API calls.

8

I don't think that's true.

In all cases I've tested devices/* returns data much faster than devices/all. And devices/all seems to really pound the hub while it is generating it's payload.

I think internally to the hub devices/* is much less resource intensive even though the payload is larger.

I agree that the devices/all payload is smaller though.

As many have seen, devices/all returns malformed json in some cases and omits some values altogether that devices/* does return...

But to your point, those could all be fixed.

9

Let's give this some love please :grin:

1 Like
10

I still ask WHY though? If devices/* already returns well formed data and is less resource intensive, why bother fixing devices/all?

Not trying to be argumentative, I just don't see why that is a good use of engineering resources.

Regardless though, there may be reasons or use cases I don't know about. I think @bravenel is the lucky owner of this area, so up to him of course.

1 Like
11

It's missing the device type / driver, so I am having to make multiple extra calls just to get all the full details.

1 Like
12

Are you talking about devices/* ?

13

Yes the /apps/api/XXX/devices/394?access_token=YYY is missing the type field that should the device driver.

14

OK, that will be in this upcoming 2.2.6 release:

Screen Shot 2021-03-11 at 12.31.00 PM
Screen Shot 2021-03-11 at 12.31.00 PM2594×130 19.1 KB

1 Like
15

Ah, that makes sense.

I've never used that field for anything - I purely work off of attributes and commands so it doesn't matter what "type" it is to me.

Thanks for pointing that out, now I see why you want devices/all to work, or type added to devices/*. :+1:

16

Can't retire devices/all, for what should be obvious reasons. But /devices/* should work pretty well...

1 Like
17

No worries. I exclusively use devices/*.

18

@bravenel, Thanks for including it.
@JasonJoel, I am using the API for exporting data into another monitoring system, so it's always important to have as much context / info about the device as possible.

Thanks for the reactivity!

2 Likes
19

Thanks for satisfying my curiosity. I've been trying to guess why you needed device type/manufacturer when device attributes and capabilities were available ....