Soft Keypadlinc-like Console from Raspberry Pi

[gaetanlord]

I play a little more on this. After a reboot I tried again, and a kill does return the window manager as expected.

But I still wonder if there is a way to have an exit button. Note that I haven't read completely the usage note and it might already be possible to do it

 

I forgot to mention that I have the following input device and tried all of them

crw-rw---- 1 root input 13, 66 Dec 28 01:01 event2

crw-rw---- 1 root input 13, 63 Dec 28 01:01 mice

crw-rw---- 1 root input 13, 33 Dec 28 01:01 mouse1

 

I also have message like this in Xorg log file

 [  1555.592] (II) input device 'FT5406 memory based driver', /dev/input/event2 is tagged by udev as: Touchscreen

[  1555.592] (II) input device 'FT5406 memory based driver', /dev/input/event2 is a touch device

 

This seem consistent with the device I have when I look at 

cat /proc/bus/input/devices

 

I: Bus=0000 Vendor=0000 Product=0000 Version=0000

N: Name="FT5406 memory based driver"

P: Phys=

S: Sysfs=/devices/virtual/input/input2

U: Uniq=

H: Handlers=mouse1 event2 

B: PROP=2

B: EV=b

B: KEY=400 0 0 0 0 0 0 0 0 0 0

B: ABS=2608000 3

 

I also tried the following driver

https://github.com/pimoroni/python-multitouch

The example work and I could use the touchscreen

 

 

[kck]

There is an exit console option under maintenance.  Tap screen 5 times to get to maintenance and you'll find options to restart or exit the console or reboot or shutdown the Pi.  If the screen is a touchscreen I would think the console should see that.  The console does run native on the screen - it doesn't use X-windows.  The console just uses the pygame touch handling stuff which is fairly generic.  It can be a bit touchy (no pun intended) though because it needs to use an older version of the low level libraries.  You can see that those get downgraded as part of the install scripts.  All the code for the console is, of course, there on your system and it sounds like you are tech savvy so feel free to poke on it if you wish.  It might be possible to recast the console to run in a virtual Xwindow - just not something I had tried.  I'm traveling for the next few days so I'll only be online intermittently but feel free to queue up any questions and I'll take a shot at them.

[Screw Loose Dan]

Santa was good to me and I received a rasberry pi 3 for Christmas.  This project has been my main reason to want to get a rasberry pi.  Thanks for all the hard work that you have put into it!

 

I read through a good portion of this thread (I missed a few pages in the middle) and read documentation on Git Hub.  I hope I didn't miss anything important, but I did initially struggle a bit.

 

I'm a complete noob when it comes to Rasberry PI's and Python, so I thought perhaps it was something I was doing wrong (although I work in IT and troubleshoot plenty of code).  Hopefully I'm not bringing up something painfully obvious.

 

However, after looking at the logs and looking at console.py, I think the minimal install might be a bit too minimal (or error handling could be done differently).  I installed following your install scripts and used the minimal config.  I kept seeing something like this in the logs:

12-30-17 22:32:08 Sev: 1 -LParam: KeysPerRow: 2
 
<type 'exceptions.AttributeError'>
Python 2.7.13: /usr/bin/python
Sat Dec 30 22:32:10 2017
 
