Soft Keypadlinc-like Console from Raspberry Pi

[kck]

One of the things I did when I installed a bunch of Insteon switches during a master bedroom remodel was to create a bedside consoles by mounting an 8 key keypad in a box for each of our nightstands that can control all the lighting in the bedroom and do things like prep the bathroom (heat floor and towels, make sure the hot water recirc is running, etc.).  This had incredible WAF scores - my wife loves not having to get up to do this stuff.  When I got a RPi to run the Echo bridge stuff I thought it might actually make a much more functional bedside console for about the cost of a Keypadlinc.  So I got an Adafruit 3.5" touchscreen display for it and have build a soft console that mimics everything that the existing keypad does but allows for an arbitrary number of screens as well as different types of screens.  It is about the same cost as the KPL since it is just a RPi, the $45 PiTFT screen, a case, and a $10 wireless adapter.  I think it should actually work fine with a Pi Zero and the cheaper 2.8" screen which really would make it the same cost (and the code should self configure to the smaller screen though I haven't tested that).  Currently it supports on/off keys (the keys change appearance mimicking the KPL LED), and keys that run programs (e.g., I have one that sets up the bathroom).  Key display tracks status changes from other switches by watching the ISY event stream (i.e., it behaves like a key on a KPL would when the key is a responder to a scene).  It self configures the key layout for the number of keys on the screen (i.e., it isn't restricted to 8 - anything from 1 to 25 keys will be displayed sensibly).  It also has a clock screen with a configurable day/date etc. appearance.  Pretty much all colors (background, keys, characters, etc.)  are configurable from the configuration file, as is a homescreen to which the display returns after a user set time period and a time to dim the screen.  I plan to add some other screens that I'd like such as a weather screen and a thermostat screen.  The entire project is coded in Python and adding a screen type basically amounts to coding a subclass of a defined Python screen class to do the setup from the configuration file and the actual display when called upon.  The only hardware issue I have at the moment is that I'd like to find or fabricate a screen bezel to make the unit appear a bit more "finished".  The code is up CORRECTION: code is on GitHub.com/kevinkahn/softconsole now on bitbucket at https://github.com/kevinkahn/softconsole in case anyone would like to use any of it as is or as the base for their own unit.  Just thought that I'd share this given all the helpful stuff I've learned from others here.  Within reason I'm happy to answer questions regarding the project.

 

For a few pictures of this see:

 

https://1drv.ms/u/s!AmUpYkWiYac5g907yF7tyubLcd5uiw?e=QXazzA

Edited February 12, 2021 by kck
Update links

[k5map]

kck,

 

VERY kewl and thanks for sharing... I have a few RPi laying around so looks like I have a new project

 

Just so I know all of the requirements, can you post what you loaded into your RPi outside of the OS and your project?  What add-on modules are required for the ISY?

[kck]

OS version is Jessie.  Python, Pygame are there already I think.  I'm afraid I've lost track of the other Python libraries that I have installed but at worst you'll get a not found and installing them is trivial so no problem there.  Otherwise the only software issue is that the Jessie version has apparently broken the SDL library handling of the touchscreen so you have to downgrade SDL to the Wheezy version.  There is a note about that on the Adafruit page for installing the PiTFT that provides detailed instructions to do so.  I don't think there are any other special items.

[k5map]

Ok doesn't sound too painful   

 

I have a good idea what I need for the RPi.  As I understand it, the RPI communicates directly with the ISY.  If so, it is required to have the Network add-on module for the ISY?

[Teken]

Ok doesn't sound too painful   

 

I have a good idea what I need for the RPi.  As I understand it, the RPI communicates directly with the ISY.  If so, it is required to have the Network add-on module for the ISY?

 

Oh my dear friend if you get this hammered out please do document the journey and the steps to accomplish the very same. I would hazard to say if the entire thing could be compiled into a image anyone could download and just change a few network parameter along with user / password.

 

This would be a complete God send . . .

 

To the OP - You Rock & You Know it!

[mwester]

Hmm... I can see a node-server-based integration with v5.0 firmware adding a lot of ease-of-use here!  I don't have the exact devices you describe here, but perhaps a little shopping is called for

[kck]

