Creating a universal WiFi LED Bulb Flow?

[Andrew Jawitz]

Hello,

  I've always been interested in converted my household lighting to be controllable by WiFi. The Phillips HUE looks really cool and has a lot of apps thanks to its energetic developer outreach, but at over $200 just to get started there's no way I would consider doing this for my whole house.  If at all.  I've found a much more accomodating solution to be in the UDP-WiFi based bulbs variously marketed as MiLight/LimitlessLED/EasyBulb etc...  These can be purchased for around $20 per bulb plus the WiFi Bridge.

  The problem is that the majority of apps for RGBW Home Lighting are written for the Phillips HUE (which is based on Zigbee if I'm not mistaken, though I don't think it will work with XBee).  LimitlessLED has a very basic API resource at http://www.limitlessled.com/dev/- which should work with any bulbs using the same WiFi Bridge.  It looks like the Ninja Blocks community has become very fond of them since it uses the same 2.4mhz RF frequency.  

   I was wondering how easy it would be to write a new node for LimitlessLED using the HUE node as a reference?  Furthermore, I was wondering if we could set up a WiFi-LED Flow Template that would perform the same functions regardless of which particular Smart Light brand or protocol is being used.  So if there was a flow that connects a Phillips HUE to an Alarm Clock for example, we would be able to swap out the HUE node for a MiLight, LIFX or any one of many new smart lights on the market without having to modify the basic structure of the flow itself.

[Dave C-J]

Should be do-able - there are several node modules already there to help that would be good to wrap into a Node-RED node - https://github.com/CloCkWeRX/node-limitlessLED or https://github.com/gembly/LimitlessGEM

but not having the necessary hardware I can't really comment with any authority as to which would be best to pick.

All these "Chinese" brand version seem to share common protocol and control (from a quick online dig around) - but due to the differences to Hue you would need a different package underneath to drive them... (which probably means a different node - unless we combine both into one with a select option)... - either way it should be possible to mostly align them so the same incoming message could drive either.

(There is a Lifx npm here also... https://www.npmjs.org/package/lifx - and several folk have been playing with them and Node-RED

https://github.com/TinajaLabs/lifx-alert   and  https://plus.google.com/101807348913242636382/posts/fY997JPGLXP - again neither of which I have hands on experience of.)

--
http://nodered.org
---
You received this message because you are subscribed to the Google Groups "Node-RED" group.
To unsubscribe from this group and stop receiving emails from it, send an email to node-red+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
regards

Dave Conway-Jones

[Lawrence Griffiths]

Andrew I've have lifx working in a pure node setting but it's can brake quite often.

I've mailed them and node.js is on the their todo libraries list but no hint of when that might be.

As to your question we are moving in to the realms of Equipment/Device type profiles.

Zigbee has them for HomeAutomation http://www.zigbee.org/Standards/ZigBeeHomeAutomation/Features.aspx

I have to reference the EnOcean wireless one and it's 168 pages long :(

That said I'm happy to help out as having some light weight and generic interfaces in NR for common device types is a must.

Simple lighting methods might be

On/Off

Dim Up/Down

Brightness - 0 100%

Groups or Scenes the bulb belongs too

// IF RGB

R value

G value

B value

For RGB sequencing (eg. step between colour change) and a fade time between chanes

 

Lawrence

[Max Hadley]

I've made a start at an rfx-lights node for controlling lighting using an RFXcom transceiver. By its nature, this has to be pretty generic as every manufacturer has a slightly different set of commands. I've been stupidly busy on other things lately so the project has languished a bit. I'll try and pull it into shape and post to the list when it is in a testable state.

I'm using the message topic as an MQTT style 'address' for the light bulb. The last path component is the lamp number, or a '0' or '+' meaning 'all' or 'group' according to the device's semantics. The message payload is the command. 'On' and 'off' do what you would expect, with 1 and 0 synonymous (strings or numbers). There's also a 'toggle' (on/off) command as some devices work like that. For dimming commands, I accept 'dim', 'brightness' or 'Level' with a number from 0 to 1, or a value from 0% to 100%, or 'dim+' or 'dim-' for devices that work that way. I allow 'mood' commands 1 to 5 for LightwaveRF devices. All the commands are interpreted by matching RE's so it's pretty liberal at what it accepts, and case insensitive.

If anyone had any spare time they could lend me, it would help ;-) Seriously, testing effort will be much appreciated. Watch this space!

