Compiler error when using Xenon

[shanevanj]

Error unsupported with Xenon and Ethernet Wing

[barakwei]

I don't have a Xenon device, but anyway, more information is needed.

[shanevanj]

There is not much more to say...Plug a Xenon into an ethernet wing, claim it on particle, open web IDE and search for Papertrail library and select the example given. Use the example and compile - shows error unsupported platform. I edited the library .cpp file in my ignorance and removed the check and tried again. This resulted in a semi-bricked Xenon that took some time to recover. I subsequently loaded the Loggly example from your sister company and it worked. It is a pity since particle refer to your library in their documentation yet it clearly doesn't work.

[barakwei]

Use the example and compile - shows error unsupported platform.

If you could point me to the exact line that failed to compile, I might be able to help you.

[shanevanj]

This first error is due to the #include statement using "" instead or <> around the file name

The second error is when you compile again. Simply removing the check in the .cpp file caused an error on my Xenon that required a CLI intervention to reload the device OS.

[barakwei]

OK, the problem is here https://github.com/barakwei/ParticlePapertrail/blob/master/src/papertrail.cpp#L13-L21

Notice that the library doesn't support anything other than WiFi or Cellular. I have no problem supporting ethernet as well, but I couldn't find an official API to resolve addresses (https://docs.particle.io/reference/device-os/firmware/xenon/#ethernet).

When I look in the FW code it seems that Ethernet.resolve is usable, so this may work after all.

Can you please check in a sample app if Ethernet.resolve("www.google.com") actually complies and return a valid address?

If so, you can take the header file and the cpp file of this library and change the above method so it would work by adding

#elif Wiring_Cellular
    return Cellular.resolve(host);
#elif Wiring_Ethernet
    return Ethernet.resolve(host);
#else 

If this works, I'll update the library with the change.

[shanevanj]

So if I use Ethernet.resolve("www.google.com") in a new app - it resolves

**** Port Open
Ready...
216.58.223.36

void setup() {
Serial.begin(9600);
waitFor(Serial.isConnected, 10000);
Serial.println("Ready...");
}
void loop() {
Serial.println(Ethernet.resolve("www.google.com"));
delay(5000);
}

If I change the .cpp to :

#if Wiring_WiFi
return WiFi.resolve(host);
#elif Wiring_Cellular
return Cellular.resolve(host);
#else
return Ethernet.resolve(host);
#endif
}

and compile and flash - it bricks the Xenon - (green light fast flashing) and will not connect to cloud - I then have to put into DFU mode, and use CLI to "particle flash --usb tinker" and restore tinker app and only then will it reconnect back to the cloud

Shared link to the web IDE app example

[barakwei]

OK, it's good to see it can resolve. I'm willing to release a new version just for this change.

The reason for the device getting bricked will be hard to detect without a device, so I would start by trying to sending logs manually by using lazy_init and log methods. If this works, then maybe you're logging to early or something using the built-in logger.

If you're manually sending logs and still getting stuck then you might need to debug more using serial and see when the device gets bricked.

[shanevanj]

So I am using the example in the the library and after it is flashed to the device, the device normally restarts and connects to local ethernet and then to the particle cloud (colour sequence being slow green flash, fast green flash and then cyan flash and the cyan breathing) - in this instance when using the example, it goes from slow green flash to fast green flash and then will not continue - so user level app is not even being loaded as its still in the DeviceOS connection phase - only way out is a DFU refresh.

I will experiment more this week end und let you know what I can find.

[barakwei]

The problem with the example is that it sends messages very early in the boot phase and this might be a problem. Try declaring and initializing the logger later (say in the loop() method).

[shanevanj]

The issue appears when the class is instantiated - with an empty Setup() and Loop()

`#include "papertrail.h"

// TODO: Change the host and ports to match yours.
PapertrailLogHandler papertailHandler("logsX.papertrailapp.com", 12345, "PapertrailSimpleDemo");

int i = 0;

void setup() {
// waitUntil(Particle.connected);
// waitFor(Serial.isConnected, 10000);
// Serial.println("\nLogging test");
// Log.info("Log.info");
}

void loop() {
// Serial.println(Ethernet.resolve("www.google.com"));
// Log.info("Log.info");
// delay(5000);
}`

[barakwei]

If the initialization is in loop does it work? If so I'll add ethernet support. Next, I would open an issue on the FW, and see what they have to say.

[shanevanj]

This does not brick now - the serial messages are sent out ok. No events appear in my papertrail event log though.

`
#include "papertrail.h"

int i = 0;

void setup() {
PapertrailLogHandler papertailHandler("logs.papertrailapp.com", 43081, "PapertrailSimpleDemo");
}

void loop() {
Serial.printf("\nLog message #%d", ++i);
Log.info("Log message #%d", i);
Log.warn("This is warning message");
Log.error("This is error message");
delay(5000);
}
`

[barakwei]

You're not using it right. Move the init line to the loop method.

[shanevanj]

Then it lock up and the serial output stops - it doesn't brick though, but you have to put xenon in safe mode to re-flash again (even though its breathing cyan)

`
#include "papertrail.h"

int i = 0;

void setup() {
waitUntil(Particle.connected);
waitFor(Serial.isConnected, 30000);
}

void loop() {

PapertrailLogHandler papertailHandler("logs.papertrailapp.com", 43081, "PapertrailSimpleDemo");
Serial.printf("\nLog message #%d", ++i);
Log.info("Log message #%d", i);
Log.warn("This is warning message");
Log.error("This is error message");
delay(5000);

}

`

[JumpMaster]

I recently ran into this issue. The Xenon devices do not support direct TCP/UDP so options like logging via PaperTrail or connecting to an MQTT server are not possible.

The Xenon should use Mesh.publish to push the request to the router which can send the data out to the wider world.

[shanevanj]

Except when the xenon is plugged into an ethernet wing it does have TCP and can publish to MQTT, but paper trail is still broken. Regards Shane +27826010499

…

On 06 Dec 2019, at 3:59 PM, Kevin Cooper ***@***.***> wrote:  I recently ran into this issue. The Xenon devices do not support direct TCP/UDP so options like logging via PaperTrail or connecting to an MQTT server are not possible. The Xenon should use Mesh.publish to push the request to the router which can send the data out to the wider world. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.