We’re excited to announce that starting with the next Ezlo Linux firmware update ( ETA: end of next week) we’re adding support for HTTP for our hub API, besides web sockets.
You can take a look at the documentation:
HTTP_server_API.pdf (63.3 KB)
Please share your feedback for the document below. 
So what does this mean? Besides web sockets.
Are we going to be able to send simple one line http commands to the Ezlo hub to perform some action?
Like turn a device on or off or run a scene or set a variable value of a particular device?
Like we can today with Vera and Luup Requests?
No one from Ezlo has confirmed we will still be able to do this yet.
Well, the short answer is no: you’ll need two headers after you get an Auth key.
More secure, less flexible.
More secure is all well and good.
But more difficult is not.
We want Luup Requests as we have now with Vera.
Turn it off by default if they must. But we need it.
No one from Ezlo has confirmed we will be able to send simple one line http requests to the Ezlo hub. Many different LAN integrations depend on it.
@melih I have mentioned this several times previously.
Can you confirm we will not be losing the Luup Requests functions we have today in Vera?
Thank you.
Hello @cw-kid
example of how to create a request with curl utility:
curl --insecure ‘https://127.0.0.1:17000/v1/method/hub/scene/run?sceneId=NNN’ --http1.1 --header “Authorization: Basic <base64(user:token)>”
several more examples:
set item value:
https://127.0.0.1:17000/v1/method/hub.item.value.set?_id=NNN&value_bool=true + authentification headers
or
https://127.0.0.1:17000/v1/method/hub/item/value/set?_id=NNN&value_bool=true + authentification headers
https://127.0.0.1:17000/v1/method/hub/item/value/set?_id=NNN&value_int=1 + authentification headers
https://127.0.0.1:17000/v1/method/hub/item/value/set?_id=NNN&value_float=1.2345 + authentification headers
https://127.0.0.1:17000/v1/method/hub/item/value/set?_id=NNN&value=string_value + authentification headers
run scene:
https://127.0.0.1:17000/v1/method/hub/scene/run?sceneId=NNN + authentification headers
scenes list:
https://127.0.0.1:17000/v1/method/hub/scenes/trigger/devices/list + authentification headers
where NNN is an identifier.
This is why it needs to be simple for dummies HAHA,
OK can we back up a bit ?
I now have my Atom up and running and I have some devices and scenes added into the Atom.
I have an Everspring appliance plug paired to the Atom. In the Vera mobile app I have no way of looking up the device ID or the scene number of a particular scene, so that is the first problem I have. I need to find out what these ID values are first some how ?
User tokens and authentication headers you might as well be talking in Greek. This is why the current Vera Luup Requests is so easy to use as you don’t need any of that.
The LAN IP address of my Atom is 192.168.0.243 so for dummies can you explain how we send a HTTP command to the Atom to turn on the Everspring appliance plug ?
Thank you.
How do you access the log on the Atom ?
http://192.168.0.243/cgi-bin/cmh/log.sh?Device=LuaUPnP
Doesn’t work like it does for a Vera FW controller.
Looking at the API test tool and “hub.device.list”
I get this response. I have 3 Z-Wave devices paired to the Atom.
Its not clear, should this tell me the devce ID value of each of the 3 devices?
OK I have to expand devices to see them.
So the device ID of the Everspring plug is Z9EC16EFA
So now what ?
https://192.168.0.243:17000/v1/method/hub.item.value.set?_id=Z9EC16EFA&value_bool=true + authentication headers
How do I add the authentication headers to the URL command ?
Id are now alphanumeric, that’s correct. Auth header are documented in the doc attached on the first post.
That doesn’t help me.
I know the answer however its not currently possible to send a simple one line HTTP command to a Ezlo hub and that is the big problem.
What is my user name and token ?
Yep, doc is still too simplified. Anyway, you should be able to get both from api tool.
If I remember correctly, it was documented by @reneboer on his post announcing Ezlo bridge for openluup.
You’ll need a curl command at least. I’ll probably add headers to my plugin for virtual devices to support Vera’s devices to call Ezlo one locally and directly. But right now I’m at the beach place and not near a PC - pririoties 
I just mentioned being able to do that on another thread here.
I will have a look for Rene’s post.
Ezlo really really need to allow us to be able to send simple one line HTTP commands to the Ezlo hub without auth.
If not lots of my LAN integrations are going to be broken. 
I can’t see anything in the Ezlo bridge thread or on his Github readme about how you work out what your username is and how to get a token.
Also what do you do when the token has expired ?
Its all well and good the Ezlo dev’s saying use a curl command, but if the token has then expired then presumably the curl command stops working.
And not all my LAN apps can even send curl commands. They can just post simple one line HTTP commands to Vera.
I don’t know why they can’t use give us the same functionality we have now with Vera Luup Requests.
Maybe I have something on my PC at home. I’ll be back in a week.
All that said, this is good from a security point of view, but could makes things complex. I don’t know their plans, but similar solutions (home assistant, zway server) have the ability to flag a token as never expiring. Unfortunately this firmware is still too new and it’s still missing a proper web gui, so we’re just here speculating.
I wish they just added an ip white list for http commands instead of this, but it’s probably doable as external plugin/program running on the same box.
It would be great, i can start transferring part of my devices to ezlo and not loose automations with devices / plugins not supported by ezlo.
One quick question to ezlo team, what will happen if we send 20 http commands to different devices at same time?
you will be hard pressed to find devices supported by vera but not Ezlo.
Exactly, but not “could” it will make things more complex for local LAN devices and apps to control the Ezlo hub.
Have them turn it off by default out of the box if they must.
But still the requirement is still there for a like for like replacement for the current Vera Luup Requests functionality that does not require authentication.
What is the security concern anyway?
It’s not like we are going to directly open up the local HTTP API port on our router firewalls from the WAN to the LAN via port forwarding.
And personally I have an encrypted always on VPN tunnel protecting the whole LAN.
So unless the Mios cloud is somehow compromised what do I really have to worry about?
Anything is better than us being forced upon with Web sockets and user auth and tokens that will break current Vera functionality and integrations we have now on our LANs.
@melih This is the one topic that is really concerning me about the whole Ezlo platform, that and no signs of a proper logic engine.
Can you step in and make a decision about this local HTTP API and if we will be forced to use user authentication or not?
That doesn’t include all the current third party Vera plugins we will be losing however. Thinking particularly of the 3rd party Logitech Harmony plugin amongst others.
But yes hopefully we are going to have far more natively integrated Z-Wave and Zigbee devices on the Ezlo platform and a whole new world of none Ezlo supported devices integrated via Alexa / Google Home and Ezlo VOI.
I have built an IOS APP loaded on several wall mounted iPads that rely on HTTP API to periodically fetch all the devices status:
“http://(Constant.veraIP):3480/data_request?id=sdata&loadtime=(loadtime)&dataversion=(dataversion)&timeout=60&minimumdelay=2500”
I am not sure we have something similar to get everything in one shot (full update) then partial update only for the devices that changes status.
The App also uses HTTP API to turn on/off/dimm devices and run scenes.
Without this my App (and other integrations) will be broken.
I am actually getting the devices instant status change via the MQTT plugin, push instead of continuous pull, so integrating MQTT natively to get/set devices will make life a lot easier
The response from the Ezlo staff about a local http Api without forced authentication is silent.
No Vera Luup Requests direct replacement is being offered it appears.
So tell me what is my username and token?
And is this token peristant? Or does it expire?
With this information I can work out my curl commands however lots of other LAN integrations will be broken without simple one line http commands with no authentication to control the Ezlo hub on your own internal LAN.
Best Home Automation shopping experience. Shop at Ezlo!
© 2024 Ezlo Innovation, All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules
