For my Project One, I want to use a stock-standard sensor at my workplace in a nearby town, connecting to an existing gateway (within 2km says TTN map).
But before that, for my Project Zero, I want to read an existing installed sensor (any location any value, but ideally stock-standard), something already connected and operating correctly. This step is purely to establish my ability to read a sensor on TTN, which will minimise the unknowns when I move on to Project One.
Any suggestions? I’ve rummaged in TTN forums without spotting a public test sensor.
but for a few bucks you can build one yourself, you’ve made it to register this TTN account, if you’re lucky that gateway that you’ve spotted will receive your node’s data.
just search this board for building instructions.
Yep thanks, and relax: if necessary I’m okay jumping straight to Project One (my sensor on existing gateway) using instructions like those.
However, ideally I’d precede that with an existing sensor. That way, if I later cannot see data from my own sensor, then I’d be confident it’s a problem with my sensor itself - not the gateway or in my TTN account somehow.
Call me a zany optimist, but I’m hoping there might be a public sensor out there somewhere, maybe exposed by a device manufacturer or retailer. I could imagine it being handy to demonstrate the usefulness of a device, or maybe serving as a diagnostic test. Fingers stay crossed.
Nodes (which may have sensors or actuators or nothing like it at all) are coupled to an application which is part of an account. You can not add a node to an application without making it inaccessible for other applications. When adding a node to an application all traffic for that node will only be routed to that application (and the node needs to have keys matching that application). So there is no way to provide a public node without providing public access to an application.
Providing public access to an application can’t be done without making an account public because there is no way to grant access to an application all users.
Even if an account would be shared (which would open it to abuse as anyone could modify the device information, rending it useless) it would not validate your Project Zero as it would not use your account.
Second assumption where you make a mistake: if there would be a public node somewhere, it would be highly unlikely that node would be using the gateway you would be using and even if so, it would not be at your location so that location might still not be in reception range of the gateway. (In urban environments with lots of building 2km can be quite a distance)
So basically your Project zero is a non starter. Skip it and get some hardware yourself.
You might want to read up on LoRaWAN technology. Nodes do not connect to a gateway, nodes connect to a network. A node transmits (broadcasts) its data and any gateway within reception range will receive the data and forward it to the back-end of the provider that gateway ‘serves’. If that provider has the magic keys (the encryption keys used to validate the packet is received correctly) it will make the data available to the end user. (The method for making it available depends on the provider)
Wow - thanks so much for your long thoughtful answer. I’ll continue waiting for my hardware (ordered awhile ago) instead of wasting effort on an impossible and pointless Project Zero,
I really appreciate the time you spent and the detail you included for a TTN novice. Thank you.
Thanks again: more useful detail. I’ve done some IoT reading, but the material I’ve found has mostly been pitched at folk using their own Arduino or Raspberry Pi hardware - which is not where I’m headed. I’ll keep looking, thank you. Much appreciated.
While both Arduino and the Raspberry Pi have some potentially severe unique issues, they are in general the well-known off-the-shelf approximations to the types of systems that are appropriate for the roles where they are used, ie:
A node should be built around a small flash-based MCU with a simple event scheduler or small RTOS
A gateway should be a stand alone embedded board typically running a full operating system but not trying to do anything but run gateway-related tasks.
More minimal gateway compute solutions are possible but add a lot of challenge, and so far with the the few on the market, that has resulted in issues of inflexibility.
As for your original question, it would have been possible for the TTN server software to be designed with a way to share decrypted node application feeds in a “read only” manner but it was not built with that feature. One could probably make their own MQTT relay or similar to share select private nodes. There are likely installation projects that use TTN which share the data in some other way on their own website.
Now understood, with help from yourself and others (thank you).
I’m aiming to use off-shelf nodes - like sensors for door open, water level, movement detection - and after determining that they work with TTN existing network, then look to add my own gateway and more complex nodes.
Eventually if I end on Arduino etc, that’s okay - but I mostly want to be a TTN user, not a developer.
This is unlikely to work out well in practice; you might be able to use pre-made hardware but you’ll likely end up wanting node software (ie, firmware) that can be tuned to need by someone responsive to requests. Ideally, open source software you can commission anyone to change for you. There just too much “how it should work” that is still being explored in light of contradictory tradeoffs or otherwise depends on exact need.
“Work with” in the meaningful sense means being able to get your hands on them and see how they behave in real-world conditions. Otherwise you might as well just read someone’s forum post of their experiences with something, which would be more informative than just seeing the data feed.
Things are probably not at a point where one can really be a “user” unsupported by a developer, unless your application is an exact duplicate of something someone else is already working on for TTN.
MyDevices (cayenne) has several solutions that are ready to deploy. If cayenne is a match for the requirements there are plenty of of the shelf nodes compatible with it.
