quite some logs, will try to read a bit before killing etc.
edit : killing make touchscreen actif again, now let’s restart the app and see if it is actif again without a reboot
restarting without reboot made it come to normal. See if it stays ok if it comes back after 24 hours.
Weird!! Let me know how you get on.
mmm another reboot and it doesn’t work anymore … weird
the latest log
[INFO ] Logger: Record log in /home/pi/.kivy/logs/kivy_18-09-17_0.txt
[INFO ] Kivy: v1.11.0.dev0, git-038acbf, 20180915
[INFO ] Python: v3.5.3 (default, Jan 19 2017, 14:11:04)
[GCC 6.3.0 20170124]
[INFO ] Factory: 195 symbols loaded
[INFO ] Image: Providers: img_tex, img_dds, img_sdl2, img_pil, img_gif (img_ffpyplayer ignored)
[INFO ] Window: Provider: egl_rpi
[INFO ] GL: Using the "OpenGL ES 2" graphics system
[INFO ] GL: Backend used <gl>
[INFO ] GL: OpenGL version <b'OpenGL ES 2.0'>
[INFO ] GL: OpenGL vendor <b'Broadcom'>
[INFO ] GL: OpenGL renderer <b'VideoCore IV HW'>
[INFO ] GL: OpenGL parsed version: 2, 0
[INFO ] GL: Shading version <b'OpenGL ES GLSL ES 1.00'>
[INFO ] GL: Texture max size <2048>
[INFO ] GL: Texture max units <8>
[INFO ] Window: virtual keyboard not allowed, single mode, not docked
[INFO ] Text: Provider: sdl2
[INFO ] GL: NPOT texture support is available
[INFO ] ProbeSysfs: device match: /dev/input/event0
[INFO ] MTD: Read event from </dev/input/event0>
[INFO ] ProbeSysfs: device match: /dev/input/event0
[INFO ] HIDInput: Read event from </dev/input/event0>
[INFO ] Base: Start application main loop
[INFO ] MTD: </dev/input/event0> range position X is 0 - 800
[INFO ] Support: Starting twisted reactor
[INFO ] MTD: </dev/input/event0> range position Y is 0 - 480
[INFO ] HIDMotionEvent: using <b'FT5406 memory based driver\x00 $
[INFO ] MTD: </dev/input/event0> range touch major is 0 - 0
[INFO ] HIDMotionEvent: <b'FT5406 memory based driver\x00 $
[INFO ] MTD: </dev/input/event0> range touch minor is 0 - 0
[INFO ] HIDMotionEvent: <b'FT5406 memory based driver\x00 $
[INFO ] MTD: </dev/input/event0> range pressure is 0 - 255
[INFO ] HIDMotionEvent: <b'FT5406 memory based driver\x00 $
[INFO ] MTD: </dev/input/event0> axes invertion: X is 0, Y is 0
[INFO ] HIDMotionEvent: <b'FT5406 memory based driver\x00 $
[INFO ] MTD: </dev/input/event0> rotation set to 0
[INFO ] Base: Leaving application in progress...
[INFO ] Support: Stopping twisted threads
[INFO ] Support: Shutting down twisted reactor
I have a similar issue with WFArchive. A reboot starts the applications before all the services are ready. I am working on a fix that will delay the start of the applications for a few seconds to make sure the RPi and all other needed applications have all started.
@eric, that’s a good question. Are you starting the application manually once the Pi has booted, or is it booting straight into the console?
Also, I assume you have made the necessary changes to ~/.kivy/config.ini as per Step 7 of the instructions:
Delete everything in the [input] section. Add this:
mouse = mouse
mtdev_%(name)s = probesysfs,provider=mtdev
hid_%(name)s = probesysfs,provider=hidinput
and are not running as root?
not as root, auto start via the trick mentioned above, avoids to have a terminal open or to use screen.
when booting the home page comes up and a little later your script starts
guess it starts to fast as Gary mentions … how can we add a delay in the trick ??? Mmmmm
yes I did the change in kivy but will recheck if it was maybe altered
edit : still there untouched
edit 2 : pid is pretty low when auto starting (like 390 when there are +600)
killed the service and restarted via terminal (pid must be higher and touchscreen is active for your script
Hence Gary’s theory seems to hold
Is this the trick you are using: https://www.raspberrypi.org/documentation/linux/usage/systemd.md?
If so you can use the
After=
argument to make sure it doesn’t boot until after the touch screen is available. I have never tried this so not 100% sure what you would need to add to relate to the touchscreen.
nope this one : Announcements & Updates - #69
OK. That makes sense. Autostart is not something I have investigated yet, but sounds like it is not completely straight forward. I think the systemd.md approach is probably the best way to go. Does anything in this link help: Kivy and touchscreen at startup - Raspberry Pi Forums?
I’d try and help troubleshoot, but I am currently in the process of ripping the guts out the console to make it compatible with all the different unit combinations!
no hurry
will have a look and see if I can rework it for the script , no promise 
and a thing for tomorrow evening as zzz time is coming and honestly, trying this when you’re hald asleep
happy fiddling with your script 
I can only give the same advice I gave to Gary, go modular and not 1 file doing all, you can dev later new modules that are called in the main part, hence no need to break all every time you want to add, alter something, just the module
will be more work today but ask Gary, less tomorrow
Edit: This auto start script is now included in the WeatherFlow PiConsole download. Follow the Auto-Run instructions on the GitHub page (GitHub - peted-davis/WeatherFlow_PiConsole: Raspberry Pi Python console for WeatherFlow Tempest and Smart Home Weather Stations) to get setup.
Hi @eric, I’ve been having a look at autostart options and think I have a solution. If you’re willing to test it, details are below.
Navigate to the WeatherFlow PiConsole directory:
cd ~/wfpiconsole/
Make a new file called WeatherFlowPiConsole.service
nano WeatherFlowPiConsole.service
Copy this into the new file (this assumes you have the Console installed to the default location and are using the default ‘Pi’ user)
[Unit]
Description=WeatherFlow PiConsole
After=network.target
[Service]
ExecStart=/usr/bin/python3 -u main.py
WorkingDirectory=/home/pi/wfpiconsole
StandardOutput=inherit
StandardError=inherit
Restart=no
User=pi
[Install]
WantedBy=multi-user.target
Copy this file into /etc/systemd/system as root
sudo cp WeatherFlowPiConsole.service /etc/systemd/system/WeatherFlowPiConsole.service
Start the service using
sudo systemctl start WeatherFlowPiConsole.service
If the console boots and everything is working, kill the Python task and set the service to start automatically at reboot
sudo systemctl stop WeatherFlowPiConsole.service
sudo systemctl enable WeatherFlowPiConsole.service
Reboot the Pi and wait for it to auto-start. I have told the service that an internet connection needs to be present before it can start, so there should be no problems with the screen not being ready. Let me know how you get on, and if it works I will add the .service file to the next release.
One question.
Have you considered what will happen if another application forces the use of the folder name “WeatherFlow?”
I considered using that folder and then I realized it is too common and might cause issues in the future.
will test it tonight when I come home. Only have a few mins left to go to work now
Worked! Thanks.
Did several reboots just to test…all good.
Great! Good to hear.
confirmed, tried a few reboots, let’s see 24 hours later
That’s a very good point. What directory name do you use for your archiver? Perhaps we should try and have a fixed directory naming convention for the different programs written for the Raspberry Pi?
I use ‘wfarchive’ currently. I was using ‘wfarchiver’ and found that the ending ‘r’ was awkward to type. So this current version has so many changes that I also renamed the application.
I’m just trying to think ahead and avoid any conflicts but you know something will come back and cause me issues. 
I’m always open to ideas to make it easier on the user. @eric ha good ideas so maybe he can offer suggestions.
24 hours later (or almost) and it is still running fine … no hicups.
Regarding names, always hard to find a name that covers the package
If the script doesn’t change it is supposed to run as is 24/24 7/7 , no other program can run except in the background since there is no way to stop it via the touchscreen, even less toggle to home etc …
As long this is the case, most probably no one is going to run anything else next to it.
And indeed I was already thinkering that using a pi just for this little console using hardly any resources is an overkill (ok we know the pi zero can’t)
I installed snmpd to track the usage and only possible problem I see is the ram usage, slowly but surely it is rising … slowly. Not even sure it will ever proof to be a problem … an extra week without a reboot will tell if it continus to rise or stabilises.
will thinker a bit about naming … 
Apps shouldn’t “force” use of a directory name. They should have a configurable default location…but that said, probably naming it something more like WeatherFlowPyConsole or the like to try to be probably unique might be a good idea.
It looks like he might have it configurable based on the config file snippet in the post above yours…
WorkingDirectory=/home/pi/WeatherFlow
But the snippet only has the systemd startup file. Whether the code cares where it’s installed to or not is a different thing. Well written code shouldn’t care where it’s installed to.
It’s a pi, so I’d recommend using the normal LSB directory locations rather than user pi’s $HOME. For extra points package the whole thing up as a .deb file that would be easily installable and that installs all the prerequisites/corequisites. That would be really slick.
(disclaimer - it’s been…an adventure, shall we say…in weewx land trying to package things so it can be installed and updated and removed cleanly, but in this case it’s just the Pi and likely only modern Raspbian, so that would make a lot of the pain points go away)