Screw Loose Dan

Any idea what these errors might indicate? I don't see anything in the logs on the ISY that correspond. I took a quick look at the code, but couldn't really tell what might be causing it. 10-07-18 23:29:42 Sev: 4 Unexpected ISY event to screen: TimeTemp00 10-08-18 00:29:44 Sev: 4 Unexpected ISY event to screen: TimeTemp00 10-08-18 00:30:00 Sev: 4 Unexpected ISY event to screen: TimeTemp00 10-08-18 01:29:44 Sev: 4 Unexpected ISY event to screen: TimeTemp00 10-08-18 02:29:44 Sev: 4 Unexpected ISY event to screen: TimeTemp00 They appear to occur roughly every hour and roughly 30 minutes opposite of the hourly weather updates (not sure that's relevant, just what I noticed). Best I can tell everything is working. Just curious.

Well, that got things back to normal for me now! Thanks! I'm sure I've tripped over the trailing comma issue before. I thought I had even tried adding it in at some point, but I was initially having multiple issues getting switched over...so who knows. And, I'm not sure why, but now the Conditions looks centered between the Clock and Forecast. It had been just off center/low when I had the time on two lines. Maybe an optical illusion... Thanks!

Hi Kevin! I'm still using my softconsole. I really like it and use it all the time. I haven't had much time the past few months to play around and had fallen way behind on versions. But, things were working/stable for quite some time, so there wasn't much need. This weekend I took some time and rebuilt my main unit. The changes to the TimeTemp screens through me for a bit of a loop. It took an embarrassingly long time to read in the usage notes that the backwards compatible TimeTemp screen was now TimeTempX. My fault for having poor reading comprehension skills. But, maybe in the future for changes like that, leave the 'legacy" screen name alone and go with something like TimeTemp2 for the new format. Just a thought. I ended up switching to the current TimeTemp screen, but can't manage to get the formatting just like I want. I can't seem to get the time format all on one line. This code make crazy things happen: TimeFormat = "%-l:%M: %P %a %b %-d" This works (but isn't what I want): TimeFormat = "%-l:%M %P","%a %b %-d" Also, is there anyway to eliminate the Label entirely? If I comment it out, I get the default "TimeTemp" and if I make the "LocationSize = 0" there still appears to be some space used (but, it's hard to tell). I haven't played with the new weather provider yet, but that looks promising.

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

I'll admit, I'm a bit out of my league. Kevin (kck) developed this code, I'm sure he'll have more insight, and I'm sure the log will help him narrow things down. Are you using a basic/minimal configuration just to see if you can get it working? My best guess is that the code is choking on the format of the response from the ISY for a particular device while it's enumerating the list of devices, but that doesn't really help you fix it.

I believe it's only been tested on version prior to 5. What errors are you seeing? Some logs to look at: /home/pi/Console/Console.log # this is the main log, presuming the process gets started. /home/pi/earlyprep.log # I believe this is only used during installation /home/pi/prep.log # I believe this is only used during installation /home/pi/log.txt /var/log/syslog # this captures the logs as the service starts. journalctl -u softconsole.service # Run this on the command line, and it will show the same as what is in syslog, but only for the softconsole

I apologize, I absolutely meant VNC. I rarely use VNC and so I'm not that familiar. I personally don't see much need for it on a device like this (but I understand for developing the software it could be helpful). Are you using it to display the console or just a desktop? The little I understand of VNC, I believe for a seperate desktop you would probably need a new instance like you are doing. As far as the config scripts go, the biggest issue I had was I misread the prompt about installing VNC/ssh on regular port. I answered N to that and should have left it Y. I was distracted and doing multiple things at the time and I think when I read it I thought it was asking if I wanted VNC installed, which is why I answered No. I wasn't paying attention, which is really on me. But, somehow the ssh port got set to "-100" which meant sshd wouldn't start...it took me a while to figure that out. Although had it gotten started on an odd port it probably would have taken even longer to find. (I pass no judgement on those that decide to run ssh on different ports. Obscurity can be one layer of security. I think there are much more important layers, but to each their own.)

I installed the new version on one of my Raspberry's. Since I had been messing with so much, I did a fresh install. It took me a bit, but I got everything up and running and it all seems good now (your config scripts get me everytime). I confirmed the >4 day forecast stuff worked. Why do you install your own VPN service and not use the built in one? I have to work 12 hour shifts the next four days, so I won't have too much time to play with things, but everything appears to be working for now.

I would very much like to see running it as a service implemented into the standard release at some point. I'll be more than glad to help in anyway I can. Some of my thoughts as I look at how your code works...(just typing out loud! ) Regarding the consoleexit bash script, I have to admit, there's a few things in there that seem redundant or I don't understand (which is very likely). I could probably easily make the changes to the bash script to get things to "work" with the systemd service, but question how to best handle the beta stuff. Doesn't seem like it would be a good idea to run the beta as a service and while changing the systemd unit scripts to do it would be possible, it seems like a generally bad idea. I think once the initial install implements the service/unit file, it probably shouldn't be touched unless there is good reason. I think the simplest/quickest way for the service/beta to be handled, is when choosing to running the beta, disabling/stopping the system service and then running the beta scripts as you do now (not as a service). When switching back to "stable", stopping the beta console script, enabling/starting the service would get you back. With the current setup, I presume a reboot of the Pi gets you back to stable, correct? Problem here is disabling the service would prevent it from starting on reboot. If the service is just stopped, it should be okay, I would just be concerned with running the beta and accidentally starting the service. Do you do any checks currently to know which one is running? I can't imagine both in parallel would be good... Presuming the scripts don't currently have anyway to determine if the beta or stable is running, I was thinking it might be best to write a file (like 'run_as_beta'), have the console script as it starts detect if that file exists (and that the path of the current script isn't the beta one). And, if it does exist to stop the service and start the beta version (like you do now). Getting back to stable would be as easy as removing the file (programmatically or otherwise). On exit, if no errors leave the beta file, if errors existed remove the flag to get back to stable (to mimic current behavior, I think) and restart service. A regular reboot of Pi would get still get you back to beta (service would start stable, it would check for file, etc). I don't have much experience with these RPi's, but is their network stack that unstable that they need to be rebooted that frequently? Is logging the netstat and ping on errors/unknown reboots really necessary/helpful? Or, was it left in troubleshooting a specific issue? When I was doing some work to my WiFi lately, I thought the console script handled the lack of wireless gracefully...until it rebooted. Maybe prompt for a reboot if ISY is not reachable after XX amount of time, or chose to wait? (Rebooting in my work world is akin to pushing a thumbtack in with a sledgehammer...it can work, but generally NOT acceptable.) If the network is that problematic, I wonder if toggling the network adapter wouldn't make more sense than a reboot (but even that seems strong handed to me). If necessary, a much nicer way to ping your default gateway in bash (because not everyone has the same IP address range!): DEFAULT_ROUTE=$(ip route show default | awk '/default/ {print $3}') ping -c 1 $DEFAULT_ROUTE We could probably also work out pinging the ISY address, which I think makes more sense than pinging the default gateway for most of the script issues. Now that you accept URLs or IP's for the ISY address that would need to be handled, but do-able. FYI - The bit of playing around I've done with the systemd service, it seems to work just as advertised. I have made some minor changes, which I'll get updated in my original post on the topic. Biggest change was the Restart=always -> Restart=on-failure (allows the program to exit cleanly without the system restarting it). The system attempts to restart the script anytime it is killed or not running (unless exited cleanly). If I borked something in the python code and it throws a code, it just keeps trying the restart until I correct the code. Then it starts right up.

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

