I’m trying to compile the sketch from the source — I get a lorryload of errors. It’s too late to investigate. It looks like a load of libraries have got changed.
This is what I see with two devices connected, repeated every 10s. The first shorter blip is the start conversion command convertTemperatures(), when you zoom in on that you can see the one wire reset being a longer period where the bus is pulled low. The second longer section is the reading of the temperature values retrieveTemperatures().
If i then unplug the temperature sensors without resetting the emontx i continue to see both the convert and retrieve attempts but short in duration as it’s not getting any response of course.
If I reset the emonTx4 and ensure that temperature sensing is turned on (it gets disabled at startup if no sensors are detected). I see the single convertTemperatures() attempts which when you zoom in on it looks like this:
The code for convertTemperatures() looks like this:
void convertTemperatures(void)
{
if (temperatureEnabled)
{
if (DS18B20_PWR >= 0)
{
pinMode(DS18B20_PWR, OUTPUT);
digitalWrite(DS18B20_PWR, HIGH);
}
onewire_reset();
onewire_write(SKIP_ROM);
onewire_write(CONVERT_TEMPERATURE, true);
} // start conversion - all sensors
}
A reset, followed by the two writes.
Could that be due to the automatic disabling of temperature sensing if it does not detect any sensors at startup?
If after startup you send the command t1 to turn temperature sensing back on, does it work?
It’s probably these lines that are tripping it up for you @gonzo ?
emontx4/EmonTxV4.ino at main · openenergymonitor/emontx4 · GitHub
byte numSensors = EmonLibCM_getTemperatureSensorCount();
if (numSensors==0) {
Serial.println(F("No temperature sensors detected, disabling temperature"));
EEProm.temp_enable = 0;
EmonLibCM_TemperatureEnable(EEProm.temp_enable);
}
If it’s failing to detect the sensors at startup, it disables temperature sensing from that point on. You could try if you like removing those lines if your happy to compile and upload the code.
The intention behind that is to eliminate any interference with the electricity monitoring side of things. Im going to write a post explaining that side of things in more detail next.
I wonder if this might be due to the need for the DxCore version of the OneWire library for the EmonTx4, it tripped me up last week, when switching from Atmel328 to AVR-DB devices the OneWire library needs to be changed. Here’s the DxCore variant: GitHub - SpenceKonde/OneWire: Library for Dallas/Maxim 1-Wire Chips
From what I remember, my problems were the number of arguments for the EEProm library was different, and it didn’t know the AVR registers.
Ah ok, probably need the avrdb branch of the eeprom library. I never merged these into a single library that supports both cores.
Surely this can’t be correct? It means that if no sensors are detected - say because of a loose plug connection - it will never be possible to enable temperature sensing again without taking the emonTx to a programmer or a programmer to the emonTx.
No it just changes that at startup. If temperature sensors are present and detected at startup, temperature sensing will be enabled. Otherwise temperature sensing is disabled. If temperature sensors are connected whilst the emontx is already powered up a power cycle is required.
Actually I see one problem with it. If the eeprom is saved after startup say after setting some calibration values, but the temperature sensors are disconnected, it will save the eeprom with the temperature sensors disabled setting, posing a problem when temperature sensors are later connected and the emontx is power cycled
The command ‘t1’ would then need to be issued and eeprom saved to re-enable temperature sensing…
I will improve on that and make an update to this firmware.
What I think is needed is, when no sensors are detected, the library internally sets the temperatures to disabled, but the sketch should NOT write it to EEProm. Thereafter, until the next power-up or intervention via the API, the library won’t allow any temperature activity.
At present, I think the library doesn’t specifically disable itself if no sensors are detected at start-up (which was probably an oversight).
All you need therefore is
if (!EmonLibCM_getTemperatureSensorCount())
{
Serial.println(F("No temperature sensors detected, disabling temperature"));
EmonLibCM_TemperatureEnable(false);
}
This will allow the user to reset and seek the sensors with a simple power cycle, or API call via the serial interface. (The EEProm should only ever be read at start-up.)
1 Like
Which I guess begs the question… what’s the intended use of the EEProm setting? I guess it gives you a way to disable 1wire even when there are sensors connected? In most cases you’d think it would be easier to just unplug the 1wire cable. Perhaps it’s intended for the case where you don’t have easy physical access to the device, but you do have remote terminal access?
Excuse the delay in replying…
I was unable to capture any reset pulse from the EmonTX. Suggesting that the firmware is not even attempting to detect the temp devices.
I did note that the shipped unit reports V1.5.4. But latest on Github was 1.5.3
At this point I will probably give up on the temperature measurement.
I only added them because the connectors where there. And I don’t want to compromise the power measurement accuracy, as that is the primary requirement here.
Do you mean generally, or in Trystan’s particular line of code?
I was referring to the EEProm flag for enabling/disabling temperature sensing. When would you want to have it disabled (Vs just unplugging the bus)?
A very good question - I don’t know. I think Trystan got a bit confused. The purpose of the EEProm is to store settings saved on command by the human user so that those settings, rather than the sketch defaults, are used at power-up thereafter. They have no other purpose – they should never be recovered and restored except by the sketch using the API at power-up, which is why I don’t provide a user command via the serial interface to restore those settings. Automatically writing to EEProm (or in this particular case writing a value that could inadvertently be saved by accident) is fundamentally wrong, and will lead to all manner of confusion if it’s allowed to happen.