kck

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

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

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

Actually all those are just leftovers from the installation. I don't delete them because when doing development I sometimes need them afterwards and it was simpler to just leave them. It is interesting that the .1 files are there since those are generally left as an option by cp when you copy over an existing file but that is not generally a default option - you need to set it. By chance do you do that in your startup files? Not an issue - just surprised to see them. Feel free to delete them. On the https deal I just copied the code that Chris provided. Did you wait a bit after seeing that message. I ask because sometimes the ISY doesn't respond and the code retries so I do see that not responding message on occasion generally followed by a later success. I don't think there is any other response code since I think You get that message when the request times out though it is possible there is some other cause.

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

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.