Archived Forum

It looks like the DS18B20 is returning error values. This could be a possible connection or power issue. My home temperature sensor occasionally returns a high value like that (but not very often). Double check that the sensor is powered from 5v and that a 4.7k value resistor is pulling up the data line. How long is the cable run to the sensor? If all else fails you could add a line of code to do a simple sanity check on the temperature value returned, eg you know it should be between certain limits.

Hi Glyn, the emonTx is 5V powered with a USB wall charger. I assume the onboard 4k7 resistor is to pull-up the data line?

The cable is only 2-3m long. I used 1.5m CAT5 UTP cable to prolonge the cable of the waterproof sensor from your shop.

I have to say, the cable is running parallel to a 230V AC cable to feed the circulation pump and 24V AC to control the 3-way valve. Could that be the problem?

This line of code, should I add this in the sketch or can I do a sanity check in emonCMS (if not, maybe add this as a wish?). Boiler temperature can never drop instantly from +- 50°C to 0-2°C or 500+°C. So maybe when the sensor measures a delta T of more than 10°C, it should ignore the reading?

I've have the same sort of problem on an emonTx and RFM2Pi with one of my current readings.  My spikes are 255 or 65535 so are clearly due to a problem in the digital domain.  I haven't got to the bottom of it yet but the errors have been introduced by the time it gets to raspberrypi_run.php.  Looking at your graph the numbers don't look exactly like my problem but could it be the same cause?

[edited to remove incorrect conclusion about the cause]

I have to say, the cable is running parallel to a 230V AC cable to feed the circulation pump and 24V AC to control the 3-way valve. Could that be the problem?

Switching inductive loads - that could indeed be a (or even the) problem. Are you able to relate the times the pump / valve switches to the spikes occurring?

Nope, as this is a very old (60s) Honeywell M900 series 135ohm thermostat/control system. I really don't know how my 3-way valve is controlled... It looks like some sort of Wheatstone bridge.

I think it's easier to re-route the cables to check this :-).

I think it is the feed processor/parser? In the screenshot you see my inputs, input config, feeds and dashboard.
As you can see my nodes get frequently updated. But my boiler_temp feed does not get an update! So the chart is empty.

Do I do something wrong? Or is this new modular version still not 100% working? I'm using the RFM2PI, emonTx and emonGLCD (living_temp)

What I also don't know is this node10_3 whom I called 'random'. According to my sketch I'm only sending out 2 values from 2 DS18B20 waterproof sensors.

Hmmm this is strange. My emonGLCD indicates I'm consuming 4800 Watts but I have no CT's connected to it. I also commented out all power calculations/readings from the emontx_temperature_power.ino sketch.
Could that be the problem to the spikes in the readings and the unknown node10_3? I also have a node10_4 who suddenly appeared after a day...

I'm getting a little bit further! When your DS18B20 doesn't return a correct reading, it displays -127°C. When using a emonTx or emonGLCD, the code multiplies the value by 100 so it can send the number with enough figures. I think this is because the RFM12B or emonCMS can't handle floating values.
If we didn't multiply by 100 we would end up with temperatures like 20°C and not 20.43°C. The emonCMS input processor divides the received value by 100 to obtain a floating value.

Anyway, back to this -127°C value, sent by the emonTx as -12700. The funny thing when you do this is. In the emonCMS input view, you see the value changing from -12700 to 52836. Even though the emonTx or emonGLCD is sending out -12700 the whole time (checking the serial monitor confirms this). Sending -127 gives 65409 in the input screen.

This means there are 3 options. Or the RFM12B doesn't like values like -12700, -127 or there is something with the input processor of emonCMS or the third option, there's something in the firmware of the RFM2Pi (emonBase for Raspberry Pi).

52836 is 0xce64 in hex which is unsigned 52836, interpreting it as signed int gives you -12700

It looks like the code should handle this, so I am unsure what the problem is

for($i=2; $i<(count($values)-1); $i+=2){

              if ($i>2) $msubs .= ",";
              //$msubs .= $values[$i] + $values[$i+1]*256;
              $int16 = $values[$i] + $values[$i+1]*256;
              if ($int16>32768) $int16 = -65536 + $int16;
              $msubs .= $int16;
            }

Where is this code coming from? Is it from the RFM2Pi firmware & the Raspberry module for emonCMS?

https://github.com/emoncms/raspberrypi/blob/master/raspberrypi_run.php#L125 Make sure you have the latest co

Updated to the latest version and I still have issues.
My sensors are fine. I did a 30min serial monitor log with a laptop connected in the basement to the emonTx. Then I copy pasted these results in Excel and made a graph. No spikes here... So all DS18B20 reading are fine. See my attached readings (serial.print log) and screenshots.

It goes wrong in either the RF part or in the emonCMS parser/Raspberry Pi plugin.

Anyone else experiencing this? I am totally puzzled on what could be the reason

And the strange thing is, the emonGLCD's captured values are just fine (only sends out the temperature)?
Maybe receiving multiple values is difficult? Or it goes wrong while sending out multiple values?

Just to confirm these node id's are ok:
emonTx node id: 10
RFM2Pi node id: 15
emonGLCD node id: 20

The IDs won't matter as long as they are different and unique. multiple values isn't a problem too - I have my energy monitoring send out 10 integers and receive them perfectly.

Maybe when you powered the emonTX from your laptop, the power supply was better and you din't get these spikes. Can you experiment with another one, maybe those spikes are the result of bad power supply?

Also, I don't know what your code is, but if you power the DS18B20 from a digital pin to read it, it needs some time before you get reliable reading.

I assume that things like initialize delays etc are covered in the examples? And I already tried 2 different power supplies. Will test my 5000mAh mobile booster with USB 5V out.

I used this example: https://github.com/openenergymonitor/emonTxFirmware/tree/master/emonTx_t...

The only thing I did was change the device addresses. Then later I wrote some code when the reading was -127°C because I thought this was the cause of the temp. spikes. And I also added a resolution constant to choose between 9,10,11 or 12 bit.

I attached the modified example to this post. Maybe you see/find some irregularities?

Suddenly, all was working fine today :-). Can't tell if it was that 'one more reboot' that solved it? Did several reboots Saturday and now Sunday all is working, no nasty spikes anymore! Anyway, it works, I'm happy!