I’ve completed my project to have some RGBWW lights in the garden. I had to go with MiLight, because it’s the only viable solution to control colors outdoor. I didn’t like Philips Hue Outdoor offers, so MiLight floodlights are perfect for accent coloring in the garden.
Long story short, I wrote all my code in C# and I can control the lights. I know there’s a MiLight Plugin, but it’s not what I want to use (RGB is implemented with the wrong serviceIDs and I don’t want to add load to my Vera, since it’s rock stable at the moment).
So, I thought: why not create a virtual device, so I can control every WiFi and HTTP capable device? I will just read the HTTP URL format from a couple of variables and we’ll be ready to go. It could be very similar to @rigpapa’s SiteSensor, but it will support all the RGB stuff (including the RGB wheel) and call an HTTP endpoint when there’s an action.
This way, support for other kind of devices (IE: Tasmota) could be added in minutes.
IF it can support both RGBW & RGB and all WiFi lights, then yes it would be more than handy.
There appears to be many manufacturer specific devices available but a Generic device that can support all would be great.
I plan to support RGB+CCT (so RGB+addressable white temperature). Vera support for RGB is subpar, so full control will be only possible on the details page, but we’ll get the color wheel and all the stuff on the first page - plus complete support in mobile apps.
It’s a nice dream, but no amount of coding on the plugin side will make this a reality. The limitations of the mobile apps are just that–limitations of the mobile apps. Vera uses what is referred to as a “static JSON” file to define the user interface for a device on the UI7 web interface. This is not parsed and used in the mobile apps (including third party–I don’t know of any that do). Pretty much all apps look at device type (about which I’ve railed incessantly already) rather than supported services to determine the capabilities of the device, with the result being that any device type that isn’t recognized gets no useful UI. That includes every plugin that defines its own device type. Switchboard gets around this by using the Vera-native device types, but you’ll note that on three-way switches, which use a standard/well-known device type but have a custom UI in UI7 web (for the third state), the custom UI is not present in VeraMobile. Reflection of the same problem.
A further problem here is that not all RGB lights have a simple RESTful API, or HTTP interface at all for that matter. Many are custom TCP two-way communication. Supporting a large number of devices in a unified plugin seems like a good idea on the surface, but by the time you address all the exceptions, you not only end up with a fairly complex (to test/verify/maintain) piece of machinery, but it’s also bloated with code most people don’t use or need: it supports 28 different manufacturers, and you use two. The space issue will eventually be alleviated by newer hardware, but the complexity issue I think makes this a bit impractical on the implementation/support side.
Fixing the interface problems in Vera’s UI for RGB/W devices will do a much better job of addressing the problems than creating a new plugin, IMO. Start creating bug reports. Get your issues on engineering’s radar. They cannot duplicate the user experience of tens of thousands of people–they need to hear from us to know what to address.
Edit: And for the plugins that aren’t compliant, talk to the authors and bring them around. Keep in mind that some plugins may pre-date mechanisms/services added in firmware released after the plugin was first written, and it’s hard to tell an installed base that everything is changing and they have to edit all of their scenes/configurations to keep up (the dreaded breaking change that so often occurs in these situations).
I know the situation. My idea is to leverage the official service, and then map the calls to HTTP calls. Of course I don’t want to support TCP/UDP devices, but I want to provide a clean way to have a virtual RGB device. It’s not impossible to write a basic interface and I plan to just provide some luup variables to set the endpoint URLs for common scenarios (ie: Switch On, Switch Off, SetColor, Brightness, etc). That’s what most virtual device are used for.
I already explored a similar situation with a vrtual roller shutter device file and it’s working OK. I posted here my idea about RGB just to brainstorm a little. Tasmota, Shelly and many more have REST APIs, so it’s gaining some traction.
RGB is not bad. RGB+WW/RGB+CCT is missing, and I will report this to them - thanks for suggesting. The only implementation I found for addressable white temperature is in ALTHue by @amg0. His plugin is the only one correctly implementing standard serviceIDs - and so it will render OK on mobile apps - except things on the secondary page.
I tried in the past, but most of them are abandonware - with no clear license attached. So, you have to completely rewrite them to make them working again. In case of MiLight, the published plugin is working with previous generation and if you want to use the new one, you have to fetch some files from the old forums - not an ideal situation. Plus, I don’t really want to have this load on my unit, just to change some colors from time to time - but that’s my own personal motivation.
Anyway, I was just searching for feedback. I will report the need to have an official RGB+W/RGB+CCT support, and continue to write a plugin for myself. We’ll see if I’ll post it, your are right that it’s very specific to my needs and maybe not so common. Thanks for you feedback.
Based on my own experience with these things, if you don’t have two-way communication, where the Vera status is updated from the device(s), you’ll get lots of push-back. That’s going to increase your workload somewhat.
The Yeelight plugin (mine) also works correctly on mobile, for exactly that reason. Of course, you wouldn’t know that unless you had used it (not many Yeelight users out there, I think).
Another thing I did in Yeelight on the suggestion of @HSD99 was implement gel colors and named color profiles (save/recall). The implementation uses the standard services exclusively, so you can control brightness, temperature, and color, and also have access to profiles and gels, on any bulb that supports just the basic standard services (SwitchPower1, Dimming1, Color1). You’re welcome to lift that code if you want it.
Since Milight box has no ack for commands, there’s no need to sync the status. It’s pretty solid and commands are working OK. I’m still not sure if I’ll publish this, since I’m the only one probably needing this.
It’s not a master-child device, and it’s using a custom implementation file only (so, standard RGB1 json/xml). It could be probably optimized, but I have just 3 zones, so that’s OK for me.
The commands (switch, brightness, whitemode and rgbcolor) are mapped to URLs, where the variable parameter is replaced for %s.
I’ve also tried it with a Tasmota (no RGB, but only on/off) and it’s OK (RGB commands are pure REST calls).
It’s limited to HTTP get only, but it seems most of those little things have simple GET-based REST API.
It should be compatible with Shelly RGBW2, with just a minor modification (red, green and blue are separate commands: ie /color/0?red=A&green=B&blue=C)
Edit: saturation (the ability to get both white and color channels at the same time) is not implemented, since I’m not planning to use it.
Edit2: it’s also openluup/altUI compatible (when you have copied all the necessary files from the vera).
