0.9.2 was working - 0.9.3 Complains about config.json (again) *Found workaround

[ripred]

Okay here's an update and a question.  Mac OS 10.11.3.  I had already successfully registered 5 Oaks with particle.io (each upgraded the firmware).  I had a working sketch developed under 0.9.2 (with my own min/max fix) which allowed me to control 2 servos on my Oak.  Worked great, changed the sketch many times and each uploaded great.  Today I decided to upgrade to 0.9.3.  I moved my existing Arduino15 folder to my desktop so it would not be found, started the IDE (1.6.7 which had worked with 0.9.2 for me) and set the Preferences again to find the additional libraries, and installed the 0.9.3 Oak libraries and tools.

Now I am back to being unable to upload a sketch, each time it complains about not being able to find the config.json file.  I checked and the file is successfully being updated and placed at the correct location - /Users/trent/Library/Preferences/oak/config.json.  So now this seems different from the config.json problems that existed a week or so ago.  This seems more like an IDE issue rather than an Oak/firmware issue but I am not sure.

Question:  Do I need to Restore my Oaks to factory defaults (they all worked fine under 0.9.2) and re-register them with particle.io again?  I'm getting a little concerned that each firmware release might mean that I have to break out my FTDI and start all over with my Oaks from scratch each time.  Is this the case?  I thought I had read that after the initial firmware upgrade was successful that firmware upgrades would be automatic from then on?

I am going to remove my *new* Arduino15 folder and put back the original 0.9.2 version I had saved away to see if it still works under the older 0.9.2.

Anyone else seeing this behavior, or can clarify whether I need to restore/upgrade fw/ for all 5 Oaks all over again?  Again I have concerns that this time consuming process may be required with every firmware release/fix.  That would be disappointing.  Just to clarify, It compiles fine but ends with an error in the 1.6.7 IDE stating:

"Config file not found at: /Users/trent/Library/Preferences/oak/config.json - please run the oak tool from the command line with no arguments to configure.".  I have checked and the file is there.  I even tried chmod'ing it to r/w for everyone (666) - again, IDE doesn't seem to find it.  I can tell from the changes to the output that I am running a newer oakcli and have verified that choosing a different Oak (I show 5 choices from my previous registrations) does change the contents of the config.json.

Thanks in advance

[ripred]

Update #2: I restored 2 of my Oaks to their factory defaults (FTDI OakRestore) and upgraded their firmware and successfully completed the particle registration (again).  Running the Arduino 1.6.7 IDE with the Oak board selected via the Boards Manager (oak libraries version 0.9.3) and I still get the complaint about not finding the config.json file.  *Sigh*, this all seems like a step backwards. I now wish I had left well-enough alone since my 0.9.2 packages (with local fixes) all seemed to be working fine.  Again this is on a Mac OS X 10.11.3 with the 1.6.7 Arduino IDE.  I have seen posts in the past two weeks about the 1.6.5 IDE working better for some people.  That may be my next try or I might just put these all aside and call it an interesting $50 lesson.  Sorry for the pessimistic tone but my interest level versus frustration levels seem to be crossing a line where this is all starting to become a little too *experimental*. If anyone else is experiencing going from a working 0.9.2 environment to a non-working 0.9.3 environment I'd love to hear if your experiences match mine and if there is anything I am missing or not trying.

Thanks all

[ripred]

Update #3

Tried IDE 1.6.5.  Same results.
Turned on verbose output during uploads (in Arduino IDE) to see full path of ino.bin file.  On a command line I moved into the .../tools/oakcli/0.9.3 folder and executed the  ./oak binary along with the argument to the .ino.bin file to flash.  Still complained about not being able to find the /Users/trent/Preferences/oak/config.json file.

Remembering back to when we first had a path issue I ran NodeJS on the oak.js we had used a couple of weeks ago to solve the original APPDATA path problem.  The upload attempted and ran successfully, flashing the newly compiled ...ino.bin correctly to my Oak.  It is now controlling two servos again.

My belief now is that the oakcli binary for Mac that is currently part of the 0.9.3 library update is either out of date or it has a new bug in it.  I will next attempt to find the oakcli compiled by another member that I saw a couple of weeks ago and see if that works.

Summary:  Current oakcli binary for the Mac in 0.9.3 package is out of date or has a new bug.  NodeJS with fixed oak.js code works fine.

[tcarleton]

