The flipside of too much security

I just typed my password into a google search.

That was accidental; I run a multitude of different operating systems across a number of different hardware and virtual platforms.  Some of the places I’m required to enter passwords save them securely for me (for example, my corporate VPN client), others I use a password manager in the browser.  But sometimes I still have to enter them manually.

I like my bank – it uses _parts_ of my password so I never inadvertently type it anywhere.  However this entering of my password in Google happened because of a couple of things: being eternally vigilante throughout the day does not equate to having to enter a password multiple times, and screen blanking versus screen locking.  In the case in question one of my laptops went blank screen to powersave, I then started typing my unlock password (which is mandated changed every 90 days) and pressed enter, only to find that the screen had blanked but not locked.  Of course I can alter this so that when it blanks it also locks, but my point is that constantly entering passwords is counterproductive and some sort of presence (RFID? geo-fencing?) is more applicable than the simple you-have-not-touched-the-keyboard time out, and is probably better for security control.

And don’t get me on to the mis-handled SSO tokens, constant re-entry of passwords throughout the day as I use corporate internal websites!

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.