Hi -
Please bear with me, my coding skills is VERY limited, hinges on non-existing actually 
I am using a MAX17201A fuel gauge in an application with the B524 as uC. Reason for the external fuel gauge is due to the primary cell application (Li-SOCL2 and LiMnO2). I found a library on Github and have been trying to import that into WebIDE so I can included it in my project, but have had no luck. Below is the link to the Github page. Would appreciate some help
Regards,
Friedl
@friedl_1977, the easiest way is to copy the library files to your project via cut and paste. First, add files to your Web IDE project by hitting the “+” sign in the top righ-hand corner. One file will have the .cpp extension while the other will be .h. Name the file “max1720x”. The other tab will automatically be named the same.
Go to GitHub and select the max1720x.h file to open it and copy its content using the “Copy raw contents” button.
Now do a paste in the (newly added) “max1720x.h” WebIDE file tab and save (I hit Ctrl-S to do this). Now do the same but with Github "“max1720x.cpp” file. The library is now copied to your project and you will find this at the top of the .ino file:
// This #include statement was automatically added by the Particle IDE.
#include "max1720.h"
Using the Github example and compiling for a BRN404x with DeviceOS 5.2.0 (prerelease), I had not compilation errors.
Hi @peekay123 -
Great thank you!! I will do this and let you know should I encounter any issues. I2C has really been giving me problems in this particular board and not sure why to be be honest.
I am hoping to target the fuel gauge directly as for some reason, the “scanner” is not detecting it. I reflowed four boards and double checked the schematic with Maxim but the problem persists 
Kind Regards,
Friedl.
Hi @peekay123 -
Indeed I do, 10k. The scanner I use is a very simple one, suppose to detect all I2C addresses connected directly to the uC. It does pick up some addresses but not all.
For some odd reason, 0x77 stopped showing up as well 
Maybe worth mentioning, some devices are connected to I2C via the multiplexer due to them having the same fixed address. The ones I am looking for now are simply the ones connected directly to the uC.
Regards, Friedl.
Based on the datasheet, the I2C address should be 0x6C and possibly 0x16 for reading a higher memory range, though that is somewhat unclear in the datasheet. Not sure what it isn’t found.
Hi @peekay123 -
According to Maxim it should be 0x6C yes… but I am not seeing that in the scan. Here is the code I use to scan:
//#include "Wire.h"
int tilt_value;
void setup() {
pinMode (D23, OUTPUT);
digitalWrite (D23, HIGH);
delay(5000);
}
void scanner () {
Wire.begin();
Particle.publish("\Quick Scanner ready!", PRIVATE);
for (uint8_t addr = 0; addr<=127; addr++) {
delay(10);
Wire.beginTransmission(addr);
if (!Wire.endTransmission()) {
Particle.publish("Found I2C 0x" + String(addr,HEX), PRIVATE);
}
}
Particle.publish("done", PRIVATE);
}
void loop() {
scanner ();
delay(10000);
}
Regards, Friedl
That is because they state the 8bit address but the Wire object expects you to provide the 7bit address (0x6C >> 1 = 0x36 and 0x16 >> 1 = 0x0B) 
@ScruffR -
So what you are saying is that I have been struggling all day to fix something that isn’t broken?? 
… 
… 
Sometimes the universe needs something to humor itself
Hi @ScruffR -
Exactly the reason I prefer sticking to PCB design, but always happy to make the universe smile I suppose. Just let me know when you need another laugh, I am sure I can come up with another stupid mistake 
Thanks for the help and thanks @peekay123 for the advice on the library, will test it today. Suppose it is better to learn the Workbench environment in the long run.
Regards, Friedl.
Hi @peekay123 eekay -
Referring to the screen grab attached; I am not seeing a .cpp file in this particular library. Am I being completely stupid now? 
I copied the contents of the PCA9547.h file into the newly created file in the WebIDE already and hit “save”, just don’t know what to do with the .cpp file now? I am receiving errors while compiling so assume I did something wrong… again 
../hal/b5som/pinmap_defines.h:46:13: expected ',' or '...' before numeric constant
Regards, Friedl.
When you look into the header file, you’ll notice that it doesn’t only contain the definition of the PCA9547 class but also the implementation. Hence, no .cpp required.
That error message rather indicates something else, which would require more background.
Probably only a missing semi-colon or something like that.
With Web IDE you can always post a SHARE THIS REVISION link for anybody willing to investigate what may be going on
Hi @ScruffR -
Thanks! I have tried soooo many already without much luck. Got one to work-ish but the publishes were a mess.
Let met revert back to that one, I will save and them use your option of sharing below.
With a little luck someone will assist 
Many thanks, Friedl.
Since I neither have a B5SOM nor any of these expansion boards I could only focus on the build problems you experience tho’ - not the actual readings and publishes.
Hi @ScruffR
All and any help is always greatly appreciated! Here is the link (I think)
Just in case, here is a link to the Github repository as well:
Regards, Friedl.
The problem in that library is that the function setAddress() uses A0, A1 and A2 as parameters, but these are already in use as pin definitions (i.e. #define) and hence trip the compiler.
You can changes these into a0…a2 in the parameter list and implementation and then the build should go through.
You also need to revisit your publishing logic. As is you are running into the rate limit as you are trying to publish six events in one second - the burst limit is four with four seconds cool down.
This should work better
void scanner_2() {
i2cSelect.enable(ch % 4);
char msg[128];
snprintf(msg, sizeof(msg), "set ch <%02X>, cur ch <%02X>, status <%d>", ch % 4, i2cSelect.channel(), i2cSelect.getStatus());
//Serial.println(msg);
Particle.publish("I2C", msg); // ONE instead of SIX publishes ;-)
++ch;
delay(1000);
}
Hi -
Fingers crossed!!
Hi @ScruffR
Getting there, it runs just giving me weird results. Almost 100% certain it has to do with my casting to Strings for publishing. Will look into it now
Have you seen the code in my post above?
With that you can also drop the delay(30000) in your loop() to get your results as fast as possible.
