kck

I just pushed a new release (2.5) of the console. First, thanks to Screw Loose Dan for the code changes to support https/wss access. Just specify https://addr instead of addr in the config file for the ISY to get that. The major new feature is support of the official Raspberry Pi 7" screen. That screen has a quite different way of delivering touch events and was not compatible with the standard libraries that I use. Happily pimoroni on the web did a small support library for it that I was able to adapt to use in the console. Even better, I was able to adapt that library to finally get rid of the need to downgrade the SDL libraries as part of the install of the console. For those of you who don't know what this means - don't worry it just simplifies the install process and makes it less fragile over the long run. For those who do know of what I speak it means no dangers of inadvertently upgrading those libraries if you do some other upgrade on the system running the console. This is new code and should be decently tested but if you do an install and have issues with touch you can fall back by using the pisetupold.sh script rather than pisetup.sh to do the install. Kevin

Oh no! I've never ordered anything directly from Thingiverse. Probably would have made the same mistake in you place. FYI - before I had a 3D printer of my own (nice toy) I did some printing via 3dhubs.com. It is sort of an Uber for 3D printing where folks with printers who are willing to print for others offer to do so. Results can vary depending upon the person you wind up going with but it can often be done pretty quickly and locally. The site handles all the providing of the costs, escrowing payment until you are satisfied, mediating communications etc. You might check it out.

Chris, Why don't you send me the files or a diff of them. I'll put them in the project and include them in a "currentbeta" release so that initially they only impact you if you pull that. I'll try to figure out how to regression test (I'm remote from my ISY at the moment) and then after that move them to the standard release. Thanks for looking into this. I do recall that back when I did play with this a bit I ran into the warning also. I seem to remember not being able to get rid of it even though I did the disable_warnings thing. It's been a while though so I don't really remember. Also to gaetanlord and anyone else interested in the 7" display, I actually got one of those and also located what looks like it will be a usable touch driver that I can integrate into PyGame. If I can manage that (project for the next couple of days I hope) I will let folks know. Initially I expect to just support it as a bigger screen although longer term there really should be more flexibility in setting it up. Kevin

Sorry - forgot to actually do the screen update. Need one more line after that addition that says: pygame.display.update() It's in the currentbeta now. Unfortunately I don't have a debugging system set up where I am (at my snowbird house) yet so I'm doing the fix blind. Sorry to get it wrong. Also, if you look in the docs directory at the file params.txt you'll find a file called params.txt that is auto generated that has a bunch of what I think you are looking for. It should be pretty up to date - it only gets generated on my development system but I think it should be correct as of a week ago which would be the same as today since I've made no changes. What is lists is for each module what parameters are defined locally to the module and what global parameters the config file may override for that module. Since it is based on my general parameter grabbing utility it doesn't guarantee that the parameter is actually used in the module but it should be pretty close.

Well I thought non-blinking messages should work with Blink = 0 but it seems I didn't bother to actually show the message when Blink is 0 - duh! I just pushed a 'currentbeta' release that adds the missing 2 lines. If you want to shortcut downloading, since you seem to be fully competent at munging code, you can also just insert the following 2 lines: else: config.screen.blit(self.messageimage, self.upperleft) in screens/alertscreen.py after line 117 as the else half of the is Blink 0 test. The text characters do use KeyCharColorOn as their color choice. Looks like the examples are wrong. I think this dates to when I had a request to allow different character colors for on and off keys and it never all got cleaned up properly. This isn't likely the only place where a parameter name is inconsistent or wrong. I've never been happy with the config file stuff because the library I use makes it hard to have and maintain master lists of parameter names so variations creep in. I've thought about changing it but there are enough config files around that use this format that changing seems worse than living with it. Let me know if the fix gets the non-blink case right since I'm not set up to easily check it out at the moment.

OK - think I managed to get the release tags updated to that the current version installs. I think you are right about the IP check. I seem to remember that had to do with stuff other than the console - I'll need to look at that and figure out what is really needed.

Ouch. You are right about the release. In my rush to get out of town with this fixed it looks like I neglected to force push the 3 script related tags. Now I'll have to figure out how to get them fixed while not on the machine that actually made the changes. My git/github depth is limited. Good catch on the network number. I'm afraid to admit that I'm also an rather old networking guy (dating from first BSD IP stacks) so that is embarassing. All I can claim in defense is that I had stole that code from somewhere when I was first trying a Pi to run the Alexa bridge and haven't much looked at it since. That clearly needs to get fixed. I should go back and look at what is really needed there or probably even better would be to switch the start up out of rc.local and into the System V init system that seems to be the system management of choice for the Debian Linux system now. (It has the ability to sequence things after the network has initiated.) Kevin