Max

[Andrew Jawitz]

I suppose a good place to start would be to create a proper MiLight/LimitlessLED/AppLamp/EasyBulb node that I can use and compare with others who have different lighting systems.  It would also be a good way to teach myself how to create new Nodes.

 There do appear to be npm packages in the form of https://github.com/gembly/LimitlessGEM and https://github.com/CloCkWeRX/node-limitlessLED.  However, I already tried these with the Ninja Blocks platform and they didn't work.  I know the Wifi Controller has been updated to 4.0 and the libraries might not have kept up with the changes (which seems to be the fatal flaw with Ninja Blocks in general).

   However, I did recently notice somebody created a complete php API on Github- https://github.com/yasharrashedi/LimitlessLED, which I'm guessing would be really really useful if I knew php...

  The most promising code to build off of seems to be these two gists on gh-

/**
 Filename: commands.js
 AppLamp.nl led light API: wifi box byte commands
 © AppLamp.nl: you can share,modify and use this code (commercially) as long as you
 keep the referer "AppLamp.nl led light API" in the file header.

 RESPECT AT LEAST 50 MS BETWEEN EACH SEND COMMAND TO PREVENT PACKAGE LOSS
 The functions in this file will return the appropriate hex commands as 3 byte array
 to send to an UDP-socket towards WIFI BOX-IP:8899 (see wifibox.js)
 
 Example Usage in Node JS:
 var cmd = require('commands.js');
 example turn on all white bulbs on:
 cmd.white.allOn();
 set the hue of a color bulb to yellow
 cmd.rgbw.hue(128);
 
 **/



var ColorRgbwCmd = function(){};
var WhiteCmd     = function(){};
var ColorRgbCmd  = function(){};
//makes the rgb/rgbw/white variables globally available in NodeJS
// for ex. use: commands.rgbw.hue(64);

module.exports = { rgb: new ColorRgbCmd()
		  ,rgbw: new ColorRgbwCmd()
		  ,white: new WhiteCmd() };
				   
				   

/*RGBW BULBS AND CONTROLLERS, 4-CHANNEL/ZONE MODELS */


/* Switch ON() your light or make it ACTIVE 
* use function parameter `zone` with value '0' to target ALL zones, 
* value '1' for zone 1, value '2' for zone 2,... to 4 
* You can also use this command to link your bulbs 
* Prepend this command once for the appropriate zone to activate the zone 
* before using hue() / brightness() / whiteMode() / effectModeNext()
*/
ColorRgbwCmd.prototype.on = function(zone)
{  return [[0x42,0x45,0x47,0x49,0x4B][zone],0x00,0x55] }; 

/* use function parameter `zone` with value '0' to target ALL zones, 
* value '1' for zone 1, value '2' for zone 2,... to 4 */
ColorRgbwCmd.prototype.off = function(zone)
{  return [[0x41,0x46,0x48,0x4A,0x4C][zone],0x00,0x55] };

/* Shortcut to ON(0) */
ColorRgbwCmd.prototype.allOn  = function(){  this.on(0) };
ColorRgbwCmd.prototype.allOff = function(){  this.off(0) };

