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

Using curl is in my backlog. This should give you the flexibility to send whatever you want.

Are we speaking about a value for the authorization header?

Yes, that’s correct. And maybe with cookies, although I don’t know if that’s even possible. I was looking at the proxmox api today and that uses cookies.

Ok, I’ll try to implement curl in a future update. With curl you can definitely send cookies and headers.

Thanks, that’s really great!

v 2.1 on GitHub => dbochicchio/vera-VirtualDevices: Virtual HTTP Devices plug-in for Vera and openLuup (github.com)

New features

  • Alarm Partitions
  • Door Locks
  • curl support (thanks @RHCPNG for the idea)
  • power consumption for lights (thanks @HeldeRodrigues for the idea)
1 Like

@therealdb
Hi!
I’ve been seeing your description, but I feel really stupid because I don’t know how to configure the new options!
Will the app update itself to the new version?
How do I add the new options?
Sorry for these questions! :frowning:

That’s fast! Very cool. I will be trying it out soon.

Download the release from GitHub.

Go to your controller via web interface, then Apps, Develop Apps, Luup files. Upload all the files. Leave Restart Luup after upload checked. Wait for luup engine to reload. Go to your device, then Advanced.

Set SetUpdateMetersURL to http://youshellyIP/status

The other variables are already set for a Shelly by default. Just update MeterUpdate (in seconds) if you want to change the update frequency.

Reload luup engine again (ie: go to Apps, Develop Apps, Test luup code and insert luup.reload() and press OK). This should be enough

By default it will meause the first relay, just replace [1] with [2] in both MeterPowerFormat and MeterTotalFormat and you should be ready to change the relay.

It’s experimental, but it should work.

@therealdb
Hi.

Just moving to v2 on vera. I am a little confused about this section in the read me.
" Be sure to use the new D_Virtual*.xml files as device_json.

Go to every device you want to adopt as children, and

  • change device_json to the new D_Virtual.xml* version"

do you man the device json or the device file?

oh, you’re right. It’s confusing. I’ll fix it.

So, device_file (not device_file) should be set to D_VirtualBinaryLight1.xml, if it’s a binary light, and so on.

Thanks for noticing @ElCid!

One more thing that slightly confused me.
Is D_Virtual*.xml only in the child devices or also in the master?

both, otherwise they’ll act in legacy mode.

hi @therealdb
i was looking at status json data (working on an node-red integration with vera.
I noticed This entry
“Device: 178. Fail to load implementation file D_VirtualMotionSensor1.xml”

In this location startup.tasks

There are 4 array items relating to 4 virtualhttp devices set up as motion sensors. it seems there is no D_VirtualMotionSensor1.xml.

Is this a bug as devices appear to work.

Sensors are still on legacy mode. I have to package the device files for all of them and I’m planning this for next release.

Ok i have put them back in legacy mode, as the devices were not updating in OpenLuup via VeraBridge.

I have the On/Off working just fine for a Shelly rgbw2 that I just installed. Is there a way to use the Vera UI’s dimmer slider to set the level on the Shelly as well? I see the SetBrightnessURL in the device’s variables but what goes there?

Yes. Set it to

http://192.168.1.XX/color/0?turn=on&gain=%s

@therealdb Since you asked :wink: I actually have a feature request if it’s possible and you consider it to be useful.

Option to add multiple endpoints for on/off/dimming etc.

Use case: Group physical HTTP devices to act as 1 device.

Example:

  1. You have a fixture with 3 smart bulbs that you have no need to control individually.

  2. You have a lot of cameras that you arm with HTTP calls when house mode change, no need to arm them individually.

Today I do this with Switchboard and Luup code in scenes, but would be neat to have that integrated and sent async in the virtual device instead.

Good suggestion. I’ll add it soon.

I think a good approach is to write a command per line. What do you think?

Thank you! Yes one per line seems like a good idea.