kck

I just pushed a very minor fix for the items ScrewLooseDan was seeing in the log. It has a few other internal improvements but most of the other stuff is probably only of interest to my setup (Sonos etc.) Release comments on GitHub: V3.11 is a very minor clean up from 3.1. It fixes some benign error reports that didn't belong in the code. It also continues to imporve some of the communication error reports that can occur when packets get dropped between hubs and the console. A general improvement is that when you access the maintenance log when there is an outstanding "error in the log" indicator (see 3.1 release) the console auto pages to the first unseen Warning or higher message in the log. For Home Assistant hubs it handles a few more types of node report messages without logging them as anomolous and fixes issues with running HA scripts from a console key.

Yup - that is the announcement that I accidentally tripped over a couple of months back. No email to folks with accounts - if I hadn't been doing something that took me there I still wouldn't know. And now it is essentially 60 days from their shutdown and they still can't provide any info on new options or api. For a company like IBM this really is pretty disgraceful. I intend to keep an eye on what they do since the local nature of the personal stations is indeed nice and I use a few myself even in the city (we're 500 feet higher at my house than PDX airport so in winter temps above/below freezing can make a big difference). There are a few other providers that supply weather for free for non-commercial use - picked APIXU somewhat randomly after cursory look at a few. If you happen upon one you think would be better I think the code to add it should be pretty easy - certainly compared to the rework I had to do to get APIXU added. If WU creates some free option that looks interesting I'll probably add that. But given their recent behavior it sort of looks like amateur hour there. Meanwhile, I will probably push a small update next week that fixes the annoyances you have in the current version. I was also adding a bunch of fixes/improvements for my Home Assistant based version that runs my seasonal house and I just want that version (finished up I think yesterday) to run on all my systems for a few days before I push it only to discover some silly bug. By the way, for really local temperature/humidity I have built a bunch of little MQTT based thermometers from these: https://www.aliexpress.com/item/Upgraded-version-ESP-01-ESP8266-serial-WIFI-wireless-module-wireless-transceiver-ESP01-ESP8266-01/32889696429.html?spm=a2g0s.9042311.0.0.3da24c4dS5vL57 https://www.aliexpress.com/item/ESP8266-ESP-01-ESP-01S-WIFI-Module-Adapter-Download-Debug-Link-Kit-for-Arduino-IDE-USB/32885857400.html?spm=a2g0s.9042311.0.0.3da24c4dS5vL57 https://www.aliexpress.com/item/High-Precision-AM2302-DHT22-Digital-Temperature-Humidity-Sensor-Module-For-arduino-Uno-R3/32759158558.html?spm=a2g0s.9042311.0.0.3da24c4dS5vL57 for a total price of about $6 each (not including a small plastic case I print for them). I run the Tasmota firmware on them so no work there other than loading it. I use them for outside temps and for inside temps in a far part of my house away from the thermostat. Probably a waste of time but, hey, it's a hobby. Those ESP-01 are really great for anything that require almost no local computing but WiFi access, like remote relays (built a few of those as well for various needs).

Thanks so much for the detailed analysis. Pointed me right at where the issue is. Variable change reporting uses a different path through the code than does node state changes and that path results in an alert to whatever screen is showing at the moment the variable changes - whether the screen cares about it or not. Oops. I'll need to think a bit about the right permanent fix. It may be that the logic is overly complex in trying to only tell screens what they have said they want to know. That is some very old code at this point that dates from well before things like variable reporting was in place. It may be I should just report all changes to the screen that is up and let it decide if it cares. But since the code is so old I want to be careful just changing it. In any case, the message you see is completely benign and with any luck it will go away entirely in the next release. Really appreciate the effort you made diagnosing this since I didn't have any screens with quite the situation you have I would only see this on a very intermittent basis and that wasn't enough to get the pattern. Kevin

