Ezlo Linux firmware - HTTP documentation preview

Guys, an annouce of our next release…

As we discussed before, here is the API description for:

  • Enable or disable insecure access (WS and HTTP as opposed to secure WSS and HTTPS).
    You may want to enable it if self-signed certificates used on controller are not supported in your client software.
  • Enable or disable anonymous access (without authentication via hub.offline.login.ui for requests via WS API or HTTP basic authentication for requests via HTTP API)
  • Notify controller about new local access data availability.
  • Login to Controller via direct connection as user
  • Login to Controller via direct connection as controller

It will be possible to enable/disable basic auth and remove all security by own choice and have the same simple one line commands how it works now on Vera hubs.
If you need security, it will be possible to enable it through api request.

It will be available in our next Thursday’s release

LocalModeCommands.pdf (92.3 KB)

3 Likes

@Oleh

I can’t see hub.offline.login.ui in the online API Tool.

So how do we turn off authentication for one line HTTP requests ?

Thanks

Hi

Can you explain how you setup the authorisation in Postman please ?

I’m getting a Error: socket hang up

Thanks

Using a Raspberry Pi to send the command but from my Atom I am just getting this response and its not working:

curl: (52) Empty reply from server

Curl version on the Pi

Seems Curl is already the latest version

image

I guess this doesn’t work on the Atom as yet.

@cw-kid,

You are right, its not implemented yet for Atom, we are working on it.

Oleh

Please can you help answer my question here about turning off authentication for the HTTP API

Thank you.

Hi @cw-kid,

You have to use the API Tool https://apitool.ezlo.com/, select your Ezlo Plus hub, click Connect, then API Calls “Not Listed” and enter the below in the Textbox.

{
"method": "hub.offline.anonymous_access.enabled.set",
"id": "12345",
"params": { "enabled": true }
}

Now check with hub.info.get.

Cheers Rene

Brilliant thanks Rene, I will try it later !

So the ID number can be anything ?

Yes the id is useful for websocket communication with the hub as the reply will include the same id. As websockets are asynchronous the replies may be received out of order. The id will tell the receiver what the reply is for if order is relevant.

Cheers Rene

1 Like

hub.offline.anonymous_access.enabled.set and hub.offline.insecure_access.enabled.set are now set to true.

image

Do you also need to enable this one ? hub.offline.login.ui

Example from the document looks like I need a token which I don’t currently have.

{
"method": "hub.offline.login.ui",
"id": "_ID_",
"params": {
"user":"user.identifier",
"token":"Hs87Kns41106743NMS2"
}
}

FFS its still not working.

CURL Get Hub Info:

CURL Run a scene:

WGET

Chrome Browser:

try to include the --http1.1 option, and maybe --insecure.

Cheers Rene

Thanks but I already tried that.

The curl options should be specified before the url argument. Also, you can use the --verbose option to see what is happening under the hood. I also see that you are trying standard http vs https presumably because you are trying to set the hub to insecure local mode. What happens if you use the following?

curl --http1.1 --insecure --verbose http://192.168.0.11:17000/v1/method/hub/info/get
curl --http1.1 --insecure --verbose https://192.168.0.11:17000/v1/method/hub/info/get

Hi

Thanks for your help !

Yes I am trying to use HTTP rather than HTTPS and the auth token.

HTTP

HTTPS

 curl --http1.1 --insecure --verbose https://192.168.0.11:17000/v1/method/hub/info/get
* Expire in 0 ms for 6 (transfer 0xe09880)
*   Trying 192.168.0.11...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0xe09880)
* Connected to 192.168.0.11 (192.168.0.11) port 17000 (#0)
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: C=RO; ST=Iasi; L=Iasi; O=controller; OU=d026af70-7f32-11ea-ab2d-b7c43c5254eb; CN=90000400; emailAddress=sysadmins@ezlo.com
*  start date: Aug 28 15:48:35 2020 GMT
*  expire date: Feb 22 15:48:35 2021 GMT
*  issuer: C=RO; ST=Iasi; L=Iasi; O=location; OU=8098afb0-a7da-11e9-ab53-05964c0ff1e4; CN=clas.ezlo.com; emailAddress=sysadmins@ezlo.com
*  SSL certificate verify result: EE certificate key too weak (66), continuing anyway.
> GET /v1/method/hub/info/get HTTP/1.1
> Host: 192.168.0.11:17000
> User-Agent: curl/7.64.0
> Accept: */*
>
< HTTP/1.1 200 OK
< content-type: application/json
< connection: close
<
HTTP/1.1 200 OK
content-type: application/json
connection: close

* TLSv1.2 (IN), TLS alert, close notify (256):
* Closing connection 0
{"error":null,"id":"5f50df88120bab679022945e","result":{"architecture":"armv7l","build":{"branch":"at","builder":"@6f94411cdbcf","commit":"e218a385eccb4ef8bcf0c1d1","time":"2020-08-28T13:27:44+0000"},"firmware":"1.3.1028.3","kernel":"4.19.75","localtime":"2020-09-03T13:20:24+0100","location":{"latitude":54.0043029785156,"longitude":54.0043029785156,"state":"customAll","timezone":"Europe/London"},"model":"h2.1","offlineAnonymousAccess":true,"offlineInsecureAccess":true,"serial":"9pi@raspberrypi:~ $

Well, at least you know that it works over https and the json payload confirmed that you have enabled insecure local access.

I think you have to use https but since you enabled anonymous acces you don’t need to use an auth token. You won’t get any feedback in a browser, just a blank page or in some cases “the page can’t be reached” but if you have the MiOS app open you can see that the scene runs instantly when called from a browser with https. Quite impressive that the app is updating live!

1 Like

that’s because they’re using websockets. that’s a bi-directional socket connection between clients and servers. So, servers can push update to the client without polling. Less memory, less CPU and better UX for apps. That’s a right approach, kudos to the team for that.

1 Like

OK I have finally gotten a token from my Ezlo Plus, I had to remove the controller from my Vera account and add it back again.

I can successfully send commands to the Ezlo Plus with authentication to get the hub info and to list devices.

However when I try to send a command to turn on an appliance plug device I see this in Postman:

I have triple checked from the Api Tool that I have the correct device ID

So why isn’t it working and why am I seeing this error ?

HTTP/1.1 500 Internal Server Error
content-type: application/json
connection: close

{
    "error": {
        "code": -32602,
        "data": "rpc.params.wrong_field",
        "message": "Wrong field of object",
        "reason": "Item not found by id: 5f4e5871120bab1069c13c49"
    },
    "id": "5f54bcf1120bab191bf1dbe7",
    "result": {}
}

If I try it using Curl instead I see the same thing:

Thanks

I am also unable to send a command to run a scene.

Again I have checked in the Api Tool that I have the correct scene ID:

image

Yet this error is returned:

content-type: application/json
connection: close

{
    "error": {
        "code": -32601,
        "data": "rpc.method.notfound",
        "message": "Unknown method"
    },
    "id": "5f54c053120bab191bf1dbec",
    "result": {}
}

If I try it using Curl instead I see the same thing:

Best Home Automation shopping experience. Shop at getvera!

© 2020 Vera Control Ltd., All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules