Rainviewer stopped working for anyone else?

[Vindictor]

Hi there, When I went to bed last night (UK timezone) I noticed that my rainviewer cloud overlay had frozen. Oh well, this happens now and then..... I thought I'd shutdown, wait until this morning, boot it fresh and see if it works.

It does not. The rest of PiClock is functioning, Openweathermap data is there, local METAR data is there... the Google Maps images are correct, but no cloud overlay. Even if the skies were clear, I'd usually see "rainviewer.com" in the corner, and the time cycling through.

I've just tried an update.py and also a git pull to see if anything has changed. I already miss it. I genuinely use this weather graphic to judge when to go out, when there are showers/rain around.

Not sure if the service has been changed/stopped, or if it's just me having issues? Many thanks.

[feh123]

Hi I am in the UK and rainviewer is working for me. I am using the radar images for rainfall, I am not sure what you mean exactly by the cloud overlay.

[Vindictor]

Hi I am in the UK and rainviewer is working for me. I am using the radar images for rainfall, I am not sure what you mean exactly by the cloud overlay.

Thanks. I just mean the rainclouds, laid over the Google Maps image. I just visited rainviewer.com, and went to my location and found it to be working correctly from the website. Odd that it's been working perfectly on my PiClock and now has suddenly stopped. It's getting nothing, as I said, I don't even see "rainviewer.com" and the forecast times cycling in the corner of the map.

Anyway, thanks for your response. I guess it's just my PiClock!

[feh123]

Ah, okay. I am just using mapbox and rainfall radar. It does go down sometimes - it happened to me a few weeks ago. Rainviewer in my browser was working but the API seemed to have failed to deliver the radar pictures. It wasn't my PiClock and it came back after a few hours - so not as long as your outage.

On Thursday, 9 November 2023 at 09:52:21 GMT, Vindictor ***@***.***> wrote:  

Hi I am in the UK and rainviewer is working for me. I am using the radar images for rainfall, I am not sure what you mean exactly by the cloud overlay.

Thanks. I just mean the rainclouds, laid over the Google Maps image. I just visited rainviewer.com, and went to my location and found it to be working correctly from the website. Odd that it's been working perfectly on my PiClock and now has suddenly stopped. It's getting nothing, as I said, I don't even see "rainview.com" and the forecast times cycling in the corner of the map.

Anyway, thanks for your response. I guess it's just my PiClock!

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

[Vindictor]

@feh123

Yeah, I've had it freeze before, but not for as long as this. I thought I'd SSH into my PiClock and have a peek at the log files. For some reason they haven't updated since March 24! In the "Clock" subdir of PiClock, I see PyQtPiClock.1.log to PyQtPiClock.7.log. logs 1-5 are dated March 24, and the rest are even older.

I guess I'll leave it for now and if it doesn't work by the weekend, maybe I'll grab my Pi400 and set up a fresh SD card, and install PiClock fresh on that, transfer my settings across, and then move the SD card to the old Pi3 that runs my PiClock. Maybe even use the opportunity to upgrade it to a Pi4 and use it for more things,

I really do love my PiClock, and will miss it when it stops working. ;)

[feh123]

My PiClock is (nearly) up to date so that sounds a good idea (https://github.com/SerBrynden/PiClock). There was a lot of discussion about python 3 and pyqt5 but I think these updates are standard now. I agree - no PiClock is not good! It's brilliant. 

On Thursday, 9 November 2023 at 10:19:29 GMT, Vindictor ***@***.***> wrote:  

@feh123

Yeah, I've had it freeze before, but not for as long as this. I thought I'd SSH into my PiClock and have a peek at the log files. For some reason they haven't updated since March 24! In the "Clock" subdir of PiClock, I see PyQtPiClock.1.log to PyQtPiClock.7.log. logs 1-5 are dated March 24, and the rest are even older.

I guess I'll leave it for now and if it doesn't work by the weekend, maybe I'll grab my Pi400 and set up a fresh SD card, and install PiClock fresh on that, transfer my settings across, and then move the SD card to the old Pi3 that runs my PiClock. Maybe even use the opportunity to upgrade it to a Pi4 and use it for more things,

I really do love my PiClock, and will miss it when it stops working. ;)

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[Vindictor]

My PiClock is up to date, as far as the updater goes, but it was originally installed in 2017, and updated ever since then. I did try to update Raspbian in the past, which broke it (Python was updated on the newer version at the time, I think) so I wound back to a backup, and have stuck with it ever since. Currently running on Stretch, though I think it did actually start life on Jessie.

So maybe a fresh install wouldn't hurt. I see you recommended the SerBrynden version. OK, I'll give that a go over the weekend. Do you use Bookworm? Thanks for the responses. As I sit here now at Midday in the UK, still no rainviewer rainclouds showing on my PiClock. It's just strange how it stopped working, after having no issues whatsoever. Oh well. Cheers.

EDIT: I set this up so long ago I couldn't remember how I'd set PiClock to autostart. Seems I'd added it to ~/.config/lxsession/LXDE-pi/autostart. No idea why I did it that way, maybe that was in the original docs? It works, anyway!