That probably shouldn't really be a warning level log message but I've been trying to find a benign race condition. I see it intermittently, generally related to changing screens from the console. This is the first time I have seen it so repeatable. Do you have any sort of periodic alert check by chance? A bit of background on the message: whenever a screen is becomes active (i.e., is actually what is on the physical screen) it registers for events related to nodes it care about. This is do, e.g., a key screen can change the look of a "key" if it is turned on/off from elsewhere. Many screens have no related nodes (e.g., timetemp screens) and don't expect to see node events sent to them and this message comes from the underlying screen display definition if an event is forwarded to a screen that hasn't defined any event catcher. Where I have seen this raised it is because an event was en route at the same time that a screen change happened to an uninterested screen - but I couldn't figure out why this particular race was even possible hence the error message. The fact that you are seeing it so predictably suggests that something appears in the ISY event stream in a predictable way that is getting forwarded to the displayed screen. Bottom line: I'll downgrade the level of the message when I next am in the code but if you think of anything that you have in the ISY that happens at about that interval (a program perhaps that runs every hour on the half hour) I'd be interested because I'd still like to figure out why the race can happen at all.

Dan, Glad to hear it is still working for you. Obviously I'm using it but it's nice to know it of value to others as well. Sorry about the screen type change. I debated what to do and thought about doing what you suggested - maybe that would have been better. With WU going south (not to mention their flakiness) I wanted to add or move to a different provider and knew I'd break the config for the keys. Mostly I hated having the legacy screen version hanging around once WU actually goes away so I opted for change it's name so I could delete it, but at the least I probably should have made it even more clear in the announcement that you needed to make that change. As to your 2 items - happily I can easily answer both to your liking. Setting LocationSize = 0 does indeed just completely skip the label and it doesn't per the code use any space since it literally just skips over the code that renders the location label. So you should be good there. The TimeFormat things is a weird side effect of the Python package I use to parse the config files and how it treats strings and lists. TimeFormat needs to be a list internally (a list of 1 is fine). But the library turns a string into a list of characters (in Python that is sort of what a string is) unless the string is itself an element of a list. So in your example that works TimeFormat gets parsed as a list of 2 strings whereas in your other example TimeFormat turns into a list of those characters (not at all what you want). But the fix is easy, if non-obvious. Put a trailing comma on that first version: TimeFormat = "%-l:%M: %P %a %b %-d", This turns TimeFormat into a list of strings of length 1 and should get you the single line version. I do have some discussion of this weirdness in the usage notes but it is pretty arcane and something I wish I could get rid of. But it is pretty ingrained in how I use the library. I hope this sorts things out for you - if not let me know. Kevin

I just pushed V3.1 of the softconsole in case anyone is using it. There is one non-backward compatible change in it regarding the weather provider (but it now supports APIXU as a weather provider in addition to the increasingly flakey and soon disappearing WeatherUnderground). Below is the release comment and the full documentation in useagenotes has been updated for all this (by the way I have 8 of these units currently between 2 houses): 3.1 of softconsole adds a number of new/updated capabilities. Of most importance is weather support. WeatherUnderground has become increasingly flakey as a provider and they have now announced that will drop support for their current API at the end of the year (they claim they may replace it with a new personal API but have no details at this point). As a result the release adds support for an additional weather provider, APIXU, who provides free weather for personal, limited use (10000 calls/month). Structurally the program has actually separated the weather provider part from the rest of the weather support logic so it would be straightforward to add other providers by modeling them after the apixustore.py file. (Basically, this code simply has to map the, typically JSON, returned by a provider to a standard form of naming using elsewhere in the console.) Unfortunately, adding this support made it too difficult to maintain backward compatibility of the config file so you will need to update yours even if you are using WU by adding section(s) to define weather provider(s) and sections to define internal location names from which weather is to be fetched and map to the provider's location code. See the example auth.cfg, weathersources.cfg, and any weather cfg file for example of how this works. The WU proveder has been made more robust in an effort to deal with the WU flakiness in the meantime (things like missing sky conditions, out of date data, stations gone missing, etc.) Some other changes: This release also updates Home Assistant support for their new authentication regime (post 0.77 of HA). Use their access tokens and supply that as the password. A small added feature is the display of a small light (unobtrusive) dot in the upper right of the display if a Warning or Error level entry has been made in the log file since the log was last looked at. Accessing the log from the maintenance screen clears the indicator. Two new screen types have been added that will probably not be of interest to anyone other than me that support Octoprint (a manager for 3D printers) and Sonos systems. The Sonos screen depends upon Home Assistant running. The termshortenlist has been moved to the Console directory (where as a config type file it really belonged) for : As always lots of little bug fixes throughout.