The network module is not needed - in fact I don't have it.  The console subscribes to the event stream that the ISY puts out and also does some direct rest calls to get the current status of devices when needed.  It uses the PyISY library to get the ISY configuration (but bypasses it for the subscription monitoring for some arcane Python reasons and does some direct calls for current status to avoid cache effects that PyISY seems to induce).  The config file identifies keys on the screen by name, matching them to the device/scene names in the ISY.  It doesn't currently use the folder hierarchy to qualify names - it assumes that ISY scene/device names are unique except that the same name can be used for an ISY scene and a device in which case the console matches the scene.  For cases where the console key should reflect a scene "state" (normally the state of the responder keys in the scene) it monitors one of these but it is also possible to specify a scene proxy device that will  be used to reflect the state of a scene (I have some "scenes" where I induce the "state" of the scene by a program that looks at the state of a set of devices and uses that to illuminate a key).  Currently I don't support fast on/off but might add double tap recognition to be able to do that at some point.  The most fragile part of the program is the config file since I don't really do any error checking on that.  The library I use to decode the config file does have provision for validating such files but since I've been doing this for myself I haven't bothered to use it.  There is an example of my current config file on bitbucket so you can see what it sort of looks like.  The program itself seems quite stable - it ran for a couple of weeks while I was gone and was responding fine when I got back.  I'm currently half way through adding provision for weather screens for 1 or more locations by querying weather underground.  Using them does require a key but you can get one for low volume use (<500 queries per day) for free.

 

As to Python libraries in use you can scan the imports at the top of the .py files to see what I use.  All the public ones can be installed by apt-get or pip which is really simple.

 

As to Teken's question - I'm pretty sure that it wouldn't be too difficult to build a package that loads up and just runs.  My problem in doing it is that since I've been developing this I have a "polluted" system so wouldn't be a good test candidate without getting a separate RPi setup.  I may do that eventually but not at the moment.  I'm happy to help anyone who wants to play with any of this though.  I've been doing it to satisfy my programming itch which hadn't really been scratched for 3 decades or so that took me from software engineer to manager to lab director.  Must say it is fun remembering why I got into programming in the first place nearly 50 years ago!

[Teken]

The network module is not needed - in fact I don't have it.  The console subscribes to the event stream that the ISY puts out and also does some direct rest calls to get the current status of devices when needed.  It uses the PyISY library to get the ISY configuration (but bypasses it for the subscription monitoring for some arcane Python reasons and does some direct calls for current status to avoid cache effects that PyISY seems to induce).  The config file identifies keys on the screen by name, matching them to the device/scene names in the ISY.  It doesn't currently use the folder hierarchy to qualify names - it assumes that ISY scene/device names are unique except that the same name can be used for an ISY scene and a device in which case the console matches the scene.  For cases where the console key should reflect a scene "state" (normally the state of the responder keys in the scene) it monitors one of these but it is also possible to specify a scene proxy device that will  be used to reflect the state of a scene (I have some "scenes" where I induce the "state" of the scene by a program that looks at the state of a set of devices and uses that to illuminate a key).  Currently I don't support fast on/off but might add double tap recognition to be able to do that at some point.  The most fragile part of the program is the config file since I don't really do any error checking on that.  The library I use to decode the config file does have provision for validating such files but since I've been doing this for myself I haven't bothered to use it.  There is an example of my current config file on bitbucket so you can see what it sort of looks like.  The program itself seems quite stable - it ran for a couple of weeks while I was gone and was responding fine when I got back.  I'm currently half way through adding provision for weather screens for 1 or more locations by querying weather underground.  Using them does require a key but you can get one for low volume use (<500 queries per day) for free.

 

As to Python libraries in use you can scan the imports at the top of the .py files to see what I use.  All the public ones can be installed by apt-get or pip which is really simple.

 

As to Teken's question - I'm pretty sure that it wouldn't be too difficult to build a package that loads up and just runs.  My problem in doing it is that since I've been developing this I have a "polluted" system so wouldn't be a good test candidate without getting a separate RPi setup.  I may do that eventually but not at the moment.  I'm happy to help anyone who wants to play with any of this though.  I've been doing it to satisfy my programming itch which hadn't really been scratched for 3 decades or so that took me from software engineer to manager to lab director.  Must say it is fun remembering why I got into programming in the first place nearly 50 years ago!

 

I hope others will be able to contribute in this endeavor because honestly I won't lie to you this in my mind is the holy grail! I kid you not I have seen lots of make shift things and given what you stated in terms of over all cost.

 

