kck

That adafruit-pitft-touch-cal that is left in the /home/pi directory is their script. Not sure what you mean that it comes back as command not found. It should run as root so something like "sudo ./adafruit*" or sudo python ./adafruit* should run it (it is a Python program). Generally the current directory is not in your search path so a script like that needs to be located as ./script so perhaps that is what you mean. I don't know why the calibration would be off since they basically take the screen type and use that to just force set the parameters. You can look at their script to see what they do. Key elements are rotation and screen type - if you are on your 2.8 screen make sure you pick the right type 28r or 28c depending upon resistive or capacitive. That's about all I can suggest.

Great. Now at least you have a starting point. To add the clockscreen, add myclock.cfg to the include. Then add 2 lines: DimIdleListNames = MyClock, DimIdleListTimes = 20, The trailing commas are important. This will give you a system that shows your button then after 45 seconds (the TO you set earlier) will switch to displaying the clock. The 20 is not significant here but if you define a set of idle screens it would switch to the next after 20 seconds. Hope that helps. Also, I found some strange race condition that I'd never seen before that happened in this minimal configuration. I fixed it and pushed up a version so if you do run into an issue with a crash after the clock screen has been displaying for a bit grab that newer version. You can do that from within the console app now that you have it running. Tap the screen 5 times to get the Maintenance screen up. Select "Select Version" there, then select "Download Release", When the button clears the download should be done, so hit return, then "Exit/Restart" then "Restart Console" and confirm. Should restart you with the new version. You can see the version change in the respective log files near the front.

I had hoped that the current version you have would let you get the minimal test you wanted up but it really expected that there was a secondary screen chain. So, I fixed that and released an updated "currentrelease" on GitHub. I then ran essentially what you had using my office light. Here is the config.txt file: cfglib = cfglib include = auth.cfg, mintest.cfg HomeScreenName = Test HomeScreenTO = 45 DimLevel = 50 DimTO = 25 MainChain = Test, SecondaryChain = Test, And here is the mintest.cfg file: [Test] type = Keypad label = Kitchen, [[Office Ceiling]] With this you get a single big button that turns the light on and off. Should give you a starting position. So you need to download the current release which you can do by running that setupconsole.py from the command line. That should get you the current release. I plan to poke around in the code to try to further harden it against config errors but as I warned at the outset, that is hard to get anywhere near perfect. The log file does dump all the parameters it reads so it is always worth scanning for one that seems odd if you see strange results.

First issue - you don't define any screens! Your Test.cfg file is never processed because you don't include it. Console processes the config.txt file and any other files it points at via includes but here you don't do that so you have no screens defined. Probably the program should have a check for this but it never occurred to me that someone might have a config file that was essentially empty. You need to add Test.cfg to the include. Myclock is also not processed but it isn't referenced in config.txt so that's fine. Mainchain should have that trailing comma so that the parser knows that Test is a single name rather than a sequence of 4 names, 1 per letter. That's the parser quirk that I can't do anything about. So what is happening in the failure is that the console thinks there are no screens and when I try to build the navigation links between the screens it fails. I can definitely improve the error checks here plus your case did show a subtle error in the code that I'll fix for some edge cases. For now though try adding the include of the Test.cfg and adding a comma at the end of the line that sets Mainchain and let me know what happens.

