Any official response from Ezlo regarding our concerns about losing the current Vera LUUP Requests functionality and being able to send simple one line HTTP commands from our LAN devices and apps to Vera, to control device and scenes etc without authentication requirements ?
Like how can I send a http command to the Ezlo Atom to run a scene on there to send a VOI command ? I want to do this from my Vera Plus for example.
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.
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.
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)
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:
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):
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.
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?
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:
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.