By the way - if anyone is using Sonos then via the Home Assistant support you can have any or all your Sonos speakers say anything you want via that path also. I have added Sonos control via HA to my version of the softconsole (probably will push that version if anyone else wants it) but am not doing any announcements at this point. Just another possible way to voice things from the automation system.

Absolutely. I don't mind adding some cloud services as extra conveniences in places but as an example, last night my cable modem glitched and the house lost internet. All the "Alexa, turn on the office light" in the world would not have gotten me the lights turned on so I go reboot it. As a basic level home control should reside in the *home* from my perspective.

Pretty much a personal choice I guess. As pointed out, a phone isn't always with me around the house. More to the point, the last thing I want to do when going to bed is to find the phone (probably on a charger), authenticate, open an app, then get to turn out the lights in the bedroom etc. This way it's a simple console sitting next to the bed on the bedstand - one on each side. I can guarantee you that even if I were willing to do the phone thing my wife most certainly would not. This is even more an issue when waking up while it's still dark. Find a phone to turn on the lights and set up the bathroom? It's rather like the wall switch - don't need those either but hard to see getting rid of them because they are the right solution in the right place. As to voice control I have more mixed feelings. While I do use it on occasion I find that it still wants me to repeat things too often for my taste. Worse, if my wife is upstairs and I use the voice system she hears me speaking but can't understand what I'm saying so the sequence goes: Alexa turn on the kitchen light, "OK". (wife shouting) what did you say?. (me shouting back) nothing. So whether voice is effective is a complex of how good it is and the environment at the moment. So all in all my console is very popular with my spouse and others who have reason to use it. Lots of tools - pick the one(s) you like best for the situation you are in.

I just pushed a minor bug fix release to clean up a few odd race conditions. It also has an alternate initial setup script p10setup.sh that is meant to use with the stretch-lite version of Raspbian particularly for Pi0 systems. It does not install VNC so all remote access needs to be via ssh. I have used this version to rebuild all my home systems to get them on a stretch OS version so I know it installs and works on Pi2, Pi3, Pi0 baseboards and 35r, 28c, and 7 inch displays. One side effect of this is that I no longer have any Python2 systems running. I don't think I am likely to break anything soon, but I would suggest anyone using this eventually do a full reinstall that uses Python3 as there are some subtle language differences and eventually one will inevitably bit me. I have looked at alternative weather providers and APIXU seems like it may be a reasonable choice. Unfortunately I won't get a chance to work on it for about 2 weeks since I'll be traveling. However, once back I should be able to integrate them as an alternate provider. A side effect of that change will be that it should become very easy to add other providers since I'll make the weather fetching a general configurable module. If anyone has any opinions on these guys versus another free source, do let me know since I could pick a different provider as the initial WU replacement.

