Under new management??

@pugwash

Working well!
I'll have a good look at the code soon as I can.

Cheers!

I have two configurations currently under test.

Configuration 1:

A bare-bones ATmega328P running at 8MHz 3.3V, it has been up for 120 hours but I don't expect more than another week of uptime as the 9V - 5V/3.3V bridge, not only has an onboard LED but also an AMS1117 voltage converter with a quiescent current consumption of about 5mA.

Configuration 2:

The battery charging board has no LEDs lit up while powering the remote ATmega328P also running at 8MHz/3.3V and the sensors. I am expecting weeks of uptime with this configuration.

@frogandtoad

Don't bother with version "h", I am now up to version "j", the previous versions were so buggy, I discovered. Had to rethink the receiver side and make some changes to handle the incoming data as instances. I was getting data wandering from the attic to the balcony records and vice versa. And I added a true timestamp instead of just showing the current time.

I don't know whether this might be improved by some OOP, perhaps???

@pugwash

Posted by: @pugwash

the previous versions were so buggy, I discovered.

Yeah, I was going over it and thought I saw something not quite right.

Posted by: @pugwash

I don't know whether this might be improved by some OOP, perhaps???

Another goal of OOP is to structure code, to avoid repeatability, and to introduce readability - I think this version has taken a further step "backwards" than the prior version 🙂

Yes, this is a prime candidate for OOP... it should be obvious now that as your program is getting slightly larger, the task of organising and structuring the code without repeatability becomes increasingly difficult.

I'll drop the other one and start looking a this one for some ideas.

Cheers!

@frogandtoad

The first problem I had is that, despite the remotes having exactly the same build and identical sketches running on them, one is transmitting every 64 seconds and the other every 68 seconds.

And because I was using just one struct to handle incoming data, calculate min and max values and store the data in the EEPROM, I was getting erratic values in the min and max variables. So I changed to two structs dedicated to each remote and during setup loaded each struct with the data already stored in EEPROM (might not be absolutely necessary). Anyway, this stopped min & max variables being stored at the wrong location in the EEPROM.

If more remotes were to be added, this may call for an array!

@pugwash

Quick question...

Have you changed the way you're using the Min and Max temp values?

Are they supposed to be a reference for incoming temperatures, for example if the temp in attic go's below the Min, then take some action, or if the temp go's above the Max, then take some action (turn on a fan, alert overheat, shutdown, etc...)?

Or... are you just simply wanting to overwrite and record the Min and Max values coming in?

I would also choose "the right tool for the job", and the 20x4 LCD is not it!  A cheap OLED can present all of your data in one go - You shouldn't write code just to satisfy a bad tool, just because you have it laying around, but a cheap OLED instead, can clean up the code and present the information much, much better!

I'm also not convinced you're using the EEPROM as it was intended for... it should be there to read configuration data that *rarely* if ever changes, not to constantly read and write to it in the loop, and 3 different objects at the moment.

I'll show you some code soon enough, but these are some concerns I think need to be addressed to make the code cleaner and less repetitive.  Right now you only have 2 sensors, and the code repeats in many places... I'm sure if you add another sensor, you will start to struggle in maintaining the code even more, because you will have to copy and paste many lines of the same code, also making the program unnecessarily larger - I have spoken about and provided examples with arrays in previous posts, and I think that is the way to go.

Before we get onto the OOP stuff however, I'm going to write a function, so you stop haunting me with those millis() calls, and show you how to put it into your own utilities header file, along with any other of your favorite functions you create 🙂

Stay tuned!

@frogandtoad

Have you changed the way you're using the Min and Max temp values?

No! They are just there for display purposes only!

I'm also not convinced you're using the EEPROM as it was intended for... it should be there to read configuration data that *rarely* if ever changes, not to constantly read and write to it in the loop, and 3 different objects at the moment.

I will abuse the EEPROM, as I see fit ? 

I would also choose "the right tool for the job", and the 20x4 LCD is not it!  A cheap OLED can present all of your data in one go - You shouldn't write code just to satisfy a bad tool, just because you have it laying around, but a cheap OLED instead, can clean up the code and present the information much, much better!

Aesthetics, but I'll take a cheap OLED, if you want to buy me one for my upcoming 65th birthday. ?  But I want something I can see without glasses!

Henry Crun: "My eyes aren't what they used to be!"

Neddy Seagoon: "Oh, really!!"

Henry Crun: "No, they used to be my ears!"

you stop haunting me with those millis() calls

I am not putting a delay() longer than a couple of milliseconds function, in MY code!!

I have finally dispensed with using the EEPROM altogether!

I just write down the daily Min and Max values in the traditional way, with "pen and paper" ? ? ?  

@pugwash

Sorry for the delay... here's the code I said I would provide to replace those millis delay's: - I use this in my own little library that I have been creating which looks like this:

A directory in my library folder called: fat_utilities
Within that directory resides the following file:

Arduino code example looks like this:

// Be sure to include our new functions library
#include <fat_utilities.h>

void setup() {
  Serial.begin(9600);  
 }

void loop() {

  // Testing for default delay of 1 second...
  if(fat::delay(MILLIS, 1000)) {
    Serial.println(F("\nMilliseconds delay completed\n"));
   }

  // Both delays run simultainiously @ 1:4 ratio between prints

  // Testing for a custom delay of 0.25 seconds...
  if(fat::delay(MICROS, 250000)) {
    Serial.println(F("Microseconds delay completed"));
   }
   
 }

If you do not wish to use the namespace qualifier, then you can remove them, and add the following namespace qualifier instead:

#include <fat_utilities.h>

using namespace fat; // Example usage

This will now allow you to use the functions as normal:

  // Testing for default delay of 1 second...
  if(delay(MILLIS, 1000)) {
    Serial.println(F("\nMilliseconds delay completed\n"));
   }

  // Both delays run simultainiously @ 1:4 ratio between prints

  // Testing for a custom delay of 0.25 seconds...
  if(delay(MICROS, 250000)) {
    Serial.println(F("Microseconds delay completed"));
   }

 These functions can work together simultaneously:

-- OUTPUT --

Microseconds delay completed
Microseconds delay completed
Microseconds delay completed
Microseconds delay completed

Milliseconds delay completed

Microseconds delay completed
Microseconds delay completed
Microseconds delay completed
Microseconds delay completed

Milliseconds delay completed

Microseconds delay completed
Microseconds delay completed
Microseconds delay completed
Microseconds delay completed

Milliseconds delay completed

[ETC]...

Cheers!

@pugwash

Posted by: @pugwash

I have finally dispensed with using the EEPROM altogether!

I just write down the daily Min and Max values in the traditional way, with "pen and paper"  

About time! 🙂

Seriously, I would just write all raw data to an SD card as I mentioned previously, and then write a reporting class or function to display whatever data you require... min, max, average, signal strength, power, fan on, off status, etc... and... to a proper display screen!

You know it makes sense! 🙂

@frogandtoad

Turning to an earlier post:

We cannot directly instantiate an Animal object, because what would it mean to have an Animal object? Animal is an abstract object, representing common features of Animals, but a Cat or Dog or an Emu "IS-A" a "TYPE" of "Animal" with common features and behaviors.

The only thing that these three animals have in common, is that "they can't fly" ? ? ? 

@frogandtoad

When Bob Geldorf, who hated Pink Floyd for being part of the establishment, got Waters and Gilmour back together on stage, somebody in the audience was holding up a banner with the words

"Pigs Have Flown"

Never thought it more appropriate!!

Sorry for going off topic ? ? ?