Initially found addresses lost

[blah188]

Got a situation. Libarary sees sensors during 1st seach (in begin) but addresses not stored. Subsequental searches may fail on some configs (long wires, weak bus, etc, I encountered it personal). And here is no way to get those found addresses and use it directly (direct access by addresses work better than search!). Can you add feature in ::begin() to store addresses? I can code it myself if you accept pull requests, don't want to fork...

[milesburton]

Morning, we are always open to PRs. I’m just away from home but I can review it when I’m back home

…

On Fri, 26 Jun 2026 at 11:30, blah188 ***@***.***> wrote: *blah188* created an issue (milesburton/Arduino-Temperature-Control-Library#291) <#291> Got a situation. Libarary sees sensors during 1st seach (in begin) but addresses not stored. Subsequental searches may fail on some configs (long wires, weak bus, etc, I encountered it personal). And here is no way to get those found addresses and use it directly (direct access by addresses work better than search!). Can you add feature in ::begin() to store addresses? I can code it myself if you accept pull requests, don't want to fork... — Reply to this email directly, view it on GitHub <#291?email_source=notifications&email_token=AAJGHM7KVMJ2ELK22RB5WHL5BZGDDA5CNFSL4Z3JMQ5C6L3HNF2C22DVMIXUS43TOVSS6NBXGUYTENRTGI3TTJTSMVQXG33OVJZXKYTTMNZGSYTFMSSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJGHMZNEPMTYTVLJZWBH735BZGDDAVCNFSNUABDKJSXA33TNF2G64TZHM2DEMJXGU3TMO2JONZXKZJ3GQ3TKMJSGYZTENZZUF3AE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** com>

[RobTillaart]

@blah188

And here is no way to get those found addresses and use it directly (direct access by addresses work better than search!).

One can obtain all addresses by getAddress(uint8_t *, uint8_t),
Although this is not efficient, you only need to do this once at startup.
Advantage is that after a call to begin() you know how much devices there are,
and thus know how much memory you need to allocate for your "address book".

Can you tell us more about how this new functionality should work?
Do the changes break existing API and thus existing projects?

---

(some thoughts popped up, as I like the idea but no not oversee all consequences yet)

Is it your idea that begin() gets another signature int begin(uint8_t * addressBook = nullptr)?

• does not break existing code, except for time used for the copying of the addresses found
• begin() returns the amount of devices found (good idea anyway)
• begin() fills the addressBook with all addresses it found, unless addresBook == nullptr.
  User is responsible for allocating enough memory for the addressBook.
  Should not be a problem as the user knows the hardware setup.
  The ACTL could keep the pointer to the addressBook for fast lookup iso search.

[blah188]

Yes, i use getAddress(...) but in my setup second wire search fails (while if I supply addresses, temerature calls work).
If I had program library from scratch, I would probably save addresses in begin() for future usage, so access by index become straightforward.
But it is written already, so I beleve int begin(uint8_t * addressBook = nullptr) is acceptable. May be also wise to accept buffer length: int begin(uint8_t * addressBook = nullptr, uint8_t bufferSizeInBytes = 0) or begin(uint8_t * addressBook = nullptr, uint8_t maxDeviceCount = 0) as theoretically setup can be changed and device crashes unexpectedly.

[RobTillaart]

Yes, i use getAddress(...) but in my setup second wire search fails

That is strange, any idea why that happens?
Can you post an minimal example that shows the problem?
Sounds like this is the problem you want to solve

If I had program library from scratch, I would probably save addresses in begin() for future usage, so access by index become straightforward.

That implies that the begin() function has manage the memory needed for the addressBook. Possible, not trivial.
Having the addresses available would indeed improve access time.
I am interested to see your PR coming.

BTW, it is always possible to write a new library to meet your specific needs, in fact I wrote two for simple, single DS18B20 configurations.

as theoretically setup can be changed and device crashes unexpectedly.

maxDeviceCount won't work (well) in practice, you might end up with a mix of devices for which you have the address and for some you don't.

Thinking out loud there are several strategies to cope with that.

• make a linked list of addresses
• or if the storage is too small, fail so the user is informed the addresses found did not fit the available space
  (e.g. deviceCount = -12, negative to indicate fail and 12 to inform how many found.)

[blah188]

Well I almost decided to write own lib based on your code :) I was too lazy before but Claude changes things... Anyway I wrote alot of libs for self usage (logging, arrays, task management) and can use it. So probably this topic can be closed. I still may decide to make PR though for your review.... The problem is I never did it on github yet, but don't think it's too hard.

[blah188]

Hmm, well it didn't take long. PR is ready, feel free to review :)