There is a problem with 2 end devices (class C).
There are 2 electric power meters on which the power supply/cut-off relay can be controlled.
At simultaneous sending of commands (with difference of 1-2 seconds) to both electric energy counters, one of the counters receives and executes the command, and to the second counter the command does not reach.
Both commands come to the base station, it is visible when I connect the terminal to it.
What could be the problem? In general, can LoRaWAN technology be used to send commands to, for example, 20 or more such devices?
Thank you in advance for your answer. I 'm sorry if the question was stupid.
The community network does not support class C so you are using a private TTI instance?
Gateways are subject to the same airtime regulations as nodes because the use the same frequencies. So a gateway may not be allowed to transmit at that point in time.
In general lorawan is not the best technology for downlinks. If you downlink infrequently (once a day or so) lorawan can be used. If you need frequent downlinks (every few minutes) you should look at another technology.
That means you are using class A and as a result you are only able to downlink when an uplink is sent. For a timely response you will need to send regular uplinks which might conflict with the TTN fair access policy which allows only 30 seconds airtime a day.
That depends. Where are your devices on the world (which regional lorawan settings and what other regulations apply)? How often do your devices uplink?
Electric power counter has external power supply and performs electric energy counting. It is a Class C device, it can be polled, data on consumption, active power, tariff diversity (electric energy cost), etc. can be obtained, power supply (electric power cost) can be remotely switched on/off, etc.
The devices are located in the Russian Federation. The frequency range is RU868.
By default, the device sends power consumption information every 2 hours. However, you can configure this setting from 10 minutes to 24 hours.
Other parameters and remote power on/off can be queried by certain commands that are sent to devices.
That all makes perfect sense for your application - if and only if used on a compatible network.
The public TTN network does not currently support class C
Class C would indeed be the best way to use your devices, but to do that you’ll need a different network. And this forum is really only about the TTN network. Forums tied to various solutions you could use for the server infrastructure role for a private network may give you some guidance on setting up class C, for example Chirpstack’s forum.
I haven’t looked into it in detail, but I suspect that as class C doesn’t have any particular time constraint on the downlink, if requests are queued which would seemingly collide in time then the server software will simply push out the transmit directives to the gateways one after another with any delay required by local regulation in between. Things get far simpler when a node is mains powered and can keep its receiver on in the way class C is designed. But all of that is beyond the scope of this particular forum.
Worth noting: class C is also closer to the case of having a utility company truck drive around and query meters. I wouldn’t normally think of that as being a LoRaWAN (vs other protocol on top of LoRa radios) application but at least if you have a sense of which nodes would be in range you could probably poll them. Or build something that was a superset of LoRaWAN and could either operate with fixed gateways, or with mobile meter-reading vans.