Its in the same ball part as a KPL which has limited capabilities . . .

 

Your working prototype if fully developed could sell quite well if the entire thing was plug & play.

Edited January 29, 2016 by Teken

[jon102034050]

Subscribing to this thread to monitor its development. I'm considering pickup up a screen as I do have a spare Pi just hanging around I've been looking to build a project on.

 

Thanks for your hard work!  Looks awesome so far.

Edited January 29, 2016 by jon102034050

[Toddimus]

This is extremely cool!  I recently put some extra blank switch locations around the house in preparation for something like this.  I had been thinking of using old iPhones or maybe some sort of small tablet, but a RPi with touch screen would be awesome! 

 

In fact, I just received two more RPi 2 boards today that I ordered from Makershed.  They are having a big sale.  They were already half off ($20) and then there was a 20% off coupon code which made them $16 each!  Yes, that's for the latest RPi2.  Looks like they are out of stock now though.

[Teken]

This is extremely cool!  I recently put some extra blank switch locations around the house in preparation for something like this.  I had been thinking of using old iPhones or maybe some sort of small tablet, but a RPi with touch screen would be awesome! 

 

In fact, I just received two more RPi 2 boards today that I ordered from Makershed.  They are having a big sale.  They were already half off ($20) and then there was a 20% off coupon code which made them $16 each!  Yes, that's for the latest RPi2.  Looks like they are out of stock now though.

 

Figures, missed it by this >< much . . .

[jon102034050]

Dang!  Missed it!

[kck]

An update on this:

 

First off for reasons having to do with the development ide (PyCharm) I have moved the project to GitHub (it was on BitBucket).  The new url for it is: https://github.com/kevinkahn/softconsole.git

 

It is now in pretty good shape.  It supports key screens with on/off keys and keys that will cause a runthen if double tapped and blink to provide feedback.  It has weather screen(s) that show current conditions and forecast from any WeatherUnderground location by providing the WU location code.  Note to use this you need to get a key from them which is free for this level of use.  It has Thermostat screen(s) that allow any of the operations that the Insteon thermostat allows (setpoint up/down, mode, fan mode).  It has a Clock screen that you can configure as you like.  It will auto dim after a configurable untouched time and return to a designated home screen or to an idle screen.  I use a dark background clock as an idle screen which when dimmed creates little light in a dark room but is still readable for the time.  Navigation between the screens is via command buttons at the bottom.  There are actually 2 screen sequences because I found I had enough low use screens that I didn't want to have to page through them so quad tapping a screen switches between the main screen sequence and a secondary sequence.  There is a decent amount of on board logging and the log can be accessed from a maintenance screen (accessed by 5 or more taps from anywhere).  That maintenance screen can also shut down the console or shutdown or reboot the RPi.  While I'd hardly guarantee no bugs the system has been running solidly for me.

 

I have a list of other things I'd like to do with this and will keep banging on it but as it stands it is pretty useful.  One of the things for sure on my list is to verify that it can self configure for the smaller 2.8" PiTFT since I have a place where I'd like to use one of those in the house.  I won't guarantee great customer support but I'd be happy to answer questions and take other ideas for enhancements should anyone play with this.  In any case the code is all out there for anyone who'd like to try it or tinker with it.

 

To an earlier question - I do intend to get another new Pi in the next few weeks and when I bring things up on it I will do detailed documentation of what is needed to be loaded etc.  In the meantime if you are at all a Python person I'm pretty sure you'll be able to work out what's needed since I was a newbie with Python when I started this little project.  By the way for tinkerers, you can code up a new screen type by basically defining a new screen class that can be instantiated that has a single callable method that will get invoked by the drivers in the program so extension shouldn't be too hard.  You'd only have to modify one line of existing code to cause an import of your new module so that it would get registered so the base program can call it when it sees a reference to the new screen type in the config file.

[ScottAvery]

As it is Python, what would it take to run on a more elegant form-factor device, such as an android tablet?

[kck]

