Soft Keypadlinc-like Console from Raspberry Pi

[EVictory]

PS: One last note.  Yesterday (10/26/2019) we lost utility power for over 14 hours and my house was running on a whole-house generator.  I know generator power causes problems with insteon powerline communications.  This probably contributed to exception errors on the 26th.  I do not think this is related to the console upgrade I did earlier today.  The console was working correctly before the upgrade except for the APIXU weather.

[EVictory]

Just saw that you will be traveling until next Sunday.  This can certainly wait until you get back.  I will also be very busy this week with work so would not be able to respond much during the week.

Thanks for a great program.

[kck]

The problem looks like it is with that failure to find the darksky module.  It is essentially causing a compile error.  The install scripts for the current release should have installed that library so it should be there so I don't know why it isn't.  As a fix you can try going to the Pi console and running the command:  sudo pip3 install darksky_weather   You should see a Python library get installed with no final error.  Then try running the console from the command line and see if it comes up.  I am particularly surprised about this failure since most of my consoles got updated via the normal script and didn't have this issue.  I understand that my development console is different since I need to manually install any new libraries there and so can have it working even though normal ones would have this kind of failure.  In any case, if this fixes it I'll have to poke a bit on why the upgrade didn't do it in the first place to make sure no one else bumps into this.  If it doesn't fix it, then I'll look at whatever other error causes the failure.

[EVictory]

Kevin,

Manually installing the darksky module appears to have fixed the problem.  I was able to manually start the console.  The weather module is working again.  Thank you so much for your help.  Your support of SoftConsole is top notch!

-Emile

[kck]