My PiClock is (nearly) up to date so that sounds a good idea (https://github.com/SerBrynden/PiClock). There was a lot of discussion about python 3 and pyqt5 but I think these updates are standard now. I agree - no PiClock is not good! It's brilliant.  On Thursday, 9 November 2023 at 10:19:29 GMT, Vindictor @.> wrote: @feh123 Yeah, I've had it freeze before, but not for as long as this. I thought I'd SSH into my PiClock and have a peek at the log files. For some reason they haven't updated since March 24! In the "Clock" subdir of PiClock, I see PyQtPiClock.1.log to PyQtPiClock.7.log. logs 1-5 are dated March 24, and the rest are even older. I guess I'll leave it for now and if it doesn't work by the weekend, maybe I'll grab my Pi400 and set up a fresh SD card, and install PiClock fresh on that, transfer my settings across, and then move the SD card to the old Pi3 that runs my PiClock. Maybe even use the opportunity to upgrade it to a Pi4 and use it for more things, I really do love my PiClock, and will miss it when it stops working. ;) — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.>

[feh123]

I am on Bullseye. I have only learnt about Bookworm in the last few weeks and as my PiClock is working well I thought I would wait. Interested to hear how it goes! There is a thread on PiClock where SerBrynden helps me with a cronjob auto reboot. Don't know if that could be relevant to you.

[Vindictor]

@feh123 Great, thanks. I have Bookworm running on my main Pi4 here, which is used as a basic fileserver and gateway to my home devices while out (updated from Bullseye) but my Pi400 that I use for tinkering already has a new Bookworm install that I made last weekend, so I guess there's no harm in starting with that and seeing if it works. I may try this n0bel version as well. Of course what I'm really hoping is that Rainviewer starts working again, as suddenly as it stopped yesterday. All the best, and if it runs OK on Bookworm I'll post a response.

EDIT: and just for fun, because @feh123 said that his is still working, I just changed the coordinates in my Config.py to be around Buckingham Palace (51.50120367457228, -0.14243717904696152). I rebooted, and the map has correctly updated and it's interesting to see Tower Bridge, Covent Garden and more on the map, but, no rainviewer.com rain clouds over the map. I just thought I'd rule out if it's an issue with my location.

[SerBrynden]

@Vindictor The Rainviewer API sometimes goes down for awhile. And the old version of PiClock doesn't clear the radar boxes before updating, like it should, so you'll see previous old radar images.

The latest PiClock is my fork at https://github.com/SerBrynden/PiClock. n0bel has been absent for a few months. Mine works with Bullseye. You can use Bookworm, but PiClock requires some tweaking. You need to setup PiClock to run in a virtual environment because Bookworm forces Python scripts to run in virtual environments. I have yet to update my fork with new install instructions and startup script.

PyQtPiClock.1.log will always be the most recent, but might not give as much useful detail unless you are using my fork. In this case, it would probably show you the error messages that the Rainviewer API URL cannot be reached.

[SerBrynden]

@Vindictor Also, a new log file starts every time PiClock is started, the old files are renamed and shifted down, and PyQtPiClock.1.log becomes the new one. So your PiClock has probably been running since March without restarting.

[Vindictor]

@SerBrynden Many thanks for your response. I'll give your fork a try. actually I think I did try it back when the darksky issues were going on, and people were switching to openweathermap. I think I installed your version on a new SD card, but then got the original PiClock working, and because it was already in the Pi that I use and it was already setup, I just stuck with it. I guess it's time to move on. Maybe I'll take advantage of this and move to a spare Pi4 I have in a cupboard, which I can then use for a few extra purposes, too. Put PiHole on there, add a large EXT4 USB3 HDD and use as NAS... the Pi will be on, anyway. I guess I'll stick with Bullseye for now, on that device.

As for the logs, it's a strange one. That Pi is powered down every night. I used to leave it on 24/7 and just turn off the monitor overnight, but I ended up wearing out the button on the monitor! So it was easier to just SSH in to the Pi and shutdown, and power it up again in the morning. so it's actually cold started every morning. I've also rebooted it a number of times this morning. the log hasn't updated since March (and that seemed to show rainviewer issues, at that time) ((Yes, the time and date on my Pi are correct.... also the SD card is not full, I also checked that))

Whatever, it sounds as though I'd be better off moving to your fork, espeically if N0bel has now had to move on. I love my PiClock, and am delighted that someone else is still maintaining it. Thank you. (I actually have family members who will call / message me to ask if there's rain heading in, before they hang out washing, based on my PiClock satellite images!)

EDIT: Here you can see my log files, and the dates they were last updated, and the sizes

-rw-r--r-- 1 pi pi 9.3K Mar 24 2023 PyQtPiClock.1.log -rw-r--r-- 1 pi pi 9.3K Mar 24 2023 PyQtPiClock.2.log -rw-r--r-- 1 pi pi 9.3K Mar 24 2023 PyQtPiClock.3.log -rw-r--r-- 1 pi pi 9.3K Mar 24 2023 PyQtPiClock.4.log -rw-r--r-- 1 pi pi 7.1K Mar 24 2023 PyQtPiClock.5.log -rw-r--r-- 1 pi pi 7.1K Mar 10 2019 PyQtPiClock.6.log -rw-r--r-- 1 pi pi 3.0K Sep 25 2018 PyQtPiClock.7.log

