XB3 Global - Error with Digi Remote Manager upload file example

Digi Remote Manager
1

Hello, I am relatively new to Digi Remote Manager (DRM) and I was attempting to perform the example automation (Update Micropython from Remote Manager…) found in the documentation for the XBee3 - Global devices. I have both the GM1 and GM2 models and in North America. I continue to get an error in the automation that has the following result step:

<commands>
  <put_file>
    <error id="4">EINVAL invalid name</error>
  </put_file>
</commands>

The destination file path I used was as listed in the example:

In the Destination File Path field, enter: ~/MicroPython/main.py

Then I thought to myself…what is the file path from XCTU/Xbee Studio and so I tried:

~/flash/main.mpy

Note that I used the compiled uPython file in this second path. I used both the .py and .mpy files for both destination paths with no luck. I was thinking the file path was incorrect, but that didn’t work either. I did notice that when I selected the file from my computer, DRM adds a string of numbers to the beginning of the file name. The following is the request from the result for the upload file step and contains the changed file name:

Destination File Path
~/MicroPython/main.py
Source File
automations--1-fileset/1699472418424-main.py

Anyone have any idea? I am attempting to overwrite the existing main.mpy file on the device. Do I need to delete that first? Should I add a script in the automation to put the device into something other than REPL mode? I did deviate from the example and those deviations are as follows:

  1. Added to the first RCI the XML to disable uPython autostart (which would inversely match the later RCI XML which enables autostart).
  2. I added SM/UDP Request Connect after each reboot. I did this since it appeared that though I set up my XBees to connect to DRM once an hour, it does not “connect” (as in get the green chainlink) if this request is not made. For example, I left everything running over night and this morning I checked the connection history/summary tab and there were no connections (green bars). I assume that a connection request must be submitted in order for it too connect. This makes sense as connecting and staying “green” for the timeout interval would just unnecessarily burn data. Is my connection assumption correct?

All other steps fired off great. Especially after I added the Request Connects - then the automation completed very quickly. Following the example perfectly did not allow the automation to finish unless I manually requsted a SM/UDP connect. There is a minor typo in step 6g with the extra \ and misspelling of ‘micropython’.

Thank you and please let me know if you need screen shots, pics, setting configs, etc.

-Nick

2

I believe I figured it out. I still have another test to run which I will explain near the bottom. So my first issue was that I was doing a boneheaded thing and included the tilda (~) at the beginning of the file path. I wasn’t sure if DRM utilized this as way to define relative paths or if the documentation was using a generalized path. I would assume on their “high horsepower” devices they have more memory and an enhanced file system and they included the tilda for brevity of the example. However removing it seemed to work great, however I did use my modified path using “flash” instead of “micropython”. Here is what worked for the destination path:

/flash/main.mpy

The example uses /Micropython/myfile.mpy and I am not sure if that works or not as I have not tested it.

On my subsequent tests, I did use the Remove File automation step before I uploaded the new file. I am still not sure if this is necessary, but didn’t seem to be a big deal in terms of execution time (might burn more data tho). My concern with removing the file before uploading the new file, is that if the upload fails for some reason, then technically there would be no “main.py” file for the XBee REPL to execute. However the possibility of an interruption during an overwrite is probably about the same. So in either case, there would be an issue with the device not functioning properly which would just have to be corrected manually.

We generally do not update the software on deployed devices remotely unless it’s an extreme need. We usually default to “if its not broke, don’t break it”. My luck is that anything I do causes some failure or glitch. However my goal is to allow us to more frequently and confidently make changes to devices remotely. This will be a big improvement and save me a lot of personal headaches.

-Nick

1 Like
3

I’m very impressed, this was something unthinkable for me, in the next steps of this prerogative. I’m looking forward to the results of the new tests.

4

Hello Nick,
You are correct that the ~/ does not refer to any sort of home directory. Instead, the only root directory is /flash. You can refer to the documentation here.
The /MicroPython directory does not exist as well. It is expected that MicroPython files either go in /flash or in /flash/lib.
Best,
-Matt

1 Like
5

One more question, and maybe this should be a new topic, is there any documentation or index for the XML used for the automations/RCI payloads? I can infer quite a bit just by looking at the examples, but I checked the module documenation and didn’t see anything.

Let’s say I wanted to run an automation to modify some firmware settings on the XBee that I would normally do thru XBee Studio or XCTU, but I want to have an automation configure it. The use case would be for an XBee that is no longer within physical reach. I can guess at the sections and AT codes would follow those listed in XCTU/Studio, but would like to know specifics so I don’t end up breaking some thing. For example, the RCI payload to change check-in interval to remote manager would be:

<set_setting>
	<remote_manager>
		<DF>360</DF>
	</remote_manager>
</set_setting>

And lets say I want to change the APN (AT command AN), I would guess that the following would work

<set_setting>
	<cellular>
		<AN>myapn.com</AN>
	</cellular>
</set_setting>

I’d rather know the specifics over having to guess at the XML code. One workaround I might do is to simply put the XBee into a persistent connection state and changed them through Remote Manager, but of course this process will require me to be ready a specific window and will also burn more data. I looked breifly through the Remote Manager documentation and didn’t see anything either. I was hoping someone could point me in the right direction.

Thank you.