Hue Controller
This Hue controller for one of the lights on campus uses a ceiling fan switch to turn on and off, a force sensing resistor to turn down brightness, a rotary encoder to change the hue and a NeoPixel strip to visualize the current status of the light.
Source code available on GitHub, missing a push. Has production code but also credited examples for testing each component separately.
Issues / Future additions
- Need to find a smoother way to diminish the light strip light.
- Look into API transitions.
- Re-map rotary encoder to move through hues quicker.
- Review code especially with the intention of calling the API the minimum possible.
Project Requirements
Physical interface for turning lights on and off, dimming them, and changing color. Use the Hue system and lamps that are on the floor at ITP.
Component list
- Arduino Nano 33 IoT
- 8 Bits WS2812 RGB LED Stick
- Rotary Encoder
- Arduino Nano Screw Terminal Adapter
- Ceiling Fan Switch
- Protoboard, terminal blocks
Libraries
- NeoPixel library → could also use FastLED Library (animations / efficiency?)
- WiFiNINA
- SPI
- ArduinoHTTPClient
- Encoder Step Counter
References / Code Samples
tigoe.net/hue-control
Rotary Encoders+ITP Phys Comp Controlling sensors for FSR
Light and Interactivity, Philips Hue ControlHue Info email from Tom
Core Concepts Vimeo ArduinoHttpClient_hue_controlNeoPixel References
First step: using ArduinoHTTP Client HueBlink example
Using browser dashboard to query the state of all lights
Philips Hue debug dashboard (CLIP API Debugger)
http://172.22.151.226/debug/clip.html // IP Address for ITP_south_floor, accessible since through network
GET request to /api/$HUE_USER/lights or /api/QL6AHnxaf3-3YER9xoBCp8DRDsfweUcfuuAtmqP5/lightsLight 9 that was on at the time of testing did not respond to my PUT request to turn on, which is intriguing. I would have expected to see better error handling especially from being a Phillips API.
Only light 5 and 6 were responsive to my request.
Connection to Rotary encoder
Successfully controlling hue via Rotary Encoder but need to tweak the ranges. Updated base code in this commit.
[ add video ]
Planning out my circuit
I want to add a visualizer for color and dim level through the 8 Bits WS2812 RGB LED Stick.
It ended up being a circuit with more connections than required because I wanted to be able to use this protoboard in the future for other boards or because wire for ceiling fan switch wouldn’t fit in the Nano terminal adapters.
I realized I had the username on my GitHub commit history, so did git filter-branch --tree-filter to remove it from commit history.
git filter-branch --tree-filter ++++++ username content.
git for-each-ref refs/original
// Deleting the refs
git update-ref -d refs/original/refs/heads/main
git reflog expire --expire=now --all
git gc --prune=now
// checking that it's all deleted
git log --all --oneline -S "(username)"
git for-each-ref refs/originalCeiling Fan Switch
Using it to turn light on and off. We know when light is off through the API, not through switch state. In this case, LED strip should be off as well. I wonder if the API accounts for this because it didn’t seem to have good error handling for state at least?
NeoPixel Visualization
If there's 100% brightness, then all 8 NeoPixels should be lit up. If there's 0% brightness, no Neopixels should be lit up.
Could also use a circular NeoPixel around the rotary encoder to know which hue is currently selected.
Errors
C++ is case sensitive
Improving response time
Disabling other microcontroller functions to fire loop quicker?
transitionTime would smooth the bulb further, but bulb is already smoother than the strip.
I’ve reduced the amount of steps the rotary encoder needs to take to change hue, but perhaps would adding transition time be the answer?
time that it takes for message to get to network. Add fade.
Hallefect sensors. Read change in direction of magnetic field.
Read sensors all the time but only act when needed.
It would be so so fun to do a little wave between all the lights that includes moving the brightness through a sine wave.
Nothing is changing yet, I’m making a put request to the server
The reason to do this is preventing that someone else changes the light without my knowledge. But in this case I’m optimizing for visuals and responsiveness. Solution: writing to the API instead of letting the API write to the strip. Better yet, write to the bridge and the strip at the same time when changes happen to any of our sensors.
Alternatively, instead of making API calls / PUT requests from the controller into the bridge frequently, I can listen for rotary encoder events.
Pseudo Code
setup() {
- make a put request for a specific light setting, including a transitionTime?
OR
- get current light data and assign that starting point to light strip.
}
loop() {
- listen for rotary encoder events,
- if there’s change, make a put request for hue in the lights.
}
Arduino owns the state
Class Notes
ZigBee - no direct consumer pieces for it. Difficult documentation. There’s a push for Bluetooth now.
There’s some
The XPs could be programmed to be Hue Bulbs.
Everybody now makes things for Alexa and Google.
IFTT.
Hue allows for third parties.
Send transition time so that fade takes a second or two.
When system transitions a little slowly, we slow down in our expectations.
Soft buttons will change people’s expectations in responsiveness.
There’s potentiometers that go back to their original state.
How can we create feedback in our controls?
Tolerances;
What we’re seeing on networks doesn’t allow for real time.
Phillips HUE API has groups and scenes.
A phone can do everything. So how do you know what to do?
Project
Scanning for Radio signals. Wi-Fi is a form of radio technology. I keep forgetting. I’d like to understand why.
There’s an article around hacking into Lutron’s light switches from an ITP alum.
Document if I go down this path.
It would be so fun to create
>Functional Furniture?
Final project
About web based APIs. Explore an API and come up with a physical interface.
Pick one by next week, communicate that to Tom. Pick a partner.
Tide API from Noah - Tom’s fav API.
Bluetooth
Bluetooth LE became much more of a publish & subscribe model.
Bluetooth I
ToolBLEx - Tom’s favorite.
LED.ino example.
Bluetooth also has RSSI.
Visualizing
There’s math on getting angle.
Gyrometer is measuring angle
Accelerometer is
See if up, down or sideways. You look for one of the axis to be reading maximum value.
Other option is that I can look at see X, Y, Z - which ever one is the highest I know that’s the side facing down. Where as, I can also look at minimums.
If axis is facing down AND X (???)
Design the thing so that people will do something predictable. If I’m doing an intangible controller, I’d need to add something gestural about it.
Gestural Sensor.