Absolutely correct analysis. It is the bug I posted about 3 posts or so up in this thread. It looks like you grabbed the version before I pushed the fix for it on the 27th. It should now be fine not to have an [Alerts] section. I had added the code to check for bad parameters and show any parameters that had not been consumed by the program processing the config file after I did the minimal test adds so it never got tested with an absolute minimal config and since I always had alerts (both explicit and due to having command variables in my ISY that can cause remote operations in the console from the ISY side) I never saw it. But you nailed the issue so you can't be than much of a noob . By the way, the alert that you left in checks for a new version periodically and reloads the console with that so by now you probably have 2.41 installed if you look at the current version. I've never run with an ssl secured version of things. I had tried a long while back but couldn't sort it out and since I didn't feel I needed it in my situation didn't pursue it. If you can tell me what needs to be fixed to get it to handle this case let me know. Unfortunately I am remote from my ISY for a good while now so am limited in what I can debug from here.

There is an exit console option under maintenance. Tap screen 5 times to get to maintenance and you'll find options to restart or exit the console or reboot or shutdown the Pi. If the screen is a touchscreen I would think the console should see that. The console does run native on the screen - it doesn't use X-windows. The console just uses the pygame touch handling stuff which is fairly generic. It can be a bit touchy (no pun intended) though because it needs to use an older version of the low level libraries. You can see that those get downgraded as part of the install scripts. All the code for the console is, of course, there on your system and it sounds like you are tech savvy so feel free to poke on it if you wish. It might be possible to recast the console to run in a virtual Xwindow - just not something I had tried. I'm traveling for the next few days so I'll only be online intermittently but feel free to queue up any questions and I'll take a shot at them.

