i’m new, so i don’t how to start to do this (link) or which tools of TTN i need to control a siren automatically
TTN isn’t really very suited to controlling things, because currently TTN only operates as LoRaWAN Class-A.
This means that the only way a downlink can be sent to a node, is in direct response one or two seconds after the node sends an uplink message.
In effect, this means TTN fits use cases of measurement which might very infrequently want to send an “adjustment” back to the node, but with no particular time urgency to do so.
That doesn’t sound like the usual use case for a “Siren” at all.
Likely you should use another scheme to control your device, either a class C LoRaWAN network, or something entirely other sort of radio. But be aware that sending asynchronous downlinks tends to require a mains powered node which can keep its radio on all the time to receive unexpected messages.
3 Likes
but if i need to control a siren for an ews for floods and i have a time around 2:30 hours to send the message and active the siren,
Is it important that you have a high level of reassurance that the flood early warning siren actually does go active when wanted ?
1 Like
Given your image, see also Monitoring weather, waterlogging and drainage conditions with flood warning in Rio de Janeiro, and its links.
1 Like
Hi @oscarillo, with 2 hrs 30mins to activate the siren I think that LoRaWAN is perfectly suitable for an application like this.
However I think that your diagram is missing a server behind TTN. If you are going to activate an emergency siren in a public place then you need very solid logic and reliability.
For integration I think that you could use MQTT and your own server in the cloud.
Please also consider:
- A serious activity like activating a public emergency siren should not be done using a single message or a single sensor.
- You should use multiple sensors in case one develops a fault.
- You should send uplink messages something like once every 15 minutes.
- You should store all received uplink messages in a database.
- You should run a process on the server to scan the recent uplink messages in the database something like once every 5 minutes and carefully log all decisions taken in the logic and any errors encountered.
- You should check and calibrate all the sensors at installation time.
- You should periodically re-calibrate the sensors, e.g. once every month to begin with and then once every 3 months.
- To begin with you should NOT automatically trigger the siren. You should send a txt message to a human who then has 2hrs to manually trigger the siren. You should only move to fully automated operation once you are very confident that the system is working reliably.
- The siren should only operate for a fixed time, e.g. 2 minutes, in case there is a fault.
- You should think of all ways that the system can fail and how the system will react.
1 Like
Regardless of how LoRaWAN in concept might be force-fit to this, it should be noted that TTN is not suitable for safety applications, but only for “nice to know” ones.
There’s absolutely no guarantee that the network infrastructure will be available when needed.
That is not just theoretical, there are actual outages which have occurred for a wide variety of reasons.
If I were actually going to build something as described, it would probably take the form of a hybrid system where the sirens were either always receiving or kept periodic downlink windows based on regularly resynchronized clocks. And then critically, it would depart from LoRaWAN in that the gateways would have the authority to interpret uplink traffic, and autonomously turn that into a downlink if they did not get a response from the central server within a certain amount of time. Thought would also have to go into de-conflicting the opportunities for autonomous dowlink from each of the multiple gateways with overlapping coverage of the area.
Essentially it’s a case where you have to think “well what if this part fails” for every part of the system, and then think up a way to handle that.
1 Like
I hinted at this earlier.
Something like a early warning siren for flooding, where potentially lives are at stake, really needs to be run on a system where there is a reasonable re-assurance that the infrastructure used will be regularly maintained and fixed promptly when it breaks down.
TTN is really only avaialble under ‘best endevours’, if the TTI guys are busy eleswhere, TTN wont get fixed.
By all means use TTN in the first instance but there needs to be a robust alternative way of activation in place.
2 Likes