Wanted: emonTH 2 sketch that handles many external ds1820Bs - I'll pay for it!

Hi guys
It would be great at create a new Sketch and put in Github: that handles many ds1820Bs on the latest V2 emonTH.
Or at least - because want to use an emonTH to measure many temperatures, then other people may well want to, also!

There are sketches for V1 to do that - but not for V2.

I have not looked at the sketches, and wouldn’t understand the code much anyway - so maybe it is a trivial task for someone who knows the existing sketches, to create a V2 one from V1 examples. Or maybe it is tricky… hence I’m willing to pay!

These are the V1 sketches I’m refering to.

Many thanks for any offers of help!

PS - maybe some one will prove i’m a wally, by saying that that old V1 sketch will run out of the box on V2 hardware anyway!!

PPS - the above sketch is not ideal in that it seems the ID’s in emonCMS of the sensors will change if sensors are added or removed…

It would be nice if the new sketch could maintain sensor hardware-Id match to emonCMS ID, no matter what other sensors changed.

Otherwise it’s a lot of fiddly work needed:
a) emonCMS graphs will all need to be changed and /or feeds recreated.

b) the pain of working out which sensor matches each ID… would have to heat each sensor one by one, watch for the Feed that changes… and then rename… phew

1 Like

You can’t have a “universal” sketch that will always maintain the sensors in order, and in the same slots. The reason is the way the sensors are searched for, explained in ‘Learn’. Therefore, your sketch must be customised with the serial numbers of your temperature sensors so that they can always be allocated the same positions in the data that’s sent to emonCMS.
So you need two sketches. The first, to determine the serial numbers, already exists for the emonTx, so that’s easy. The second, to run on your emonTH2, needs to have the pre-programmed serial numbers code from an emonTx V2 sketch merged into the ‘standard’ emonTH2 sketch.

How many sensors do you need?

Thanks for the very fast response!

> How many sensors do you need?
Our Underfloor manifolds have up to 12 actuators -so add a couple for the main feed and return - 14 sensors.

> You can’t have a “universal” sketch that will always maintain the sensors in order.

Is that because the emonTH has no SD card or any other non-volatile memory… so can’t save the mapping used last time of hardware_ID to ID as passed to emonPi?

So unless there’s a hardware way to add a memory chip… Have you ever heard of anyone doing that? It would anyway take more battery power… although with 14 sensors it;l take more juice, so I guess we’d want a PSU and not battery anyway?

> So you need two sketches

I guess so long as the ‘usability’ is made as easy as possible… that would be liveable with. Eg if the ‘finding’ sketch saved a copy of what it found to a PC, then next time it was run it could ensure to reuse the mappings for any sensors that were found the time before: so no need to physically heat each sensor one by one to work out which sensor is which!

And actually in our case: we’d set up the 14 sensors once and then leave the emonTH in the manifold box, with a mains PSU, and never touch it again! so the sensors would not be changing anyway.

Thanks again for your help!

PS Don’t know your other time committments, but if you were willing to take on this task for us, would you be looking at fitting it in within a week; or two or ?

The ATMega 328P does have EEPROM memory - but the problem is the second time around. It would be easy to search for the sensors at initial power-up, then forever use those. But what happens if one goes faulty and you replace it? You then need a mechanism to replace the serial number of the sick one with the new, or you rescan all the sensors and then you have the problem in emonCMS again. Whichever way you go, at a minimum you will need to connect a programmer to be able to implement a change. The real issue as I see it is usability.

With 14 sensors, you need to check up on the wiring requirements. Would they all be grouped together or widely distributed? If the sensors are grouped and the wires are short, they can be connected in ‘star’. Otherwise, they must be wired on a bus, paying attention to the length of any stubs, and to the terminations, so that you don’t get reflections corrupting the data. If the bus is long, as a result of winding around a house, you might need one of the specialist driver chips to interface the bus to the ATMega 328P.

And yes, the power requirement is somewhat greater, but it depends on the frequency of the measurements too, of course. We turn on the power to the bus, instruct all the sensors to read, then poll each in turn to get the result, so the bus needs to be powered for longer.

