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?

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!

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.

I had a similar problem, I have a scene called "All Lights", which includes all my house lights to I can turn them all off at once (or in theory all on). I got the same results you had, it would turn off XX number of lights that I had added. My work around was in the ISY portal to give the spoke mapping "entire house". Perhaps that will help?

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.