kck

You have and extra ExecStart it looks like. The stuff after the '=' is a normal Linux command to execute. Also note that you should wait a bit before looking since the sleep thing always delays the actual console start by 5 seconds from when the service is nominally started. It's really only there to keep tight error restarts from happening. I'll look at the touch stuff in a bit (dinner time lest my wife get too upset with me :-))

Yup - that's definitely a different screen. You can get by the dimming issue with a small edit to a file for now if you want to try it. In consolestable open the file hw.py with sudo nano. All the way at the very bottom of the file you will find: def GoDimPi7(level): with open('/sys/devices/platform/rpi_backlight/backlight/rpi_backlight/brightness', 'w') as f: f.write(str(level * 255 // 100)) Delete the last 2 lines and replace with a single line that has a tab then pass, i.e., it should then look like: def GoDimPi7(level): pass Make sure that the indentation is a single tab - not spaces. Exit with ctl-X and accept the write of the file. This should make brightness control a no-op. Now beyond this I am not sure whether the HDMI screen will work. It's a completely different type of output system but it is worth a try. Unfortunately I don't have an HDMI screen to try things on. Kevin

The screen that the system is tested for is the Raspberry Pi foundation official 7" screen. I'd bet that you have a Chinese screen - that's fine but unfortunately may give issues for the Console. How is the screen connected to the Pi - via HDMI cable or via the direct ribbon cable? Also, does the screen have any documentation regarding dimming it? I may be able to just disable dimming for you and see if things will work. Kevin

@garybixler What screen are you using? The console is looking for the control "file" for a 7 inch Adafruit PITFT. So presumably you installed specifying that screen type? If you have that screen the system should have created an entry with the path /sys/devices/platform/rpi_backlight/backlight/rpi_backlight/brightness. Does that exist on your system? If you are using one of the other supported screens then the dimming is done differently and that code would be replaced by other code.

@bambamf16 Oops - I duplicated your type with capital S. Can you just edit that test program to a) change the "fb1" to "fb0" and capitalize the S in the string with Goodix? That should make it run. That 203 Exit according to a google search says that systemd didn't know the interpreter to use. But the runconsole.py (which is just a smaller version choosing program) has the #!/usr/bin/python3 at the top which works fine for me. One person did comment that if the file had been left in DOS terminator mode that would mess up the interpretation of the shebang at the start. Any chance you happened to have it open for an edit? What you should see in a systemctl status is: ● softconsole.service - SoftConsole Loaded: loaded (/usr/lib/systemd/system/softconsole.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2019-06-04 10:19:01 PDT; 3 weeks 2 days ago Process: 4058 ExecStart=/home/pi/consolestable/runconsole.py (code=exited, status=0/SUCCESS) Process: 4057 ExecStartPre=/bin/sleep 5 (code=exited, status=0/SUCCESS) Main PID: 4062 (python3) CGroup: /system.slice/softconsole.service ├─4062 python3 console.py ├─4069 python3 console.py └─4093 python3 console.py Worst case I think you could edit the service file to say ExecStart=/usr/bin/python3 /home/pi/consolestable/runconsole.py but really it should work fine the way it is.

