Soft Keypadlinc-like Console from Raspberry Pi

[kck]

The crash has to be happening in the screen display routine for the tstat but there isn't much that happens there - the Python crash message will probably point at it.  The screen names you are using are fine and the fact that you get to the screen from the nav button says it has been parsed and loaded ok.  Really all the screen display routine does is query the ISY for the tstat info and format it.  I even tried switching mine to C from F and that all worked ok since I didn't know if you were running F or C.  In addition to telling me what the log.txt file says one other thing you could do is to start the console and before you go to the tstat screen go to maintenance (5 taps), set flags, and set the "Main" flag on.  Then return/exit maintenance and go to the tstat.  I would expect that in the log.txt file you would see what came back from the ISY and it should be something like:

Main ->  Active Subscription List will be:
Main ->  Enter to screen:  Thermostat - Main
Main ->  CLIFS : 8 : Auto
Main ->  CLIHCS : 1 : Heat On
Main ->  CLIHUM : 23 : 23.00
Main ->  CLIMD : 3 : Auto
Main ->  CLISPC : 46 : 23.00
Main ->  CLISPH : 42 : 21.00
Main ->  ST : 40 : 20.00

 

(This was from a tstat in C mode - numbers would of course be higher for F).  If the problem is in the actual comms to the ISY (don't know why that one call would fail given everything else is working though) you won't have gotten to the debug line so won't see this.  In any case, I'd guess I can diagnose stuff pretty quickly from that point.

[EVictory]

Kevin,

Attached is a zip file containing logs and copy of config.txt and tstat-DN.cfg files.  I looked at the log files before I pressed the navigation button to enter the thermostat screen.  The Console.log did not change when I pressed the button.  In other words, nothing was added to the Console.log when I pressed the button and it crashed.  However, the log.txt did get the lines below added as a result of my pressing the Downstairs-AC button.

 

-----------------------

Traceback (most recent call last):

File "console.py", line 237, in <module>

config.DS.MainControlLoop(config.HomeScreen)

File "/home/pi/consolestable/displayscreen.py", line 207, in MainControlLoop

K.Proc(config.PRESS) # same action whether single or double tap

File "/home/pi/consolestable/displayscreen.py", line 103, in NavPress

self.SwitchScreen(NS, 'Bright', 'NonHome', 'Nav Press')

File "/home/pi/consolestable/displayscreen.py", line 99, in SwitchScreen

self.AS.InitDisplay(nav)

File "/home/pi/consolestable/screens/thermostatscreen.py", line 144, in InitDisplay

self.ShowScreen()

File "/home/pi/consolestable/screens/thermostatscreen.py", line 110, in ShowScreen

self.info[item["@id"]] = (int(item['@value']), item['@formatted'])

ValueError: invalid literal for int() with base 10: ''

 

-Emile

Thermo Crash.zip

[kck]

That's weird - that says that one of the properties that the ISY is sending back for your tstat has a non-integer value which I didn't think should happen.  I expect an integer value and get something else.  I forgot to have you add a "LogLevel = 0" line to the front of your config.txt which I think is why the debug line that should have been output to the log if you turned on the Main debug flag didn't come out.  Just as a quick test: if I hit the ISY from my browser with a "http://192.168.1.15/rest/nodes/22%2018%20A3%201"where the IP address is the ISY and the 22 18 A3 1 is the tstat address I get a response whose "properties" look like:

<properties>

<property id="CLIFS" value="8" formatted="Auto" uom="n/a"/>

<property id="CLIHCS" value="1" formatted="Heat On" uom="n/a"/>

<property id="CLIHUM" value="24" formatted="24.00" uom="%"/>

<property id="CLIMD" value="3" formatted="Auto" uom="n/a"/>

<property id="CLISPC" value="46" formatted="23.00" uom="degrees"/>

<property id="CLISPH" value="42" formatted="21.00" uom="degrees"/>

<property id="ST" value="135" formatted="67.50" uom="degrees"/>

</properties>

 

I am guessing that if you do the same one of those value= items won't be an integer.  It would be good to know what it is and what it means.  I'd guess that it will be a blank (i.e., " ") which I can check for and turn into a value but I'd like to know what to turn it into.  To give you some context: CLIFS is fan mode, CLIHCS is heating/cooling state, HUM is humidity, MD is mode, SPC is cooling setpoint, SPH is heating setpoint, and ST is current temp.  the temp values are all 2x the actual (i.e., 46 is 23 C).  The HUM is a percent.  If you could tell me what your tstat is telling you and what it is actually set to I should be able to deal with whatever it is reporting via the ISY.

[EVictory]

Kevin,

Your post earlier today was at 12:36 PM.  My post was at 12:38 pm.  I was typing my 12:38 post when your post came in and did not see it until tonight.  The logs I sent you earlier did not have the flags set as you asked.  I will do that shortly after this post.

 

Below is the result I get when enter http://192.168.200.25/rest/nodes/1D%206D%208C%201 in my browser.  This is the Downstais-AC thermostat, address 1D 6D 8C.  Both thermostats are older 2441TH Insteon Thermostats, firmware v.00 and I use F.  Notice the CLIHCS values are spaces.  Attached is an image in the ISY

 

<properties>

  <property uom="n/a" formatted="Auto" value="8" id="CLIFS"/>

  <property uom="n/a" formatted=" " value=" " id="CLIHCS"/>

  <property uom="%" formatted="51.00" value="51" id="CLIHUM"/>

  <property uom="n/a" formatted="Auto" value="3" id="CLIMD"/>

  <property uom="degrees" formatted="72.00" value="144" id="CLISPC"/>

  <property uom="degrees" formatted="63.00" value="126" id="CLISPH"/>

  <property uom="degrees" formatted="69.00" value="138" id="ST"/>

</properties>

 

I have had them for several years.  I have upgraded my ISY firmware many times since first adding them to the ISY.  I have seen other cases where I have needed to uninstall and reinstall devices in the ISY to get the latest support offered by ISY firmware releases (remotelincs, leak sensors, etc.).  I may try deleting and reinstalling one of my thermostats.  Or, it may be that the early thermostats did not offer as much functionality as later versions. 

 

-Emile

[EVictory]

Kevin,

I deleted and reinstalled one of my thermostats.  As I thought might happen, when I added it back, it looks different.  Now I have three nodes instead of one.  Now the thermostat shows as firmware v.0B in the ISY.  I also opened up the physical thermostat and it is stamped with physical v1.15.  Below is a browser page again.

 

<properties>
  <property uom="n/a" formatted="Auto" value="8" id="CLIFS"/>
  <property uom="n/a" formatted=" " value=" " id="CLIHCS"/>
  <property uom="%" formatted="50.00" value="50" id="CLIHUM"/>
  <property uom="n/a" formatted="Cool" value="2" id="CLIMD"/>
  <property uom="degrees" formatted="71.00" value="142" id="CLISPC"/>
  <property uom="degrees" formatted="63.00" value="126" id="CLISPH"/>
  <property uom="degrees" formatted="69.50" value="139" id="ST"/>
</properties>

 

Now the values are in the same order as your sample (uom first).  As you can see, I still do not have an HCS value.  I suspect this early version of the thermostat does not support it.  The SoftConsole still crashes when I try to select thermostat screen via nav buttons.

 

I discovered a new issue.  Went to Maintenance screen and selected Set Flags as you asked.  When I pressed the MAIN button -- it crashes.  In fact, if I tap any button on the Set Flags screen it crashes.  All of the other Maintenance screens seem to work.  (I have not tried any of the Select Version buttons yet.)

 

-Emile

[kck]

Yep - your tstat reports blank apparently when it isn't heating or cooling.  Mine reports a code that maps to "off".  My display from the ISY console shows the heat/cool state as "Off" where yours is blank.  My tstat looks to have a slightly later firmware (v.0D) so that may be it.  My system also has the 3 nodes for each thermostat as you saw when you reinstalled.  No problems though.  I'll add code to expect a non-numeric code in the ISY response and map it to something sensible.  Most of the bugs I find from folks are things like this where there have been subtle changes in the way things get reported when the ISY is queried or in the event stream.  I'll try to get a version posted as a "currentbeta" for you to try in a couple of hours.

 

Not sure why the flags would crash - mine works fine and that's just a debugging convenience so not critical.  Still it should work so if you get a chance at some point could you grab the log.txt from a crash and send it my way.  In general, that log.txt file captures the crash info from python and usually will pinpoint the exact line of code that blew up and approximately why.  I'd like to find a way to capture that to the Console.log file but haven't figured out how to do that (it's kind of a meta problem since you want to recapture control of the python system after it has errored out but I think I may be able to do it at some point). 

 

