You were right - Join Accept frequency was wrong.
Good news - problem solved. It all came down to the firmware in the device (LPS8 gateway) not being correct. Edwin at Dragino sent me a link to a new firmware and bingo - problem solved 
.
Many thanks to everyone for your comments and encouragement.
For future reference, the following is okay now too. So, apparently, this is also affected by status packets or uplinks sent from the gateway to TTN?
https://www.thethingsnetwork.org/gateway-data/gateway/eui-a840411eb93c4150, which showed "frequency_plan": "AS_920_923" earlier, returns "frequency_plan": "AU_915_928" now:
{
"eui-a840411eb93c4150": {
"id": "eui-a840411eb93c4150",
"description": "LPS8",
"country_code": "au",
"attributes": {
"antenna_model": "915",
"brand": "Dragino",
"frequency_plan": "AU_915_928",
"model": "LPS8",
"placement": "indoor"
}
}
}
Note that the above is also lacking the location now (and owner details). Same goes for https://www.thethingsnetwork.org/u/sgrobler Did you set those details to be private? (If you made changes, then maybe that actually updated the details on the other network components, rather than the new gateway firmware?)
For ttnctl gateways status, when invoked from Europe, I still see Last seen: 2020-09-29 14:14:39 and Frequency Plan: EU_863_870 like earlier. But maybe that’s caused by my settings for the CLI, which somehow prefer the EU router? For future readers it may still be nice to see what the result is when invoked by a Meshed user.
For ttnctl gateways info, which already showed Frequency Plan: AU_915_928 earlier too, the location and owner have gone missing too.
Yes I did set those to private. I am fairly convinced it was the firmware that resolved the problem because I had previously deleted the gateway in ttn and re-created it, and it still didn’t work.
What is the significance/etiquette for setting details private/public?
My project is a one-off hobby project.
…but your gateway could help build the network even when that project is done! 
Any TTN device can use any TTN gateway, regardless if its location is known. (Devices just transmit, gateways just forward, so the only requirement is a matching frequency plan.) If the location is public then it’s easier for people to debug, or to guess if there is coverage. And if the owner is public then one can even contact the owner in case of problems. That surely helps build the network, but: up to you.
Any chance you can show us a packet as sent with the new firmware? I doubt the details of the above uplink will make TTN use a different frequency plan. Maybe the contents of status messages differ though. Also, I hope that using a different endpoint to sent those messages to, does not affect anything.
I’ve reset it to public, but its off at the moment, while I get some sensors together.
I’ll post a packet when I get back on line 
Nice.
Ah, bummer. If you’re not running it 24/7 then it’s actually much better to not make its location pubic: others will surely expect gateways to be online day and night.
Even more, even when the location is not public, devices that use ADR may be instructed by the TTN network server to limit their transmission power or to switch to a better data rate, if your gateway had best reception for a series of packets. So, switching it off may already affect devices in your neighbourhood that suddenly see packet loss as the network has changed.
What are you trying to achieve by connecting it to the TTN community network but not running it 24/7?
Giving it some more thought, maybe even then it’s better to have the location public: at least people may then sometimes see it as offline on, e.g., thethingsnetwork.org/map and ttnmapper.org instead of just having to guess what happened? Not sure what’s best here.
(Of course, the above is moot when trying to run gateways 24/7 when using the TTN community. Please consider doing that!)
One might also legitimately ask what TTN is trying to achieve by having no way to distinguish between experiments and infrastructure.
Someone wanting to try out TTN realistically typically ends up needing to get a gateway, either because there isn’t good local coverage, or because they need the raw gateway view of what is going on to debug node issues.
And because we’ve told them they can’t use a single channel abomination, that has to be a real gateway.
But just buying a real gateway doesn’t mean it’s going in a roof top machine room with a nice antenna and 24/7 power.
More likely it’s sitting on a desk with a power cord stretch across the room to a free outlet and uplinked via a spare patch cable where the locking tab broke off the RJ45 three years ago.
Maybe it’s time that gateway registration (or better yet, the backhaul protocols themselves) gained some flag bits.
Don’t count on me
Don’t use my RSSI in the ADR algorithm (or at least, not unless the node is also registered to this account)
I’ll probably drop downlink transmit requests, so chose any other gateway first
I can only receive this channel/SF…
Expecting particular hardware be used is already a tall order; expecting that once plugged in for any purpose it stays powered and backhauled 24/7 is… a bit much.
But yes, that is currently the implicit ask.
Nice idea to have those options in TTN Console! But then please disable the “Save” button and link to the Manifesto (and downloads of private stacks) until all have been unchecked. 
No.
The whole point is to allow those newly interested to experiment and learn by participating at the edge of TTN, and to usefully contribute uplink’s of other node’s traffic to it to the degree to which they are able, without the network being negatively impacted by the degree to which they are unable
It’s the “all or nothing” mindset you are promoting which isn’t actually workable for anyone but the most established users who can support hardware in real, permanent installations.
Otherwise, might as well just tell everyone unable to commit to being an infrastructure service provider from day one to get lost and try chirpstack instead.
For the 4 example options that you’ve given, which I feel are mostly human choices which are easily avoided when getting to know the basics before connecting something*, I very much disagree.
But yes, one cannot expect the community network (or any network) to provide constant non-changing coverage.
*) If we would make it easier to find that information, or maybe even “mandatory” to read it.
How can you try anything without connecting it?
Do you really want to steer people to using a server other than TTN, before trying TTN?
If you do that, a lot may never come back
Wheras a set of “this is an experiment” flags are something which can be easily un-checked, by people who’ve never needed to leave the fold in the first place.
Ah, the whole point of those flags? (I read that as of TTN. Silly me.)
Yes, very nice!
Wed Oct 7 13:33:25 2020 daemon.info lora_pkt_fwd[2610]: RXTX~ {"rxpk":[{"tmst":1872152540,"time":"2020-10-07T13:33:25.475624Z","chan":5,"rfch":1,"freq":917.800000,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","lsnr":10.0,"rssi":-30,"size":24,"data":"QHEQACaABAACvMVB5U/RCz+10APMynUM"}]}
Some differences - do they explain the problem I had before?
Thanks for the discussion about public vs private etc. When I get my kit finished it will be set up permanently, so I will make my gateway public so it helps build the network.
Thanks again to everyone for your interest and assistance!
I don’t see anything referring to a frequency plan. Maybe it’s in the status messages? Or a change in some URL that the new firmware uses? I just read/remembered that AU915 and AS923 have their own endpoints on Meshed as well:
And as for:
I just read:
Though the latter is about info (which already showed AU915 for me), not about status (which showed EU868), maybe that still explains things.
Meanwhile, that very same gateways status, when using my EU868 TTN account, is giving me no results at all:
ttnctl gateways status eui-a840411eb93c4150
INFO Discovering Router...
INFO Connecting with Router...
INFO Connected to Router
FATAL Could not get status of gateway.
GatewayID=eui-a840411eb93c4150
error=Gateway eui-a840411eb93c4150 not found
But gateways info still looks good.
Can we get a copy of the link from Dragino ?
Sure - here it is:
This is for the LT-22222-L firmware update ?
No - its for the LPS8 gateway. Don’t think I did anything on the LT2222
To be clear, this is a mistaken action.
It is not the gateway, but rather the network server, which commands the downlink frequency
The only way a gateway upgrade would have anything to do with this is that if doing so coincidentally result it the gateway being pointed at a different server, or being “considered anew” by TTN.
But it’s not a change in the gateway software that fixed the issue, because the issue was never in the gateway software to begin with.