/* Hue range 0-255 [targets last ON() activated bulb(s)] */
ColorRgbwCmd.prototype.hue =  function(decimal)
{  
	var hex = decimal.toString(16);
	hex = (hex.length < 2) ? '0x0'+hex : '0x'+hex;	
	return [0x40,hex,0x55];
}
/* Switch to white mode [targets last ON() activated bulb(s)] */
ColorRgbwCmd.prototype.whiteMode = 	function(){  	return [0xC2,00,0x55] };
/* Brightness range 1-100 [targets last ON() activated bulb(s)]*/
ColorRgbwCmd.prototype.brightness = 	function(percent)
{ 	brightnessIndex = Math.max( 0,(Math.ceil(percent/100*19))-1 ); //19 steps
	return [ 0x4E 
		 ,[ 0x02,0x03,0x04,0x05,0x08,0x09
		   ,0x0A,0x0B,0x0D,0x0E,0x0F,0x10,0x11
		   ,0x12,0x13,0x14,0x15,0x17,0x18,0x19][brightnessIndex] 
		 , 0x55
	       ]; 	
};

/* Effect mode next [targets last ON() activated bulb(s)] */
ColorRgbwCmd.prototype.effectModeNext =	function(){  return [0x4D,0x00,0x55] };
ColorRgbwCmd.prototype.effectSpeedUp = 	function(){  return [0x44,0x00,0x55] };
ColorRgbwCmd.prototype.effectSpeedDown= function(){  return [0x44,0x00,0x55] };



/* DUAL WHITE BULBS & CONTROLLERS */


/* Switch ON() your light or make it ACTIVE 
* use function parameter `zone` with value '0' to target ALL zones, 
* value '1' for zone 1, value '2' for zone 2,... to 4 
* You can also use this command to link your bulbs 
* Prepend this command once for the appropriate zone to activate the zone 
* before using brightUp() / brightDown() / warmer() / cooler() */ 
WhiteCmd.prototype.on = function(zone){  return [[0x45, 0x38,0x3D,0x37,0x32][zone],0x00,0x55]; };

/* Switch OFF zone with value '0' to target ALL zones, 
* , value '1' for zone 1, value '2' for zone 2,... to 4 */	
WhiteCmd.prototype.off = function(zone)
{ return [[0x39, 0x3B,0x33,0x3A,0x36][zone],0x00,0x55]; };

/* Switch zone to Night Light Mode with value '0' to target ALL zones, 
* , value '1' for zone 1, value '2' for zone 2,... to 4 */	
WhiteCmd.prototype.nightMode = function(zone)
{ return [[0xB9, 0x3B,0x33,0x3A,0x36][index],0x00,0x55]; };
WhiteCmd.prototype.allOn = 		function(){ return [0x45,0x00,0x55] };
WhiteCmd.prototype.allOff = 	function(){ return [0x39,0x00,0x55] };
WhiteCmd.prototype.brightUp = 	function(){ return [0x3c,0x00,0x55] };
WhiteCmd.prototype.brightDown = function(){ return [0x34,0x00,0x55] };
WhiteCmd.prototype.warmer = 	function(){ return [0x3E,0x00,0x55] };
WhiteCmd.prototype.cooler = 	function(){ return [0x3F,0x00,0x55] };



/* RGB BULBS & CONTROLLERS, PREVIOUS GNERATION SINGLE CHANNEL/ZONE*/
						
ColorRgbCmd.prototype.off = function(){ return [0x21,0x00,0x55] };
ColorRgbCmd.prototype.on = function(){ return [0x22,0x00,0x55] };
ColorRgbCmd.prototype.hue = function(decimal)
{  
	var hex = decimal.toString(16);
	hex = (hex.length < 2) ? '0x0'+hex : '0x'+hex;	
	return [0x20,hex,0x55]; 	
};
ColorRgbCmd.prototype.brightUp = 	function(){ return [0x23,0x00,0x55] };
ColorRgbCmd.prototype.brightDown = 	function(){ return [0x24,0x00,0x55] };
ColorRgbCmd.prototype.speedUp = 	function(){ return [0x25,0x00,0x55] };
ColorRgbCmd.prototype.speedDown = 	function(){ return [0x26,0x00,0x55] };
ColorRgbCmd.prototype.effectSpeedUp = 	function(){ return [0x27,0x00,0x55] };
ColorRgbCmd.prototype.effectSpeedDown = function(){ return [0x28,0x00,0x55] };