Thanks! I just saw yesterday that WU was dropping new free API keys and who knows how long our existing ones will work for. Particularly given that WU was founded and runs based on a network of user owned weather stations that provide WU their data for free, this really is slimy. Once upon a time I would have expected more from IBM (who now owns WU). I noticed this because I was trying to track down an intermittent issue where WU provides nonsense for the forecast - specifically they return a forecast for Jan 3, 2018. This got my attention when I saw snow predicted for the next day after our mid 70s weather! For this I'm putting some new code in the next release to notice this case and continue to use the existing forecast on the assumption that in one of the next fetches they will send valid data. Since it seems random on their end this is a good bet. In the meantime I am also looking around for a new source of a free weather API. There seem to be a few possibilities but if anyone here has a suggestion I'd love to hear it. In some sense the best bet would be NOAA since they are by definition going to be free for low use rates as a government provider. However, I don't think (need to check) that their interface redirects to a Canadian met office and I know there are some Canadian console users. It should be pretty easy to adapt the existing screens to a new source (I'd guess a couple of hours of work) so I just need to find/choose an appropriate one. Kevin

Good to hear you're enjoying it! I agree that the 7" screen is really beautiful and the weather icons really make it pop. Thanks to ScrewLooseDan for motivating me to get the icons working. Not sure what the issue was with 2.8 install but I am glad you worked around it. It sounds like a problem with the adafruit script. Those guys are really bad about keeping a stable interface to their scripts to allow folks to use them within other scripts. I have asked them, to no avail, to create a more stable non-interactive interface to the scripts that I can count on so that random problems don't occur when I release an install script and then they make some random change after my release that breaks the release. I suspect this is what you saw because the 7" install doesn't use their scripts at all. I'm about to push a minor fix in the next few days for some things around my house, while building new software loads for my console some of which are a couple of years old running on 2 version back Raspbian so that should test installs at the moment pretty well. You should be able to get to the ISY variables in the console via the store mechanism. They should be available as State:varname or Int:varname and be useable anywhere you can mention a field name on a timetemp screen. Take a look at the timetempLQ7.cfg example file. There I use a variable from MQTT as MQTT:PatioTemp but it could have come from the ISY as something like ISY:Int:MyTemp. You can also use the VARKEY if you want to show it on a keyscreen. A $ in a key label will get substituted with the value of the variable controlling the key (take a look at the example testconfig.txt in the LR1 screen). I think the writeup for the VARKEY in the usage notes is also pretty complete. If you use the VARKEY approach you can also change the color of display based on the value to grab attention if things are extreme in some way (e.g. below freezing). If this doesn't make sense let me know. By the way - I do a display like you are wanting at our seasonal place where I have a wifi temperature/humidity sensor. There the sensor publishes its values via MQTT and I display those. Same idea as you want I think - just a different reporting path. For an application I have here in Portland I'm planning to also use MQTT and the console to push the values back to ISY variables - again same idea just a different data transfer route. Kevin

I just pushed a new version (3.0) of softconsole as current release. This completed a major restructuring of how the hub was handled which allowed me to add multiple hub support and expand the console to use Home Assistant hubs. The motivation for this was that I was installing some zwave switches in our seasonal house and wanted to be able to control those and the current state of ISY support regarding zwave plus and v5 versions didn't leave me comfortable yet. So I opted to put these devices under Home Assistant control (running on a pi). Softconsole can now be configured to talk to multiple hubs of either ISY or HA variety. Thus for anyone with multiple ISY hubs on their network, the console can handle these, or like in my case handle a combination of ISY and HA hubs. This engendered some changes to the format of the configuration file to define hubs but the old syntax for just a single ISY hub is still supported. Any screen can specify the default hub for that screen of just inherit the overall default hub. Any individual key can specify the hub that handles the node it controls. Thus a single screen can have keys corresponding to nodes handled by multiple hubs. Thermostat control via the HA hubs has only been tested for Nest thermostats since that is what I had in my seasonal house, but since this uses only the standard HA "climate" domain it should work with others. One change that I made to thermostat control for the HA systems is that changing setpoints initially is just done locally on the console and shown with greyed setpoint values. Once you pause touching the screen for 2 seconds these are pushed to the hub, and the setpoint display is made normal looking once the hub confirms the changes. This makes the screen more responsive but more importantly deals with Nest restrictions on rates of cloud interactions (boy I hate systems that require the cloud for what should be local access). I play to eventually propagate this approach to the ISY thermostat screen as well as it gives a nicer user interface. There are a variety of other internal changes associated with the release but these should not be particularly visible. I've had the 2 node (ISY + HA) configuration running for a month or so in my place and it all seems quite stable. The usage notes on-line have been updated with all the new information. Here is a copy of the release blurb from GitHub: V3.0 of softconsole is now available. This is the completion of some major changes that allow the console to operate with ISY and Home Assistant hubs. A single console can connect with multiple hubs (multiple ISYs, multiple HAs, or a combination of both). The Home Assistant support includes support for Nest thermostats via HA and probably supports other units since it uses the standard HA climate interface but hasn't been tested with units other than Nest. It also moves to a fully cached state model which makes entering a new screen slightly faster. While no instance of the state being out of sync between the hub and console has been seen there is an alert proc available that can be run periodically (e.g., once or twice a day) to verify the cached state correctness. Existing config files should be compatible but there is a new format to support multiple hubs. Also added is support for a hub becoming unavailable for some period of time due to reboots, network issues, etc. Key screen with keys corresponding to unavailable nodes now display as unusable.

