Community
OpenEnergyMonitor

OpenEnergyMonitor Community

Emonth V2 Temperature & Humidity Accuracy - INPUT/FEED Calibration

Tags: #<Tag:0x00007fe7b3a616a0> #<Tag:0x00007fe7b3a61330> #<Tag:0x00007fe7b3a611a0> #<Tag:0x00007fe7b3a60d68> #<Tag:0x00007fe7b3a609d0>

I have just received a second Emonth V2 to use with 2 external DS18B20 sensors to monitor my gas boiler in & outlet temperatures. I thought that I would place them next to each other (3cm’s apart) indoors and compare the readings to check their operating accuracy before I flashed one of them to support 2 DS18B20’s.
The declared specification is (emonTH -Temperature & Humidity Node):

  • Accuracy humidity ±3%RH
  • Accuracy Temperature: ±0.4 degC.
    Over the past 18 hrs I have calculated:
  • Humidity difference of 2-4%RH (average of 2%RH)
  • Temp difference of 0.0-0.4 degC (average of 0.3 degC)

Is it advisable to use the ‘Calibration’ function on the INPUT to provide my emonTH FEEDs with similar data points or is there a reason not to do this?

I have used a calibration factor in the Inputs menu to fine tune the accuracy of power monitoring, so I guess it should work for temperatures too. Personally, I’ve not been too worried about temperature probe accuracy. For me, if the sensors are within a degree, that’ll do for me. It’s telling me what’s going on.

What I have seen so far is the amount of short cycling my boiler is doing, about 6 starts an hour so far, excluding DHW demands. I don’t think thats too bad to be fair for a combi. The aim for me was to experiment with flow temperatures, seeing if there is a sweet spot that reduces cycling and ensures return temperatures are suitably low (below 54C so the boiler is actually condensing). It’ll also give me a good idea how low I can go for flow temperatures whilst maintaining a good room temperature and warmup response time for the day a heat pump takes over from the boiler.

Anyone seriously interested in the DS18B20 ought to read this:

Thanks for the link about counterfeit DS18B20’s.

I’ve reread my original post and realised that I didn’t make it clear that I was referring to the onboard sensor:

  • Si7021 Temperature & Humidity Sensor

I’ll look at checking the two DS18B20 sensors later when I get time to connect them to compare their reported values.

I’ve got a condensing system boiler and I’m aiming to do the same as you are with the dual DS18B20’s connected to an emonTH.

Anyone know if the encapsulated DS18B20 sensors that come with the EmonTH are genuine? They are encapsulated and the article does suggest if they are waterproof then they are more likely to be genuine.

I think this is one for @Gwil

A day later and it seems that the onboard temperature sensor (Si7021) of both my emonTH’s now report almost identical values, so I’m now removing my 0.3 calibration value for this INPUT.
As for the two DS18B20 sensors these are also reporting similar values to each other and that of the onboard Si7021.
As for the the Si7021 Humidity Sensor, these report an approx 0.4% difference a day later.

I did have a little issue connecting the DS18B20 sensors:

  1. Initially I was clamping on the insulation because I had pushed the wires too far into the block.
  2. I didn’t realise that I had to power cycle the emonTH for it to discover the connected DS18B20.

As to whether the DS18B20 sensors are genuine, I’m sure that they are considering that I purchased them via the Open Energy Monitor online shop. I’m intending to look at using the ‘emonTH_DHT22_dual_DS18B20’ firmware and will discover the sensors’ addresses using the utility sketch.

That has been known to cause trouble. The insulation should always be stripped back to the correct length. Too long is as bad as too short.

That is true for all input sources and sensor nodes. It’s in the FAQ.

I published a version customised for the emonTH2 only 2 days ago.

They certainly should be genuine Maxim/Dallas sensors. @glyn.hudson would know more about it than I, but we always do our best to procure from reputable suppliers.

Were a batch recently withdrawn from sale because you discovered they were not genuine?

Earlier in the year, we received a bad batch of the sensors that have the RJ45 connector. Yes, they were withdrawn from sale as a precaution (the majority behave as expected, we noticed the bad ones a day or two after we received them). We have sourced a new supplier for the next lot.

It is important to note that the ones that come with the emonTH - the wire ended ones - are unaffected by this.

2 Likes

The encapsulated sensors in the shop return the following when tested with

28-CE-D3-61-09-00-00-13: ROM ok.
  Scratchpad Register: 1D/01/4B/46/7F/FF/03/10/C5
  Info only: Scratchpad bytes 2,3,4 (4B/46/7F):  Maxim default values.
  Scratchpad byte 5 (0xFF):  ok.
  Scratchpad byte 6 (0x03):  ok.
  Scratchpad byte 7 (0x10):  ok.
  0x4E modifies alarm registers:  ok.
  0x4E accepts 10 bit resolution:  ok.
  0x4E preserves reserved bytes:  ok.
  0x4E accepts 12 bit resolution:  ok.
  0x4E preserves reserved bytes:  ok.
  Checking byte 6 upon temperature change: not necessary. Skipped.
  --> Sensor responded like a genuie Maxim.
      Not tested: EEPROM, Parasite Power, and undocumented commands.

28-CE-D3-61-09-00-00-13: Family A1 (Genuie Maxim).
``
1 Like