Soft Keypadlinc-like Console from Raspberry Pi

[kck]

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.

 

[kck]

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.

 

[EVictory]

Keven,

It has been a while since I last posted on this thread and a lot has happened since then.  I have moved to a new home in the last year.  When setting up the ISY in our new house, I went with ISY firmware v5.x instead of v4.x.  I have rebuilt my two 3.5" screen SoftConsoles from scratch and created a third unit using a 7" display.  The 7" version is really nice.  In the process of rebuilding the SoftConsoles, I came across an issue you may want to know about.  I also have a question.  These are listed below.  

Issue: I attempted to run the pisetup.sh per your instructions when rebuilding the 3.5" SoftConsles.  I used the latest version of Stretch and put the pisetup in the boot directory.  When running it, I told it to auto-reboot.  I could not get the script to to run all the way through.  It would fail at or before running the adafruit-pitft.sh script.  To get the SoftConsole working I manually ran adafruit-pitft.sh and then manually ran installconsole.sh.  I was installing SoftConsole v2.8.  Incidentally, the pisetup.sh of v2.8 worked flawlessly when setting up the 7" display where I did not see this problem.

Question:  In my system I also have io_guy's NodeLink (OWLink) for 1Wire temperature and humidity sensors.  This system uses a Raspberry pi with a 1Wire HAT board to turn the Pi into a sensor controller that makes the sensor readings available in the ISY.  The v5.x NodeLink version makes each temperature and humidity sensor available as a read-only device in the ISY that can be used in programs.  I have also copied the sensors values into variables for compatibility with the original OWLink.

My question is, how can I display the temperatures in the SoftConsole?  I would like to be able to have a page that displays the various temperature and humidity values on a SoftConsole screen similar to the Weather or TimeTemp type pages.  For example, I would like to have a page that show the temperature and humidity from outside on the rear patio or in the garage/workshop.  Since I place the temperature values in ISY variables, is there a way to display the value of an ISY variable.  Another way to do this might be to query the OWFS on the NodeLink RPi directly.

You have created an assume system with SoftConsole!  The addition of the icons in the weather and timetemp screens looks great.  Thanks ahead of time for any help you may provide.

-Emile

[EVictory]

PS: I upgraded from v2.8 to v3.0 with no issues.

[kck]

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

[plingafelt]

Certainly late to this game, but see you're still developing and refining the code on Git.  This is brilliant.  I found it a few days ago and got a chance to do an install last night.  Fantastic.  I'm really enjoying this.  Thank you for sharing your creation.

As an FYI, for folks who may come along after me, on 4/15/2018 Weather Underground stopped issuing free API keys.  (Just missed it!).  From the posts there, it looks like the cheapest keys will be around $850/month....   For the time being existing keys will work, though how long that might be wasn't clear.  

[kck]

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

[kck]

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.

[Autonow]

Can I ask a question why do you need another HMI. Can you just use your smart phone? They seem to be permanently attached to our bodies 

[mwester]

Alas, my phone is not attached to my body in any convenient location -- it's usually in a pocket, and sometimes is over in the other room on the charger.  And then, of course, there are all the other phones, over which I have no control to install applications, nor do I wish to grant them access to my home automation.

Bottom line: a phone is just a remote control, and while there's some "novelty" factor in using a phone to turn something on or off, that wears off quickly.  A wall switch -- old-fashioned paddle or toggle or something like this topic's smart-switch is often the best and most efficient way to offer control for something.

There's a fork in the HA road -- in THAT direction are all those who feel strongly that remote control using phones and smart watches is HA, in the OTHER direction are those who have different ideas.  It really is that polarized... and as you can probably tell, I believe strongly that a remote control, even if it's a cell phone, is not really what HA is all about.

JMO, that and $5 will get you a mocha-latta-frappe-wappa-wappa-wing-ding at your local over-priced coffee shop! ?

[larryllix]

17 minutes ago, mwester said:

Alas, my phone is not attached to my body in any convenient location -- it's usually in a pocket, and sometimes is over in the other room on the charger.  And then, of course, there are all the other phones, over which I have no control to install applications, nor do I wish to grant them access to my home automation.

Bottom line: a phone is just a remote control, and while there's some "novelty" factor in using a phone to turn something on or off, that wears off quickly.  A wall switch -- old-fashioned paddle or toggle or something like this topic's smart-switch is often the best and most efficient way to offer control for something.

There's a fork in the HA road -- in THAT direction are all those who feel strongly that remote control using phones and smart watches is HA, in the OTHER direction are those who have different ideas.  It really is that polarized... and as you can probably tell, I believe strongly that a remote control, even if it's a cell phone, is not really what HA is all about.

JMO, that and $5 will get you a mocha-latta-frappe-wappa-wappa-wing-ding at your local over-priced coffee shop! ?

