Hello, I found some weird behavior with the maker api. Where do I submit bug tickets.
Users don't submit bug tickets. You can post your observations here on the forum and if Hubitat staff agrees that it is an issue and can isolate the cause and devise a fix, they will. But just because you think it's a but doesn't make it one.
What does that mean? Groups will have multiple attributes because they contain multiple devices. How would you suggest that information be returned?
No, because that command could take several seconds or even longer to execute. The requesting application might not wait that long before a timeout. Plus, the MakerAPI is handling the communication with the requesting application. The device driver is executing the command. How would you suggest that the system report success? How would it evaluate success? It is up to the requesting application to verify that the attributes have changed according to expectations, if the requesting application feels it necessary to do so. That is the only to evaluate the success of the command.
Do you mean multiple parameters? Commands requiring multiple parameters cannot be done with the maker API. The only way around this is to use a custom driver to parse out the two parameters from the one parameter that is passed to Hubitat through the Maker API. Short of that, you would have to use another app to receive commands into Hubitat.
I would suggest that you do a little more reading up on the forum here since you are so new to Hubitat. Also, there is docs.hubitat.com where you can find more information as well.
Users don't submit bug tickets. You can post your observations here on the forum and if Hubitat staff agrees that it is an issue and can isolate the cause and devise a fix, they will. But just because you think it's a but doesn't make it one.
Understood. I think I am used to working with software where the code and tickets are in the open where I can search to see if other users are having similar issues.
What does that mean? Groups will have multiple attributes because they contain multiple devices. How would you suggest that information be returned?
'attributes': [{'currentValue': None, 'dataType': 'STRING', 'name': 'RGB'},
{'currentValue': None, 'dataType': 'STRING', 'name': 'color'},
{'currentValue': 'RGB',
'dataType': 'ENUM',
'name': 'colorMode',
'values': ['CT', 'RGB']},
{'currentValue': None,
'dataType': 'STRING',
'name': 'colorName'},
{'currentValue': None,
'dataType': 'STRING',
'name': 'colorName'},
{'currentValue': 2732,
'dataType': 'NUMBER',
'name': 'colorTemperature'},
{'currentValue': 13, 'dataType': 'NUMBER', 'name': 'hue'},
{'currentValue': 10, 'dataType': 'NUMBER', 'name': 'level'},
{'currentValue': 55,
'dataType': 'NUMBER',
'name': 'saturation'},
{'currentValue': 'off',
'dataType': 'ENUM',
'name': 'switch',
'values': ['on', 'off']},
{'currentValue': 'off',
'dataType': 'ENUM',
'name': 'switch',
'values': ['on', 'off']}],
Sorry, I should have been more specific. For devices with name "hueBridgeGroup" the attributes section of the response can have various attributes with the same name. If those attributes are tied to devices in the group then maybe add the deviceId to the object? This doesn't appear to be the case because I have hue bridge groups with more than 2 devices but attributes like "switch" only appear twice.
No, because that command could take several seconds or even longer to execute. The requesting application might not wait that long before a timeout.
Do you have an example of an application where this is a problem?. Request timeouts are configurable for almost every http client I have used. The command endpoint returns everything about that device. Is that not the state of the device after the command is applied? If it is, isn't that more expensive than just returning what changed?. If it isn't, then the response is very misleading and instead should just return the http status code with a message like command received.
Another possible approach would be to return a ticket. The client could poll for status on the command using the ticket. I would much prefer the command endpoint to return the results of the command though.
Plus, the MakerAPI is handling the communication with the requesting application. The device driver is executing the command. How would you suggest that the system report success? How would it evaluate success? It is up to the requesting application to verify that the attributes have changed according to expectations, if the requesting application feels it necessary to do so. That is the only to evaluate the success of the command.
Is the MakerApi source available? Without seeing implementation details my guess would be return the results of what happens when the command is sent to device driver. success would be if no error occurred when sending the command.
Do you mean multiple parameters? Commands requiring multiple parameters cannot be done with the maker API. The only way around this is to use a custom driver to parse out the two parameters from the one parameter that is passed to Hubitat through the Maker API. Short of that, you would have to use another app to receive commands into Hubitat.
How do I request this be changed?
/devices/1/setLevel/50
/devices/1/command/?parameter1=50¶meter2=10
I would suggest that you do a little more reading up on the forum here since you are so new to Hubitat. Also, there is docs.hubitat.com where you can find more information as well.
I will definitely do that but that doesn't address my concerns with the MakerApi. Are you suggesting I will find better ways to solve my problems if I read a bit more?
You can...by searching the forum.
No. it's the current state before the command.
No. Native apps and drivers are not public. You would know that if you took any time at all to learn about the system before jumping in wanting to change everything.
I'm suggesting that you might find out that they aren't really problems if you learned how the system worked a little more first. The maker API is not a full system API. There is no Hubitat API. The Maker API is a limited interaction directly with the hub through HTTP GET messages. That's it. If you want something more, you'll have to write the app yourself. Hubiat staff has expressed zero interest in expanding it. I suggest you look at some of the Eventsocket or Logsocket implementations if you are looking for a way to confirm your commands.
This has been requested multiple times.
If you would like to do it again, you can email support@hubitat.com
Thank you for taking the time for responding to my post. It has become clear that hubitat will not fit my needs.
If anyone is wondering what i moved to:
Took about a day to move everything over and I have had a much better experience.
Very glad you found something that fits your needs better. Good luck!
Download the Hubitat app
