kck

Cool! Would you mind if I added it to the standard distribution so it would be generally available? Everything about Antarctica was fantastic - the most amazing scenery I've ever seen. You just can't get the sense of grandeur from TV shows - the scale gets lost. And the penguins are incredibly cute!

Yes. See the parameters KeyColorOn and KeyColorOff and KeyCharColorOn, KeyCharColorOff, and change wording KeyLabelOn, KeyLabelOff. Also KeyOffOutlineColor and KeyOnOutlineColor

Chris, Definitely just get the current stable release. It has the fix for the report/clear message and your ssl ignore in it. I can't tell you much about the zwave via ISY stuff. I do run Zwave but control it via homeassistant and the console also handles homeassistant hubs so that works for me. If the sensors have an option for reporting via an MQTT broker that would also work pretty easily. That is how I handle some other sensors that I built (sub $5 temperature/humidity sensors using ESP-01 board and DHT-22 sensor). The console can parse MQTT messages and extract things like temperature from those. But I don't have any idea if your sensors have that option. Kevin

Chris: Yup that error sucked at telling you the location field didn't match. EVictory ran into the same problem last week. That's the problem when you are testing your own code - sometimes you just don't make some errors/typos to see how bad the messaging is. I've fixed (trivial 3 liner) both the TimeTemp and Weather screen creation code to catch this in the future (so at least some future person may thank you). That fix will go into whenever the next release happens. Glad Dan could point you in the right direction. Dan: After you reported that the explicit python3 didn't work I looked and there is a small starter program "runconsole.py" that decides whether to run beta or stable etc. and it just used "python" to start the real script. I can edit that to use python3 for the next release but in the meantime you can just edit the one line that does the subprocess.Popen to use python3 and I think that will do it for you. (ETA: also edit the 1st line that indicates the script interpreter for runconsole itself to say python3) Way back when I started this I didn't know anything about Python deployment or I would have used something like the venv mechanism to compartmentalize the console. Unfortunately it would seem to be a lot of work to get there from here at this point. You might look to see whether the other stuff you are running can be installed with venv - that would let it set its own libraries and interpreter versions.

You could go to the systemctl service file and edit it for the console to use python3 instead of python. That should explicitly run python3 even if you switch the alternative that python maps to. The Python folks keep saying that python 2 gets deprecated at the end of the year but given the number of programs that still seem to require it I'm beginning to doubt that.

The console only support APIXU as a weather service. It used to support WeatherUnderground but they went away/pay only. APIXU has free signup for limited but very sufficient calls/day. The VARKEY key type on a keyscreen is the answer for this. It can be used either for display only or for setting variables. Basically it allows you to change the appearance of the key based on an ISY variable value (e.g. red if 5, orange if 1-4, green if 0). It's documented in the usage notes. Again the VARKEY so long as you can get an ISY variable to hold the value. Alternative is to just reference the variable value and show it on a weather or time/temp screen using the store reference syntax. I do that to display the local temperature on my deck along with the general weather I get from an APIXU feed. There are examples of this in the example config files, see e.g., timetempPDX.cfg.

Dan, The light sensor would be nice - of course it would require some hardware added to the Pi. Have to think about that as it would be a bit more than some folks would want to tackle. However, the time based change you can do now pretty much. All the screen general variables are in the store "System" so in particular the DimLevel is referenced as System:DimLevel. So I have a couple of alerts defined in my configs that look like: [Alerts] [[AdjustScreenDim]] Type = Periodic At = 11:00pm Invoke = AssignVar.Assign Parameter = System:DimLevel = 5 [[AdjustScreenDimUp]] Type = Periodic At = 6:00am Invoke = AssignVar.Assign Parameter = System:DimLevel = 50 These do the obvious things. The only issue with them is that since they execute at a specific times so the initial condition after console start will persist until the first time one executes. If you are running MQTT then you can even do the adjustments via that if you publish the right stuff. For example, using mosquito you could run the command: mosquitto_pub -t consoles/rpi-pgaw1/set -m '{"name":"System:DimLevel","value":50}' To change the brightness of that node right now. This is handy if you want to quickly experiment with dim levels - just reissue it changing the value. You could even send this to all your consoles with a single command if you replaced "rpi-pgaw1" in the above with "all". So it wouldn't be too hard to do more sophisticated changes by running scripts from cron or the like. Other system variables are also changeable if that's useful. Do a StoresDump from the debug flags screen and you'll get a file in the Console directory with a full dump of what the stores hold and in principle you could change any of them. The caveat is that things that impact screen colors and the like may have been already used to build templates and so not have any effect, although I think background colors would change. I know key colors wouldn't generally change. Figuring out how to make all those actually take effect dynamically is actually on the longer term todo list so if there are any items that you think would be useful to make sure are actually changeable let me know. Does this handle your immediate desire? Kevin P.S. Going to Antarctica to see the Penguins!

