kck

Just pushed release 3.9 with a number of new capabilities that had been requested by users. File watch alerts and enhanced VARKEYs This release has quite a few changes/enhancements: FileWatch alerts and screens: It is now possible to set an alert that watches the modified timestamp on a file and triggers an alert when it changes. This is most useful in conjunction with an improved capability for alert screens. The message on an alert screen will now interpolate a store variable. The FileWatch alert will reflect the file contents into a store variable in one of two ways: either as a single store value that holds the entire file or as a set of variables within the FileWatch store that will contain the values set in the file. A simple example of use would be to generate an alert screen that displays the file contents when it changes. It is possible to clear such an alert automatically after a given time interval. VARKEYs have been enhanced to be of more use in interacting with hubs. They now provide an option to invoke a program on the hub when pressed, and for HA hubs which allow parameters, pass a parameter. Their display options have also been enhanced. The net effect is that it is possible to construct a multibutton set of keys on a screen to do things like control a fan with speeds. Related to the above, access to attributes of entities in HA can now be made via the store associated with the hub, e.g., HASS:light.ceiling:brightness would evaluate to the brightness setting of the light.ceiling entity in the HASS hub. Weather fetching has been changed to operate autonomously for all defined locations. Previously, fetches were initiated when a screen needed them and there was not recent weather. Because it is now reasonable to use weather information in places other than weather screens, the console now simple updates weather whenever it expires, using the cache mechanism if multiple consoles are in use. A minor addition is to allow semi transparent navigation keys if a picture screen is used as a regular screen rather than as an idle screen which improves appearance.

I just pushed a new release (3.8) that adds a photo frame capability at the request of a user. (Something I had been thinking about adding for a long time but had been in procrastinate mode on). Short blurb from github release below and full details added to the usage notes. Photo Frame Screen V3.8 This release adds a new screen type "Picture" to the console that allows the console to also act like a photo frame. It supports a directory mode that sequentially displays jpg files found in that directory to the screen while that screen is active. The directory is monitored for changes and those are reflected in the displayed photos within a few cycles. It also supports a single picture mode that displays only a single jpg which is monitored for changes. In this mode changes are reflected to the display within 3-4 seconds and so is suitable for use if the desire is to display changing screen captures or the like. See the description in the usage notes for all the details on how it works. The release also adds support for username/password for MQTT which was previously missing. It adds an advanced network node command to the maintenance screens to clear retained knowledge of a dead node from the MQTT broker. It also will handle MQTT server down situations more gracefully. Finally, it adds a small developer oriented feature to enable personalized operations to be done on every console boot. See the Developers Notes section of the usage notes for more information.

I just pushed V3.7 of the console to github as the current release. The main motivation for this release was that the Pi4 doesn't handle frame buffers in the same way as all previous Pi versions with the result that the console may not orient in the same way as the desktop on at least some screens. To address this and also add some general flexibility this release adds the ability for the console itself to rotate its screen relative to the underlying system's base orientation. The release note is pasted below: Soft screen rotation and streamlined install This release primarily adds support for soft rotation of the display that is required for the Pi4, at least when used with the 7" Pi display. Pi 4 display drivers don't use the frame buffer in the same way as previous models so they may not honor rotations set at the system level. This results in the native desktop displaying in one orientation but the console displaying in another. The usage notes explain how to set the screen type to use soft rotation and the installation scripts now add support for this. (Note this has been tested with the Pi 7", the 28c PiTFT, and the 35r PiTFT screens at this point but should work generally.) This provides general purpose flexibiliy to arrange the console screen orientation as you like easily (and since it is set at console start changing the orientation is also very straightforward). The console install scripts have been streamlined in this release to avoid the second reboot that used to be required. This should somewhat speed up installation although the bulk of the time is still in updating the base system to current. The release also fixes a bug when an alert screen gets invoked while in Maintenance mode, a bug in MQTT status handling. It also reworks Home Assistant restart code to insure that states are correct for changes that happened while the console was offline. Finally it again adjusts the use of Adafruit install script use to handle their changes related to a 28c PiTFT.

It will stay on the web. Additionally it is, of course, open source so anyone who wants to can copy or mod it or add to it as they wish. I run my consoles extensively with Home Assistant but I'm not sure who else does. So the HA stuff has probably had less diverse use and is therefore likely to have a few more bugs. If you start using it with HA by all means report any issues or suggestions so that I can look at them.