Good question.  All the core logic certainly shouldn't care and in the most recent version most screen presentation stuff scales to screen size/resolution.  I'd guess the remaining issues would be in some low level code that relies on screen specific function.   E.g., the dimming code uses Pi specific IO pins to control screen brightness.  This could probably be easily replaced.  I don't have an Android tablet but I'll take a shot at running it on a Windows box later today or tomorrow and see what gotchas I see.  My guess at a bottom line is that the current version wouldn't "just run" but that it wouldn't take too much work to adapt it.  But the question does suggest that I really ought to do some work to make the screen specific stuff more modularized in the code than they are at the moment (although they are pretty localized I think).  I did happen to emulate running on a smaller screen (320x280) just last night and with the exception of my thermostat screen which I need to do some debugging on the console did just run and adjust its fonts and button sizes to the smaller area so I'd be pretty hopeful.  I'll write more after I get a chance to test.

 

By the way, one of the other reasons that I have been interested in the Pi (besides it providing a price competitive solution for deployment anywhere a portable KPL would make sense) is that I think there is a middling chance that by using a Pi Zero I could actually fashion a version for mounting in a normal electrical box.  This would mean a KPL at price parity that would be infinitely more functional than a KPL.  This is a longer term project - need a Pi Zero, a powering solution, and probably some 3d printed bracket work.  Idea would be to squeeze a P0, screen, 5v power, and a micro switch from Insteon if load control is needed into a standard ebox.  Not sure it will all fit but quick look leaves some hope.

[ISYhbsh01]

As it is Python, what would it take to run on a more elegant form-factor device, such as an android tablet?

 

On an Android tablet I would use the Tasker app to do this.

[kck]

Well this was a pretty gratifying experience.  I tried running the existing code on a Win10 python system.  There were some things that just aren't relevant (like screen dimming) and some things that are a bit different between Windows and Linux (these shouldn't impact an Android use).  There were some strangeness about file permissions for Windows related to my log file that I didn't try to sort out since it didn't seem worth it.  However, once I commented out that stuff that Windows didn't like it ran fine!  It was a bit odd seeing the console display on a big desktop screen but all the text and buttons scaled up to be proportional to the screen size so it all looked quite natural.  While I had thought I had coded stuff so that it should behave well it was surprisingly nice to see that it actually did.  Since I did the experiment I'll go back and encapsulate what I can of the platform specific things to make them easy to replace with an alternative module.  So thanks for the prod to try this - it was interesting and the answer to your original question is a qualified - it should.  I don't actually have an Android platform to try it on but I suspect Windows was a lot more challenging target.

[kck]

So there is now what I consider a stable V1.0 version of this on github/kevinkahn complete with at least basic documentation on setting up the console.  There isn't any documentation on the larger issues of setting up a RPi and getting the necessary other Python packages loaded so to use this you'd need at least basic Python skills.  I still plan on doing a from scratch documentation on a fresh Pi in the next month sometime and seeing how much of the install and setup can be automated.  I'm using this version daily at home though and it seems solid.  Comments/suggestions/critiques certainly accepted.  While it is a project I am doing for my needs I think it does have larger potential value and am happy to try to support that.

[Teken]

Looking forward to taking some time to read the v1.0 e-docs and the future release where its all bundled together in one image.

[kck]

Finally got the time to work on making this easy to install.  The v1.1 version includes a script to setup a new RPi.  It still requires you to do the basic install of the Raspbian OS (Jessie) and connect it to the network which if wireless requires a tiny bit of work.  Once that is done though there is a script and instructions on downloading and running it that will install everything else and adjust configuration stuff so that the console will run.  You then just need to build a config file for whatever screens you want to use.  I have tested this on a RPi2 with the Adafruit 3.5" PiTFT with resistive touchscreen.  I have a 2.8 capaciive screen coming (one I had gotten seemed to have been defective) and intend to test it with that possibly late next week.  I also have a PiZero that I want to try when I get a chance.  So if anyone wants to play with this, feel free.  Also feel free to let me know if something doesn't work or any ideas (I added a combined time/temp screen for my wife after she had been using it for a while and wanted less info but all on one screen - WAF points!).  Sorry Teken - it still isn't quite a single download image and go - not sure how to get there - but what is there is pretty automated and has, I think, decent instructions.

[Teken]