What I can tell you from a quick look is that your config.txt file has problems. Some simple items: add a trailing comma to MyClock in the line with DimIdleListNames and do the same with the 20 on DimIdleListTimes. This is noted in the usagenotes documentation and is due to the way the python package parses strings versus lists of strings. Neither of these caused the failure though. I can't tell what you have in the config file that is causing the failure though. The parser things it sees a screen called "T" and another called "s" that you never define. It does somehow get 2 screens on its Main Chain of screens called "e" and "t" so I am guessing that you have "Test" written somewhere that isn't being parsed. Are your "["'s correct? A single '[" defines a topmost structure (a screen) and a "[[" would be down a level, e.g. a button on a screen. You might send me the config.txt file and I can take a quick look. I probably should add yet some more error checking code here, though the parsing is done by a library package so that me be tricky. In any case, just sending along the log makes it pretty easy to at least localize the problem. By the way, I assume that you must have run the console twice after the run that you sent me? The log files are sequenced so Config.log is always the current or most recent and Config.log.1 the previous run. Since you sent Config.log.2 that would have been 2 back which is file unless you edited after this in which case the config log you sent won't match the config text file I'm asking you to send. So do make sure that you send me a log that corresponds to the config you actually ran so I don't spin my wheels.

You can always run the console from the Linux command line with sudo python -u console.py (be in the consolestable directory so it can find console.py). I have difficulty believing that there are no log files or error messages created when you run. The console and/or python log all sorts of issues when they can't run. Even if you didn't get to the creation of the Console.log file in the Console directory which happens very early in the code, python itself would give errors if it blew up. Without some sort of error message there really isn't much I can do from this end. I suspect that your credentials are wrong or not set for the ISY or some other issue exists with your config file such that the parser I use can't read it. I would get rid of all includes and just have a config.txt file (I'm not sure what your test.txt since unless you change things from the command line console looks for a config.txt file in Console) that has the authorization info (address, username, password) and then directly (without includes) builds a simple screen. The fonts droid message shouldn't matter - the program uses a font that isn't normally installed but that shouldn't bother python in practice since it just substitutes a default font. If you want to get rid of that you can always install that font (sudo apt-get install fonts-droid). No idea why the 3.5 is having trouble (I assume that you have a different SD card that is configured for that screen and aren't trying to use the system built for the 2.8 screen for it - that won't work) I have 3 3.5 screens running here at the moment and 1 2.8 screen. Also have a 3.5 Chinese clone running (although that screen is flakey hardware-wise). So bottom line - please look in the Console directory and the home directory for logs and make sure you run as root because otherwise the console program can't get access to the frame buffer.

Not sure what you mean regarding the config files for a light switch. Pretty much everything in my examples are light switches. Remember - you are defining a screen full of keys and each key can correspond to a switch. So it sounds like what you want is to define a screen on which one of the keys corresponds to Kitchenette Lights. Assuming that is what you named that switch in the ISY setup then I'd expect the simplest config file would look something like: include = auth.cfg, myclock.cfg HomeScreenName = Test HomeScreenTO = 45 DimLevel = 50 DimTO = 25 DimIdleListNames = MyClock DimIdleListTimes = 20 MainChain = Test Which should give you something with a single large button that should turn those lights on/off and if left untouched for a while switch to a clock screen. If you look at some of the other examples you'll see screens that have more buttons. I have found that a 2.8 inch screen works well with 4 or maybe 6 buttons while a 3.5 inch screen handles 8 just fine. Beyond that I'd go to another screen that you switch to using the nav keys at the bottom. By the way - I didn't actually test this sample so it may have some parameter bugs that you should be able to sort out. As to the Adafruit screen, I haven't had any fail (though I physically broke a screen). Did you change some settings on the OS of the Pi that might have caused that? Otherwise my only suggestion would be to reseat all the plug points. I have on occasion seated the screen onto the Pi connector off by one row of pins and had the screen light up but not work so check that all the pins are in the right spot on the female plug. If none of that works you might try downloading a complete image from Adafruit that is supposed to be ready to boot on that screen, burn it to a CD, and see if it comes up. That would at least tell you if you have a hardware issue with that screen or have done something to the software on you Pi. [Test] type = Keypad label = Kitchen [[Kitchenette Lights]]

Aha! That error message was what I needed - thanks. Somehow a typo crept in - in setupconsole.py the line should read StageVersion not StagedVersion. I was not seeing this because I run "homesystem" which uses the other arm of that if statement where the typo wasn't present. Great as python is as a language it is so dynamic that it doesn't catch this kind of error whereas most languages would. In any case - my bad. You can edit your version of the file or just download it again since I just pushed a fix of it or you can rerun the full build but it should work now. Really sorry for causing you the problem, Kevin

I'm at a loss to know what you are doing that makes it fail - I just ran the Python setup script and it did exactly what it should do. If it is failing it should generate an error message of some sort out of Python. To be precise as to what I just did: I did the 2 wgets that you see in the installconsole.sh file that get the files setupconsole.py and githubutil.py and had them in /home/pi I then ran sudo setupconsole.py. What you should see on your console if you do this from the command line will look something like this: *** Setupconsole *** Already present: Console Created: consolestable Created: consolebeta Already present: consolerem Staging homerelease in consolestable because InitialInstall--2017-09-03 17:24:54-- https://github.com/kevinkahn/softconsole/archive/homerelease.tar.gz Resolving github.com (github.com)... 192.30.255.112, 192.30.255.113 Connecting to github.com (github.com)|192.30.255.112|:443... connected. HTTP request sent, awaiting response... 302 Found Location: https://codeload.github.com/kevinkahn/softconsole/tar.gz/homerelease [following] --2017-09-03 17:24:54-- https://codeload.github.com/kevinkahn/softconsole/tar.gz/homerelease Resolving codeload.github.com (codeload.github.com)... 192.30.255.120, 192.30.255.121 Connecting to codeload.github.com (codeload.github.com)|192.30.255.120|:443... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [application/x-gzip] Saving to: ‘homerelease.tar.gz’ homerelease.tar.gz [ <=> ] 78.62K --.-KB/s in 0.09s 2017-09-03 17:24:55 (902 KB/s) - ‘homerelease.tar.gz’ saved [80503] Stage homerelease as stable Installed staged stable Staging currentbeta in consolebeta because InitialInstall--2017-09-03 17:27:22-- https://github.com/kevinkahn/softconsole/archive/currentbeta.tar.gz Resolving github.com (github.com)... 192.30.255.113, 192.30.255.112 Connecting to github.com (github.com)|192.30.255.113|:443... connected. HTTP request sent, awaiting response... 302 Found Location: https://codeload.github.com/kevinkahn/softconsole/tar.gz/currentbeta [following] --2017-09-03 17:27:23-- https://codeload.github.com/kevinkahn/softconsole/tar.gz/currentbeta Resolving codeload.github.com (codeload.github.com)... 192.30.255.121, 192.30.255.120 Connecting to codeload.github.com (codeload.github.com)|192.30.255.121|:443... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [application/x-gzip] Saving to: ‘currentbeta.tar.gz’ currentbeta.tar.gz [ <=> ] 78.63K --.-KB/s in 0.1s 2017-09-03 17:27:24 (713 KB/s) - ‘currentbeta.tar.gz’ saved [80515] Stage current beta release Installed staged beta Just to make things hard I had actually deleted consolestable and consolebeta but not the other 2 directories Console and consolerem. That is why you see the messages at the top that those 2 are already present. This python program doesn't do much magic. It simply calls the utility StageVersion from githubutil. That procedure issues a wget for the requested version (in your case currentrelease) . It then issues a tar call to unpack that file into consolestable/stagedversion. There is some magic to identify the GitHub version (the sha stuff) that you can ignore unless it blows up for some reason. Then setupconsole calls InstallStagedVersion which just saves any existing version (you won't have one) into previousversion and pulls the stagedversion into consolestable. The last thing it does, which again for you should not matter, is to run a script to update any python libraries in case the new version needs something the old one didn't. If you look in /home/pi/text.txt you'll probably see a bunch of messages that requirements are already met. That's all that's going on here - really not much. As I said - I've just run it again and it ran yesterday for me when I was building a new system. If something is going wrong you are going to have to give me some more information about error messages or the like. You could try issuing the wget that setupconsole issues for the currentrelease directly from the command line and see if you get the gz file downloaded from GitHub. If that works you could try issuing the tar command manually against that gz file. But I need some other clue if I am going to help further. Kevin P.S. You do need to run all these as root. When you run the installconsole.sh script it actually checks to see that you are running as root and exits with a message if you are not. However, if you are running the pieces manually then you need to make sure of that yourself.

I just ran the tiny python program that does both the creation of those directories and the populating of them and it worked fine here. The real log that you should have sent is prep.log. Is there anything like an error report near the end of that log? If you want to try to manually rerun just the part that seems to have failed you look at the end of the installconsole.sh script. There are 2 lines that start "wget" and one after those that starts "python". Rerun those 3 commands as root. You can just retype them at the console. If you want to have the console autorun at start the mv and chmod commands just below that may also be needed in case the script didn't run them originally. I'd still like to see that real log if you get a chance to find out why it didn't run correctly since it does fine here.

So if you haven't figured this out: in the ISY admin console just go to the Programs tab and then within that tab go to the Variables subtab. There are 2 subtabs there - Integer and State. You already have some State variables. Just go the Integer tab and at the bottom click to add a variable and click Save. That should do it.

Just like a state var. Not in front of isy console at moment but just look at isy docs. You have some state vars defined - just add a non state one. Sent from my SAMSUNG-SM-G935A using Tapatalk

Looks like I don't expect anyone to have no integer variables defined. Apparently you have a few state variables and no integer ones. My bad for that assumption. As a quick fix to get you going just define an integer variable (don't need it to do anything) which should make the current code happy. I'll fix the no variable case bug next chance I get. Let me know if that gets you moving. Kevin

There was on small error in the pisetup that might have an impact. The last command in the script sets the calibration for the Adafruit screen and it was missing the parameter that sets the type of screen. If you grabbed things before I got that fixed then the symptom you'd see is that the buttons don't react corresponding to where you touch the screen. Fix is easy - just rerun that command with an extra parameter -t <screentype> where screentype is 35r, 28r, or 28c depending upon which screen you have. It should look like: ./adafruit-pitft-touch-cal -f -r 0 -t 35r if you have the 3.5" for example. Run it as root. As to setting up your own screens, the default location for the config.txt file is the Console directory not the consolestable. Basically you should never need to manually touch consolestable - that's just the code. The default location for the include library files is Console/cfglib. All these locations are settable but why make life harder. So you should put at least a minimal config.txt file in Console and if you want any includes put those in cfglib. I suggest that you start by taking one simple room with a couple of lights and build a screen for that. If you just want to try things out even before that, define only a clock screen in you configs and you should just get that with now interaction beyond authorization with your ISY. Let me know if you have questions and I'll try to help. Kevin

OK - I recreated the lost changes to the docs and the install scripts and installed it successfully on the latest version of Raspbian (Stretch) from the Raspbian site. It should also work on Jessie but I haven't tried that. Tomorrow I will try to do one more completely clean install using the current scripts and directions just to make sure that I didn't assume anything when I did it just now. However, I am pretty sure that what is out there will work ok if you want to go ahead and use it. As I warn in the notes there are some long waits for some of the scripts to do their work. I did see one place where for some reason a script (not mine) that I call needed an extra carriage return. If the system seems to hang with a message saying that Bluetooth support has been installed in a message ending with "++++" wait a bit but if nothing seems to be happening hit return . You should then see another question about enabling BT. The hang I think I saw doesn't seen to exist in the script so it may just have been something I did accidently while running it. Kevin

Hmm. Looks like some major instruction changes I made earlier in the year while was working from a different development system didn't propogate through github into the current stuff. Let me sort that out and tell you what to do. I think the new scripts are there and it is just the instructions that are wrong but I don't want to waste your time if something else also didn't propogate correctly.

Yup -still here. I haven't done a complete clean install in quite a while so I should probably try one to see if anything has "rusted" over time in the scripts. Meanwhile - can you send the log files from the install. Also - which directories aren't getting created? The consolestable and Console ones? I'll take a look later this afternoon and see what I can tell you. Kevin P.S. Just as an FYI my consoles seem to run completely stable these days. I only see a reboot when my home router gets sick, which it seems to do periodically with the result that all the home comms go out for a while. Even then, though, the consoles reboot and reconnect when the router recovers.

@larryllix: I do use programs in a manner similar to what you sound like you are doing for complex scenes where I want to have a type of "status" for the scene. Of course, it is a completely arbitrary notion of status for a scene defined to accomplish my purpose. My point about the proxy or flag idea is that there are some very common scene scenarios like a simple 3 way where that is pretty serious overkill if one simply wants to know if the controlled light is on. In that case you need to just look at the controlled device which is effectively the state of the scene. Problem is that you either have to do the arbitrary mapping between device name and scene name which is what it sounds like the Google home solution in place does, or you need to use a program. Neither are proportionate in complexity to what the user wants to be doing, and for a lot of newer users these are pretty weird constructs to do something as simple as asking what they see as the state of a scene. For my console purposes I automated that by guessing,which works most of the time and allows me a manual override when needed. It just seems that the ISY could provide a very small amount of assistance that would make this easier for the most common case and do it in a manner that is philosophically compatible with the v5 notion of virtual devices. I can live with things as they are but variants of this discussion happen often enough that were I UDI I would seriously consider whether some additional functionality was called for to simplify the simple cases.

This flag idea is very close to what I do in my soft console program. Since I want to reflect the status of simple scenes like 3-ways on the console it automatically will pick one of the devices in the scene to use as a proxy for the state of the scene and use that when it needs to decide what to display. That works for 90% of the cases. For the rest I also allow the explicit designation of a proxy device to represent the scene status in which case that device is used instead of the randomly chosen one. Works really well. I can really understand why something similar would be good for this case. Actually, this function could be done in the ISY itself by allowing scenes to have a proxy defined there. That would actually be an even better place for it since it would centralize the information in one spot rather than having it spread across different places. Perhaps in the V5 stuff a node type could be defined that was a responder only and could be instantiated and added to a scene. That would make scene status look like just another device. In the long run it might also allow for a more flexible (by the user) definition of what scene "status" might mean in cases a bit more complex that the 3-way like cases.

Just an FYI for anyone building one of these: I updated the 3D design files on Thingiverse (https://www.thingiverse.com/thing:1652666) to include a V5 version that incorporates the great ideas Emile provided about to do a much better bezel and to use inserts for the screws that secure the case and the Pi and screen. Overall these changes make the case look better and make it easier to assemble.

Aaron, The usage notes on github has the install instructions: https://github.com/kevinkahn/softconsole/blob/master/docs/useagenotes.md You should be able to run the piprep script and it will ask you a series of questions and then create directories and populate the console into them. It should also, if you answer yes to the question about autostarting on boot update the rc.local file to automatically start the console. You will need to build and config.txt file to have the console build screens otherwise you will just see a red exit screen when the console starts and immediately exits not having found a configuration. I suggest looking at the config.txt and stuff in the cfglib that are in the example config files at github. If this isn't working for you can you describe a bit more what isn't working and perhaps I can provided more help based on that. You do need to spec the correct display in on of the question in the script since the Adafruit folks have a 3.5 resistive and 2.8 capacitive and resistive models and they vary some in their drivers. Happy to help some more as needed. Kevin

Emile et al., I just pushed a 2.2 release as currentrelease. It improves the handling of an unexpectedly closed websocket stream by catching the situation and reopening a new stream rather than restarting the console entirely. This makes recovery from the close much faster (probably a second or two rather than 15-20 that it was). I still cannot diagnose the conditions that cause the close to happen. It simply manifests as either a close command in the stream or a 0 byte message - at least that is what the Pi library appears to be seeing. It does seem to be related to network noise since it happens more on some networks and systems than others. The release also adds a bit more diagnostic info gathering that may point at the underlying issue in the future. Kevin

OK - Thanks. That would explain why after I did a Query from the admin console things cleared up. So I am assuming that the ISY keeps the last state it had from the device but is saying that it's most recent attempt to communicate with that device failed. Good to know - just couldn't find it documented any place I looked.

When I start the event stream using websockets in the initial dump of device state info there is one record that arrives as: '<?xml version="1.0"?><Event seqnum="195" sid="uuid:70"><control>ERR</control><action>0</action><node>3B 92 51 1</node><eventInfo></eventInfo></Event>' I can't find any documentation of what control=ERR might mean. The device in question is a 6 button KPL dimmer and right after this record I see the Ramp, OnLevel, and 5 Button status events. The device appears to be functioning fine and from the admin console I don't see anything unusual about it. So why is this ERR event being sent and how do I diagnose what is going on? Thanks, Kevin

Nice job on the case improvements! I have heard/seen reference to those metal inserts but haven't used them. I assume you design a hole just a bit smaller than the insert and then heat/push the insert in using a soldering iron? Very professional look. May need to add some of those to my toolbox. Also like the improved bezel. I had one screen that came off as well but I just got some scotch permanent 2 sided tape and fixed it that way. But the light leakage, while not really an issue, does bother me. The case was my first real 3d print design effort and I did it because I couldn't find a case with a top/bezel for that screen. Don't know why I never added that lip once I had gained some more experience. Think I'll put that on the list to fix. As to the software. I verified that the empty scenes were not a problem of any sort. I just noticed them and didn't know whether they indicated some other issue - they don't. I'll keep adding as much diagnostic logging as I can to the comms in the program to see if I can get us a handle on what is going on. I have seen a log like yours once recently on one of my systems. What is bothering me is the fact that there is no actual error message coming up from the websocket library. If I set up a test where I forcibly break the connection using tcpkill (which spoofs a reset into the link) I do get an error message. I'd expect that if the comms just dropped out from a timeout of some sort I'd see some similar exception and there is certainly code to catch and report such an error. So while I think it is a low level comm issue I'm not fully convinced it isn't really a bug of mine. Just as a general observation, I do occasionally see retries on my boxes in the log. There are 2 places where they appear. First is in initially downloading the ISY device/scene info. There I have a significant time delay and a lot of retries since the most common reason for that failure is actually when the house takes a full power outage. The Pi simply gets back a lot faster (<20 seconds) whereas the ISY seems to take a minute or two to get back. The other place I see occasional comm errors is when changing screens out of an idle state where I do a rest query to the ISY for the state of the devices on the now active screen. That uses to have a long timeout which would make it look like the console had locked up when really it was just timing out. I greatly reduced the timeout there since the ISY really should either respond virtually immediately or you should just retry. So all this does suggest that the Pi comms can get into a funny state at times. Still my consoles all hold the websocket stream up for days to weeks without failures. By the way - my configuration has the consoles on WiFi and the ISY on Ethernet off the house router. If you get a failure where you docapture the debug info (will be in log.txt or if you set LogLevel to 0 in the Console.log file) I'd be interested in at least knowing what the last events on the stream were. I'll push a small update later today that has a bit more error capture in it and keep looking at my systems to see if I find anything in them. Kevin P.S. One last random item on a weird comm issue I discovered on a Pi recently. I had one Pi2 with a small plugin Edimax WiFi dongle that would not consistently keep its name active on my network using mdns which is a multicast protocol. I had pulled out my little remaining hair trying to understand why that system, running an identical build to other systems that used USB dongles or Pi3s was the only problem case. I swapped out the dongle for a different one and the problem was cured! There is no "rational" reason why this should be an issue but I found a very obscure reference to a broadcast issue with some wifi chips which seems to be what I had run into. So if you happen to have a different dongle around you might try swapping and see if it makes any difference even though I don't think broadcast/multicast should be involved here.