{“error”:{“code”:-32602,“data”:“rpc.params.wrong_field”,“message”:“Wrong field of object”,“reason”:“Unexpected Json format for value type ‘rgb’: "{\"red\":255,\"green\":0,\"blue\":0,\"cwhite\":0,\"wwhite\":0}"”},“id”:“60e8c6e7120bab124281ffac”,“result”:{}}
I would expect that; the order of keys doesn’t usually matter in objects (although you never know how the API might be parsing the data). There are a number of items like this in the API docs that need to be further documented. There’s just too much that’s left to “discovery”, and experience has also shown that if it’s not documented, in the absence of specification there will be variances in functionality/interpretation over time as well. That list of items and values should explicitly describe the structure (for both HTTP and WebSocket APIs), acceptable range of values, and the meaning of values in the range. It’s got default values, which is good. Needs the rest.
Another question in this call is the meaning of cwhite and wwhite. By default, I’d assume that they mean the same thing that they did on Vera (wwhite is 2000K-5500K range scaled 0-255, and cwhite is 5500-9000K range scaled 0-255), but (a) nobody who hasn’t developed for Vera would know that, and (b) who knows if that’s even a correct assumption.
But I don’t know what the correct JSON data format should be ?
NOTE - In the first screen shot on the left hand side you can see all those other Requests that SET things. They are all GET single one line HTTP commands.
For Ezlo HTTP API, this is a working POST request but its for retrieving a value from a device, in this case a temperature sensor value. Rene you were the one who showed us how to do this.
Yes. You can send a POST request with a Home Remote plugin. It’s not much different than the GET. Just change “http.get” to “http.post” & be sure to include your Content (data) as the 2nd argument to the function. You can read more about it here:
Another option might be Multi System Reactor. The first version that supports Ezlo hubs has just been released.
If I can control the colours of the RGB bulb paired to the Ezlo Plus hub via MSR, then I will be able to use MSR’s own much simpler HTTP API and create some different colour “scenes” in MSR and just send GET commands from Home Remote dashboard app to MSR to run those “scenes” etc to in turn control the bulb, effectively cutting out Ezlo’s own HTTP API that requires POST for controlling RGB lights.
I believe the MSR integration uses the wss web socket for interacting with the Ezlo hubs.
I have had it confirmed by an Ezlo developer that it does require POST to set colours on an RGB light, which makes it more difficult for end users to use.
The whole point of the HTTP Server API is for end users to be able to use, not just for developers or more technical types.
So it should be made more simple like the current Vera Luup Requests HTTP API.
Every time they make something POST it ups the difficulty. Also I have some other apps I use that don’t support sending POST commands, so it should all be GET like Vera is now in my opinion.
I know it’s not always possibile, but my own Virtual Plug-in is supporting curl commands, so you should be able to map an Elzo command this way. I’m using it for my own endpoints accepting POSTs and it’s rock solid (and it’s using RGB virtual devices as well). Give it a try.
I now thanks to the MSR developer, have a dashboard page like this, that works and changes the colours of my RGB bulb paired to the Ezlo Plus hub.
As I said it’s a shame the official Ezlo HTTP Server API can’t control colours on a light with GET instead of the more complicated POST.
It can be laggy sometimes however changing colours, when clicking on these buttons too quickly. Likely the Ezlo HTTP web socket API being slow to respond ?