I take it that asking for my commitments is a request to write a sketch? Along with moderating here and staying alive etc, I won’t make any sort of promise. Doing it the simple way would be fairly easy. But for anything more, a week is a non-starter. If you need one sketch that’s interactive via a programmer, I can see it taking more like a month or two, because I have a nasty feeling it could get very complicated.

I’m about to send you an important PM.

If you are planning on sealing the emonTH away with the manifold, I’m guessing the on-board temp and humidity sensors are going to be redundant, and if you are powering by 5vdc rather than batteries, you could just get a RPi Zero WiFi and use that to read the ds18b20’s

That way you can ssh in and alter the temp sensors as required. Once you have id’d (and labelled) each one by connecting one at a time or by warming each one in turn, you can use a simple python script and use friendly named variables to ref the sensors,

A RPI Zero WiFi, SD card, case and power supply will cost less than an emonTH, I wouldn’t normally recommend this route as the emonTH can be more “plug and play” but since you are having to make so many changes this maybe easier.

> It would be easy to search for the sensors at initial power-up, then forever use those. But what happens if one goes faulty and you replace it?

How about this:

  • sensors found are matched against the known list:
  • new ones get allocated new emonCMS Ids
  • expected ones that no longer show up: fine, no data for those get sent to emonCMS

Maybe I;m not understanding the full picture?

> If you need one sketch that’s interactive via a programmer, …

Ideally, the sketch is such that the user doesn’t need any interactivity:just install the standard sketch and power up.

the existing sketch I linked to above is already like that. So just add in the code to save the found sensors in python Tuples or etc: with the abiltity as above on each battery restart, to handle new sensors.

not a bad idea. Although complicates the system and the amount of brain power to understand it in the future: t have different types of hardware and firmware in the one system.
See my suggestion above: if that is feasible then it removes all the manual faffung around f finding IDs and recording them.
Plug and play!
to keep the system as above, it’d be worth paying more to use emonTHs. And anyway it wuld be cheaper if we wanted to leave some ‘spares’ with the system agaunst any emonTHs dying over time: 1 spare emonTH would be enough. But adding and RPIZero means we’d need also a spare for that too.

They would all be within a single box of 50x50x20 cms.
So star wiring would work.
I bought an ethernet 4-way thing in the shop here… would need a 14 way version: or just solder 4 sensors per ethernet plug, to get 16 wired.

Interesting project, I don’t have an emonTH to play with but the code looks simple enough.

Will you be using a single emonTH transmitting to the emonBASE/PI or multiple 14 sensor emonTH units?

Will a single ATMEGA pin (5) driving the voltage/power to 14 sensors cope with the current?

if you want you could use something based on my sketch for the ESP

it works fine you can unplug and plug in sensors add more sensors while it running and on it next loop it will find then and broadcast the temps from the new sensor… it currently set up to handle 20 sensors but you can add more . the only reason it limited to 20 is when you first start it it broad cast all connected sensor address to be displayed so you can make a topic for them…

1 Like

Or your 4 way thingy to 4 other 4 way thingies gives you 16. Haven’t looked at the 4 way connectors but can’t see why that shouldn’t work.

I wouldn’t worry about sensors failing - they’ll probably last longer than you and you could have moved before they die. If they do die it’s a quick job to replace the one that died and then make the link in the emoncms system to replace the one that died with the new one. You might have to re-configure things but that’s a lot less hassle than managing the code to allocate unique ids to inputs.

My experience is that every time there is a power fail the sensors always return to their original position in the reporting sequence. In fact some time ago Robert wrote a bit about how each sensor works out where it is in the sequence of reporting. Something to do with the unique id each of the sensors is pre-programmed with. So I’m guessing any replacement sensor would end up at the end unless it’s come from old stock.

So I’d keep it simple use one of the stock programs, work out which sensor is which (hot cup of tea or coffee essential for this step) then set up emoncms based on this knowledge and if a sensor fails re-configure the system. The alternative would just be too complex and time consuming.