So I pushed 3.2.1 as the current release. Mostly minor bug fixes and better dealing with V5 ISY Node Server devices that I don't otherwise handle to avoid lots of log entries.

Great - thanks for letting me know. Sorry it was a bit of a hassle to get initially working. I try to test everything I can but some stuff I don't run and so depend on testing blindly with some folks like Dan who do. Given your comment I won't worry about figuring out the alternative approach. Don't think it would add any real security inside most homes anyway. Kevin

OK - think I have a workaround for now. It appears that the library I use doesn't pick up the OS certificates by default. I nervous that without a bit more careful testing than I have time for I won't get things correct in getting it to pick them up. However, it looks easy to tell the library to not worry about the cert. So I just pushed a version that does that. Since the console only operates on your internal network this seems a reasonable stopgap. If you grab the new stable version I just pushed to GitHub it should do this. If you want a quicker test then in the file isyeventmonitor.py in the consolestable directory the 4th from bottom line (which is a run_forever call) should be changed to: ws.run_forever(ping_timeout=999,sslopt={"cert_reqs": ssl.CERT_NONE}) and you will need to add an "import ssl" line to the top of the file. The library in question is websocket-client with the code at https://github.com/websocket-client/websocket-client/blob/master/websocket/_http.py The longer term fix appears to be to set an environment variable ( WEBSOCKET_CLIENT_CA_BUNDLE) to point at the OS cert bundle directory and get your self signed cert in there. If you are into Python feel free to explore! If you want to try that you should get rid of the sslopt that I added in the release file and described above. Let me know if the workaround works around. Kevin

Well the reason the websocket stream isn't opening is given as SSL: CERTIFICATE_VERIFY_FAILED. On the other hand the requests from the request interface seemed to succeed if things get set up and you can turn the light on/off. Unfortunately I'm not particularly up-to-speed on how the SSL should work so I don't know at this point what that means other than it is the response that comes back as an error on the attempt to open the stream. BTW - the reason that it creates one a minute or so is that the console expects that websocket errors generally clear and so waits a bit and then retries to open the stream. You're seeing the history log for every failure.

The PORT could be the issue. I haven't tried to support a non-standard specified port although I would have thought it would work. I use a standard Python library for websockets that just takes the url and it looks like the url would just have the port as part of it and so should work. I just tried changing my config files to specify the IP:80 since it uses http on the standard port and that seemed to work just fine as the console came up as expected. I'm pretty sure that others here are using https on its standard port. I suppose that there could be a bug in the library that somehow doesn't like the specified port if it isn't standard but that seems unlikely. If it were possible you might try temporarily using the standard port and dropping the :portnum part of the url to see if that fixes it. If so, I'd have to figure out why the existing library and usage doesn't work. But really, I'm guessing that something else is going on with the comms. Clearly, the direct comms work since you can turn the light on but the websocket stream isn't connecting correctly. There is a debug file that may have a clue in it in your Console directory in a hidden directory names ".HistoryBuffer" If you send me that file (the last one if there are more than one) it might shed some light on the nature of the websocket error. The Dell keyboard probably was the source of the other events so I'd not worry about those. Those key events just got forwarded to the console that didn't know what they were. As to the config structure - the usage document is pretty complete and there are a lot of examples in the example configs directory. However, there is no support for defining a button screen that takes you to another screen like you are describing. The nav keys at the bottom are the console's way of moving between screens. The screen tree model you are describing is a good one - just not the one the console implements. Sorry on that one. (Perhaps a future enhancement.) Unfortunately I have a bit of a time crunch to be useful to you getting your comm issue sorted quickly because I am about to be traveling out of the country for 3 weeks. I'd normally try to figure out the issue and get you a fix right away but I have only tomorrow and still a list of things to do unrelated to the console. So I won't be able to do any significant debugging/fixing right now although if the HistoryBuffer file makes it clear what is going on I may be able to do something quickly. Kevin