And

/**
 Filename: wifibox.js
 //AppLamp.nl Wifi LED light API: wifi box UDP socket, command sender
 © AppLamp.nl: you can share,modify and use this code (commercially) as long as you
 keep the referer "AppLamp.nl led light API" in the file header.


 Usage in Node JS:
     //load this wifi box class
     var WifiBoxModule = require('wifibox.js');
     var cmd = require('commands.js');
     //create instance with wifi box ip and port
     var box = new WifiBoxModule("192.168.1.255", 8899);
     //send a command ( see commands.js )
     box.command(cmd.rgbw.hue(180));
     box.command(cmd.white.allOn());
     
     
     TIP: You don't need to know the exact IP of your Wifi Box. 
          If you know your DHCP IP range, just replace the last digit to .255 
          That way you wil perform a UDP multicast and the wifi box will receive it. 
          So for example your network range is 192.168.1.1  to 192.18.1.254,
          then use 192.18.1.255 to perform a multicast.
 **/

var http = require('http');
var dgram = require('dgram');

var WifiBox = function (ip, port) {
    this.client = dgram.createSocket('udp4');
    const default_ip = '192.168.1.255';
    const default_port = 8899;
    this.ip = (ip != undefined && ip.length > 6) ? ip : default_ip;
    this.port = (port != undefined && port > 0) ? port : default_port;

};


WifiBox.prototype.command = function (threeByteArray) {
    var buffer = new Buffer(threeByteArray);
    this.client.send(buffer
        , 0
        , buffer.length
        , this.port
        , this.ip
        , function (err, bytes) {
            if (err) {
                console.log("udp error:" + err);
                throw err;
            } else {
                console.log('bytes send: ' + [threeByteArray[0], threeByteArray[1], threeByteArray[2]])
            }
        }
    );
}

WifiBox.prototype.toString = function () {
    return 'WifiBox: { ip:' + this.ip + ':' + this.port + '}';
};


module.exports = WifiBox;

If anybody can give me some pointers on using these files to create a NodeRED node it would be greatly appreciated!  Furthermore, I'd be more than happy to create a repo to use as a nucleus of a universal WiFi-LED template.

[Andrew Jawitz]

RE: MiLight/LimitlessLED/AppLamp etc...  there almost seems to be many too many different resources to work with.  So many that its tough to know where to begin.  I'll try to keep a list of resources in this thread in case anybody has any suggestions for which one to use as the starting point for a Node-Red node.

 

  Even though one can outfit an entire house with these bulbs+wifi gateway for a fraction of the price of a single Phillips Hue hub, its much more difficult to find information about them. Part of the problem is the fact that they are manufactured under a "generic" license which means they are sold under multiple different brand names, which I've listed below for reference.  Adding to the confusion, the wifi hub has shipped in two different versions.  As far as I know, the deprecated version is known as WiFiCON  whereas the current version (as of 11/14) is WiFi370 .

  

  The various brand names include-

• MiLight
  
• LimitlessLED
  
• EasyBulb
  
• LimitlessLED
  
• AppLamp
  
• RemoteLED

   Some of these brands provide a limited API reference for developers, of which the limitlessled API seems to be the most extensive.

 

•   www.limitlessled.com/dev/
  
•   http://www.wifiledlamp.com/service/applamp-api/
  
•   http://remoteled.com/api.html
  

   As has already been mentioned in this thread, there have been multiple drivers written for Node.js and npm

NPM packages- 

•  https://github.com/CloCkWeRX/node-limitlessLED
  
•  https://github.com/gembly/LimitlessGEM 
  
•  https://github.com/secesh/node-rgb
  

 

  Node.js Drivers/scripts-

 

•  https://github.com/b4cedev/node-light-wifi370
  