@garybixler That suggests something is wrong with your systemctl service file. Did you edit it in some way? I have never seen anything like "boot-softconsole" so I can't really help there - that is happening before softconsole ever starts apparently. I can tell you that there should be a file in /usr/lib/system/system with the name softconsole.service and it should be identical to the file in ~/consolestable/scripts/softconsole.service. By the way - what version of Raspbian did you load? You should be on the Stretch version from 04-08 (or possibly an earlier version of Stretch). There is a Buster release now available but I just briefly tried an install with that and there seemed to be issues. But that only appeared in the last day or so. Don't use that for now. @bambamf16 When you say the console won't autostart what symptom are you seeing of that? Look at systemctl status softconsole to see what was going on or scan /var/log/syslog for entries starting with "softconsole" to see if you see any error messages, exception reports etc. By the way, those timestamp files are indeed debug log file that should be going elsewhere. Just delete them and I will look at avoiding them on early exits for the future. Regarding the screen calibration stuff; I am attaching a file below that you should run to test the screen from the perspective of my console touchhandler. First, turn off the creation of a desktop on the console screen by running (from the VNC terminal) sudo raspi-config and selecting boot options, then desktop, then Console Autologin (option B2). This gets rid of any interference from the X desktop. Reboot and you should just see a text terminal on the pi screen. Then run the program with sudo python testtouchhandler.py from the virtual terminal. You should see some output then a request to touch the screen. Every touch of the screen should result in some coordinates showing Press, possibly Move(s) when your finger shifts, and Release. Drag your finger from someplace on the screen off to each side (left, right, top, bottom) a few times each. What I'm trying to collect is the min and max coordinates reported in each direction. Then hit ctl-C and you should see a report of those min and max values. Those are what I'd like back. By the way, you might also see if the screen seems sensitive at all places. Any touch should give a set of touch coordinates so if you thought things seemed non-responsive with the console running on a part of the screen, see if you get a response in those same spots with the test program. Hope this all makes sense - essentially I'm trying to discover what your screen reports for touches in the x (horizontal) and y (vertical) directions. One other thing you can verify is that my x and y agree with the orientation you are using. If you touch the left bottom corner of the screen you should be seeing a coordinate with a low first value and a high second value (ignore the 0 that shows as the first value in every touch report). In fact, it would probably be useful to just do a touch in each corner and tell me the values for the upper left, upper right, lower left, and lower right to make sure I orient the touch space correctly to the display space. Kevin testtouchhandler.py

That's odd because to my knowledge capacitive screens don't need calibration. They just return pixel coordinates. Just so I am clear, this latest somewhat working setup has pi7 as the screentype and the touchscreen type constant that matches what you get from the system device? I may need to see if I can find some better documentation for the screen and possibly add some debug info to a beta to sort out the touch mismatches. There are reports I find in Google about calibration issues on that screen but they make no sense if it really is a cap screen.

If touch was working you'd just go to maintenance and tell it to shut down. if it was started as a service automatically, then sudo systemctl stop softconsole should work. If you started it some other way then do a ps agx | fgrep console and issue a sudo kill -SIGINT on the console processes that you see there.