Just FYI that LogLevel = sets a detail level for log entries.  It defaults to 3, 0 gets you everything including any debug that is turned on.  Those flags let you turn on specific types of debug info.  They can also be set in the config file by using <flagname> = True so that they are on from the start of the console.

 

Sorry for the rocky start on this - hopefully this will get you up and running.  Nevertheless, do continue to ping me with problems or suggestions.

 

Kevin

[kck]

I have pushed a version that I think handles the thermostat issue (since mine doesn't return a blank I'm a bit limited on testing the fix but it was pretty simple).  It should now show your tstat as 'Idle' if it isn't running the heat/AC.  This version is marked as 'currentbeta' so you should be able to try it by loading your current version, going to Maintenance/Select Version then choose "Download Beta" which should show the button pushed for a couple of seconds while the download happens, then "Use Beta Release".  Then if you Return, Exit Restart,  Restart Console, and confirm the console should reboot in the beta version.  You'll see that listed at the start of the new console log where it tells you what version is running.  Let me know if this fixes things.

 

One small caveat - I put this fix into my current development version which has moved to a simpler event subscription model with the ISY.  I don't think this will cause any other issues since I have been running this code base on my systems for a couple of weeks with very solid performance.  Still - it is a slightly different code base than 2.0.  I was planning to push this as 2.1 soon anyway so I think you'll be good.

 

