I don't see much room for code improvement
Well, not necessarily performance, but readability and organisation as I mentioned... but ya never know what the cat will drag in, so we'll start small and may gain additional ideas from there 🙂
I believe the remote sketches a pretty compact, as I have deliberately kept everything to an absolute minimum i.e. gathering the data and transmitting it, leaving the receiver to do any heavy lifting.
I had to weigh up my impatience against being a skinflint.
I ordered and have already received 6x18650 locally because of shipping restrictions on batteries.
I have also ordered 10 ATmega328 (€13) plus 10-off 28 pin sockets and a bootloader shield and 6-off 3.3V charging boards from China (skinflint part).
Locally I have ordered 1-off ATmega326 (costs 3 times the Chinese versions) and one charging board(impatience part) ? ?
This way I don't forget in five weeks time "Why I ordered them in the first place!" ? ?
Two more posts and I have another signature coming, can you guess what it might be? A clue is Pink Floyd again!
I had to weigh up my impatience against being a skinflint.
Yeah, I understand... right now (always), I have to wait for the slow boat from China, and sometimes up to two months. The other day went to a local electronics store for an 9DOF (accelerometer gyro, compass)... almost purchased it due to impatience, but these guys are anywhere from 3 to 5 times the price, so I just left in disappointment - Our whole retail and manufacturing industry has just about gone here mate, and the ones who remain charge an arm and a leg, because they can!
I believe the remote sketches a pretty compact, as I have deliberately kept everything to an absolute minimum i.e. gathering the data and transmitting it, leaving the receiver to do any heavy lifting.
OK, here is refactoring attempt one:
struct { struct { float MIN; float MAX; } attic = {0.0f, 0.0f}; struct { float MIN; float MAX; } balcony = {0.0f, 0.0f}; } Sensors; // New access method (SensorGroup.Sensor.Attribute) Sensors.attic.MIN Sensors.attic.MAX Sensors.balcony.MIN Sensors.balcony.MAX
Struct size still the same, and I think the access itself is clearer, in terms that it is self documenting.
Start with that, and let us see what else we can come up with 😉
Implemented the suggested refactoring and this is now Version 2.
Cool, but I've got bad news for you!
Ohhhhh, shit!!!
What do they say?
If it ain't broke don't fix it!
Don't get me wrong, it is not that I don't appreciate you taking time to show me these alternative methods, I do!
I will be the first to admit that the code you posted has a degree of elegance and readability but may be overkill for this little project.
I won't be doing much in the way of coding for the next couple of days until I have sorted this bootloader and bare bones ATmega328 problem, ultimately getting the remotes to run on 3.3V.
Now that my short excursion into power reduction on the remote sensors is over, it is time to look at further improvements on the local receiver.
I don't want this receiver occupying my serial port constantly, so I intend to display the data on either a 1604 LCD or an OLED module. And I want to store all incoming raw data and the max/min values in EEPROM. The LCD would then get the display data directly from the EEPROM but the EEPROM would be updating with each received message in the background and with a button to toggle between one set of data and the other displayed on the LCD.
The code you posted above has given me some food for thought. I was wondering if I should place all the data in one class, with methods to calculate the min and max values or just restrict the parent class to the raw received data and then extend the class to include the min and max values, and all the associated methods.
Your thoughts would be appreciated:
Now that my short excursion into power reduction on the remote sensors is over, it is time to look at further improvements on the local receiver.
The code you posted above has given me some food for thought. I was wondering if I should place all the data in one class, with methods to calculate the min and max values or just restrict the parent class to the raw received data and then extend the class to include the min and max values, and all the associated methods.
Without putting a great deal of thought into it, my initial thoughts would be to send the raw data from each remote location sensor just as per my previous example. However, because it was just an example, I fitted both an ID and a Name attribute to give you some ideas, but in all reality, just a small byte for an ID is all you need to recognize the correct sensor at the receiver station based on ID during post processing, and a reporting name can be added then if desired.
You could extend this object with a post processing object to perform calculations to dynamically update the LCD in the loop, ring a buzzer if temp is exceeded, open a flood gate via relay, etc... So it would kind of look very similar to what I previously posted, just with added functionality in the extended sub class, which would become the controlling interface, just like an air traffic controller 😉
Give me some rough code even(pseudo code) of what you envision, and lets see what we can come up with.
This is what I was thinking, in the most simplest of terms:
To handle the incoming data
struct { byte station; float temperature; float pressure; float humidity; float ultraviolet; }bme280data; bme280data myObject; // declare the message object
To create an extended object to store in EEPROM
struct {
// extend bme280data to include the following struct { float MIN; float MAX; } attic = {0.0f, 0.0f}; struct { float MIN; float MAX; } balcony = {0.0f, 0.0f}; } Sensors;
I hope this makes sense.
Hmmm... I don't think it's very different to what I previously posted... the only difference is that I turned Sensors into an array of structures, rather than having 2 identical repeating structures embedded within the same struct... am I missing something? 🙂