First, don’t sweat the details above, main thing is we’ve only got one place to answer questions - but it was the weekend when we were off doing other things, sunny here, Sunday roast with bottle of Margaux on the patio!
Cross-check in this context was double extra check the EUI you have on the site / using at the command line, yours fails at my end as well, but feel free to check eui-de5ca70000000000.
But of more interest is the continued refusal of the website to show that your profiles has a gateway - particularly as the map on the TTN home page is showing your gateway. Something must have gone wrong with the setup, it may be simpler to add a new one and see if the console complains there is already one registered.
Yes, very much agreed. While gateway Traffic in TTN Console is troublesome, using, e.g., the MQTT API for the device’s data has been rock solid for me. You’ll then also see which gateway(s) received the data. You can test the MQTT setup by simulating an uplink in TTN Console.
@descartes Thank you for your reply. I realize now that I was most certainly too impatient. I should have followed your example and gone to the patio with a drink. My tastes are not as refined as yours are. My drink is more likely to be a Leinenkugel’s Summer Shandy this time of year. Now that we have that out of the way, I did test with your EUI and received positive confirmation that it is working. I was close to deleting my gateway from the TTN but stopped when the console warned me that I would never be able to register the EUI again. I wasn’t sure if EUI’s are generated or if they are hardware specific like a MAC address so I didn’t want to make matters worse if the EUI is specific to the hardware. I am currently using a Rasberry Pi 3 B+ as that is what came with the kit I ordered. I do have a 4 but thought the three was sufficient for the gateway. This is the image I used when I originally configured the Pi. RAK2245_based_on_Raspbian_OS_for_RPI3_V4.1.0_20191202.img I did verify the image on the sdcard before booting the pi to it. I could redo it and go through the registration again if you think that would be helpful. If so, should I delete my gateway first?
I am going to try this process to see if I can use the MQTT API for testing as you suggested. I will also work on getting the Feather node running and try the simulating uplink step you linked to. I did try sending an uplink as you suggested in your post but not sure what I am looking for in the data. Perhaps I need to go through the documentation for MQTT API first. I am going to work on that and will let you know how that goes. Again I appreciate all the help.
I am not sure I understand this question. I believe I need to test with the MQTT API to view this URL. I will post back once I get that going.
Here is a screenshot of the “dummy device” I created in an attempt to follow your second link on simulating an uplink.
No, somewhere in the gateway configuration there is a setting for the URL to which the gateway sends the received packets, and its status messages like the following:
According to your logs, the above does succeed. But: where is it sending it to?
The Pi3 is more than adequate (I’ve RAK Pi Zero gateways that work just fine).
It may be worth re-installing as the URL Arjan is referring to is the one the the gateway talks to TTN - it needs to match the one the console page.
However, as ever, I’ve learn’t a new URL to check things and it does look like there may be an EUI entry issue as the location report above reveals a different EUI from the one you quoted.
When I run gateway-config on my gateway and choose “Edit packet forwarder config”, it references the file located at /opt/ttn-gateway/packet_forwarder/lora_pkt_fwd/global_conf.json. When I view the contents of that file there is a section at the bottom that has a couple of URLs in it. That section is as follows.
Is that the referenced URL to which you are referring? The examples seemed to indicate that the URL is from a node configuration. I don’t have that set up yet.
This is bizarre. These are my coordinates, but not my EUI. Not sure how that happened.
{“eui-b827ebfffee6cbe6”:{“id”:“eui-b827ebfffee6cbe6”,“location”:{“latitude”:41.56465148925781,“longitude”:-90.51200103759766,“altitude”:206},“country_code”:“us”,“attributes”:{“brand”:“Raspberry Pi based”,“frequency_plan”:“US_902_928”},“last_seen”:“2020-07-20T14:52:32Z”}}
Hmmm, the one in your conf file returns no info on the gateway-data url but there is that other one in the database for your location. Clearly the server has had a ‘moment’.
I think we need to get @arjanvanb to page the back room wizards to de-borf the entries so you can try again with a clean slate.
Beware: we cannot be sure that eui-b827ebfffee6cbe6 is not someone else’s, especially as it’s clearly connected. But eui-b827ebfffeb39eb3 surely seems to be in some troubled state within TTN.
Did you restart the gateway recently? Does the 6cbe6 one go offline when you switch off yours? (Aside: its coordinates and altitude seem to be changing a bit over time, suggesting a GPS.)
Those GPS coordinates point to my house. That is one heck of a coincidence. I think I would know if someone was breaking into my house and setting up a TTN gateway. I will power mine down to see if that change is reflected in the console. Thank you!
Now I have the power - if you’ve got a cheat sheet on the URLs you use for diagnosis, it would save me trawling through previous posts to make sure I’ve got them all!
Whilst it fills me with a random range of uncomfortableness but given that the EUI is generated from the Pi’s MAC address so isn’t a “real” one and if you change Pi, it won’t change in the config, let’s try changing your EUI on the device to the one that TTN thinks you have.
Or, if you have the patience, re-install the whole gateway just in case you have multiple Pi’s and we have some re-generation of the EUI issue going on.
@descartes@arjanvanb I powered the device back on. Then I updated the global configuration and restarted the packet forwarder. I noticed the device started updating again. I then went to register a gateway with b827ebfffee6cbe6 as the EUI and this time it accepted it without issue. The gateway is now showing up in the console with EUI of b827ebfffee6cbe6 and it shows as connected. I also still have the old not connected gateway too. I figure I will just leave that one in case it somehow one day magically reverts to that value. I believe I do have both Ethernet and WiFi configured on that pi. I didn’t realize the EUI was based on the interface’s MAC address. I am betting that is how I got one EUI registered and another one that was actually working based on how traffic was routed. Thank you both for all of your help! I guess I am going to move on to configuring my node and learning how to use the MQTT API. Thank you again, it is much appreciated!
