Virtual HTTP Light Devices, supporting RGB(WW), Dimmers, Switch and much more (Tasmota, ESP*, Shelly)

nope, but you can simply call Vera’s HTTP endpoints in order to do it.

see Virtual HTTP Light Devices, supporting RGB(WW), Dimmers, Switch and much more (Tasmota, ESP*, Shelly) - #86 by Stripe - General Plugin Discussion - Ezlo Community

Sorry, I meant the " Alternate App Store" ALTUI : Alternate App Store - Alternate UI - Ezlo Community

I can help if needed, but I’m not going to put it into the store myself… needs to be originated by the author.

I never did it, but I’ll be more than happy to add this, Opensprinkler and VeraAlexa to AltAppStore. Please @akbooer send me the instructions. Thanks.

Thanks therealdb. If you follow the link to the app store thread, the second post has a detailed description on how to publish a plugin.

1 Like

Indeed so…

What is the VeraAlexa @therealdb?

C

1 Like

Its AlexaTTS, catman you have the plugin installed. lol

2 Likes

DOH! It’s too early!

C

3 Likes

New version on GitHub:

  • more polishing for Dimmers/Lights/RGB
  • Heaters are almost completed

I will update it very soon on App Store and try to submit it to the AltAppStore.

Nice work @therealdb. I find your work to be most help full in making things work with vera.

Some feature requests for future versions -
1 a master device to keep track of all http devces.
2 the ability to edit child device urls in master device.
3 the ability to post requests with json body
{ type: 'smarthome', payload: { entity: 'Lamp', action: 'setColor', value: '#FF00FF' }} with %s subsitutions.

1 and 2 require some work, so it’s a maybe.
3 is doable. I will investigate and plan in a future version.

Thanks for your words.

1 Like

Thinking about this, @ElCid, is GET enough, or do you need to make a POST?
I’m thinking about giving the flexibility to decide the method (defaulting to GET) and payload to send as body. do you also need to send headers?

it might become quite complicated, but I’m exploring this option as we speak.

The option to select GET or POST would be best as some api’s only work with POST requests. As to headers, they may be needed, as in authenication

maybe a change in variables
say-
Url = The url of the request
Request - Get or Post
Type - Form data or json
onData - the form or data body for on request with substitutions .
ToggleData - toggle data
offData - off data
Headers - any headers you may want in json name value form

1 Like

I’m thinking about adding a second variable to every command, called something like TurnOnCommandParameters, and when present, just send it via curl as command line parameters. This should be easier and you can send whatever you want. I will still support replace into the parameters as well.

Since every request should potentially be different, every commands should have this option. Default will be no arguments specified, the HTTP call will be sent via GET as today.

2 Likes

You are correct , it would be better to have seperate requests, more versatile.

While I’m still working on a way to call CURL commands directly, there’s a new update available. I will add it to official AppStore in the coming weeks. If you want it fresh, get from github.

I just added support for virtual Window Covers/Roller Shutters/Blinds

In Vera those are mapped to dimmers anyway, so it was easy. There’s only a new Stop command, while Up/Down just set the corresponding brightness.

Updated version sent to AppStore for approval.

@therealdb
How about a http sensor, I know there are 4 types but a generic one to handle all. with power on/off urls

It would make it possible to use a http endpoint that could be called from out side vera to trigger alarms. by using a standard vera call

Do you want a Virtual Device making HTTP calls when tripped, or a device that it’s a virtual sensor?

The latter is easy to achieve, I use it to trigger scenes from external code (ie, my presence sensor is a virtual sensor attached to some logic pinging my phone, arpinging and getting position from IFFT). Just create a new device, specify device_type, device_file, device_json and leave altid blank.

I think it’s doable, I’ll try in the next batch of updates.