•  https://gist.github.com/AppLamp-API
  

  The Wifi Hub controls the lights using UDP commands with each color state specified in a hex code.  This makes it somewhat more compiicated to do anything more than turn lights on/off or specify a single color.  Node-RED could come in handy in this regard by automating the specific UDP commands as an output that can be triggered by anything in the Node-RED universe.  I'm curious to see if some of the actions developed for the LiFX and HUE nodes would also function as a good interface for the MiLight UDP commands?

[Claudiu O]

There are also the TCP lightbulbs (Connected by TCP) - I got a few bulbs and the gateway when on sale at Home Depot and the gateway ended up being a few dollars only. They don't have a cloud service or open API but several people made progress figuring it out, like here http://home.stockmopar.com/connected-by-tcp-unofficial-api/ I keep planning to write a node for them but I don't know where to start with the discovery and all the other stuff. Thanks for posting all these resources, I'll start looking at them and maybe I'll figure it out at some point.

[Andrew Jawitz]

   Yes, I forgot about the TCP bulbs, and it also reminds me of an even more intriguing product sold at Home Depot called the "Wink Hub" that can control new smart bulbs by GE.  Incredibly, the "Wink Hub" is Linux-based, costs only $50 and ships with embedded antennas for Zigbee, Z-Wave, WiFi and Bluetooth!  It does have a cloud service and a RESTful API, but users are still limited to using the stock platform unless enough hackers take notice and start porting other OSes onto it.  It does appear that people have managed a root exploit, but the vulnerability was patched in a subsequent release.  There does seem to be a lot of potential for this system however,  as one of the founders of thethingsystem now appears to be working for Wink and there's already a node.js-module within the Wink-API- https://github.com/TheThingSystem/node-winkapi.

   At the end of the day however, the 'Wink Hub" is still just another commercial gadget in an already crowded marketplace of incompatible "smart things".  So I think this ever growing list of "cloud enabled smart appliance hubs" only confirms the original thesis of this thread, that a platform like NodeRED can be used to simplify the connections between devices that might use diverse communication protocols to control them.  In other words, a light bulb is still a light bulb. Whether or not the light (or color) is controlled from a Zigbee, Bluetooth or RF24 gateway needs to be less relevant if the IOT is ever going be more relevant.

[Gareth Coleman]

On Saturday, 29 November 2014 17:24:12 UTC, Andrew Jawitz wrote:

   At the end of the day however, the 'Wink Hub" is still just another commercial gadget in an already crowded marketplace of incompatible "smart things".  So I think this ever growing list of "cloud enabled smart appliance hubs" only confirms the original thesis of this thread, that a platform like NodeRED can be used to simplify the connections between devices that might use diverse communication protocols to control them.  In other words, a light bulb is still a light bulb. Whether or not the light (or color) is controlled from a Zigbee, Bluetooth or RF24 gateway needs to be less relevant if the IOT is ever going be more relevant.

Absolutely, I couldn't agree more, it seems obvious that consumers don't and shouldn't have to care about frequencies, protocols etc. But this means that many companies are getting damp knickers at the thought of locking households into their proprietary system for all the smart devices they can dream of. And that there is a great case therefore for developing more open ways of doing these things.

Just to throw a curve ball into the discussion, I've recently discovered the ESP8266 system on a chip that has a small 32 bit micro controller with wi-fi radio and TCP/IP stack for £3. OK this device isn't perfect - toolchain is kinda funky, and even if the SoC does all the heavy lifting for you it's still slow to startup and power hungry.

But it neatly sidesteps the whole expensive, proprietary mess of wireless protocols - and may well mean you don't have to worry about a basestation as well!!

So I'm gonna hope that in a few short months the cheap wireless RGB led light bulbs coming out of china will be wifi - and I can avoid dealing with any of the systems with a Z in their names. There have been some great proof of concept hacks like this one: http://imgur.com/a/WoQqT that should lend themselves well to integration with node-red.

[Andrew Jawitz]

