kck

Gary, If you plan to do most editing on the Windows side and then move stuff to the Pi let me suggest you download/install WinSCP ( https://winscp.net/eng/index.php ). This gives you a very simple graphical interface to copying file across machines. It will remember your login info and then you can just open it and have 2 panes one into your PC and one into the remote machine and do drag/drop between them. You might also get Notepad++ ( https://notepad-plus-plus.org/ ) wich is a nice text editor for Windows and you can right click along the bottom and change the line termination from Window/Unix. So this way you can safely edit your Linux files on Windows and never worry the termination question again. While both have tons of features you can happily ignore most of them and they provide simple editing and transfer in a "Windows" style. Kevin

If you just want to read the examples and perhaps copy some snippets and do it on your PC an easy way to do that is to open your browser to https://github.com/kevinkahn/softconsole/tree/master/example configs and you can see all them there. For that matter you can see all the source code and scripts there. Then you can easily copy/paste snippets into whatever your favorite dos editor is. Just remember when you want to put a file that you create that way on Linux to fix the line terminators.

Just use less or any other Linux display tool. They are all just text files.

Great. I was really pulling my hair out trying to figure out what the console was doing because what I was seeing just didn't make any sense. Hopefully you can add the switch back and things will still work. Kevin

I tried that on my system and that doesn't seem to be it. I've never seen a structure like his is reporting. It really looks more like he did a replace device at some point that didn't fully work or something. I don't think an internally consistent ISY should ever report what I'm seeing his report.

@garybixler There is something very unusual about your ISY configuration. You have a node, that Front Door Keypad with the Insteon address 4D 3A 57 1. The actual button on it look correctly reported as ending in 1 (the top) and 3, 4, 5, 6 (so looks like this is a 6 button switch with the top and bottom controlling 1 device.) The parent for the main device (ending in 1) should be the internal ISY address of the folder it is in but in fact it seems to have no parent. The parent for the sub devices (the other buttons) should be the main device but instead are listed as A D5 3A 1 which looks like an Insteon device but that device doesn't even exist in your configuration. So what is your Insteon device A D5 3A 1 and what folder is the actual device in? Looks to me like at some point the ISY internal database has gotten messed up (don't think this is a v5 issue since to my knowledge others are running with v5 and this part of the ISY stuff hasn't changed.) Kevin

Think you left off the " ." at the end to tell it where to copy the file to. "." means current directory.

Beat me to it. To be completely specific: on Windows go to Powershell and issue: scp pi@rpi-dev7:/home/pi/Console/xml.dmp . Where your replace "rpi-dev7" with the name of your Linux system. It will prompt you for your Linux password and do the copy to whatever directory you are in on the Windows box. Then you can just attach the file to a message in this thread.

I suspect that these is something in your configuration of your ISY that I haven't seen before and the console is tripping on it. Can you edit the config.txt file and add a single line to the top that reads: ISYDump = True Then run the console again. After it fails with that error 13 you should find a file in the Console directory called xml.dmp. Can you send that to me. (It doesn't really have any privacy sensitive info in it but it is a dump of what the ISY gives the console as its node structure.) With that I may be able to find my bug since even if this is due to something I don't support, it shouldn't crash without better information. Kevin

Ah - good. That exit code 13 is for a fatal error exit that the console has hit. Take a look at Console/Console.log. There are only about 3 places that can arise from and they are all basic configuration file related items. If I had to guess, I suspect that your ISY credentials are somehow not getting you to the ISY but the log should have a reason right before it exits. Wait - I see that you also posted the proximate cause above. Some issue digesting you ISY stream. I've never seen that - let me look at the code a bit and perhaps I can find the bug/issue.

