|
|
8 years ago | |
|---|---|---|
| data | 8 years ago | |
| dist | 8 years ago | |
| lib | 8 years ago | |
| src | 8 years ago | |
| .gitignore | 8 years ago | |
| .travis.yml | 8 years ago | |
| PROTOCOL.md | 8 years ago | |
| README.md | 8 years ago | |
| platformio.ini | 8 years ago |
This is a replacement for a Milight/LimitlessLED remote/gateway hosted on an ESP8266. Leverages Henryk Plötz's awesome reverse-engineering work.
Milight bulbs are cheap smart bulbs that are controllable with an undocumented 2.4 GHz protocol. In order to control them, you either need a remote ($13), which allows you to control them directly, or a WiFi gateway ($30), which allows you to control them with a mobile app or a UDP protocol.
This guide on my blog details setting one of these up.
This module is an SPI device. This guide details how to connect it. I used GPIO 16 for CE and GPIO 15 for CSN. These can be configured later.
You'll need to flash the firmware and a SPIFFS image. It's really easy to do this with PlatformIO:
export ESP_BOARD=nodemcuv2
platformio run -e $ESP_BOARD --target upload
platformio run -e $ESP_BOARD --target uploadfs
Of course make sure to substitute nodemcuv2 with the board that you're using.
This project uses WiFiManager to avoid the need to hardcode AP credentials in the firmware.
When the ESP powers on, you should be able to see a network named "ESPXXXXX", with XXXXX being an identifier for your ESP. Connect to this AP and a window should pop up prompting you to enter WiFi credentials.
The HTTP endpoints (shown below) will be fully functional at this point. You should also be able to navigate to http://<ip_of_esp>. The UI should look like this:
GET /. Opens web UI. You'll need to upload it first.GET /settings. Gets current settings as JSON.PUT /settings. Patches settings (e.g., doesn't overwrite keys that aren't present). Accepts a JSON blob in the body.GET /radio_configs. Get a list of supported radio configs (aka device_types).GET /gateway_traffic/:device_type. Starts an HTTP long poll. Returns any Milight traffic it hears. Useful if you need to know what your Milight gateway/remote ID is. Since protocols for RGBW/CCT are different, specify one of rgbw, cct, or rgb_cct as `:device_type. Accepts a JSON blob.PUT /gateways/:device_id/:device_type/:group_id. Controls or sends commands to :group_id from :device_id.PUT /gateways/:device_id/:device_type. A few commands have support for being sent to all groups. You can send those here.POST /firmware. OTA firmware update.POST /web. Update web UI.Route (5) supports these commands:
status. Toggles on/off. Can be "on", "off", "true", or "false".hue. (RGBW only) This is the only way to control color with these bulbs. Should be in the range [0, 359].level. (RGBW only) Controls brightness. Should be in the range [0, 100].temperature. (CCT only) Controls white temperature. Should be in the range [0, 100].saturation. (new RGB+CCT only) Controls saturation.command. Sends a command to the group. Can be one of:
set_white. (RGBW only) Turns off RGB and enters WW/CW mode.pair. Emulates the pairing process. Send this command right as you connect an unpaired bulb and it will pair with the device ID being used.unpair. Emulates the unpairing process. Send as you connect a paired bulb to have it disassociate with the device ID being used.
Route (6) suports the commands all_on and all_off, which do as you'd expect.
Turn on group 2 for device ID 0xCD86, set hue to 100, and brightness to 50%:
$ curl --data-binary '{"status":"on","hue":100,"level":50}' -X PUT http://esp8266/gateways/0xCD86/rgbw/2
true%
Set color to white (disable RGB):
$ curl --data-binary '{"command":"set_white"}' -X PUT http://esp8266/gateways/0xCD86/rgbw/2
true%
You can add an arbitrary number of UDP gateways through the REST API or through the web UI. Each gateway server listens on a port and responds to the standard set of commands supported by the Milight protocol. This should allow you to use one of these with standard Milight integrations (SmartThings, Home Assistant, OpenHAB, etc.).
You can select between versions 5 and 6 of the UDP protocol (documented here). Version 6 has support for the newer RGB+CCT bulbs and also includes response packets, which can theoretically improve reliability. Version 5 has much smaller packets and is probably lower latency.