Can I emulate a thing/device from a TCP/IP connected node

End Devices (Nodes) Hardware
1

Say I’ve got to kit out a factory with an existing network of devices, and adding new lora devices for things that move around and are outside the building. Obviously, I’ll be adding my own gateway for the factory, but I’ll make it a community node.

Here is my dilemma. I would like to standardise the backend between all the nodes. But some are ethernet and some are Lora. Adding lora to all of the nodes with ethernet is only my very last resort here. I have access to the source code for all the nodes that have a mixture of .net and freertos running on them and am happy to upgrade them. The way I see it I have 3 choices.

My first preference would be to develop a c lib that let the nodes with ethernet connect to the things network as if they were lora devices. Complete with their own EUI, but I would need to register those or generate those somehow??? That would just be the greatest outcome of this, and I’m surprised no-one has done it. Some things are in houses and have wifi too, can’t they join TTN?

My second option is to use p2p on the lora devices, collecting all the data to a node with ethernet and push that data to the old backend system.

Last choice is to add lora to the existing devices. Sacrificing hardware costs to update the backend and cut down on software costs. I’d feel a bit wasteful doing it this way though.

2

Please don’t route traffic of non-LoRaWAN origin through TTN as if it came from fake nodes.

If you take some time to look at it, you’ll realize that the data volume (message size and frequency) you’re allowed to use with LoRaWAN and TTN in particular is miniscule; sooner or later someone’s going to demand you push more through your big wide Ethernet pipe than you can realistically pretend is coming from a node (or a day comes when the acceptable use guidenlines get actually enforced - on your fake nodes just as on real ones). And the backend systems are budgeted with the idea that the flow from any given gateway is in data processing terms, a trickle.

What you should do is write a mode in your code to extract out only the most critical, concise messages. And then if you want to, in a case where it has to run without Ethernet you could pass that to a LoRaWAN stack running on a distinct processor, keeping that functionality contained.

On the backend side you should have something that takes in data from your ordinary nodes, and from TTN for your TTN nodes, and re-combines them.

In essence, make a TTN interface a subsystem of your ordinary system; don’t try to make your ordinary system a subsystem of TTN.

It’s not clear though that you really have a LoRaWAN application, vs say a WiFi one, or a role for some custom mesh. Before anything else, take a hard look at the acceptable use traffic volumes.

2 Likes
3

Thanks for the reply, I get that the traffic requirements are really small. The nodes we were planning for temperature and humidity, plus 2 more fields on a 10minute cycle/ non critical. The ethernet has to be there still for the local traffic and in application programming though so i can’t get rid of it. I may not have understood your reply correctly. Are you saying that I should suck up the critical details I want from the network and send the critical ones through a lora node? That would push me right to the Fair Access Policy limits I think. The way i understand what i’ve read so far is that whiles nodes can mostly roam, depending on agreements between servers. Gateways are tied to specific servers though? does this mean a gateway goes down if it’s server goes down? Would i be able to ignore the fair use rules if the company added it’s on TTN v3 server that the gateway pointed to? Are there rate limits between servers when it comes to peering? I’m not trying to rip of the community here. I’m actually hoping that whatever the solution to this is it might grow and help it.

4

What exactly do you mean with “standardise the backend between all the nodes” and what would be the purpose to ‘standardise’ this?

“Ethernet” are those nodes wired to a LAN or using WiFi?

Only one single LoRaWAN gateway (think coverage and resilience)?

5

This is the actual answer - have your ethernet nodes talk directly to your data store / application and those nodes that have to / can only be on LoRaWAN move data via a gateway / Network server / App server to your data store.

Are you saying that I should suck up the critical details I want from the network and send the critical ones through a lora node?

If you already have a connection, why not use it to send the critical details through it - LoRa isn’t that special that it automagically handles critical messages and isn’t as fast as local ethernet. If they are that critical, why not send via your local network and if you don’t get an acknowledgement back (because someones unplugged the network for instance), send via LoRa as a fall back.

The way i understand what i’ve read so far is that whiles nodes can mostly roam, depending on agreements between servers. Gateways are tied to specific servers though?

More that nodes broadcast a message and ALL gateways that can hear it process it but only those gateways connected to your chosen backend infrastructure will result in a message arriving. Agreements between servers are rare but TTI can peer the community with your own setup. Peering between different companies isn’t a thing in this cut & thrust commercial dog-eat-dog world.