Finally got the time to work on making this easy to install.  The v1.1 version includes a script to setup a new RPi.  It still requires you to do the basic install of the Raspbian OS (Jessie) and connect it to the network which if wireless requires a tiny bit of work.  Once that is done though there is a script and instructions on downloading and running it that will install everything else and adjust configuration stuff so that the console will run.  You then just need to build a config file for whatever screens you want to use.  I have tested this on a RPi2 with the Adafruit 3.5" PiTFT with resistive touchscreen.  I have a 2.8 capaciive screen coming (one I had gotten seemed to have been defective) and intend to test it with that possibly late next week.  I also have a PiZero that I want to try when I get a chance.  So if anyone wants to play with this, feel free.  Also feel free to let me know if something doesn't work or any ideas (I added a combined time/temp screen for my wife after she had been using it for a while and wanted less info but all on one screen - WAF points!).  Sorry Teken - it still isn't quite a single download image and go - not sure how to get there - but what is there is pretty automated and has, I think, decent instructions.

 

Hello Kck,

 

First thank you so very much for taking the time and effort in making it even more streamlined and easy to set up and load. Second, this is going to be a fantastic little project for me in the near future. 

 

Yes, you are making me spend money I don't have!

 

Ha . . .

 

I will need to read over your instructions in the next few weeks and decide when the touch screen should be purchased. Any additional information about the two screens along with caveats would be nice to know. I am really looking forward to getting this off the ground once other competing Alpha / Beta projects are hammered out and underway.

 

Once again I thank you so very much for taking the time to share this with me and the group.

 

Rock On . . .

[kck]

Teken,

At this point I have tested it with the 3.5 screen and RPi 2.  As luck would have it last night my PLM seems to have died (at the 3 year point) and I'm snowbirding it in SoCal with my ISY/PLM in Oregon running remote over the net.  I ordered a new PLM for my wife to install at home (I hope) but that will be a week or so before I can get it back on the air.  Meanwhile I do have a PiZero and should get a 2.8" screen this week to replace an apparently DOA one.  So with luck over the next 1-2 weeks I hope I can test the various other combos of Pi and computer and tell you what works and what I learn about the various choices.  The cheapest combo would actually be a PiZero and a 2.8" resistive which I don't have but should be able to pretty safely extrapolate to.  That combo would be $5+$35 plus WLAN card ($10) and wall wart.  The longer term deluxe version would be a Pi3 and 3.5 screen but from the Adafruit forum I don't think the Pi3 support is in place quite yet.

 

If you do get to play with it or even if you just read through the stuff and have any suggestions or feedback please do pass it on.  For me this is a hobby project that has gotten me back to real programming after a long career that took me to the strategic levels but left the gratification of actually building stuff behind.  So ideas for things to try are always welcome.

 

Kevin

[ScottAvery]

I love the idea of a unit that could go in a standard electrical box and agree some 3d printing could help with the proper mounts.  a finished surface may take more work, perhaps with a rotary tool and a standard face plate.

 

Would be awesome if you could hack the Wink Relay and put your own OS on it as that is a slick form factor.

[kck]

Update:  I have now tested at least in a rudimentary manner using the RPi2 with the 2.8" Capacitive PiTFT with the setup script and it all seems to work.  I'm still a bit limited in my testing due to my dead PLM.  Also,

I believe I fixed a reported bug that caused a crash if a node was in the top level directory versus in a folder.  Since I have all mine in folders I hadn't triggered the bug.  Also, I don't have any zwave devices so can't test with them but apparently some such devices don't have any properties and if one of those was found my parsing of the ISY data structures blew up.  I think I now just ignore such devices (not sure what one could do with them from the console in any case if they have no properties - if I'm missing something about that just point me at an explanation and I'll try to deal with them more intelligently).  These bug fixes are in the currentbeta release.  Glad to see a first bug report from someone else since I know my code is inevitably biased to how I use the ISY.

[kck]

Another update:

I got around to testing the app using the PiZero and the 2.8" capacitive touch screen and it appears to work fine.   Since the PiZero is a $5 item this is certainly the cheapest solution.  I haven't tried it with the 3.5" or 2.8" resistive touch screen but based on the other tests I'd expect those to work as well.  I also couldn't find a case I liked for my house bedstands so I designed a case and angled stand to 3d print.  I'm picking up the 2nd version of that case this afternoon and will see how it all fits.  Assuming it does then there are design files for that case/stand on GitHub as well should anyone want them.   The case is designed for the Pi 2 or Pi 3 layout with a 3.5 PiTFT screen.  I'll post some pictures and an update regarding the case once I get it.

 

Still to test: a Pi3 with one or both of the screen choices.