Arduinos In The Grow Room: My Project

Wow, that was a simple enhancement... Thanks @Latitude17 I'm glad you persisted :)

They are talking back and forth over the I2C lines (SDA/SCL), the Mega 2560 simply issues a request for data and the pro/mini just does a write of the 2 integer values (top and bottom reading) which the Mega picks up via a Read. It can't get much simpler than that!

I'm just hardcoding those values right now, but I'll add some code to the I2C module to toggle the digital pins to provide power for each of the 2 sensors on the probe, and read A0 to get the values, which will simply be returned to the Mega 2650.

The unknown part is done, I learned something new, and have another tool in my toolbox should I need it in the future :)

Now, to plan full scale production of up to 30 of these probes... btw, gonna call my sensors Probes now rather than sensors... (more code and db changes) since Probes can now have multiple sensors... I also think I'll stick to using the Pro/Mini's for the I2C interface since I already have about 10 of them, and I can order them from Banggood, 10 for under $30 Cdn. $3 each isn't a bad price... Also, they are small, easy to program, and have plenty of I/O pins. I can actually just solder the wires directly to them, and put them inline on the wire, wrap em in shrink wrap, and you'll never even notice them...


BTW, I was so excited about all this, I only slept for an hour last night!
 
The second "probe" is finished...

Capture.PNG


The Pro/Mini makes for a nice compact I2C interface...

It's so easy to add it to the system, all I need is the I2C address, no worries about which pins to toggle for power, or to read the sensor, that's all handled internally by the I2C Interface...


I set it up so the master simply writes a 1 to the I2C bus with the address of the probe, and the probe goes off and measures the two sensors. The master waits for one second, then does a requestFrom the I2C address, and the slave sends the readings.... can't get any simpler than that!

@Latitude17 I can't thank you enough!
 
Just a quick note, while we're on the topic of "sensors" here... I know these resistive soil moisture sensors are prone to corrosion, but I have taken some steps to deal with this. The corrosion happens when you have a DC current flowing from one metal to another through the soil. I mitigate this by only applying power for milliseconds while actually reading the sensor. Corrosion also happens just from having the metal sitting in moist soil, so it cannot be stopped completely, however, it's the DC current that's the biggest cause. I keep track of how long each sensor is powered, and keep a running total in my database for that specific sensor. Right now, these numbers are meaningless, but as I detect actual corrosion on a sensor by visual means, or sensors start to fail, I will be able to correlate between failure, and the amount of time that sensor has been powered. At least that's the plan :)
 
One last issue with these I2C modules, and that is address assignment. Because the code needs to assign a different address to each physical module for the I2C bus, right now, it is hard coded as a #define and I have to remember to change it every time I upload code to a module to make sure it is unique, and the correct one to identify that sensor...

I had the same issue with the module ID for each of the Mega 2560's, it was hard coded, and I had to change it all the time. Of course, I'd forget to do so, and it became a nightmare. To solve the problem, I took advantage of the fact that ALL my modules were Wemos Mega 2560's with on board ESP8266 modules providing WiFi connectivity (and MySql connectivity).

To take advantage of this, on boot up, it looks up the module ID in the database based on the MAC address of the ESP8266, which is always going to be unique. Works like a charm...

I don't have that option here, so I'm trying to think of possible solutions...

The only one I've come up with is to use EEPROM to store the address once, and have the sketch load it when it runs. The problem with this, the EEPROM gets erased when you upload a new sketch. To get around this behavior, you can set the EESAVE fuse using the ICSP header, which on the pro/mini is available on digital pins 11, 12, and 13. So the procedure would be, for a NEW sensor, modify the fuse byte, then run an initial sketch that writes the HARD CODED address to EEPROM. This only needs to be done ONCE. Next, upload the "working" sketch which can read the EEPROM and join the I2C bus with the stored address. Now whenever you upload new code, it won't erase the data stored in EEPROM.

