This is my first time doing anything that’s LoraWAN related. I’m not an IT or electronics engg. so please bear with me if I come across as being snobbish or naive.
So I recently purchased a Dragino LT-22222-L Controller and a Seeed SenseCap M2 Gateway hoping I could get them to work with one another. My friend suggested it ‘might’ be possible and so I decided to give it a go. I actually wanted Sensecap relays but they weren’t available where I am.
I have absolutely no clue what to do next. My eventual goal is to be able to turn on/off my Dragino relay via my remote MQTT broker [that I use with Home Assistant].
So here are my questions:
a. Can I send downlinks to/receive uplinks from my Dragino relay via the Sensecap M2 gateway using TTN/Things Stack? If yes, how?
b. Can I integrate TTN/Things Stack with my MQTT broker to do the same? If yes again, how?
I’m not insisting on a step-by-step walkthrough (even though that’d be awesome) but if you could point me in the right direction, I’d greatly appreciate it.
So if I register my sensecap m2 gateway on TTN [following instructions in the link you provided], and then if I add my Dragino relay on TTN applications like so, uplinks from the Relay will directly show up on my TTN portal? Also Dragino’s relay documentation suggests the same in section 3.2.2
Once you have data coming into the TTN console App/Device view you just need to use Integrations to add your MQTT connection.
System reasonably easy to set up and operate if you follow the instructions carefully and pay attention to details. Have done several of them over the years and have one of the larger capacity LT-32222 units running in near touching distance here (monitoring a solar powered GW test rig) that has run happily almost continuously for >4.5 years now (LW1.0.2) on TTS/TTN V3.
Man gets free service that costs sponsoring company 10,000’s a year to run, taken aback without having any context, so here’s the details to fill in the awareness:
Free servers in three locations around the world for free - there has to be limits on both uplinks & downlinks or the free service would collapse.
Some of the best IoT documentation to get started with
Gateways are deaf to all uplinks whilst transmitting
Devices & gateways have a legal limit on air time - too many downlinks from one gateway and it can’t send anymore for a while which messes up other peoples plans - you own the gateway but if it’s on TTN it is a shared resource in return for the aforementioned free servers they/you use.
If you need to send many downlinks, then you can either run your own server(s) or pay or a TTI instance - which would restrict you to legal limits.
LW is NOT suitable for command & control - a device has to be autonomous in the event that a message up or down doesn’t get through. If it’s not safety critical and the device has some modicum of sense - like it shuts off water once a tank is full - then LW has potential.
Due to the deaf gateway / duty cycle, downlinks are a sort of fortnightly thing to confirm to the device it’s still being heard and perhaps to update settings.
LW was designed asymmetric for low power long range sensors to get data back to base - hence a gateway having 8 channels for listening.
LW operates in a shared part of the license free spectrum - keeping transmissions down from long range radios that can be heard for miles/km is being a good neighbour.
With the website you put in your profile, maybe having a chat with @rish1 would be a good idea - TTN is for learning & community applications - by migrating to a paid for service you will neatly side step the downlink restrictions.
I apologize, I didn’t mean to condescend in any way. 10 downlinks/day or fewer is still handy - plenty of possible use cases that I can think of (like the water tank example). I wasn’t aware of TTI services - thanks for sharing. I’ll look into it.
TTN does have great educative literature. I did spend quite a bit of time learning from there about LoraWAN - device classes, duty cycles, etc. - excellent material.
Not really - it’s a detail thing where you need to evaluate what data really needs reporting and how often, with multiple trigger detection/mitigation, frequency of status updates, etc. Also more of an uplink driven application than one constrained by limited downlinks. Classic examples of occupancy mentioned over the years and ones where I have seen/been involved include parking spaces, canteen/cafe queing times/management, toilet occupancy/waiting time/queue management/cleaning rota adaptation, Covid limited room/hall occupancy management., etc.
The uplink aspect of these can be helped with judicious use of multiple GW’s to ensure most/all sensors are able to operate (perhaps under ADR control) with shortest possible SF/airtime. (One of the reasons why the original low cost Indoor GW’s - precursors to e.g. TTIG’s - were conceived was to assist network ‘build out’ vs ‘build in’; rather than rely on remote GW’s 100’s/1000’s m away trying to penetrate into buildings to provide coverage - inevitably leading to higher SF’s and longer on air time/lower sensor density, deploy many more low cost GW’s in building/on lot to provide the required coverage. Such applications are often as much about planning the GW coverage & efficacy as about what sensors to use and how configured Test on TTN then deploy with TTI/TTS…
This is exactly what I ended up doing on a tricky site. My initial setup consisted of an internal gateway trying to cover a whole site. I had a lot of areas with no coverage, bought a Tektelic Kona Enterprise gateway, tested it in three seperate external locations across the site, still had some locations with unreliable uplinks (and a lot of devices running SF10-12, I’m using TTI for this).
I ended up fitting 7 * Browan Femto Lite gateways< I could probably have got away with 5 or 6, but for the cost per unit I appreciate the additional redundancy it gives me.
