I was wondering if there was a way to use a downlink message created by a python MQTT server to trigger my sensors. I am trying to have a downlink that will communicate with my arduino program, I want the program to wait for some sort of signal then run my sensors and use the result of the sensor to send an average distance to my TTN application. Is there anyway I could do that? Note that I have my application working and my gateway as well. I just want a method to implement the following. Thank you in advance!
For the vast majority of devices which are setup as Class A, a downlink is only received after an uplink. For Class C devices that listen all the time (at the cost of battery life) then yes, you can send a downlink when ever you like.
However we don’t do no stinking downlinks here at TTN. Or if we do, we keep them infrequent. The Fair Use Policy asks that you do less than 10 a day per device. We try to keep it to one a fortnight, if you must.
Can you tell us why you can’t have the device figure out that it’s a good time to send rather than tell it?
It’s for a project where I display the availability of the parking in certain region. I want the user to be able to trigger the sensor to update the status from the UI directly rather than me updating it frequently when no one is using it.
I was planning on having a python listener that would listen to any request coming from my UI. Then, I want to send a downlink to my device to run my sensors and then uplink the result back to ttn. From this, my python listener will update my UI.
If a parking sensor is doing its job it will be updating free/busy as and when that happens, with a periodic status update after any change of status after the event so that if 1st message lost or missed status have good chance of being updated within a reasonable time - say 5 or 15 mins later depending on how ‘busy’ a parking area may be. The device may vary the update rate dependig on time of day/location based on how busy an area may be at various times of the day etc. A device watchdog may also give a 1/2x per day device update - so application know still working, battery level etc. It is then down to the end application to maintain the status database and the potential parking client then ‘interogates’ the database to find free spaces…there should be absolutely no need for a user to trigger a status request of all the end devices in the area to find free/busy data…that would be a potantial nightmare wrt RF airtime use and management - especially in a busy area (and remember ‘area’ could be huge given LoRa and potential similar devices nearby or in areas surrounding. Imagine the impact in say (Heathrow?!) airport car park(s). I think you are coming at this from the wrong end of the telescope. (IMHO). Note parking has been a much discussed toic on the forum for many years - search is your friend… )
Update - I see Johan indicated broadly same as I was typing my reply. Note there is no need for parking to become a Class C implementation - Class A for longer battery life and the win!
Yeah, just have the sensor batch together updates, sending when they reach a threshold of time (something like 10 minutes) or number of cars in or out.
LoRaWAN isn’t really great for polling from our end, it’s a bad design because it involves downlinks. Downlinks are bad.
As others have indicated above, there are better backend designs as well. You may want to consider that you have some modules you know & understand and you are trying to make them do the job even if they are not suitable.
Thank you so much for your detailed explanation, I will for sure change my implementation and will update my status periodically w.r.t. the fair use policy!
)