Correct. Those have not been assigned by the LoRa Alliance, so you could say they’re “illegal”. Of course, anyone can do whatever they want, but as soon as they are using the LoRaWAN logo they need to adhere to the rules of the LoRa Alliance.
Note that according to some messages at Slack, apparently Actility/ThingPark Wireless does support whatever DevAddr it gets. But: I would not rely on that unless they explicitly tell you they will keep doing that in the future:
@cruzer 2017-12-02 10:27 AM
Hey guys, just want to ask some help if someone can point me to a direction where to find the solution.
My problem is this TBS-220 Parking sensor running AS923.
I have a RAK831 gateway running in Raspberry Pi host, and it can’t seem to get the data coming from the parking sensor.
I know the sensor is working because it is working in our “thingpark wireless” platform, but can’t seem to make it work in TTN.…
@arjanvanb 2017-12-04 9:57 PM
@cruzer I guess you considered this, but in case you did not: if you continue to use Actility then I’d ask them about support of
0x70addresses in the long turn, before getting more sensors. Just like TTN, they should only handle their own NetID…
I don’t know:
-
Your attempts to use @brocaar’s lora gateway bridge with the TTN Gateway are wrong, as the TTN Gateway is simply not using the Semtech protocol, which is what that bridge expects.
-
I don’t expect someone to write firmware for the TTN Gateway to support the Semtech protocol. (Also, right now, I would not know how to load such firmware into the gateway.)
-
I’d expect the TTN Gateway to some day support private backends (if those support the protocol that the TTN Gateway uses). But I don’t know if it’s already possible today. Maybe it is already possible.