Kevin

 

P.S.  Once I do push it as 2.1 you should use the maintenance screen to reselect stable release and download the then stable release so you're back on the normal stuff.

 

P.P.S.  Arg - almost forgot.  The new code base uses a Python library that the V2 install script didn't load.  You will need to run "sudo pip install websocket-client" before you upgrade to the beta.  If you don't you'll see a crash which says it can't find the websocket module. 

[EVictory]

Kevin,

 

The code changes worked!  (See below.) 

 

 

The Select Version buttons on the Maintenance screens also worked.  They make upgrading rather simple.  That's kind of neat.  The Set Flags screen now appears to work as well.  Perhaps this weekend I will try setting up some buttons to link to an X10 devices to see if they will work.  I also need to implement some alerts. 

 

I have a few questions:

 

1. I noticed Rasbian Jessie installs VNC.  But I noticed your installer installs tightVNC.  Is there a reason you prefer tightVNC over the native VNC that comes with Jessie?

 

2. I notice you install OpenVPN.  What is this used for?

 

Thanks for a great program!

 

-Emile

 

 

 

[kck]

Great! and sorry for the difficulties.

 

To the questions:

1.  I don't even really remember to be honest.  I think I might have had a system with no VNC and just grabbed one.  TightVNC seemed to work fine for me so I never gave it another thought.  Just FYI - I personally do relocate its port.  I wanted to be able to access a RPi from outside through my firewall and discovered that I was getting clobbered with attacks when it opened the normal port.  Nothing go through since I use good passwords but it was annoying and put traffic on my home net.  Moving it to some other random port doesn't actually increase security since an attacker can try all my ports find the open one and then probe to see what service is on it.  But most attackers aren't that motivated so in practice it pretty much eliminated attack attempts through my router.  Of course, if you don't need to access from outside that is much better.

2. OpenVPN is in the script only because it simplifies my install in a case or two.  I run a VPN to allow myself into the home network and also to establish a permanent connection between this house and my vacation place.  I should probably delete it from the script (along with things like the ddclient) since it doesn't apply to anyone else but . . .

 

I'll be interested in seeing what happens with the X10 devices.  I'm going to guess that they will cause a crash but with any luck I can figure out why and fix the issue if so. 

 

If you happen upon questions drop me a line and if you have suggestions do the same.  The program structure is pretty clean these days so changes are often not too hard. 

 

Kevin

[kck]

I just pushed a 2.1 version that makes the fix from the above discussion part of the release.  It mainly moves the program internals to pure websockets from using one of the other ISY libraries to make it simpler and a bit faster.  It also continues the effort to make the program more robust against configuration errors and network problems.  At least at my house it seems to survive a pretty wide range of power outages, network storms (don't ask - I haven't figured those out but have something to do with my router), and other communications issues.  Full comments in the release announcement on GitHub - note that there is one shell level command you need to give before upgrading to this release to install a library.  I have added a way to handle things like this automatically in the future.  The release can be downloaded and installed from the console maintenance panel or via the autoversion updating mechanism if you enable that.

 

Kevin

[EVictory]

Kevin,

The last couple of weeks have been busy so I have had little time to work with Soft-Console until this past weekend. 

 

I ended up building another SD card from the ground up so I could leave off TightVNC and use the realVNC built into Jessie.  That makes two times I have built Soft-Console.  I could not get the scripts to install the Soft-Console files either time.  The script installs all of the libraries just fine but it fails with the setupconsole.py and githubutil.py scripts saying it could not find the catch.txt file.  It is not a problem for me as I manually copied the files over to the home/pi directory using WinSCP but I wonder if others had the same problem.

 

I did some testing with the X10 devices (from the X10 module).  The Soft-Console ONOFF type works just fine with the X10 device.  When I press the device button in Soft-Console, the ISY sends an X10 ON command.  When I press the device button again, the ISY sends an X10 OFF command.  In my case, I had programs detect the X10 commands and take actions by setting a variable to 0 or 1.  I think I could have done this in Soft-Console using the SetVar type but I wanted to test the X10 device.

 

I am having a Soft-Console reboot problem.  Even while leaving the Soft-Console unattended, I have noticed it spontaneously crashes and reloads the Soft-Console.  When I look in the log.txt file, I see this sequence.

 

Consoleexit script: restart - /home/pi/Console/config.txt - codeerror

 

I have attached all of my log and config files.

 

My Data.zip

[kck]

I'm away at the moment but will look at this Thursday when I'm back home.  I can't imagine what the catch.txt thing is - I don't recall any file by that name and I'm pretty sure I don't create/use such a file.  All those 2 python files let me do is to avoid doing a manual install and setup.  They just mimic what happens in the automatic download and install that you can access from within the program.  The codeerror is definitely my issue in that is generally means I got to a branch or other place in the code that I should never be able to get to or that I don't know how to recover from.  It is probably some status info from the ISY that I'm mishandling. 

 

Kevin

[kck]