You are definitely not getting a websocket stream from the ISY which is why you get the x-d out screen and no feedback. The touch is sending the on/off blindly which is why you do see the light control. I don't know what those KeyDown/Up events are unless you have somehow chosen to use a strange touchscreen or not spec'd the touchscreen in the setup correctly. If the screen an Adafruit screen or the 7" Foundation design? And did you spec that when installing? Because those events look like they might come from some other touchhandler code. I don't think this would be related to the ISY comm problem but not sure. The comm problem is also odd. Basically, the websocket code is getting an error processing the stream that I don't expect to see - i.e., don't know what it is. The fact that you can turn things on/off suggests that your authorization is ok otherwise I'd ask if your password etc. is correct. My guess is that there is something odd about your ISY url as you spec it. You might try just using http and the actual ip address to start rather than https and see if that helps. You an event set the IP address in the config file to just the IP address with no "http" in front and see if that works. Here's an example of what is in my config file. If this still has problems send me the start of the Console.log file where all the basic info is documented like the screentype and isy address stuff.

Thanks for the quick feedback. I'll probably push that as the standard release tomorrow.

@chrisb5 I think the root of the problem may be starting with the lite Stretch version. Not sure what the drop from that but from the errors it looks like perhaps a bunch of Python. I suggest to rebuild a system with normal stretch with desktop (don't think you need the one with the extras beyond that). Looks like the current one at https://www.raspberrypi.org/downloads/raspbian/ is from 11/13. On the fresh system at a terminal prompt types "sudo pip install --upgrade pip" and you should get the latest version of pip which is something like 18.0. (This isn't strictly necessary since an older version is generally fine but it should give some assurance that the system is all there.) Just to make sure things are solid type "sudo pip3 install future". The pisetup script actually does this (at line 69) but it is about the only thing that could go wrong before the run of the run of getsetupinfo.py. From there the install scripts should work fine - I use them fairly regularly in building test systems though I haven't built one in a couple of months. ETA: Looking at some documentation it appears that Python3 is not included in the lite version which is required to run the console.

@Screw Loose Dan Those were the result of one more place where I didn't know how V5 reports things. Think I've fixed it and put in the new beta. If you can check it that would be great since I can't verify the fix.