That"s quite a curve ball!  I've been placing all my bets on the MIPS-based, Atheros AR9331 to be the SoC that conquers all, especially now that the Arduino Yun has made it sufficiently popular to finally get it into regular circulation.  But the ESP8266 looks impossible to ignore! The price to capability ratio simply boggles the mind!

  Thus far, the major issue with the AR9331 is the lack of mainstream kernel support for node.js in MIPS processors.  Though that might have changed by now.  

[Andrew Jawitz]

Something else that strikes me about the ESP8266 is how it seems to come packaged as transceiver modules similar to the nRF24L01 RF transceivers, for which I started another thread RE: integration into NodeRED- https://groups.google.com/forum/#!topic/node-red/TsSfdbDZ9CA.  Incredibly, it appears that the ESP8266 modules are actually CHEAPER than the nRF24L01s!!!

[Gareth Coleman]

Yes, it can be used over a serial line to 'just get/send data' like lots of the other modules, except this time the radio layer is wifi.

But the more interesting uses are getting code to run on the onboard mcu - there is a lua firmware available which seems to have incredible power - really feels like the future in our hands (in my case, allow 21-35 days for delivery!).

--
http://nodered.org
---
You received this message because you are subscribed to a topic in the Google Groups "Node-RED" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/node-red/NSS5ooJ23H8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to node-red+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

------------------------
Gareth Coleman

layer zero labs

l0l.org.uk

[svante karlsson]

I have not managed to spend the necessary time yet on the  ESP8266 's but I believe a really good path would be to get MQTT running on those chips. Subscribe to a key with config, another with output parameters and publish in-data. The the virtualization of a "lightbulb" or whatever device would then be handled in MQTT space where it would be a matter of a json transformation. I also agree on that the price point will make alot of impact on "Z" devices.

--
http://nodered.org
---

You received this message because you are subscribed to the Google Groups "Node-RED" group.

To unsubscribe from this group and stop receiving emails from it, send an email to node-red+u...@googlegroups.com.

[Gareth Coleman]

There is already at least one effort underway, see https://github.com/soynerdito/ESP8266-MQTT

Luckily there are also already open implementations e.g. Nick's out there to serve as templates.

It is going to be exciting seeing what code options are available by the time I get delivery! Seems like quite a lot of interest and active development going on.

Gareth

[Andrew Jawitz]

Speaking of MQTT...  (before we get too far OT) it seems like an MQTT-UDP bridge would be the best way to connect the MiLight bulbs.  Compared to what I'm used to doing with LED strips like Adafruit's Neopixel"s, the MiLight capabilities are far more limited to on/off commands and specifying certain colors at certain times.  I've never seen any way to set up a fade loop for example.  OTOH that can make it a little bit easier to set up a certain number of actions to be triggered by MQTT-UDP whenever a certain context is met.

 For example, Sunrise=Lights off and Sunset= Lights off would be pretty straightforward but another common one is to trigger orange/yellow colors in the minutes preceding a morning alarm to simulate a sunrise effect.  Of course, this gets somewhat more complicated if your using a smartphone-based sleep cycle alarm, as the alarm will go off at different times according to the monitored sleep movements.  Assuming the alarm is Android-based in such a case, the best option would be to use Tasker to trigger an action whenever the sleep cycle alarm goes off.  I suppose it could be possible to set up everything in Tasker by triggering the MiLight controller app, but you would need to figure out how to simulate several complicated commands that replace the colorwheel function in the app.  Having to rely on my smartphones connection to the MiLight WiFi hub creates another set of problems as the connection is far from reliable.

  

 So this is where I can see MQTT and Node-RED serving a purpose. In addition to handling the scheduled tasks like Sunrise=Lights Off etc... it can also augment Tasker as a consistent rules engine through the Tasker/MQTT plugin.  

  First things first though, I need to figure out how to set the msg.payload in the UDP function to relay commands to the MiLight Hub.   For example, when the LimitlessLED/dev/api page states 

 to turn all RGBW COLOR LimitlessLED Smart lights to ON then send the TCP/IP UDP packet of:  0x42 0x00 0x55

  

   How would I set this up in a UDP node?