Hi,
I see that the setLabel command exists from: docs. hubitat .com / index.php? title=Device_Object
I would like to be able to call it form the maker api so that i can keep hubitat labels synced when a device is renamed.
making the normal call with
apps/ api/ 48 /devices /6/ setLabel/newName?access_token = token
Does not seem to work.
Can anyone help with how I can programmatically rename a device?
Thanks
The device object you linked to describes the methods provided by the underlying driver architecture of Hubitat to driver writers.
Unless the driver you are controlling has a command that either exposes directly or has functionality that internally uses setLabel(), you won't be able to change the label through the Maker API interface.
Thanks for the reply. I see, so it seems maker is really just a front end api and hubitat config API does not seem to exist.
That really too bad and is a bit limiting for integrations. Maybe this can be requested.
For me, it looks like the simplest solution for this to work in the short term would be use a simple selenium automation script to make the change.
I can see why this doesn't work. Clearly, as currently implemented, Maker API only supports the device commands, not the other device methods from the documents. Maybe it could, will look into it.
Hi bravenel. Thanks so much for looking into into it. I actually got it to work using the selenium driver. Howerver, it would be much more reliable and secure to do it though the maker API since the other solution requires the user to store the full admin credentials outside hubitat
As a driver writer, I often make design decisions about the state of data that I set and which is only editable using the driver methods within the driver (or from a parent driver or app, I suppose).
If that various data were editable directly from some other API like this, it could create opportunities for people to make changes out from underneath the driver implementations that unintentionally break functionality based on those changes.
Device labels and names should hopefully be innocuous, but device data, DNI, and the like would probably not in a lot of cases. Just a thought.
There is no plan yet to make a change to Maker API, but rather, I am looking at possibilities and reasons pro/con to add capabilities to it. There are no device methods available that do something the user could not otherwise do themselves, either directly through the UI or indirectly through a simple app.
Significantly, directly manipulating state of a driver is not one of those things a user can do, except by whatever methods the driver author has created that cause it. As for unintentionally breaking functionality, the driver author bears significant responsibility to not allow this to happen. I am aware of two examples, both of which entail renaming a device, one that is correctly implemented, and one that is not (and must be fixed, accordingly):
A Hub Variable (or Local Variable) Connector must use the name of the variable to cause the variable to be set when the Connector itself has its attribute set. While the Connector device is created with the variable name as its name, should the user change the Connector device name, it would break the Connector's functionality. The fix for this risk is to store the initial name into state when the Connector is first created, and then to use that for all future references to the variable. There is no way for the user to defeat this, either on purpose or inadvertently.
The other case will remain unnamed, but also entails a reliance on the name of the device at the time it is created. Unlike the case of Connector drivers, this driver does not save the name into state, and hence is vulnerable to inadvertent destruction by an unknowing/unthinking user (the existence of which is purely hypothetical).
Yes, your examples are exactly the type of possible issues I was envisioning. I agree there is responsibility by the driver writer to create resilience to unexpected data changes. I also just wanted to throw out that creating new, previously unavailable ways to easily change data that was previously inaccessible is likely to expose some bad assumptions in existing drivers and may create issues/churn.
There is an assumption that users of Maker API are expert users. If new functionality is exposed, (a) they aren't using it now, and (b) if they start using it they better know what they are doing. Anything exposed in Maker API is already exposed to apps.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
Download the Hubitat app