EDIT2: Actually maybe I'll rename the log files to log.bak and see if I start getting new log files.

EDIT3: No I didn't. I ended up cp'ing the log files to another folder, as cp .log .bak didn't work, demonstrating my lack of bash skills) and then deleted the log files from the Clock folder. Reboot and... no new log files. (Unless as of March 2023 when the update.py script updated PiClock for openweathermap, the log files are now stored elsewhere) I just looked in /var/log, just in case. Obviously they're not in there. Oh well, I guess this is futile. better to just start again with your fork. Thanks again.

@Vindictor Also, a new log file starts every time PiClock is started, the old files are renamed and shifted down, and PyQtPiClock.1.log becomes the new one. So your PiClock has probably been running since March without restarting.

[SerBrynden]

@Vindictor How do you run PiClock? If you are using the command bash startup.sh -n -s then no log file will be saved. The -s option causes no log files to be created, but instead logs to your terminal screen. If -s is omitted, logs are created. The -s option is normally omitted when started from the desktop icon or from crontab.

[SerBrynden]

My fork at https://github.com/SerBrynden/PiClock is now updated to run on OS version Bookworm and should run on older versions as well, as long as it supports Python3 and PyQt5.

[Vindictor]

@SerBrynden Hey there, Thanks for the update regarding Bookworm. That's great to know. Rainviewer is still not working on my PiClock, so this weekend I will switch to your fork. As I mentioned previously I already have a fresh Bookworm install on my test Pi400 which I only made last weekend, and have installed Kodi and a few other things on there to test decoding and HDR performance.

I'll install your fork onto that tomorrow. Assuming all works well, I'll grab another SD card, install bookworm on that, and then your fork.... and then maybe some other services after everything is confirmed working.

As for how I'm launching PiClock, it hasn't changed since 2017. Log files used to be saved, until March of this year. This is an old (maybe the original) 8gb sd card. It did occur to me that it could be having issues.... but aside from rainviewer suddenly not working, and no log files since March, it doesn't seem to be having any other issues. If I just SSH in from here......

I launch PiClock from ~/.config/lxsession/LXDE-pi/autostart, as at the time it helped to also run some extra commands... I see @point-rpi still there, though commented out. Anyway, the command inside of autostart is just "/home/pi/PiClock.sh"

Next time I'll maybe just use cron, although running it from autostart does make it easy to comment out the command to prevent it auto booting when having issues, or wanting to do something else (as the Pi itself is out of reach, and with no keyboard/mouse attached - it's configured only via SSH)

Anyway, doesn't matter. My old PiClock is broken, for whatever reason. I'll copy the contents of my PiClock folder to a PC via FTP as a backup, and then I can easily copy and paste API keys and check configuration compared to the new install that I'll do this weekend.

I look forward to trying it on Bookworm, and I thank you for your time and effort. Do you have a paypal or something, where a small thanks can be sent?

[Vindictor]

@SerBrynden I just reread your post above, about the logging. I'd forgotten it will log to the terminal screen, as I usually have it autostart on that Pi. I've just commented out the command to start PiClock from autostart, and I will now start it manually via SSH and see what it logs to the terminal, regarding rainviewer (or anything else)

