Soft Keypadlinc-like Console from Raspberry Pi

[Screw Loose Dan]

It just cycled until it killed the console.

 

But, your comment about it being just a timeout made me take a look at the timeout values in isy.py.  I increased them all to a value of 10 and it all worked!!  Not sure a timeout of 10 is sane, but I'm guessing SSL just adds a bit more overhead.  I presume that timeout value is in seconds? In your isy.py are 3 and some are 5.  With the value of 10 for all timeouts, I've restarted it multiple times and it runs up without issues.  Thanks!

[Screw Loose Dan]

Just to follow up, in case anyone else tries it...I got everything working with SSL/HTTPS, but found it extremely slow and cumbersome.  It is so slow that I went back to using HTTP.  I did some digging around on the forum and the limitation is the ISY hardware.  It's documented (see here and here for example) that it takes 4+ seconds to establish an SSL connection (TLS handshake) for rest calls, this is because the amount of computation it takes when using a certificate with 2048 bit encryption.  Those using smaller keys might not have (as much) an issue but industry standards now suggest 2048 bits as a minimum.

 

Since I'm planning on only using these soft consoles on my private lan, I'm not worried about using insecure http.

 

While on the topic of HTTPS and secure connections - I switched the URL for WeatherUnderground to use https and saw no downside.  This is my line 81 of weatherinfo.py:

self.url = 'https://api.wunderground.com/api/' + WunderKey + '/conditions/forecast/astronomy/q/' \
                                   + location + '.json'

And a couple pictures of my 7" display:

 

 

 

I have pondered how difficult it might be to get the WeatherUnderground icons to display.  Seems like on the 7" display, they would really enhance the look.  So the weather might look something like:

Current -  53 F

Sat  53/30

Sun  48/37

Mon  51/42

Tues  54/31    (interesting the "chance of rain" and "rain" icons look the same)

 

If anyone has any ideas how that might be done, let me know.

Thanks again Kevin!  I've been having a blast playing around with this and have two units now "deployed".  Much appreciate all your efforts.

[kck]

Nice stand.  I'll add an installation option to not flip the screen next time I touch the script.  I had not wanted the power coming out the bottom for my situation but with that case it works well that way.  

 

I'm sure there is a way to add the weather icons - I'll have to think about that one.  It never seemed to be worth it on the smaller screens but on the 7" I agree it would look good.  I don't think the issue is with fetching them - it will be with figuring out how to describe the screen layout you want since I let the config file control that.  By the way is there any real advantage (other than I guess securing your WU API key which is free anyway) in using an https connection there?  I can certainly change that to use the secure option.

 

Interesting observation about the speed of https on the ISY.  I hadn't realized that although I had noted that for a lot of things including startup it is pretty slow.  I may uniformly up the time outs a bit anyway to cover folks who want to try the secure option.  Like you, my systems all run on my home net so I don't worry about it much.  I try not to make the timeouts too long because then you can get some pretty long pauses when there is a network glitch that can make you think things are hung.  So it's a bit of a guess what the right timeout should be.  Where I really ran into issues initially was handling a whole house power outage because the Pi systems are back up in seconds whereas the ISY takes a good while to get back up.  That made the pi systems "lonely" they would hang or die.  Now they have been taught to have patience. 

 

Kevin

[Screw Loose Dan]

