Ezlo Linux firmware - HTTP documentation preview

[reneboer]

Hi,

I managed to work out the WebSocket authentication, so this should be doable as well. The challenge is to obtain the token, that is a two-three step process. Once you have that you can re-use it for the ‘simple’ curl requests.

Will let you know once I have the right series of curl commands.

Cheers Rene

[cw-kid]

Curl commands can be used in some situations and if the token doesn’t expire etc.

However for many other integrations I have setup with some apps on my LAN a curl command would not be possible.

Hense why we need the same thing on the Ezlo platform as we have on Vera today aka Luup Requests, simple one line http commands with no authentication.

[reneboer]

Hi cw-kid,

The token does seem to last quite long, but I have not figured out how long yet. Without authentication i do not see coming, but who knows. Can always create some proxy type function to run on a Pi or so. (i know, even more pieces to fail)

Cheers Rene

[cw-kid]

Well we stopped Logitech closing down their local Harmony API altogether with the backlash.

So never say never.

[cw-kid]

@melih

Any turn around on this yet?

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

???

[cw-kid]

@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

[eonnet]

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

[eonnet]

@cw-kid can you return my post here

[eonnet]

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

[cw-kid]

Sorry dude its back now.

[blacey]

@Ioana

Please share your feedback for the document below

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"
  }
}

[rigpapa]

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.

[blacey]

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?

[rigpapa]

@blacey

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?

[blacey]

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.

[reneboer]

@rigpapa

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

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

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.

[eonnet]

@reneboer

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

[eonnet]

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

[Pitt13]

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