It works via SMS even if the Internet is cut … You send an SMS to gateway and it run the %body%
scene. You can get confirmation with a SMS send by Vera Edge through se same gateway
If the http requests are not integrated in Ezlo FW this will close the door to any simple communications between the zwave controller and the external world
I find it very, very unfortunate.
I don’t imagine for a moment that Ezlo’s response to Http requests is negative …
For very obvious reasons, for many types of different integrations we have all already implemented with our current Vera hubs on our own LANs and perhaps wider in some cases.
It is clearly obvious that many of us will lose a great deal of functionality with no direct like for like replacement of Vera Luup Requests, which is what they are proposing.
I understand the need for security however at the cost of much more complexity being added and a vast reduction in the current functionality we are going to be losing on the Ezlo platform is it worth it?
Have them turn it off by default out of the box for the sake of security if they must.
However those of us that use Luup Requests on our own LANs and we do not directly open up the http port directly to the WAN / Internet, then I see no reason for them to refuse us this functionality we have today on our Vera hubs.
I need our developers and leaders to give a second opinion here, regarding Vera Luup Requests and how Ezlo are wanting to implement a more secure replacement that will require Curl commands and token authentication.
I understand the need for security however the new local http Api for us end users is going to add more complexity and reduced functionality.
With Vera Luup Requests as is today we can send simple one line http commands to Vera from our LAN devices and apps, to control Vera devices, run scenes and set variables of particular devices and much more.
Do you agree that Ezlo are making a mistake by making the local http Api much more restrictive and less accessible to end users?
Should they turn off the local http Api by default but allow users that require it to be able to enable it and use it without authentication as we can today with our Vera hubs?
Perhaps with a warning not to port forward the local http port on their routers from the Internet to the LAN.
I would really appreciate your sage advise and comments as Ezlo are not willing to comment on the matter.
I’ve already asked @Oleh for confirmation and clarification and a response and Ive asked yourself several times also, starting many months ago when we first spoke about this and much more recently on the “Ezlo Linux firmware - HTTP documentation preview” thread.
a firewall rule to enable anonymous calls inside a specific subnet
the ability to generate a never expiring token and pass it via query string
There are plenty of solutions to avoid an header to be specified. Including, it things are still like this in the future, writing a bridge running on other platform (or a nodejs app or whatever) and making the curl/http calls for you.
Hi @cw-kid, your guess about how the final product will look like is as good as mine. I do not have any info on the future functionality roadmap. I would like a simple way to fire off scenes as toggle switches as well yes. But right now you first need to get a token, and they said it is an expiring one, but no specification for how long it is valid (I am using one for WebSockets for four weeks now). I am looking into the http access they just added to the Linux Ezlo, but you cannot get a token with just curls commands as you need to encode data an decode (base64) the responses and then do a lookup in a json response for the right token. Once you have the token, I think curl commands become possible.
Finally got my Ezlo Plus. Could only add it manually to Vera app iOS. Wired or wireless did not work. For me Zigbee is the big thing with new firmware as Vera firmware has close to none in my opinion. I know it’s not well supported yet as z-wave seems to be priority for now but had to try since the only devices I had unpaired was Zigbee devices. Failed to pair Xiaomi humidity and temp sensor, Xiaomi motion and light sensor with message something like “Inclusion stopped”. Paired an innr light bulb but can’t control it. When trying to include devices again I only get “Failed to put controller in inclusion mode”, same after several reboots. Latest firmware, can’t see version in local connection? was visible in cloud connection, v.1.1.988.2. And now when switching to my Vera Secure the dashboard is completely empty? I know beta is beta but why mess with my current setup on the other controller? That’s kind of disappointing. Looking forward to more Zigbee integrations like Xiaomi, Hue and IKEA.
I just noticed an outdoor light was on before the time it should have turned by schedule. I opened the app and found a new device showing in ‘No room’ with a long alpha-numeric name that looks like a GUID. I tried to delete it but it won’t go away.
Every other device except ‘Google home’ and the Zigbee bulb entry that’s been stuck on my system (won’t delete either) now says “Device broken. Please remove and try to pair the device again.”
A reboot of the Ezlo Plus didn’t fix anything.
I assume it is best at this point to do a full reset of the device to get rid of the Zigbee device and unknown device that are stuck on the interface. Of course the reset would probably be easier if my reset button hadn’t broken off of the controller in shipping.
I’m going to give the reset a shot but if I can’t get that to work I’m probably going to move everything back over to my Vera Plus and call the beta test over.
Edit: I can’t seem to reset the device with the button missing. I tried shorting the contacts where the button was but no luck. I’ve moved all of my devices back to my Vera Plus and unplugged the Ezlo Plus.
BTW, it’s not impossible to write a bridge and once they have a clear story around tokens, it could be done with minimal effort. Think about a light nodejs, or lua, or python service running on a PI or something similar. It could be easier if they’ll add an MQTT bridge, as they promised somewhere else in the forum.
I’ve never used a Raspberry Pi before. Looking for a cheap used one on eBay at the moment however.
To run node red for Vera / Google Home TTS integration and also to run the java HA bridge software for Logitech Harmony “Home Control” integration for Vera devices.
Currently running them on my Windows file server but want to offload them on to a dedicated Raspberry Pi / Linux device.
But still your Bridge suggestion requires a 3rd party developer to do it and a device such as a Raspberry Pi for the end user to have and for the end user to have the knowledge on how he would set it all up.
None of that is required today with Vera Luup Requests as is.
Since the firmware update and having to reinclude devices, The Alexa voice control is not working. I have deleted old ones and then rediscovered. Alexa found the new devices, but when i issue command by voice the response is device name is not responding, same responce fro VOI. All works via Vera app
Thank you for reporting this. We made an initial investigation and we raised a ticket to be further investigated by the cloud team - looks like the issue comes from here. We’ll keep you posted with the result.
True, but mqtt is the best thing they can natively do in order to support a broader ecosystem of connected devices. So, if they natively support mqtt, your chances of being able to integrate with other things is higher. For the the http only things, bridge could be easily written. 3rd part devs have always been the best advantage of this platform, I think many will move to the new one, when things are stable and then tools will be better. We’ll see.