You ran into a corner case bug in my code - 1 line fix. I have pushed a 2.41 with the fix, or if you want to just keep testing for the moment just add an empty Alerts section to your config file by adding a single line [Alerts] at the top level (if you're using the minimaltest config right after the mainchain definition line). Sorry about that. I'm not sure why you weren't asked in the setup scripts whether you wanted to create the minimal test config which would have set it up without you manually copying/editing the minimaltest.txt file but it sounds like you got that ok. That error message about Veranda is something else at your end. The console queried the ISY for the state of that node and the ISY returned the code "ERR" which I believe means that it doesn't know the state and can't talk to the node. Whatever that is would seem to be at your end. You might try using a different switch for your initial test. One other thing. I have never run the console myself on the 7" screen and don't have one. I think it should run since it tries to self configure to the screen parameters. I'll be interested in knowing how that goes so even if it works great do let me know. If you bump into any other issues let me know. Kevin

I just pushed a new release (2.4) that provides cleaner and more flexible options for on/off keys and runprogram keys to allow secondary verification and blinking response feedback. The verification screen came as a result of noticing that some keys map to difficult/annoying to reverse results (typically running a program that does a bunch of things) so this reduces the chance of accidentally executing such a key if desired. I also wanted a quick and simple way to pull data from my WeatherUnderground feeds to an ISY variable - a poor man's weather update. So there is now an alert procedure that defines such an operation that can be executed periodically. The documentation has been updated to reflect these changes and continue to improve clarity.

From what I can see 5.x will represent the really only viable way to support a potentially unlimited number of devices that will appear over time in the Zwave universe. So long as only Insteon was the target UDI could keep reasonably up to date since Insteon devices got released or changed pretty rarely. Not likely to be true with a large number of startups and established companies in the Zwave market. The node server approach would seem to open things up to support of devices that for reasons of timing or volume aren't supportable by UDI. For that reason I saw the architectural change UDI was making from 4 to 5 as a very positive thing. But I have been dismayed at seeing how slowly it has progressed and that is beginning to make me uncomfortable with the UDI path. I understand their conservatism and desire to only release very solid code (since that mapped to my approach for most of my career) but whether they or I like it the speed of change now has simply become too fast for that to likely be viable. Today the world is dominated by the fast turn, broad based beta approach to development. By any current standard UDI's progress on 5.x has been glacial and since I think it represents a critical need for them to stay relevant as devices in the automated home proliferate I really think they need to get a lot more aggressive about getting it out.

Glad to hear it. If it's any consolation for your somewhat bumpy journey, I think the install script and related stuff is much easier for others than when you started thanks to our joint learnings about where the potholes were. Let me know if you have any suggestions for other improvements to the console or it's install etc. Kevin

I just pushed a new release (2.3) that fixes the Bluetooth issue by removing the Kali Pi kernel stuff that had been required to work around Raspbian system problems for some of the screens. It also further simplifies installs in that it asks all the questions it needs up front and then will run unattended including rebooting as needed. If you specify a minimal test configuration it will configure everything and ultimately reboot into the test configuration. It has been pretty well tested on a Pi3/35r configuration and on a Pi0W/Waveshare3.5 configuration which represent representative extremes. One note regarding the (cheap) Waveshare screen is that it does not dim (not supported in its hardware) so while it is available for only $20 which with a $10 Pi0W makes for a quite inexpensive console, I wouldn't suggest using it in your bedroom unless you sleep well with a rather bright screen on all night. Makes a good living room console though.

Well I just created a system from blank SD card on a pi0w using a Waveshare 3.5 screen (trying out a Chinese cheap screen). I see the Bluetooth situation. Interestingly it seems to work fine on my Pi3 after the install. Must be something in the system configuration script that I get from the guy in Australia (which is needed for other reasons for the touchscreens). I have left a message in his forums for him and he is normally pretty prompt at responding modulo timezones. So I'll see what he says and figure out if there is a solution. I hadn't noticed this because I don't use BT for anything. Don't know what the console not showing is. It almost sounds like it that the backlight isn't on which could be something related to the dimming issue that I fixed on the Pi3. Try this: open a vnc session to the pi while it is running the console. Then cd /sys/class/backlight/soc:backlight and then sudo echo 1 > brightness and then sudo echo 0 > brightness. Let me know if either echoing a 1 or 0 to brightness turns on the screen. If a 1 turns on the screen then it would appear that for some reason the dim value is being set to 0 within console on the pi0. Echoing 0 should disable the full power backlight override and use whatever the pi0 PWM is doing which might be the issue. I can't quite try this here easily because I don't have an Adafruit screen handy and the Waveshare screen doesn't dim (or at least I haven't researched if it does yet).

Regarding name wrap: with a key description if you explicitly give the key a label rather than defaulting it to the name from the ISY then a comma provides line breaks. So label = Wall Plugs, will treat "Wall Plugs" as a single unbreakable label whereas label = Wall, Plugs will treat that as 2 words one per line. Since the label parameter expects a sequence of things if you leave off the trailing comma: label = Wall Plugs then is actually gets treated with each letter as a separate word and hence on a separate line. (i.e., it will sort of wind up looking "vertical" on the button - probably not what you want. Regarding the thermostat: I'd never seen anything like that happen. But since you mentioned doing an explicit query I tried that and got the failure. Looks like under some unknown conditions, the ISY sends through garbage info for the current state of the Thermostat. I've now guarded against that case but if you are looking at the screen when you do a query you may see nonsense values briefly that should then repaint correctly. Not sure why I never encountered it before. Think I asked above but by chance is your Thermostat running on battery versus being powered from the furnace? If so that might explain why you saw it earlier without the explicit query since I think the case arises while the ISY is processing a query which takes a bit longer than the state request from the console. In any case, it shouldn't crash any longer.

So I just added 2 optional parameters that can be specified when defining a screen: KeysPerRow and KeysPerColumn. These will override the normal layout code and should allow you to handle landscape. There may be some better long term solution but that should work at least for now. The split screen idea would be neat for a bigger screen but the currently defined screens won't do that. You could probably hack them in Python to combine a button and weather screen or something if you want to define a new screen type. That's an idea that definitely goes on my futures list in case I get myself a larger screen system. For now the easiest path would just be more and/or bigger buttons. By the way - the really quick response this week is due in part at least to the ugly forest fire raging just outside Portland which has made our air rather yucky to breathe on the golf course. Has be spending time on my other retirement hobbies.

There was someone who ran it on a 5.x version. The only issue that came up at that time was that the ISY had altered how it reported status in certain cases (as I recall it had to do with reporting UOM as well as the actual value). I fixed that easily at the time once I figured out what had changed. So I think it should work but I'm still running 4.x. I'm planning at some point to install some of this in our other home and will probably start there with a 5.x ISY and some Z-wave but no timeline on that. I haven't got a 7" screen but that certainly sounds interesting and in theory things should scale since the console get info about the screen from the underlying system. Of course we all know how well theory works with software and new hardware. Still I do think it should be close because I even managed to do a test once by cobbling up running the code in a Win10 window. As to portrait/landscape, that shouldn't really matter. The configuration of the screen is all in the OS so if you can get the screen calibrated in the OS as a landscape then the console program will just see a screen size in pixels corresponding to that arrangement. Having said that it may well be that the button layout for that sort of screen won't look as you'd like. That should be easy to improve if you let me know what you'd like. Right now the program has a set of layouts that just depend on the number of buttons. Generalizing that to allow more choices that would handle other screen arrangements would be worthwhile. So just let me know on that one. The one thing that probably will not work will be dimming. That seems very specific to the screen. If you are a Python person look at the module hw.py to see what the console currently knows about the hardware. I think handling a different hardware should be easy enough but expect it will require a change here. @Teken: after my experience with Aaron, I have tried to encapsulate all that learning in the useagenotes that come with the install and that you can grab from GitHub to look at. I figured that embedding the information there would be the best place to stick it. I created a very simple starter case that should let a user see if the console is installed and running before launching into more elaborate screens. I am hopeful that this meets the need and will continue to enhance the information there as I see more is needed. Before you start I suggest you read through the current version of the note and tell me if anything jumps out at you as missing. Edit: I just looked at the button layout topology code and changing that will be very easy. Right now it just has an (row,columns) pair for each possible number of buttons. I can just add some alternate arrangements for landscape or bigger screens.

Thanks. I took a shot at your suggestion and added some of that info to the useage notes. Some of that info might still be useful to you so do peruse it. As you go along please feel free to suggest other things I might document and, of course, suggestions on program improvements are always welcome.

OK - there is a new release up that should work fine to dim Stretch or late-Jessie systems. You can grab it if you want. I also added, based on your experience, a minimal config example and writeup in the useage notes that should walk a new user through what we did with less pain. It also explains the simple operations. Since you just went through this I'd appreciate it if at some point you looked at it and tell me if it a) makes sense and would have helped. Kevin P.S. Hope you're in the NE and not Florida based on looking at the Irma projections a friend in Miami sent me.

Yup. The change that is causing this actually looks like it went into the system late in the Jessie life (i.e., latest build of Jessie has the failure but earlier ones don't). I finally tracked it down to a change in the way some of the pins on the Pi are controlled in recent versions which essentially overrides the dim control that I am using. I have just figured out how to manually turn that off and get dimming to work again but now I need to figure out how to do it from inside the console program. I'll work that out and get a patch into the program. By the way, I'm not chasing this one only for you - if our bedroom units don't dim at night I'll lose lots of WAF points and at some point I'll update them to Stretch so I'd better have this fixed first! Kevin

If you have any repeat problem with the tstat do the LogLevel 0 and turning on the Main flag then go to the tstat. Otherwise no idea what the issue there was. Glad everything else is working. I'm actually building a Jessie version to check the dimming myself. I've posted a question a couple of spots on the web to see if anyone else has any insights on it.

I just noticed the dimming issue. It looks like it is an issue with the most recent version of Raspbian (Stretch). I have older Jessie systems that dim fine. I'm going to have to see if I can isolate what that issue is or try to find someone to punt it to on the web and stay with Jessie for now. Not sure what to tell you regarding the tstat. I have essentially the same config file as you must be running and it works fine here. Is your Thermostat battery powered by chance? I'm looking for some reason why the ISY might not respond when asked about its current values. Could you try one thing when you get a chance. At the top of your config.txt file add a line: LogLevel = 0 That will turn on some additional logging. Then once the console starts go to the Maintenance screen. Tough "Set Flags" and touch "Main" so that that button turns on. Then Return and Exit Maintenance. Then try going to the Thermostat screen. If comms with the ISY have worked in the Console.log file you should see some messages that look like Main-> stuff. That stuff is the current values the tstat is returning to the ISY. If you don't see some stuff like that then it would appear that the comms to the tstat is failing for some reason.

Well the clock not showing is probably that you spelled it wrong in the DimIdleListNames directive - capital c for clock. This is reported in the log file if you look. Also, you can't put a single screen on both the main and secondary screen lists which is what the error message in the log under Secondary Screen List Undefined screen name is. The error about Home screen name is due to the extra comma on the home screen directive line. Basically, the comma at the end thing is that if a directive can take a list of names then in the case where there is only on name you need the comma to indicate that it is a list of 1 item. If the directive takes just a simple name then no comma. I know that's confusing - I should probably look again at what I could do about it. Overall, I do suggest that you scan the log for any message with severity 4 or 5 as these probably indicate something is wrong. The level 3 are all just informative but if you get a level look back at the 3's because they may help understand what is going on. There is an odd comms error from the ISY at the end of the log - that indicates that the ISY sent a message with an error indication about that node (Porch Door lock). May be of no significance since you aren't using it here but it gets reported. Now about the thermostat - I built as close a configuration as I can given different houses just now and it worked fine for me. The actual screen code does start by displaying the 2 keys and then paints everything else so if the console crashed that would be consistent with it happening somewhere in the thermostat display routine. (I am assuming that it crashed when you say the screen went blank? I.e., the program exited?) I am however surprised not to see any logged traceback info since Python doesn't crash without dumping such. Are you sure you didn't have any on the screen? The log you sent ends abruptly with that comm error message.

Great. I did just find/squash one very small bug related to a configuration as simple as yours is at the moment (strangely bug wouldn't impact more complex configs). It would have eventually locked up your system once the clock was running as a idle screen. I pushed that to github. The clock should run as the idle screen if you just add the 2 lines above and add it to the include. Note that this uses the clock screen as an idle after the console has not been touched for the timeout interval so you won't see it on the navigation keys. The only way to know it is working is to just start the console and wait a minute or so (or whatever your timeout is set to). If you want to see that you can get the nav keys working I suggest you generate another key screen and list it in the MainChain list.