Hi all,
I’m trying to remote administer a RAK4631 running V2.0.12 from a T-Beam running V2.0.11 by using Linux Python-CLI, hardware connected to the T-Beam.
Here is an example showing the problem:
~/Downloads/Meshtastic$ meshtastic --dest '!d2cf9f7b' --get lora.tx_power
Connected to radio
Requesting channel 0 info from remote node (this could take a while)
Requesting channel 1 info from remote node (this could take a while)
Error: Timed out waiting for node config
meshtastic --info shows that the admin channel is existing on both nodes and the psk for the primary and secondary channel, as well as both urls are equal.
The nodes can see each other in the mesh and it is possible to transfer regular messages over the primary channel.
Trying vice versa (RAK => T-Beam) gives the same negative result.
I see something non-suspicious on the Debug-Panel from the ADMIN-APP… This is running on channel 1 whereas i set my primary channel to 6 but this shouldn’t matter(?).
~/Downloads/Meshtastic$ meshtastic --dest '!d2cf9f7b' --reboot
Connected to radio
INFO file:node.py reboot line:463 Telling node to reboot in 10 seconds
Waiting for an acknowledgment from remote node (this could take a while)
Received an ACK.
A --shutdown command also worked, although the ACK did not arrive (running long-slow here). Changing --set-owner also worked. However:
~/Downloads/Meshtastic$ meshtastic --dest '!d2cf9f7b' --set lora.tx_power 6
Connected to radio
Requesting channel 0 info from remote node (this could take a while)
Requesting channel 1 info from remote node (this could take a while)
Error: Timed out waiting for node config
For getting or setting, the CLI needs to request the channel and config of the remote node, which currently consists of multiple packets. That’s why this is a bit unreliable, especially if the packets need to hop across multiple nodes to get to the destination. Things like reboot and shutdown only require one packet, so the chance of that working is higher, although indeed the ACK may be lost or may not arrive in time.
I think the commands you used are correct, it’s just that how the CLI handles getting and setting commands is not really suitable now that multiple LoRa packets are required for it (IIRC this used to be one packet before, but it has gotten too big).
By the way, are you by any chance testing with two devices in the same room? This might cause problems, it is better to space them at least some tens of meters apart.
OK, so this sounds that i/we have to wait some time until that is improved in a next FW update.
Really, the SNR matters? I experimented in the same room, yes.
Now i put the remote node farer away and use poor antennas. The rssi is -94.
Result:
~/Downloads/Meshtastic$ meshtastic --dest ‘!d2cf9f7b’ --get device.role
Connected to radio
Requesting channel 0 info from remote node (this could take a while)
Requesting channel 1 info from remote node (this could take a while)
Requesting channel 2 info from remote node (this could take a while)
Requesting channel 0 info from remote node (this could take a while)
Requesting channel 1 info from remote node (this could take a while)
Requesting channel 2 info from remote node (this could take a while)
Error: Timed out waiting for node config
Still strange… Trying with even lower rssi didn’t change the situation…
The problem is probably not with the firmware, but just with how the CLI handles it.
A too strong signal might saturate the antenna or distort the signal in another way. It looks like it is getting a bit further now, but I am not sure why it started again at channel 0.
Another test: Trying to --get a parameter from a T-Beam, called by a TTGO Lora V2.1-1.6:
~/Meshtastic/Firmware$ meshtastic --dest ‘!a3faae70’ --get lora.tx_power
Connected to radio
Requesting channel 0 info from remote node (this could take a while)
Requesting channel 1 info from remote node (this could take a while)
Requesting channel 2 info from remote node (this could take a while)
Requesting channel 0 info from remote node (this could take a while)
Requesting channel 1 info from remote node (this could take a while)
Requesting channel 2 info from remote node (this could take a while)
lora.tx_power: 0
Completed getting preferences
The first time i’m getting a result at all. But the result is wrong!
Another attempt on the same infrastructure:
~/Meshtastic/Firmware$ meshtastic --dest ‘!a3faae70’ --get lora.hop_limit
Connected to radio
Requesting channel 0 info from remote node (this could take a while)
Requesting channel 1 info from remote node (this could take a while)
Error: Timed out waiting for node config
meshtastic --dest '!bdf0ae34' --get lora.region
Connected to radio
Requesting channel 0 info from remote node (this could take a while)
Requesting channel 1 info from remote node (this could take a while)
Requesting channel 2 info from remote node (this could take a while)
Requesting channel 0 info from remote node (this could take a while)
Requesting channel 1 info from remote node (this could take a while)
Requesting channel 2 info from remote node (this could take a while)
lora.region: 0
Completed getting preferences
meshtastic --dest '!bdf0ae34' --get lora.hop_limit
Connected to radio
Requesting channel 0 info from remote node (this could take a while)
Requesting channel 1 info from remote node (this could take a while)
Requesting channel 2 info from remote node (this could take a while)
Requesting channel 0 info from remote node (this could take a while)
Requesting channel 1 info from remote node (this could take a while)
Requesting channel 2 info from remote node (this could take a while)
lora.hop_limit: 0
Completed getting preferences
meshtastic --dest '!bdf0ae34' --get device.role
Connected to radio
Requesting channel 0 info from remote node (this could take a while)
Requesting channel 1 info from remote node (this could take a while)
Requesting channel 2 info from remote node (this could take a while)
Requesting channel 0 info from remote node (this could take a while)
Requesting channel 1 info from remote node (this could take a while)
Requesting channel 2 info from remote node (this could take a while)
device.role: 0
Completed getting preferences
Remote admin has almost never worked reliably since 2.0 and it’s a shame, since it’s a much more efficient way to change settings than using Wi-Fi or Bluetooth.
Yes, i meanwhile have a number of remote nodes and it would be great to upgrade them remotely. Also changing the lora.tx_power would be useful.
At least the reboot and shutdown commands are working…
So let’s hope for some FW updates in that issue…
I would, but it’s beyond my skills i fear. It’s not a single .cpp file i guess. But some day, who konws… There is always a learning curve…
I just upgraded the python CLI to 2.0.9. It’s not long ago that i upgraded to 2.0.8. So there must be someone working…
That does not sound good!
Would you say the project tends to die? Just a short hype?
So there is no one interested in remote node administration? I would always have to climb hills and high buildings with a notebook and USB cable, just to flash the latest FW…
PS: I don’t know what’s the result from the recent meeting which was announced for defining the next steps, where the project develops. In my opinion the basic functionality (writing messages that actually arrive and get confirmed) should work reliable, otherweise a marojity may leave the project sooner or later…
Most users don’t want to have to use a CLI at all. The project is in better shape than ever, but it is all volunteer and people work on what they want, which may not match what you want. If you are passionate about remote admin from the CLI, have at it.
Yeah, a lot of what I’ve seen in terms of remote nodes is people tend to set and forget or they have access to them. While the remote administration would be nice, it’s not a priority for many. With the advancement of the apps and the amount of control you have with them now, that’s mainly what people care about.
Remote administration of nodes via CLI is not a basic functionality. It would be Advanced. In terms of basic functionality, sending and receiving messages and confirming they arrive, that’s pretty much 100%. You can now even determine if the specific node you wanted to receive the message (direct message) did in fact receive it thanks to the Traceroute module that was recently added.