Apologies if this issue is covered somewhere else but I couldn’t find the same issue posted.
I am new to LoRaWAN and have probably done something stupid in my end device setup on TTI.
My gateway appears to be functioning correctly and I have an end device that I can read from via an MQTT integration (uplink data). However, I cannot send messages to the device.
When I click on the end device from the console “end devices” tab the device appears to be greyed out and the following message is shown:
" This end device is registered on a different cluster (au1.cloud.thethings.industries ). To access this device, use the Console of the cluster that this end device was registered on."
I’m not sure why I have this error as this is the cluster that I am using. I thought that deleting and reinstalling the device might help but I can’t see how I would do that.
My end device is eui-a84041fb51873a6d.
Any ideas will be greatly appreciated.
Thanks for the tip. That sounds like just the sort of thing that would explain my difficulties. My knowledge is still pretty limited so I’m not always sure what good looks like.
I have just tried logging out and in again, making sure that I selected the “au1” cluster.
The dashboard seems to show me connected to the au1 cluster by the URL as well as the connection status icon.
The gateway has an “au1” address i.e. xxxx.au1.cloud.thethings.industries…
When I click on an uplink data entry under “Live Data” for the end device I see the following entries which match what I expect:
“cluster_id”: “au1”,
“cluster_address”: “au1.cloud.thethings.industries”,
“tenant_address”: “xxxx.au1.cloud.thethings.industries”
Where xxxx is my Tenant name (I changed it to xxxx here).
Could it be a problem that I named the end device with 2 words with a space between them? I assumed that the device would be referenced bu it’s EUI rather than its name.
The frequency plan is Australia FSB2. I believe that this is what TTN & TTI require. The image below shows the setting for the Gateway
Settings directly from the end device (via RS232 and AT commands) also appear to align:
End device current version and frequency band:
v1.6.0 AU915
Frequency Band (8 channels mode):
2
916.8 917.0 917.2 917.4 917.6 917.8 918.0 918.2
Thanks, I will look further into the documentation around naming. If the space in the name is a problem, I’m not sure how I will fix it as I don’t seem to be able to edit the devices configuration. I will cross that bridge when I come to it.
My application is non-commercial and on a tight budget, so I have not subscribed to support on TTI. I went straight to TTI as the up-time is claimed to be better than TTN. This is important for my application.
You can’t put a space in the device id and you should be able to edit a device name.
There are so many contradictions and other randomness in this I’m slightly flabbergasted. Would be so very interested to know where it is claimed that the up time is better.
I think the most important point to emphasis is that LoRaWAN is NOT suitable for mission critical messaging - not because of the infrastructure, but because of the shared spectrum and the consequential issues arising. The metric TTI work to for RF issues is 10% packet loss. If uptime is so important to your application that you feel the need to use a free Discovery instance that is designed for evaluating for a larger deployment, then you’ve picked the wrong technology because that’s not where it will come undone.
And if the application is important, don’t use technology you aren’t completely familiar with.
Here are a couple of links and extracts from them that gave me the impression that TTI might be better from an uptime perspective. Bear in mind that I did not have a good frame of reference as to whether TTN would be good enough.
The Things Industries
"Make the move from The Things Network to The Things Industries
Step up from The Things Network to the enterprise environment of The Things Industries. Feel comfort in the familiar interface and open source codebase for the Network Server. Be certain of high availability, 24/7 support and, explore the advanced features of The Things Stack.
Availability Guaranteed
The Things Stack routes over 600 LoRaWAN messages per second (50 Million messages per day) with a guaranteed uptime of >99.9%. Our servers are monitored 24/7. Redundancy is implemented on all the components of The Things Stack and failover servers are configured in case any issues occur."
Fair usage policy applies (not suitable for businesses)
May experience occasional downtimes with no high availability"
Probably TTN is very adequate to meet my needs but I wasn’t sure at the time.
My use is quite tolerant to loss of packets due to RF issues. There is an existing system that will act as a fall back, with the penalty of some user involvement, if LoRaWAN can’t deliver. The up-time that is valuable is the up-time of the cloud-based services that will also assist in informing whether the backup system needs to kick-in. When it is working reasonably well the LoRaWAN subsystem will reduce the user workload.
Because I already have a backup system I can tolerate some problems while I am learning. Learning more about LoRaWAN is a key objective here. Clearly I still have plenty to learn.
Nothing you’ve quoted says that TTN is any less that TTI. The up time of TTN is pretty much identical to TTI instances, after all, they share the same clusters, but if (very very occasionally when) an issue arises, we get fixed second, or more likely (see below) third.
And if you are really concerned about the availability for your application, as before, LoRaWAN may not be the right fit and if it is and you want the reassurance, perhaps funding it would be the smart move. If I was fixing a foobar or glitch or disconnect or whatever, I’d look to the Discovery instances after I’d sorted out the paying customers.
Principally that TTN is paid for by TTI so we do our best to keep those costs down - using a Discovery instance with no intention of paying is just pushing the boundaries on “keeping the costs down”. Hoping then for free support without being part of the TTN community,
The other big learning is that asking before doing is actively encouraged. So if asked about uptime, we’d say it’s pretty damn good, in fact the price performance ratio is off the chart.
