I have a pi-based (PI-Supply RAK) gateway operating fine, and in it’s location it would be nice to monitor temperature and humidity and report it back to an application of mine. Naturally i feel like I should somehow be able to inject data from the gateway as if it were a node, rather than have to run a second device right next to it to TX to it.
I’ve seen some gateways with sensors built in, so I assume it’s perfectly possible- but what’s the best route to doing this?
It’s a real mess to inject anything in to the gateway as if it were a device.
But as, by definition it is on the internet, the work of moments for it to run some code that sends the data straight to your data store - thereby bypassing all the LoRaWAN infrastructure - so you still get to see it if LoRaWAN has a coffee break.
The intention would be to keep all of the infrastructure and data access the same, rather than split up routes for each type and make it un-necessarily complex. If I wanted to do it that way, I’d have skipped lorawan entirely and set up my own in-house solution; this way my systems all communicate through one route whether they’re at my house or 1km away. It’s merging of comms solutions that messes up most projects of mine 
Please search the forum, this question pops up every few months and gets answered every few months.
The short answer: can it be done, but not easily as you basically need to implement a node without RF front end on the RPi that interfaces with the packet forwarder. That ‘node’ needs to implement the full LoRaWAN stack including downlinks, MAC commands etc or it won’t work with TTN V3. You also need to modify the packet forwarder to recognize downlink traffic to that specific node and redirect it in stead of transmitting it.
Using another channel to transfer the data is a lot less work, a better solutions from architecture point of view, better chance of being future proof. Also less fun.
Thanks Jac, I had a quick search before posting but couldn’t seem to nail keywords to find anything useful - this could be a my failing with terminology. I’ll keep digging in the search and see if I can find the answers.
With hindsight, it might actually just be simpler to add payload to another one of my sensors elsewhere on the system, I’d just hoped to keep the rf bandwidth to an absolute minimum. Let’s see how I get on 
Presumably you want to receive the data that the devices are sending and not have them disappear in to the ether. So you’d end up with something like a HTTP/Webhook or an MQTT client or similar. In that respect, you get the code on the Pi to talk to the very same entry point on your application. All your data ends up in the exact same place. You are going to have to write code / create something to do the monitoring, making something that talks to your end point is going to be substantially easier than writing something that can fake being a device.
If you do go for the canary option with a radio on it, bear in mind you don’t want it too close to the gateway because you run the risk of overloading the input stage of the gateway with variable results.
A canary is the best option overall as long as you monitor it for uplinks being routed via your gateway - if each uplink has your gateway id in it as part of the meta data then you know your gateway is working. If something else breaks, you can look at where the data stops flowing which is very useful, as opposed to just having a gateway monitor.
If going this route, consider using a 50 ohm resistor to ground instead of an antenna.
@JamesBuckle Hi James, quick change of threads…also you can dial down the tx power to just enough for the GW to pick up + some safety headroom, where ever its placed. Suggest adding say 6-8db over threshold where you start to regularly loose packets to allow for local environmental variables. That way if your GW goes RF ‘deaf’, e.g. through a nearby lightning strike (not unusual in the hiller ground where you are north of Glasgow! 
), but remains operational you will still get warning as messages will stop (have seen GW’s limp on but with Rx sensitivity down some 20-60dB on RX signal level), and you won’t have to worry so much about scrapping and analysing the actual RX power level.
Cheers all, some great points there - I’ll go away and think about the best route forward!