does this mean a gateway goes down if it’s server goes down?

Absolutely, the gateway is a box with an aerial and a network connection (ethernet, wifi, GSM/LTE, carrier pigeon) - you WILL have several of these. The serverS - note the capital - the network server that handles the messages from (& to) gateways and the application server should be on solid hardware being supported by people in white coats with pocket=protectors - this is what TTI do. You receive (send) messages from the application server and do as you wish with them.

If the servers are embedded in to the gateway which is available for a number of use cases - at which point your other gateways are using that master gateway, so if it goes offline, game over.

Would i be able to ignore the fair use rules if the company added it’s on TTN v3 server that the gateway pointed to?

Sort of, the fair use rules apply to TTN and you don’t add a TTN server but you can use the software. If you go to TTI so they run servers for your exclusive use, then you are unrestricted apart from the legal rules for your country regarding use of the airwaves. You do have the option of running your own servers on your own or rented hardware.

Are there rate limits between servers when it comes to peering?

Probably not if they are on ethernet but I’m not aware of that much peering going on.

6

At the moment, data from the sensors in the building is pushed out via a https post. via php it is then put into sql. The problem with this is that we can’t just send new modules for them to “join” or activate like the super sweet thing you guys have got going on. In fact, the fixed ip address and UID for the module must be baked into the firmware each time something is added. It’s pretty old and antiquated compared to these new-fangled devices that you can “activate” on a server.
Yes, we would probably use a couple of gateways at the factory. Coverage isn’t more important than the 1hectare factory grounds though. In fact if we have to run a private TTN server that’s fine too. Just thinking out loud if there is a bigger picture here to start getting in on. If we do a big LoRa job now, we probably take a loss this time. But it would be great to have the experience under our belts if projects keep going that way. If we managed to set up peering between our over worked TTN server onsite. The only traffic it might have to receive would be if we started tracking trucks offsite.
^ am I understanding all of this correct?
I’m dreaming of the day when we send a module out that has ethernet. Someone plugs it into the network, it gets a DHCP address, pings one of our TTN servers and we activate it on the spot. No more independent firmware files. If we do a job where the module roams, we can utilise TTN and minimise the traffic. But if we are in a local setting that requires more traffic. We can use our own TTN servers and send the required traffic. We would keep the part of our backend that deals with firmware updates etc, that we have working well already. But use the TTN stuff for monitoring systems. Just started playing with a TTN v3 server.

Thanks in advance for your help. I could be dreaming here.

7

Can you do a hardware revision to include an Id chip that has a unique device address in it?

Or if they have ‘proper’ ethernet/wifi hardware, use the MAC address?

If you are running servers they are NOT TTN - they are just LoRaWAN servers that run TTN open source software. I’m not aware of TTN allowing peering between TTN and independently owned servers. Unless you had a huge number of gateways the support issues would outweigh the benefits.

Depending on where in the world you are (where are you?), your tracking of trucks once they leave the site via TTN gateways will vary enormously - have you looked at the coverage for the areas you are interested in

8

https://techoverflow.net/2015/02/03/reading-the-stm32-unique-device-id-in-c/

Hmmmm, I could also use the the hardware chip id as well to create a UUID, and if i was running my own server onsite I wouldn’t have to worry about clashes either. Then if one day i do have to track away from the factory those devices could be added to TTN. It’s a shame i couldn’t just T into the TTN network and quote an install fee to grow out the network the required amount for the extra devices. I have a feeling from what i’ve read that TTI isn’t cheap. And it doesn’t make sense to use them if 99% of the traffic never leaves the building. Thinking about tracking away from the plant is premature though, more ten year thinking ahead.

Thanks for your thoughts, I’m learning a lot.

By the sounds of things i should just keep doing what I’m doing with ethernet devices, except improve it. Then run the LoRa stuff in parallel and pipe those results to our existing back end. I suppose i may have got carried away with how cool the joining system is for LoraWAN and imagined joining ethernet devices that way. Maybe it’s just a dream.

9

It’s not a great use case for a commercial application to run over TTN - it’s best efforts at the server end and gateways deployed by the community can come & go on a whim.

