In all honesty, I am not sure if this has to do with NonBlockingDallas, or one of the overarching libraries.
Using the code, it appears that DS18B20's are scanned for with .begin(), and only devices that are present at .begin() are returned. The use case I am interested in is that the DS18B20 devices may have faulty cabling and may not be physically connected all the time. It appears that if a DS18B20 is there when .begin() is run, then the device will be detected when it re-appears.
It does not appear that any new sensors that are attached are reported by the library. I did consider running .begin() periodically, but it appears to be a blocking function, even including a delay(50).
In all honesty, having a sensor needing to be present at start up is not a big issue, but it is something that in an ideal work I would fix. Thanks
In all honesty, I am not sure if this has to do with NonBlockingDallas, or one of the overarching libraries.
Using the code, it appears that DS18B20's are scanned for with .begin(), and only devices that are present at .begin() are returned. The use case I am interested in is that the DS18B20 devices may have faulty cabling and may not be physically connected all the time. It appears that if a DS18B20 is there when .begin() is run, then the device will be detected when it re-appears.
It does not appear that any new sensors that are attached are reported by the library. I did consider running .begin() periodically, but it appears to be a blocking function, even including a delay(50).
In all honesty, having a sensor needing to be present at start up is not a big issue, but it is something that in an ideal work I would fix. Thanks