ripred, I think I might be seeing the same thing on Lubuntu x64 - assumed it was because I haven't re-activated with the new firmware (separate issue, separate message) but the IDE says it can't find the file that the new oak tool rights (I've verified the file exists and is recreated each time).

I've already done the "purge" steps to remove existing digistump files from packages and staging, but this still persists.
I've used the oakcli download links for 0.9.3, used the one found in packages/digistump/tools/oakcli/0.9.3/oak dirs.  Ran nodejs oak.js and even ran through the build process from "https://github.com/digistump/OakCLI".

[ripred]

@tcarleton et al:

Update #4:

After I was able to use nodejs this afternoon to upload successfully (with a modified oak.js that used to work and continues to do so on OS X) I want to point out the following:

I returned to using the Arduino 1.6.7 IDE and it still works fine as long as I use nodejs to upload the resulting bin file.

I had moved (not deleted) my old 0.9.2 Arduino15/... folders.  After the results I discovered from my previous posts in this thread I have also found that copying the oak binary from my (previously working) 0.9.2 folder into the existing 0.9.3 folder can get things working again via the Arduino IDE without having to go to a command line to finish the upload using nodejs.  Again, looks like a bad linux/mac binary.

Just in case it helps I am not using the oak.js from the current github.  I am using one that we debugged a couple of weeks ago that was tweaked specifically to get Mac OS/linux to possibly work.  I'll attempt to attach the oak.js source I am using with NodeJS and *maybe* this source will fix your issues as well.  I know this source version has no sensitivity to being Windows aware because those parts were cut out but this works for me under nodejs, with everything else being a fresh install of Oak libraries 0.9.3 with the Arduino 1.6.7 IDE, again, under Mac OS X (darwin).

Best of luck!

[tcarleton]

ripred,
Thank you for posting it! Just tried and the modified pathToConfig wasn't the fix for me -- the output seems to be the same fields with different auth tokens for each attempt (makes sense), I'm guessing the only difference was the ability to select different oaks in the background...

Looking at the script though -- I didn't realize this was also a (the?) mechanism to do the uploads, and the source of the error message I'm seeing in the arduino console.

function loginOrFail(){
   if(process.argv.length>2){
      console.log("Config file not found at: "+pathToConfig+'config.json'+" - please run the oak tool from the command line with no arguments to configure.");

I guess now I have to figure out if where the IDE is calling it from before trying to debug.

[tcarleton]

Okay!  So, replacing the oak binary in my ~/.arduino15/packages/digistump/tools/oakcli/0.9.3 directory with an old one (my downloads directory is a mess fortunately) doesn't complain about the config.json anymore!  I'm guessing there's something about the way the argument is passed to the new binary that the shipping 0.9.3 tool doesn't like.

Now, to risk trying to upload to a 0.9.2 or not   

[fredderf]

Apparently there's a problem with "nexe" on the mac.  I added a little debugging and discovered the require call to load the config was failing.  I changed the require path to a constant (instead of a dynamic path) and the error went away.  Re-uploading from Arduino Studio now says:
Sending file to cloud, to flash to device...
Device flashing started successfully.

But I don't think the code made it to my Oak.  I changed my LED blink code to leave the LED on for 2 sec then off for 2 sec.  My Oak is still just blinking slowly.


function loadConfig(){
   process.stdout.write("loadConfig");
   try{
      config = require('/Users/xxxx/Library/Preferences/oak/config.json');
//      config = require(pathToConfig+'config.json');
      process.stdout.write("loadConfig: access_token = " + config.access_token + ", device_id = " + config.device_id);
      return true;
   }
   catch(e){
      process.stdout.write("loadConfig - error = " + e);
      return false;
   }
}

[koioslabs]

Just wanted to add that I'm also encountering this issue, I tried running oak.js via node, but didnt really help anything. I've also verified the config.json exists.

I may try tomorrow to debug it further, not that motivated tonight

[nelsonsilvafilho]

Same problem here on a Mac OSX 10.11.14 with OAK 0.9.3
Arduino 1.6.5 after compilation tell there is no config.jason but it exists .

[kirby]

I am a sub-noob with node.js. However, I figured out that the issue is apparently a 'No such native module' error at the

config = require(pathToConfig+'config.json');

of the loadConfig() function. If I change that to "require('/home/kirby/.oak/config.json')" things seem to work just fine from the command line. Still doesn't like to work from within FC23/arduino1.6.7/oak0.9.3.

Is this function hidden somewhere inside the 0.9.3 code?

I will leave it to higher pay grades to figure this out.

[werner]

I also had issues when I switched, but then I completely deleted the Arduino IDE and re-installed everything from scracth.  Afterwards the problem was resolved.

[gej]

Hello,

Since you all have the problem on Mac and we have here the problem on Ubuntu we tried to investigate and didn't succeed.

However:

eurycea did succeed. He uploaded his fork to github.
https://github.com/eurycea/OakCLI/commit/a74c5b0e17196fcf3866fcbe9073422503bf401b

-    config = require(pathToConfig+'config.json');
+    contents = fs.readFileSync(pathToConfig+'config.json', 'utf8');
+    config = JSON.parse(contents);

We now have a working .0.9.3 under linux together with 1.6.7 arduino.

(rename the oak.new to your oak)

https://dl.dropboxusercontent.com/u/12324509/oak.new.xz
(only for ubuntu/linux 64 bits)

[byronsalty]

This replacement cli fixed the problem for me too. Though it took about 20 minutes to create the new oak command.

The key part for me was realizing which oak cli to change, which for me was in:
/Users/<username>/Library/Arduino15/packages/digistump/tools/oakcli/0.9.3
 

[mkarliner]

Worked for me as well, on El Capitan with Arduino 1.6.7

Thanks very much.

Mike