Great.  When I get a  chance I'll look at those other log messages to see how I can suppress them.  You shouldn't wind up with a overrun log like that because then you'll miss something of note.  Just out of curiosity, it the system you had the issue with a Buster system and if so, was it a clean install or an upgrade from Stretch.  Just trying to understand why the auto install of that library didn't happen.  (No rush answering since I'm out east all this week.)

[EVictory]

I have no softconsoles running buster yet.  

[kck]

I just pushed an update to V3.6 that now allows dynamic screen titles (to show e.g., time or current temps or whatever) as well as consistent navigation 
of the Maintenance screens.  Release blurb below.

V3.6
This release adds two major capabilities and handles a number of smaller issues/bugs.  The first major change is to allow store item values to be substituted 
in screen titles.  This permits any screen title to display, e.g., a local temperature or some other value of interest.  To support this a new optional parameter 
ScreenTitleFields is added that expects a list of fields to be substituted.  ScreenTitle now supports Python style formatting placeholders into which the fields 
will be substituted.  If the screen is one that would persist for a long period of time but you want it repainted regularly to display field value changes you 
can now specify a parameter Clocked = <seconds> which will cause a repaint every <seconds>.  Usefully related to this are entries in the System store for 
Time and UpTime.  Time returns the epoch time if used bare or may be used in a form Time:<format> string to return a textual time using standard Python/Unix 
time formatting strings.  This guarantees that changes to substituted fields in the title will be refreshed at this interval.  For an example of using this 
to display temperatures see example file config-rpi-dev7.txt, specifically the section for LR1 or the cfg file for pgawBRmain.

The second major change to how navigation works for Maintenance screens.  These have always used a different style of navigation that regular screens (not 
using the Nav keys at the bottom).  These have been changed to use tree of screens model introduced in release 3.4 to use Home and Back keys for navigation.  
This makes exit from maintenance always easy (Home key) and return to previous screen consistent (Back key).

The release also updates support to handle the new version of Home Assistant climate devices (Thermostats) that was introduced there a while back.  It will 
still support the old climate devices for now using the hub type HASS.0 (or since the 0 is a version value that defaults to 0 just HASS) and the new style 
using the hub type HASS.1.  The release also has fixes for a number of small bugs and does some general housekeeping on error and log messages.

[kck]

DarkSky was acquired by Apple on April 1 and announced that their api will shut down end of next year (and I think that new api keys are no longer available even now).  So I have updated the console with a new version that additionally supports Weatherbit as a provider.  Documentation also has been updated to note this (and its location and units options).  The release is up as V3.6.1:

This release adds support for Weatherbit as a provider. This is to provide an alternative to DarkSky which announced ending it service in 12/21. Use type=Weatherbit for this provider. This provider supports an additional option units = 'I' or units ='M' to request Imperial or Metric reports. If omitted it defaults to Imperial.

[EVictory]

Kevin,

This morning I attempted to upgrade one of my three softconsoles to the latest v3.6.1.  I believe my previous version was v3.5.1.  I selected Download Stable from the maintenance screen and button briefly changed color.  I left the console alone for a quite while to give it time to download but it never responded.  I eventually manually rebooted it.  Now, the softconsole will not start.  I logged into RPi using Putty and attempted to manually start the soft console.  I have included a screen shot of errors shown in Putty. Below are the last 8 entries from the console.log file.  It shows my fetching new version as the last entry. 

05-16-20 09:49:51 Sev: 3 Long term: Humid and Partly Cloudy generically shortened to: Humid&Partly Cloudy
05-16-20 09:49:51 Sev: 4 Long term: Mostly cloudy throughout the day.
05-16-20 09:53:07 Sev: 4 ISY Extra info in event: ST/Status/139/1D 6D 8C 1/NoneOrderedDict([('fmtName', 'Temperature')])
05-16-20 10:40:18 Sev: 4 Long term: Mostly cloudy throughout the day.
05-16-20 11:07:32 Sev: 3 ISY: busy for 22.1313 seconds
05-16-20 11:30:44 Sev: 4 Long term: Mostly cloudy throughout the day.
05-16-20 11:36:03 Sev: 3 Entering Console Maintenance
05-16-20 11:36:33 Sev: 3 New version fetch(currentrelease)
 

I am not sure what happened but it looks like it hung attempting a download.  Do you have any ideas on how to recover?

[kck]

That's odd since it isn't something that has changed in a long, long time (if ever).  Wiringpi is a library that gets used to handle dimming the screen for some screens.  Should have been there if your system needed it for any previous version.   Which screen do you use?  I don't recall.   Here are a few things to do:

1. At a console prompt type pip list.  Near the end of the list it outputs you should see a line for wiringpi with a version number.  Mine shows 2.60.0  - what is yours?

2. If it isn't 2.60.0 you should be able to update it via the command:

sudo pip install --upgrade wiringpi

3. I noticed an extra character in the screendefinitions file on github that looks like it has been there since last August.  I don't think it should impact you unless you are running a Pimoroni screen but in any case if you are go to consolestable and edit the file screendefinitions to delete the "s" in the middle of PWM19.  I can't understand why that would cause your symptom in any case.

Wiringpi is a raspberry pi library that provides access to the GPIO pins on the board.  I only use it to adjust brightness on some screens.  From my perspective it is a black box and the error makes it look like it imported wiring pi but that the module is missing one of its methods.  No idea how that could even happen.

I did notice one other thing though.  The log of your download doesn't look complete.  After that message New version fetch, there should be another message: Staged version installed in consolestable.  If you didn't just cut off the log, then you didn't let the download actually finish.  When you say, you manually rebooted do you mean the Pi?  That could leave things in some indeterminate state.  You should start the download from the maintenance screen.  Then you should do the console restart from the Exit/Restart screen in Maintenance.  So long as the download is still in progress hitting restart console and then proceed will just quickly flash the  restart button and return you to the restart screen.  Once the download completes then proceed will get you a red screen indicating that you requested a restart and it should.  If you did break something with that reboot, there is a script in consolestable called domanualdownload.py.  You can try that by going into the consolestable directory and then running sudo python ./domanualdownload.py.  That should grab the current version on github and install it.

Let me know if this helps?

By the way - if you move to Weatherbit and run multiple consoles, be aware that they effectively limit you to 250 weather refreshes per day (a refresh there is actually 2 API calls and they give you 500).  If you get weather for multiple locations on 3 systems you'll hit the limit at more then 3 locations if you are refreshing once per hour.  I am in the process of enhancing the MQTT based multi-console support to allow the consoles to share weather for locations which will mean that the number of consoles shouldn't increase the number of weather fetches over a single console.  I'm running a version of this in my house now since limit impacted me.  I'll probably push it in the next week or so once I know it is solid.

[EVictory]

Kevin,

Thanks for your response.  Sorry for the delay. 

1. This SoftConsole has RPi 2 Model B v1.1, an Adafruit PiTFT 3.5" touchscreen, a PiFace Shim real time clock, and a USB WiFi.  Raspbian is Stretch.

2. wiringpi is 2.60.0

3. The fetch line is the last line in the comsole.log file.  This looked odd to me as well.  It is as if the updated started but never finished.  It may have hung during download.  I started update from the maintenance screen.  Then left it and went into kitchen, got coffee, talked with wife, etc.  When I came back to console about 10-15 minutes later, the console was unresponsive.  That is, it would not respond to touch.  That is when I removed power, counted to 10, restored power.  Not sure what happened.  We did have a power outage two nights ago where whole house generator ran for about 2 hours to provide power.  I have noticed that sometimes electronics do not like generator power.  At any rate, I do think something happened during update where it never finished.

4. Tried sudo python ./domanualdownload.py and it showed sha already matches.  Tried sudo python -u console.py again but still get black screen.  I notice the screen is black (not powered) as opposed to lit but displaying black where you can still see light behind screen.  On power up, the screen does light up and displays raspbian X GUI briefly. 

5. I am still using darksky.  I have three softconsoles but all three show same weather data.  I have not played with MQTT yet.  What are you using for MQTT server?

 

[kck]

OK - standard configuration so that should all be good.

Did you still get the same wiringpi error when you did the run of the console?  I assume you did since the "sha" message would indicate that the manual download didn't do anything.

I think it is still wise to force a manual download to know it got staged/installed completely.  First thing I'd suggest is to save your previous version.  There is a directory in consolestable called previous previousversion.  Save that by doing a sudo mv previousversion ~  That should move that directory up to your home directory so you have it.  Next delete the versioninfo file in consolestable.  That will force domanualdownload to not see the download as pointless and cause it to actually do it.  You should then see the following:

Install from: /home/pi/consolestable
Couldn't get version info, assuming currentrelease
Current hub version different
Running (currentrelease): none of none
Getting: c2ba46d5dc11e6b68c8e9e2db07d3b8724cd7391 of 2020-04-27T18:58:30Z
Staged version installed in /home/pi/consolestable
 

There may be a substantial delay because especially on a Pi2 there can be a bunch of library updates going on here that can take a while.  After this completes there should also be a file in the consolestable/previousversion (note that this is a new previousversion from the one you moved and contains the probably bad download) directory called stagelog.log that has more detail on the install.  Just for reference I'm attaching the stagelog that I just got from running this process on an old system I had laying around and not in use.  I ran this and it worked fine on the test system which was a Pi3B running Stretch with an Adafruit PiTFT3.5.  For reference the start of the Console.log file for this system was:

05-17-20 13:04:28 Sev: 3 Soft ISY Console
05-17-20 13:04:28 Sev: 3   © Kevin Kahn 2016, 2017, 2018, 2019, 2020
05-17-20 13:04:28 Sev: 3 Software under Apache 2.0 License
05-17-20 13:04:28 Sev: 3 Version Information:
05-17-20 13:04:28 Sev: 3  Running under Python: 3.7.3 (default, Apr  3 2019, 05:39:12) 
[GCC 8.2.0]
05-17-20 13:04:28 Sev: 3  Run from: /home/pi/consolestable
05-17-20 13:04:28 Sev: 3  Last mod: /home/pi/consolestable/alerts/lightsensor.py
05-17-20 13:04:28 Sev: 3  Mod at: Sun May 17 12:47:17 2020
05-17-20 13:04:28 Sev: 3  Tag: currentrelease
05-17-20 13:04:28 Sev: 3  Sha: c2ba46d5dc11e6b68c8e9e2db07d3b8724cd7391
05-17-20 13:04:28 Sev: 3  How: Offline Dnld: 05-17-20 12:46:11
05-17-20 13:04:28 Sev: 3  Version date: Commit of: 2020-04-27T18:58:30Z
05-17-20 13:04:28 Sev: 3 Start time: Sun May 17 13:04:27 2020
05-17-20 13:04:28 Sev: 3 Console Starting  pid: 1571
05-17-20 13:04:28 Sev: 3 Host name: rpi-test
05-17-20 13:04:28 Sev: 3 Screen type: 35rB
05-17-20 13:04:28 Sev: 3 (Display device: /dev/fb1 Driver: fbcon Dim Method: PWM18)
05-17-20 13:04:28 Sev: 3 Touch controller: stmpe-ts
05-17-20 13:04:29 Sev: 3 (Capacitive: False Shifts: x: 0 y: 0 Flips: x: 0 y: 0 Scale: x: 1.0 y: 1.0)
 

 

As always let me know if this helps.

 

Kevin

P.S.  I run mosquitto as my MQTT broker.  Had been running it as a native install but just recently move to running it under Docker since that helps a bit with maintenance.  If you run a broker and tell your console about it, you'll be able to manage any of them from any other and once you move to Weatherbit you'll get shared updates which as I said will help keep you below their fetch limits (coming soon).

stagelog.log

Edited May 17, 2020 by kck

[EVictory]

Kevin,

I moved the previousversions directory, deleted the versioninfo file, and manually downloaded again.  As expected, the download worked this time.  I received the on-screen messages you indicated and have attached the stagelog.log file from the new previosversions directory.  However, when I try to start softconsole I get the same messages on screen about wiringpi has no attributes (see attached screen shot).  The Console.log file remains unchanged since yesterday, so I do not think softconsole is getting far enough to initialize it.

All throughout stagelog.log file there are notes about pip.  Also, I do not use a homeassistant.

You are using pip version 10.0.1, however version 20.1 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.

Should upgrade pip?

I will look into setting up a pi with mosquitto.

 

stagelog.log

[kck]

Seriously weird!  

Just to see if something is broken in Python libs run at a command prompt "python".  This should give you an interactive Python prompt.  At this prompt type "import wiringpi" - should return another prompt. Now type: "wiringpi.wiringPiSetupGpio()" (case matters so be careful with that).  It should return 0 and another prompt.  If it does that is wiringpi working with the attribute that the log claims is missing.  If this works I'm really stumped because that is the identical code to what is running in the console hw.py module. If it doesn't work type "dir(wiringpi)" which should list all the attributes of wiringpi - there should be lot of them - 203 to be exact apparently.  If you type "len(dir(wiringpi))" it should say 203.  Finally, typing wiringpi.__file__ should give a file name of where it was loaded from.  (Remember this in case you decide to do the option item at the end.)

In any case, you might try uninstalling/reinstalling wiringpi to see if that helps.  First off I would upgrade your (shouldn't matter but always good to be at least close to current) pip via:

sudo pip install --upgrade pip

Then uninstall wiringpi with:

sudo pip uninstall wiringpi

This may ask you to proceed.  When it finishes (it's quick) it should say is did its work successfully.  At this point if you were to do the python/import/etc. from above Python should say there is no wiringpi module - you might check.  Then reinstall it with

sudo pip install --no-cache-dir  wiringpi

The no-cache-dir will force pip not to use any cached version on your system, just in case.  You should see it say it is downloading and then it will do the install.  By the way, you can do a:

sudo pip uninstall homeassistant

to get rid of those other messages, although they should be benign.  That lib dates from quite a while back and is not longer in use anywhere.

If none of this works I'm close to out of ideas.  What you are seeing doesn't really seem to have anything to do with the softconsole code but rather with something that has gotten messed up on the system.  If all this fails to tell us anything you  may need to rebuild the pi.  But if you want to try one more bit of debugging first (extra credit assignment)  you can go into consolestable and edit the file hw.py to insert the following:

with open('/home/pi/check', 'w') as f:
   f.write('{}\n'.format(wiringpi.__file__))
   f.write('{}\n'.format(dir(wiringpi)))
   f.write('{}\n'.format(len(dir(wiringpi))))

after what should be line 103 which is a line that starts DimType = screendefs[ . . . and before the following line which is if DimType . . .  The with should be aligned with the previous and following lines and the 3 other lines tabbed in to align with the first line in the following if statement.  Python is very picky about alignment.  If you do this and run the code you should get a file in your home directory called check that will show precisely what the use of wiringpi in the console looks like and perhaps we can figure out from that what the problem is.  As I said this is optional to rebuilding but might be worth a try.  The check file should show exactly where console is loading the module from (maybe there are somehow 2 version of it on your system) and what is in it.  It should show the same file name that you saw up top from the independent python run.

Really sorry I'm not being more helpful - this has me really scratching my head.  Python is generally very predicable but it is a really complex language from an implementation point of view and I have seen it do some strange things.

Edited May 18, 2020 by kck

[EVictory]

Kevin,

The dir(wiringpi) returned a short list and len(dir(wiringpi)) returned 8.  So, wiringpi was corrupt.  Uninstalling wiringpi and reinstalling it fixed the issue.  After reinstalling wiringpi, there were 203 items returned by dir(wiring).  I did update pip and removed homeassistant as maintenance measures.  After all of this, I was able to start SoftConsole!!!  Thanks so much for your help. 

I think SoftConsole is a great piece of software.  I will be retiring in about two months.  After retirement, one of my projects is to rework all of my SoftConsoles where I rethink all of the screen layouts and leverage MQTT. 

Below are two pics of my control center in the utility room.  At the top is an 8-port network switch, the ISY, and network patch panel for incoming network.  At bottom is modified PC power supply and home brew power distribution for ISY, network switch and all the RPis. 

In middle (shown below) are three RPis.  One on right is my Ubiquiti wireless access point controller.  The second RPi from right has PolyGlot installed.  The third RPi has an RPI3 1-Wire Host Adapter hat (Sheepwalk Electronics) installed.  On the third RPi I run NodeLink by Automation Shack.  I have 1-wire temperature and humidity sensors installed in bathrooms, in the attic, under the back porch, etc.  NodeLink makes these values available in ISY.  I can add several more RPis to the right and second from right positions by stacking them.

[kck]

I just updated the Console to V3.6.2 to better support Weatherbit weather.  The service permits 500 API calls per day but it takes 2 calls to get current and forecast conditions.  Thus if one runs multiple consoles with multiple weather locations it is possible to hit the limit in which case you won't get new data until the next day.  This updates fixes this by allowing consoles on a network to share data with each other to avoid redundant fetches.  Other than requiring MQTT in the configuration, the operation of this caching is not visible to the user - i.e., no need to pick which console does the fetch as whichever one needs the data first handles it.  Release blurb from github:

 

Quote

V3.6.2
This release adds support for multiple consoles on a network to share Weatherbit data so as to reduce the number of daily calls to the service. Provided that the consoles are running MQTT, they will broadcast their weather fetches to caches in other consoles. If a recent update exists in its cache, a console will use that data rather than doing its own fetch. Thus, e.g., if the consoles are all set to update weather for a location once per hour, only one of them will actually do a fetch from the service while the others will see that data appear in their caches without an explicit fetch. This helps limit the use of the service calls which for free accounts are limited to effectively 250 current/forecast calls per day. As part of this update, error messages around weather fetch errors have been cleaned up.

 

Edited May 22, 2020 by kck

[EVictory]

Kevin,

I have had a Softconsole running for several years using a 7" touchscreen from the raspberry foundation.  My screen connects to the RPi with a flat ribbon cable and it is in landscape mode.  The micro SD card in this softconsole died (ie, became unreadable).  Therefore, I have been attempting to build the softconsole from scratch using a new SD card and the latest version of buster.  I am having trouble getting the softconsole to run correctly and it appears to have something to do with the 7" screen.  I have ran pisetup twice now with the same results.  The 7" screen shows the desktop while booting but either continues to show the desktop are goes dark, once softconsole starts. 

If I do a 'sudo systemctl status softconsole', the service appears to be running. (See below).  No Console.log file is generated.

pi@console-22:~ $ sudo systemctl status softconsole
● softconsole.service - SoftConsole
   Loaded: loaded (/usr/lib/systemd/system/softconsole.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2020-07-21 22:44:24 CDT; 1s ago
  Process: 1702 ExecStartPre=/bin/sleep 5 (code=exited, status=0/SUCCESS)
  Process: 1703 ExecStart=/home/pi/consolestable/runconsole.py (code=exited, status=0/SUCCESS)
 Main PID: 1704 (python3)
    Tasks: 1 (limit: 2068)
   CGroup: /system.slice/softconsole.service
           └─1704 python3 console.py

Jul 21 22:44:18 console-22 systemd[1]: Starting SoftConsole...
Jul 21 22:44:24 console-22 softconsole[1703]: Starting using directory: consolestable
Jul 21 22:44:24 console-22 systemd[1]: Started SoftConsole.

I then stopped the service and attempted to manually start the softconsole as shown below.  After both attempts to install with pisetup, I got the 'touchscreen device cannot be found' error and also the file not found error for the .HistoryBuffer/hlog file.  During the pisetup questions, I specified a pi7 screen with the power connector on top (flipped screen).  When the 7" screen does show the desktop, it is flipped as requested.   

pi@console-22:~ $ sudo systemctl stop softconsole
pi@console-22:~ $ sudo python -u ./consolestable/console.py
pygame 1.9.4.post1
Hello from the pygame community. https://www.pygame.org/contribute.html
07-21-20 22:46:17 Console ( 1764) starting in /home/pi/consolestable
Traceback (most recent call last):
  File "./consolestable/console.py", line 182, in <module>
    utilities.InitializeEnvironment()
  File "/home/pi/consolestable/utilities.py", line 107, in InitializeEnvironment
    ts = Touchscreen(os.path.dirname(config.sysStore.configfile))
  File "/home/pi/consolestable/touchhandler.py", line 160, in __init__
    self._f_device = io.open(self._touch_device(), 'rb', self.EVENT_SIZE)
  File "/home/pi/consolestable/touchhandler.py", line 308, in _touch_device
    raise RuntimeError('Unable to locate touchscreen device')
RuntimeError: Unable to locate touchscreen device
exitlogging
07-21-20 22:46:17 Exiting with history trace (0)
07-21-20 22:46:17 Suppressing History Buffer Dump for Exit Trace
Process AsyncLogger:
Traceback (most recent call last):
  File "/home/pi/consolestable/logsupport.py", line 225, in LogProcess
    with open('/home/pi/Console/.HistoryBuffer/hlog', 'a') as f:
FileNotFoundError: [Errno 2] No such file or directory: '/home/pi/Console/.HistoryBuffer/hlog'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
    self.run()
  File "/usr/lib/python3.7/multiprocessing/process.py", line 99, in run
    self._target(*self._args, **self._kwargs)
  File "/home/pi/consolestable/logsupport.py", line 253, in LogProcess
    with open('/home/pi/Console/.HistoryBuffer/hlog', 'a') as f:
FileNotFoundError: [Errno 2] No such file or directory: '/home/pi/Console/.HistoryBuffer/hlog'
pi@console-22:~ $

Do you have any idea what I am doing wrong?

-Emile

Edited July 22, 2020 by EVictory

[kck]

Doubt you are doing anything wrong - looks like something is different about how Buster is setting things up.  The console is looking for the touch device.  This should be at /sys/class/input/event0 which would be a directory.  (Actually could be in an event? if there are more than one - it looks at them all.)  Within that directory there should be a device/name which is a string that defines the type of handler.  That gets matched against an entry in the file touchdefinitions in the consolestable directory to get the needed parameters.  I actually run a 7" Pi screen as my standard development system so I can check to see what the current Buster does.  In the meantime, can you check what a cat of the device/name file shows and also cat the touchdefinitions file to see if there is a corresponding entry there?  Also, what Raspbian release are you using?  The current one dated 2020-05-27?  I'll gen up an install with that version and see if something changed there.  BTW - the other exception for hlog is just a side effect of a very early in the program failure.  I should probably catch all that and exit more cleanly.  Setting up the hardware is about the first thing the program does so things aren't very clean for exit at that point.

 

Kevin

[kck]

Emile,

As I guessed neither you nor I did anything wrong.  The Raspbian folks just "improved" support for their touchscreen.  In the process they changed the name of the device so I wasn't matching on it.  Not sure when it happened - sometime between last July and now I think since my existing Buster version had the old naming.  Good news it that it is a very easy fix for you (and I'll update it for the next release).  Go into consolestable and find the file touchdefinitions.  Duplicate (or just edit) the line starting with FT5406 memory based driver and replace that string with "raspberrypi-ts".  The new or edited line should appear as:

raspberrypi-ts|True|0|0|0|0|1.0|1.0

That should get things working since the program will then understand what type of touchscreen it is dealing with.  Let me know if that fixes it for you.

 

Kevin

[EVictory]

Kevin,

That fixed it.  I added a line to the touchdefinitions file containing the new definition.  

Having been in IT for many years, I am well aware how 'updates' can have unintended consequences.  

Thanks for your quick help.

[EVictory]

Kevin,

I am working on re-doing all of my consoles to use Buster (instead of Stretch) and the latest version of SoftConsole.  To this end, I upgraded my oldest console with a Raspberry Pi 3 B+ to take advantage of the built-in wi-fi.  (The USB Wi-Fi adapter I was previously using on the model 2 Pi was not not working every now and then.)  I installed SoftConsole from scratch using pisetup.sh.  I found the Adafruit 3.5" screen was not configured correctly upon completion. 

I got it working by referring to old documentation I had and to another SoftConsole also running an Adafruit 3.5" touchscreen.  However, I thought you may be interested in what I found.  During the pisetup questions, I indicated I wanted a 35r touchscreen.  However, after setup finished the /boot/config.txt file contained the following:

# --- added by adafruit-pitft-helper Thu 23 Jul 2020 10:20:27 PM CDT ---
dtparam=spi=on
dtparam=i2c1=on
dtparam=i2c_arm=on
dtoverlay=pitft28-capacitive,speed=64000000,fps=30
dtoverlay=pitft28-capacitive,rotate=0,touch-invx=true,touch-invy=true
# --- end adafruit-pitft-helper Thu 23 Jul 2020 10:20:27 PM CDT ---

To get the SoftConsole to work with the 3.5" screen, I changed this to the following as this is what was used on my working 3.5" SoftConsole.  I decided to just comment out the original dtoverlay lines.

# --- added by adafruit-pitft-helper Thu 23 Jul 2020 10:20:27 PM CDT ---
dtparam=spi=on
dtparam=i2c1=on
dtparam=i2c_arm=on
dtoverlay=pitft35-resistive,rotate=0,speed=20000000,fps=20
#dtoverlay=pitft28-capacitive,speed=64000000,fps=30
#dtoverlay=pitft28-capacitive,rotate=0,touch-invx=true,touch-invy=true
# --- end adafruit-pitft-helper Thu 23 Jul 2020 10:20:27 PM CDT ---

I think the pisetup program may not be handling the 3.5" screen setup correctly.  Thought you might want to know.

PS: I noticed you had the 2.8" screen using a speed of 64000000 and frames per second of 30.  What is the best  speed and fps settings for a 3.5" screen?  Am I missing anything?

-Emile 

Edited July 24, 2020 by EVictory

[kck]

Arg.  Another case where stuff changed under me.  The script uses the Adafruit install scripts for the screens.  Those scripts have never been friendly to being used by another script since they only take interactive input.  Why folks don't write such utilities to have a stable scriptable interface is beyond me.  So pisetup fakes the interactive input to the script and -- you guessed it -- they recently changed the input codes for no real reason (they added another supported screen to their script but decided to put it in the middle of the selection choices instead of at the end).  I'll update my scripts and perhaps I can figure out how to make it more resilient to their changes.

As to the speeds etc.  - I don't know.  They all come from the aforementioned install script so that comes from Adafruit.

Thanks for catching this, figuring it out, and alerting me.

Kevin

[kck]

I just pushed V3.6.3 to github with changes to installation to fix the problems noted in the previous few posts due to changes in Buster treatment of the Pi 7" screen and the Adafruit install scripts for the PiTFT screens.  The release note on github:

This release fixes some installation issues caused by changes in the underlying OS release support for the Raspberry Pi 7" screen and the Adafruit installation scripts for the PiTFT 3.5" and 2.8" screens. The fixes are also a bit more resilient against future changes that might occur to such scripts. While ultimately it is impossible to guarantee compatibilty with any future changes, at least the errors raised may more directly point to the problem so that it can be quickly resolved. The installation process also now gets all the user interaction done before anything else so that the long running part of the scripts that update the OS can be done unattended.

The release also fixes a bug with blinking keys on clocked screens where the blinking didn't show up and a bug where a bad weather fetch from Weatherbit could pollute the weather info cache for a fairly long period of time. Some of the periodic statistics reporting in the log file has also been revised.

[iamtheghost]

Just dropping a line to say that I love this project and I hope you never remove it from the web. I don't use ISY-994, but I do plan on creating 3-4 of these for my HomeAssistant system one day in the future when I have fewer projects. Incredible work!

[kck]

It will stay on the web.  Additionally it is, of course, open source so anyone who wants to can copy or mod it or add to it as they wish.

I run my consoles extensively with Home Assistant but I'm not sure who else does.  So the HA stuff has probably had less diverse use and is therefore likely to have a few more bugs.  If you start using it with HA by all means report any issues or suggestions so that I can look at them.