Hot water tank temperature monitoring

Github is worse than a can of worms to me, so I’m not sure when this

was first published - looks as if the last update was May 2018, but there’s definitely an indication that 4 temperature sensors can be used.

So it looks as if you are looking at out of date information.

Thanks for your reply. That’s very interesting and also very perplexing.

I had a support message from @glyn.hudson in July 2018 where I asked about multiple sensor support, and he replied:

Sorry this is not possible without significant FW modification… If your interested in exploring this, please post on the community forums. I will do my best to help on the forums.

Is it worth a punt and just buying another sensor to see if it works, do you reckon?

I’m pretty sure it won’t work work without modifying the FW.

Well yes and no . . as far as I can tell!

The OEM project has sort of painted itself into a corner by going down the route of fixed payloads of data and auto-installing emonhub node definitions. Basically to make the changes to the FW to include more sensors would involve utilising another couple of node ids, and of the 30 possible, most (if not all) are already used by other devices and/or other emonTH payload definitions.

Indeed there is provision for up to 4 sensors to be recognised and even read, this code requests a reading from each of the sensors discovered at start up (4 max)

BUT! Only the very first discovered sensor (aka allAddress[0]) is read into a variable to be added to the typedef payload.

so on the surface it looks like that line needs moving into a loop to read all sensors and the payload needs changing (both in the sketch and emonhub), however, since I do not know the history of the code and Glyn says “significant” modification, I wouldn’t like to rule out the possibility that 4 sensors were tried and there was an issue so they backtracked to a single sensor? So maybe it isn’t so straight forward??

Either way, for there to be an official change to support multiple temp sensors would require utilising more node ids, so while changes might be reasonably trivial for ad-hoc FW’s (with a bit of coding), it might never reach an official update. But there again I could be wrong, stranger things have happened.

[edit - Also noted whilst looking at the FW,

There have been 7 V3.x revisions since the last V2.x FW and DHT22 is not used in the v2 hardware so why is it in the FW name? especially when the FW appears to be called “src.ino”

and why is there still several refs to DHT22 in the code? On lines 114, 115, 164 and 165, each line has a comment saying it isn’t used, so why is it still there I wonder?]

Do you have a particular need for it to be battery powered? If not, I’d use an WEMOS D1 Mini and Tasmota.

There are very many sketches with the words “Recommended node ID allocation”. I seem to remember, when the system of NodeIDs was put forward, a very strong statement was written to the effect that adhering to the proposal was by no means obligatory: “There is no intention to enforce this as a standard.” appears in Learn | OpenEnergyMonitor
Yet that seems to be the situation we are now in. The real problem is we’re using the NodeID as an identifier of both the Node and the payload - something that I’m sure JeeLib never envisaged. What’s wrong with having two different payloads for the same NodeID? Put all the variations in emonhub.conf, with all but one disabled (commented out). That should be the default payload. Most times, it’ll work out of the box and nothing has changed. If it doesn’t work, remember that emonhub.conf is easily edited via a web browser, so when a node doesn’t show up, comment one definition out and un-comment the next one until it does. Can that really be so hard or confusing if it’s written up and explained properly?

Or, if you want it to be automatic, use the first byte or two of the payload as the payload identifier. That way, you have 29 possible sensor nodes and 256 or 65536 possible different payloads.

Thanks for the replies chaps, your time is much appreciated, no matter how abundant it may be at the moment!

While I’m technically-minded enough to purchase and operate OpenEnergyMonitor equipment, I’m afraid a lot of the detail in your replies went above my head, sorry. I would have no idea where to begin modifying firmware, sketches, nodes and payloads, unless there was an exact list of steps spoon-fed to me, which I certainly would not expect any of you to do.

No, I have mains power available in my loft where my cylinder is. I have googled and searched the forum, and it seems the device you mention is the same as the NodeMCU ESP8266 that is sold in the shop - is that correct? From what I can see from the guide section of the website, this appears to also need an emonTX to work - if this is the case, I might as well buy another emonTH unit (which is already pricey enough) given the costs involved. Again, unfortunately, unless there is a guide somewhere I can follow, this would be above my level of skill - I’m looking more for an “out-of-the-box” solution.

One thought on this would be to set up somewhere on the forum where people who find all the technology too overwhelming can ask for assistance from more experienced people. Payment could be sorted out between the two parties once they’ve connected with each other.

Simon

Apologies. Three of us hijacked the thread to discuss the technical details.

Given your level of expertise, the only OEM solution that I can think of that comes close - and it’s not guaranteed as I don’t have an emonTH V2 to test - would be for you to buy a programmer and upload a changed sketch (“Arduino-speak” for the user’s software program) and modify your emonPi (or emonBase) to accept the block of data (“payload”) that it sends. To use, that’s a quite small modification. I can understand that for you it could be hard.

