Ezlo Linux firmware - HTTP documentation preview

Yes I just spotted that mistake.

I have changed it now:

Still the same however:

Think I am getting a bit closer:

Previously to get the devices ID number in the API Tool I was using the hub.devices.list query.

However if I use the hub.items.list query instead I see this for my appliance plug:

image

If I use the _id number instead of the deviceId number in Postman I am now getting a different error message seemingly one step closer.

I have it working now !

I can turn my appliance plug on and off via Postman…

However @Oleh its very confusing as to which device ID we are meant to be using?

On this screen shot from the API Tool.

On the left hand side is the output from a hub.items.list query.

No human readable devices names are displayed, however from previously using a hub.devices.list query I know the ID of my plug was “5f4e5871120bab1069c13c49”

So in the hub.items.list query list I found that item.

I then tried to use the _id “5f4e5871120bab1069c13c4d” in my Postman query but this did not work.

Then on the right hand side under the broadcast messages I noticed a slightly different _id number with a c on the end instead of a d “5f4e5871120bab1069c13c4c”

I then tried to use this _id in Postman with value_bool=true and value_bool=false and its now working and I can turn the plug on and off OK.

So it needs to be clearer to us users as to which ID number we are meant to be using in our local HTTP commands to control devices.

Yep, the first id had the attribute “hasSetter=false” and “valueType=power”. As you figured out you need to address the switch part of the plug (item). I’m guessing value_int=1 works as well to turn it on?

Yes 1 and 0 turn it on and off

1 Like

So the commands I have working OK in Postman strangely don’t seem to be working in Curl:

No Auth - Turn on plug using “/”

or

No Auth - Turn on plug using “.”

Here is the “Switch” item part of the plug with the correct _id to use:

image

The plug has several different items:

basic - I can also use this _id in Postman to turn the plug on and off:

image

electric_meter_watt

image

electric_meter_kwh

image

Try value=1 in curl

Its the same problem in Curl when using value_int=1

And with “/” instead of “.”

Its strange the HTTP command works fine in Postman and in Chrome browser and turns the plug on.

I’m no curl expert but seems like the value sends as null, try with “https…value_bool=true” or _int=1 just as long as you quote the url

1 Like

That works with quotes around the https URL !

Nice one @Crille thank you very much for all your help and you other guys.

I am writing an idiots guide on how to use the HTTP API for the rest of the idiots like me. :grin:

2 Likes

Anyone have a working command example how to set a devices variable ?

For example how to set a motion sensors “Tripped” variable to either 1 or 0 ?

I’ve written a dummy guide for all this here.

@oleh

Why no “hasSetter” for a Security Device ?

I am looking at my Everspring door contact sensor and trying to see if I can trip it manually by sending a HTTPS command to it.

Looking in the Api Tool in the broadcast section, if I open the door contact sensor I can see the following:

id: "ui_broadcast"
msg_subclass: "hub.item.updated"
result:
_id: "5f4e588c120bab1069c13c51"
deviceArmed: false
deviceCategory: "security_sensor"
deviceId: "5f4e588c120bab1069c13c4f"
deviceName: "Everspring HSM02"
deviceSubcategory: "door"
name: "security_threat"
notifications: null
roomName: "Lounge"
serviceNotification: false
syncNotification: false
userNotification: false
value: true
valueFormatted: "true"
valueType: "bool"

I can see the item objects _id number which is “5f4e588c120bab1069c13c51” and I can see its value is now “true”.

However if I use the “hub.items.list” query and find this device item object:

_id: "5f4e588c120bab1069c13c51"
deviceId: "5f4e588c120bab1069c13c4f"
hasGetter: true
hasSetter: false
name: "security_threat"
show: true
value: true
valueFormatted: "true"
valueType: "bool"

The “hasSetter” says false.

I have tried sending this command to trip the door contact sensor manually but it does not work.

https://192.168.0.11:17000/v1/method/hub.item.value.set?_id=5f4e588c120bab1069c13c51&value_bool=true