@bambamf16: That would have been my next suggestion. The error you got with pi7 is because apparently your display does dimming in some other way. But with custom the code will point the display at fb1 which you don't have. Are you actually seeing a console screen appear? With the screentype as custom right now you simply aren't getting a touchhandler started in the console which is why you aren't seeing touch working. Of course, it is possible that even if the handler was getting started it might not work. Right now the code for the screen and the touch handler are a bit intertwined for historical reasons. I can probably clean that up but it may take me a day or two since that is old code I haven't looked at in a long time. If you want to try one more patch at your end, you can go to the file hw.py (not hwa.py) and all the way at the bottom you will find the lines: def GoDimPi7(level): with open('/sys/devices/platform/rpi_backlight/backlight/rpi_backlight/brightness', 'w') as f: f.write(str(level * 255 // 100)) You could try deleting the last two of these and replacing them with a single line that has the same indentation as the "with" that just reads "pass" Make sure that the indentation is achieved with a tab character not spaces (Python is picky). This should make brightness setting a no-op and get rid of the error when you set the screen to pi7 and should get you the right touch handler. I have no idea what you are seeing with files that have date/time names. Do they have any interesting content? They might be some log files that are getting in the wrong place as a result of some exception reports happening very early in initialization before the structures to get them where they belong are set up. Kevin

@garybixler: If you do a nano on pisetup it should just say Read 323 lines. If it also says "Converted from Mac format" then the file is still in a bad format (Mac version of bad versus Windows version of bad). When you do the write of the file from nano it should only show the name of the file to write - Alt-M when you try to write it out switches between Mac and Unix flavors. I just reproduced what you see on my system - if the file is in Mac format the pi just returns. Not sure why as I'm not a Mac person but you definitely have the file format wrong.

This one is easy. You somehow managed to get the file translated to DOS format from its original Unix format. Windows and Unix use different end of line conventions and it looks like you managed to get the pisetup.sh into Windows format so the shell on Linux couldn't make sense of it. Things you might have done to cause that are editing it and writing it back (even with no real changes) on Windows using a Windows editor. You should just copy the version from the GitHub copy and then copy that to the SD card. The easiest fix for this using the copy of the file you have is to edit it on your pi system. Run sudo nano pisetup.sh on the Pi. This opens the simple editor on Linux. You will see a highlighted line that says how many lines it read and then says '(Converted from DOS format)' Now type ctrl-O and it should say File Name to Write [DOS Format]: pisetup.sh Now type Alt-M and the 'DOS Format' part should go away. Now it return to actually write the file back. This should fix the line terminators. The difference in line terminator conventions is one of the more annoying differences between Windows and Unix and something to keep in the back of your mind if you ever see really weird messages from a program that is reading a text file in Linux. Always worth a check to see if somehow the file got written with the wrong terminators. Kevin

OK - Custom definitely won't work. I think pi7 should - you can check by editing the file in your home directory ".Screentype" to be "pi7" instead of custom. That should solve the output side of things (i.e., the can't find fb1 stuff). Editing that will avoid rerunning the install script. (By the way, the installconsole.sh is left in a directory of your home directory called consoleinstallleftovers). The issue wilh touch is that outside of the console you are running via an Xserver. The console does direct control of the screen and touch and so isn't using the correct driver info given the different name. If you are willing to try editing one source file we can see if the simple fix will sort this out. If not, I'll generate a beta release for you - just slower and you need to download a bunch to go that route. You will want to go into the consolestable directory and find the file touchhandler.py. Line 122 of that file defines TOUCHSCREEN_EVDEV_NAME. You want to edit this so that the string is 'Goodix Capactivie Touchscreen' instead of the 'FT5406 memory based driver'. I hope that this will let the console fine the touch events for your screen. If it does, then the only other issue may be the relative orientation of the touch event coordinates versus the actual screen. I.e., does where you touch correspond to the button drawn under the touch. It is possible that it might be flipped horizontally or vertically and I'd need to account for that. If you can try this and let me know what you see that would be easiest. If you're uncomfortable with editing that py file I can generate a full beta with that change instead. Once I know what works I can incorporate a permanent change in a next release. Kevin

That screen is not one that I have support for in the scripts or have every tried so I'm not sure what is going on. What sort of screen did you tell the install scripts you had? It looks like /dev/fb1 isn't defined which suggests to me that you chose one of the standard Adafruit screens or other. If you look in /dev you probably only have a fb0 defined. You might try installing as a pi7 and see how that works. It looks like the screen you have is capacitive which should at least make getting this to work seem possible (resistive screens are more of a bear to get right). Take a look at /sys/class/input and you should see a directory named event*, i.e., event0, event1, etc. First how many such directories are there? Hopefully only one, event0. For each such directory look at its subdirectory named "device" (e.g.,/sys/class/input/event0/device) and cat the file "name" and tell me what you get. I'm hoping you see "FT5406 memory based driver". If so the pi7 setting should be close and I may just need to possibly adjust some scaling. If touch works with that driver then let me know if touched seem to be in the right places and if the screen looks normal. You might also tell me what the console log says the screen dimensions are if the console starts with these settings. We can go from there to try to get that screen working for you. (Since that I can see of the documentation for that screen shows that it is 800x480 I think the pi7 settings may work out of the box.) Kevin

I just pushed V3.3.1 to GitHub. Release note: V3.3.1 is a minor update primarily to handle a discovery I made that any code that touches the file system on a Pi in any way can cause delays of many (up to 10) seconds. Normal logging activity from the console could therefore cause what seemed to be stalls of the interface. This release moves file system interactions to asynchronous threads that can suffer the delays without being noticed. The release also now handles Home Assistant nodes that the console knows about but that are not on-line in HA at the time the console starts. This can happen on systems that cohost both a console and home assistant at power up time because HA can be slower to initialize that the console. Other minor code cleanups and small bug fixes as always. The discovery about the Pi file system delays may be of interest to other users of Pi systems since it is an OS issue potentially impacting any system that has multiple processes doing a substantial amount of file I/O so I documented this issue (and another Pi item of possible interest related to WiFi dropouts) in a separate thread at: https://forum.universal-devices.com/topic/26380-couple-of-obscure-but-noteworthy-raspbian-pi-items/

I just pushed a new version as the currentrelease labeled as V3.3. It makes the screen title stuff discussed above part of the standard release and it pulls Dan's alert also discussed above as part of an install. Here is the full release description: (as always, I updated the usage notes to include documentation improvements for all this). V3.3 is a significant internal cleanup as well as adding a few features. It adds an ability to specify a title for a screen via the keywords - see the usage notes for details. If reduces or downgrades unneeded reporting in the log by changing the severity of many messages from Warning to Info or Detail. This should reduce log clutter. It improves some of the term shortening for weather based on experience with the APIXU weather service. It updates Home Assistant support to be run quietly with versions up to 0.90 by handling some of the newer HA domains that get reported. It also no longer installs any homeassistant libraries as part of the initial install which simplifies/shortens the install process for those who don't use HA. It now installs Dan's light sensor alert - see his github for details at https://github.com/ScrewLooseDan/softconsole_sensor_alert. Autoversion downloads are now done asyncronously to the console interactions so that the console isn't locked up while the new version is set up - this is mainly an issue on pi0 systems due to their speed making the setup a somewhat long process. Explicit maintenance screen updates are still syncronous. The release also adds a new alert that some might want to use. I have discovered that there must be some sort of a memory leak in Raspbian desktop since after very long up-times (40+ days) the Raspian X desktop that is created by VNC sessions winds up with huge memory use and eventually will cause the console to lock up. This alert (lxpanelreset) is meant to be run periodically (probably once every few weeks would be enough but I just run it once per day since it is harmless) to do a reset on the lxpanel which frees the memory. You could also do this with crontab but this saved me from needing to edit all my system crontabs. This version makes a major cleanup to how internal timer work for the console. This should be invisible to all users as it was done to make my maintenance and development easier but if you notice something strange regarding timing do let me know since regressions are always a risk with reworks. It adds a flag on the maintenance debug flag screen to force out a message to clear error indicators of all networked systems if you are using the multi-console error notice stuff. It adds a bit of a failsafe mechanism to catch dead consoles that get hung in a strange state. This doesn't happen often, but I had one system that seemed prone to it (possibly failing hardware) so I added a dead man timer process to restart a console in such a state. Again - this shouldn't be visible to you but . . . If anyone is running the "homerelease" version, there are some bug tracking/logging things enabled in that version - probably a good reason not to run my homerelease version as it is really meant for my houses.

No silly questions! Unfortunately, though, I don't use or even have the ISY Climate module so can't really help you on this one. I use APIXU for my weather (you can get a free low use code from them) and there are examples of its use in the sample config files - basically all the weather data manifests as store variables that can be referenced in screens, alerts, etc. If the ISY climate module has the ability to set values into ISY variables that would be a way to make them available on the console - don't know if it can do that. My guess would be no in V4 ISY and possibly yes in V5 since my sense is that the newer firmware has been trying to smooth the differences across variables and device states (e.g., I think you can actually get the temperature as a value from a thermostat in V5 whereas in V4 you cannot, at least in any easy manner). If you do see something that is missing that I could add (realizing that I don't actually have the module) let me know and I'll take a look. By the way, still planning an imminent release of an update but when you pointed out the installation of homeassistant in the install scripts, I thought I'd see if I could remove that. Turns out it was an artifact of how HA used to allow access but that with a small amount of work I can get rid of it for the future since HA changed their stuff a bit.

