Hello @tomq42 confused as to what might be going wrong there with the temperature sensors. You seemed to have some strange results last time if I remember, with it just starting to work without having really changed anything? What happens if you send just the command “t1”?
The documentation indicates that to turn temperature monitoring on the command is “t0 1”. I had tried this, but it obviously didn’t work!
Sending t1 appears to turn temperature monitoring on.
However, if I disconnect and reconnect the cable, power cycling the emonTx, it appears to be back off again. Having turned it on, I do seem to be getting readings in the emonPi, even after taking the USB cable out and reconnecting the powersupply.
It appears that connecting the USB cable and connecting the config interface seems to have the effect of resetting the temperature monitoring switch to “off”. That is: With the “inputs” screen in emonPi open on my laptop I can see temperature readings. I unplug the power from the emonTx and connect it to my laptop with the USB cable. I get up to date temperature readings (that is the “age” value goes back to a couple of seconds) but they are all zero. Connect up the config interface and it says temperature monitoring is off (see above picture). Send “t1” and I start getting readings out on the emonPi. Disconnect the USB cable and put the power cable back in and I am still getting temperature readings in the emonPi.
@TrystanLea - I realised you only updated the avrdb branch which led me to realise that I’d missed the fact that you have to use a specific branch! Can you put that in bold in the docs (so stupid folk like me don’t miss it)?
I don’t think using a specific branch is a great idea. That will often get missed I think. I also think these libraries should have releases as well 
. I suggest you make separate repos for each library so for instance EmonLibCM-avrdb which then has it’s own releases.
Also perhaps a build doc in the EmonTX repo stating the required libraries and releases?
Shame the Arduino IDE cannot pull libraries directly from github with a config file 
. But my views on that tool are not a secret.
1 Like
Sorry yes, that’s a recent change, I will update.
It sounds to me that there’s some kind of timing issue with your temperature sensors, they are just not being detected in time. Are they temperature sensors bought from the OpenEnergyMonitor shop? have you extended the cables? I need to find a way to replicate what you are seeing so that I can then work out a suitable fix. The other option is to have a config option e.g temperature: off (t0), auto detect (t1), always on (t2). It seems that your sensors work just fine once it’s past that initial sensor detection stage.
Thanks for the useful information on the issue, that’s really helpful!
Ok sure.
My intention was to merge these branches together and detect the hardware platform. But it might be better to do it with different repositories as you suggest.
1 Like
Thanks. I’m just trying to sort out my libraries, some are pulled from OEM and some from my forks, actually it it a bit of a mess (my fault).
I don’t have much confidence in what libraries and which versions of those libraries are actually being included in the build! At least with PlatformIO you can specify the source and version (tag) in a build file so have a high degree of confidence in the build state 
I have precisely the same issue! In my case, unlike Thomas, I cannot make the temperature configuration persist after setting it manually. I’ve tried unplugging the serial cable from the Mac/Chrome web setup and plugging it back into the EmonPi with the EmonVS left in, and unplugged. In neither case do the T values continue.
(I’m using the serial port to input data to EmonHub (no RF) )
I originally had this problem with an existing (assumed clone) ds18b20 I had on-hand (plugged in via RJ45 as T1) and so bought a new one directly from you last week (plugged in as T2 via the block). Both have standard 1m leads with no fancy wiring.
Interestingly, as the initial temperature enabled messages come in, you can see that the ‘original’ sensor T2 has a single out-of-band reading of 304 but then immediately settles to ~21.6, the ‘fake’ sensor has two out-of-band readings at 25 but then settles to ~21.8. This behaviour is reproducible.
As a final quirk when I first installed the new firmware (late last night) T1 started producing values. However the P2 sensor was defaulted to 50A (I’m using a 100A sensor) and so it was this mornings reconfigure of P2 to use 100A that broke the temperature.
Here’s the configuration output:
emonTx V4 CM Continuous Monitoring V1.5.4
OpenEnergyMonitor.org
Loaded EEPROM config
Settings:
Band 433 MHz, Group 210, Node 17, 7 dBm
Calibration:
vCal = 807.86
assumedV = 240.00
i1Cal = 300.30
i1Lead = 3.20
i2Cal = 300.30
i2Lead = 3.20
i3Cal = 150.15
i3Lead = 3.20
i4Cal = 60.06
i4Lead = 3.20
i5Cal = 60.06
i5Lead = 3.20
i6Cal = 60.06
i6Lead = 3.20
datalog = 9.80
pulses = 1
pulse period = 100
RF off
temp_enable = 0
JSON Format Off
Reference voltage calibration: 1.0301
No temperature sensors detected, disabling temperature
AC missing - Apparent Power calc enabled, assuming 240.00 V
MSG:1,Vrms:240.00,P1:720,P2:434,P3:217,P4:87,P5:86,P6:87,E1:803,E2:0,E3:0,E4:0,E5:0,E6:0,T1:0.00,T2:0.00,T3:0.00,pulse:0
MSG:2,Vrms:240.00,P1:580,P2:11,P3:5,P4:2,P5:2,P6:2,E1:804,E2:0,E3:0,E4:0,E5:0,E6:0,T1:0.00,T2:0.00,T3:0.00,pulse:0
MSG:3,Vrms:240.00,P1:578,P2:11,P3:5,P4:2,P5:2,P6:2,E1:806,E2:0,E3:0,E4:0,E5:0,E6:0,T1:0.00,T2:0.00,T3:0.00,pulse:0
Temperature on
MSG:4,Vrms:240.00,P1:579,P2:11,P3:5,P4:2,P5:2,P6:2,E1:808,E2:0,E3:0,E4:0,E5:0,E6:0,T1:25.00,T2:304.00,pulse:0
MSG:5,Vrms:240.00,P1:569,P2:11,P3:5,P4:2,P5:2,P6:2,E1:809,E2:0,E3:0,E4:0,E5:0,E6:0,T1:25.00,T2:21.50,pulse:0
MSG:6,Vrms:240.00,P1:571,P2:11,P3:5,P4:2,P5:2,P6:2,E1:811,E2:0,E3:0,E4:0,E5:0,E6:0,T1:21.87,T2:21.62,pulse:0
It looks as if I need to look at the configuration code. The original version I published some while ago appears to have worked correctly for some time, but from comments made, it appears that something has been changed in the emonTx V4 version. I’ve been far too busy to be able to look at the emonTx V4 sketch.
The documentation and the code that’s known to work can be found (with a bit of digging and selection to find the most appropriate starting point) here: The emonPiCM
If anyone wants to try to use the code from the ..._config.ino file, that and the emonTx V4 sketch will need to be changed to accommodate the variables that need to be changed by the configuration commands.
I’ll ask the silly question, did you click ‘save’ or issue the command s before powering down?
My understanding is that all happened because the EEPROM library was written for the Atmel 328P - and not changed to suit the much smaller EEPROM memory available in the Atmel AVR-DB when it was used in the emonTx V4.
Anyway, you’re off-topic. The comment I was responding to concerned configuring the temperature sensors. From the comments in several topics, the configuration commands appear to have been changed, which would explain why they don’t respond to the documented command. In the original configuration commands t0 is a prefix to the actual command and referred to all temperatures generally, prefix t1… referred to sensor 1, etc. That’s what appears to have been changed. I’ve yet to verify this, and I don’t see it happening imminently.
No, I’m don’t think I am, as the issue with the configuration not being saved was, AIUI, related to the EEProm code.
It could be there is a bug in both.
Yes I have changed the configuration options for temperature sensors in v1.5.3. The intention was to only enable temperature sensing if temperature sensors are connected at startup and so eliminate the minor interference that the temperature sensing code has on the electricity monitoring for users who do not use temperature sensors.
Unfortunately it seems that the auto detection is not completely reliable and so I need to either work out how to fix the auto detection, it might just need a delay in the code, perhaps its a power issue and I’m checking too soon? I haven’t been able to replicate the issue which makes testing a little more challenging.
The alternative solution or perhaps a worthwhile option in and of itself is to have temperature sensing set to ‘auto detect’ as default but then have the option to turn on or off temperature sensing manually.
At the moment the options saved to EEPROM are: 0: temperature sensing off & 1: auto detect temperature sensing. While you can over-ride the auto detection after startup the setting does not persist as the autodetect over-rides on the next reboot.
@NickT are you familiar with using the Arduino IDE? would you be able to set it up to upload firmware to the emonTx4? following the guide here: Firmware — OpenEnergyMonitor 0.0.1 documentation
It might be worth trying a couple of seconds of delay at Line 296 here: emontx4/EmonTxV4.ino at main · openenergymonitor/emontx4 · GitHub e.g add the line:
delay(2000);
It would be interesting to hear if that makes any difference.
1 Like
Actually I didn’t! It was already set to enabled and I didn’t power it down. I used the t1 command to enable it after power up and initialisation, when it was already sending messages. Magically the T values appeared.
I’ve never used Arduino but I’ll give it some time today and see where I get to. My shiny new HomeKit energy/temperature solution can’t fully work without it (it was built and tested using an EmonTx3 system).
After a short learning curve I did manage to compile and load the firmware with the modification you suggested. Line 296 was a blank line before the call to EmonLibCM_TemperatureEnable() and I tried it there, no change. I then moved it after the call (see image) and it works!
I’m new to the Arduino IDE (2.03 for Mac/Intel) and after following the instructions it still showed me a message that ‘newer versions of your libraries exist’, which I ignored and doesn’t seem to have come back. It also kindly pointed out that there is an `assignment within if()’ at line 1312 of emonLibCM.cpp, that although not an error might be an accident. I left this alone, @TrystanLea was that deliberate?
Do you mean this
if (temperatureEnabled = _enable)
which is nowhere near line 1312?
If so, it’s a perfectly legal ‘C’ language construct, and it’s correct. I’ve no idea why the compiler is flagging it. Reference: Kernighan & Ritchie, The C Programming Language, pages 236 & 237.
I’m more than familiar with C thanks Robert, and the reason the compiler flags it is that it is a common programming mistake that may, or may not, be intended. Although syntactically correct, it may not be semantically correct. The original author would know that. The most recent git blame names that person as @TrystanLea so let’s hear from him. Although he could have trivially modified an earlier version of the line.
I do indeed mean line 1312 on branch avrdb (as per the instructions for compiling the firmware). See below. I ag’d the entire codebase (ag 'temperatureEnabled[\t ]*=[ \t]*_enable') and it occurs only here (and on line 44 in a comment). How nowhere near do you think it is?
BTW I’m a newcomer to this forum and am surprised at the tone of your post.
The question has been asked many times, and I’ve responded many times. Maybe you didn’t find it in a search? Is it not obvious from the context that
if (temperatureEnabled == _enable)
will not achieve the desired outcome?
The reason the line number is different is you referred to emonLibCM, where it is line 1233 in my editor, not Trystan’s -DB version - which I haven’t had time to study because all my time has been occupied making the 3V12I version to work - and this is still ongoing.
I make the following post in a constructive fashion:
Now, as and when you respond again, you can enlighten people as to why the compiler flags this as a warning. If you were responsible for that line of code you could also take the recommended course of action and add additional parentheses to show that you know what you are doing, that is using the result of an assignment statement as a truth value deliberately. If I’d seen that I’d have known, and the compiler would have kept quiet.
Making a decision about whether =, or == is correct requires knowledge of the entire context as temperatureEnabled is a global. It’s a truism to say things are
obvious from the context
but most of us don’t have time or need to have the full context in our heads and so observing language standards and coding conventions is a great time saver when different people collaborate. If you’d like any co-operation on the ‘3V12l’ version (whatever that might be) you might consider that. It would even help your future self. Here modern compilers are your friend, use them. I wish I’d had that when I first wrote C on a PDP-11 back in the day…I’ve spent countless times thinking ‘which idiot wrote it that way…’ to discover it was me!
Lastly, the magic of Git means that there are many versions of code in a single repo, it should have been obvious from the context (installing this firmware update, see what I did there?) that the libraries were on the avrdb branch.
Happy New Year
Nick