I don't think the ISY version in general should have any impact. Couple of questions: are you running stretch or buster Raspbian? If you do a ls /dev/fb* what do you see? If you do a systemctl status softconsole what do you see? Do a journalctl -u softconsole - go to the end (End key) and look backwards at the messages - what are they. In particular you should see a "Starting SoftConsole message from systemd. What follows that? Just so you know, I have 2 systems (one I develop on) that are Pi3B+ with the foundation 7"display on them. Just today for reference I imaged one with Raspbian, having copied over the pisetup.sh and network supplicant files, remotely logged in to the system over ssh, sudo'd and went to /boot and ran pisetup. After answering the question, the system goes through a reboot, installs the console, and does another reboot. For my purposes, I had not set the console to automatically run at boot so I remotely logged in (either via ssh or via VNC) did a sudo systemctl start softconsole. This takes about 5-10 seconds after the Pi screen turns blue and I see the console log start rolling by until eventually the home screen appears. For reference I do not have a keyboard attached to the Pi nor do I use tha Pi screen as a desktop. I shouldn't matter if you did but I wanted you to understand everything possible about my flow. You are using a stock screen that I use on a standard pi so this should really all work. Where I expect confusion is in building config files which is why I have that ability to build a minimalist one for you so you can at least verify that things come up. There is likely something that you are doing that is different from what I just described. If you can think of what it might be I may be able to diagnose what is happening. By the way, it sounded like earlier you may have gotten the red screen error about no config file. If you did, that was the console running which proves it could see and use the screen at least at that point, though why you had no config file I don't understand. As I mentioned above, verify that in Console directory you have a fairly short config.txt file and that in Console/cfglib you have an auth.cfg file that look like it have the correct stuff for your ISY (address, user name, password). I hate seeing folks frustrated, especially if it might be because of some error or confusion I created so I would like to help at least get a sign of life. By the way, if you are on Raspberry Stretch then you should stick to the stable release. The beta works fine for me but it has fewer miles on it. Let me know any other way I can help. Kevin

@garybixler Don't know what you're doing if the screen doesn't rotate. That's straight Raspbian function. If you don't say Y to flip then the screen will appear in landscape oriented so that the power plug of the attached Pi points down. If you say flip then all that happens is that the directive lcd_rotate=2 gets added to the OS /boot/config.txt file which makes the screen appear in landscape with the power plug pointed up. Nothing to do with the console code at all - 1 line in the install script. As for the minimal example. You should have a file config.txt in your Console directory that describes the 1 screen it creates and you should have an auth.cfg file in Console/cfg that has your credentials. That hasn't been touched in my code in a long time and I just checked and it seems to work fine. No console config found means that in ~pi/Console it found no config.txt file nor a file of the form config-<nodename>.txt - If the console can't find either then you get a red screen that says no config file found and an exit.

1. Actually since you have the beta there is a facility that I haven't put in the general release yet (will be in the next one) motivated by a request up the thread, to support "GOTO" keys. This is a key that takes you directly to another screen you have defined that doesn't use the nav keys at the bottom. I don't currently support 2 completely different actions for single and double tap on the same key (I'll put it on the idea list) but you could have 2 keys on a screen one of which turns on/off the Fan-Medium scene and one next to it that does a GOTO a fan selection screen. That's at least close. GOTO isn't in the usage notes yet but there is an example of it I've been using for test in the "TreeTest" screen in the config-rpi-dev7.txt file in the examples. 2. Close - look at the SETVAR key. You can have each press move to a new value that is in a list so it isn't unlimited but you could have the list be 1, 2, 3, 4, 5 or even make the differences separate values. You can also change the key appearance to you'd visually know you were in override if the value wasn't 0. The label on the key can include the current variable value and is updated whenever that is changed either from a press of the key or from the ISY. I think that should be very close to what you want. See the garage.cfg file for a short example. Also the notes do cover this decently. 3. Don't think this one is there. There is a provision to set values based on time but that doesn't change the screens. -> idea list 4. You should have no problem accessing the same device from keys on different screens if that is the question. 5. Are you using v5 on your ISY with nodeserver? I'm still on v4. But I still think any device that acts like a switch should work. Worst case for now is that you could have the key trigger an ISY program to do the work. I am hoping to move to v5 if I get the time sometime this summer at which point I can fix any issues that. 6. Blanking is the extreme form of dimming (brightness = 0). So with dimming off there is no blanking. However it was my intent once we got you running to figure out dimming (even if it is only 0 or 1) for you. If you can poke around your screen documentation to figure out how to dim it, or if it won't dim then blank it, I should be able to pretty easily put that in. Right now the code supports 2 dimming methods (you can see their code in hw.py). PWM uses the pulse width modulation of the Pi to adjust the light intensity using pin 18. Pi7 uses a built in Linux pseudo device provided by the driver to set the intensity. Given that your screen uses all the connection pins on the Pi I would expect a variant of the first might work, perhaps with a different pin. Kevin

