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:

 

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.