Ds18b20 and emonTX3CM firmware

borpin · 2 June 2020 13:12

OK I have not changed anything so that should not be an issue.

Robert.Wall · 2 June 2020 13:49

I’ve run out of ideas.
I think I’ve downloaded the sketch you’re using. One change: I’m using 868 MHz and two sensors. I’ve unplugged the sensor on the RJ45, now on the emonGLCD I’m seeing 2225 from the active sensor and 30000 on the other two. That is correct.
I think I’ve downloaded the emonLibCM you’re using.
I’ve wiped the EEPROM.
I’m seeing temperatures on the radio.

I reset the emonTx, entered config mode; did w0, x, now on the terminal monitor I’m seeing

Continuing…
NO CT’s detected
AC missing
MSG:1,Vrms:3.24,T1:22.25,pulse:0

Here’s my binary EmonTxV3CM.ino.standard.hex (81.4 KB)

borpin · 3 June 2020 12:58

Tried every combination but no luck @TrystanLea any ideas?

Stripped right back, emonTX powered by DC, prebuilt V1.6, sensor wired directly to terminal block. Nothing else attached.

BTW @Robert.Wall, I found switching between different firmware builds, it sometimes seemed to pick up settings from the EEPROM. Does an r clear the EEPROM completely?

Robert.Wall · 3 June 2020 13:26

That’s actually the whole point of the emonEEProm library. If the sketch/build has an unique signature, then each gets to use its own patch of EEPROM. You can have several sketches, each owning their own patch and not interfering with one another.

It depends. If you’re NOT using emonEEProm library, then it should do (but check the code for the config file that you’re using). If you are, then it flags your patch of EEPROM as “invalid”, and the call to read it fails. It’s not actually wiped - another s will write the new configuration, but it only overwrites the changed bytes (in an attempt to conserve EEPROM life).

Fire up EmonTxV34CM_max.ino that came with your emonLibCM. That doesn’t have any fancy stuff in it, it just demonstrates all the library API, including temperatures. If that reports temperatures, it eliminates your hardware, sensors and the library.

Bill.Thomson · 3 June 2020 14:24

With a 100,000 write cycle spec, there’s not likely much chance that’s going to be a problem.

Ref:

Robert.Wall · 3 June 2020 14:44

I know, but it seemed a better idea to do it than not - especially as it’s at no significant cost in usability nor programming effort (just a different EEPROM library call) nor execution time.

And there was I, hoping you were shedding light on what’s gone wrong for Brian.

Bill.Thomson · 3 June 2020 14:49

As the TV sitcom secret agent Maxwell Smart used to say sorry about that, Chief

borpin · 3 June 2020 14:59

Ok so potential progress; it at least read the sensor address, but no temperatures.

EmonTx v3.4 EmonLibCM Continuous Monitoring Maximal Demo
Temperature Sensors found = 1 of 6, with addresses...
28 90 85 56 B5 1 3C 37

Temperature measurement is enabled.

AC present
 V=247.51 f=50.07
Ch 1 I=0.709 W=104 VA=175 Wh=0 pf=0.5910
Ch 2 I=0.000 W=0 VA=0 Wh=0 pf=0.0000
Ch 3 I=0.000 W=0 VA=0 Wh=0 pf=0.0000
Ch 4 I=0.000 W=0 VA=0 Wh=0 pf=0.0000
 pulses=0
Temperatures:
  1 = 25.0000
AC present
 V=246.99 f=50.07
Ch 1 I=0.736 W=108 VA=182 Wh=0 pf=0.5948
Ch 2 I=0.000 W=0 VA=0 Wh=0 pf=0.0000
Ch 3 I=0.000 W=0 VA=0 Wh=0 pf=0.0000
Ch 4 I=0.000 W=0 VA=0 Wh=0 pf=0.0000
 pulses=0
Temperatures:
  1 = 0.0000

Libraries included in build.

Dependency Graph
|-- <EmonLibCM> 2.3.0 #8d0539c [git+https://github.com/openenergymonitor/EmonLibCM.git] (/opt/openenergymonitor/EmonTxV34CM_max/.pio/libdeps/emontx_pi/EmonLibCM)
|   |-- <DallasTemperature> 3.7.7 (/opt/openenergymonitor/EmonTxV34CM_max/.pio/libdeps/emontx_pi/DallasTemperature_ID54)
|   |   |-- <OneWire> 2.3.5 (/opt/openenergymonitor/EmonTxV34CM_max/.pio/libdeps/emontx_pi/OneWire_ID1)
|   |-- <OneWire> 2.3.5 (/opt/openenergymonitor/EmonTxV34CM_max/.pio/libdeps/emontx_pi/OneWire_ID1)
|   |-- <SPI> 1.0 (/home/pi/.platformio/packages/framework-arduino-avr/libraries/SPI)
|   |-- <Wire> 1.0 (/home/pi/.platformio/packages/framework-arduino-avr/libraries/Wire)
|-- <JeeLib> (/opt/openenergymonitor/EmonTxV34CM_max/.pio/libdeps/emontx_pi/JeeLib_ID252)

Robert.Wall · 3 June 2020 16:01

All I can say is I’m using the official Arduino IDE, I don’t update the other libraries as a matter of course - having been burned by that one in the past - and I’m not seeing the same problem.

That means nothing to me. If somebody’s produced an “updated” library that’s not backwards compatible, that’s unacceptable.

borpin · 3 June 2020 16:12

Except that you are using a version of the OneWire library that is not even listed AFAICS.

Could you try the pre compiled V1.6 or 1.7 and see if that works please?

Robert.Wall · 3 June 2020 16:14

I’ve no idea how to do that. I always compile and load in one operation using the Arduino IDE. I can’t see an option to import and load a compiled binary.

