Having trouble sending dynamic data to a RESTFul Command

Configuration
1

Looking for some help here to help me see where my stupid mistake is.

I have working RESTFul commands with static payloads, but trying to use dynamic variables is proving difficult and I don’t see any easy way to troubleshoot these EG to see what is being sent and what not.

I have this WORKING command:

rest_command:
  powerview_office_primary_open:
    url: http://192.168.0.147:80/home/shades/positions?ids=36
    method: PUT
    headers:
      accept: "application/json, text/html"
      user-agent: "Mozilla/5.0 {{ useragent }}"
    content_type: "application/json; charset=utf-8"
    payload: '{"positions":{"primary":1,"secondary":1}}'

That has the primary and secondary positions hardcoded. That works. Now I am trying to make a more generic “set position” command where the primary and secondary values would be passed to the command. To do this I really just copied the same command then replaced the hard coded values with templates like so:

powerview_office_set_position:
    url: http://192.168.0.147:80/home/shades/positions?ids=36
    method: POST
    headers:
      accept: "application/json, text/html"
      user-agent: "Mozilla/5.0 {{ useragent }}"
    content_type: "application/json; charset=utf-8"
    payload: '{"positions":{"primary":{{ primary }},"secondary":{{ secondary }}}}'

I then tried calling the command from the developer tools like so:

service: rest_command.powerview_office_set_position
data: 
{"primary":0.5,"secondary":1}

This does not elicit any response from my shades so clearly the passed values are not working. I’m probably just plain doing it wrong or maybe more embarrassingly have a typo or mistake somewhere but I am not sure what is going on.

Is there some way to debug these?

2

Answering my own question here for future Googles, but I did get this working and the problem was indeed a stupid mistake. I had the second command set as being POST when it should have been PUT (can be clearly seen in the code above sigh)

But how I figured this out is important and may help others, as I discovered that there were in fact messages in the System->Logs->Full logs that helped me troubleshoot it.