Sure. I actually didn't intend to turn this into a system comparison - I was just trying to answer the original poster's question and assure him that there was at least one other person running things they way he seemed to want to run his. Interestingly, just today I was listening to the latest HA podcast (there is one that has a new episode for every release) and their guest said he was running an ISY as his hub linked into his home assistant configuration - so there are at least 2 of us I guess. Be clear, I support using the ISY and continue to recommend it so I don't want to be misunderstood. The state machine model has lots of side effects to consider that many folks find confusing. Look at for example the tutorials on how to write conditions. Also, the flow of a program is interrupted by anything that causes a reevaluation of the trigger condition. This is consistent with the state machine model but often not what a user who changes a state condition in the text of a program expects to happen. Loops are very limited; subroutines are separate programs and actually schedule independently of the invoker which can cause surprises. Loops and embedded if/then/else are difficult. None of this is surprising if you really understand the state machine model but it isn't what most folks who have any programming background are familiar with. The HA model has these attributes for their automations. However, scripts are much the same as shell scripts or programs that most folks are familiar with. They run to completion, have unlimited length, multiple loops, multiple if/then/else, etc. They can call other scripts in completely synchronous manner. The HA model for automations also has more control over multiple triggering of an automation (think ISY program) in that you can specify if it should cause and abort and restart (the ISY model), ignore the new trigger until while the current invocation is running, or create a parallel second invocation. They also recently added an optional "cool-down" interval between triggers that can cause a dead period after a trigger to handle in a simple manner debouncing triggers and the like. I would say that the result is that you can get by with fewer scripts in the HA model for most cases than in the ISY model but certainly you can achieve the same result in either case. Overall, if you look at the typical questions in the forum regarding programs that don't work as expected, most of them come from folks expecting script like behaviors. Finally, my other point was that IF you are planning to run HA in any case, then I would suggest using ISY for scenes and state triggers related to the Insteon devices and doing the rest of the automations on the HA side since there will be devices in your home that the HA side will know about that the ISY doesn't (else why use HA at all - stay with ISY and Node Servers). The total developer community on the HA side is huge with the result that you will be hard pressed to find a home automation related device that isn't supported with an integration. The sheer size of that community makes it impossible to keep up with given the smaller ISY community. The caveat is that it is a volunteer community for the most part (there is a core paid development staff but it is quite small). However, that community is extremely responsive (I've had multiple issues resolved in literally hours to a couple of days when raised on their forums) and the code itself is all open so you can always look at it yourself for a quick patch if you are so inclined. The release schedule for HA is every 3 weeks and these are generally very meaty releases so the pace of improvement is quite rapid. As I said - I am still a fan of ISY but I am also a realist and the UDI guys have a niche they service well but for a lot of general hobby type users HA may well be a better choice for their core platform.

Just to clarify: I was not suggesting that there were things you could not do on an ISY that you could do on HA. What I was observing is that there are 2 fairly different approaches to doing this sort of programming. The ISY uses the state machine one while HA provides both a state machine one and a more traditional procedural one. Each approach has its strengths. HA allows using the approach that makes for the most understandable solution for a given problem. I have programmed some pretty complex stuff on the ISY side of things before I had HA running. Some of those things just get a lot simpler with a pure procedural approach. Heck I used to take pride in entire complex programs in 1 liner APL code but it couldn't be my choice for maintainable code. (Some of you old timer programmer types will know what I am talking about!) Beyond this - If you are going to run HA in any case, then it will wind up with access to all your devices, even those not under ISY control. So in that case locating most of the automation programming there will just be a lot easier.

Yes - you will need an Insteon "modem" for any controller that accesses Insteon switches. (This would apply even if you wanted to use direct HA to Insteon via their integration.) I run an ISY that also talks to my HA so it sounds like you want a configuration like mine. There are pluses and minuses to ISY vs pure HA Insteon but since I started with the ISY that is my current setup. ISY has greatly improved their connectivity and opened it up via Node Servers but HA has that open connectivity as a fundamental premise. On the other hand, HA is an open source project with all the lack of commercial support that implies. I'd say the biggest differences in actual automation is that I find ISY's programming still more obscure that it needs to be. They essentially use only what HA would call automations - i.e., a state machine oriented programming paradigm. This is very good for a lot of home automation activities since it corresponds to how operations happen in the real world. However, it is far too obscure and error prone if you actually have a need for what most folks would call a sequential "program". HA has scripts as well as automations and those operate completely as a sequential programmer would expect. Automations can invoke scripts so you get access to which ever programming model fits you immediate need. A nice thing about running HA with ISY is that you can use HA for the script like operations and use the ISY for the more state machine like triggers. Your thermostat can be controlled either via an ISY Node Server or directly via and HA integration. However, if you are already planning to run HA then I'd go that route since otherwise you wind up with 3 separate entities in the loop to maintain and keep sorted.

