Thanks both, Im happy with my solution above for now and will keep an eye on reliability issues from it’s use.
The other option on the EmonTx4 is to offload the temperature sensing to an ESP8266 expander board. Il try and put together an example of how to do this.
We are also bringing out the emonPi2 in a few months time (I need to do a forum post on this), temperature sensing is handled by the RaspberryPi on the emonPi2. If someone does have a lot of trouble with temperature sensing reliability using the EmonTx4 with DS18B20 temperature sensors bought through the shop and for whatever reason I’m not able to work out a satisfactory solution, we would offer a replacement with an emonPi2 when it’s available.
If there are reliability issues with DS18B20 temperature sensors bought elsewhere, I know we’ve had issues with different timings on clones etc already and I can’t guarantee that the above will work for all devices.
Looking through the schematics, I’ve got a potential solution to suggest / discuss that I think is worth considering. I’d have thought that the AVR should be capable of dealing with all these sensors fine, it’s just needing to disable interrupts to bit-bang that’s an issue which could be avoided if one used a hardware interface instead. Whist the AVR doesn’t have a 1-wire IP block, it does have I2C and you can utilise a DS2484 to provide a hardware 1-wire implementation bridged to I2C. This means your access to 1-wire devices only requires register read/writes to the I2C interface that can occur with interrupts enabled.
FYI it’s a SOT23 footprint and adds around £1 to the BOM cost. I also think that as it’s a proper line driver it would also help with being able to extend 1-wire sensors / networks much further away from the board.
Looking at the practicalities, on the current schematic, the AVR pins 46 & 47 (PA2 and PA3) are currently unused and can be muxed to I2C master which allows this to be tested with minimal design impact. If you’re planning a re-spin sometime soon, could I propose breaking out these pins an additional two pins extending the “analog expander” header which could be non-pop as standard so as to not interfere with anything in use / production, but would allow for designing compatible variants of the current 6 CT expansion that could also utilise hardware driven 1-wire or any other I2C based expansion / hacking? (If doing so, ideally one would put the two I2C pullups on the main-board too)
There’s also a variant called the DS2484-800 which provides 8 individual 1-wire lines which can be used independently. That would mean that you could utilise one sensor per line so that individual device addresses become irrelevant which might be of interest?
Personally I like the idea of keeping stuff on the AVR as having cheap(er) sensors on RF in different physical locations offers more flexibility (and works well for my own needs!) but also adding another microprocessor purely for something simple like this feels a bit like overkill both cost and complexity wise?