Here’s an idea I had for tying the LED lighting in with the space probe. This forms a “notice of intent,” but it’s also a request for comment.
At present, when you turn the Space Probe on, the LED strips are turned on to illuminate the space. When the Space Probe notices that time is running out (i.e.: you said you’d be here two hours, and it’s now 1:50 or so) it starts blinking its LED purple. When you turn the Space Probe off, it (eventually) turns off the LED strips.
Here is one idea for future enhancement:
When turning the Space Probe on/off or adjusting the time, the Space Probe simply sends a suitable message to a message queue.
The Space Probe subscribes to another message queue which describes the expected behaviour of the LED and VU meter.
The LED strips individually subscribe to message queues, which will provide simple configuration such as “turn LED strip 1 on” or “set LED strip 1 to RGB #FFFFFF” or “set LED strip 1 to ‘PURPLE’ at brightness 50%”.
A coordinator program will monitor the Space Probe queue, and arrange for the following:
When the probe is turned on, start an illumination program which brightens the LEDs to full white over a few seconds. This allows for the space opener to quickly survey the space to make sure everything is in order, open windows, or turn on fluorescent lights if necessary.
1a) As the space probe is being adjusted, adjust the VU meter and blink the LED. Once the Space Probe knob has been idle for more than half a second, sed the LED to steady state.
When that program has completed, enter “random lighting” mode (this will be some other device’s responsibility, presumably whatever it is that acts on the LED strip MQTT queue messages).
When the “space open” time is expiring, pulse the space lights purple and blink the space probe LED purple.
When the “space open” time expires, or the Space Probe is set to 0, bring the LED strips up to full white over a few seconds, then gradually dim them to “off” over two minutes. This allows the space closer to survey the space in decent lighting, and provides feedback that something is happening as a result of twiddling that dial.
The “components” would probably be:
Space Probe itself
MQTT queues for space probe setting, Probe LED, Probe VU Meter, each LED strip
An LED strip “master” which acts on the LED strip message queues
Of course I have no idea how complex MQTT is, compared to what an Arduino with an Ethernet shield is capable of. I also have no idea what is actually happening in the Space Probe code.
So my preliminary project will be to recreate the space probe with my own hardware and work from there.
Sounds like a great idea setting up MQTT (or similar) @ManicDee
If my memory is correct @devdsp had plans a few years ago back at Downer to set up MQTT - I could be mistaken though.
Either way - I think it sounds like the way to go - allows other things to subscribe / send messages - a way towards a more automatic/autonomous/living space.
I did start playing with MQTT to do basically this in the old space. Re-implementing the spaceprobe is something that’s been on my list of infrastructure related projects for a rainy day in the space. Haven’t had many of those recently.
Currently the spaceprobe works as an HTTP server which gets polled from a (probably still lua) script on aspirin. The HTTP polling is what’s causing the icky lag. It’d be much nicer if most of the logic went back onto the micro in the spaceprobe and it just announced state changes over a push system like MQTT or making an HTTP request. Then the script on aspirin would just need to send out tweets and emails when it gets updates from the spaceprobe.
The LED strips are controlled over DMX using a very python script on aspirin. It could reasonably easily be upgraded to listen for MQTT messages rather than reading the space-api json file for state changes. I’m keen to build a state machine style script to do things like you describe as well as put in a ‘clean up time’ light state.
Ardiunos are well capable of running MQTT btw. Which reminds me… at one point I totally had an arudino listening for MQTT messages to turn LED strips on… https://github.com/makehackvoid/mqtt_tableleds
MQTT is pretty lightweight and is also available in the ESP8266 library
Hopefully in the next few days/weeks I’ll get around to releasing my
home_automation system I wrote in python, it heavily uses MQTT (via
mosquitto) to talk to itself/my work in progress wifi light switches (which
are based on the ESP8266)
Whilst it sounds a little stupid to have a system that talks to itself via
MQTT the idea behind it is to simplify interfacing and improve
extendability (flexibility to either directly talk to the WIFI Leds or via
the normal event setup or even through a custom event (that’d be used to
fire off groups of lights for example))
my wip code for me light switches (I’ll have a crack at your debouncing
when I get around to it @ManicDee)
