You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The descriptions of the physical hardware used by those that are using the Relay TS011 facilities is diverging and runs the risk of confusing everyone making a mess of support or anyone trying to obtain hardware.
Trying to reach a concensus that clearly describes the roles and clarifies the CLI commands has the potential to reduce support issues.
Steps to Reproduce
TTS refers to serving for the device that relays a message from an out of range device that is called served. This has pronunciation, spelling, autocorrect and I'd suggest is too phonetically similar to make for a clear conversation, particularly being heard by a non-native English language listener.
Semtech haven't surfaced the docs for a serving device but refers to the served device at compile as MODEM_APP=RELAY_TX ALLOW_RELAY_TX=yes
KroonosRelay from @StevenCellist has settled after discussion with me, on Relay for the serving device and NodeR for the served device.
Additionally, the TTS CLI docs says things like ttn-lw-cli relays create [application-id] [device-id] [flags] which is OK but less than ideal as device-id references the serving device (Relay). To setup a served device the syntax is ttn-lw-cli relays create [application-id] [device-id] --mode.served.serving-device-id string where device-id is the served device and the 'string' references the serving device - which is somewhat obvious given the text of the flag. I'd anticipate a lot of finger trouble typing that lot and getting the device ids the right way round etc.
Current Result
I've managed to solicit many errror messages in the last few days from the CLI that were either a blizzard of incomprehensible output or a succinct oneliner (Redis error). Then I have to figure out serving vs served.
Expected Result
If other words were used for serving and served or aliases could be set or duplication of the flags with an alternative naming scheme it would help make already complex functionality clearer to configure.
Relevant Logs
Examples - SnowJoke is a Mac mini M1 running Sonoma talking to the relay.eu2 discovery instance:
nick@SnowJoke Reference % ttn-lw-cli relays update ttc2024demo noder-loradio32-1 --mode.serving.limits.join-requests.reload-rate 60
error:pkg/redis:store (store error)
correlation_id=5be5eda4ad9a412992b06ddac1b7825b
nick@SnowJoke Reference % ttn-lw-cli relays get ttc2024demo noder-loradio32-1
error:pkg/networkserver:relay_not_found (relay not found)
correlation_id=d6a85a89b2e346bb9585143b26966bc8
nick@SnowJoke Reference % ttn-lw-cli relays get ttc2024demo the-relay
error:pkg/networkserver:relay_not_found (relay not found)
correlation_id=313c8f0c04ea47978abe9e7f85d78ed6
URL
No response
Deployment
The Things Stack Cloud
The Things Stack Version
3.32.1
Client Name and Version
The Things Network Command-line Interface: ttn-lw-cli
Version: 3.32.0
Build date: 2024-09-05T14:50:21Z
Git commit: 32b3f88e3
Go version: go1.21.13
OS/Arch: darwin/arm64
Other Information
If this strikes a chord, hopefully we can discuss a naming convention that provides clarity to savvy end-users who don't tend to read the specs (99% of them!)
Proposed Fix
Relay and NodeR came about after a lot of to & fro during development and has made testing so much simpler when talking about the different elements of a deployment.
Contributing
I can help by doing more research.
I can help by implementing a fix after the proposal above is approved.
I can help by testing the fix before it's released.
As a short explanation for the NodeR name: it is a Node with the TS011 extension such that it can talk to a Relay --> a Node that does Relay --> NodeR.
(I don't mean to say that this is the ultimate naming solution, it is an explanation for the choice of name we thought fitting.)
Summary
The descriptions of the physical hardware used by those that are using the Relay TS011 facilities is diverging and runs the risk of confusing everyone making a mess of support or anyone trying to obtain hardware.
Trying to reach a concensus that clearly describes the roles and clarifies the CLI commands has the potential to reduce support issues.
Steps to Reproduce
TTS refers to serving for the device that relays a message from an out of range device that is called served. This has pronunciation, spelling, autocorrect and I'd suggest is too phonetically similar to make for a clear conversation, particularly being heard by a non-native English language listener.
Semtech haven't surfaced the docs for a serving device but refers to the served device at compile as
MODEM_APP=RELAY_TX ALLOW_RELAY_TX=yes
KroonosRelay from @StevenCellist has settled after discussion with me, on Relay for the serving device and NodeR for the served device.
Additionally, the TTS CLI docs says things like
ttn-lw-cli relays create [application-id] [device-id] [flags]
which is OK but less than ideal as device-id references the serving device (Relay). To setup a served device the syntax isttn-lw-cli relays create [application-id] [device-id] --mode.served.serving-device-id string
where device-id is the served device and the 'string' references the serving device - which is somewhat obvious given the text of the flag. I'd anticipate a lot of finger trouble typing that lot and getting the device ids the right way round etc.Current Result
I've managed to solicit many errror messages in the last few days from the CLI that were either a blizzard of incomprehensible output or a succinct oneliner (Redis error). Then I have to figure out serving vs served.
Expected Result
If other words were used for serving and served or aliases could be set or duplication of the flags with an alternative naming scheme it would help make already complex functionality clearer to configure.
Relevant Logs
URL
No response
Deployment
The Things Stack Cloud
The Things Stack Version
3.32.1
Client Name and Version
Other Information
If this strikes a chord, hopefully we can discuss a naming convention that provides clarity to savvy end-users who don't tend to read the specs (99% of them!)
Proposed Fix
Relay and NodeR came about after a lot of to & fro during development and has made testing so much simpler when talking about the different elements of a deployment.
Contributing
Validation
Code of Conduct
The text was updated successfully, but these errors were encountered: