How to post data to TTN via TCP/IP

1

Yes, I know TTN is primarily a LoRa network using gateways to receive and forward LoRa packets. However, those gateways are connected to the WiFi or Ethernet as a transport mechanism to the network. What if I had an node which was WiFi enabled (ESP32), how could I cut out the middleman and forward the packet directly to TTN.

Can somebody please point me to a tutorial which explains how this can be achieved? I have searched to no avail. I have a node collecting temperature, humidity and atmospheric pressure and sending it to ThingSpeak by using a GET command and would like to adapt it to send it to TTN instead.

Thanks for your input, Steve.

2

This kind of use case/question comes up regularly (use forum search) and is discouraged - why burden the TTN infra unneccessarily? Ih that case TTN itself is just ‘another middle man’ - push the data over the internet connection directly to ThingSpeak or what ever your dashboard/integration solution is… dont attempt to mimick a LoRaWAN ‘node’ delivery… because you cant.

3

LoRa is not LoRaWAN

Because ???

Or put less bluntly, you will have to mimic the entire of the LoRaWAN MAC stack in all of it’s 70+ pages detail - join, encryption, frame counters, handling MAC requests etc. Many have thought of this, we never hear back from them.

Also, if you do want to use TCP/IP, you’ll have to write your own copy of BasicStation as well.

And if Jac were here, he’d point out that the gateway is not the middle-man because all a gateway does is listen on some radio frequencies and if they noise is right, pass on the what it hears. The middle-man is the Network & Application server.

5

STOP RIGHT THERE.

Single channel packet forwards are ABSOLUTELY PROHIBITED ON TTN as they are functionally a denial of service attack on ADR.

Even if you don’t have a radio at all, the fact remains that this is NOT how TTN is intended to be used.

Feed your non-LoRaWan data to your ultimate data backend by another path; don’t spoof the shared TTN network’s infrastructure

  • Be kind to your fellow community members. << don’t abuse the network
  • Does your reply improve the conversation? << don’t abuse the network
  • Constructive criticism is welcome, but criticize ideas, not people. << don’t abuse the network

There’s a proper way to accomplish your goal, and that’s to feed your data to its ultimate destination by a parallel path around TTN, not an abusive path through it.

Even if you ignore the community aspect entirely and look at only self-interest, there’s no sane reason to make a fully private data flow have TTN’s public infrastructure as a point of failure in the middle.

1 Like
7
  1. My post made it clear I was intending using the code ONLY as a means of getting TCP/IP data to TTN, not as a single channel gateway and was intending obeying fair use policy, not spamming TTN with everything my fat pipe broadband could throw at it.
  2. Take it up with the guys who wrote the code for a single channel gateway, not me
  3. Please explain in layman’s terms HOW this is a DOS attack, who to? the other seven people who might have transmitted simultaneously if I had an 8 channel gateway.

If you want to encourage people not to do a thing, you really need to explain why its bad in terms they understand.

I thought TTN stood for the THINGS network, not the LORA THINGS AND ONLY LORA THINGS OR ELSE network.

As to “Because ???” because ThingSpeak is only a 12 month term then you have to set up all over again.

8

Wrong assumption and we all know ‘what thought did’ to borrow a phrase. Perhaps start with looking at the very 1st page of information wrt The Things Network - the Home page: https://www.thethingsnetwork.org/

Where the introductory headline declares:

We are a global collaborative Internet of Things ecosystem that creates networks, devices and solutions using LoRaWANÂŽ

Note “creates networks, devices and solutions using LoRaWAN(r)” - not even LoRa only, (or TCP/IP injection).

If you wish to use the network, and contribute to the Community, then you are welcome to do so - please just use and follow the rules provided to ensure fair use and interop for all…

This work was undertaken in the very early days of LoRaWAN development & deployments, going back to LoRaWAN 1.0 and even pre-release versions, indeed to before the LoRa-Alliance was formally introduced to the market, and long before 1.01,1.02,1.03, 1.04, 1.1 etc. when full GW’s were Very expensive ($thousands!) and more importantly long before the impact on other legitimate full LoRaWAN (Min 8 channel support) users was recognised, diagnosed, and more fully understood. SC implementations were deprecated long before even I started using TTN, several years ago, and have been repeatidly covered and discussed on the Forum since. The Internet rightly hates sensorship and so it is not possible to remove instructions to implement these, especially instructions suggesting how to connect them to TTN, which are often repeated and cloned, nor would one want to as they can have a role, if behaviour well understood and accepted, in small scale private instantiations however they are damaging if used in the Community network.

Indeed and often linked in to the academic year and academic licences for MatLab, etc…

The ‘Integrations & Dashboards’ market is quite wide, with many players and offerings, and very competative, so recommend you take this issue up with Thingspeak or look to use one of their competitors, and dont use their limitations as a reason to impose improper use on the Community.

Re (3) To understand why this is an issue please put the time in to research and read the discussions and historic explainations available through Forum Search.

9

Seems to be some contradictions here which doesn’t engender warm fuzzies with the volunteers on here who could potentially find a solution.

Right now this topic is still unlisted and I’ve not seen anything to inspire making it public again.

However the three people other than you who can see it do have some level of competence - in fact a bit of a perfect combo - Jeff on Gateways, CS on the MAC and me on integrations.

I have gateways that do all sorts of extras but without messing about with getting packets encrypted and injected in to the stack.

I’m not sure which bit of Things Speak that requires you to set it up all over again but as Jeff says, there are other ways - including setting up a Linode for $5/month that runs Node-RED, InfluxDB and Grafana.

Or proxy the data via a webhook which also takes a feed from your IP based device and then relays it on - which is exactly what I do but without the relay. So I can have multiple devices on all sorts of connections that all present at the end point seamlessly.