flashDevice() fails in Particle JS API [SOLVED]

Hi,

I have the following Javascript for the JS API which tries to flash my Photon:

/*jslint node: true */
"use strict";

var auth = require('./auth.js');
var Particle = require('particle-api-js');
var particle = new Particle();

particle.login({
    username: auth.username,
    password: auth.password
}).then(
    function(data) {
        console.log('Login success: ', data.body.access_token);

        var flashPr = particle.flashDevice({
            deviceId: auth.device,
            files: {
                file1: './test.bin'
            },
            auth: auth.token
        });

        flashPr.then(
            function(data) {
                console.log('Device flash result:', JSON.stringify(data));
                process.exit();
            },
            function(err) {
                console.log('An error occurred while flashing the device:', err);
            });
    },
    function(err) {
        console.log('Login failed: ', err);
    }
);

When I execute it the following is logged:

Login success: <---redacted---->
Device flash result: {"body":{"id":"<device id>","status":"Update started"},"statusCode":200}

But shortly after in Particle Console I see a ‘spark/flash/status’ event with data ‘failed’. I have tried both full and relative names for the binary file. I am using version 6.0.3 of particle-api-js.

To run this you will need an auth.js file with your credentials, like:

module.exports = {
    username: '<your email>',
    password: '<password>',
    device: '<deviceId>',
    token: '<auth token>'
};

Did you make sure they .bin file matches the device type?

Yes, it was compiled in the cloud using Particle Dev with my Photon selected.

Chris

Have now tried this with Tinker program downloaded as Tinker.ino, then compiled in the cloud with Particle Dev, but no luck.

I can successfully upload using button in Particle Dev so it seems like the binary is good.

Hello Chrisb2,

I ran into the same problem when trying to flash a Photon via JavaScript from a web-app. Turns out you need to make an HTTP GET request for the file and specify the responsetype of the request. I got it to work with the following code:

// Create a new XMLHttpRequest.
// Just giving a url to the binary file does not work when flashing firmware. We first have to GET the file
var xhr = new XMLHttpRequest()

// Set the event handler for when the request is completed
xhr.onload = function(e) {

	// Create a new file from the response
	var file = new File([xhr.response], 'lights.bin')

	// Flash the binary firmware to the specified device
	var flash = lights.app.particle.flashDevice({deviceId: device.id, files: { file1: file} })

	flash.then (

		function(data) {
			console.log('Device flashing started successfully', data)
		}, function(err) {
			console.log('An error occured while flashing the device, trying again', err)
					
		}

	)

}

// Get the file
xhr.open("GET", url)
// Specify the filetype, important!
xhr.responseType = "arraybuffer"
// Make the request
xhr.send()

Hope it helps!

When using this with Node.js, there’s no need to get the file, since it should be in the specified directory. For web apps you do need to GET the file first though :o

I was able to reproduce the failure to flash behavior with 6.0.3, but it works correctly with 5.3.1 for me.

npm install particle-api-js@5.3.1

Also: Unrelated to your problem, but you don’t have to particle.login in every time you use the Particle API JS. You can just save the accessToken string in your configuration file and pass it directly into any function. This eliminates the need to save the username and password; you can just save the access token.

Ah, didn’t notice you were using Node.js, hope you find a solution!

Thanks rickkas7, downgrading to 5.3.1 work for me, I will look into raising a bug against the JS API. Thanks for the hint on script too.

Have established by trial and error that the ‘bug’ was introduce in 6.0.3 as 6.0.2 works fine.

Looks like this commit which changed dir handling in Agent.js may be the source of the problem:

Support nested directories when compiling sources

Chris

2 Likes

This topic was automatically closed after 4 days. New replies are no longer allowed.