I just pushed V3.6.3 to github with changes to installation to fix the problems noted in the previous few posts due to changes in Buster treatment of the Pi 7" screen and the Adafruit install scripts for the PiTFT screens. The release note on github: This release fixes some installation issues caused by changes in the underlying OS release support for the Raspberry Pi 7" screen and the Adafruit installation scripts for the PiTFT 3.5" and 2.8" screens. The fixes are also a bit more resilient against future changes that might occur to such scripts. While ultimately it is impossible to guarantee compatibilty with any future changes, at least the errors raised may more directly point to the problem so that it can be quickly resolved. The installation process also now gets all the user interaction done before anything else so that the long running part of the scripts that update the OS can be done unattended. The release also fixes a bug with blinking keys on clocked screens where the blinking didn't show up and a bug where a bad weather fetch from Weatherbit could pollute the weather info cache for a fairly long period of time. Some of the periodic statistics reporting in the log file has also been revised.

Arg. Another case where stuff changed under me. The script uses the Adafruit install scripts for the screens. Those scripts have never been friendly to being used by another script since they only take interactive input. Why folks don't write such utilities to have a stable scriptable interface is beyond me. So pisetup fakes the interactive input to the script and -- you guessed it -- they recently changed the input codes for no real reason (they added another supported screen to their script but decided to put it in the middle of the selection choices instead of at the end). I'll update my scripts and perhaps I can figure out how to make it more resilient to their changes. As to the speeds etc. - I don't know. They all come from the aforementioned install script so that comes from Adafruit. Thanks for catching this, figuring it out, and alerting me. Kevin

Emile, As I guessed neither you nor I did anything wrong. The Raspbian folks just "improved" support for their touchscreen. In the process they changed the name of the device so I wasn't matching on it. Not sure when it happened - sometime between last July and now I think since my existing Buster version had the old naming. Good news it that it is a very easy fix for you (and I'll update it for the next release). Go into consolestable and find the file touchdefinitions. Duplicate (or just edit) the line starting with FT5406 memory based driver and replace that string with "raspberrypi-ts". The new or edited line should appear as: raspberrypi-ts|True|0|0|0|0|1.0|1.0 That should get things working since the program will then understand what type of touchscreen it is dealing with. Let me know if that fixes it for you. Kevin

Doubt you are doing anything wrong - looks like something is different about how Buster is setting things up. The console is looking for the touch device. This should be at /sys/class/input/event0 which would be a directory. (Actually could be in an event? if there are more than one - it looks at them all.) Within that directory there should be a device/name which is a string that defines the type of handler. That gets matched against an entry in the file touchdefinitions in the consolestable directory to get the needed parameters. I actually run a 7" Pi screen as my standard development system so I can check to see what the current Buster does. In the meantime, can you check what a cat of the device/name file shows and also cat the touchdefinitions file to see if there is a corresponding entry there? Also, what Raspbian release are you using? The current one dated 2020-05-27? I'll gen up an install with that version and see if something changed there. BTW - the other exception for hlog is just a side effect of a very early in the program failure. I should probably catch all that and exit more cleanly. Setting up the hardware is about the first thing the program does so things aren't very clean for exit at that point. Kevin

I just updated the Console to V3.6.2 to better support Weatherbit weather. The service permits 500 API calls per day but it takes 2 calls to get current and forecast conditions. Thus if one runs multiple consoles with multiple weather locations it is possible to hit the limit in which case you won't get new data until the next day. This updates fixes this by allowing consoles on a network to share data with each other to avoid redundant fetches. Other than requiring MQTT in the configuration, the operation of this caching is not visible to the user - i.e., no need to pick which console does the fetch as whichever one needs the data first handles it. Release blurb from github:

Seriously weird! Just to see if something is broken in Python libs run at a command prompt "python". This should give you an interactive Python prompt. At this prompt type "import wiringpi" - should return another prompt. Now type: "wiringpi.wiringPiSetupGpio()" (case matters so be careful with that). It should return 0 and another prompt. If it does that is wiringpi working with the attribute that the log claims is missing. If this works I'm really stumped because that is the identical code to what is running in the console hw.py module. If it doesn't work type "dir(wiringpi)" which should list all the attributes of wiringpi - there should be lot of them - 203 to be exact apparently. If you type "len(dir(wiringpi))" it should say 203. Finally, typing wiringpi.__file__ should give a file name of where it was loaded from. (Remember this in case you decide to do the option item at the end.) In any case, you might try uninstalling/reinstalling wiringpi to see if that helps. First off I would upgrade your (shouldn't matter but always good to be at least close to current) pip via: sudo pip install --upgrade pip Then uninstall wiringpi with: sudo pip uninstall wiringpi This may ask you to proceed. When it finishes (it's quick) it should say is did its work successfully. At this point if you were to do the python/import/etc. from above Python should say there is no wiringpi module - you might check. Then reinstall it with sudo pip install --no-cache-dir wiringpi The no-cache-dir will force pip not to use any cached version on your system, just in case. You should see it say it is downloading and then it will do the install. By the way, you can do a: sudo pip uninstall homeassistant to get rid of those other messages, although they should be benign. That lib dates from quite a while back and is not longer in use anywhere. If none of this works I'm close to out of ideas. What you are seeing doesn't really seem to have anything to do with the softconsole code but rather with something that has gotten messed up on the system. If all this fails to tell us anything you may need to rebuild the pi. But if you want to try one more bit of debugging first (extra credit assignment) you can go into consolestable and edit the file hw.py to insert the following: with open('/home/pi/check', 'w') as f: f.write('{}\n'.format(wiringpi.__file__)) f.write('{}\n'.format(dir(wiringpi))) f.write('{}\n'.format(len(dir(wiringpi)))) after what should be line 103 which is a line that starts DimType = screendefs[ . . . and before the following line which is if DimType . . . The with should be aligned with the previous and following lines and the 3 other lines tabbed in to align with the first line in the following if statement. Python is very picky about alignment. If you do this and run the code you should get a file in your home directory called check that will show precisely what the use of wiringpi in the console looks like and perhaps we can figure out from that what the problem is. As I said this is optional to rebuilding but might be worth a try. The check file should show exactly where console is loading the module from (maybe there are somehow 2 version of it on your system) and what is in it. It should show the same file name that you saw up top from the independent python run. Really sorry I'm not being more helpful - this has me really scratching my head. Python is generally very predicable but it is a really complex language from an implementation point of view and I have seen it do some strange things.

OK - standard configuration so that should all be good. Did you still get the same wiringpi error when you did the run of the console? I assume you did since the "sha" message would indicate that the manual download didn't do anything. I think it is still wise to force a manual download to know it got staged/installed completely. First thing I'd suggest is to save your previous version. There is a directory in consolestable called previous previousversion. Save that by doing a sudo mv previousversion ~ That should move that directory up to your home directory so you have it. Next delete the versioninfo file in consolestable. That will force domanualdownload to not see the download as pointless and cause it to actually do it. You should then see the following: Install from: /home/pi/consolestable Couldn't get version info, assuming currentrelease Current hub version different Running (currentrelease): none of none Getting: c2ba46d5dc11e6b68c8e9e2db07d3b8724cd7391 of 2020-04-27T18:58:30Z Staged version installed in /home/pi/consolestable There may be a substantial delay because especially on a Pi2 there can be a bunch of library updates going on here that can take a while. After this completes there should also be a file in the consolestable/previousversion (note that this is a new previousversion from the one you moved and contains the probably bad download) directory called stagelog.log that has more detail on the install. Just for reference I'm attaching the stagelog that I just got from running this process on an old system I had laying around and not in use. I ran this and it worked fine on the test system which was a Pi3B running Stretch with an Adafruit PiTFT3.5. For reference the start of the Console.log file for this system was: 05-17-20 13:04:28 Sev: 3 Soft ISY Console 05-17-20 13:04:28 Sev: 3 © Kevin Kahn 2016, 2017, 2018, 2019, 2020 05-17-20 13:04:28 Sev: 3 Software under Apache 2.0 License 05-17-20 13:04:28 Sev: 3 Version Information: 05-17-20 13:04:28 Sev: 3 Running under Python: 3.7.3 (default, Apr 3 2019, 05:39:12) [GCC 8.2.0] 05-17-20 13:04:28 Sev: 3 Run from: /home/pi/consolestable 05-17-20 13:04:28 Sev: 3 Last mod: /home/pi/consolestable/alerts/lightsensor.py 05-17-20 13:04:28 Sev: 3 Mod at: Sun May 17 12:47:17 2020 05-17-20 13:04:28 Sev: 3 Tag: currentrelease 05-17-20 13:04:28 Sev: 3 Sha: c2ba46d5dc11e6b68c8e9e2db07d3b8724cd7391 05-17-20 13:04:28 Sev: 3 How: Offline Dnld: 05-17-20 12:46:11 05-17-20 13:04:28 Sev: 3 Version date: Commit of: 2020-04-27T18:58:30Z 05-17-20 13:04:28 Sev: 3 Start time: Sun May 17 13:04:27 2020 05-17-20 13:04:28 Sev: 3 Console Starting pid: 1571 05-17-20 13:04:28 Sev: 3 Host name: rpi-test 05-17-20 13:04:28 Sev: 3 Screen type: 35rB 05-17-20 13:04:28 Sev: 3 (Display device: /dev/fb1 Driver: fbcon Dim Method: PWM18) 05-17-20 13:04:28 Sev: 3 Touch controller: stmpe-ts 05-17-20 13:04:29 Sev: 3 (Capacitive: False Shifts: x: 0 y: 0 Flips: x: 0 y: 0 Scale: x: 1.0 y: 1.0) As always let me know if this helps. Kevin P.S. I run mosquitto as my MQTT broker. Had been running it as a native install but just recently move to running it under Docker since that helps a bit with maintenance. If you run a broker and tell your console about it, you'll be able to manage any of them from any other and once you move to Weatherbit you'll get shared updates which as I said will help keep you below their fetch limits (coming soon). stagelog.log

That's odd since it isn't something that has changed in a long, long time (if ever). Wiringpi is a library that gets used to handle dimming the screen for some screens. Should have been there if your system needed it for any previous version. Which screen do you use? I don't recall. Here are a few things to do: 1. At a console prompt type pip list. Near the end of the list it outputs you should see a line for wiringpi with a version number. Mine shows 2.60.0 - what is yours? 2. If it isn't 2.60.0 you should be able to update it via the command: sudo pip install --upgrade wiringpi 3. I noticed an extra character in the screendefinitions file on github that looks like it has been there since last August. I don't think it should impact you unless you are running a Pimoroni screen but in any case if you are go to consolestable and edit the file screendefinitions to delete the "s" in the middle of PWM19. I can't understand why that would cause your symptom in any case. Wiringpi is a raspberry pi library that provides access to the GPIO pins on the board. I only use it to adjust brightness on some screens. From my perspective it is a black box and the error makes it look like it imported wiring pi but that the module is missing one of its methods. No idea how that could even happen. I did notice one other thing though. The log of your download doesn't look complete. After that message New version fetch, there should be another message: Staged version installed in consolestable. If you didn't just cut off the log, then you didn't let the download actually finish. When you say, you manually rebooted do you mean the Pi? That could leave things in some indeterminate state. You should start the download from the maintenance screen. Then you should do the console restart from the Exit/Restart screen in Maintenance. So long as the download is still in progress hitting restart console and then proceed will just quickly flash the restart button and return you to the restart screen. Once the download completes then proceed will get you a red screen indicating that you requested a restart and it should. If you did break something with that reboot, there is a script in consolestable called domanualdownload.py. You can try that by going into the consolestable directory and then running sudo python ./domanualdownload.py. That should grab the current version on github and install it. Let me know if this helps? By the way - if you move to Weatherbit and run multiple consoles, be aware that they effectively limit you to 250 weather refreshes per day (a refresh there is actually 2 API calls and they give you 500). If you get weather for multiple locations on 3 systems you'll hit the limit at more then 3 locations if you are refreshing once per hour. I am in the process of enhancing the MQTT based multi-console support to allow the consoles to share weather for locations which will mean that the number of consoles shouldn't increase the number of weather fetches over a single console. I'm running a version of this in my house now since limit impacted me. I'll probably push it in the next week or so once I know it is solid.

DarkSky was acquired by Apple on April 1 and announced that their api will shut down end of next year (and I think that new api keys are no longer available even now). So I have updated the console with a new version that additionally supports Weatherbit as a provider. Documentation also has been updated to note this (and its location and units options). The release is up as V3.6.1: This release adds support for Weatherbit as a provider. This is to provide an alternative to DarkSky which announced ending it service in 12/21. Use type=Weatherbit for this provider. This provider supports an additional option units = 'I' or units ='M' to request Imperial or Metric reports. If omitted it defaults to Imperial.

I just pushed an update to V3.6 that now allows dynamic screen titles (to show e.g., time or current temps or whatever) as well as consistent navigation of the Maintenance screens. Release blurb below. V3.6 This release adds two major capabilities and handles a number of smaller issues/bugs. The first major change is to allow store item values to be substituted in screen titles. This permits any screen title to display, e.g., a local temperature or some other value of interest. To support this a new optional parameter ScreenTitleFields is added that expects a list of fields to be substituted. ScreenTitle now supports Python style formatting placeholders into which the fields will be substituted. If the screen is one that would persist for a long period of time but you want it repainted regularly to display field value changes you can now specify a parameter Clocked = <seconds> which will cause a repaint every <seconds>. Usefully related to this are entries in the System store for Time and UpTime. Time returns the epoch time if used bare or may be used in a form Time:<format> string to return a textual time using standard Python/Unix time formatting strings. This guarantees that changes to substituted fields in the title will be refreshed at this interval. For an example of using this to display temperatures see example file config-rpi-dev7.txt, specifically the section for LR1 or the cfg file for pgawBRmain. The second major change to how navigation works for Maintenance screens. These have always used a different style of navigation that regular screens (not using the Nav keys at the bottom). These have been changed to use tree of screens model introduced in release 3.4 to use Home and Back keys for navigation. This makes exit from maintenance always easy (Home key) and return to previous screen consistent (Back key). The release also updates support to handle the new version of Home Assistant climate devices (Thermostats) that was introduced there a while back. It will still support the old climate devices for now using the hub type HASS.0 (or since the 0 is a version value that defaults to 0 just HASS) and the new style using the hub type HASS.1. The release also has fixes for a number of small bugs and does some general housekeeping on error and log messages.

Great. When I get a chance I'll look at those other log messages to see how I can suppress them. You shouldn't wind up with a overrun log like that because then you'll miss something of note. Just out of curiosity, it the system you had the issue with a Buster system and if so, was it a clean install or an upgrade from Stretch. Just trying to understand why the auto install of that library didn't happen. (No rush answering since I'm out east all this week.)

The problem looks like it is with that failure to find the darksky module. It is essentially causing a compile error. The install scripts for the current release should have installed that library so it should be there so I don't know why it isn't. As a fix you can try going to the Pi console and running the command: sudo pip3 install darksky_weather You should see a Python library get installed with no final error. Then try running the console from the command line and see if it comes up. I am particularly surprised about this failure since most of my consoles got updated via the normal script and didn't have this issue. I understand that my development console is different since I need to manually install any new libraries there and so can have it working even though normal ones would have this kind of failure. In any case, if this fixes it I'll have to poke a bit on why the upgrade didn't do it in the first place to make sure no one else bumps into this. If it doesn't fix it, then I'll look at whatever other error causes the failure.

That doesn't look like a Buster issue. You are getting tons of exceptions from the ISY stream. I don't think anything has changed recently in ISY support. Have you done any big changes to your ISY stuff? If you see the startup log appear on you Pi console (the blue background scroll) then screen access is fine. Unfortunately I am traveling until next Sunday so can't help too much while limited to my phone screen.

I just pushed a small release V3.5.1 to add DarkSky as a weather provider given the demise of APIXU. Release comments below: V3.5.1 is a quick release to add DarkSky as a weather provider given that APIXU is going away. Use of DarkSky is pretty much the same as use of APIXU was with one notable difference: DarkSky only accepts lattitude/longitude as a location. To convert existing weather to DarkSky: go to their website and create a (free) account. Change the name of the weather provider in your config files from (probably) [APIXU] to [DarkSky]. Change the location parameter for each place from its current name to the lat,lon pair for the location. An easy way to get that is to go to latlon.net where you can input a place name or use a map to quickly get the coordinates. This release has gotten a bit less testing at my house than the usual release because of the urgent nature of getting it out but it has shown to be solid. One thing I have noticed about Dark Sky is that their condition summary phrases tend to me a lot wordier than the previous weather guys. I beefed up the term shortening logic a bit to help but you may still see more long phrases than in the past. Of course you can, as before, manually change those via the termshortenlist. Let me know if you encounter any issues with this. Kevin

I just noticed that APIXU which is the weather provider that the console uses has decided to change their name and create a much more restrictive free usage limit. Unfortunately they claim to be shutting down the old api 10/14 which, unless I missed a long standing notice, is rather short notice. In any case, it looks like my best alternative is to switch to DarkSky since they have a sane personal use policy. I'll try to get something updated quickly but it may be a day or two after the shutdown if I have any trouble since I'm going to be out of town for the next couple of days with limited opportunity to work on it. Kevin

I just pushed a new update of the soft console. As usual it squashes various bugs but it is mainly for improving multiple console administration (which I do since I have about 9 consoles running). Release note: V3.5 is primarily aimed at simplifying administration of multiple consoles on a network. It completely reworked the multi-console error indicator and command structure. If you are running multiple consoles with MQTT, when you enter the Maintenance mode you will see an additional option for network consoles. That will provide access to screens that report all available status for other consoles on the network, including the error status of their logs, the versions of hw and sw they are running, their up-time, etc. It also provides access to issue commands to other consoles (or for commands that make sense, all consoles). You can display error logs (either all or just recent errors), clear error indicators, request restarts, etc. Note that as part of this rework, the meaning of the error indicator in the upper left corner of the screen has been changed. A solid circle indicates an error report on some other console on the network while a cross indicates an error on this console. Both may be present if appropriate. Also, remote errors are no longer reported in the local log since they are directly available via the remote screens. Also note that some advanced commands for administration (accessing development versions for example) have been moved to behind double taps on the main select version and network console name buttons to reduce normal clutter. This release also adds HorizButtonGap and VertButGap parameters to allow separating the buttons on the display. It incorporates a number of structural changes to how Home Assistant hubs are handled but none of these should be user visible. This version has been tested and runs fine on Buster. However, be aware that some Buster installations seem to locate the frame buffer at /etc/fb0 and others as /etc/fb1. The code attempts to get the right buffer but if you find that the console seems to start but does not display anything, use the screendefinitions (as described in the usage notes) to force the display to what you need. The release also is more tolerant of weather outages at APIXU by waiting longer to post errors to the log when the service is not reporting meaningful weather, since APIXU seems to sometimes go autistic for a few hours.

I just pushed a new release of the console as the current stable release. Short description here and usage notes have been updated: V3.4 is a moderate update. The major functional addition is GOTO keys which now allow you to specify a tree structured relationship among screens in addition to the chain of screens supported to this point. This was a user request in the discussion thread and is documented in the usage notes. Following on to the previous release a number of console activities that can take a while have been made asynchronous including fetching weather, network health checks, checking the sha for automatic updates, and some internal debug logging. These changes further reduce any console responsiveness lag. The only visible impact is that on the first access to a weather screen for which weather has not yet been fetched you may see a momentary message that a fetch is in progress whereas previously the screen would be effectively locked while this was happening. Some console performance stats are now reported via MQTT. This release supports the Pimoroni 4" display as you may have noted from the lengthy remote development effort above in the thead. In doing this, I reorganized how screens and touch information are input into the console which should make it easier to incorporate other screens in the future, as well as to handle differences between Stretch and Buster versions of Raspbian (which have frame buffers named slightly differently). There are changes to the install scripts to allow for user intalled screens versus the set the script handles, to allow installation on Buster systems. This version has been tested to run on Buster, though since that version has only been available for a few days its use has been somewhat limited. One other small change: previously key color for a key in the off state would be dulled even when specific colors were provided for KeyColorOn and KeyColorOff. Now if both of these are specified they are used as is and not dulled.

If you do get WinSCP I have one "advanced" suggestion: When you first use it you will do a New Site to enter the host name you want to work with (it can remember any number of hosts so you can use it to get to any of a bunch of systems easily). After you enter the host name and user name and password, hit the advanced button and you'll see a list of option groups down the left side. Pick SFTP and now on the right side you'll see protocol options. Next to SFTP server it will say Default. Replace that with "sudo su -c /usr/lib/openssh/sftp-server" (without the quotes). OK it and save the site. Now you will always be able to transfer files even if they are root owned on the remote machine. It will make your life much easier.