Great! By the way - it sounds like you are using HA (only or with ISY?). Besides me you will probably be the heaviest (only?) user of HA with the console so please do ping me as needed since the code has had a much more restricted use environment with HA than with ISY and likely has issues. Also, suggestions for improvements regarding HA use with it happily accepted. I've been doing a bunch of cleanup to the code, much of it related to HA and specifically updating my fairly old version of HA to the near current (.90.2 since I had issues with .91 and zwave). I'd been sitting on that since I didn't think it impacted anyone else, but I'll push it to github later today and I'd suggest updating to that once I do since it will provide a cleaner baseline and fewer spurious HA log messages.

That's odd - aiohttp is some Python library that the home assistant access module just uses (that module actually came from the HA folks - I just sucked it in to my download when they decided to stop supporting it directly) and it seems present on all my systems. I will do a clean build/install at my end to see if something has changed to make it not a part of the standard install. In the meantime, you might try doing a "sudo pip install aiohttp" to see if you can get it installed manually. Basically what you are seeing is a Python "compilation" error (it doesn't really compile) where it fails to find a needed library. By the way, VNC should run fine in normal landscape mode since it doesn't access the desktop on the pi screen. There is a secondary VNC port that gets set up if you explicitly choose a port at that chosen port -1 that does overlay the pi screen and would be in portrait but you'd have to go out of your way to get to that one and generally I wouldn't/don't use it except for some wierd debug situations. I do all my normal access into the consoles for maintenance etc. from a PC running VNC viewer from RealVNC and that works great.

