Compilation problems

Hi Matt

I still have some peculiarities. My target platform is Wemos D1 mini. When I look at the overview of the libraries, a number are crossed out. I did add the path to those libraries. Some compilation problems might relate to that.

I added a screenshot and my code. The code compiles with the Arduino IDE but not with your's Could you enlighten me on what my mistakes are?

Attachments: 

Comments

The crosses just mean those

The crosses just mean those libraries haven't yet been compiled.

I can't find the "MQTT" class anywhere. What library is that defined in?

Ta.

Ta.

The only problem I see is with system_phy_set_max_tpw(txPower);, and you shouldn't be using that anyway. You should be using WiFi.setOutputPower(txPower); instead - where txPower is the power in dBm (0 to 20.5)

It looks like you have a

It looks like you have a rogue SD library tucked away somewhere. Right click on the SD library in the tree and select "Recompile Now". the status tab should show you where the library is that it's picked.


if (topicPub != "eltraco/hb") FLprint = true;

That's not how you compare strings in C. You need to use:

if (strcmp(topicPub, "eltraco/hb") != 0) FLprint = true

FLwifiReset == true;

That does nothing. It compares the values and throws the result away. I think you wanted FLwifiReset = true;


static const char *MQTTclientId = ClientName;

You're defining and assigning that variable, but not using it for anything. If you really want it to be there, then mark it as unused:

static const char __attribute__((unused)) *MQTTclientId = ClientName;

  sprintf(text, "%i,%i,%i,%i,%i,%i,%i,%i,%i,%i,%s,%s,%i",
          CfGen.IdHcntr[0], CfGen.IdHcntr[1], CfGen.IdHcntr[2], CfGen.IdHcntr[3], CfGen.IdHcntr[4], CfGen.trp[0], CfGen.trp[1],
          CfGen.trp[2], CfGen.trp[3], CfGen.decoderNr, CfGen.SSID, CfGen.pwd, CfGen.debug);

You are accessing CfGen.IdHcntr[4], yet CfGen is defined as:

struct sConfig {
  byte IdHcntr[4] = {0, 1, 2, 3};
  byte decoderNr = 0;
  byte trp[4] = {192, 168, 2, 1};
  char SSID[15] = "ELP";
  char pwd[15] = "1pkwdrt8";
  boolean debug = true;
};
sConfig CfGen;

That means you can use CfGen.IdHcntr[0] through CfGen.IdHcntr[3]. Not CfGen.IdHcntr[4]. There is no CfGen.IdHcntr[4].


byte ConvertByte(char a) {
    byte m;
    String b = String(a);
    if (b == "F") m = 15;
    else if (b == "E") m = 14;
    else if (b == "D") m = 13;
    else if (b == "C") m = 12;
    else if (b == "B") m = 11;
    else if (b == "A") m = 10;
    else if (b == "9") m = 9;
    else if (b == "8") m = 8;
    else if (b == "7") m = 7;
    else if (b == "6") m = 6;
    else if (b == "5") m = 5;
    else if (b == "4") m = 4;
    else if (b == "3") m = 3;
    else if (b == "2") m = 2;
    else if (b == "1") m = 1;
    else if (b == "0") m = 0;
    return m;
}

If b is anything other than 0-9/A-E then what is m? It has no known value - so it complains. You should initialize m to have some default value. It may well be the case that b can never be anything other than those 16 values - but the compiler doesn't know that.

byte m = 0;

char ConvertHexa(byte b) {
  char m;
  switch (b) {
    case 0 ... 9:
      m = char(48 + b);
      break;
    case 10 ... 15:
      m = char(55 + b);
      break;
  }
  return m;
}

The same goes here. If b isn't one of those specific values then m is undefined.


So you can see all the mistakes in your program that the Arduino IDE hid from you. Mistakes that would have had you scratching your head for weeks (or months) and getting more and more exasperated, and eventually throwing the whole lot in the bin. But UECIDE tells you about them so you can find your mistakes and correct them.

I also notice that the

I also notice that the PubSubClient library you are using is riddled with problems as well. I'll be nice and fix them for the author...

Ok - I have fixed

Ok - I have fixed PubSubClient and made a pull request to the upstream repository. Here's my clean copy. I haven't tested it to see if I broke anything (I doubt I did), so I'll leave it to you to verify.

Attachments: 

Salut,

Salut,

is it possible that you are looking at an old version of the library? In the Changes file it gost up to version 1.9, but the official site shows 2.7 - I got my PubSubClient from here: https://pubsubclient.knolleary.net/

Ciao, Mathias

The problem is I think there

The problem is I think there are two completely separate libraries both imaginatively called "PubSubClient". And they both work in completely different ways.

Thank you very much!!!!!

Thank you very much!!!!!

If somebody might hesitate to move from the Arduino Ide to UECIDE this shows reason enough to make the switch!!!

I followed your directions

I followed your directions and changed the code accordingly. After installing a different SD library that library compiled nicely also.
But after uploading the software the serial monitor was not accessible.
Error: Port name - /dev/cu.usbserial-14220; Method name - openPort(); Exception type - port busy
How do I solve this last hick-up?

The ESP8266 core comes with

The ESP8266 core comes with the SD library. It is possible that you had one installed elsewhere that was overriding the built in one. Removing the old one should have allowed the official one to work.

I'm not sure how port locking works on OS X. The only locking that the IDE performs is on Linux using POSIX compatible /var/lock files. It does nothing on OS X or Windows. Not being an OS X user I can't easily test these things out properly. I have a VM of High Sierra, but it's slow, flickery, and an absolute pain to use - so I don't unless I really have to. Any "locking" that is done to the port will be by esptool. Either that or it's just plain lying and it's not locked - just the serial terminal thinks it is. Which is a distinct possibility.

I'd suggest trying a different serial terminal program to test with (no clue what would be available on OS X...) to see if the port is actually locked, or if it's just the serial terminal that thinks it is.