A problem occurred in a Python script.  Here is the sequence of
function calls leading up to the error, in the order they occurred.
 
 /home/pi/consolestable/console.py in <module>()
  321 
  322 LogBadParams(config.ParsedConfigFile, "Globals")
  323 LogBadParams(alertspec, "Alerts")
  324 """
  325 Dump documentation if development version
LogBadParams = <function LogBadParams>
alertspec = None
 
 /home/pi/consolestable/console.py in LogBadParams(section=None, name='Alerts')
   71 
   72 def LogBadParams(section, name):
   73  for nm, s in section.iteritems():
   74  if isinstance(s, Section):
   75  LogBadParams(s, nm)
nm undefined
s undefined
section = None
section.iteritems undefined

To me it appeared the code at line 323 was balking and the LogBadParams section (line ~72) wasn't receiving a variable for "section" from the earlier section.  Best I could figure it was throwing an error because there was no alert section.  Without doing more digging in the code, I added an alert section and now the the console loads with the minimal configuration!  

 

This was all the I added to the config.txt:

[Alerts]
[[AutoVersion]]
Type = Periodic
Interval = 3 hours
Invoke = AutoVersion.CheckUpToDate

 

I have to dig to see what that "alert" does exactly, but I presume from it's name it's probably pretty safe for now.  After adding this, I don't see any more errors in the logs.  

 

[chrisb5]

I too got a pi3 for Christmas but have had less luck with the install...

My isy is setup secured (i.e. requires https and a non standard port). The :port is accepted by the isy ip prompt but https required code changes I just started digging in to... and warnings from one of the libraries due to my self signed certificate.

 

- Chris B

 

Sent from my SM-G920V using Tapatalk

[kck]

 

To me it appeared the code at line 323 was balking and the LogBadParams section (line ~72) wasn't receiving a variable for "section" from the earlier section.  Best I could figure it was throwing an error because there was no alert section.  Without doing more digging in the code, I added an alert section and now the the console loads with the minimal configuration!  

 

This was all the I added to the config.txt:

[Alerts]
[[AutoVersion]]
Type = Periodic
Interval = 3 hours
Invoke = AutoVersion.CheckUpToDate

 

I have to dig to see what that "alert" does exactly, but I presume from it's name it's probably pretty safe for now.  After adding this, I don't see any more errors in the logs.  

 

 

Absolutely correct analysis.  It is the bug I posted about 3 posts or so up in this thread.  It looks like you grabbed the version before I pushed the fix for it on the 27th.  It should now be fine not to have an [Alerts] section.  I had added the code to check for bad parameters and show any parameters that had not been consumed by the program processing the config file after I did the minimal test adds so it never got tested with an absolute minimal config and since I always had alerts (both explicit and due to having command variables in my ISY that can cause remote operations in the console from the ISY side) I never saw it.  But you nailed the issue so you can't be than much of a noob .  By the way, the alert that you left in checks for a new version periodically and reloads the console with that so by now you probably have 2.41 installed if you look at the current version.

 

 

I too got a pi3 for Christmas but have had less luck with the install...

My isy is setup secured (i.e. requires https and a non standard port). The :port is accepted by the isy ip prompt but https required code changes I just started digging in to... and warnings from one of the libraries due to my self signed certificate.

 

- Chris B

 

Sent from my SM-G920V using Tapatalk

 

I've never run with an ssl secured version of things.  I had tried a long while back but couldn't sort it out and since I didn't feel I needed it in my situation didn't pursue it.  If you can tell me what needs to be fixed to get it to handle this case let me know.  Unfortunately I am remote from my ISY for a good while now so am limited in what I can debug from here.

[Screw Loose Dan]

Absolutely correct analysis.  It is the bug I posted about 3 posts or so up in this thread.  It looks like you grabbed the version before I pushed the fix for it on the 27th.  It should now be fine not to have an [Alerts] section.  I had added the code to check for bad parameters and show any parameters that had not been consumed by the program processing the config file after I did the minimal test adds so it never got tested with an absolute minimal config and since I always had alerts (both explicit and due to having command variables in my ISY that can cause remote operations in the console from the ISY side) I never saw it.  But you nailed the issue so you can't be than much of a noob .  By the way, the alert that you left in checks for a new version periodically and reloads the console with that so by now you probably have 2.41 installed if you look at the current version.

I can assure you I am way over my head with the RPi, and Python is not even close to my comfort zone.       

 

I was having some issues with my RPi so I rebuilt the whole thing (fresh OS install).  Did the regular install using your scripts and while testing it, noticed that it was still having issues with the lack of Alert section. 

 

I'm not sure the best way to tell which version I'm on, but in the versioninfo file the sha hash is:

ed06759aaf0f276258dd3dbaa47ee3c15c2fe9a6

I'm not very good at GitHub (or any repository for that matter, I troubleshoot other people's stuff, I don't code).  But, it seems like your script checks versions here:

 

https://api.github.com/repos/kevinkahn/softconsole/tags

 

Looking at that, it appears the hash in the versioninfo file is the same hash as home/current/beta and also V2.31 AND V2.4.  It appears the V2.41 sha hash is: 

93a44e389b8a96441eaaa078888a27659481c036

I don't think your installer would ever get that version with the way "current" and "beta" are currently.     Again, I'm not that familiar but something doesn't make sense.

 

Also, I didn't see it mentioned anywhere, but the rc.local file has part of an IP address hard coded into the file (as a guy that has a networking background, this makes me shiver!).  Your IP address range is completely different than mine, so of course the rc.local stays in an endless loop and fills the startlog.  This is regardless if the console is to start or not.  Obviously it's easy enough to update the IP address as a quick fix.  But, while I was there I also put in a couple IF statements so it only loops for a couple minutes.  Something like this:

<snip>

echo "Running rc.local -- getting my IP" >> /home/pi/startlog
 
# Gets what the ISY IP address should be from the config file
ISYIP=$(head -n 1 /home/pi/Console/cfglib/auth.cfg | awk 'NR==1 {print $NF}')
echo "ISY IP . . . "${ISYIP} >> /home/pi/startlog
if [[ ${ISYIP} != 10.1.* ]]
then
echo "Doesn't appear to be a valid IP address in auth.cfg" >> /home/pi/startlog
else
# Tries to get IP address from the ip route command
IP=$(ip route get ${ISYIP} | awk 'NR==1 {print $NF}')
echo "Immediate . . . "${IP} >> /home/pi/startlog
 
# Do a loop for 120 iterations/~2 minutes
count="120"
i="0"
while [  $i -lt $count ]
do
  if [[ ${IP} != 10.1.* ]]
  then
echo "Waiting . . . "${IP} >> /home/pi/startlog
  i=$[$i+1]
sleep 1
IP=$(ip route get ${ISYIP} | awk 'NR==1 {print $NF}')
  else
# get out of loop and set $i high
  i=$[$count+1]
  fi
done
 
# Did it reach the interval, log and move on.
if [[ $i -eq $count ]]
then
date >> /home/pi/startlog
echo "No luck getting route to ISY IP.  Error -  "${IP} >> /home/pi/startlog
else
date >> /home/pi/startlog
echo "My IP address is "${IP} >> /home/pi/startlog
fi
fi
</snip>

There's definitely gotta be better ways of handling all this.

[kck]

Ouch.  You are right about the release.  In my rush to get out of town with this fixed it looks like I neglected to force push the 3 script related tags.  Now I'll have to figure out how to get them fixed while not on the machine that actually made the changes.  My git/github depth is limited.

 

Good catch on the network number.  I'm afraid to admit that I'm also an rather old networking guy (dating from first BSD IP stacks) so that is embarassing.  All I can claim in defense is that I had stole that code from somewhere when I was first trying a Pi to run the Alexa bridge and haven't much looked at it since.  That clearly needs to get fixed.  I should go back and look at what is really needed there or probably even better would be to switch the start up out of rc.local and into the System V init system that seems to be the system management of choice for the Debian Linux system now.   (It has the ability to sequence things after the network has initiated.)

 

Kevin

[Screw Loose Dan]

No worries at all if you don't get to it for a while.  I'm having a blast playing around.    Well worth the price of admission!! 

 

Getting this to run as an init script would be cool.  I played around with making it an init script for a bit, but was really lost in the weeds.  I think my issue was getting to the interactive shell, but not really sure.

 

In the interim, I'm not sure that any of the ip address checking is really necessary.  I presume as long as you have any default route, you should be okay.  The only "gotcha" I can think of is if the default route is in the 169.254.0.0/16 range, that would mean no DHCP server.  But, I think the check for the network should really be done by the application scripts, probably not best in the re.local script as it took a while to find it!   

[kck]

OK - think I managed to get the release tags updated to that the current version installs.  

 

I think you are right about the IP check.  I seem to remember that had to do with stuff other than the console - I'll need to look at that and figure out what is really needed.  

[Screw Loose Dan]

I had removed the alarm to automate the update, I'll re-enable it to see how that goes. (I did alarms for my garage doors instead.)  But, it does look like the tags are more what I would expect on GitHub.

 

Another item I kept stumbling over...the libsdl1 downgraded package.  It took me a while to figure out why I would get everything working, then the touchscreen would start acting all wonky.  A fresh install would fix it...but it would always start acting up again.  Vicious cycle.

 

I paid closer attention and after I had everything working, at some point I would run a 'apt-get distro-update'.  The libsdl1 package was being updated!! 

 

Looks like you need spaces the /etc/apt/preferences.d/libsdl file. Your script creates:

Package: libsdl1.2debian
Pin: release n=jessie
Pin-Priority: -10
Package: libsdl1.2debian
Pin: release n=stretch
Pin-Priority: -10
Package: libsdl1.2debian
Pin: release n=wheezy
Pin-Priority: 900

 

When I change it to look like:

Package: libsdl1.2debian
Pin: release n=jessie
Pin-Priority: -10
 
Package: libsdl1.2debian
Pin: release n=stretch
Pin-Priority: -10
 
Package: libsdl1.2debian
Pin: release n=wheezy
Pin-Priority: 900

The distro-update doesn't bork the libsdl1 package with the spaces added.

 

Bash w/echo gets wonky with line feeds (or maybe it's my own incompetence), but when I change lines 120-130 in installconsole.sh like this, it appears to create the file with the spaces needed:

#set the priority for libsdl from wheezy higher then the jessie package
printf "Package: libsdl1.2debian
Pin: release n=jessie
Pin-Priority: -10\n
Package: libsdl1.2debian
Pin: release n=stretch
Pin-Priority: -10\n
Package: libsdl1.2debian
Pin: release n=wheezy
Pin-Priority: 900\n
" > /etc/apt/preferences.d/libsdl

 

Is it easier to track these items in GitHub if I report them as bugs?

 

[Screw Loose Dan]

I have been playing around with some alerts and banging my head against the wall.  Is it possible to have an alert not blink?  I've tried setting "Blink = 0", but the screen doesn't show the message.  The defer button shows, but no text in the message area.  Am I doing something wrong?

 

The example alert screen configs all appear to use CharColor parameter in the Alerts section, but that doesn't appear to change anything on alert screens.  The text of the message (when it blinks) appears to follow the KeyCharColorOn.  Is that expected?

 

Just working my way configuring things, but I really am enjoying this project!  Thanks again for all the hard work!

[kck]

Well I thought non-blinking messages should work with Blink = 0 but it seems I didn't bother to actually show the message when Blink is 0 - duh!  I just pushed a 'currentbeta' release that adds the missing 2 lines.  If you want to shortcut downloading, since you seem to be fully competent at munging code, you can also just insert the following 2 lines: 

else:
    config.screen.blit(self.messageimage, self.upperleft)

 

in screens/alertscreen.py after line 117 as the else half of the is Blink 0 test.

 

The text characters do use KeyCharColorOn as their color choice.  Looks like the examples are wrong.  I think this dates to when I had a request to allow different character colors for on and off keys and it never all got cleaned up properly.  This isn't likely the only place where a parameter name is inconsistent or wrong.  I've never been happy with the config file stuff because the library I use makes it hard to have and maintain master lists of parameter names so variations creep in.  I've thought about changing it but there are enough config files around that use this format that changing seems worse than living with it.

 

Let me know if the fix gets the non-blink case right since I'm not set up to easily check it out at the moment.

[Screw Loose Dan]

Thanks for the quick response, but I can't get the message to display when not blinking.  I tried changing it manually and when that didn't work I tried the beta to confirm I hadn't messed something up.  Still no luck when not blinking.  But, it's pretty late here, so it's entirely possible I'm doing something stupid, so I'll take a closer look tomorrow sometime.

 

I have had some struggles with the parameters and figuring out what does what and where.  I was thinking about making myself a master config file fully commented with some of what I've discovered/stumbled upon along the way.  If you want, I'd be more than happy to share it.

[kck]

Sorry - forgot to actually do the screen update.  Need one more line after that addition that says:

pygame.display.update()

 

It's in the currentbeta now.  Unfortunately I don't have a debugging system set up where I am (at my snowbird house) yet so I'm doing the fix blind.  Sorry to get it wrong.

 

Also, if you look in the docs directory at the file params.txt you'll find a file called params.txt that is auto generated that has a bunch of what I think you are looking for.  It should be pretty up to date - it only gets generated on my development system but I think it should be correct as of a week ago which would be the same as today since I've made no changes.  What is lists is for each module what parameters are defined locally to the module and what global parameters the config file may override for that module.  Since it is based on my general parameter grabbing utility it doesn't guarantee that the parameter is actually used in the module but it should be pretty close.

[Screw Loose Dan]

The no blinking option in the currentbeta now works as expected!  Thanks!  And, no need to apologize, I appreciate all the effort.

 

I do use the params.txt file at times, but when I'm using one of the example configs as a template I tend not to refer back to it.  Hence, why I spent so much time trying to figure out why the text wasn't changing with the CharColor parameter, I assumed the example config would have the correct parameters without double checking the params.txt file.  But, we all know what they say about assuming...  

 

I ordered one of the cases the other day from the Thingiverse website.  Not sure how long it will take to arrive, but anxious for it to arrive.  I have a kpl next to the bed, and it works fine, but I expect this to be a major upgrade.  I've also just purchased another RPi to build a second unit for the living room.  I bought a 3.5" screen for it, but I'm debating getting a 7" to try.

 

Have you considered using the images from weatherunderground for conditions and forecast?  I know the API returns the image URL, just not sure how much work it would be on the RPi/Console side.  Might not look good on these tiny screens (or it might help with the longer description issue?), but I was thinking they would look nice on a 7" screen.  Just curious if you had looked into it at all.

[chrisb5]

I'm not familiar with git but I did pull down copies of the files that appear to need updates to accommodate https:// console connections onto my dev box and made changes I think will take care of allowing http or https connections (as well as the ws:// vs wss:// connection probably needed in isyeventmonitor.py. 

 

No idea how to test these though since the scripts all want to pull from the git repo and I'm not git savvy. 

 

Happy to zip up the 5 files though and email them or something. Changes are pretty minimal - along the lines of:

 

if config.ISYaddr.startswith( 'http' ) :

  config.ISYprefix = config.ISYaddr + '/rest/'

else:

  config.ISYprefix = 'http://' + config.ISYaddr + '/rest/'

 

and updating the prompt in getsetupinfo.py to request the full URL to access the console (i.e. http://1.2.3.4/ or https://1.2.3.4:9999). Checks everywhere I found references to the ISYaddr check for the old format (no http prefix) so either should work.

 

My server certificate is self-signed and last I tested some of the modified code myself I did get warnings from one of the libraries (lost the note I kept on that) but it wanted to have warnings disabled I believe - probably a urllib3.disable_warnings() type setup.

 

-Chris B

[kck]

Chris,

Why don't you send me the files or a diff of them.  I'll put them in the project and include them in a "currentbeta" release so that initially they only impact you if you pull that.  I'll try to figure out how to regression test (I'm remote from my ISY at the moment) and then after that move them to the standard release.  Thanks for looking into this.  I do recall that back when I did play with this a bit I ran into the warning also.  I seem to remember not being able to get rid of it even though I did the disable_warnings thing.  It's been a while though so I don't really remember.

 

Also to gaetanlord  and anyone else interested in the 7" display, I actually got one of those and also located what looks like it will be a usable touch driver that I can integrate into PyGame.  If I can manage that (project for the next couple of days I hope) I will let folks know.  Initially I expect to just support it as a bigger screen although longer term there really should be more flexibility in setting it up.

 

Kevin

[Screw Loose Dan]

I mentioned before that I was ordering a case off the Thingiverse site. I have never ordered anything like that previously and really didn't know what to expect. And, I figure some may find this amusing (laughing at my expense is always acceptable!  ).

 

I hit the button "Order this printed" on the Thingiverse page linked previously in this thread. I thought it was a bit more expensive than I was expecting, but since I've never done anything like this before...I just went with it.  In hindsight, I realize that was a not the right thing to do (although I'm not 100% sure what the right thing to do is).

 

Yesterday a medium size box shows up.  It had a fair amount of heft to which piqued my curiosity.    Once opened, I quickly worked out that I had multiple versions of the case!!  LOL!  I now have all versions of the case!    

 

I went back to the site to work out the what/why.  It's probably pretty obvious to anyone that has ever ordered anything using that site before, but as a n00b, it was pretty easy to overlook. Kevin keeps all the prior versions of the files for the case on the Thingiverse site.  I had incorrectly presumed there was some sort of version control built into the site - there isn't!  LOL 

 

Now I get to work out which bits go with which version!  

[kck]

Oh no!   I've never ordered anything directly from Thingiverse.  Probably would have made the same mistake in you place.  FYI - before I had a 3D printer of my own (nice toy) I did some printing via 3dhubs.com.  It is sort of an Uber for 3D printing where folks with printers who are willing to print for others offer to do so.  Results can vary depending upon the person you wind up going with but it can often be done pretty quickly and locally.  The site handles all the providing of the costs, escrowing payment until you are satisfied, mediating communications etc.  You might check it out.

[kck]

I just pushed a new release (2.5) of the console.  First, thanks to Screw Loose Dan for the code changes to support https/wss access.  Just specify https://addr instead of addr in the config file for the ISY to get that.  The major new feature is support of the official Raspberry Pi 7" screen.  That screen has a quite different way of delivering touch events and was not compatible with the standard libraries that I use.  Happily pimoroni on the web did a small support library for it that I was able to adapt to use in the console.  Even better, I was able to adapt that library to finally get rid of the need to downgrade the SDL libraries as part of the install of the console.  For those of you who don't know what this means - don't worry it just simplifies the install process and makes it less fragile over the long run.  For those who do know of what I speak it means no dangers of inadvertently upgrading those libraries if you do some other upgrade on the system running the console.  This is new code and should be decently tested but if you do an install and have issues with touch you can fall back by using the pisetupold.sh script rather than pisetup.sh to do the install.

 

Kevin

[Screw Loose Dan]

I just pushed a new release (2.5) of the console.  First, thanks to Screw Loose Dan for the code changes to support https/wss access.  

 

I can't take credit for that!  Thanks goes to Chris B gave that code. 

[kck]

Oops.  Confused the SDL update issue with the security stuff.  Sorry Chris and thanks for the improvements!

[Screw Loose Dan]

I received my 7" display today, so I've been playing with that.  Only "issue" I had with the 7" display was the display was upside down after your install scripts.  I commented out the lcd_rotate option in the /boot/config.txt to resolve it. For reference, I was using this display with this stand.

 

I've also been playing around with using SSL.  My isy is accessible with no certificate errors in a browser using this:

 

https://isy.example.com         (not really my domain name)

 

However, when I put that in auth.cfg, I get the following in the Console.log:

 

... <snip>

01-19-18 17:49:20 Sev: 3 Param: ISYuser: dan

01-19-18 17:49:20 Sev: 3 Param: CharColor: darkgrey

01-19-18 17:49:20 Sev: 3 Param: DimTO: 15

01-19-18 17:49:23 Sev: 3 ISY not responding

01-19-18 17:49:23 Sev: 3 -ISY (nodes): https://isy.example.com/rest/

 

Using just "http://isy.example.com"(no"s") in the auth.cfg file works without apparent issue.  

 

Has anyone else used the current release with SSL?  Is it possible to see what the return code the isy.py script is getting when it can't connect? My attempts to add more log commands around line 309 in the isy.py script were unsuccessful.

[Screw Loose Dan]

Not an issue, but maybe a clean up...I noticed with the latest version on a fresh install was these files which I suspect some are artifacts from your dev environment:

 

-rw-r--r--  1 root root  1209 Jan 19 16:22 getsetupinfo.py

-rw-r--r--  1 root root  1209 Jan 19 16:31 getsetupinfo.py.1

-rw-r--r--  1 root root  3490 Jan 19 16:22 installconsoleSDL.sh

-rw-r--r--  1 root root  3490 Jan 19 16:31 installconsoleSDL.sh.1

-rwxr-xr-x  1 root root  3490 Jan 19 16:31 installconsole.sh

-rw-r--r--  1 root root  4387 Jan 19 16:31 installconsole.sh.1

 

Of the install scripts, I presume only the installconsole.sh should be there since it's the only executable shell script.  Are both getsetupinfo scripts needed?  Not an issue, just something I noticed.

[kck]

Actually all those are just leftovers from the installation.  I don't delete them because when doing development I sometimes need them afterwards and it was simpler to just leave them.  It is interesting that the .1 files are there since those are generally left as an option by cp when you copy over an existing file but that is not generally a default option - you need to set it.  By chance do you do that in your startup files?  Not an issue - just surprised to see them.  Feel free to delete them.  On the https deal I just copied the code that Chris provided.  Did you wait a bit after seeing that message.  I ask because sometimes the ISY doesn't respond and the code retries so I do see that not responding message on occasion generally followed by a later success.  I don't think there is any other response code since I think You get that message when the request times out though it is possible there is some other cause.