Fix _parseCSV() array index bug: lon and ele always returned lat value

[mikeysklar]

Bug found and reported by gadgeteer on the forums.

In _parseCSV(), all three location fields hardcode fields[1], so lon and ele always return the latitude value.

Before (buggy):

_lat = atof(fields[1]);
_lon = atof(fields[1]);  // wrong — always returns lat
_ele = atof(fields[1]);  // wrong — always returns lat

After (fixed):

_lat = atof(fields[1]);
_lon = atof(fields[2]);
_ele = atof(fields[3]);

Also removes the unreachable return true; at the end of the function.

[mikeysklar]

Been testing this and while the code fixes one issue it also crashes from another. So I'll be doing further testing.

[brentru]

@mikeysklar To confirm, does the crash occur when the user tries to run the adafruitio_04_location.ino sketch? What board are you running this sketch on to repro. the crash?

[brentru]

Looks like Huzzah esp8266 feather

Been testing this and while the code fixes one issue it also crashes from another. So I'll be doing further testing.

I'll try to repro.

[ladyada]

fyi, esp8266 need lots of wdt kicks with yield()!

[mikeysklar]

I've seen the crash on two different boards Feather V2 and Qt Py ESP32-S3 using.

adafruitio_04_location.ino

I think it is a missing (but necessary) trailing comma with parse_csv that will resolve it. Testing and will update PR.

[brentru]

@mikeysklar If fixing it keeps causing another bug, please lmk and I can investigate.

[mikeysklar]

End-to-end verified on Feather ESP32 V2 and QT Py ESP32-S3 (with companion PR #181)

Ran the stock examples/adafruitio_04_location sketch with this PR and #181 applied on both an Adafruit Feather ESP32 V2 and an Adafruit QT Py ESP32-S3. Consecutive round-trips through the real AIO broker, every field matching, value incrementing across cycles (no reboot loop), no crash on either board.

Feather ESP32 V2:

----- sending -----
value: 1
lat: 42.321427
lon: -83.025754
ele: 1.00
----- received -----
value: 1
lat: 42.321427
lon: -83.025754
ele: 1.00
----- sending -----
value: 2
lat: 42.311427
lon: -83.005754
ele: 2.00
----- received -----
value: 2
lat: 42.311427
lon: -83.005754
ele: 2.00
----- sending -----
value: 3
lat: 42.301427
lon: -82.985754
ele: 3.00
----- received -----
value: 3
lat: 42.301427
lon: -82.985754
ele: 3.00
----- sending -----
value: 4
lat: 42.291427
lon: -82.965754
ele: 4.00
----- received -----
value: 4
lat: 42.291427
lon: -82.965754
ele: 4.00

Note: on main the S3 was crashing in what looked like the publish path (right after the ele: 0.00 print), but it was actually the same atof(NULL) deref hit via the inbound echo on a tighter timing window — the save() call returns, the MQTT thread delivers the echoed message a few ms later, and _parseCSV() crashes before loop() gets back to its next print. The combined #180 + #181 patches fix both boards.

The two fixes

• Fix _parseCSV() array index bug: lon and ele always returned lat value #180 (this PR) — _parseCSV() was reading fields[1] three times for lat/lon/ele instead of fields[1]/[2]/[3].
• Fix parse_csv() dropping the final CSV field #181 — parse_csv() stopped dropping the final CSV field. Its '\0' case never emitted the accumulated tail into buf, so an N-field CSV came back with NULL in slot N-1.

They mask each other: this PR's index bug kept readers away from fields[N-1], hiding #181's NULL. Landing this PR alone without #181 turns "wrong values" into "null-pointer deref on every receive" (LoadProhibited on ESP32). #181 should land first, then this one.

[mikeysklar]

I can do further testing. I would appreciate if others would confirm these two pull work or if there are any other downstream concerns with these changes.

git clone -b combined-pr180-pr181 https://github.com/mikeysklar/Adafruit_IO_Arduino.git

[brentru]

In my queue to test this morning

[mikeysklar]

Sounds good. Testing went well for myself and forum user gadgeteer yesterday.

[brentru]

@mikeysklar Can you please check out a PR for the combined PR branch instead of having two separate PRs open?

Plz checkout a PR for branch combined-pr180-pr181

Then tag me for review.

[brentru]

Works on ESP8266

[mikeysklar]

Cool. Glad to hear it works. See PR #182 for combined PRs.

[brentru]

Closing in favor of #182