kck

Gary, Do you not like the case (you can probably find other designs by now - there weren't any I could find when I started doing this) or do you mean issue with getting one built? If the latter one thing to look at is 3dhubs.com. They are sort of an Uber for 3D printing and are how I got started. You upload a design file to their site and they will immediately provide quotes from folks in your area who will print it given a material choice. If you like one of the quotes they forward the info to that maker and if he/she accepts then 3dhubs handles escrowing payment until you get the part. I had a few things done that way - always just picking up the item although many makers will ship if needed. My experience was pretty good - of 4 guys I had print something 3 were great and one (an overly cheap option) wasn't. The last guy I dealt with I have remained in contact with and exchanged advice about printing after I got a printer of my own. Kevin (If you were near Portland I'd print one for you. The case prints in ABS in a few hours and a few bucks worth of material.)

Yikes! I'm doing this for fun! Don't turn me into a production house! ​ I want to stay retired! Seriously - willing to help as necessary short of that. Thanks for the kudos.

I uploaded a slightly improved version of the 3D printed case to Thingiverse in case anyone might want it for this or other uses. It's at http://www.thingiverse.com/thing:1652666 It has a bit better lid seal, access to the SD card without removing screws and an extra feed hole for small wires out the back if desired.

If you look in the docs directory at github the usage notes document has most of that. Also, the prepsystem script is designed to take a raw RPi and install everything but if you look through it you can see all the steps etc. If you have questions after that I can try to answer them (and use the questions to update the docs). Kevin

It was just pointed out to me that the link in the first post of this thread dates from when I was using bitbucket. The code now lives on github.com/kevinkahn/softconsole

I started a separate thread on the wall bracket for this because that might be of use independent of my softconsole and is actually about mechanical design. Thread is at http://forum.universal-devices.com/topic/19124-wall-mount-rpi-with-28-touchscreen/

That daemon died is an old print statement for debug that happens if a signal occurs for the spawned daemon and it isn't alive. It may be misleading in that the main process could be having the error and the daemon death is just part of the crash of the main program. When things start you should see a blue screen with a bunch of log messages starting with the program id and copyright and listing stuff as the program sets up. All that should also be in the current Console.log file in the Console directory. The program keeps the last few under serial names. If you can tell me how far that log gets that might help. I suspect that the program is simply not robustly handling an error in the config.txt file and blowing up rather than politely saying something useful. That is one are of the program that I know is fragile since as I built things I wasn't generally making errors in the config file but those are exactly the kinds of errors that a new user would have. Can you send me your config.txt file? I can try to see how it is getting parsed and, I hope, id the issue. Kevin (I'm on Pacific Time if we need to coordinate anything deeper - I would like to diagnose this so I can make the program more robust.)

Looks like you are running an old version - my bad because I thought I had made the fixes for what I think this was a real release but it looks like I didn't. There were 2 issues that got fixed at that point. One had to do with zwave devices that don't have properties (I don't have any zwave stuff so didn't know these existed) and the other was for devices at the top level of the ISY tree. To the latter, all my devices are in folders so I hadn't bumped into the bug. In any case, the version that I had released earlier today as 1.22 should have fixes for these both. There have been a bunch of other bug fixes along the way so I'd suggest that you pull release 1.22 and use that. That release should also make it easy to pull future beta or real release code from the maintenance screen. By the way the https warning were driving me crazy. I have not been able to figure out how to get the cert stuff right at both the ISY and console ends. So the release 1.22 also just uses http. This only is meant to run on an internal house network so the security shouldn't be too big a deal. I had only switched to https because I was away from the house for 6 weeks and wanted to be able to still debug things through my firewall and I couldn't do that on port 80. So you shouldn't see the warnings any longer though someday it would be nice to sort out Python, ISY, and certificates. You are correct that the key names in the sections being the device/scene name from the ISY. The label field lets you override how the key on the console displays the device/scene name if the one in the ISY isn't what you want. Thanks for the feedback - sorry about the bug (especially since they were fixed when someone else reported them months back - ugh). I'll try to respond on anything else you happen upon. It is always tough to find issues that don't occur in the way one uses the code oneself so I don't doubt that you'll trip over other stuff I have missed.

Actually you can pretty much get what you seem to want by just setting the outline offset to 0 and the key color and background color both to white. Might have to play with the "off" coloration to get it closer but it is not too far off even now. A couple of items regarding this to think about though. First off, I use the colors for the bedside units because with glasses off and in the dark it is MUCH easier to see which key to press. Without the color you actually need to read the label which for aging eyes can get tough when just awakened. Second, for the bedroom units you definitely do not want the default situation to be a bright screen of any sort - that throws far too much light. I actually set my timeout screen to black background (it's a clock with weather) and even then dim the backlight. Now for use in a wall unit in some other room this might be less of an issue although I suspect you still won't want the idle situation to be like you picture - it will glare too much. Finally, it is useful to be able to put some other screen up with some info of interest when the pad otherwise idle even in the wall case - if all you ever plan to put up is the keypad you'll be better off just using a real keypad. So bottom line - I think the current code can get very close to your pictures if that is what you want (and could be adjusted slightly if needed to get the rest of the way there) but I don't think once you actually start using such a unit that will turn out to be what you really want. By the way - no CAD training for me - the tools are really easy to learn and mostly it becomes something of a puzzle to figure out what you want a gadget to look like. Still hoping to get to put a full wall unit together sometime later this week.

So I found some time to take a few pictures of what I am doing which should give you an idea of what might work. Pictures are here: https://drive.google.com/folderview?id=0B0VzcK-K28WaYm1VMU5XVWNaSms&usp=sharing. If you look at image 5141 you can see the display and just barely the edge of the Pi Zero hanging below it. The black vertical box on the left is the power supply - takes in line voltage and provides 5V. Its inn a separate compartment so it should be the only place where line voltage and 5V are together. The white box at the bottom is an Insteon Micro Dimmer. You can see how the entire assembly fits into a single gang box. You can't tell but it leaves about an inch for wire connections below the assembly. The assembly has a screw hole aligned for the standard switch mount position in the box. At the moment I can only screw it down on one end. If that isn't enough I can add a friction bracket at the other end to provide more stability - that awaits an actual test. There are 2 screw holes for mounting a faceplate that are at diagonal corners (only place to put them. I have a design for a custom faceplate that will work with these. I hope this gives you a decent picture of what might be done. I think this version of the assembly bracket is very close to final. Next step is to finish a faceplate and then try the entire thing in a real box. I hope to get to that next week as I am away for the weekend. Comments or other ideas always welcome! Kevin P.S. The current drawn buttons are pretty arbitrary. It shouldn't be too hard to improve them (I make no claim to being an artist ). What sort of things did you have in mind?

Don't have a picture at the moment but I'll try to get one of the prototype next week. What I am doing it designing a bracket that supports the display and PiZero and a small 120-5V power supply and possibly has a slot to position a micro Insteon. It certainly wouldn't pass code but what I am doing is making sure that the 5v parts are separated by plastic walls from the 120v parts with just small holes for the necessary wires to pass through. The display is to big to actually recess into a single gang box but would mount on the surface of the box. Positioning the screw holes to hold things together is tricky and a work in progress. It would require a custom faceplate which is slightly larger than a standard size one (more like a midsize commercial plate) and has it's mounting screws in a different place to work with the display dimensions. The plate may also wind up being slightly thicker (like about 2mm so not really noticeable) than a standard plate. I think I can make this all work but proof is in actually building one which is my work in progress. More info next week I hope.

For anyone interested in using a RPi as a console of some sort with my or other software, I designed/fabricated a case for my bedside use that you might be interested in. I have 2 of my soft consoles in use on either side of our bed, each configured differently per the desires of me versus my wife. I couldn't find a case that would work well with the PiTFT display I was using so I designed one along with a stand for it. Pictures can be seen at https://drive.google.com/a/coral-zone.com/folderview?id=0B0VzcK-K28WaQVdheE1vcDdreXM&usp=sharing. I fabricated it on my 3d printer (Flashforge Creator Pro) in black ABS and it came out well enough that my wife is happy (main criterion ). Anyone who wants to use and/or modify it is free to do so. I uploaded both the design files (in case a modification is desired) as well as the STL files. The design is done in 123D Design (free software from Autodesk). In case you aren't aware, there is a very large network of folks that will do 3d prints for others at 3dhubs.com that is very easy to use (and even will give you a cost estimate before you contact anyone about the job) so if you don't have your own printer and you want to try out 3d printing that is a good way to go. The files are up on GitHub.com/kevinkahn alongside the softconsole code. P.S. I have another effort to try to do a version with the smaller display and a Pi Zero that could go into a single gang electrical box. I think I can make it work but it is still in progress. That would produce a very flexible controller for the ISY and other info for the cost of a Pi Zero ($5), a small touchscreen display ($35), and a power supply (~$5). I think there would even be room in the box for an Insteon Micro Switch/Dimmer which would mean it would effectively be a replacement for things like a keypadlink for not much more money. I'll report back when/if it works out.

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.

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.

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

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.

Assuming that you want to make the lights be able to dim just make sure that the dimmer is the switch that has the load attached. The on/off switches will still generate dim commands. So create a scene with the 3 switches all as controllers. Should work with no problem. The thing to remember about any Insteon switches is that they really are 2 mostly separate things - a load controller and a human accessible switch. All the human accessible switches generate the same command set on the network even if their co-packaged load controller doesn't implement some of those commands. Here the on/off load controller elements are simply not being used. This is also nice to remember when you manage to burn out a load controller like I have (overloaded the dimmer unit). That switch is still perfectly fine to use in a place where a load isn't being controlled - like as part of a multiway setup, or as in my case as a KPL with no directly attached load.

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.

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.

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.

I've actually been thinking about adding an alarm clock facility to my soft console application for the Pi. Since I have a console sitting on my bedstand it would be a natural spot for it and provide a rich/easy interface. This approach would probably put the time alerting logic itself in the RPi and then trigger a program on the ISY at the designated time. By the way - current version of the softconsole is a quite stable v0.91 on github.

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.

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!

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.

For anyone who bought a RPi to bridge to their Echo I just posted a little console project I did with the RPi I have doing the bridging as a new topic in the How are you using the ISY area that you might have some interest in.