Could you please publish a schedule when these brownouts will be conducted?
I am running some last field tests. After December 1st the project will be completed and migration to V3 is not planned. If you´d conduct those brownouts each Wednesday at a weekly schedule, that would be awesome for me, as it would not mess up my field tests.
Thank you!
I agree - a schedule for brownouts would be greatly appreciated. We are also trying to gather as much data as we can during these last weeks of a field study and would try to schedule work around the brownouts if possible. Travel to field locations involves considerable expense and a trip could be largely wasted if a brownout occurs during a visit. Cheers!
Leaving aside the constant reminders since the beginning of the year which makes planning a trial well after the original shut down date somewhat of a debatable decision, scheduling brown outs will only end up with people thinking it’s maintenance when they skim read the information.
You could turn on data storage and retrieve the data that’s missing from that source. You may have to beg or plead with TTI staff to do that for you. You may need to offer a barrel or two of beer.
Or automagically switch over to the ports that are available to transfer data during brownouts.
The 1st of December was always the date of the original shutdown. Prior deadlines were just for those who want to migrate to V3. On the other hand, one could ask why conduct brownouts if there have been constant reminders since the beginning of the year?
However, the situation is like it is. If TTN staff indeed wants to avoid publishing a schedule, maybe at least consider writing me and @PSU-EME-WAG a PM. I would be grateful.
A post was merged into an existing topic: Gateway status:“disconnected” after migration from V2 to V3
2 posts were merged into an existing topic: Gateway status:“disconnected” after migration from V2 to V3
It was originally read-only April and shutdown Sept but had to be extended. And this from the announcement at the top of the thread:
Whilst we weren’t told what the consequences of missing the 30th Sept deadline, it was a big hint that we shouldn’t expect much thereafter.
Because of the thousands of devices still on v2 about a month back. Plus 8,000+ gateways which have been auto-patched-migrated-a-thon by linking v2 gateway servers to Packet Broker so will still be around a bit longer - whilst the gateway servers remain standing - if they fall over, it’s game over.
I’ve plenty of code around so if you have Data Storage enabled on your v2 or you want a Python MQTT client that can reconnect I’m not totally unsympathetic. If you are running a web hook I’m not sure where that leaves things.
How difficult is it to retrieve from v2 Data Storage and dump into a spreadsheet? We still do everything in spreadsheets (modified the script that you provided elsewhere for a v3 webhook - thank you again!).
DS to tab delimited in Python - I’ll open another topic as this is getting specific
Thank you, Nick. Unfortunately, I am controlling some HVAC components in real-time via the LoRaWan sensors. I do not want to overemphasize this topic. I got fallback mechanisms, though it would just be nice to be prepared. If I will get this information, I´d be happy. If not, I will get along as well.
It’s unclear to me what will happen to our v2 gateways after december 1st.
We currently have ~20 gateways on v2, routing traffic from our v3 end devices to our TTI stack. But as these gateways are spread out over different countries it is difficult to access them for re-configuration.
Will they still keep forwarding to v3 through the packet broker after december 1st?
Yes, but this is a bonus with an indeterminate timescale for support - deeply unlikely to be a forever option - so don’t hang about with migration as soon as you reasonably can.
As @descartes already wrote, this is indeed temporary, so you will have to reconfigure your gateways.
If you need to physically access the gateways to do this, please take that opportunity to also set up secure remote access so that you reconfigure and upgrade your gateways in the future without having to visit them.
And your solution for those of us without the wifi code/claim code for remote TTIG’s to hand is…? 
!
Surely start point should be if I am the ‘owner’ (and sole collaborator) in V2 then there is no obvious reason why I should not continue to be the ‘owner/sole collaborator’ in V3!.. In otherwords if the migration is being done from the same account surely there should be no issue - perhaps a validation email to the address associated with the account to say something like ‘an attempt is being made to migrate “gateway name/gateway eui” from V2 to V3 do you accept this? click here link 1 to accept click here link 2 to reject, if no response seen within 24hrs the migration will be rejected’ or something similar?
Good plan - could knock up a one-shot database thing in a few hours - but not let you test …
When I finally migrated a Kerlink using the Semtech UDP protocol a week ago, basically all I did on that gateway was this from the documentation:
If you are using a Semtech UDP Packet Forwarder, change the
server_addressin yourglobal_conf.jsontoeu1.cloud.thethings.network
This used to refer to router.eu.thethings.network. I’m sure it has been considered, so what would break if somewhere after December 1st any remaining V2 gateway would just be migrated from V2 Console to V3 Console, and that old domain name would just become an alias for the new one?
This has come up earlier, but I don’t think it was answered:
There is an potential issue with certificates used by mqtts connected gateways. For UDP gateways there wouldn’t be issues.
Ah, I guess there is nothing like SNI for MQTT, or maybe not all clients support that if it exists? But then, that could be solved with an extra IP address, serving one certificate per IP address? As long as ports don’t change, I’d assume that would work, if wanted.
(Lacking a true community in Haarlem I was very much tempted not to bother migrating that specific gateway, thinking it would need a USB-triggered firmware upgrade. But I learned some beekeepers are using it, and in the end one of your posts convinced me it would/should be easy.)
The incident on our status page was just updated with new information. The first post in this topic has been updated accordingly.
The incident on our status page was just updated with new information. The first post in this topic has been updated accordingly.