In addition to buying the programmer, you’d need to install the Arduino IDE and some libraries on your computer to compile the sketch. That’s not trivial, but there is a detailed step-by-step procedure in ‘Learn’. It might be worth reading through that purely to evaluate the possibility.

Also, your emonTH needs a screw terminal block to connect the DS18B20. I assume that’s fitted?

By implication, you mean as here - programming the hardware, or would you anticipate yet further involvement?

Would you envisage this being done through The Shop or on a 1-to-1 basis?

Similar but cheaper LOLIN D1 mini — WEMOS documentation. I only get mine from China as there are very many bad knockoff versions around.

It really is very easy. Buy some sensors from AliExpress at the same time. Solder them to the D1, Plug the D1 into your PC. Use the Tasmota flash program to upload the program and then configure from the Tasmota UI. I use old Phone charger to run them off and a cheap plastic box.

There is nothing to actually program - no worse than flashing an SD card. Search on YouTube for a Wemos Tutorial (Drzzz is quite good). For a tenner, it must be worth a punt - the satisfaction is huge!

No, the one sold in the shop is for a specific purpose. A standalone one would just post the values via the MQTT broker on the emonPi - so talks over Wi-Fi.

Hi Robert,

I was thinking on a 1to1 basis. I’m sure there are plenty of users out there who would be willing to help others.

In this case, I’ve seen loads of posts about multiple sensors for heat banks, in fact I’ve posted the code I tweaked to get 8 sensors on our heat bank. And there may be someone out there that would be glad to help someone do this kind of tweaking.

If we had a heading where people could ask for help and another heading where people could offer their services then they could get together.

Simon

[Edit - RW]
@TrystanLea, @glyn.hudson ?

@Robert.Wall
I would certainly be comfortable doing those things, yes. However, I would need to know which files/sketches and the exact changes I’m making. I have zero experience with Arduino and limited coding knowledge besides shell scripts (I’m a Linux sysadmin by trade). As I said before, though, I would not expect anyone to provide this level of guidance to me.

Yes, that’s correct.

@borpin
That does, indeed, sound easy. I didn’t realise a third-party device would be compatible with the emonPi.

I’m sure you anticipate my next question, though: what will I need to do to accomplish this?

It seems there may be two ways to skin this cat then, with similar levels of financial outlay. From what I understand, the former may work and is relatively more complicated, whereas the latter should work and is relatively simpler. Is that a fair analysis?

Once again, thank you all for your assistance.

I expect the change I’d do to the sketch would work, it’s just that I can prove it on the V1 hardware but not the V2, which doesn’t actually prove very much.
I can write out the changes - it’s not at all complicated:

In https://github.com/openenergymonitor/emonth2/blob/master/firmware/src/src.ino
Change line 125:
int temp_external;
to read
int temp_external1; int temp_external2;
(or more if you wish - two statements on one line so as not to move the line numbers around - that’s all!)
similarly change line 379:
float temp=(sensors.getTempC(allAddress[0]));
to read
float temp1=(sensors.getTempC(allAddress[0])); float temp2=(sensors.getTempC(allAddress[1]));
and line 438:
Serial.print("tempex:");Serial.print(emonth.temp_external); Serial.print(",");
to read
Serial.print("tempex:");Serial.print(emonth.temp_external1); Serial.print(",");Serial.print(emonth.temp_external2); Serial.print(",");
then the last substantial change that will shift the line numbers:
change lines 381 - 384

      if ((temp<125.0) && (temp>-40.0))
      {
        emonth.temp_external=(temp*10);
      }

to read

      if ((temp1<125.0) && (temp1>-40.0))
      {
        emonth.temp_external1=(temp1*10);
      }

and replicate for temp2 as new lines immediately below:

      if ((temp2<125.0) && (temp2>-40.0))
      {
        emonth.temp_external2=(temp2*10);
      }

Then the change to emonhub.conf. The lines to change are the ones reproduced in the comment at the top of the sketch (you can replace that comment if you wish):

    [[23]]
      nodename = emonTH_5
      firmware = V2.x_emonTH_DHT22_DS18B20_RFM69CW_Pulse
      hardware = emonTH_(Node_ID_Switch_DIP1:OFF_DIP2:OFF)
      [[[rx]]]
         names = temperature, external temperature1, external temperature2, humidity, battery, pulseCount
         datacodes = h,h,h,h,h,L
         scales = 0.1,0.1,0.1,0.1,0.1,1
         units = C,C,C,%,V,p

I’ll repeat myself - I haven’t proved this, but I don’t see a reason for it not to work (unless I’ve missed something silly).

Tough. I just have. :grinning: You get this as part of the service.

