Ezlo Linux firmware - HTTP documentation preview

@melih

Any turn around on this yet?

End users can’t deal with sockets or complex authentication or expiring auth tokens.

???

9 posts were split to a new topic: Python Script for Ezlo FW HTTP API Curl commands

@reneboer

I’ve split your python script and our talk in to a new thread.

Save messing up their official HTTP Document Preview thread with it.

Thanks

@rigpapa can you help out and tell us how to send this command via http request on reactor?

@cw-kid can you return my post here :slight_smile:

Hello @Ioana,

i’m trying to get http commands working from vera to ezlo, at the moment i’m trying to dim certain dimmer to a level. When i try it via posman sending this GET command https://192.168.0.110:17000/v1/method/hub.item.value.set?_id=5f305e6d124c3510a3c3cc57&value_int=40 with authorization i’m managing to dim the dimmer to 40% but when i try it from test command from vera i can’t:

  1. os.execute('curl -X GET curl --insecure 'https://192.168.0.110:17000/v1/method/hub.item.value.set?_id=5f305e6d124c3510a3c3cc57&value_int=40' --http1.1 --header "Authorization: Basic <base64(xyzUSER:xyzTOKEN)>"')

it says: Failed to test code, please try again

Sorry dude its back now.

My controller running 1.1.988.4 is listening on port 17000, not 16000, so the docs need to be updated or the port needs to change in the firmware.

/opt/firmware/bin/at88util -v
1.1.988.4

curl -H "Authorization: Basic <redacted token>" \
	--insecure \
	--http1.1 \
	--silent \
	https://192.168.0.216:17000/v1/method/hub/info/get

{
  "error": null,
  "id": "5f315d87129de117069de8b6",
  "result": {
    "architecture": "armv7l",
    "build": {
      "branch": "at",
      "builder": "@c6ecd9788c17",
      "commit": "9719549df7a899f7caab705f",
      "time": "2020-08-03T16:12:57+0000"
    },
    "firmware": "1.1.988.4",
    "kernel": "4.19.75",
    "localtime": "2020-08-10T10:45:27-0400",
    "location": {
      "latitude": <redacted>,
      "longitude": <redacted>,
      "state": "customTimezone",
      "timezone": "America/New_York"
    },
    "model": "h2.1",
    "serial": "90000330",
    "uptime": "2d 20h 35m 18s"
  }
}

I would put the auth string and ID into an expression variable. The auth string will need to be pre-encoded to base64, as Reactor’s expression language does not currently have a base64 encoding/decoding functions (I can add them easily). The target value could also be in an expression variable, or a constant, whatever your need calls for. The request would then look like this (I’ve left the variable as a constant):

Here’s the variable setup, using your ID string from your post and username ‘user’ password ‘pass’ (for the AUTH string):

You can encode the base64 username and password/token using the base64 command on the Vera or most Linux distros. Syntax varies a little, but it’s usually some form of echo -n "user:pass" | base64

Theoretically, it should be possible for you to write Reactor logic to periodically request a new auth token and just stick it into the ID variable, all within the same ReactorSensor.

I’ll add base64 encode and decode functions into upcoming 3.8.

2 Likes

Using variables for the authentication id and token looks handy and wise. I’m pushing house mode changes from my production vera to my ezlo hubs using Reactor and this will reduce the maintenance when the token expires.

That said, I looked at the docs, to see if Reactor’s house mode is available as a variable that I can use to push the mode value to the ezlo hubs but didn’t see it. My experience in the past, is that the Vera house mode variable can lag the Vera’s actual mode due to race-condition issues in the House Mode plugin. Is there a way that I can retrieve an accurate current house mode from Reactor for use in an activity variable to push the house mode to the ezlo slaves?

The House Modes plugin using polling, so it’s guaranteed to be wrong for some period of time from 0 to the polling interval. Reactor doesn’t do this.

Reactor’s HouseMode variable is kept on the Reactor master device. It’s the same variable that drives the House Mode condition, so you can reliably use it. So the Request URL field in the HTTP Request action might look like this:

https://192.168.0.110:17000/v1/method/hub.item.value.set?_id={ID}&value_int={getstate("Reactor", "urn:toggledbits-com:serviceId:Reactor", "HouseMode")}

Notice here I’ve just put the expression in line, rather than going through a variable. Did you know you can do that?

1 Like

Thanks @rigpapa.

FYI, here is the house switch mode method that I am using.

https://192.168.0.216:17000/v1/method/hub/modes/switch?modeId={getstate("Reactor", "urn:toggledbits-com:serviceId:Reactor", "HouseMode")}

Works like a champ.

1 Like

Note that it is not your normal logon user id and password that is used for the token here. You first must request those values from the portal as you can see in my script. Once you have those you could use those as input. Note that those values are also stored in the EzloBridge in-case you are using that.

Yes i found them in ezlo bridge and i’m using those

Thanks @rigpapa coupled with switchboard - virtual dimmer it works perfectly, i was doing the authentication wrong :slight_smile: but now i fixed it.

Hi guys
Can you do some things for us automatically, for a newbie like me and for our future uses please?

Guys, an update about simple one line http commands.

We are planning to add possibility to enable/disable of authentification in our HTTP API.
In this case it will be possible to disable auth and remove all security by your own choice and have the same simple one line commands how it works now on Vera hubs.
If you need more security, it will be possible to enable it through api request.

4 Likes

Hallelujah :grin:

Hi @Oleh
Good news in an ocean of questions for http request
Very happy to read that
Many thanks

It is in progress now.
You will have a choice between security and simplicity.