Release 2022.08.1

Woohoo, and it’s not even christmas :smile::+1:

1 Like

I rebooted the one that was on 514 and now it’s boot looping again so I’ll let it keep rebooting I guess. I didn’t press update button just reboot in advanced page. It’s still showing up during its reboot as 514 in a devices listing but only if I catch it just before it reboots…it’s still not getting http ntp or normal ntp

Working OK, but uptime stuck at :01

No it’s not.

It is only updated every 10 minutes or so.
If you refresh the page in a few minutes you’ll notice.

1 Like

What is the treat?

1 Like

All good here. Thanks Harry.

Beta stays at build 0505, yes?

I have some that updated, some that won’t and some that are still broken. Heading to bed

Lounge is in a reboot loop, and I’m guessing that’s why the temps are thru the roof so I’m letting rest while I sleep. 2am here btw.

Finally after about 30 mins the 5th one has got the update prompt. Will try the 6the one when I power it up in the morning

looks like 2 units are jost hosed up so bad I need to reflash them. :man_facepalming: :tired_face:

The biggest issue is they are both displays so means complete disassebly. Im only going to sacrifice stand alone RPi from now on…but this should not be happening in stable systems updates.

I’ve created a rescue script that will disable the daily reboot.
Question is if it will have time enough to pull in the script before it reboots again :face_with_monocle:

So let me know how it goes…

1 Like

I reflashed the 2 offending setups… all good I hope… broke an SD card in the process tho sheet happens

Can you send me feedback from one of those units?
I’m interested to see how NTP is doing (during boot up).


NTP is working… takes a while but gets it…not https this time

edf9cba94c136c18 and the other 68c97f5eb30eee5e

both are wired and no wifi setup yet (doing that now) - edit Done

1 Like

I have four Raspberry PI4s running 2022.08.01. All still require in excess of 5 minutes to boot, likely due to time sync issues. But, when I attempt to send a report from the Advanced tab, RoPieee reports failure indicating a firewall or internet problem. Is there any guide summarizing how a firewall must be configured to permit RoPiee access to send reports to the internet? For example, am I expected to configure NAT entries in order to allow RoPieee access to the internet?
On other PI-based applications such as ezBeq, I’ve found it necessary to disable IP6 by editing the /etc/sysctl.conf file. But, I can’t ssh into RoPieee to try that.

On a related note, I have one Raspberry PI running the prior Stable release. No matter how long it remains active, it never indicates that an updated version is available. Again, could this be a firewall -related issue?

I dont’ believe the older 4017/44019 builds will every indicate there is an update, but I think it did say now and then there is a new release version that is available - ie the NG builds we are on now.

Most firewalls should have some rule that allows for internally initiated requests should be allowed out and the responses returned to the requesting device.

Maybe Harry can detail what ports should need to be opened for a Ropieee device to communicate with base, and any other services NTP etc.

FWIW mine just updated , yes it took a few minutes but nothing abnorml

It sounds your firewall is rather strict with outgoing traffic.
Anyways, to be able to send feedback you need ‘good old’ ftp access (port 20 and 21). In most firewalls this just means that you need to enable the ‘ftp service’ or something like that.

The 5 minutes boot time is rather strange: I pressume that your firewall also blocks NTP, but the fallback should take care of that.

Anyways, try to get me the feedback so I can have a look.

What do you mean with ‘prior stable’ release?


I am on beta 505 as well. Assuming this update does not apply to us.