A new version of the softconsole (V2.8) is now available. This version has some sizeable internal structural changes and so may have some residual bugs but I have tested it as well as I can at this point. It adds a number of new capabilities (all of which are documented in the usage notes). It now supports subscribing to one (or multiple) MQTT servers for information that can then be displayed as part of screens or can be pushed to an ISY variable. While this is primarily to allow local non-ISY information to be added to screens it can be used as a quick way to connect your MQTT server to your ISY. The way ISY variables, local softconsole variables, weather underground data, MQTT subscription values, debug flags, and even some system configuration values are handled has been unified in a common store format that allows any of these values to be displayed on screens that allow such references or copied or changed when that makes sense. For details read the section of the useagenotes on "stores". ISY node names can now be referenced as fully qualified rather than just by a their simple node name thus allowing the same node name to be used in different parts of the house. Periodic alerts can now be triggered at specific times of the day as well as on a regular time cycle. There is a new type of "key" that can be defined on a key screen that can reflect the value of an ISY (or any other, e.g. weather) variable with different colors. This allows creating "status" screens that show such things as house or environment status with easily observed colors. E.g., external temperature below freezing, heat running, etc. can be visually portrayed. This type of key also can be used to sequence through setting a corresponding ISY variable to a set of values with color change as the feedback. There are also minor bug fixes and small changes in how some parameters are set, with all user visible items documented in the usage notes. Deprecated parameter settings will now cause warnings in the log file to alert that these items will permanently change in the future and should be updated when convenient. Finally, for the programming types among you the code base is now compatible with both Python2 (which is what it currently installs and runs under) and Python3 (which is the new version of the language). With Python2 support planned to end some new libraries are only being build to be Python3 compatible and I wanted to be able to use these in the future. As always, if you trip over something I missed please let me know I will try to get it fixed quickly.

V2.7 is now available as the current release. This version primarily adds better weather display (thanks to Screw Loose Dan for suggestions and test assistance). There is an option for 2 column display of the forecast which works really nicely on the 7" display. Also, you can now have the icons for the weather displayed for the current conditions and the forecast. While the impetus for adding this was the larger display format, it turns out to look really good even on the 3.5 inch display which surprised me. There are also a number of small bug fixes and internal improvements in handling wifi outages, install prompts, etc. For tiguana's problem above I have attempted to deal with scenes that have unknown nodes in them (which I don't think should normally occur in the ISY database) by logging the anomaly and continuing. I have also added a general ability to dump what I am getting from the ISY at startup so in the future I can more easily try to diagnose any issues that folks might see. I hope that benefits both me and users in getting quicker fixes to problems.