TTI publish pricing - 1,000 devices on self-support is €190/month for them to run the network server for you. Doesn’t seem that expensive. YOU have to provide the gateways.

I think you are over-reading the join systems for LoRaWAN - much of it is involved in the setup of encryption for over the air transmissions - either in advance (ABP) or on first join (OTAA). All of IoT or M2M needs a way of having unique node addresses but there are many many ways of achieving that - one job we installed blank nodes and just turned them on one at a time and the server told the node what it’s id was, it was stored in flash and thereafter all setup. Kept the other nodes in my bag to stop anyone turning on any other new ones at the same time.

As for securing the data on an internal network, if you need to there are plenty of libraries for encryption or use TLS (SSL).

10

This sounds like a mixup of two very different things.

First off, it looks like you need an auto-configuration scheme. A generic node gets plugged into Ethernet, reaches out to your server, provides some sort of hardware serial number (such as the Ethernet MAC it has to have anyway) and based on pre-assignment (or the tech or customer in the field scanning a QR code with their phone while running your deployment app) role customization information is pushed down to the node and it starts doing whatever it is supposed to do. (as an aside, if you want other interaction with a deployment app, include a BLE radio)

That’s vaguely like a capability in LoRaWAN, but it really has nothing to do with LoRaWAN or radio communication. You might be inspired by some of the functionality in designing your own, but it isn’t really a help for you and there are probably other things out there already for needs that are more closely similar to yours and probably better models.

The second possibility is if for some reason you don’t have Ethernet at all, or initially. There you might be able to use a radio solution. There you might be able to use radio instead of Ethernet. If that’s a permanent need, LoRaWAN running to some gateway(s) on site (perhaps backed by LTE if not a wired backhaul) could have a role. But if it’s a temporary setup need, you’re probably better off with something like WiFi or using a BLE radio to exchange information with a setup app running on someone’s phone, while that phone remains in contact with your backend servers.

FWIW if I had to design a generic embedded computer for a need such as yours I’d look at having an expansion bay for a connectivity option. If your host CPU can actually run an operating system (usually worthwhile if you are doing IP networking - router SoCs are common in IoT products) I might make the expansion bay USB-based, perhaps in the form factor of an mPCIE slot primarily offering USB, but maybe with the I2C management actually hooked up for a change, and with SPI and/or UART on alternate pins the way a lot of LoRa concentrator cards do. Then you could drop in an LTE modem, or some custom card with a LoRa node radio/MCU module (Murata, Microchip, maybe even RAK), or something Zigbee, or BLE, or whatever is interesting next week. You could also place pads to solder a USB-A socket to try off-the-shelf connectivity dongles. If you don’t have a full OS on the host, USB host is still possible though emphasis might shift to the other interface options first. Another fun thing you can do is have optionally populated components below the space where the mPCIe card could go.

11

Thanks for all of the help. I’m taking it all on board and appreciate the input.
I’ve got another idea, bear with me here. What if the lora devices were joined using the TTN network and the first downlink is used to configure them. Then they go about their factory chores using the p2p networking. Or more specifically a library similar to this https://github.com/nootropicdesign/lora-mesh. Then I don’t have to worry over bandwidth. I could still follow all of the transmit rules so as not to saturate the radio band. Then just have them connect to TTN every 12 hours to look for downlinks. I could have a bridging node with ethernet and lora to provide interoperability between the networks, and collect the data to our existing backend over http. Can anyone see any problems with this? is switching in the code between p2p and lorawan on the fly possible?

Ta

12

Yes, testing

is switching in the code between p2p and lorawan on the fly possible?

Yes but why …

A new device of any description connected by anything from TeraBit fibre to carrier pigeon starts up - it has to have an ID already if you want it auto configured. The other end sends back the configuration to use. This is a generic problem.

This can be done with P2P/Mesh without the TTN join / downlink wrinkle which is just adding a Taj Mahal on top of the Eiffel Tower as a design engineer I know would say. It would be quicker and simpler for the few lines of code on P2P/Mesh to setup a new device than integrating LoRaWAN & Mesh code to create a FrankenDevice.

If you don’t want them with an ID (as discussed above), then someone has to be present when it’s turned on to tell the server what/where that has come to life.

At some point a moderator will ask you to steer closer to TTN related matters.

2 Likes