Maker API model and manufacturere fields are blank

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"}]}]

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?

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.

Ok thanks for the clarification.

@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

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

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?

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.

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.

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.

Let's give this some love please :grin:

1 Like

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

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

Are you talking about devices/* ?

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

OK, that will be in this upcoming 2.2.6 release:

1 Like

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:

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

1 Like

No worries. I exclusively use devices/*.

@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

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

Download the Hubitat app