Any other ideas? Keep in mind, the address MUST match the "Sensor ID", since each Sensor has to be addressed specifically (I need to know which sensor I'm reading).
 
Tead said:
If you could control power to them without any sort of ID tracking, you could power one on, read it's ID, move on to the next one, rinse wash repeat.
Click to expand...

The problem is assigning that ID to the i2c module in the first place. I'm not able to individually control the power to each i2c module (pro mini) They draw too much current to power them from a digital pin on the Mega (besides, I can have 114 i2c modules, so not enough pins to do that).
 
Well, you know what they say, don't believe everything you read on the internet...

Seems that EEPROM data IS preserved when uploading new sketches, at least in my case. I decided, given the limited options, to just go ahead and give it a shot, and it works fine without messing with Fuses and the ICSP.

Now, perhaps I have some setting that allows this, I have no idea. I do use the Visual Studio 2017 IDE (with Visual Micro) rather than the Arduino IDE, perhaps there is something inherent in these tools that makes this work. I'll investigate more as time permits, but for now, I've got some coding to do, PROBLEM SOLVED!
 
Tead said:
I was kind of confused a bit by your previous EEPROM words. EEPROMs are actually designed to hold data without power... that's their magic after all. The ICSP process is used to overwrite the code (sketch).
Untill you do the ICSP, it should be holding onto whatever sketch was last loaded.... no?
Click to expand...


You are correct, data is stored even during a power down. According to articles I had read, the EEPROM was erased when you UPLOAD A NEW SKETCH. To me, that sort of made sense. I can't find the link again :(

Found it, here's the article I read....
retain eeprom on sketch upload
 
Read the thread. Thanks.

So... lemme translate some of this into my kinda lay-words. I'm a bit of a fish out of water about the details of the subject, but I've been exposed to some over the years. Help me thru it here.

EPROMs... the simpler brother of the EEPROM, simply stores a set of instructions (sketch). You erase them with UV, then write a new set of 1's and 0's.
The EEPROM is a twist on this. It allows you to trip a fuse and overwrite the existing load of 1's and 0's.

So, I kinda don't see any issue unless you change the physical configuration and need to reprogram the EEPROM.
I'm missing something... I know I am. Dammit.... I started a discussion and I'm in over my head. Meh... I'll learn.
 
I'd be in over my head trying to explain memory usage on the Arduino :) When I refer to EEPROM, I'm talking about the ability to store up to 512 bytes of data in a non volatile memory. This is in addition to your sketch, which is also stored in non volatile memory, so it's still there when you power down/up... I've not had much of a reason in the past to store data in EEPROM (EEPROM also refers to the library that you use to access this memory space) I'd just hard code the data in the sketch. When you upload a new sketch, the data is part of the sketch... In my experience, an Arduino is used over and over to do different tasks, you might buy a couple, and use them in many different ways, so for example, today I use it to control some LEDs, tomorrow to water my garden. Uploading the new sketch should (intuitively) provide you with a clean slate for it's new task. This is why I was easily led to believe that uploading a new sketch would also clear out your data from the EEPROM memory, that it was done on purpose... The first half of the thread I linked to seems to support that line of thought, that your data would be erased, and a clean slate provided... Had I read the entire thread, I would have seen people stating that this was not true, and your data was NOT erased. Of course, I discovered the truth by actually trying it myself :)

You aren't missing anything, I was simply wrong, and should have known better than to trust the internet without testing it myself. I still think there is a setting somewhere that I just haven't found, since many people refer to it, to "preserve eeprom during sketch upload", or if you like, the opposite of "erase EEPROM data when uploading new sketch"
 
Yep, and that might normally be an option, but in this case, I'm using an Arduino Pro/Mini as an I2C Controller for a soil moisture sensor. It's only job is to listen for a request from the main module for the reading from the sensor. There will be one of these for every pot of soil, in my case, up to 40 of them. The idea here is to keep it as small as possible, and cheap :) Every one of these I2C controllers will run identical software, with the ONLY difference being the I2C Bus address. I'm trying to get away from having to compile a special version for every sensor just to change the address. These soil moisture sensors are just a small part of my overall project. The whole reason for doing this, is simply as an exercise. I have no end goal, it will NEVER be finished, or polished, or for sale, etc. No profit motives, it may be that it never even works as planned, but it's the journey, not the destination :)
 
I started with mini's and am just a bit ahead of you in your journey of hardware discovery. You're going to end up with an ESP8266 (like a NodeMCU) for just about the same money per unit and WAY more feature-rich. Added bonus of built-in wifi and bluetooth. I utilize the over-the-air (OTA) update mechanism via WiFi and love it.

As far as the i2c wiring, I opted for a IP66 rated CAT6 ethernet cable (solid strand). Single/clean cable run and lots of options including power-over-ethernet (PoE) if you wanted. I do not use it for actual ethernet traffic, mind you. ;)

Glad you're diggin' it!
 
I update the ESP8266's on the Wemos Mega's using OTA. Since they are in the grow room, and I'm not, this makes it much easier. I even went as far as plugging the two Mega modules into a laptop using the USB so I can do a remote desktop to the laptop, and using batch files, upload the binaries I've compiled onto the Mega's themselves. I also have a couple standalone 8266's, one of which is my Web Server....

I did try setting up some regular Arduinos with Bluetooth OTA update, but didn't get very far, and didn't persist, but it is feasible.
 
Tead said:
Is there any sort of unique piece on the I2C controllers? One could imagine appending that info to the bus data. Something like a MAC address or whatever.
Click to expand...

The hardware address on the device that he's assigning, acts similarly to a MAC address. In this case it's much abbreviated and local (i.e. 0x68) versus globally unique 8-bit MAC (i.e. 00:0a:95:9d:68:16). Appending the info to the bus would require them ALL to parse it and ask "is this for me?", instead of relying on the static assignment and keeping it simple.
 

Similar threads

B
Arduino Climate Control
2 3 4 5 6 7
Replies
130
Views
23K
Brother T
B
OG13
Arduino based room controller
12 13 14 15 16 17
Replies
337
Views
149K
killersmile
K
C
GrowOS - DIY Arduino CO2/Temp/Hum Automation
2
Replies
23
Views
20K
The Happy One
The Happy One
DrewT
Software platforms for garden automation
Replies
14
Views
2K
ducknaldo
ducknaldo
Teleon
Weatherstation 2.0
Replies
4
Views
1K
Teleon
Teleon
Back
Top Bottom