Hey I'm just an old retired software guy who finds some of this fun (and some frustrating). After climbing the corporate ladder to wind up far away from the bits I find it nice to remember why I got excited about computers nearly 50 years ago. Enjoy! (By the way, best bet on configurations it to look at my examples - they are all setups that run somewhere around my place. I think the usage notes are pretty complete too. Kevin

Well setting the scaling should fix the scrunching I think. But I've never actually used that code. What I should do is figure out how to create a screen mode that would help do all this but this is the first display that I've seen have this problem since I moved from the now-dead pygame touch handling to this native event based stuff.

FYI - there is a long thread ( https://forums.pimoroni.com/t/hyperpixel-4-touch-screen-dimensions-are-swapped/8198/38 ) on the Pimoroni forums about this reversal of touch and pixel dimensions. Not having the screen I can't follow it all but it seems a) this is a known issue and b) there *may* be some other drivers or firmware updates that fix it. But in the meantime it sounds like scaling a la my previous post is the solution.

Progress! You can try to get the touch aligned by playing with the values in touchdefinitions. The values for shiftx and shifty get added to the values that the hardware returns (the ones you ran the test for) and changing them should let you align the value that gets returned to the screen higher level code. That code expects (0,0) in the upper left going to the max screen pixels in the lower right (480, 800) Actually, looking closer at the values it is odd. Your horizontal (across the landscape) is 800 pixels but the touch values seem to go from 324 to 790 which is only about 470 so it would seem that in addition to subtracting the 324ish value the scaling should be set to 800/470, i.e. about 1.7. The vertical seems to go from -297 to 467 or about 765. So it would need to be scaled by 480/765. What bothers me (and made me not notice this when I looked at your results) is that 765 is ~800 and 470 is ~480 so it looks like the results are somehow rotated but that makes no sense since you were clearly getting values by touching the actual screen in its used orientation. By the way, it doesn't look like you need a flip - that handles case on some screens where the pixel values go in one direction and the touch values in the opposite one. That might happen here is you rotated the screen 180 degrees from its current orientation and the screen driver hardware got told about that. By the way - I assume that when you installed the screen driver there was some way to tell it that you were in landscape? Otherwise the pixel addressing wouldn't be working.

You need to fix the typo in touchdefinitions - the capital is missing there and that is what is being looked at.

Darn capitals. The error is in the touchdefinitions file. The instance in touchhandler isn't used any more - I should delete that but hadn't spent much time cleaning up old stuff.

Silly typo causing that - sorry. Edit the screendefinitions file. The line that defines pimoroni4 has slant characters instead of vertical bar characters between the last 2 parameters. It should look like this: pimoroni4|/dev/fb0|fbcon|None

OK - think I have something worth trying. Best would be to build a clean pi. 1. Make sure you get the new pisetup from github 2. This pisetup will ask if you want to download the beta also - answer Y 3. Answer N to the auto run of the console 4. It will ask if you want to install a screen. Answer N since I am assuming you will already have your screen on and working 5. It will ask for the type of the screen - answer pimoroni4 - this value is used in a lookup in a new file in the beta directory called screendefinitions. It must match an entry in that file and the rest of the line in that file has parameters. By the way, at the moment I am assuming that the Hyperpixel won't dim. It probably does but since I'm not sure how best to not try it for now. 6. After everything completes, edit the (root owned) file versionselector in the pi home dir to say beta instead of stable 7. Try doing a sudo systemclt start softconsole and cross your fingers At the least we may get some more info on adjustments. By the way, there is another file in the beta directory called touch definitions. It has the shift values etc. so if we are close but off a bit, you can tune things by editing it.

I'm in the process of checking out a beta version with configurable touch parameters - just want to make sure it's not DOA. Once I get that done I can have you redo the install if you are willing. In principle, this version allows specifying shifts, flips, and scaling for the input position values so we should be able to get them to align with the screen. Of course, I can really test that here without a screen that has those issues but I have tried it on my screens and it will create offsets (which make my screens misalign as expected). Installing that beta will also guarantee a clean baseline again. Probably this will take me another hour or so to validate. Kevin

That's pretty weird. It says it ran runconsole to success but there is a print statement in runconsole that should put an entry in the systemd log saying "Starting using directory: consolestable". I can come very close to reproducing your situation if runconsole.py is DOS or MAC format or is empty. All I can think of is that something has happened to that file. The behavior is that systemd thinks it has run runconsole successfully and is watching the resultant service which it seems to think is the sleep process since that is the last pid it knew about. So I would play around with runconsole a bit to see if you can get it to output something (e.g., add a print statement as its very first line) I think I am close to having a version with touch fixed up that I can give you. Just want to make sure I understand as much as possible about your configuration. The display is in landscape mode. It appears as /dev/fb1 (or is it /dev/fb0). You have a separate way into the system using a virtual terminal. When you did get the console display to appear, which terminal did you actually run it from? By doing a run from the virtual terminal or by doing a run from a keyboard connected to the desktop that shows on the Pimoroni screen?

That looks like it should if sampled about 1 sec after systemd decides to start things. I just did a start on my test console while watching from another virtual window and I see pretty much the same that you see. But then after a few more seconds the console starts. Do you see the same status after a minute or two? I don't claim much expertise regarding systemd - it has always seemed to work for me. You might try just deleting the entire ExecStartPre and get rid of the delay and see what happens. Beyond that I'm kind of stumped since there isn't much to the service definition for the console. Here's what it all does in case it helps you: [Unit] <- this is just boilerplate # Description could really be anything meaningful/distinct Description=SoftConsole # This should make sure the network is up After=network.target <- this says to start the service after the network is up [Service] # Script needs to be executable and first line will be '#!/usr/bin/python -u' Type=forking <- this is the type of the service, means the program that gets started will fork another process that is the real thing and then exit PIDFile=/home/pi/console.pid <- this says the original program will write this file with the pid of the real service RestartPreventExitStatus=11 12 13 <- these describe what to do if real service exits with these codes RestartForceExitStatus=31 32 33 34 35 # try not to start until system time has had a chance to update ExecStartPre=/bin/sleep 5 <- do this before trying to start the service ExecStart=/home/pi/consolestable/runconsole.py <- the service starter program # to test systemd stuff change to consolestable consolecur WorkingDirectory=/home/pi # Working dirctory gets moved to consolexxx directory by runconsole.py # Should restart service if it is not stopped gracefully Restart=on-failure <- if service exits with non-0 status restart (but modified by the stuff above # Slows things down a little on restarts, maybe doesn't need to be so long RestartSec=3 <- delay before trying a restart # Makes sure any output gets to syslog and named sensibly StandardOutput=syslog StandardError=syslog SyslogIdentifier=softconsole [Install] WantedBy=multi-user.target # Allows the use of journalctl -u softconsole.service to view relevant logs Alias=softconsole.service

Quick question: are you running the screen in portrait or landscape orientation? Looks like portrait but wanted to check since the screen coordinates make it look like landscape. That is one really weird set of touch outputs. They look sort of arbitrarily shifted. But I think I can figure out how to adjust for them.