Sprinkler device is ESP Home based, running on WEMOS DI R2 arduino type board. The board has a quad relay shield set up as four “switches”. This all works fine from the automation scripts in HA.
So I thought I would look at the REST API and play with CURL commands from my remote console.
Search with “Turn the light on:” to find the example on the help page.
Problem starts when I try a POST, using the curl based example from the REST API “help” page, which is the following:
$ curl -X POST -H "Authorization: Bearer ABCDEFGH" \
-H "Content-Type: application/json" \
-d '{"entity_id": "switch.christmas_lights"}' \
http://localhost:8123/api/services/switch/turn_on
Note I drop the use of “\” when typing in the command onto one line in my console, so I am only using “\” in this post for formatting, if I use it at all.
With “switch.christmas_lights” set to my “switch.zone_1” and ABCDEFGH switched to my permanent token and “localhost” set to the IP of my HA server; I get the following when I use resulting the curl command:
curl: (3) [globbing] unmatched close brace/bracket in column 14
{"message": "Data should be valid JSON."}
So the “switch” in HA is not getting turned on. The relay on the physical device, representing the virtual switch in HA, is certainly not coming on.
The switch and associated relay both still work happily from the HA automations whenever the physical is powered on.
Note the domain of the device in the automations is “switch”, so I am assuming it need be “switch” in the “entity_id” in the curl POST command.
So, is the example POST in the HA help correct?
I have been curling using the same token and IP to GET various data responses based upon the GET examples on the same page. So changing GET to POST and adding the -d clause should not have been a problem.
To save hassles the full call (excluding my actual token) is:
$ curl -X POST -H "Authorization: Bearer ABCDEFGH" \
-H "Content-Type: application/json" \
-d '{"entity_id": "switch.zone_1"}' \
http://192.168.0.100:8123/api/services/switch/turn_on
Moreover, if it helps, the following works fine:
curl -X GET -H "Authorization: Bearer ABCDEFGH" \
-H "Content-Type: application/json" \
http://192.168.0.100:8123/api/states/switch.zone_1
Happily returning:
{"attributes": {"friendly_name": "Zone 1", "icon": ""}, "context": {"id": "ad87fc27c3304a5fab6dcf27a8e5868c", "parent_id": null, "user_id": null}, "entity_id": "switch.zone_1", "last_changed": "2020-04-18T14:05:49.638539+00:00", "last_updated": "2020-04-18T14:05:49.638539+00:00", "state": "unavailable"}
Yep, and for the discerning audience, you’ll note the device “state”: “unavailable”. Before you get exited, if I power the device up that then makes the state change from “state”: “unavailable” to “state”: “off” (the default on powerup of the device).
If I then try the curl POST command again, to turn the switch on, the same error response behaviour ensues, that is:
curl: (3) [globbing] unmatched close brace/bracket in column 14
{"message": "Data should be valid JSON."}
So, no it does not depend on switch available state.
Depressing also, there appears nothing in the developers log relating to any of the API based transactions, including the errors.
Any suggestions please?
Cheers,
B