Looking at the other item objects for this door contact sensor there is only one of them that the “hasSetter” is true, the “basic” one.

_id: "5f4e588c120bab1069c13c52"
deviceId: "5f4e588c120bab1069c13c4f"
hasGetter: true
hasSetter: true
name: "basic"
show: true
value: false
valueFormatted: "false"
valueType: "bool"

So I tried changing the command for this item objects _id number instead but it still doesn’t work and doesn’t trip the sensor.

https://192.168.0.11:17000/v1/method/hub.item.value.set?_id=5f4e588c120bab1069c13c52&value_bool=true

I don’t get any errors in Postman for these commands the response is 200 OK.

So do this mean we cannot trip / untrip security devices via the HTTP API ???

I am thinking of virtual motion sensor devices in particular !

Armed / Disarm a device.

Example Armed Command: (WORKING)

https://192.168.0.11:17000/v1/method/hub.device.armed.set?_id=5f4e588c120bab1069c13c4f&value_bool=true

Example Disarmed Command: (NOT WORKING - BUG OR SECURITY RESTRICTION ?)

https://192.168.0.11:17000/v1/method/hub.device.armed.set?_id=5f4e588c120bab1069c13c4f&value_bool=false

Response:

HTTP/1.1 200 OK
content-type: application/json
connection: close

{
    "error": null,
    "id": "5f577777120bab5bdafc8fa2",
    "result": {}
}

The arm command works and arms my Everspring Door Contact Sensor. The disarm command doesn’t work not sure why?

Hi cw,

A security sensor is a physical device and if a door is open or closed is determined by the sensor, so to me it makes sense there is no Setter, but only a Getter to read the current status.

On your http tests, are you sure to replace all dots with forward slash?
So

https://192.168.0.11:17000/v1/method/hub/device/armed/set?_id=5f4e588c120bab1069c13c4f&value_bool=false

I know that on the websocket interface both arm and disarm work.

Cheers Rene

Yes I agree with that statement.

Shame I cannot create virtual motion sensor devices or virtual switch devices yet on the Ezlo platform for further testing the Ezlo Server HTTP API.

Running this command with the “/” instead of the “.” dots, works and Armed the Everspring Door sensor.

https://192.168.0.11:17000/v1/method/hub/device/armed/set?_id=5f4e588c120bab1069c13c4f&value_bool=true

However running this command to disarm the door sensor do not work and the sensor remains armed.

https://192.168.0.11:17000/v1/method/hub/device/armed/set?_id=5f4e588c120bab1069c13c4f&value_bool=false

The response in Postman is 200 OK. So I think this is a BUG !

I’ve also tried value_int=0 and that doesn’t work either.

Thanks

Hi cw,

There are still some issues with the http API it seems. Looks like you found one.

You can create ‘virtual’ sensors, but at this moment you will have to write a plugin. Soon I’ll push a new version of the Ezlo SolarMeter plugin that shows much of the techniques for Ezlo plugins. GitHub - reneboer/ezlo-SolarMeter: An Solar Meter plugin for the Ezlo Linux hub

Cheers Rene

I’ll have a look but that’s probably over my head writing a plugin.

In my Vera Plus I mainly use Virtual motion sensors and switches.

Never used a plugin in Vera to create these virtual devices however, I just created them myself via Apps - Develop Apps - Create Device and use PLEG logic behind them.

Do we have a working example of a Luup variable get command?

It’s not clear in the API document. It suggests you have to use first hub.devices.list to get the devices ID. Then use hub.items.list to find the correct item object of that device, then somehow you query that items value.

Not sure how you are meant to do all that in a single line http command request.

In the API document the example they give is for querying “metering items” but it’s not clear to me.

Anyway I am going to test setting House Modes next.

@cw-kid
Security_threat is internal item controlled by the logic of plugin.
Its not available for control from Lua API.

Its a known issue, we already have a ticket for this issue and working on it.
The easiest way to continue to work with disarm by HTTP - just restart the hub.

1 Like