Python Script for Ezlo FW HTTP API Curl commands

I assume I can try to send the curl commands from Vera now I have my token.

Where on the Vera would you upload the ezlo_curl_auth’ file into a temp dir or something?

You actually don’t have to put the credentials in a separate file - you can simply specify them as command-line arguments to curl. Here is an example of a complete curl command that will retrieve the hub info.

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

Try the command above substituting your Authentication token and IP Address for your ezlo hub. If that works, then you are on your way. On the Vera, you can simply specify all the curl arguments in a single command and skip the file. If you are using Reactor, see @rigpapa’s suggestion above for using expression variables to hold the authentication token.

Tried adding the token to the curl command rather than using a file and now it says:

curl: (52) Empty reply from server

  • Trying 192.168.0.243…
  • TCP_NODELAY set
  • Connected to 192.168.0.243 (192.168.0.243) port 17000 (#0)
  • schannel: SSL/TLS connection with 192.168.0.243 port 17000 (step 1/3)
  • schannel: disabled server certificate revocation checks
  • schannel: verifyhost setting prevents Schannel from comparing the supplied target name with the subject names in server certificates.
  • schannel: using IP address, SNI is not supported by OS.
  • schannel: sending initial handshake data: sending 147 bytes…
  • schannel: sent initial handshake data: sent 147 bytes
  • schannel: SSL/TLS connection with 192.168.0.243 port 17000 (step 2/3)
  • schannel: failed to receive handshake, need more data
  • schannel: SSL/TLS connection with 192.168.0.243 port 17000 (step 2/3)
  • schannel: encrypted data got 96
  • schannel: encrypted data buffer: offset 96 length 4096
  • schannel: SSL/TLS connection with 192.168.0.243 port 17000 (step 2/3)
  • schannel: encrypted data got 993
  • schannel: encrypted data buffer: offset 993 length 4096
  • schannel: SSL/TLS connection with 192.168.0.243 port 17000 (step 2/3)
  • schannel: encrypted data got 367
  • schannel: encrypted data buffer: offset 367 length 4096
  • schannel: SSL/TLS connection with 192.168.0.243 port 17000 (step 2/3)
  • schannel: encrypted data got 9
  • schannel: encrypted data buffer: offset 9 length 4096
  • schannel: sending next handshake data: sending 158 bytes…
  • schannel: SSL/TLS connection with 192.168.0.243 port 17000 (step 2/3)
  • schannel: encrypted data got 6
  • schannel: encrypted data buffer: offset 6 length 4096
  • schannel: SSL/TLS connection with 192.168.0.243 port 17000 (step 2/3)
  • schannel: encrypted data got 45
  • schannel: encrypted data buffer: offset 45 length 4096
  • schannel: SSL/TLS handshake complete
  • schannel: SSL/TLS connection with 192.168.0.243 port 17000 (step 3/3)
  • schannel: stored credential handle in session cache

GET /v1/method/hub/info/get HTTP/1.1
Host: 192.168.0.243:17000
User-Agent: curl/7.55.1
Accept: /
Authorization: Basic MTA4ZDFmMTAtY…y1kMzNkMjRiYzQ2MmU=

  • schannel: client wants to read 102400 bytes
  • schannel: encdata_buffer resized 103424
  • schannel: encrypted data buffer: offset 0 length 103424
  • schannel: encrypted data got 31
  • schannel: encrypted data buffer: offset 31 length 103424
  • schannel: server closed the connection
  • schannel: schannel_recv cleanup
  • Empty reply from server
  • Connection #0 to host 192.168.0.243 left intact

C:\WINDOWS\system32>

Hi @reneboer

I’ve bought a used Raspberry Pi 2 off eBay to run Node-Red and HA-Bridge.

So I now have a Linux box to test with (Raspberry Pi OS Lite)

For the Ezlo Atom, I believe I now have my ezlo_curl_auth file containing the token setup correctly.

When I run the first test command however I get an “Empty reply from server”

Same when trying to run a scene on the Atom

I now also have an Ezlo Plus as well. However on that one I don’t seem to get any token given back at all.

Curl version on the Pi

Seems Curl is already the latest version

image

Hi @cw-kid,

Are you sure you have the correct IP address for the Ezlo hub in all uses? is it 192.168.0.11 as used for getting the token, or 192.168.0.243 used in the curl commands? It must be one and the same.

Cheers Rene

Rene

192.168.0.11 is my Ezlo Plus that is not getting a token back

192.168.0.243 is my Ezlo Atom that is saying curl: (52) Empty reply from server.

I already have a token from the Atom OK.

Note that the token belongs to a hub, you cannot use it for multiple devices even if they are on the same account. Also the Athom probably does not have the http interface (I have not tested it, but the Plus works)

I guessed that would be the case.

My problem with the Ezlo Plus then is its not returning any token when I run the python script to try and get it.

I just see this:

But when I run the script against the Atom it does work and I do get a token back.

That probably explains why I am getting the (52) Empty reply from server, response back from the Atom.

I just need the token from my Ezlo Plus instead and then I can get it working running scenes via a http command etc from my Vera Plus.

Can you try to include the --debug option in the script? That will show the communication with the Ezlo cloud

Already have please check your messages.

Thanks

@reneboer

I removed the Ezlo Plus from my Vera account and added it back again.

Now the command works and its returning a token OK.

Thanks

1 Like

Is this script still functioning? I’m getting a 404 on the authentication URL in this script when running it.

Not sure we’ll have to test it again @reneboer

I notice a small difference in the auth URL in the script compared what’s used in the API Tool.

In the script the auth URL is like so:

https://vera-us-oem-autha11.mios.com/autha/auth/username/{user}?SHA1Password={pwd}&PK_Oem=1&TokenVersion=2

In the API Tool its like so:

https://vera-us-oem-autha11.mios.com/autha/auth/username/{user}?SHA1Password={pwd}&SHA1PasswordCS={pwd}&PK_Oem=1&TokenVersion=2

The standard script still works OK for me on my Windows 10 laptop. I just ran it and it returns a token string.

Sorry to come in late - where in any of the API documentation are the Ezlo endpoints for tokens described? Is a public endpoint available instead of communicating directly with the controller similar to the vera relays?

When I run the command:

curl -K ezlo_curl_auth https://192.168.1.112:17000/v1/method/hub/info/get

I get the result

curl: (56) Failure when receiving data from the peer

Even if I send a mocked up authentication token. If I switch the IP address the command reports back that it does not connect so I know I’m connecting to the correct IP with my local LAN.

How can I get more information about the (56) failure? No one else on this post seemed to have this error. Perhaps it’s related to the Windows 11 firewall. I disabled the firewall temporary however I get the same error.

I am able to connect to the PlugHub device via the Ezlo API Tool

Please lend guidance.

Did you try using the curl --verbose option?

-v, --verbose
      Makes curl verbose during the operation. Useful for debugging and seeing what's going on "under the hood". A line starting
      with '>' means "header data" sent by curl, '<' means "header data" received by curl that is hidden in normal cases, and a
      line starting with '*' means additional info provided by curl.

      If you only want HTTP headers in the output, --include might be the option you are looking for.

      If you think this option still does not give you enough details, consider using --trace or --trace-ascii instead.

      This option is global and does not need to be specified for each use of -:, --next.

      Use --silent to make curl really quiet.

      Example:
         curl --verbose https://example.com

         See also -i, --include. This option is mutually exclusive to --trace and --trace-ascii.

I’m using Windows 11 - 21H2

The -v gave me a lot of information

The results of the -v are:

C:\TempRecording\Scripts>curl -v -K ezlo_curl_auth https://192.168.1.112:17000/v1/method/hub/info/get

  • Trying 192.168.1.112:17000…
  • Connected to 192.168.1.112 (192.168.1.112) port 17000 (#0)
  • schannel: disabled automatic use of client certificate
  • schannel: using IP address, SNI is not supported by OS.
  • ALPN: offers http/1.1
  • ALPN: server did not agree on a protocol. Uses default.

GET /v1/method/hub/info/get HTTP/1.1
Host: 192.168.1.112:17000
User-Agent: curl/7.83.1
Accept: /
Authorization: Basic MmI4…ZTk=

  • schannel: server closed abruptly (missing close_notify)
  • Closing connection 0
  • schannel: shutting down SSL/TLS connection with 192.168.1.112 port 17000
    curl: (56) Failure when receiving data from the peer

The --trace in the token file did not yield any additional information.

Any ideas on what is causing the “schannel: server closed abruptly (missing close_notify)”