To be clear: it is user configurable per device using their Toolbox app, but Rejoin Mode is enabled by default.
From the manual (https://resource.milesight-iot.com/milesight/document/am103&am103l-user-guide-en.pdf):
“Go to Device > Settings > LoRaWAN Settings of ToolBox App to configure join type, App EUI, AppKey and other information. You can also keep all settings by default.”
Ok , thanks for clarifying - panic over! 
That additional info makes a huge difference. Its not unlike the original RS1xx family from Laird - their default protocol needed an initial time synch and forced confirmed uplinks - not TTN (or Spectrum) friendly, then they quickly adopted and adapted to allow for unconfirmed options etc.It’s now a user selection over BT during set up…
As with the Laird unit guess we need to highlight to AM103 users that they should not just blindly accept defaults
1 Like
@Ichthus_College_Info Hi Steven,
I have the Milesight AM103 in place also on TTN. Normally a Milesight sensor can be password protected for NFC.
Nice to see that Airteq (Dutch company) is selling these as stand alone and not connected to a lorawan network. If you would, you can have a lot of historical data. And based on that, school can take proper actions.
But, Ichtus college is in Veenendaal. I live in Venray. Maybe get in touch? you can have the data enter nicely via TTN in a dashboard that is developed and maintained by your ICT students themselves. I can’t do this myself and use Datacake for this.
So. feel free to email me at < redacted >. I’m happy to help
Marc
PS,
I have given guest lessons at various schools about Lorawan and at ROC in Venray they have started Lorawan themselves
Hi Marc, thanks for your reply!
Luckily, I have some LoRaWAN / TTN experience already thanks to my WIP project www.meetjeleefomgeving.nl which is launching officially 31st of May with two updates planned still (and a slightly outdated website).
I will soon be hooking up all 90 AM103s to TTN and still need somewhat of a dashboard for housekeeping to monitor ventilation etc. Could be done by students as well indeed!
If need be, I’ll know where to find you, thanks 
Hi Steven,
perfect. Lorawan is than an easy way to deploy wireless sensors in a school building. 1 or 2 gateways and of you go.
One question: did you buy CO2 sensors because of the Dutch regulations for CO2 in schools?
Marc
Yes we did! And it coincided with research towards ventilation in our school.
meten = weten inderdaad
for our EN friends… but that doesn’t sounds so nice
measuring is knowing
1 Like
@MarcVanBracht, forum policy is to post in English - you can add the same content again in any language that the moderators can translate if you wish. Please edit your post accordingly and given the frequency that Google indexes this site, do not include your email address - send it via private message.
done. sorry for this inconvenius
1 Like
Updated the CO2 sensor a little over 24 hours ago such that it doesn’t send anymore LinkCheckReq uplinks.
Number of downlinks is still a little on the high side…
@descartes does this align with your observations wrt no. of uplinks? I could leave a console running for a couple of hours again.
Or is this behaviour decent for an ADR enabled device?
Seems a bit much - but about what I normally get - a few uplinks, then a couple of downlinks saying they are to set Rx1, then all quiet for a few more hours, rinse, repeat.
As the test device I started on Monday dropped straight down to DR5 power level 2 within the first few minutes and wasn’t moved, I can’t see why it would need further downlinks.
I’ll trawl through the JSON console captures this evening to see if I can learn more.
I’ll leave a fresh console open for a couple of hours to see if I can catch one or more downlinks. Will let you know if there’s anything apart from ADR stuff.
This device is only two floors and a couple meters separated from the antenna, meaning that it also immediately took a dive down to DR5.
There shouldn’t be any ADR stuff - if it’s not moved and given the close proximity of device & antenna and it’s been set, I’m hard pressed to understand why there should be more downlinks.
Perhaps @Jeff-UK or @kersing who are gateway masters could comment …
Gateways are not an active component in the ADR stuff. A node and the LNS are. Gateways are just dumb media convertors (to quote someone) 
1 Like
YOU, Mr Jac Kersing, are THE Gateway Master - it was an honorific, not a reference to the gateway’s involvement, although just for clarity, why is it that LoRa doesn’t log in to the gateway - it works so well for WiFi.
What I was wondering was if you had any observations on why the LNS should repeatedly send Rx1 settings that may or may not have some ADR bits attached when the device is clearly on a good signal.
Although how I type this, it may be trying to get the power output down further and if the device can’t and/or doesn’t understand the power level, it’s not ack’ing the request and carrys on transmitting. Which would may hold true for the Speed LoRa-E5 as the cheap-skates only wired in the HP output.
Whilst we are talking about power, why can’t I get 10km in an urban environment?
Because it doesn’t work well for resource constrained devices (gateways in this case) if the are thousands of nodes in its vicinity. Because of this WiFi AP can only handle a small number of devices. A LoRaWAN gateway thousands.
That would be an excellent example of a reason. Decoding the downlinks could show what’s happening.
Because there are to many absorbers around. Including the kind walking around ingesting alcoholic beverages.
My console is running for seven hours now and I seem to find some interesting behaviour.
It looks like about every four hours (extrapolating based on total number of uplinks now), the LNS sends an ADR request to the AM103. The AM103 responds on the next uplink with an ADR accept. But then on the next uplink 10 mins later, the LNS once again decides to send an ADR request, to which the AM103 properly responds on the next uplink again with an ADR accept. After which the LNS shuts up and the process repeats about four hours later.
Console is still buffering so I can share whatever details you are looking for - I should also have the gateway logs from the ADR-duo that’s happening right now again, but it’s too crowded that the first one four hours ago has gotten pushed off.
As Tesco (the supermarket) says, every little helps!
Is it possible that LNS sends ADR-commands to the nodes to reduce their TX-power?