Did you ask the scripts to have the console start automatically? Sounds like after the install you are just rebooting to the standard Linux desktop. Assuming you can access the system either on that tiny desktop or (preferably) via vnc from a real desktop, su to root and try systemctl status softconsole. I would bet you will see that it isn't running or even possibly enabled. Assuming that to be true, systemctl enable softconsole followed by systemctl start softconsole should start the console. If this is not the issue then we can try to figure out what is really the problem, but the install scripts seem to be pretty reliable these days. You might also look in the ~pi/Console directory to see if there is a Console.log file there and if so tell me what it in it. The presence of such a file would indicate that the console did try to start but failed and then I'd expect something useful in the log. Let me know in any case and I'll try to help you sort it out. Kevin

Just pushed a beta version with the screen title capability in it. I've tested it but since I don't have a lot of use for this at this point I figured I'd turn it loose on you to try. The title capability is enabled for most screen types: clockscreen, keyscreen, thermostatscreen(ISY and Nest), timetemscreen, weatherscreen. There are 3 relevant keywords: ScreenTitle = string is the title (duh!), ScreenTitleColor = white is the text color, and ScreenTitleSize = 50 is the text size to use (obviously choose your color and size). If you set a non empty title the rest of the screen shrinks vertically to allow the space. Some of these screen types already had a label keyword. That is still there, and if you don't set a ScreenTitle explicitly that value is used. It is also used in any case for the nav key on the previous and next screens. So this allows the nav name to be different that the title if you set them differently. See if this gets you what you'd like or whether some other tweak would help. I'll be traveling Wed through next Tuesday but may get on line to answer questions but can't update code until I'm back. Enjoy! (In case you haven't done it, get the beta by going to maintenance, selecting to use beta, download the beta from the same screen, and then restart the console.)

Wow - you really dug into that! What I'm going to do is just add a general property on any screen for a title. Some screens already have it as a specific feature (thermostat, weather) so I just need to rationalize those with the general capability. I have a first test version running but want to make sure I haven't broken something. I'll try to push a version to try next week - sooner if I get the time.

Sorry - I missed that you asked that before as I was leaving for a trip. There isn't at the moment but let me take a look at how hard it would be to add for you.

Do you mean for my softconsole or did you post this in the wrong thread? For softconsole pretty much everything is customizable but I'm confused by your reference to "standard Insteon buttons" since the console doesn't have anything referred to that way. If you mean virtual buttons on the softconsole that correspond to Insteon devices then the softconsole documentation describes pretty well how to set their color and even change their color based on state of the device.

You can clear the error notification. The way that works is that each console records when its log starts (basically its startup time). When you view a log on any console it broadcasts an update to a variable called GlobalLogViewTime that is its log start time. Then any console with a first unseen error with a time later than that clears its flag. This is done so that if a console starts after another one has seen an error, viewing the "newer" console log doesn't clear the error that occurred before it started. Sort of a same if inexact way to not miss something. So, if you want to get all the consoles to clear you'd publish to all a set of System:GlobalLogViewTime to 0 or some other small value. You can see the code that does this in logsupport.py line 296.

OK - I'll stick it in next time I update stuff and point to your GitHub. Guess I'd better not break the management console reporting stuff now that someone else is using it! JSON: take a look at the example config pgawmqtt.cfg in the distribution. The parsing I do is very simplistic. You should be able to set the Topic = garage/wemos/tele/SENSOR and then json = AM2301:Temperature and TopicType = float which should all get you a store entry at MQTT:XXX assuming you named your MQTT feed "MQTT" (change as needed) and XXX as the name of the entry from the mqtt config. Basically the flow is that the mqtt section defines a mapping from topic and value (extracted from json if needed) to a store entry that you can then use as you wish. I do exactly what it looks like you are doing where I have a bunch of ESP-01s with temperature sensors running Tasmota (great contribution from that author!) that report with MQTT packets every minute or two. Let me know if this doesn't work.