things4u / ESP-1ch-Gateway

Version 6 of the single channel gateway
MIT License
370 stars 149 forks source link

End of the one channel gateways ? #94

Open florafrisia opened 3 years ago

florafrisia commented 3 years ago

Hi,

I'm searching for the solution why my gateway is not working. I came across this article from the things industries https://www.thethingsnetwork.org/forum/t/single-channel-packet-forwarders-scpf-are-deprecated-and-not-supported/31117

Can someone elaborate a little more about this matter that scpf are not supported anymore.

With kind regards,

Peter

RCB07 commented 3 years ago

Of course dont work :( Its very sad

shybzzz commented 3 years ago

I can see this article is of 2019, and it worked somehow till 2021 :)

but current version of master branch of this repository does not work form me with ttn v3

cstratton commented 3 years ago

Weather or not is appears to work to even the slightest extent is irrelevant, even trying to connect these to TTN is explicitly prohibited.

platenspeler commented 3 years ago

It works.

cstratton commented 3 years ago

It works.

Only in the view of those who aren't really trying to use LoRaWAN on a real LoRaWAN network, and hence ignore the problems which a gateway only present for one frequency and spreading factor combination causes to the ADR algorithm on other people's nodes that expect a LoRaWAN network to actually implement LoRaWAN.

If you want to use this, it will need to be on a private network. It is banned on TTN, because no, in fact it not only does not work properly on TTN, but fails in a fashion detrimental to others even as it may appear to sort of work to the person who installs it for their own more limited test without awareness of what it is doing to others.

JamesOlvertone commented 2 years ago

I am not 100% in the LoRaWAN spec but would it be possible to mimic to TTN-Server 100% compliant Nodes while in the backend sensor nodes could be anything, even raw Lora or anything else as long as you have the right receivermodule for it. I mean the whole back and forth communication from TTN through the gateway to the node should end in the gateway. If TTN sends some requests to the sensor the gateway should send the data TTN expects. The gateway manages my local nodes with keys, IDs, Join and anything else what TTN uses. This is mapped to my local sensors that can be anything.

cstratton commented 2 years ago

would it be possible to mimic to TTN-Server 100% compliant Nodes while in the backend sensor nodes could be anything

Possibility would be irrelevant - doing so is a violation of TTN's terms of use.

TTN is a public LoRaWAN network, if you want to do something that is not LoRaWAN, you have to run your own servers to handle your unique traffic. The public server instances exist only to support proper LoRaWAN traffic from the user community arriving from actual shared gateways that are there for the use of the community as a whole.

Their donated to the community backhaul and processing power are not for other types of traffic, no matter if it impersonates LoraWAN traffic or not.