<div dir="ltr">Hi,<div><br><div class="gmail_extra"><br><div class="gmail_quote">On 6 March 2016 at 15:15, Damon Hart-Davis <span dir="ltr"><<a href="mailto:dhd@exnet.com" target="_blank">dhd@exnet.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On 6 Mar 2016, at 12:49, Jeremy Poulter <<a href="mailto:jeremy@bigjungle.net">jeremy@bigjungle.net</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> I have just started adding the code to support multiple DS18B20 external temperature sensors (see <a href="https://github.com/opentrv/OTRadioLink/pull/44" rel="noreferrer" target="_blank">https://github.com/opentrv/OTRadioLink/pull/44</a>) but I have some queries regarding the sensor API before moving forward.<br>
><br>
> Currently an instance of the TemperatureC16_DS18B20 class is needed for each DS18B20 sensor and at 17 bytes each this could limit the number of sensors that can be used. The API could be changed to pass an address to the read method dropping the memory usage down to 8 bytes (or even 7 bytes as the first byte is always 0x28) per sensor or even just an index that would require no additional bytes per sensor, but probably a little slower to read the sensor. As an aside, I am not sure what determines the order on the bus so there may be a possibility of the sensors being in a different order per read or per power-cycle.<br>
<br>
</span>The order should be consistent by serial number.<br></blockquote><div><br></div><div><br></div><div>Thanks that is good to know.</div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> The obvious down side to changing the API is that you loose the nice consistent API that all the sensors have and will have to start adding a bunch of special cases to read the DS18B20 which I would think is probably not a critical use case so may not warrant polluting the code base, that being said are there other sensors that you may have multiple instances of and thus is it worth changing the base class to support indexed/addressed reads of a single sensor type?<br>
<br>
</span>My view is not, unless we have a very special use case.<br>
<br>
One possibility is to have the DS18B20 implement two interfaces; one for the int16_t sensor for the first instance, the other would be an array of int18_t to get at the whole lot in one go.<br></blockquote><div><br></div><div><br></div><div>That is an idea, how about I add something like;</div><div><br></div><div>int readMultiple(int16_t values[], int index, int count);</div><div><br></div><div>where values is an array to store the results, index is the start index of the sensor, count is the number of elements in values and the return is number of values returned?</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> The other question I have is how important would hot swapping the temp sensors be, or is it ok to expect a power cycle after adding/removing/changing a sensor?<br>
<br>
</span>I think a power cycle is fine.<br>
<br>
Rgds<br>
<br>
Damon<br>
_______________________________________________<br>
OpenTRV-dev mailing list<br>
<a href="mailto:OpenTRV-dev@lists.opentrv.org.uk">OpenTRV-dev@lists.opentrv.org.uk</a><br>
<a href="http://lists.opentrv.org.uk/listinfo/opentrv-dev" rel="noreferrer" target="_blank">http://lists.opentrv.org.uk/listinfo/opentrv-dev</a><br>
</blockquote></div></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">Cheers,</div><div class="gmail_extra"><br></div><div class="gmail_extra">Jeremy</div></div>