Meanwhile...

EmonTx v3.4 EmonLibCM Continuous Monitoring Maximal Demo
Temperature Sensors found = 1 of 6, with addresses…
28 81 43 31 7 0 0 D9

Temperature measurement is enabled.

AC missing
V=3.26 f=0.00
Ch 1 I=0.000 W=0 VA=0 Wh=0 pf=0.0000
Ch 2 I=0.000 W=0 VA=0 Wh=0 pf=0.0000
Ch 3 I=0.000 W=0 VA=0 Wh=0 pf=0.0000
Ch 4 I=0.000 W=0 VA=0 Wh=0 pf=0.0000
pulses=0
Temperatures:
1 = 21.1200
AC missing
V=0.26 f=0.00
Ch 1 I=0.000 W=0 VA=0 Wh=0 pf=0.0000
Ch 2 I=0.000 W=0 VA=0 Wh=0 pf=0.0000
Ch 3 I=0.000 W=0 VA=0 Wh=0 pf=0.0000
Ch 4 I=0.000 W=0 VA=0 Wh=0 pf=0.0000
pulses=0
Temperatures:
1 = 21.1200

borpin · 3 June 2020 20:05

Meanwhile, this code works. There must be an incompatibility with the emonCMLib and the libraries currently available / latest. I note that this sketch uses the abstraction layer provided by the Dallas Library rather than calling OneWire directly.

#include <OneWire.h>
#include <DallasTemperature.h>

#define ONE_WIRE_BUS 5

// Setup a oneWire instance to communicate with any OneWire device
OneWire oneWire(ONE_WIRE_BUS);

// Pass oneWire reference to DallasTemperature library
DallasTemperature sensors(&oneWire);

void setup(void)
{
  sensors.begin();      // Start up the library
  Serial.begin(115200);
  pinMode(19, 0x1);
  digitalWrite(19, 0x1);
}

void loop(void)
{
  // Send the command to get temperatures
  sensors.requestTemperatures();

  //print the temperature in Celsius
  Serial.print("Temperature: ");
  Serial.print(sensors.getTempCByIndex(0));
  Serial.print("C  |  ");

  //print the temperature in Fahrenheit
  Serial.print((sensors.getTempCByIndex(0) * 9.0) / 5.0 + 32.0);
  Serial.println("F");

  delay(500);
}

--- Miniterm on /dev/ttyAMA0  115200,8,N,1 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
Temperature: 24.75C  |  76.55F
Temperature: 24.75C  |  76.55F
Temperature: 24.75C  |  76.55F
Temperature: 24.87C  |  76.77F
Temperature: 24.75C  |  76.55F
Temperature: 24.75C  |  76.55F
Temperature: 24.75C  |  76.55F

At least I am learning a little bit about coding these boards .

Robert.Wall · 3 June 2020 20:24

It might save me a few weeks’ work if you can tell me what the changes have been.
But more to the point, why can’t people consider backwards compatibility when they change stuff?

borpin · 3 June 2020 20:41

Sorry, I have absolutely no idea! I couldn’t even compare the 2 as a) to old one you use isn’t available and b) the difference is probably so big it would be impossible.

I suggest instead of getting the temps via your own OneWire calls, you use the abstraction layer the Dallas library provides.

You have to crack an egg to make an omelette. Sometimes you just need to break stuff.

Look at emoncms - it has broken stuff so updates from 8.x to 10.x simply would not work. It is a good reason to keep up with changes as they occur; easier to fix a few little things.

Robert.Wall · 3 June 2020 20:55

The problem is, all that takes too long - it waits for ages, I could look up the numbers but I can’t be bothered, it’s about a second from memory, and depends on the resolution you ask for - and so breaks up the continuous monitoring. So the only way to use that and do continuous monitoring is to have two processors (or two cores).

Bill.Thomson · 3 June 2020 21:02

IIRC, for 11 bit resolution, it takes 750 ms.
The others drop roughly by a factor of 2 as the resolution goes from fine to coarse.

So yes, yer memory is still workin’

Robert.Wall · 3 June 2020 21:03

Sampling every 104 µs, that’s a long, long, time.

Basically, that’s why I only use the Dallas library to search for sensors - once, at start-up and when they’re enabled.

Bill.Thomson · 3 June 2020 21:04

Yep, That’s an “eternity” in electronics.

Robert.Wall · 3 June 2020 21:07

When you read how they do the search, it makes sense. It’s the price you pay for using one wire relatively slowly, and it’s slow because of power and driver constraints.

Robert.Wall · 3 June 2020 23:40

Bad News - for you. Nope. That theory bites the dust. I have just downloaded Arduino 1.8.12 and the only two relevant, that is non-Arduino, libraries, OneWire and the Arduino Dallas, and installed them; and my example sketch still works just fine. The temperatures still report as they should:

EmonTx v3.4 EmonLibCM Continuous Monitoring Maximal Demo
Temperature Sensors found = 2 of 6, with addresses…
28 81 43 31 7 0 0 D9
28 8D A5 C7 5 0 0 D5

Temperature measurement is enabled.

AC missing
V=3.27 f=0.00
Ch 1 I=0.000 W=0 VA=0 Wh=0 pf=0.0000
Ch 2 I=0.000 W=0 VA=0 Wh=0 pf=0.0000
Ch 3 I=0.000 W=0 VA=0 Wh=0 pf=0.0000
Ch 4 I=0.000 W=0 VA=0 Wh=0 pf=0.0000
pulses=0
Temperatures:
1 = 20.3700
2 = 20.5000

Phew!

I do force the resolution down when the reporting period gets small, then ban temperatures completely when it gets too small.

As it is, there’s a tiny hesitation while it reads the bus, because it relies on timing as there’s only a single wire data bus.