I decided to take a look at what it might take to get this running as a proper service. My initial poking around discovered: Raspbian Jesse uses systemd for service control (Earlier versions are different) RaspberryPi.org has a very simple example to follow for systemd. Pygame and systemd apparently don't play nice together, so my initial attempts didn't go well. Some google-fu discovered I was not the first to stumble upon Pygame and systemd's issue. So, I was able to work (hack!?) around it and get a service setup. I'll cover the steps I used here. First, backup and revert back to original rc.local sudo cp /etc/rc.local /etc/rc.local.bak sudo cp /etc/rc.local.~1~ /etc/rc.local Next, modify the /home/pi/consolestable/utilities.py file with the following, I added it immediately after the imports (~line 23): # next several lines stolen from https://stackoverflow.com/questions/39198961/pygame-init-fails-when-run-with-systemd # this handles some weird random SIGHUP when initializing pygame, it's really a hack to work around it # Not really sure what other ill effects this might have!!! def handler(signum, frame): pass try: signal.signal(signal.SIGHUP, handler) except AttributeError: # Windows compatibility pass # end SIGHUP hack Next create a service file for systemd to use. As root, create the file /lib/systemd/system/softconsole.service with the following: [Unit] # Description could really be anything meaningful/distinct Description=SoftConsole # This should make sure the network is up After=network.target [Service] # Script needs to be executable and first line will be '#!/usr/bin/python -u' ExecStart=/home/pi/consolestable/console.py WorkingDirectory=/home/pi/consolestable # Should restart service if it is not stopped gracefully Restart=on-failure # Slows things down a little on restarts, maybe doesn't need to be so long RestartSec=3 # Makes sure any output gets to syslog and named sensibly StandardOutput=syslog StandardError=syslog SyslogIdentifier=softconsole [Install] WantedBy=multi-user.target # Allows the use of journalctl -u softconsole.service to view relevant logs Alias=softconsole.service I added the shebang to the first line of console.py (this isn't portable and I need to determine python2 vs 3, see here and here): #!/usr/bin/python -u """ Copyright 2016, 2017 Kevin Kahn <snip> Made console.py executable: sudo chmod +x /home/pi/consolestable/console.py Using systemctl, enable to service. sudo systemctl enable softconsole.service Reboot the system if you want to verify that things worked as desired. Use the following to control the service: sudo systemctl status softconsole.service # Check status sudo systemctl stop softconsole.service # Stop service sudo systemctl start softconsole.service # Start service # # You can also use more conventional service commands like: sudo service softconsole stop sudo service softconsole start # If you make changes to /lib/systemd/system/softconsole.service sudo systemctl daemon-reload The script does put information about the service in /var/log/syslog: Jan 20 22:26:12 rpidisplay systemd[1]: Stopping SoftConsole... Jan 20 22:26:14 rpidisplay systemd[1]: Stopped SoftConsole. Jan 20 22:26:20 rpidisplay systemd[1]: Started SoftConsole. Probably easier to actually find the service logs in /var/log/daemon.log with this: grep -a SoftConsole /var/log/daemon.log Or use: journalctl -u softconsole.service I have not begun to look at how this might impact the python scripts that you have to control the console. My initial testing shows things work as expected, but I didn't do regression testing of many scenarios (like beta consoles). There maybe some other items that need further attention.

