Adafruit_seesaw.h breaks when using IOT Cloud

There is a problem as soon as one uses Adafruit_seesaw.h with Arduino code generated by the Arduino IOT Cloud which includes:
#include <ArduinoIoTCloud.h>
#include <Arduino_ConnectionHandler.h>

Here is my code:
Main Code:
#include "arduino_secrets.h"
#include "thingProperties.h"
#include "Adafruit_seesaw.h"
Adafruit_seesaw ss;
void setup() {
Serial.println("seesaw Soil Sensor example!");
if (!ss.begin(0x36)) {
Serial.println("ERROR! seesaw not found");
} else {
Serial.print("seesaw started! version: ");
Serial.println(ss.getVersion(), HEX);
void loop() {
float tempC = ss.getTemp();
uint16_t capread = ss.touchRead(0);
int moist = map(capread, 338, 570, 0, 100);
Serial.print("seesaw started! version: ");
Serial.println(ss.getVersion(), HEX);
Serial.print("Temperature: "); Serial.print(tempC); Serial.println("*C");
Serial.print("Capacitive: "); Serial.println(capread);
Serial.print("Moist: "); Serial.println(moist);

// Code generated by Arduino IoT Cloud, DO NOT EDIT.
#include <ArduinoIoTCloud.h>
#include <Arduino_ConnectionHandler.h>
const char THING_ID = "d0d57085-4094-465b-9743-2d2a320e1396";
const char SSID = SECRET_SSID; // Network SSID (name)
const char PASS = SECRET_PASS; // Network password (use for WPA, or use as key for WEP)
int pallas_Ping;
float pallas_i2c_Temp;
int pallas_ic2_Moisture;
void initProperties(){
ArduinoCloud.addProperty(pallas_Ping, READ, ON_CHANGE, NULL);
ArduinoCloud.addProperty(pallas_i2c_Temp, READ, ON_CHANGE, NULL);
ArduinoCloud.addProperty(pallas_ic2_Moisture, READ, ON_CHANGE, NULL);

WiFiConnectionHandler ArduinoIoTPreferredConnection(SSID, PASS);

The correct output is when the line "ArduinoCloud.begin(ArduinoIoTPreferredConnection);" is commented out and is:
23:30:26.618 -> seesaw started! version: FBA278F
23:30:26.618 -> Temperature: 26.17*C
23:30:26.618 -> Capacitive: 346
23:30:26.618 -> Moist: 3

As soon as this line is enabled the output becomes:
23:36:37.945 -> seesaw started! version: 19000000
23:36:37.945 -> Temperature: 25.64*C
23:36:37.945 -> Capacitive: 65535
23:36:37.945 -> Moist: 28102

Which Arduino board are you using?

I see that I2C is used for the communication between the Arduino board and the seesaw hardware. I2C is also often used by IoT Cloud compatible Arduino boards for the communication with the ATECC508 crypto authentication chip.

In theory, the seesaw and ATECC508 should be able to share the I2C bus just fine, but this sort of expectation is not always borne out in reality.

Thanks for the response.

MKR 1010 with latest drivers. I am using the i2c connection and have tried both MKR Carrier Connector and MKR IoT Carrier both with the same results.

The MKR WiFi 1010 does have an ATECC508 connected to the I2C bus, and that chip is used for authentication by Arduino IoT Cloud Thing sketches.

Unfortunately, I don't have a good idea of what the specific problem or solution could be, but I thought that I'd at least share my thoughts on the issue in case that will be helpful in the investigation.

1 Like

Do Arduino as an organisation ever get involved with these requests or is there another specific way to apply for support? These are products and services that we are paying for after all.

Found this post after Googling for the same behavior (using a Nano IoT 33). I have a scope so I'll look at the I2C bus when I have a bit of time.

Just a brief look but some weirdness on I2C when ArduinoCloud.begin() is used. It starts out Ok - a couple of [0x60, 0x04, 0x11, 0x33, 0x43] packets (for the ECCX08 crypto chip) but then some clock inconsistencies and the next message gets stuck in an address write for 2ms, which messes with my protocol decoder. I removed my seesaw device and commented out the library, just in case there was an interaction or termination issue, but the 'problem' was still there (WiFi works, btw).

When I added my seesaw device back, there was no sign of its own communication. Seesaw works fine on its own.

It could be a driver problem with the WiFi interface but I'm looking at a couple of other possibilities. TWI might being used - it's is very similar to I2C but with some differences which, I believe, means you can't run both on the same line. Also, the Arduino ECCX08 library makes mention of CRYPTO_WIRE (ArduinoECCX08/ECCX08.cpp at master · arduino-libraries/ArduinoECCX08 · GitHub). Not sure what this is yet - something just to mess with anyone trying to hack crypto communications maybe?

1 Like

Well I worked around the problem by configuring a second I2C bus. This should work for a MKR1000: (slight change here for my Nano: Second I2C Interface).

1 Like

Exactly, that was the sort of behaviour I was seeing. A few good messages and then garbage.

Thanks for the help dazwin. I will let you know what my setup looks like. I have looked into the two links that you provided. I am just not sure my "techie" force extends that far. I am sure we will find a solution. I will update you on the structure I am using in full as soon as I can (next few days).