That's very strange. I just did a clean install to see if I could reproduce and my install ran completely normally. It almost looks like you got a different helper2 script from adafruit (I just use their install stuff) or that the script got corrupted. I did notice that your download of the script came from a different IP address but I assume that is just github having multiple servers. In my script it appears line 145 is a pip command which is a standard python command. FYI - the log from your run of pisetup should be in earlyprep.log in the pi home directory so you can look at it without staring at a putty or other screen. I am attaching the earlyprep.log from my run just now and also the helper2 script. You might diff the latter to see if yours is different or at least look at line 145 to see what yours barfed on. The places where it looks like input was requested are fine. I create the answers to those questions based on your earlier inputs or softconsole requirements and feed the answers to the helper2 script so in the log you see the questions but not the answers that my pisetup script has supplied. Let me know if you find anything when you look at this again. earlyprep.log adafruit-pitft-helper2.sh

Just got back online from some travel, hence the slow response. The console has been primarily tested against the 4.x releases since I am not running 5.x. However, there was one user a while back who ran it against a 5.x release ok once I added support for a change in how certain values get reported to the console by the isy in 5.x that differed from 4.x. However, I don't think anyone has tried running against an ISY with a nodeserver in the mix. I suspect you may have one? It appears that the ISY is reporting a strange looking address of a device that I am guessing may be a node server because the address looks like a MAC address of some sort. If you look at your ISY what device does the address "00:21:b9:02:00:b3" correspond to and is it something other than a standard Insteon device? From the log you provided it looks like that device is part of a scene and when I try to construct the internal data structure that represents that scene the device isn't already in my data structures. That shouldn't occur for any Insteon device because I have already read all of those. So I am guessing that there are some other node types now in the 5.x firmware that require a different type of read. If I can figure out what they are and how to read them I can probably fix this. Otherwise I suspect I can just catch this and ignore the device. So long as you don't try to have a console button that uses it that should be ok (using it just wouldn't do anything). The other restriction from this may be that you can't use such a device as the proxy for the scene since I don't necessarily know how to get its state. Anyway, it you can tell me something about what that device is maybe I can figure something out. Kevin

Good to know things worked. I assume you meant VNC when you said VPN? The normal setup doesn't install VPN (though for some personal uses the old OpenVPN install code is still in that script though I don't use it any longer so probably should delete). If you mean VNC then to some extent that dates from a couple of Debian versions back when no VNC software came with Wheezy. However, even now I can't get the stock setup to work for me, although I'd certainly prefer to use it (though I'd still like to move its port assignment - not real security but a practical matter at times when I want to open a forwarding port in my router to get at it from outside and it immediately attracts attacks like flies). Perhaps you know how to get the right outcome more simply. The virtuald service won't run because that requires a license. The x11 service works but once I move the console to the small touch screen rather than hdmi, then the virtual terminal it opens grabs the x11 screen running on the touchscreen which is too small to be usable. If I don't set up the touchscreen that version works fine. So I just forcibly create the separate VNC/X11 terminal. Perhaps I should try not moving the console off HDMI - it used to be I wanted access for sure to that console but now I probably don't. Regarding your comment about the config scripts, I've tried to keep that whole process pretty simple. Please let me know what trips things up since I'd certainly like to fix any "gotcha" items. I run that script so often I could do it in my sleep so I'm a very bad test case for it. Any suggestions on simplifying the install are certainly welcome.

I just pushed a new release (2.6) that switches control for the console over to systemd as suggested and pioneered by Screw Loose Dan above (thanks Dan!). This really is a cleaner approach and it gets rid of some pretty fragile shell scripts and some odd logs that captured bits of information since that info is now either in the Console.log or it is in the syslog where systemd sends it. Here is the blurb from the release on GitHub: This is a major change to how the console gets started in that is moves from using the old and rather fragile rc.local file to using the systemd services manager that has become fairly standard for Linux. If you do a clean install of a new Pi system (burn a new SD card and run pisetup) you will get a console controlled via systemd and this is the best way to do this upgrade. However, you can simply upgrade an existing 2.5 system using the normal upgrade process. In this case, the system will set everything up for systemd but it will not enable it and it will leave the existing rc.local untouched as the way the console gets started. This is because blindly editing rc.local could be dangerous if you have put other stuff in there. So if you do the upgrade route I suggest that you eventually manually edit rc.local to remove the console start part of the script and then enable the service via systemctl. See the usage notes for a more detailed explanation. There are also a bunch of small bug fixes in the release including allowing for up to 10 forecast days on weather and adding an option on the 7 inch screen to flip it for power plugs on top instead of bottom.

The startup code and related stuff evolved from things I had specifically on my Pi systems but that were irrelevant to others. When folks said they'd like the code I never really cleaned all that up - but you're right that I should and moving to systemd initialization would be the catalyst for that. The strange network testing stuff was in response to some specific Pi network hangs that I was seeing and I had left it in place in case they reappeared. But ultimately it turned out that most of those were caused by a specific WiFi adapter that had some strange issues. Also, later OS releases seem to have further hardened the network stack There actually is a flag file for using the beta version along with some auto fallback logic in case the beta version blows up. I think all of this can be cleaned up in a systemd implementation. I think we'll be able to rely on the systemd restart for some of that and ditch the scripts. The main thing I want to test is the autoversion update to make sure that the right directories get used since there is some odd switching of directory names involved and it systemd hangs on to inodes rather than actual names it may not grab the new stuff. The other thing I'll want to do is to allow the in program maintenance option to shut the console down without restart if desired. Systemd allows result codes to be passed back from a service that is terminating so I think it should be straightforward the use those to get the correct actions. I just need to paw through all the little detains but I do think you are right that moving to systemd will be a much cleaner approach. I'll put this on the list for next week when I'm home. Kevin

The systemd change is something that's been on my "someday" list for a long time so thanks for looking into it. I'll need to see how it interacts with things like program commanded restarts from the maintenance page and auto version update and restarts but I should be able to sort that stuff out and incorporate the changes into the standard release.

So I took a quick look and it seems like it should be fairly straightforward to grab and display the icons. I'd probably need to play around a bit to get the scaling and positioning correct. I'm off scuba diving for the next week so not near a development system so the soonest I can get to look at it is 1st week of Feb. If you want to play with it sooner feel free. I'll probably need to modify weatherinfo.py to grab to icon and then weatherscreen.py to munge the formatting to allow for displaying it nicely. Don't think it will be a huge amount of work - just perhaps a bit finicky to get appearance right.

Nice stand. I'll add an installation option to not flip the screen next time I touch the script. I had not wanted the power coming out the bottom for my situation but with that case it works well that way. I'm sure there is a way to add the weather icons - I'll have to think about that one. It never seemed to be worth it on the smaller screens but on the 7" I agree it would look good. I don't think the issue is with fetching them - it will be with figuring out how to describe the screen layout you want since I let the config file control that. By the way is there any real advantage (other than I guess securing your WU API key which is free anyway) in using an https connection there? I can certainly change that to use the secure option. Interesting observation about the speed of https on the ISY. I hadn't realized that although I had noted that for a lot of things including startup it is pretty slow. I may uniformly up the time outs a bit anyway to cover folks who want to try the secure option. Like you, my systems all run on my home net so I don't worry about it much. I try not to make the timeouts too long because then you can get some pretty long pauses when there is a network glitch that can make you think things are hung. So it's a bit of a guess what the right timeout should be. Where I really ran into issues initially was handling a whole house power outage because the Pi systems are back up in seconds whereas the ISY takes a good while to get back up. That made the pi systems "lonely" they would hang or die. Now they have been taught to have patience. Kevin

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.

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