As far as using HTTPS for the WeatherUnderground calls, the main reason would be to secure your WU key (which I agree there isn't much value in) but it could potentially also validate that you are communicating with the WU servers. However, best I can tell it doesn't appear that the WU certificate is being verified/validated, so it really would just be just to encrypt the traffic in this case.  If the certificate is verified to be valid, then you could be assured you were indeed getting the forecast from WU servers (in theory someone could deploy a DNS hack and impersonate WU without validating the certificate). There's many that believe all web traffic should be encrypted and it's just generally accepted as "good practice". But, some wear their tinfoil hats tighter than others!    I just happened to be looking at the weatherinfo.py and saw the URL shortly after doing all the other HTTPS stuff, so I thought I would just try it.  It probably has very little impact on the performance one way or another (WU clearly isn't running their servers off 166 MHz cpu like the ISY).

 

I took a quick look at the json API for WU, and the icon URL's are returned.  So, I presume it would be relatively simple in the weatherinfo.py to add that to what is put into a variable.  But, from there I get a bit lost in how to retrieve and display the image.  Let me know if you do work on it I would be very interested, but I may poke around with it myself if I have time.

[kck]

So I took a quick look and it seems like it should be fairly straightforward to grab and display the icons.  I'd probably need to play around a bit to get the scaling and positioning correct.  I'm off scuba diving for the next week so not near a development system so the soonest I can get to look at it is 1st week of Feb.  If you want to play with it sooner feel free.  I'll probably need to modify weatherinfo.py to grab to icon and then weatherscreen.py to munge the formatting to allow for displaying it nicely.  Don't think it will be a huge amount of work - just perhaps a bit finicky to get appearance right.

[Screw Loose Dan]

I decided to take a look at what it might take to get this running as a proper service. My initial poking around discovered:

• Raspbian Jesse uses systemd for service control (Earlier versions are different)
• RaspberryPi.org has a very simple example to follow for systemd.
• Pygame and systemd apparently don't play nice together, so my initial attempts didn't go well.    

Some google-fu discovered I was not the first to stumble upon Pygame and systemd's issue.  So, I was able to work (hack!?) around it and get a service setup. I'll cover the steps I used here.

 

First, backup and revert back to original rc.local

sudo cp /etc/rc.local /etc/rc.local.bak
sudo cp /etc/rc.local.~1~ /etc/rc.local

Next, modify the /home/pi/consolestable/utilities.py file with the following, I added it immediately after the imports (~line 23):

# next several lines stolen from https://stackoverflow.com/questions/39198961/pygame-init-fails-when-run-with-systemd
# this handles some weird random SIGHUP when initializing pygame, it's really a hack to work around it
# Not really sure what other ill effects this might have!!!
def handler(signum, frame):
    pass
try:
    signal.signal(signal.SIGHUP, handler)
except AttributeError:
    # Windows compatibility
    pass
# end SIGHUP hack

Next create a service file for systemd to use.  As root, create the file /lib/systemd/system/softconsole.service with the following:

[Unit]
# Description could really be anything meaningful/distinct
Description=SoftConsole
# This should make sure the network is up
After=network.target
 
[Service]
# Script needs to be executable and first line will be '#!/usr/bin/python -u'
ExecStart=/home/pi/consolestable/console.py
WorkingDirectory=/home/pi/consolestable
# Should restart service if it is not stopped gracefully
Restart=on-failure
# Slows things down a little on restarts, maybe doesn't need to be so long
RestartSec=3
# Makes sure any output gets to syslog and named sensibly
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=softconsole
 
[Install]
WantedBy=multi-user.target
# Allows the use of journalctl -u softconsole.service to view relevant logs
Alias=softconsole.service

I added the shebang to the first line of console.py (this isn't portable and I need to determine python2 vs 3, see here and here):

#!/usr/bin/python -u
"""
Copyright 2016, 2017 Kevin Kahn
<snip>

Made console.py executable:

sudo chmod +x /home/pi/consolestable/console.py

Using systemctl, enable to service.

sudo systemctl enable softconsole.service

Reboot the system if you want to verify that things worked as desired.

 

Use the following to control the service:

sudo systemctl status softconsole.service    # Check status
sudo systemctl stop softconsole.service      # Stop service
sudo systemctl start softconsole.service     # Start service #
 
# You can also use more conventional service commands like:
sudo service softconsole stop
sudo service softconsole start
 
# If you make changes to /lib/systemd/system/softconsole.service
sudo systemctl daemon-reload

The script does put information about the service in /var/log/syslog:

Jan 20 22:26:12 rpidisplay systemd[1]: Stopping SoftConsole...
Jan 20 22:26:14 rpidisplay systemd[1]: Stopped SoftConsole.
Jan 20 22:26:20 rpidisplay systemd[1]: Started SoftConsole.

Probably easier to actually find the service logs in /var/log/daemon.log with this:

grep -a SoftConsole /var/log/daemon.log 

Or use:

journalctl -u softconsole.service

I have not begun to look at how this might impact the python scripts that you have to control the console.  My initial testing shows things work as expected, but I didn't do regression testing of many scenarios (like beta consoles).  There maybe some other items that need further attention.

 

[Screw Loose Dan]

So I took a quick look and it seems like it should be fairly straightforward to grab and display the icons.  I'd probably need to play around a bit to get the scaling and positioning correct.  I'm off scuba diving for the next week so not near a development system so the soonest I can get to look at it is 1st week of Feb.  If you want to play with it sooner feel free.  I'll probably need to modify weatherinfo.py to grab to icon and then weatherscreen.py to munge the formatting to allow for displaying it nicely.  Don't think it will be a huge amount of work - just perhaps a bit finicky to get appearance right.

I'm not in a big hurry for the icons and when I start looking at the code I get lost quickly.  I was thinking weatherinfo.py would grab the URL for the icon and put them in a variable to grab the gif's later, but maybe it's best to just to grab the gifs while still in the weatherinfo.py.  I haven't begun to look at the display side.  I'm sure that's the challenging part, especially not being familiar with the code.

 

Enjoy the scuba diving!! 

[kck]

The systemd change is something that's been on my "someday" list for a long time so thanks for looking into it.  I'll need to see how it interacts with things like program commanded restarts from the maintenance page and auto version update and restarts but I should be able to sort that stuff out and incorporate the changes into the standard release.

[Screw Loose Dan]

I would very much like to see running it as a service implemented into the standard release at some point.  I'll be more than glad to help in anyway I can.

 

Some of my thoughts as I look at how your code works...(just typing out loud!  )

 

Regarding the consoleexit bash script, I have to admit, there's a few things in there that seem redundant or I don't understand (which is very likely). I could probably easily make the changes to the bash script to get things to "work" with the systemd service, but question how to best handle the beta stuff.  Doesn't seem like it would be a good idea to run the beta as a service and while changing the systemd unit scripts to do it would be possible, it seems like a generally bad idea. I think once the initial install implements the service/unit file, it probably shouldn't be touched unless there is good reason.

 

I think the simplest/quickest way for the service/beta to be handled, is when choosing to running the beta, disabling/stopping the system service and then running the beta scripts as you do now (not as a service).  When switching back to "stable", stopping the beta console script, enabling/starting the service would get you back. With the current setup, I presume a reboot of the Pi gets you back to stable, correct?  Problem here is disabling the service would prevent it from starting on reboot.  If the service is just stopped, it should be okay, I would just be concerned with running the beta and accidentally starting the service. Do you do any checks currently to know which one is running? I can't imagine both in parallel would be good...

 

Presuming the scripts don't currently have anyway to determine if the beta or stable is running, I was thinking it might be best to write a file (like 'run_as_beta'), have the console script as it starts detect if that file exists (and that the path of the current script isn't the beta one).  And, if it does exist to stop the service and start the beta version (like you do now).  Getting back to stable would be as easy as removing the file (programmatically or otherwise).  On exit, if no errors leave the beta file, if errors existed remove the flag to get back to stable (to mimic current behavior, I think) and restart service.  A regular reboot of Pi would get still get you back to beta (service would start stable, it would check for file, etc).

 

I don't have much experience with these RPi's, but is their network stack that unstable that they need to be rebooted that frequently? Is logging the netstat and ping on errors/unknown reboots really necessary/helpful?  Or, was it left in troubleshooting a specific issue?  When I was doing some work to my WiFi lately, I thought the console script handled the lack of wireless gracefully...until it rebooted. Maybe prompt for a reboot if ISY is not reachable after XX amount of time, or chose to wait? (Rebooting in my work world is akin to pushing a thumbtack in with a sledgehammer...it can work, but generally NOT acceptable.)

 

If the network is that problematic, I wonder if toggling the network adapter wouldn't make more sense than a reboot (but even that seems strong handed to me).

 

If necessary, a much nicer way to ping your default gateway in bash (because not everyone has the same IP address range!):

DEFAULT_ROUTE=$(ip route show default | awk '/default/ {print $3}')
ping -c 1 $DEFAULT_ROUTE

 

We could probably also work out pinging the ISY address, which I think makes more sense than pinging the default gateway for most of the script issues.  Now that you accept URLs or IP's for the ISY address that would need to be handled, but do-able.

 

FYI - The bit of playing around I've done with the systemd service, it seems to work just as advertised.  I have made some minor changes, which I'll get updated in my original post on the topic. Biggest change was the Restart=always -> Restart=on-failure (allows the program to exit cleanly without the system restarting it). The system attempts to restart the script anytime it is killed or not running (unless exited cleanly).  If I borked something in the python code and it throws a code, it just keeps trying the restart until I correct the code.  Then it starts right up.

[kck]

The startup code and related stuff evolved from things I had specifically on my Pi systems but that were irrelevant to others.  When folks said they'd like the code I never really cleaned all that up - but you're right that I should and moving to systemd initialization would be the catalyst for that.  The strange network testing stuff was in response to some specific Pi network hangs that I was seeing and I had left it in place in case they reappeared.  But ultimately it turned out that most of those were caused by a specific WiFi adapter that had some strange issues.  Also, later OS releases seem to have further hardened the network stack  There actually is a flag file for using the beta version along with some auto fallback logic in case the beta version blows up.  I think all of this can be cleaned up in a systemd implementation.  I think we'll be able to rely on the systemd restart for some of that and ditch the scripts.  The main thing I want to test is the autoversion update to make sure that the right directories get used since there is some odd switching of directory names involved and it systemd hangs on to inodes rather than actual names it may not grab the new stuff.  The other thing I'll want to do is to allow the in program maintenance option to shut the console down without restart if desired.  Systemd allows result codes to be passed back from a service that is terminating so I think it should be straightforward the use those to get the correct actions.  I just need to paw through all the little detains but I do think you are right that moving to systemd will be a much cleaner approach.  I'll put this on the list for next week when I'm home.

 

Kevin

[kck]

I just pushed a new release (2.6) that switches control for the console over to systemd as suggested and pioneered by Screw Loose Dan above (thanks Dan!).  This really is a cleaner approach and it gets rid of some pretty fragile shell scripts and some odd logs that captured bits of information since that info is now either in the Console.log or it is in the syslog where systemd sends it.  Here is the blurb from the release on GitHub:

 

This is a major change to how the console gets started in that is moves from using the old and rather fragile rc.local file to using the systemd services manager that has become fairly standard for Linux. If you do a clean install of a new Pi system (burn a new SD card and run pisetup) you will get a console controlled via systemd and this is the best way to do this upgrade. However, you can simply upgrade an existing 2.5 system using the normal upgrade process. In this case, the system will set everything up for systemd but it will not enable it and it will leave the existing rc.local untouched as the way the console gets started. This is because blindly editing rc.local could be dangerous if you have put other stuff in there. So if you do the upgrade route I suggest that you eventually manually edit rc.local to remove the console start part of the script and then enable the service via systemctl. See the usage notes for a more detailed explanation.

 

There are also a bunch of small bug fixes in the release including allowing for up to 10 forecast days on weather and adding an option on the 7 inch screen to flip it for power plugs on top instead of bottom.

[Screw Loose Dan]

I installed the new version on one of my Raspberry's.  Since I had been messing with so much, I did a fresh install.  It took me a bit, but I got everything up and running and it all seems good now (your config scripts get me everytime).  I confirmed the >4 day forecast stuff worked.

 

Why do you install your own VPN service and not use the built in one?

 

I have to work 12 hour shifts the next four days, so I won't have too much time to play with things, but everything appears to be working for now.

[kck]

   Good to know things worked.  

 

I assume you meant VNC when you said VPN?  The normal setup doesn't install VPN (though for some personal uses the old OpenVPN install code is still in that script though I don't use it any longer so probably should delete). If you mean VNC then to some extent that dates from a couple of Debian versions back when no VNC software came with Wheezy.  However, even now I can't get the stock setup to work for me, although I'd certainly prefer to use it (though I'd still like to move its port assignment - not real security but a practical matter at times when I want to open a forwarding port in my router to get at it from outside and it immediately attracts attacks like flies).  Perhaps you know how to get the right outcome more simply.  The virtuald service won't run because that requires a license.  The x11 service works  but once I move the console to the small touch screen rather than hdmi, then the virtual terminal it opens grabs the x11 screen running on the touchscreen which is too small to be usable.  If I don't set up the touchscreen that version works fine.  So I just forcibly create the separate VNC/X11 terminal.  Perhaps I should try not moving the console off HDMI - it used to be I wanted access for sure to that console but now I probably don't.

 

Regarding your comment about the config scripts, I've tried to keep that whole process pretty simple.  Please let me know what trips things up since I'd certainly like to fix any "gotcha" items.  I run that script so often I could do it in my sleep so I'm a very bad test case for it.  Any suggestions on simplifying the install are certainly welcome.

[Screw Loose Dan]

I apologize, I absolutely meant VNC.  I rarely use VNC and so I'm not that familiar.  I personally don't see much need for it on a device like this (but I understand for developing the software it could be helpful).  Are you using it to display the console or just a desktop?  The little I understand of VNC, I believe for a seperate desktop you would probably need a new instance like you are doing. 

 

As far as the config scripts go, the biggest issue I had was I misread the prompt about installing VNC/ssh on regular port.  I answered N to that and should have left it Y.  I was distracted and doing multiple things at the time and I think when I read it I thought it was asking if I wanted VNC installed, which is why I answered No.  I wasn't paying attention, which is really on me.  But, somehow the ssh port got set to "-100" which meant sshd wouldn't start...it took me a while to figure that out. Although had it gotten started on an odd port it probably would have taken even longer to find.

 

(I pass no judgement on those that decide to run ssh on different ports.  Obscurity can be one layer of security.  I think there are much more important layers, but to each their own.)

[tiguana]

Can you tell me what version(s) of the ISY firmware this is supposed to work with?

I'm having zero success with version 5.0.11C

 

Thanks.

[Screw Loose Dan]

I believe it's only been tested on version prior to 5. 

What errors are you seeing?  Some logs to look at:

• /home/pi/Console/Console.log        # this is the main log, presuming the process gets started.
• /home/pi/earlyprep.log          # I believe this is only used during installation
• /home/pi/prep.log                  # I believe this is only used during installation
• /home/pi/log.txt
• /var/log/syslog        # this captures the logs as the service starts.
• journalctl -u softconsole.service    # Run this on the command line, and it will show the same as what is in syslog, but only for the softconsole

[tiguana]

The only entries that seem to be useful are in syslog:

I've attached the relevant portion of that file.

Hope it helps identify what's wrong.

 

errors.txt

[Screw Loose Dan]

I'll admit, I'm a bit out of my league.  Kevin (kck) developed this code, I'm sure he'll have more insight, and I'm sure the log will help him narrow things down.

Are you using a basic/minimal configuration just to see if you can get it working?  

My best guess is that the code is choking on the format of the response from the ISY for a particular device while it's enumerating the list of devices, but that doesn't really help you fix it. 

[tiguana]

I've tried the minimal configuration and several of the other sample configs.

The only way I've managed to get it to actually run is to not load the authcfg.cfg module but ... that kind of defeats the whole purpose of the thing.

[kck]

Just got back online from some travel, hence the slow response.  The console has been primarily tested against the 4.x releases since I am not running 5.x.  However, there was one user a while back who ran it against a 5.x release ok once I added support for a change in how certain values get reported to the console by the isy in 5.x that differed from 4.x.  However, I don't think anyone has tried running against an ISY with a nodeserver in the mix.  I suspect you may have one?  It appears that the ISY is reporting a strange looking address of a device that I am guessing may be a node server because the address looks like a MAC address of some sort.  If you look at your ISY what device does the address "00:21:b9:02:00:b3" correspond to and is it something other than a standard Insteon device?  From the log you provided it looks like that device is part of a scene and when I try to construct the internal data structure that represents that scene the device isn't already in my data structures.  That shouldn't occur for any Insteon device because I have already read all of those.  So I am guessing that there are some other node types now in the 5.x firmware that require a different type of read.  If I can figure out what they are and how to read them I can probably fix this.  Otherwise I suspect I can just catch this and ignore the device.  So long as you don't try to have a console button that uses it that should be ok (using it just wouldn't do anything).  The other restriction from this may be that you can't use such a device as the proxy for the scene since I don't necessarily know how to get its state.  Anyway, it you can tell me something about what that device is maybe I can figure something out.

Kevin

[tiguana]

Hi Kevin

 

I'm not using any node servers.  I have nothing but Insteon devices in my house.

That link may possibly be a "dead link" left over from some failed experimenting perhaps.

Unfortunatly fro me I'm a few thousand miles away from my house till Sunday.

I'll dig up more info for you then.

 

Dave.

[chrisb5]

Just tried another install myself and seeing some odd behavior. Trying the https: connection to my ISY and a 3.5 TFT display; after going through most of the install dialog got the following. Note that no where in this output did the program actually allow me to enter anything though it looked like it was supposed to wait for input for the display configs?

I haven't tried starting anything after this since i'm not sure what it failed to install? Any log I can examine?

Here's the output (forgot to increase screen memory in my PuTTY session so here's just the end of the dialog but it shows the error messages)::

HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://raw.githubusercontent.com/adafruit/Adafruit-PiTFT-Helper/master/adafruit-pitft-helper [following]
--2018-02-27 22:11:25-- https://raw.githubusercontent.com/adafruit/Adafruit-PiTFT-Helper/master/adafruit-pitft-helper
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|151.101.200.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 12048 (12K) [text/plain]
Saving to: ‘adafruit-pitft-helper’

     0K .......... .                                          100%  920K=0.01s

2018-02-27 22:11:26 (920 KB/s) - ‘adafruit-pitft-helper’ saved [12048/12048]

--2018-02-27 22:11:26-- https://raw.githubusercontent.com/adafruit/Adafruit-PiTFT-Helper/master/adafruit-pitft-helper2.sh
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 151.101.200.133
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|151.101.200.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 16938 (17K) [text/plain]
Saving to: ‘adafruit-pitft-helper2.sh’

     0K .......... ......                                     100%  819K=0.02s

2018-02-27 22:11:26 (819 KB/s) - ‘adafruit-pitft-helper2.sh’ saved [16938/16938]

----------------------------------------------------------
----------------------------------------------------------
Run PiTFT Helper 35r
Tue Feb 27 22:11:26 EST 2018
----------------------------------------------------------
----------------------------------------------------------
This script downloads and installs
PiTFT Support using userspace touch
controls and a DTO for display drawing.
one of several configuration files.
Run time of up to 5 minutes. Reboot required!

Select configuration:
1. PiTFT 2.4", 2.8" or 3.2" resistive (240x320)
2. PiTFT 2.2" no touch (240x320)
3. PiTFT 2.8" capacitive touch (240x320)
4. PiTFT 3.5" resistive touch (320x480)
5. Quit without installing

SELECT 1-5: Select rotation:
1. 90 degrees (landscape)
2. 180 degrees (portait)
3. 270 degrees (landscape)
4. 0 degrees (portait)

SELECT 1-4: [PITFT] Checking init system...
Found systemd
/boot is mounted
[PITFT] System update
Updating apt indexes...
.........
Reading package lists...
.........
[PITFT] Installing Python libraries & Software...
Installing Pre-requisite Software...This may take a few minutes!
Reading changelogs...
./adafruit-pitft-helper2.sh: line 145: warning: command not found
[PITFT] Exiting due to error: Unable to install software
Created symlink from /etc/systemd/system/default.target to /lib/systemd/system/graphical.target.

----------------------------------------------------------
----------------------------------------------------------
Reboot now installconsole.sh will autorun as root unless aborted
Tue Feb 27 22:16:16 EST 2018
----------------------------------------------------------
----------------------------------------------------------
Install will set Personal N and AutoConsole N

----------------------------------------------------------
----------------------------------------------------------
Chose to manually reboot and run installconsole.sh
Tue Feb 27 22:16:16 EST 2018
----------------------------------------------------------
----------------------------------------------------------
 

[kck]

That's very strange.  I just did a clean install to see if I could reproduce and my install ran completely normally.  It almost looks like you got a different helper2 script from adafruit (I just use their install stuff) or that the script got corrupted.  I did notice that your download of the script came from a different IP address but I assume that is just github having multiple servers.  In my script it appears line 145 is a pip command which is a standard python command.  FYI - the log from your run of pisetup should be in earlyprep.log in the pi home directory so you can look at it without staring at a putty or other screen.  I am attaching the earlyprep.log from my run just now and also the helper2 script.  You might diff the latter to see if yours is different or at least look at line 145 to see what yours barfed on.

The places where it looks like input was requested are fine.  I create the answers to those questions based on your earlier inputs or softconsole requirements and feed the answers to the helper2 script so in the log you see the questions but not the answers that my pisetup script has supplied.  Let me know if you find anything when you look at this again.

earlyprep.log

adafruit-pitft-helper2.sh

[kck]

V2.7 is now available as the current release.  This version primarily adds better weather display (thanks to Screw Loose Dan for suggestions and test assistance).  There is an option for 2 column display of the forecast which works really nicely on the 7" display.  Also, you can now have the icons for the weather displayed for the current conditions and the forecast.  While the impetus for adding this was the larger display format, it turns out to look really good even on the 3.5 inch display which surprised me.

There are also a number of small bug fixes and internal improvements in handling wifi outages, install prompts, etc.

For tiguana's problem above I have attempted to deal with scenes that have unknown nodes in them (which I don't think should normally occur in the ISY database) by logging the anomaly and continuing.  I have also added a general ability to dump what I am getting from the ISY at startup so in the future I can more easily try to diagnose any issues that folks might see.  I hope that benefits both me and users in getting quicker fixes to problems. 

[Screw Loose Dan]

Kevin - Just wanted to let you know I've been using the stable and everything appears to be working as expected.  I probably had tested most of it in beta, but figured I would let you know that the stable appears good.  And, I now have the degree symbol (°) on my TimeTemp screen.