Re the V5 firmware - I haven't run that yet. There are a couple of special cases already in the code for issues others reported with differences in how the ISY reports certain things. The errors that you are seeing are the same ones EVictory is seeing and are due to my not expecting to see those nodes. For now I have (I think) added recognition of those sorts of nodes and don't error log them on normal log level 3 (though I will report them if you set a more detailed level. This change is in the current beta version so you might try that and see if it works ok (I'm having to fix this sort of thing in the blind). I hope to push that as the current release Monday if I don't see any issues but then I'll be traveling for 3 weeks so don't want to push anything problematic. On the query thing, I don't do anything special for battery devices but generally they shouldn't be reporting comm errors. The comm errors seem to arise from real Insteon issues with getting good messages through. I had been seeing a lot of issues with this from my Garage Door Opener because its controller is not dual mode. (I finally just plugged a range extender right into the extra socket on the opener controller and that is dual mode and seems to have fixed my issues.). Basically what I do if I see a comm error get reported is to trigger a query after a small wait time (in case other things clear the problem). The query is the same thing that runs daily at 3am in a standard ISY setup. So if the error is intermittent this can fix things without waiting until the next daily house query. If not - oh well! Since multiple consoles will see the comm error I also randomize a bit across the consoles so that they don't all launch queries in lockstep. Kevin

Thanks for the logs - I took a quick look at them and I should be able to suppress the warnings about extra info. Those come from how ISY reports on the new node types that the console doesn't understand. FYI - I think you meant SceneProxy which is why you have those errors about ScreenProxy. If things are working ok anyway then that just means the console guess a reasonable choice to represent the scene "state" and you could just delete the SceneProxy items - or leave them with the corrected name. Also DimTo should be DimTO. I really should find a way to be more flexible on capitalization - I'll stick that on the todo list. The comm errors generally reflect that the ISY node is actually showing a comm error in the ISY dashboard. When I see that I try a query to see if I can clear it but it is really between the ISY and the Insteon device. On the other hand those "saw and immediately cleared" messages are some sort of ISY weirdness that I also tripped over once I started reporting comm errors. Under some conditions the ISY seems to get in a state with some devices where it always first reports ERR (which is generally the node state after a comm error) and then in the very next record in the stream reports a valid non-error state. This was driving me nuts because my garage door opener was doing it at times. The ISY dashboard would not be showing an error - it was just that the stream reported an error and immediately a clear of it. So I actually special case that which is the message you see in your logs. In my experience, the ISY would seem to do this after there had been a real comm error that then cleared. It looked like the ISY remembered that there had been an error and kept doing this until it next booted and then it wouldn't do it again until/unless the device suffered an intermittent comm error again. Probably Michel and the gang should take a look at this one at some (very low priority) point. If you see these a lot perhaps I should just downgrade the level of their reporting since they seem benign, but they do concern me a little bit since I can't explain them. In any case, by the time I make this a general release (probably next week) I'll fix what I can. Kevin

Oops. Dan is right that will work for the TimeTemp screen but when I added it for him, I didn't also add it to the Weather screen. It was an easy fix so I put it in just now. However, since I have been doing some other things that I think are stable (been running in some of my nodes for a week or so) I don't want to make it the current release quite yet. So I just pushed the change as "currentbeta". It also has a change to try to suppress those ISY node processing errors from V3 type nodes that I don't understand in the program. So you should be safe in selecting download beta and use beta for your system. Let me know if that handles your problem. Also, if you would do me the favor of running with LogLevel set to 2 once, you should see the node processing errors show back up in the log but with some more info to help me understand what those nodes look like. It you can (no rush) send me a version of the log with the detail messages. Then you can just delete the loglevel or set it to 3 (the default) and get back to a simpler log. Thanks, Kevin

Actually, if this error only happens once you've added the new weather screens then the other thing you could do is to send me the screen config files and the weathersources file (don't include your key) and I can just try running them here and see if I can find it that way. You could quickly check that by just seeing if the console will run if you don't include any of the weather screens.

Probably tripped over a bug but we need to localize it a bit. Add the lines: LogLevel = 0 Screen = True to the top of your main config file. This will make the log output a lot more verbose. Mostly it should identify the screen being processed at the time you see that error. All the parameters that describe a screen appearance etc. now get stored in a common place internally. ScreenParams is the name of the part of that place that holds those parameters. The program seems to be trying to access something called "store" and not finding it. I'm guessing you don't have anything like than in your configuration hence a bug. However if you do have something called "store" that would be a likely clue. In any case, run with the above and get me the log file from that. FYI there should be a line that looks like "Screen of type" just ahead of the failure. That should at least point at the type of screen you were creating when things went south. P.S. I would expect those other errors are in fact PolyGlot related since I don't run a v3 system so don't see those newer node reports. By the way, the delay in restart is set in the systemd config file that starts/restarts the console and is just there to avoid fast restart/die cycles when there is a permanent error like this. Kevin

I just pushed an update for anyone who is using this. Changes in this update are mainly multi-console use improvement via optionally coordinating behavior via MQTT, lots of error message/handling cleanups/improvements, and some (hidden) diagnostic stuff. One loss of capability was dropping WeatherUnderground support since they are killing their fre API at month end (but it supports since the previous release APIXU weather instead). Most of the change was motivated by my needs having 8 consoles deployed across 2 homes where managing them when an error occurred had become a bit annoying. Copied below is the full release note from GitHub. The documentation in the usage notes file have been updated to reflect the new capabilities. V3.2 is a notable release that will mainly be of interest if running more than one console. Its major addition is the use of MQTT when configured to allow multiple consoles to report their operational status and to coordinate any Warning or Error level log entries. This permits the user to look at the log on any single console and see any serious log entries made by all the consoles in the house. It also coordinates the on-screen error indicator across consoles. It allows a simple look at the current status of all running consoles, as well as the hardware/software of the systems they are running on. Finally, it allows external issuing of commands to all or specific consoles via an MQTT publish. These additions were motivated by my personal experience running 8 consoles across 2 homes. This version also moves all major system and screen parameters to the store model which makes them accessible to as screen configuration and alert parameters as well as via the MQTT set mechanism. In addition to this (which is only enables if you configure MQTT so not an issue if you don't) there are a lot of improvements in error handling of various ISY and HomeAssistant error cases. In particular, the console will now initiate an ISY query when it sees an ISY node with a communications error (motivater by a particular issue I had with my garage door opener). It also notes error conditions that clear as well as prolonged ISY busy periods (expect one at the overnight daily whole house query). In general, error messages have been cleaned up to avoid pointless Warning level messages where possible. Finally, some additional diagnostic capabilities were added to allow dumping of the history of events that led up to a situation. This version also deprecates WeatherUnderground support completely since it will be killed off by them at end of month. All the above has been added to the documentation.

Nicely done - I am pretty sure you nailed it. I had almost asked you before if you had another alert screen active. I'll have to look at how to avoid the message for that sequence but I think what happens is that the Away screen is up, then the Garage Door alert screen is enabled. If multiple alert screens are active they take turns deferring to each other. The Away screen defers which queues it for later reactivation, then the cause for the Alert screen clears, then the queued reactivation happens, and I see the alert with the condition not true and I issue the warning. That should be possible to suppress since it is a perfectly normal sequence of events - just requires the right setup and then the right timing of things. Thanks! I hate mysterious program behavior.

More curious than you know! I looked harder at the code that emits that message and I'm really scratching my head. That code should only ever see an alert that as part of its condition includes a delay. Basically the flow is that the variable change is reported which should trigger the alert evaluation. If the delay is 0 then that evaluation just invokes the alert's action (in your case it should put up the Away Alert screen it would appear). If, however, the delay is non-zero then the alert evaluation queues a task for "delay" time in the future which makes the alert reappear for execution. The message you are seeing originates in this delayed execution code when it re-evaluates the condition and sees it isn't true any longer (other code should have noticed such changes and deleted the delayed task before it came ready). But your condition appears to have delay of 0 and so should never even get queued for that delay handling code to see. So while I still think it is benign I am really stumped as to what is causing it. I'll keep noodling on it. Also, the next version of the console should have some (hidden) facility to look back at the event streams in cases of such oddities which may provide some insight. If, after you get that code we are still seeing this, I'll ask you to send along the history buffer for the event stream for when it happens. While there is quite a bit of tricky parallelism in handling the realtime environment of hub message, internal console events (like clock ticks), touch events, etc. it is still annoying to discover one of these odd bugs - especially when it would seem impossible. Kevin

I probably should have noticed these (there's a another one just like it) were still Warning level and made them detail log items. They should be benign. Interesting that you see them though. Basically what has happened is that the alert triggered (looks like it is the state variable "cell_home" going to 0) but by the time the code to handle the alert is dispatched the condition is no longer true. I think that could happen if the variable changed to 0 and very quickly changed back. Just guessing here but are you using the connected state of a mobile on your router to change an ISY variable? If so I suppose it is just possible that the phone could appear to disappear VERY briefly and cause this. I didn't think this race could actually happen (and in my older code I don't think it could have) but since I went to using the store mechanism to handle ISY variables is might be just possible for the thread that handles the ISY stream to see the var change to the alert state, queue up the event to be handled by the main dispatch code, then see the state flip back before the queued event actually gets to dispatch. In any case, since the actual handling of the event notices that the condition isn't true is just ignores it and you don't get the Alert screen. I'll downgrade those log entries to where they should be - just surprised that the race can happen apparently with some frequency. It will probably be a couple of weeks before I push a new update since I'm about to be out of town and I have some "in flight" changes in my home version that I'm not sure are stable yet (most aimed at ridding the log of pointless warning like these so that when you do see the error indicator in the corner of the screen it is something worth glancing at). Kevin