getDeviceCount() returns 0

[vatsake]

Sometimes getDeviceCount() method returns 0 sensors.
If I use the method by parsdc, it gets correct count.

deviceCount=0;
sensors.requestTemperatures();
while (tempC[0] > (-127) ){
  tempC[0] = sensors.getTempCByIndex(deviceCount);
  deviceCount++;
}
deviceCount--;

[PhySix66]

My Solution to the Problem was to rename getDeviceCount(void) to getValidDeviceCount(void) and implement a new getDeviceCount(void) . I've done this simply for tracing down the original problem to the while (_wire->search(deviceAddress)) in begin(void) function. For some reason it simply doesn't work in the begin(void), but outside of it it's OK.
This is not a good(elegant) workaround, but as the meme goes: If it works -> DO NOT TOUCH!

// returns the number of devices found on the bus
uint8_t DallasTemperature::getDeviceCount(void) {
	
	uint8_t dev_cnt = 0;
	DeviceAddress deviceAddress;
	
	while (_wire->search(deviceAddress)) {
		dev_cnt++;
	}
	return dev_cnt;
}

// returns the number of devices found on the bus that are validated via CRC
uint8_t DallasTemperature::getValidDeviceCount(void) {
	return devices;
}

[tdwilson]

I've been having trouble with getDS18count() on NodeMCU returning 0 when called in setup().

I have found five ways to make getDS18count() return the correct number instead of zero (see commented-out lines in code snippet below):

1. The duplicated call to begin() recommended in getDeviceCount still doesn't work with ESP32s (ie, Issue 85 is not really closed) #168 (comment).
2. Adding delay(0) (or any other number I tried) after (!) the call to getDS18count().
3. Changing the printf to use Serial rather than lcd.
4. Turning off optimisation just for the setup() function.
5. In the loop() function of my sketch, when I use getDS18count() to display the temperature of however many of my three (genuine) DS18B20s I have connected, it always gives the correct result.

Hopefully this information will provide some clues, as I'm puzzled about what kind of issue could have such a variety of workarounds, and especially perplexed how changing code after the call to getDS18count() could affect its result! I'm also surprised that changing the optimisation level helps: I looked at the assembly output and the main difference seemed to be whether the n_devices variable was written back to memory or held in a register between the call to getDS18count() and the printf().

// Change to ("O0") [that's a capital letter O followed by zero] to fix getDS18Count()
#pragma GCC optimize ("Os") 
void setup() {
  Serial.begin(74880); // Default for NodeMCU
  delay(100);
  
  lcd.init();
  lcd.clear();         // Sets cursor to 0, 0
  lcd.backlight();     // Make sure backlight is on
  lcd.print("Starting");
  
  sensors.begin();     // Re-enumerates the bus.       
  // sensors.begin();  // Fixes getDS18Count()     
  uint8_t n_devices = sensors.getDS18Count();
  // delay(0);         // Fixes getDS18Count()
  lcd.setCursor(0, 1);
  lcd.printf("%hhu/%d devs", n_devices, MAX_SENSORS);
  // Serial.printf("%hhu/%d devs", n_devices, MAX_SENSORS);  // Fixes getDS18Count()
  delay(1000);
}
#pragma GCC optimize ("Os") 

[milesburton]

Thanks chaps. Let me investigate

[PhySix66]

Adding delay(0) (or any other number I tried) after (!) the call to getDS18count().

This is most bizzar... getDS18count() is basicly a return(value) and it needs a call for delay() to work? (Not tested my self)
Just a thought: Can it be, that it has to do with the dual-core nature of the ESP32-S3?
Like Core 0 starts (or is in the process) of getting the data, while Core 1 already starts to do stuff with the unobtained data?
(Like drinking a glass of water, before puring it in the glass)

[milesburton]

My friend believes it could be a memory consistency issue. Hopefully he doesn't mind me sharing this email:

2. Adding delay(0) (or any other number I tried) after (!) the call to getDS18count().
3. Changing the printf to use Serial rather than lcd.

make it sound like memory consistency issues, which doesn't make sense for such a microcontroller. I don't have access to an lx106 compiler to check the assembly.

I thought it was a race condition but I don't have an IC to test at the moment. PR #259 could be our answer but could someone test it out for us?

[tdwilson]

Hi Miles, If there is any way I can help (eg send you the complete code I am using with my ESP8266 / NodeMCU 1.0), please let me know. Kind regards, Tim

…

On Sat, 4 Jan 2025 at 12:10, Miles Burton ***@***.***> wrote: Thanks chaps. Let me investigate — Reply to this email directly, view it on GitHub <#257 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABE6CIHPNCL2CJWMABRUV432I7FS5AVCNFSM6AAAAABSWQ7AYKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNZRGI3DSNZXGA> . You are receiving this because you commented.Message ID: <milesburton/Arduino-Temperature-Control-Library/issues/257/2571269770@ github.com>

[milesburton]

Hi Miles, If there is any way I can help (eg send you the complete code I am using with my ESP8266 / NodeMCU 1.0), please let me know. Kind regards, Tim
…
On Sat, 4 Jan 2025 at 12:10, Miles Burton @.***> wrote: Thanks chaps. Let me investigate — Reply to this email directly, view it on GitHub <#257 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABE6CIHPNCL2CJWMABRUV432I7FS5AVCNFSM6AAAAABSWQ7AYKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNZRGI3DSNZXGA . You are receiving this because you commented.Message ID: </issues/257/2571269770@ github.com>

Hey Tim, that's very kind of you. Let me get PR #259 passing and if you could run that on your device and give it a sanity check that'd be awesome.

[milesburton]

Just a quick update I've raised a new PR here: #264. There's an issue with the unit tests that I need to explore

[milesburton]

Just to quote Tim who emailed me directly: "Hi Miles,
I've just tried the current race-condition branch ("version 4.01") on my NodeMCU v2 and getDS18count() works the first time my sketch calls it without any work-arounds.
Thank you!
Tim"

With this in mind I'm going to merge the PR and close this issue