One thing I did notice that could be an issue at some point.  I see that you installed watchdog.  That probably shouldn't be in the script (or at least isn't necessary) since it is a program to reboot the Pi if it loses the network (also handles things for my 3d printer if attached and can power cycle a modem and router in another configuration).  In any case, if you installed it you'd need to update where it finds your local router or it may think it has lost local network connectivity and do a reboot.  It's a yaml file in the watchdog directory.  Otherwise just run without it is probably safer (it has pretty convoluted logic that seems to handle my cases but hasn't been really stress tested).  The restarts though seem to be coming because you lose websocket connectivity to the ISY for some reason.  That will require a more detailed look on my part to figure out why that might be happening.  By the way, I see you set to run "homerelease".   Should work but be warned that is a flag for me to run knowingly in my house and could have stuff that is flakey in general.  That's why the script has a prompt that suggests not setting that.  At the moment homerelease = currentrelease so it should make no difference.  Just a heads up.

[EVictory]

Kevin,

I meant to say config, not catch.txt.  Attached is a screen shot from the second attempt to install the console files.  Looks like it could not locate a module called config.

 

The log.txt file I sent earlier shows a lot of tweaking I was doing on Sunday to the config.txt and its associated x.cfg files.  I was making adjustments to the Soft-Console screens then trying them out.  At times I had bad configs that I then corrected.  I have not made changes since Sunday so any failures after that represent the issue.  I have attached the log.txt from today.

 

I actually have configured the yaml file for watchdog by adding my router IP and am interested in this program.  I have another Raspberry Pi running OWLink from Automation Shack.  That Pi goes unresponsive about once every few weeks.  Something like watchdog would help.  Just to be clear, I am NOT seeing the entire Pi reboot.  I am seeing Soft-Console crash and reload.

 

The homerelease was not intentional.  Is there a way to turn it off?

 

-Emile

log.txt

[kck]

Arg!  OK - install failure was my stupidity plus not testing.  I added a log message a while back in the githubutils module for normal operation that required importing config and since it isn't there during install . . .  I guess I hadn't done a clean install since that change.  I'll fix that when I'm home.  As to homerelease, no rush to fix but easy to.  There should be a file "homesystem" in your pi home directory.  Delete it and do a download for the stable version from the maintenance screen.  If you are running autoversion it actually looks at the current "versioninfo" in the consolestable directory to know what to check on so you probably want to also edit that file and replace "homerelease" with "currentrelease" if that is still there after the maintenance screen manual update (don't think it will be but not sure as I type this).

 

To possibly help me with the real issue of the rebooting/loss of websocket connection if you get a chance could you set the debug flags 'DaemonCtl' and  'DaemonStream' both on for a crash.  That might give me info to see what is actually coming in the websocket stream prior to it closing itself.  As I said - I'll be home tomorrow and look at this more easily there.

 

Thanks for your patience,

Kevin

[kck]

Looking at the logs I noticed 2 things:

1. You happen to have a screen named "Special".  Apparently the way the config file parser I use acts it equates that with a debug flag "Special" that I use internally and sets the flag.  Not an issue for the debug flag (although that is why you see some debug output of the form "Special -> . . ." in your logs) but it might cause an issue with the screen definition (although it looks ok further down in the log).  So I think this isn't a real issue though an interesting discovery.  In the version I'm about to push to fix the prep script error I've renamed that flag to DebugSpecial so it should make it harder for folks to bump into it.

2. You have a number of scenes with no members.  One of those (Auto DR) is expected since it has something to do with energy monitoring.  The others though seem odd.  Are they X10 related?  Or do you actually define some scenes in the ISY with nothing in them (guess that is possible).  Again don't think this would cause any issues related to the crash/restarts but they at least look suspicious.

 

Looking at the logs it seems like the websocket connection is just closing after a while at the network level and the console gets an error the next time it tries to access it.  The message that I get at the application level is that the connection is already closed.  I would expect that if I was getting some bad event in the stream I'd log that which I don't seem to be doing which makes me think it is some sort of network level event.  Is there anything odd about the comms between your Pi and the ISY box?  I noticed that in some of the logs the console had difficulty doing a read from the ISY during startup.  There are some messages about "ISY not responding" with some retries until it get through and does the successful node read.  Those are definitely odd.  The code does retries there because after a full power hit the Pis reboot a lot faster than the ISY.  So if you were restarting the ISY I would expect to see some retries waiting for it to come up but not otherwise.  In any case perhaps a detailed dump of the websocket stream will shed some light if you get the chance to do that.

 

Kevin

[kck]

All - I just pushed a V2.11 that fixes an error I introduced last release that broke the installation script.  Sorry for any inconvenience if you ran into it trying to do an install.  Symptom would have been a failure with a message about not finding config module.

[EVictory]

Kevin,

I removed the homesystem file and upgraded to v2.11.  I have set the two Daemon flags you mentioned. 

 

With the X10 module, you cannot add an X10 device to a scene, so none of the empty scenes were for X10 devices. I no longer have any X10 light switches or appliance modules as all have been upgraded to insteon.  I still have some X10 motion sensors, a few X10 RF remotes, an X10 V572RF32 Receiver, and an X10 XTB-IIR X10 Transmit Booster.

 

I deleted all empty scenes - I did not realize they would cause problems.  Some of the empty scenes were left over after some experimenting.  Others were left over from a garage that has been removed. 

 

It may very well be a problem with the communications between the Pi and the ISY.  I have noticed the Soft-Console sometimes seems to take a while when loading at the point it reads the ISY.  The Pi running Soft-Console is a Pi model 2B with a USB wireless adapter.  Also, I have a Pi running OWLink that also reports ISY timeouts from time to time.  The OWLink Pi is using the wired NIC. 

 

I am not sure what could be causing this.  Any thoughts on how to troubleshoot something like this?

-Emile

 

[EVictory]

Kevin,

I obtained your 3D case from Thingiverse and printed it. 

 

The glass screen of my 3.5" PiTFT display board became separated from the PC board and would fall forward out of the printed case if I tilted the Soft-Console.  (The double sided tape came loose.)  Also, I noticed a lot of light escaping from the edges of the display which was bothering me at night. 

 

Therefore, I modified the top cover of your case to include a lip (or bezel) that holds the glass of the display under the case.  The edge of the glass display is now covered so no light can be seen around the edges.  I used metal threaded inserts (instead of nuts) that I melted into the ABS screw holes to hold the case together.  Inserts were used for the 4 mounting holes of the Pi board, the two holes of the display board and for the screws holding the top case to the bottom case.  I also added a third screw to the top of the case. Last, I enlarged some of the screw holes so the inserts could be installed with less drilling.  Below is a link to the threaded inserts I used.

 

Insert P/N" 1GNL7

https://www.zoro.com/value-brand-ultrasonic-insert-m25x045mm-pk100-1gnl7/i/G2398496/?q=1GNL7

 

I have attached a picture of the assembled case with the modified top.  I also included a picture of the modified case top showing what the metal threaded inserts look like installed.  You install them with a soldering iron.  I have attached a zip file containing the modified top and bottom case STL files in case you are interested.

-Emile

caseV3.zip

[kck]

Nice job on the case improvements!  I have heard/seen reference to those metal inserts but haven't used them.  I assume you design a hole just a bit smaller than the insert and then heat/push the insert in using a soldering iron?  Very professional look.  May need to add some of those to my toolbox.  Also like the improved bezel.  I had one screen that came off as well but I just got some scotch permanent 2 sided tape and fixed it that way.  But the light leakage, while not really an issue, does bother me.  The case was my first real 3d print design effort and I did it because I couldn't find a case with a top/bezel for that screen.  Don't know why I never added that lip once I had gained some more experience.  Think I'll put that on the list to fix.

 

As to the software.  I verified that the empty scenes were not a problem of any sort.  I just noticed them and didn't know whether they indicated some other issue - they don't.  I'll keep adding as much diagnostic logging as I can to the comms in the program to see if I can get us a handle on what is going on.  I have seen a log like yours once recently on one of my systems.  What is bothering me is the fact that there is no actual error message coming up from the websocket library.  If I set up a test where I forcibly break the connection using tcpkill (which spoofs a reset into the link) I do get an error message.  I'd expect that if the comms just dropped out from a timeout of some sort I'd see some similar exception and there is certainly code to catch and report such an error.  So while I think it is a low level comm issue I'm not fully convinced it isn't really a bug of mine.  Just as a general observation, I do occasionally see retries on my boxes in the log.  There are 2 places where they appear.  First is in initially downloading the ISY device/scene info.  There I have a significant time delay and a lot of retries since the most common reason for that failure is actually when the house takes a full power outage.  The Pi simply gets back a lot faster (<20 seconds) whereas the ISY seems to take a minute or two to get back.  The other place I see occasional comm errors is when changing screens out of an idle state where I do a rest query to the ISY for the state of the devices on the now active screen.  That uses to have a long timeout which would make it look like the console had locked up when really it was just timing out.  I greatly reduced the timeout there since the ISY really should either respond virtually immediately or you should just retry.  So all this does suggest that the Pi comms can get into a funny state at times.  Still my consoles all hold the websocket stream up for days to weeks without failures.  By the way - my configuration has the consoles on WiFi and the ISY on Ethernet off the house router.  If you get a failure where you docapture the debug info (will be in log.txt or if you set LogLevel to 0 in the Console.log file) I'd be interested in at least knowing what the last events on the stream were.  I'll push a small update later today that has a bit more error capture in it and keep looking at my systems to see if I find anything in them.

 

Kevin

 

P.S.  One last random item on a weird comm issue I discovered on a Pi recently.  I had one Pi2 with a small plugin Edimax WiFi dongle that would not consistently keep its name active on my network using mdns which is a multicast protocol.  I had pulled out my little remaining hair trying to understand why that system, running an identical build to other systems that used USB dongles or Pi3s was the only problem case.  I swapped out the dongle for a different one and the problem was cured!  There is no "rational" reason why this should be an issue but I found a very obscure reference to a broadcast issue with some wifi chips which seems to be what I had run into.  So if you happen to have a different dongle around you might try swapping and see if it makes any difference even though I don't think broadcast/multicast should be involved here.

[kck]

Emile et al.,

 

I just pushed a 2.2 release as currentrelease.  It improves the handling of an unexpectedly closed websocket stream by catching the situation and reopening a new stream rather than restarting the console entirely.  This makes recovery from the close much faster (probably a second or two rather than 15-20 that it was).  I still cannot diagnose the conditions that cause the close to happen.  It simply manifests as either a close command in the stream or a 0 byte message - at least that is what the Pi library appears to be seeing.  It does seem to be related to network noise since it happens more on some networks and systems than others.  The release also adds a bit more diagnostic info gathering that may point at the underlying issue in the future. 

 

Kevin

[aaronball]

Hi Kevin,

 

First like to thank for all the work you have done on this. It's a great idea. I have been trying to get it running on a Raspberry 2 with the display without any luck. I'm sure it's my lack of experience on how to set things up. I have been looking for the instructions for doing that put can not find them. Can you please point to me where they are? I have the Raspberry setup running with the display working, I just can't figure out how to get your scripts loaded.

 

Thank you,

Aaron

[kck]

Aaron,

The usage notes on github has the install instructions: https://github.com/kevinkahn/softconsole/blob/master/docs/useagenotes.md

 

You should be able to run the piprep script and it will ask you a series of questions and then create directories and populate the console into them.  It should also, if you answer yes to the question about autostarting on boot update the rc.local file to automatically start the console.  You will need to build and config.txt file to have the console build screens otherwise you will just see a red exit screen when the console starts and immediately exits not having found a configuration.  I suggest looking at the config.txt and stuff in the cfglib that are in the example config files at github.  If this isn't working for you can you describe a bit more what isn't working and perhaps I can provided more help based on that.  You do need to spec the correct display in on of the question in the script since the Adafruit folks have a 3.5 resistive and 2.8 capacitive and resistive models and they vary some in their drivers.  Happy to help some more as needed.

 

Kevin

[Teken]

Kevin,

 

As always, I thank you for continuing to push the envelope in this fantastic project. I hope to do the very same once I find the time to do so - Along with a deployment that is a little more stream lined.

[aaronball]

Aaron,

The usage notes on github has the install instructions: https://github.com/kevinkahn/softconsole/blob/master/docs/useagenotes.md

 

You should be able to run the piprep script and it will ask you a series of questions and then create directories and populate the console into them.  It should also, if you answer yes to the question about autostarting on boot update the rc.local file to automatically start the console.  You will need to build and config.txt file to have the console build screens otherwise you will just see a red exit screen when the console starts and immediately exits not having found a configuration.  I suggest looking at the config.txt and stuff in the cfglib that are in the example config files at github.  If this isn't working for you can you describe a bit more what isn't working and perhaps I can provided more help based on that.  You do need to spec the correct display in on of the question in the script since the Adafruit folks have a 3.5 resistive and 2.8 capacitive and resistive models and they vary some in their drivers.  Happy to help some more as needed.

 

Kevin

Kevin,

 

Thanks for the quick reply. I will look at the useagenotes file this weekend and see if I can get it to work. I have a RP2 and a RP3 along with the 2.8r and 3.5r displays. I will try configuring both. Thanks again for your help.

 

Aaron