[Edit - 5 hours later…]
I’ve done the equivalent (almost but not quite the same) changes to the software for the emonTH V1.4, which is the one I have, and it’s giving me two external temperature readings to my emonPi, so I think it should be OK.

2 Likes

That was my response too when Trystan told me this was the route he was following 5 or more years ago during a call discussing emonhub. Not an ideal solution, but miles better than being restricted to just a handful of possible payloads.

What would be the default payload? Take the current case in hand, if the multi-temp changes made it into the mainstream FW the payload would change, so “by default” either every existing user or every future user would need to edit emonhub.conf to get a correctly working device . . . and the whole reason for using fixed payloads in the first place was to avoid any editing!

I’m not against editing the conf file, in fact I am all for it, the emonhub conf file is/was intended to be a sort of blueprint of a users (local) setup, not a semi-fixed universal text file that serves all users, that undermines the use of a conf file. emonhub originally was designed to run without many settings and only changes to inbuilt default settings were needed, plus users could define their own nodes, and yes they would have come from either a single list of default templates or from a web page for the device, eg github, But IMO, not in the conf file itself, that should be kept clean, tidy and accurate. For example, when adding this particular custom emonTH node definition to the emonhub.conf @lhs would be better served to edit the meta lines to something like

 [[23]]
      nodename = emonTH_Loft
      firmware = Custom for multi temp sensors based on v3      #See https://community.openenergymonitor.org/t/hot-water-tank-temperature-monitoring/10017/38
      hardware = emonTH_v2 with 2 external temp sensors fitted (Node_ID_Switch_DIP1:OFF_DIP2:OFF)

otherwise there is no point them being there, this accurate info could be of great value when debugging.

Also perhaps worth noting that if posting to emoncms.org or any server using http via emonhub, changing the order of the values in the payload will have consequence, ie shifting the humidity etc to the right changes their index number when processed in emoncms unless the inputs are also altered to suit, not a problem for local mqtt setups eg emonSD though.

Exactly. NodeID is being used for the wrong purpose. It worked when the number of combinations was limited, but it inherently couldn’t scale. Hence we have the problem.

The one the shop pre-loads. Correct me on the timeline, because I’m no good at remembering dates in history - but I have a feeling that “pre-ordained” nodeIDs pre-date the easy editing of emonhub.conf in the web browser?
If it’s necessary for the emonHub update process to check emonhub.conf for edits, and either politely decline or intelligently update only the unchanged bits, then that’s a problem that needs to be faced. But dissuading a user from modifying their system to the extent of preventing them from using it is putting OEM in the same league (in that respect only) as all the commercial offerings.

But it’s not a problem with a new start. It becomes a problem when the function of the node changes after recording started. In that case, I don’t see a problem with changing the nodeID, because changing the nodeID is not done to change the payload, it’s forced as a consequence of changing the payload - and could be avoided by remapping the existing data (OK, that would be messy and would mean copying the data file record by record and rewriting the contents of each in the new order as it went, but it’s not impossible).

Apologies for the late reply.

My sincere thanks to you and everyone for your assistance with this, your kindness is very much appreciated.

I have now ordered a programmer and extra temperature sensor. I will, of course, let you know how I get on.

1 Like

Adding a little context to what Paul wrote:

Those lines are not important to the operation nor emonHub’s interpretation of the data, but they will help enormously in the future when you’re remembering the what and why of the change you are doing.

Yes, I am already a prolific commenter in my scripts as I am terribly forgetful. I am probably putting myself at a severe disadvantage, what with obfuscation equalling job security and all that! :smile:

I once had it explained to me like this:
“If you’re called out at 3 am on a Saturday morning and you can’t understand what you did 2 years ago, it was too complicated.”

There’s a lot of truth in that. :grinning:

My comments always spell out the overall intention, both what it should and shouldn’t do. Any fool can read the code to see what it is doing at detail level.

3 Likes

@Robert.Wall
My programmer and sensor have now arrived and I’ve installed the Arduino software, driver and libraries as specified by the Learn page. I’m a bit stuck as to how to proceed. My searching the forum and documentation have not yielded any fruit.

When I connect the programmer and emonTH device to my computer, the LED indicator illuminates and the port successfully changes to “/dev/cu.SLAB_USBtoUART”. The board remains at its default “Arduino Uno” setting and the programmer remains at its default “AVRISP mkII” setting.

In the absence of not knowing what to do next, I try “Get Board Info”, as that seems to be the only menu option that has any vague connection to downloading an existing sketch, but I get an error message “Native serial port, can’t obtain info”.

I apologise for needing hand-holding but, as I said, I have zero experience at all with Arduino. Any further assistance you can provide would be gratefully received, thanks.

[Edit: specify I am connecting the programmer and emonTH device]