No they wouldn’t - read what I wrote. Essentially, the serial number is read backwards! But you’re right about the order while nothing changes, although it appears random, it isn’t.

My principal concern would be the connectors. If you’re worried about failures, that’s where they will be. Soldered connections would be many times more reliable. For 14 sensors, I’d be inclined to get a strip of Veroboard or similar, a handful of pins, and solder the sensor wires to the pins.

If my ASCII art is any good, something like

===O========O========O========== Power
=====O========O========O======== 1-wire
=======O========O========O====== Gnd
    Sensor 1      Sensor 2      Sensor 3

Sorry Robert - I didn’t have your analysis to hand. We need that tutorial automatically added to any discussion on DS18b20s…

I think we’re agreed though once they’ve started responding they stay in the same order until one fails or is replaced.

I think your idea of a purpose built soldered veroboard solution would be more reliable than all those plugs and sockets - but as always it’s a trade off against the expected life time of all of the constituent parts.

Might be interesting to know what the MTBF on the sensors is. Anyone know without someone diving into the spec sheets?


[Here’s the link: Learn | OpenEnergyMonitor - RW]

Just checked and there is a report from 2005 that the MTTF is over 25000 years. There aren’t many experts on failure rates and I’m not one of them but worrying about the failure of one of these sensors has to be counterproductive to say the least!


I have been using DS18B20 sensors for over 5 years. Some of the original ones I started with are still working fine, but many are not. The failures I have seen are related to corrosion and mechanical failure of solder joints and/or device leads. If you have them in a dry location you will get long life. If there is significant moisture don’t expect them to last more than a year.

I first started making my own from raw parts and cat5 cable. They are a pain to make and using solid cat5 cable is a bad idea. I then started buying the ones with stainless steel casings that claim to be waterproof. They lasted longer, but after months to a year in my compost pile they started failing. I investigated and discovered there was no epoxy, just the heat shrink. I now use hot melt glue or epoxy over the heat shrink and they seem to last more that a year.

Make sure you check the CRC and also do secondary validation. 0 degrees C will pass the CRC check and is also what you get when the data line is grounded. 85C is what you get when there is no measurement. I have also seen other weird readings as a sensor was failing. The good news is that it is unlikely they will all fail at the same time so make sure you have multiple sensors on the same system and you should be able to tell when something is amiss.

Is it a good idea to have that many DS18B20 temperature sensors on the same BUS?

I have a positive experience with 4 (3 nearby and one 10 meters away), but some friends tried to push more sensors into the wire and things start to malfunction.

The software side of the problem is relatively easy to solve, just turn to a wifi chip like the ESP8266, and create a html page where you can scan and save each device address in the position you want.

As the distance will be about 0.5 m at the most, it must be worth trying. If necessary, it will be relatively easy to insert a 1-wire interface, e.g. the DS2480B, into the circuit, though it needs a 5 V supply and so level translation to interface to 3.3 V for the emonTH.

I overlooked the OP requirements, i was guessing on a more generic setup.

To get the readings of a arbitrary number of DS18B20 devices from the ATmega maybe it would be interesting to transmit the reading along with the device addresses. Each device address would then be translated to a fixed position in another processing device, like emonhub or Node-Red.

Actually there would be no limit on the number of temperature sensors that a emonTH could handle, and there would be no need to use EEPROM, A scan-request-read-transmit loop should be sufficient.

I think the overhead might make this impractical, with an 8byte id/label per 2byte value, at 10bytes per sensor there would be a 6 sensor limit per send (using JeeLib) and multiple, lengthy payloads would hit a battery powered device hard and add significant traffic, possibly blocking other devices.

Not saying it couldn’t be done, or it wouldn’t be interesting to do, but a 5 fold increase in payload size is pretty significant.

I I like the idea of a esp8266 device with a webpage for setup though.

1 Like

All this is interesting, but from what @JustPlaying has already written, he doesn’t feel able to set up a software solution that involves any degree of programming on his part, so that’s a significant restriction. Anything that means the emonPi needs modification looks to be not viable.