As far as I know, there is a limit of 10 downlinks per day.
I would like to build a kind of climate control using a fan controlled by the an application using TTN. Is there any way to control a relais by TTN but having more than 10 downlinks per day?
Would a private gateway be a solution?
Your answers would be much appreciated.
Not using TTN, not with a private gateway either. And keep in mind you are only able to downlink when there is an uplink using class A. When TTN moves the community network to class C at least the downlink timing can be resolved.
For now the only viable solution would be your own gateway with your own backend.
So at the moment TTN is mainly a tool for collecting and analysing data but not for controlling something because of the limited number of downlinks per day, I’m right?
Mostly - you can have the local device control to an algorithm - which should be doable for HVAC - and downlink occasionally to change parameters.
Correct.
And whilst there is a fair access limit with TTN of 10 downlinks per day, if a Gateway (TTN or other) were to attempt to exceed that by much, for a large number of nodes, the Gateway can hit legal duty cycle limits as a transmitter.
Likely limits will still apply due to reason explained by Stuart @LoRaTracker. These are community resources and too many downloads not only risk pushing to limit under duty cycle limits your download effectively renders the gw deaf to everyone else’s nodes (gw simplex operation - can’t tx and rx at same same), which is why the FUP download policy exists in 1st place.
Actually, class C makes things worse from a duty cycle perspective, since it has fixed air settings. Traditionally much slower air settings, though TTN EU cranks it up a bit.
What class C changes is that the nodes do not have to poll for downlink by sending an uplink, because a downlink can instead be sent at any time. Class C reduces how busy the network is in the uplink direction, since uplinks only need to be sent when there’s actually something to report.
However, class C only works with nodes which can run their receiver continuously, which basically means mains powered nodes. If you have mains power, there are a fair number of other schemes beyond LoRaWAN which could be usable and may make more sense.
Many thanks for all the explanations!
I have to think about my project…!
This could be interesting - if someone wants to use Class C in an area on a relatively proactive basis, they may suddenly find that gateway owners have a rethink - hopefully there will be controls at gateway level so our original uplink remit can be honoured.
Currently nodes can receive the same amount of downlinks, class C just alleviates the need to poll for downlinks, that means your gateway should have less traffic. So no need for additional controls.
This is a model I have used for experimentation. A list or matrix of possible relay behavior or a simple algorithm locally on the device. The environment can inform the selection of the template from the matrix or may decide some variable to seed the algorithm, externally generated for example irrigation in respect of current measured soil/weather data.
In this case the automation is local within the device including processing etc, only the single intermittent down-link (which would be staged on the TTN server) is sent to inform the strategy. In my testing I waited for an expected uplink with status info and replied within the rx window.
The node device organised it’s own strategy including power management and sleep in accordance to a plan so preparing downlinks is just scheduling.
If you need to react to something frequent and local to the end device I believe you are best to avoid using LoRaWAN to connect the sensor to the device, wired or (depending on the situation, power etc) some other direct connection would be best. Something frequently occurring but remotely is a different challenge IMO.