Today during some routine housekeeping I restarted my Rpi-RAK831 gateway which has been my V2 workhorse for some years. It is a balena docker application which has been super reliable but now can’t obtain configuration from TTN servers?
Last week I configured a new “Fleet” and a new Gateway for V3 use with Basicstation but once tested this was shut down and put away.
I have not changed any configration and the device was working right up to the restart. This is the error I am getting in the balena console.
main *** Resin Machine Info:
main *** Type: None
main *** Arch: None
main *******************
main *** Configuration:
main *******************
main *******************
main *** Fetching config from TTN account server
main *******************
main Unable to fetch configuration from TTN. Are your GW_ID and GW_KEY correct?
Service exited 'main sha256:3f83c1b0b9323198806a58e5032bd5d11ecf5b9324b7a18f7a3ccbd37b077..
I have checked in the device configuration panel and the gateway credentials look perfect?
That might be due to an expired intermediate certificate. It might be the right time to move over to V3? There is an updated Balena setup (essentially new python script) at ttn-resin-gateway-rpi-1 if you decide to move to V3.
Thanks Jac for the reply. Actually I have a TTIG registered on the V3 stack and I have a new gateway using Basicstation ready to install once I am on the roof again. This is also registered with the TTI V3 stack. The gateway that won’t restart is collecting packets from end devices I have not yet migrated and leaves me now with no V2 gateway.
That all said, from the brief survey I did yesterday, it appears that the V3 gateway is routing packets from at least one V2 end device which I didn’t think happened?
Packet broker acts as a bidirectional router taking traffic for either V2 or V3 GW’s to either V2 or V3 applications so you should be covered for now until V2 falls over (may not get fixed as of Oct 1), or sunsets…
Thanks @Jeff-UK . I was under the impression that V2 gateways would route V3 device packets to the new platform using packet broker but not the other way around. Curious that when I built a V3 gateway to replace the one I mention above that is acting up, it didn’t seem to carry any V2 device packets where the TTIG does? No science or logs to prove this but as the TTIG is doing local end nodes for the moment all is well…
The Gateways are transparent and have no way of knowing if a packet received over the air is V2 or V3 - decisions are taken in PB and NS. Your comment about unidirectional handling was correct in early days of transition but the reverse (V3 to V2) was added later as this was becoming a block to people migrating GW’s as people wanted to avoid orphaning V2 devices whilst other community users were slower to change etc.
Good luck with the transition - if you get evidence of documented missed traffic capture details and bring back to the forum for discussion/review…
Thanks again @Jeff-UK. That is a very concise summary of what I believed was the case but what is in fact the case; my V3 registered gateways avoiding orphaned V2 end devices.
Balena is so handy for maintenance, I may try to push a new application to the gateway up on the roof per Jac’s suggestion. Even if nothing works I have a working TTIG and a fallback gateway ready to go into the box. That would be the one I asked around about the antenna connector, RAK2245 with u.fl etc.
until V2 falls over (may not get fixed as of Oct 1), or sunsets…