Add support for Dallas DS2438 temperature readings used in MS-T temperature sensors

[alandpearson]

The DS2438 is commonly used in a lot of ibuttonlink.com sensors which are very popular https://www.ibuttonlink.com/collections/1-wire-temperature-sensors

These plug straight into the emonpi and are very useful.

The DS2438 also has other capabilites for measuring DC Voltage and current which are not added in this commit. Maybe someday..

[glynhudson]

Nice work. Does this effect ds18b20 operation in any way? Do you see any issues having this enabled for all users?

[alandpearson]

Hi Glyn, The DS18B20 is unaffected. I run both devices on the same bus. This just adds support for DS2438 if it's found on the bus and processes it correctly. I'd love if this was for all users, as it would save me running 'special' firmware on the emonpi & emonTx, so if you could merge it, that would be great.

Unrelated to this... I found a problem when I compile the firmware using all the right libraries as dictated by platform IO ... the call to rf12_initialise kills reception when it is made a 2nd time (Ie the lines if ((now - last_rf_rest) > RF_RESET_PERIOD) { rf12_initialize(nodeID, RF_freq, networkGroup); // Periodically reset RFM69CW to keep it alive :-( }

I had to comment those out, and all works really well. I tried with different versions of jee lib and even the openenergymon jee lib fork. Running the original 'latest.hex' does not have the issue, so something may have changed since you last compiled it... just a heads up..

[glynhudson]

Unrelated to this... I found a problem when I compile the firmware using all the right libraries as dictated by platform IO ... the call to rf12_initialise kills reception when it is made a 2nd time (Ie the lines if ((now - last_rf_rest) > RF_RESET_PERIOD) { rf12_initialize(nodeID, RF_freq, networkGroup); // Periodically reset RFM69CW to keep it alive :-( }

Interesting, the version of JeeLib used to compile latest.hex is exactly the same as the version defined in platfromio.ini. Do you have a good method of testing this? How can try and replicate your reception dropping issue?

[alandpearson]

I can replicate this at will. Let me know what you need me to do and i'd be happy to assist. I can give you team viewer access if you need to my environment if that helps ?

Personally, I don't like resetting the thing every 60 seconds, as I have a busy little RF network ...

I noticed the tmonTx code doesn't have this reset in it and I assume it uses the same RFM69cw. Although that said, when I compiled the emonglcd code using the jcw jee lib it went almost deaf. Compiling it with the openergymonitor/jeelib restored it's hearing...

Oh jee lib, how we love you !

[glynhudson]

Personally, I don't like resetting the thing every 60 seconds,

Yeah me too, I would be nice not to do this. I'll compile a test with the rest code removed and see how reliable it is. So you have been running the emonPi without this period reset and it's been reliable receving RF? For how long have you tested?

I've just pushed a test to remove-rest-hack branch: https://github.com/openenergymonitor/emonpi/tree/remove-reset-hack

[alandpearson]

I've been running for a few days now without issue, and as I said I've a busy little RF network with about 15 jee nodes (including emonTHx2, emonTx and emonGLCD) on it. I've a few things publishing to MQTT that do TX too.

I need to run it longer but my tinkering keeps me 'restarting'. I'm finished playing with the RFM firmware now so I should be able to run it much longer now.

I would be really interested if you do a compile in your environment 'as is' (with the hack) and see if you now get the same behaviour of RX dying (or maybe it's just not as sensitive).

I think something on the underlaying dependencies changed, and I cannot find the commit referenced in jeelib that we are to compile against, so I 'think' it may be using the latest by default now ?

Either way, it would be great to get to the bottom of this.