Just to play dirty...

That line gets blurred with vocal activation gadgets. Although I don't have to touch anything, or get anything out of my pocket, it is still just "advanced" remote control, and not any form of automation.

Alexa! Turn on the sunset lights!   becomes pretty convenient, although as a fellow  HA purist, I feel so violated!

[kck]

11 hours ago, Autonow said:

Can I ask a question why do you need another HMI. Can you just use your smart phone? They seem to be permanently attached to our bodies 

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.

 

[kck]

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.

 

[Screw Loose Dan]

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.

[kck]

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

[Screw Loose Dan]

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!

[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.

[kck]

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.

 

[Screw Loose Dan]

So, I had looked at my ISY logs previously and didn't see anything there.  I had presumed it was everything in the stream, as they log quite a bit.  However, I looked at my programs...and that led to an "ah-ha!" moment.

I run a program that updates a variable ISY_Uptime_Counter_hours, as one might imagine, hourly.  I display this on a keyscreen (along with a bunch of other variables).  I only have one idle screen (TimeTemp), which does not show this variable.  And, I'm fairly certain the majority of the times I was seeing the error message I was not interacting with the softconsole and it was on the idle/dim screen (TimeTemp).

To confirm all this, I initially removed that section from my variable screen, and sure enough the next hour no error message.  To further confirm, I made a variable (Count_tmp) and another program that would update the variable every minute.  I added the Count_tmp variable to my variable screen, and sure enough:

10-08-18 14:20:19 Sev: 4 Unexpected ISY event to screen: TimeTemp00
10-08-18 14:21:20 Sev: 4 Unexpected ISY event to screen: TimeTemp00
10-08-18 14:22:20 Sev: 4 Unexpected ISY event to screen: TimeTemp00
10-08-18 14:23:20 Sev: 4 Unexpected ISY event to screen: TimeTemp00
10-08-18 14:24:20 Sev: 4 Unexpected ISY event to screen: TimeTemp00

Not sure if this is the same issue that is occuring for you , but figured I'd pass it along.  This is probably more information than you need, but if you want to reproduce it...

This is a snippet from my variable config:

[[Uptime]]
     type = VARKEY
     Var = ISY:Int:ISY_Uptime_Counter_hours
     Appearance = 0:48 red 'ISY Uptime $ hours',49:168 yellow 'ISY Uptime $ hours',169:17520 green 'ISY Uptime $ hours'        
[[Count-tmp]]
     type = VARKEY
     Var = ISY:Int:Count_tmp
     Appearance = 0:48 red 'ISY Uptime $ mins',49:168 yellow 'ISY Uptime $ mins',169:17520 green 'ISY Uptime $ mins' 

And this is my program to update the Count_tmp variable:

If
   - No Conditions - (To add one, press 'Schedule' or 'Condition')
 
Then
        Wait  1 minute 
        $Count_tmp  = 0
        $Count_tmp Init To 0
        Run Program 'Count-tmp' (Else Path)
 
Else
        Wait  1 minute 
        $Count_tmp += 1
        $Count_tmp Init To $Count_tmp
        Run Program 'Count-tmp' (Else Path)

My uptime program is identical, except different variable and only runs once an hour.  With no If condition it kicks off at startup and continuously runs (mostly in a wait state).

Hope it helps!  At least I know it's really not an issue for me.

Thanks again!

[kck]

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

[Screw Loose Dan]

So, I've been playing around with the new weather provider, APIXU.  Being fairly far out in the suburbs of Philadelphia, they don't seem to have many close stations.  The temperature reported by APIXU for my zip code is usually ~2° cooler than what WU and my own outdoor thermometers display.  I suspect this is because the actual location they are reporting for is a several miles north/west of my actual location.  For all of WU's flaws, there were several folks in my neighborhood with PWS's, so it always seemed to have a good idea of what the local weather was doing.

I did see on the Weather Underground API retirement announcement that they are indicating:

Quote

 

• Your subscriptions, and therefore access, will continue to work through 12/31/2018.
• For developers who use WU API data for non-commercial purposes, you will have access to a new plan for a personal use, low call volume API. Stay tuned for more details as we build this out.

 

I'll probably just learn to deal with the new weather service (2° is really not that significant for me).  Perhaps if I get motivated I'll look at some other services...but that's not likely.

[kck]

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).

[mwester]

FWIW, I'm also still waiting for an email to tell me what they'll be doing for me -- as this lingers, I'm more and more inclined to stop reporting my weather station to Wunderground, and switch to something else -- there are other, more open, platforms out there (although they currently lack the density and coverage with regard to personal weather stations).

[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.

 

[Screw Loose Dan]

Thanks for the fix!  I pulled it down a few hours ago and haven't had any errors since.