I have successfully automated the configuration of new Digi IX20W devices using a Python script with paramiko for ssh connection. Now, I am trying to automate the firmware update process.
I attempted to use the scp command in the Digi CLI to transfer the firmware file from my local PC to the Digi device but have not been successful. My goal is to upload the firmware to /tmp/ and then execute system firmware update /tmp/{firmware}.bin via SSH in my script.
Additionally, I checked Digi Remote Manager’s API but found no direct API for uploading firmware—only an API for triggering firmware updates based on the assigned group. Our devices require an intermediate firmware update before upgrading to the latest version, which would require assigning them to an intermediate group first.
Furthermore, I noticed that the web interface uploads the firmware via a POST request before installing it. While I’d prefer not to use web requests, I’m open to any working method.
Has anyone successfully automated firmware uploads and updates on Digi IX20W devices? Any insights on using SCP, an alternative file transfer method, or leveraging the web request approach would be appreciated.
@cshafer , granted I am a very biased opinion since I use Digi Remote Manager daily in my troubleshooting of customer issues, but I really think the answer to your question is Digi Remote Manager.
For example, a Template can be created, which is specific to a Group and Device Type, which would insure that all of your devices conform with the firmware version, settings, and file load you specify on the device, and this would automatically be checked at whatever interval you configure. To tackle your intermediate firmware update requirement, you’d run a pre-Template Automation, which would update your firmware to the intermediate version even before the Template scan continues. When the Template is scanned, your device would then be updated to that version you specified.
RE: your description of the firmware being uploaded first via POST, before the OS/firmware update runs on the devices, this is true and very intentionally by design. The firmware is uploaded in its entirety, after which a checksum is run on what was uploaded to verify the file isn’t corrupted. Only after that will the update continue, with the new OS being loaded in the primary partition, and the previous firmware being pushed to a backup partition (in case the primary OS doesn’t load). In more modern firmware versions, if the updated OS doesn’t load properly, the device will eventually fall back to what it was running before the update, as a failsafe/self-rescue feature. I can verify this works, as I test new versions of our OS pre-release all the time, and this has happened on pre-release firmware before we worked the bug out.
I haven’t personally tried doing a firmware update the way you described, so unfortunately I can’t offer any recommendation on the scripting etc. you’re trying to do to accomplish that task, but since Digi Remote Manager is bundled with many of our products now via Digi360 and Lifecycle Assurance, you can’t go wrong if you give the method I described a try. You could definitely save yourself some work though by Automating this!:
References: Templates, Automations
@michaelt Thank you for the quick and detailed response!
I agree that creating an intermediate group for the staged firmware update is the best way to go, and I’ll move forward with implementing it that way.
My main reason for initially exploring SCP or direct uploads was speed—during testing, I found that updating firmware while connected via Ethernet was noticeably faster. However, I understand the benefits of Remote Manager’s verification and failover mechanisms, so I’ll work within that framework.
Thanks again for your help! I’ll report back with any issues for successes that I have.
Automating firmware updates on the Digi IX20W is definitely a smart move, especially for managing multiple devices remotely. If you’re using Digi Remote Manager (DRM), it makes the process much smoother. You can schedule updates, push them to groups of devices, and monitor the success rate—all without manual intervention. Just make sure you test the firmware on one device before rolling it out across the network to avoid compatibility issues. Also, enabling rollback options where possible is a good safety net in case anything goes wrong. Anyone else here using custom scripts with DRM for automation?
If you’re looking for an unforgettable luxury train experience, I’d love to help you plan your dream journey! One of our luxurious offerings is the India Palace on Wheels train, a luxury train that takes travelers on a royal journey through Rajasthan, showcasing its rich heritage, majestic forts, and vibrant culture.
Palace on Wheels is India’s first and most iconic luxury train, offering an opulent travel experience in the heart of Rajasthan. Operated by the Rajasthan Tourism Development Corporation (RTDC) and Indian Railways, this award-winning train recreates the grandeur of royal carriages once used by Rajput and British rulers. Featuring world-class hospitality, regal interiors, and curated excursions, the Palace on Wheels Itinerary back in time to India’s majestic past.