Response json for a Device shows incorrect state values after calling "off" or "on" commands

I have some zigbee lights and also a group that contains those lights.

When I use the Maker API and call "on" or "off" commands on them, the actions execute properly, but the json response i get from that call still shows the original switch state. ie if I'm calling the "off" command, the response json still shows switch state as "on".

I have to call the Get All Devices again after I run these on/off commands to get the actual proper state for "Switch".

There seems to be a delay possibly with what the API is reporting or something.

First off, am I wrong in thinking the json response when calling one of those on/off commands should include the new updated state of that device?

Correct, it does not. Some devices can take a long time to respond (for instance take a dimmer that dims over 2-4s doesn't show OFF until done fading to zero). The system can't wait for the status to update before returning a value.

Yeah, you are actually. It will not be updated because the response is sent before the commands are sent to the device. If you had to wait for the device attributes to update, it could be several seconds before the response is sent to the requesting system. Plus, how would you determine when to send the message to the requesting system? That would take a lot of architecture to figure out if the status matches what was requested. Also, if you were to use this method, you would not get updates in the requesting system for changes that are made in Hubitat that are not made by your requesting system.

You should be using the Maker API's event POST messages to confirm or track device status changes. You will receive an HTTP POST message whenever an event is generated for a device that is included in the Maker API.
image

3 Likes

I assumed that the wait was inherent in me making an asynchronous call to begin with. i.e. I say "turn off" and then wait for it to tell me that it did, indeed turn off. The time it takes to complete that action is already baked into me knowing i'm not expecting devices to behave instantly.

No big deal though. I won't be writing webserver stuff to push data to my mobile app just yet. Seems like work that will slow down me getting a working prototype of my app up.

Thanks for the fast reply though! Much appreciated.

You mean an asyncronous call to the Maker API from your other system? How does the Maker API know that the call is asyncronous? It doesn't matter to the maker API.

But it is not only a timing issue. Think about the complexity of what you are asking. You are not only asking the maker API to keep track, temporarily, of the changes it has requested to the device but then also, compare the events that are generated by the device against those requested changes and only send a response when they match. That's a lot of heavy lifting for that app to do. And it gets exponentially harder (or completely impossible) when you throw in custom commands and attributes. How is the Maker API supposed to determine when the criteria are right to send the status back if you use commands or attributes that are non-standard? Some commands don't necessarily generate an event either. What if you execute a refresh command that results in no changes to the device? In that case, the requesting system would get no response at all.

So, I think you can agree, given the wide complexity of the issue and the endless possibilities of different types of responses the app would have to deal with, the only practical way for the maker API to handle it is to just send all events for the device to the requesting system and let it figure out if the requested change was made correctly or not. After all, only the requesting system knows exactly what changes are expected.

If you want to have an app that handles requests/responses the way you have proposed, you could write your own. Then you can do exactly what you are proposing. But when you use a system that is designed to be universal, you have to deal with the constraints that make it universal.

You can use/track the eventsocket to see the action completed.