so... (and I forgot about the 45 second delay as I've not run it manually in a while)

pi@PiClock:~/PiClock $ sh startup.sh Waiting 45 seconds before starting Disabling screen blanking.... Setting sound to max (assuming Monitor Tv controls volume).... Checking for NeoPixels Ambilight... Starting NeoPixel Ambilight Service... Checking for GPIO Buttons... Starting gpio-keys Service... Checking for Temperature Sensors... Rotating log files.... Starting PiClock.... logging to Clock/PyQtPiClock.1.log ioctl UI_DEV_CREATE: Invalid argument

interesting that it says the log file is being created. and it has! Running it manually seems to have created a log file. I won't paste the entire thing, as it seems to contain my Google API key, as well as my local METAR location, oh, and my coordinates as used in openweathermap.

https://tgftp.nws.noaa.gov/data/observations/metar/stations/*******.TXT getting current and forecast:Fri Nov 10 10:12:16 2023 https://api.openweathermap.org/data/2.5/onecall?appid=* wxstart for radar1 wxstart for radar2 OWM one call failed, switching to weather and forecast getting current and forecast:Fri Nov 10 10:12:17 2023 https://api.openweathermap.org/data/2.5/forecast?appid=** ('getmost', {u'04n': 2, u'02n': 1, u'10n': 1, u'03d': 1, u'10d': 1}) ('getmost', {u'overcast clouds': 1, u'broken clouds': 1, u'light rain': 2, u'scattered clouds': 1, u'few clouds': 1}) ('getmost', {u'10n': 4, u'04d': 2, u'03n': 1, u'10d': 1}) ('getmost', {u'light rain': 3, u'overcast clouds': 2, u'scattered clouds': 1, u'moderate rain': 2}) ('getmost', {u'04n': 1, u'04d': 2, u'10n': 4, u'03d': 1}) ('getmost', {u'broken clouds': 3, u'light rain': 2, u'scattered clouds': 1, u'moderate rain': 2}) ('getmost', {u'04n': 2, u'04d': 1, u'10n': 3, u'10d': 2}) ('getmost', {u'light rain': 5, u'broken clouds': 1, u'overcast clouds': 2}) ('getmost', {u'02n': 2, u'04n': 2, u'04d': 1, u'10n': 1, u'10d': 2}) ('getmost', {u'light rain': 2, u'broken clouds': 1, u'overcast clouds': 2, u'few clouds': 2, u'moderate rain': 1}) ('getmost', {u'04n': 1, u'04d': 1}) ('getmost', {u'overcast clouds': 2}) ('wxmetar', '** 100950Z 31022G32KT 9999 SHRA FEW012 SCT016CB FEW018TCU SCT025 10/07 Q1000 TEMPO 3500 +SHRA SCT010 SCT016CB RMK WHT TEMPO YLO1') get... 1699608000 radar1 radar1 0 http://tilecache.rainviewer.com/v2/radar/1699608000//256/7/61/42/6/1_1.png getTilesReply 0 get... 1699608000 radar2 radar2 0 http://tilecache.rainviewer.com/v2/radar/1699608000//256/11/993/693/6/1_1.png getTilesReply 0

A bit edited, but no serious looking errors in there. One thing.... so I tried one of the rainviewer.com URLs (radar1)

http://tilecache.rainviewer.com/v2/radar/1699608000//256/11/993/693/6/1_1.png

I get a 404.

I'll try the other one (radar2) http://tilecache.rainviewer.com/v2/radar/1699608000//256/11/993/693/6/1_1.png

Yes, also a 404.

So, could this be the issue? It's running, but there are no PNG images to display? It looked like the rainviewer service wasn't running at all because I don't even see the text in the corner, saying rainviewer.com and cycling through the times of the forecast. I just see the Google Maps images.

Anyway, I got a log file written, and maybe these png files cannot be read in this way, anyway? But getting a 404 would certainly explain why they're not being displayed on my PiClock!

Hopefully this isn't the same on the new fork.

Kind regards.

EDIT: and just as I was about to log off, I thought to consider if using https would work instead. it does! If I visit https://tilecache.rainviewer.com/v2/radar/1699608000//256/11/993/693/6/1_1.png instead of http, I see the cloud image. So is it possible that they disabled http access and my old PiClock is still trying http? (even though I've tried git pull and update.py. I guess this old version simply hasn't been updated for a while) Maybe this is the cause of my issues?

[SerBrynden]

@Vindictor I think the old Raspberry Pi OS / PiClock had a problem with https. Also, old SD cards can get become defective and have problems writing new files, such as the log files.

[Vindictor]

@SerBrynden Hi there again,

Just a quck update. I just grabbed my portable/USB powered screen, my Pi400, and a powerbank for "easy tinkering" on the living room coffee table.

I've installed your fork of PiClock onto the Bookworm install I already had on the sd card.
Test 1.

It works! Great, thanks. Interestingly I still have my original PiClock running on its screen in the corner of the room. The weather forecast data differs! Both using the same owm api key. The text is also slightly different, but that doesn't matter. For example, for 9pm tonight, your fork says 2.9mm/hr, whereas the old PiClock says 9mm. (and has never said /hr) Not important, just an obervable difference. When I first saw the mm/hr it caught my eye as I've never seen this on my PiClock. on top of that, the text fits neatly inside the boxes, whereas on my old PiClock, since moving to owm, the text can go over itself at times when there's a lot of text"

Anyway, just for fun, here's my VERY temporary (UNTIDY) setup on my living room table. As I said, screen and Pi400 being powered by a powerbank. I haven't even changed the default background yet, I just wanted to test it, and I'm delighted to see it working) Thanks again. I did insert my local METAR into Config.py underneath the primary coordinates. I'm not sure if there's an easy way to tell if info is coming from here, or owm, but I assume it's working. (IIRC the time below "Feels like" is the last time that METAR updated? Actually there's another difference. on my old PiClock it just shows the last time it updated. On your fork it shows the time plus "GMT"

Great, happy to see it work. I'll leave it for now, and tomorrow will grab a new Pi4, a new SD card, and do it again (copying the config files I just made this afternoon), change to my usual background picture, and hopefully all will be well for the foreseeable future.

Thanks for all the help, and the work.

[SerBrynden]

@Vindictor If the PiClock is using METAR, the METAR station code will be displayed next the the "last update time" under the "Feels Like" temperature. You'll also see a METAR API call in the log. Check your config file to make sure the METAR settings are correct.

Also, if you'd like to see city names, roads, and borders on top of the rain clouds in the radar image, switch to MapBox maps instead of Google Maps. Otherwise, when you have a lot of rain over your area, it's hard to see where anything is on the map.

[Vindictor]

@SerBrynden

Thanks, once again, for the update. Interesting, the METAR code has never been shown on my PiClock. Not on the original, and not today when I tried your fork, and yet I recall the information being different when I added the METAR = to the relevant file. IIRC the last updated time never used to show either, before I started using METAR.... but it's never shown the METAR code on screen. Maybe something to do with the station I use. It (the METAR info) has gone blank a couple of times. When it first happened I disabled METAR and the current weather went back to OWM, and then I reenabled METAR and it was blank again.... until a few hours later. So METAR seems to be working (aside from those brief outages). Obviously the log file wasn't working for me, before.
It occurs to me that I'll need a Micro HDMI to HDMI adapter to use a Pi4 in the place of my current Pi3, so I may not set up the new one for a few days (unless I can find another spare one). But good to know it seems to work.

You can see in my photo that the METAR code isn't displayed, but the last updated time is there, so I assume this is from METAR.

I'd read other comments about the MapBox maps. I actually prefer the rain to cover the maps. I actually waited for the rain to mostly obscure my exact location before taking that photo ;) I live on the coast, I know exactly where I am on the map. If I lived in a big city area I can imagine having map borders would help. That rainviewer display can be invaluable to see rain heading in from the sea, and so for where I live, I much prefer it to be displayed as it is. It IS great, however, to have the choice! Thanks.

Thanks again for all your help. I imagine you've read quite enough from me over the past couple of days. I appreciate your fork, immensely. Thank you, and also for taking the time to respond.

Kind regards.

[n0bel]

The problem is indeed http vs https. I had changed PiClock last year (I think) to use http instead of https because users with older Pi's and OS's would not validate newer https certs. It now appears like http no longer works. I'll update to https, but older OS's will still be out of luck.

[n0bel]

changed http to https for rainviwer https://github.com/n0bel/PiClock/commit/e18e5b1a9241035d905f143a6026a33bc21e362e

[Vindictor]

Hey @n0bel , Thanks for the confirmation, and the update.

[Vindictor]

@SerBrynden

Thanks again for the help.
I installed PiClock on a fresh Bookworm SD card this afternoon. Have configured it mostly as before. With my old PiClock the text looked bolder and easier to read (also probably why there was text overlap issues) but mainly I have one issue.

I followed your docs, I installed unclutter, however.... Bookworm uses Wayland.
This is new to me, and so caused me some initial issues with setting up the static IP I wanted to use, VNC not working, and other issues.
I've stuck with Wayland so far and found my way around, but having a mouse cursor stuck in the centre of my PiClock is a bit frustrating ;) Do you have any ideas? Do I really need to go to raspi-config and change it back to X11? (My thought was simply that if Wayland is the future of Rasperry Pi OS, then I may as well get used to it)

After all this, getting the PiClock set up on a new Pi, in the newest OS... I'm hoping there's another way to disable the mouse pointer? Something similar to Unclutter?

My apologies for troubling you again, but if you have any tips, I'd gladly hear them.

Thanks.

EDIT: OK, I didn't think I'd noticed the mouse cursor earlier, during testing. if I run bash startup.sh -n from my SSH terminal, the mouse cursor does disappear. If I run it from autostart (trying wayfire.ini) then the mouse cursor remains! At least I can get rid of it by launching from bash. EDIT2: Confirmed. Just uncommented out the autostart in wayfire.ini, [autostart] 1 = bash $HOME/PiClock/startup.sh -n

and doing it this way causes the mouse pointer to remain.
launching it direct from the terminal causes the pointer to disappear.
At least there's a workaround. I like to use a startup script as it's easy to comment out when tinkering. I'll try crontab next time, and also try the PiClock.desktop autostart method and see if that works on Bookworm/Wayland

EDIT3: Tried crontab -e and added "@reboot bash /home/pi/PiClock/startup.sh" Didn't work, at all. the Pi remains on its desktop after a reboot. I also edited it to try with -n, but no sign of PiClock after a reboot. Just in case it would help, I've also added chmod+x to startup.sh. After a reboot it still doesn't start.

EDIT4: I commented out the command in crontab. I then tried the other method, creating the autostart folder in ~/.config, and adding the link to PiClock.desktop. This method DID autostart PiClock, but once again the mouse cursor is stuck on the screen.

[SerBrynden]

@Vindictor I was able to install unclutter on Bookworm. I don't know what Wayland is.

As for VNC, I just use raspi-config to set that up.

[SerBrynden]

@Vindictor I also use the Autostart Method 1, which has never failed me:

cd PiClock
chmod +x PiClock.desktop
ln PiClock.desktop ~/Desktop
mkdir ~/.config/autostart
ln PiClock.desktop ~/.config/autostart

[maserowik]

That how I got mine to auto start 

Sent from the all new AOL app for iOS

On Sunday, November 12, 2023, 5:49 PM, Brendan Curley @.***> wrote:

@Vindictor I also use the Autostart Method 1, which has never failed me: cd PiClock chmod +x PiClock.desktop ln PiClock.desktop ~/Desktop mkdir ~/.config/autostart ln PiClock.desktop ~/.config/autostart

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[Vindictor]

Hi there folks, thanks for the responses. Just to be clear, these are issues with the new Wayland. It's probably easier to do an internet search to find out exactly what Wayland is, but the headline is "Wayland is a protocol that applications use to communicate with a display server (which, in the Wayland world, is also the compositor). It is in the process of (very) gradually replacing the X11 protocol"

Previously Raspbian / Raspberry Pi OS would use something called X11, for Bookworm there seem to be many changes in the OS, from how networks are managed (I found this out when setting a static IP) and of course, Wayland. If you install Bookworm fresh, on a Pi4 or above, it'll default to Wayland for graphics. This is not compatible with unclutter, and myriad other things. It's a big change.

While setting up yesterday I thought I'd try to stick with Wayland, as this is clearly the future.... however, having thought on it I'm having second thoughts. Thankfully it's possible to use raspi-config to change back to X11. If I do this then hopefully Unclutter will start working again!

As for the autostart.... yes, as I mentioned yesterday I tried the various methods. Wayfire.ini (which replaces the old ~/.config/lxsession/LXDE-pi/autostart way of doing it.

I tried crontab, which didn't work at all, and finally I tried the PiClock.desktop method of creating a link in .config.autostart.

Using wayfire.ini or the PiClock.desktop do autostart, but, with the mouse cursor stuck in the middle of the screen. So yes, autostart DID work, but unclutter did not.... however, for whatever reason, if I start PiClock manually from bash (via SSH) then the mouse cursor disappears during startup.

It's not only me with this issue. While trying to find a solution, internet searches found many people who build kiosk systems having the same issue, with Wayland. Unclutter doesn't work. The mouse cursor remains on the screen.

Bookworm is still quite new, thankfully (for now) X11 can be enabled instead of Wayland.... I guess for my PiClock I'll try that later in the week. Hopefully in due course updates will come (to things like unclutter) and they'll work with Wayland. If I spot an update to unclutter during an apt upgrade, I'll try Wayland again.

I had no idea there were so many changes in Bookworm, which make years of documentation and discussion about Raspberry Pi OS obsolete. I haven't, yet, tried setting up a samba server on this Pi. I hope that's not too different. Setting up my static IP and network settings was an all new experience! Previously it was a few lines in a config file. Thankfully, in one post in one forum, I discovered nmtui (must be run as sudo) which can be used to configure network settings in bookworm, using its new networkmanger. I realise this is off topic, but maybe it can help someone else starting with Bookworm.

Hopefully more updates will follow soon and make Wayland better supported. PiClock itself works fine in bookworm, it's simply the mouse cursor that's the issue, when running from an autostart. I currently have PiClock running in a "screen" which I have to manually start via SSH each time I boot it up. in the next days I'll try to switch to X11 via Raspi-Config (after backing up my SD card!) and see if that fixes my issues.

Out of interest I just tried to run Unclutter manually on this Pi with Bookworm/Wayland. Nothing happens. No error, but the mouse cursor also remains.

Also my VNC does now appear to be working, (I didn't change anything, maybe it was updated during an apt-upgrade) and so I started PiClock via the desktop link to PiClock.desktop. The mouse pointer remained on the screen after startup, however... I was able to (with VNC) move the mouse cursor to the side of the screen to make it less visible ;)

Thanks again for the replies. PiClock IS working, autostart also works... it's just the mouse cursor issue is a little frustrating.

PS, people who've been using Wayland for years already have been having the same issue. I see a few ideas to fix it, such as here, mentioning "sway" and a tool someone mentions called hideaway. https://github.com/swaywm/sway/issues/1471

Sway post about hiding the cursor https://github.com/swaywm/sway/pull/1979

[SerBrynden]

Ah, it must not be an issue on Pi3 boards, which I'm still using for PiClock. I save my Pi4 for heavier projects.

[Vindictor]

@SerBrynden Exactly. I was using a Pi3 for PiClock until yesterday. I just decided that if I was going to start again I'd use a Pi4, and take advantage of the extra power / USB3 / gigabit and plug in a large drive as an extra NAS.

I've been doing more googling. Yes, VNC was broken in Wayland until very recently. All tips were to make sure the user is using X instead of Wayland. I also won't hold my breath about Unclutter being updated any time soon!

https://wiki.archlinux.org/title/unclutter

Well, for now, Raspberry Pi OS allows both X and Wayland. While I expect support for X to be dropped in future releases (which is why I initially decided to stick with it) at least they offer the option to drop back to it. I was mostly happy with my old Stretch install on my Pi3, just for PiClock, until the https issue reared its head a few days ago. I guess I can fall back to X on this Pi4 PiClock and just leave it for the foreseeable future. By the time I need to upgrade from Bookworm, in a few years, hopefully Wayland issues will be solved. It's a real can of worms, searching for issues with Wayland. I do have another Pi4 here running Bookworm, but it was upgraded from Bullseye, rather than a fresh install, so I didn't notice so much had changed. Just errors when doing apt-get updates/upgrades that I had to workaround.... IIRC, something to do with the URLs being untrusted doing it the "old way"

I still haven't got VNC working from a Mac I have here (which I was using yesterday) but here on my Windows workstation I can connect OK. Doesn't matter. SSH is my preferred method.

Honestly, I can't believe in 2023 that the only issue I'm having is a damn mouse cursor which won't hide itself after some inactivity! ;)

In a few days I'll backup my SD card and either try sway, from above, or go back to X and see if that fixes my issues. It should do..... for now... until we're forced to use Wayland..... or.... I'll just install Bookworm on my old PiClock Pi3 and go back to using that. I'll post back if it works, in case it helps anyone else.

Thanks.

EDIT: If you fancy some fun, try an internet search for "unclutter wayland" or similar! ;p

[Vindictor]

I've just tried a cheeky little hack that I found during searching.

Basically renaming the file of the default mouse cursor (in this case to .bak) and rebooting. Now there's no mouse cursor! I rebooted and have a desktop with no cursor on it!

sudo mv /usr/share/icons/PiXflat/cursors/left_ptr /usr/share/icons/PiXflat/cursors/left_ptr.bak

Great, now I'll add PiClock back to autostart and that should fix that little issue. If a proper fix comes along, I can rename the .bak back to "left_ptr" and it will be restored.

So, just linked PiClock.desktop to ~/.config/autostart and the Pi is rebooting.... I don't believe it! When the PiClock starts in this manner, by default, it has a 15 second delay. Inside this box, a long "text cursor" appears. Then when PiClock starts, it restores a mouse cursor! I guess this is a different mouse cursor to that which I renamed to ,bak. It does look to be a little bigger. Further tinkering required. Gah, I thought I had it. I only seem to have cursor issues when auto starting PiClock! (EDIT: I did copy PiClock.desktop to the autostart folder, instead of making a link, and then edited this file to startup with -n instead of a delay.... but a cursor still appeared over the "starting PiClock" box. Never mind.

EDIT: Hmmm, then I took the more drastic step of renaming the entire cursors directory to cursors.bak. Nope, I still have a mouse cursor in the centre of my (auto started) PiClock. Never mind. I HAVE to stop for now. I'll put things back, restart and manually launch PiClock via SSH.

[Vindictor]

Ouch, just looked up and spotted my PiClock crashed, and the Pi was sitting on the desktop.

A quick peek in the log (with identifiable info changed to x) shows

[2023-11-13 13:57:32.264602+00:00] getting METAR current conditions: https://tgftp.nws.noaa.gov/data/o> [2023-11-13 13:57:32.273678+00:00] getting OpenWeather forecast: https://api.openweathermap.org/data/2> [2023-11-13 13:57:33.369750+00:00] wxmetar: xxxx 131320Z 25020KT 8000 FEW010 14/11 Q1002 7000 -SHRA FE> [2023-11-13 13:57:33.378684+00:00] Traceback (most recent call last): [2023-11-13 13:57:33.383355+00:00] File "/home/xxx/PiClock/Clock/PyQtPiClock.py", line 1229, in wxfini> [2023-11-13 13:57:33.387479+00:00] f = Metar.Metar(wxstr) [2023-11-13 13:57:33.391791+00:00] ^^^^^^^^^^^^^^^^^^ [2023-11-13 13:57:33.396709+00:00] File "/home/xxx/PiClock/venv/lib/python3.11/site-packages/metar/Met> [2023-11-13 13:57:33.401664+00:00] raise ParserError("Unparsed groups in body: "+code) [2023-11-13 13:57:33.406436+00:00] metar.Metar.ParserError: Unparsed groups in body: -SHRA FEW SCT018

Never mind, I’ll restart it for now.

Also, regarding METAR I’d previously mentioned that the METAR code was never displayed on my PiClock, despite the info coming from METAR. I believe I discovered why. Some time ago I’d manually entered the METAR = ‘XXXX’ underneath the coordinates in the settings file…. And hadn’t realised that further down there’s a blank METAR = ‘ ‘ line. And so I commented that out when I made this new bookworm install, leaving my manual entry near the top, and the METAR code is displayed.

EDIT: Damn, restarting PiClock causes an immediate crash. The PiClock loads, and then immediately returns to desktop. It was running fine until about 10 mins ago. Rebooted Pi ,same thing. Again, I’m running it from SSH using bash startup.sh -n Now, after a reboot, I get this

[2023-11-13 14:10:45.832973+00:00] libpng warning: iCCP: known incorrect sRGB profile [2023-11-13 14:10:45.844102+00:00] libpng warning: iCCP: known incorrect sRGB profile [2023-11-13 14:10:45.848045+00:00] libpng warning: iCCP: known incorrect sRGB profile [2023-11-13 14:10:45.852159+00:00] map base url for radar1: http://maps.googleapis.com/maps/api/static> [2023-11-13 14:10:45.857809+00:00] map base url for radar2: http://maps.googleapis.com/maps/api/static> [2023-11-13 14:10:45.862206+00:00] map base url for radar3: http://maps.googleapis.com/maps/api/static> [2023-11-13 14:10:45.866465+00:00] map base url for radar4: http://maps.googleapis.com/maps/api/static> [2023-11-13 14:10:46.557465+00:00] libpng warning: iCCP: known incorrect sRGB profile [2023-11-13 14:10:49.288615+00:00] getting METAR current conditions: https://tgftp.nws.noaa.gov/data/o> [2023-11-13 14:10:49.375950+00:00] getting OpenWeather One Call: https://api.openweathermap.org/data/2> [2023-11-13 14:10:49.383114+00:00] wxstart for radar1 [2023-11-13 14:10:49.388682+00:00] wxstart for radar2 [2023-11-13 14:10:49.589778+00:00] ERROR from api.openweathermap.org: 401 - Invalid API key. Please se> [2023-11-13 14:10:49.601064+00:00] OpenWeather One Call failed... switching to Current Weather and For> [2023-11-13 14:10:49.608222+00:00] getting OpenWeather forecast: https://api.openweathermap.org/data/2> [2023-11-13 14:10:50.768728+00:00] wxmetar: XXXX 131350Z 24020KT 8000 HZ ///010 SCT030 13/11 Q1002 700> [2023-11-13 14:10:50.776772+00:00] Traceback (most recent call last): [2023-11-13 14:10:50.781172+00:00] File "/home/xxx/PiClock/Clock/PyQtPiClock.py", line 1229, in wxfini> [2023-11-13 14:10:50.785586+00:00] f = Metar.Metar(wxstr) [2023-11-13 14:10:50.790273+00:00] ^^^^^^^^^^^^^^^^^^ [2023-11-13 14:10:50.795000+00:00] File "/home/xxx/PiClock/venv/lib/python3.11/site-packages/metar/Met> [2023-11-13 14:10:50.799547+00:00] raise ParserError("Unparsed groups in body: "+code) [2023-11-13 14:10:50.805463+00:00] metar.Metar.ParserError: Unparsed groups in body: -SHRA FEW SCT018

I do see the API key error. odd, it’s been working fine.
Also see the METAR errors. Also odd, previously when METAR data was unavailable it would simply be blank on the PiClock screen ,never cause a crash to desktop.

EDIT: OK, for now I’ve edited the config file and commented out the METAR config.
PiClock has now started and the weather info is complete, from OWM. No API key issue! I’m a bit concerned that (so it appears) when the METAR info is unavailable for some reason, PiClock seems to crash. But I need to stop now. Running very late from all the PiClock playing, and I’m actually typing all this (and running SSH to the PiClock) from my iPad! Cheers.

[Vindictor]

I left METAR disabled for the rest of the day, yesterday, after the numerous crashes on startup. This morning I reenabled it (uncommented it from Config.py) and PiClock started up as usual. I'll keep an eye on that.... as I said above, previously when METAR data was unavailable I'd just see a blank area where the current weather should be, but yesterday PiClock plain crashed out. But this morning, all is well.

[SerBrynden]

PiClock can't catch all possible (user) errors. If you want METAR weather, and you put a valid station code in the correct spot in the Config file, all should work fine. If you're still experiencing problems after that, then let's start over from there.

[Vindictor]

@SerBrynden Sure. It was working fine, up until the point I mentioned that PiClock crashed to the desktop, at approx 2pm yesterday afternoon.
I tried, repeatedly, to restart PiClock, but a split second after starting it would crash to desktop again. After noting the metar parser error in the log, I commented out metar, and it launched without issue. I left it for the rest of the day, and then today when I booted up the Pi, I reenabled metar, and it's been running fine ever since.
I'm not sure what the user error is here? It was working before, and it's working now.
It's just that, on my previous PiClock install, I noticed that just now and then, the metar info would be (seemingly) unavailable. This would manifest by the current weather being blank. If I left it then later it would update and work again.
I was simply guessing that, perhaps, yesterday this new PiClock install was crashing due to a lack of metar data, or maybe PiClock was receiving some kind of malformed/unexpected data from metar. Again, it was working before, on my test Pi400 and the new Pi4 install up until yesterday at 2pm (UK) when it seemed to randomly crash to desktop, and wouldn't start again until I commented out the metar command. It had been showing the correct metar code on screen, and is again today. As of this morning, I simply uncommented the metar command and started PiClock, there've been no further issues. If I notice again, at some point in the future, that the PiClock starts crashing to desktop again, I'll assume that it's due to the way it's dealing with unexpected metar data (or a lack of data/response altogether) and will start a new thread at that time.

Thanks.

[SerBrynden]

Glad to hear it's working. Recommend closing this issue.

[Vindictor]

I just wish to post one final comment.

Firstly, thanks to those who helped! Greatly appreciated.

Secondly, I just pulled my Pi4 out and made a backup of the SD card first (just in case)

I then launched raspi-config (with sudo) and under the advanced options I changed from Wayland to the older X11. The Pi rebooted. I now see some recognisable old directoties in ~/.config, such as lxpanel and lxterminal.

I then made a copy of PiClock.desktop in ~/.config/autostart and simply edited out the 15 second delay with -n

rebooted the Pi and..... success. Now that the Pi is using X11 again, unclutter works, the mouse pointer is hidden, and everything seems to work.

I just wanted to let anyone know, who comes across this thread and who maybe tries PiClock on Bookworm (or newer) which uses Wayland (on a Pi4 or newer) that so long as the option to go back to X11 exists, the pesky mouse pointer can still be hidden on autostart, with unclutter.

For how long Raspberry Pi OS will support X11 is anyone's guess. But for now, X11 is an option. With all the older Pi's still in circulation, hopefully X11 will be supported for years to come.

Thanks @SerBrynden thanks @n0bel and also to @feh123. Enjoy your clocks! :) Vin.

[feh123]

Thanks @Vindictor I have just updated to Bookworm (on a +3B RPi) and everything looks good. I too would like to thank @SerBrynden and @n0bel for PiClock!