As far as using HTTPS for the WeatherUnderground calls, the main reason would be to secure your WU key (which I agree there isn't much value in) but it could potentially also validate that you are communicating with the WU servers. However, best I can tell it doesn't appear that the WU certificate is being verified/validated, so it really would just be just to encrypt the traffic in this case. If the certificate is verified to be valid, then you could be assured you were indeed getting the forecast from WU servers (in theory someone could deploy a DNS hack and impersonate WU without validating the certificate). There's many that believe all web traffic should be encrypted and it's just generally accepted as "good practice". But, some wear their tinfoil hats tighter than others! I just happened to be looking at the weatherinfo.py and saw the URL shortly after doing all the other HTTPS stuff, so I thought I would just try it. It probably has very little impact on the performance one way or another (WU clearly isn't running their servers off 166 MHz cpu like the ISY). I took a quick look at the json API for WU, and the icon URL's are returned. So, I presume it would be relatively simple in the weatherinfo.py to add that to what is put into a variable. But, from there I get a bit lost in how to retrieve and display the image. Let me know if you do work on it I would be very interested, but I may poke around with it myself if I have time.

Just to follow up, in case anyone else tries it...I got everything working with SSL/HTTPS, but found it extremely slow and cumbersome. It is so slow that I went back to using HTTP. I did some digging around on the forum and the limitation is the ISY hardware. It's documented (see here and here for example) that it takes 4+ seconds to establish an SSL connection (TLS handshake) for rest calls, this is because the amount of computation it takes when using a certificate with 2048 bit encryption. Those using smaller keys might not have (as much) an issue but industry standards now suggest 2048 bits as a minimum. Since I'm planning on only using these soft consoles on my private lan, I'm not worried about using insecure http. While on the topic of HTTPS and secure connections - I switched the URL for WeatherUnderground to use https and saw no downside. This is my line 81 of weatherinfo.py: self.url = 'https://api.wunderground.com/api/' + WunderKey + '/conditions/forecast/astronomy/q/' \ + location + '.json' And a couple pictures of my 7" display: I have pondered how difficult it might be to get the WeatherUnderground icons to display. Seems like on the 7" display, they would really enhance the look. So the weather might look something like: Current - 53 F Sat 53/30 Sun 48/37 Mon 51/42 Tues 54/31 (interesting the "chance of rain" and "rain" icons look the same) If anyone has any ideas how that might be done, let me know. Thanks again Kevin! I've been having a blast playing around with this and have two units now "deployed". Much appreciate all your efforts.

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

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.

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.

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

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!

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.

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.

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!

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?