Direct Local API Command to Fix Track State for Fan Light

I just discovered this forum today and I have learned much in the last 6 hours.

I am needing to issue a direct command request to sync or Fix Track State on a ceiling fan light. I have learned that the following command is close…

curl -H “BOND-Token: xxxxxxxxxxxxxxxx” -i http://192.168.27.94/v2/devices/dddddddd/state -X PATCH -d “{"light": 1}”

but when I issue that command I get the following response:

HTTP/1.1 200 OK
Content-Length: 62
Content-Type: application/json; charset=utf-8
{“power”:1,“speed”:2,“direction”:1,“light”:1,“_”:“68c9472c”}

From earlier work today querying available states for the fan, I was sort of aware of the available state for the light being “light”:1,“_”:“68c9472c”

So I tried modifying the command to the following:

curl -H “BOND-Token: xxxxxxxxxxxxxxxx” -i http://192.168.27.94/v2/devices/dddddddd/state -X PATCH -d “{"light": 1, “_”:“b65e319a”}”

but now I get the following error:

HTTP/1.1 400 Bad Request
Content-Length: 50
Content-Type: application/json; charset=utf-8
{“_error_id”:23,“_error_msg”:“json parse error”}

I have tried a number of minor corrections and they all fail. I could use some guidance if anyone has experience with Fixing the Track State with the Local API command.

Many thanks

Welcome, @ClayMaster !

Whenever you get the HTTP 200 / OK and it returns all the state variables and their values, it should mean you’ve gotten all the syntax, token, device ID, etc correct.
That’s often the hardest part to help people through, as some platforms need the " symbols inside of the data string escaped with a slash, etc - such as this:
curl -H "BOND-Token: aaaaaaaaaaaaaaaa" -i http://192.168.nnn.nnn/v2/devices/bbbbbbbb/state -X PATCH -d "{\"light\": 0"}"
But it seems like you got all that correct for your method, since you got the HTTP 200 / OK.

I even see that in your example, you had issued a PATCH to set the light to 1 (“On”) and the state variables returned in the response from your PATCH command showed the light was then at a value of 1 (“On”).
Note if the state belief was already at a value of 1 (“On”), the PATCH to a value of 1 effectively does nothing.
Were you trying instead to update the state belief of the light to 0 (“Off”)? I would expect it to then return an HTTP 200 / OK response that included {…,“light”:0}.

I know you were just looking at things and comparing, then trying anything that came to mind, but for future reference, the “_” bits are not something you will include in any of your commands.

1 Like

Thank you… your choice of words has helped me understand what is going on.

I have a ceiling fan that defaults to light on in a power outage. This behavior puts the Bond Bridge out of sync with the light. When I issued the command…

curl -H “BOND-Token: xxxxxxxxxxxxxxxx” -i http://192.168.27.94/v2/devices/dddddddd/state -X PATCH -d “{“light”: 1}”

I was actually doing the right thing… changing the state of the light in the app to on which is what happens. When I was evaluating, I was looking at the light, not the app so that is where I went wrong.

I thought it would change the state of the light, but as you said, when the light is already on it won’t change anything. When I just repeated the process I looked at the Bond Bridge again, what it did do was change the “state” of the light to on. So the app and the light are again in sync. That is exactly what I was going for.

Now that the app and the light are in sync, I can issue a TurnOff command and the light will turn off.

Since the light is always powered on after a power outage, I can now control the sync status and programmatically turn the light off. Getting the app and the light in sync is critical as the light will not programmatically turn off unless they are in sync.

So cool. Thank you again your feedback clarified my understanding I was on the right track. Problem solved.

2 Likes