they don’t answer
1 Like
C:\ttn>ttn-lw-cli login
INFO Opening your browser on OIDC provider error
INFO After logging in and authorizing the CLI, we’ll get an access token for future commands.
INFO Waiting for your authorization…
INFO Successfully got an access token.
C:\ttn>ttn-lw-cli end-device delete my-honda-gps eui-70b3d57ed004b7f1
WARN [core]grpc: addrConn.createTransport failed to connect to {127.0.0.1:1700 127.0.0.1:1700 0 }. Err: connection error: desc = “transport: error while dialing: dial tcp 127.0.0.1:1700: connectex: The connection could not be established because the target machine actively refused.”. Reconnecting…
connection error: desc = “transport: error while dialing: dial tcp 127.0.0.1:1700: connectex: The connection could not be established because the target machine actively rejected it.”
You need to be patient! You posted on a Saturday and are not on a support contract as far as I am aware. Even people on the basic support contract have an 8hr response - and that is working hours on working days…you are on the free/community platform and any response will be at TTI team discretion and I assume they will prioritize support to paid customers and ones who havent done something outside of normal operation of the stack stack (127.0.0.1 is usual local/loopback) so suspect they are scratching their heads as to what you have done and why…and twice! 
Those of us experimenting and testing on the community platforms realise we may get an answer at some point but we may have to wait hours, days… for clients we commit to supported instances if we expect/need timely access to tickets and support…
You entered a localhost address for no apparent reason - I’m not surprised the system is confused - I’d just stop and wait to see if TTI can/will/want to help.
Personally I would not fret it but rather abandon those devices in your console for now - until you get some resolution - and crack on with doing ‘proper’ deployments using normal addresses… it may be you just end up with some application/device ‘clutter’ in your console views if not judged important…
OK, I’ll wait. but there is definitely a problem in v3 console. If I write there by mistake, I have to delete my consul whenever I want.
I can’t imagine they thought someone would put in that address - as a software developer I am forever chasing my tail on entry validation.
You could put some masking tape over those entries and get some new devices.
If I delete the gateway, will it be deleted on my devices? Then can I add my same device to another gateway?
Devices don’t know a gateway. You are confused with WiFi. LoRaWAN Devices just broadcast and any gateway withing radio range will receive (and forward) the data to a back-end.
Keep in mind that deleting a gateway makes the current gateway ID (not the EUI) unusable for future use as IDs can not be reused.
…and besides why would you delete the gateway - its the end device that was messed up, no?!
Yes, I know that device cannot be used. so I changed the eui number of the device with stl-usb. I want to delete those devices from the console, but it doesn’t work.
You are mixing gateways and end devices in your replies. Keep them separate as they are totally different beasts with different requirements in the TTN platform.
Can you write me the cli code that I can activate the network address on the end devices as an example. for example : c:\ttn>ttn-lw-cli end-device network-server-enabled eui-70b3d57ed004b7f1 . There should be a code like this but I couldn’t write it
If you want to change settings on an end device you need end device specific tools. Because there are many end devices by different vendors it would be hard to create a universal tool that can be made part of the TTN software stack.
I think you need to dig deeper into LoRaWAN implementation and architecure before your start to look at this issue - nodes have no knowledge of either the NS or its address…its the GW that is responsible for taking a message from a node and communicating it over the internet to the NS - the GW knows the address, the node doesnt! WHat you put into the NS/Console is information about the device - its APP/Join-EUI, its Dev EUI, and in case of an ABP device its Dev addr…its ‘keys’ if you will…that will identify its messages to the NS when they arrive from the GW. If they dont match the NS will decide it is not intended for that network and will drop it. If they match then the NS will handle the messgaae and pass on to your application. In the case of an OTAA device the NS will confirm it is one of its registered devices from those same keys and will send an assigned Dev addr back to the node. The node knows nothing of the NS IP or server web address, and the NS doesnt see the node as an IP addressed device as it doesnt have one…IP/Web address is purely for the GW-NS-GW comms. Hence a command to a node such as you propose would be meaningless.
1 Like
I just want to delete the last devices on my console and that’s it. I changed the eu id of my own device with the usb PL2303 tll device, it is working now. Thanks to all friends for their interest.
1 Like
I have the same problem. I used the CLI wrongly and the join server is set with a wrong value. Now I have the following response:
WARN Registered Join Server address does not match CLI configuration {“configured”: “eu1.cloud.thethings.network”, “registered”: “my-lora-server”}
I can’t delete the device with the CLI
Solution is: ttn-lw-cli device set [app-name] [device-name] --join-server-address xxx.yyy --join-server-enabled=false
2 Likes
dear Mryavas
could you tell how you I changed the eu id on your device with the usb PL2303 tll device, becasue i have the same issue of you?
thanks
I had created an app where my device was connected and now I lost my access and I can’t connect my device to another app again how can I connect to the app again?