I was using a button (milesight WS101) to start an action remotely. A gateway was installed in a distance requiring SF12 to get a connection. All worked fine giving me a battery status at about every 24 hours. Then anybody installed a gateway nearby and I could observe running the messages through this gateway using SF9 for a week. But now I don’t get any messages. Is it possible that someone experimenting with TTN takes the messages of the button without transfering them to the network and could the button be faked to believe it could transfer it?
Short answer no. Both payload message and the network message wrapper for LoRaWAN are encrypted and only you or the servers where device registered have the keys to decrypt. Most likely if you were at a distance and device had adapted to linking with highest SF (SF12), the presense of a new gw somewhat nearer would have allowed the device to adjust its settings downwards under ADR to optimise and improve operating life. This would result in the SF9 you have seen. Problem then is if that intermediate GW is turned off or no longer contactable for some reason the device will still run at SF9 until such time as it recognises it no longer has a valid link (firmware dependent) and would gradually ratchet up the SF back to SF12 and then re-establish a link. There are many reasons why that may fail however…
How long since last successful message? Do you know (Manual/Documentation?) how the node is expected to behave?
I don’t know, whether the new gateway is still on, I have no idea who installed it.
The button was configured to stay at SF12 and not to use ADR and at least testing here with 2m distance to a dragino gateway it ran with SF12 consistently. I’m not sure whether the SF9 in the log raises from the device using SF9 or perhaps the gateway answering with SF9. The last successful message was four days ago.
I’ll contact milesight with the problem because it may indeed be a firmware problem if it did ADR in one direction (down) but not up again. I wanted to make sure that my expectations regarding faking a connection are correct, before doing that.
The LoRaWAN Alliance requires network operators to restrict the habitual use of SF 11 & 12.
Good practise is to use ADR.
And it clearly didn’t stay at SF12 if you saw uplinks at SF9.
If you can get the gateway id from the SF9 tx’s, then you can find out more info - and maybe able to contact the owner.
If the Milesight firmware has link check implemented, no reason for it not to, then it will eventually figure out that it’s not connected to the network.
Two main observations:
People turning gateways on & off randomly are anti-social but somewhat to be expected on a community network.
A non-sensor device like a push button needs to do link checks more often and send status updates regularly. But fundamentally they aren’t a good idea for a network like LoRaWAN. A sensor device uplinking every hour may end up offline for 2 or 3 days in this sort of situation, but should recover. Unless the user presses the button once every minute for an hour, it is unlikely the device will link check very soon. But as we don’t know where in the link check cycle it is, it could come back in a minute or it could be weeks.
Almost certainly simpler to get the device reset so it rejoins.
Bonus observation - never good to have a device right at the edge of connectivity …
I’ll now go and add uplink check count to my housekeeping payload so I know when my devices are going to check again to help with decision making for when a device goes quiet.
@schnbeck May be a bit obvious Martin but also check if your own/original GW still online! What is your and the intermediate GW EUI and or GW-ID (you can see the 3rd Party GW details in any Rx metadata as above)
it’s clear that fixed SF12 is not a good idea at general, but I wasn’t able to connect to at least one gateway without it. So the chance to get at more than two or three is very small.
SO you have just found out that someone ells have installed a gateway in the area. How do you know they are not planning another 20 or 100 in the same area?
Then what will your plan of action be to limit your impact on the network then?
I have the eui of the other gateway (B827EBFFFE1F43CC), but I didn’t find a way to get more information about it. Can you point me to the right direction?
When I first tried to get it running, I had the gateway in the exact position where it is now. But the button never switched to SF12 even after trying to rejoin. That’s why it configured it to fixed SF12. Having only one connection a day it shouldn’t hurt so much. But as we saw, it practically didn’t stick to SF12.
Of course I had expected a earlier switchback to SF12 if SF9 doesn’t work. At least when pressing the button, which is configured to require confirmation, I expected to retry until confirmed.
If you search the forum you’ll find numerous posts on getting information about gateways.
Funny that: “The LoRaWAN Alliance requires network operators to restrict the habitual use of SF 11 & 12.”
Sounds like there are issues with the implementation - there is no point just retrying if you don’t get a response, it should start increasing it’s SF and/or rejoining …
Please dont! Confirmed messages require downlinks and even if you are within FUP (max 10/day) - which for an occasional button push device you should be if not hammering every day, remember that each downlink renders the sending GW deaf to all TX’s in its reception area for the duration - it may be the other user/GW owner isnt impressed by your downlinks
I saw the location in the log. But either this location is wrong or the gateway managed to fake a battery information as if it was sent by my device. But I’ll never belive a connection from northern germany to italy. There are the alps in between.
the button is pressed about once a week But then it must be sure it is acknowledged. So I think that’s what confirmation is for. And the other gateway owner couldn’t have detected this before the button was pressed, the outage of battery message was before the button was pressed.
As explained above and in many many other ways here and the internet at large, this is not possible. If a the meta data says that a gateway heard a device uplink, then unless there’s a massive yet-to-be-found bug in TTS, that’s what happened.
Occam’s razor would suggest this to be the case.
As explained above, this is not a good use of LoRaWAN - your weekly could be someone else’s 15 minute. And it doesn’t seem to help you - the device hasn’t rejoined or increased it’s SF, so rather pointless.
But this isn’t actually fixing the issue - a temporary gateway popped up, the radio settings have changed, they don’t appear to be changing back anytime soon, you will need to reboot/reset the device to get it back online and be prepared to do this again if the rogue gateway, or indeed any other gateway, pops up again. One way to mitigate having to reboot/reset each time is to install a gateway nearer to the device.
The best solution is to have a device that has firmware that can recover from these sorts of situations.
But I didn’t manage to find a search string to find such a post. Maybe I’m to old.
Yes, I think there is something wrong with the device. I’ll going to contact milesight. They made a good job in supporting me when updating the button with their tool bricked the button. So I guess they’ll be helpful.
of course I tried several terms but obviously not this term. With the sixth result I was able to find the gateway when using https://mapper.packetbroker.net/api/v2/gateways/netID=000013,tenantID=ttn,id=intima-gw-5292-02 using the id, but I didn’t find a method to look for the eui. And the gateways we have installed I were not able to find using the id. I probably have to dig deeper into using the api.
But another question regarding the intima gateway. As it it described as raspberry-pi based, I wonder whether it is perhaps a simple copy of a working pi from italy, thus having this wrong location and perhaps even a cloned eui. What would happen if the clone and the original is put to work?
What is your and the intermediate GW EUI and or GW-ID (you can see the 3rd Party GW details in any Rx metadata as above)