Petri nets, state machines, decision tables and light switches

I’ve been running a set for my home lighting for some time now using a combination of smart lighting (Lifx bulbs), Node RED from the IBM labs, and a set of sensors and time schedules.  This has enabled me to do some surprising things like

  1. Turning on my son’s lights early in the morning using a ‘rising sun’ sequence – earlier on college days, later on weekends.
  2. Enforcing a lights out! at a reasonable time during college term times, while leaving the lights on Friday/Saturday nights.
  3. Drifting colours of the bulbs through a bright white the first part of the day, into a more yellow or orange glow into the evening and later part of the night.
  4. Gradually dimming the halls lights into before the lights out! command during the working week.

Other than the annoyance it provokes in my offspring it has all be rather unreliable – mainly because the API by which I call the smart bulbs is written in a language which needs special support, and not easily integrated into my standard computer setup of diverse embedded or micro-computer hardware.  I’ve also a larger, more capable server which runs Linux and could do a whole lot of this but I wish to turn it into a power-down mode when it is not being used by my son’s gaming clan, thus saving some of the considerable electricity it consumes throughout the month.

My Node RED flows look like these:

Screen Shot 2014-09-08 at 13.00.10

 

So, a little complicated!

The real issue is that I need several different events to all A long way back I did some work around artificial intelligence and rules engines, so when my wiring diagram above started to get difficult I looked further afield into rules – most of which use something called a ‘rete engine’ for forward or backwards chaining rule invocations.  Whilst that is fine and dandy it takes lots of programming and understanding either the domain-specific rule language of the particular engine, else the programming language and constructs in which the engine is written.   None of that is trivial, unlike the wiring diagram above.  The issue becomes when you try to visualise complex conditions – wiring no longer gives that and we need to look wider afield.

The net comes to the rescue of course.  I’d seen decision tables as being close to where I needed to be.  Those look somewhat like this (from Wikipedia):

The four quadrants
Conditions Condition alternatives
Actions Action entries

 

… or a good example (also from Wikipedia).  The following is a balanced decision table (created by Systems Made Simple).

Printer troubleshooter
Rules
Conditions Printer does not print Y Y Y Y N N N N
A red light is flashing Y Y N N Y Y N N
Printer is unrecognized Y N Y N Y N Y N
Actions Check the power cable X
Check the printer-computer cable X X
Ensure printer software is installed X X X X
Check/replace ink X X X X
Check for paper jam X X

There was some discussion on the Google groups which are used by NodeRED to discuss product features or issues.  Here’s the link https://groups.google.com/forum/#!forum/node-red    Amongst other topics one was  for a couple of enhancements and mentioned Petri nets.  I’m not familiar with those and needed to look up what they did, and it seems that their use is similar to what I need for my smart lights.  Here’s the discussion https://groups.google.com/forum/#!topic/node-red/K7yQFxG07u0

Underlying it all is the concept of state machines, of which I am somewhat familiar having seen these in the world of Business Process Management or BMP.  These are good for taking many inputs and either coming to s definite, simple conclusion (either deterministic or non-deterministic finite state machines) but the issue then becomes displaying them visually.  Normally the connecting line between states is used to determine the transition but NodeRED uses it to depict data and control flow.

What I’d like is a simple way of combining multiple inputs into a single decision; at this point I’m uncertain if Rete engines, state machines, Petri nets or decision tables are the simplest to depict visually.

 

Rethinking the love affair between lights and switches

Bonnie … and Clyde.  

Hanzel … and Gretel.  

Lights … and switches.

Why do we have switches?  Think about it – what is a switch without a light? Nothing.  What is a light without a switch?  Something.  A light by itself is still useful (like a clock which is broken, it tells the correct time once per day), the only downside is that you cannot turn it off, or on.  But at least it is a light and still serves its main purpose.  What happens if we break that link between switch and light?  What happens if we rethink the gift that Edison bestowed upon us?  What if the light could be the switch and somehow know when and what to do?

I purchased some Lifx bulbs recently, and have had a really good experience in setting them up and using them from the smartphone app.  I previously used LiightwaveRF sockets and switches, but somehow they didn’t seem to satisfy what I was looking for.  I think one of the reasons is that the Lightwave system makes the switch intelligent rather than the other way around, so in the marriage of switch+light both parts of the pairing have to remain, whereas the Lifx system makes the light intelligent and makes the switch redundant.  So the divorce can be complete, and lights can stand alone without the limitations of switches.

Am I making too much of this?

We all assumed that houses should have telephone numbers, and dutifully called a house and sub-addressed the occupants of that house.  Nowdays of course we call people, and discard the need for sub-addressing the responder to the call with the assumption that if we’d wanted someone else, then we would have called their phone number instead.  So it goes.

Do we assume the same thing with lights+switches?  Do we assume that one needs the other simply because, well, they always have?  What happens when the light becomes intelligent and does what we want (switches off, changes colour, turns on at certain times, dims) without the use of a switch?  I think this liberates lights to become really, really useful.  For example, I am wiring up NodeRED, the Node.js module ‘suncalc’, Lifx bulbs all in my WiFi router and Raspberry Pi so that my lights switch on the in mornings, change to bright cool light (colour team 6500K), then change to warmer lighting in the evenings (3000K) and dim before bedtime.  A lot of this is due to colour and circadian biorythyms which mean that we expect morning light to be cooler, and evening light to be warmer (essentially bluer in mornings and yellow in evenings).  It actually works really well and the house feels a lot more ‘natural’, whatever that means!

I love this setup so much that I’ve purchased 6 Lifx bulbs, and mean to purchase another 10 GU10s to fit in my main living space.  Now I’m looking for a trigger system such as a multi-button keyfob to replace all the light switches in rooms where I’ve placed Lifx so to trigger ‘events’ such as going to sleep, leaving the room and the like.  I wonder if systems of independent motion detectors as well could provide similar intelligence to really make my system act as a whole?