September 2019 Update

New! We're moving to the new forum!

ALL new Blog posts will be on the forum.

Please join us there.

This Blog will no longer be updated...

Sunday, June 30, 2019

Bit of a redesign re: Firmware updates

The design of the Grow By Wire system considers a module to be a single device, hence a single module Id. This is true for, say, the web server, which is contained on an ESP8266 board. It is not true for say, the Sensor Module, or Switch Module, which are contained on a Wemos Mega 2560, which contains an ESP8266 built into the board, but they are two distinct devices, connected by a hardware serial line.

What this means, is, a module may consist of one or two devices, or boards...  So far, this has not been an issue, I've simply referred to them as the module (2560) and server (8266). I called the 8266 a server only because it was the access point to the network and database.

Now that I'm doing firmware updates, it IS important to know the board type, since different boards use different methods of uploading firmware. 

So, earlier today I ripped apart everything I had done up to this point regarding firmware updates, and started a fresh design, starting with the database.

With utter disregard for the work I was about to create, I butchered my existing tables and redesigned it so modules now contain boards, and those boards can have their own configuration information (currently related to firmware updates, but this can expand)  Because modules are at the heart of the entire system, almost every program was broken, all the modules were failing, and constantly rebooting trying to get connected...  

Trying not to panic, I just methodically went through each program, made changes where needed, and now I have everything running again.

I also have the new code for the Firmware Updater about half finished, so far it can do local serial updates for regular arduino boards, and serial updates for esp8266 boards. The esp8266 was a challenge, it uses python scripts to do the uploads. I'm happy to say that it's working great, and looks fantastic!


I need to add the code back in to do the serial updates on another computer via the Grow By Wire RPC Server...  Also, the code for Over The Air (OTA) network uploads is there, just needs some testing.










Saturday, June 29, 2019

GBW Serial Terminal - Update #5 (final?)

I added a little graphic indicator for the RSSI values. I wanted to create a custom control, the default progress bar wasn't suitable.



I think that's enough for this project...  it's going to be an extremely useful tool, more so during development, although I'm sure it will evolve into a management tool for the system in the future...


Thursday, June 27, 2019

GBW Serial Terminal - Update #4


Wow, this was meant to be a simple terminal program to follow along with the serial output of the modules....

Well, it's just a tad more...

The latest feature is the addition of the two buttons in the bottom section of the screen, as well as a few cosmetic changes down there...

One thing I liked about using the terminal built in to either the Arduino IDE or the Visual Micro addon for VS2017 is that when I elect to upload, the terminal closes the com port automatically, and reopens it once the upload is finished. Now, with this terminal, I keep leaving it connected, and trying to upload, then have to go find the right copy of the terminal, disconnect, blah, blah...  too much work...  By building the update into the terminal, once I finish, it will handle that automatically :)



When it connects with a module, the module sends it's module Id, and the terminal looks it up in the database, and determines if the module is configured to allow OTA updates (if it is an ESP8266) or USB updates via a COM Port (ESP8266, Mega 2560, Pro/Mini, etc). If the module is not configured to allow these updates, then the buttons will be grayed out and will not do anything.



Tuesday, June 25, 2019

GBW Serial Terminal - Update #3


In the middle box at the bottom, I've added a label "Enhanced Mode" which is visible when the terminal is in enhanced mode as triggered by the module. This means it will send our special tags for color etc.


I also added the "Module Time" label, which is updated by the module sending a tag with it's current time every second. In the past, I would have text displayed from the module that wasn't really informative, but it let me know it was still alive. Sometimes it can be 15 minutes before something actually happens, so this is my way of knowing the module is alive and functioning and not clogging up the display with meaningless messages.

The "Show Tags" checkbox is out of alignment, but that's ok, it's just temporary for testing...

GBW Serial Terminal - Update #2

Just a couple...

I added support for a generic textRGB tag... {{TEXTRGB:0.0.0.255.255.255}}

The 6 numbers are 3 for foreground RGB and 3 for background RGB. This is much better than creating special tags for every color I want to use...


I also added support for a {{REPLACELAST}} tag. It can be anywhere in a line of text, and just before the line is printed, the previous line (last line on display) is removed, so this line in effect, replaces the last...

Here's a great example where this is useful:

[MS] 2019/06/24 07:35:21 Update Sensor Min/Max
[MS] 2019/06/24 07:35:34 12% complete...
[MS] 2019/06/24 07:35:46 16% complete...
[MS] 2019/06/24 07:35:51 33% complete...
[MS] 2019/06/24 07:36:06 50% complete...
[MS] 2019/06/24 07:36:12 66% complete...
[MS] 2019/06/24 07:36:17 83% complete...
[MS] 2019/06/24 07:36:32 95% complete...
[MS] 2019/06/24 07:36:32 Finished updating Sensor Min/Max


Thats a lot of lines scrolling by all the time. It is much neater when it all happens on one line.

First, you see this line...

[MS] 2019/06/24 07:35:34 12% complete...

Then when the next line is processed, and has the tag in it somewhere, rather than print the line after the previous one, it removes the previous, and replaces it with this line.

[MS] 2019/06/24 07:35:46 16% complete...


so rather than the 9 lines above, you would end up with just 2 in the end...

[MS] 2019/06/24 07:35:21 Update Sensor Min/Max
[MS] 2019/06/24 07:36:32 Finished updating Sensor Min/Max

with the % complete showing during the processing, but replaced at the end...



Monday, June 24, 2019

A bit about watering...

I usually have anywhere between 18 and 40 plants, all at various stages of growth from cuttings, to ready for harvest. I tend to grow more small plants rather than fewer large plants (although I'm thinking of changing that, different topic).

If you've followed along, or read up on the system, you know I have a functioning Automatic Watering system, however, it is not installed, I need pumps, hose, fittings, etc...  I did have a perfectly working setup on one plant to develop that project.

So at this point, I still water by hand... BUT, I don't worry about when to water, or even check on the plants to see if they look thirsty.  I am relying on the system to notify me (via the web page, or a notification on my phone) that a plant needs to be watered.  So far, it's been working 100% reliably for months.  I do look in on the plants though, just not on any schedule...

The process has been as follows...

I initially calibrate each sensor, when the plant first goes in the pot, it gets its initial watering, so to start off, I calibrate the "wet" reading, and once the soil dries out, and I water it for the first time (this is the only time that I make the decision) I calibrate the "auto" reading which will trigger the automated watering. From this point on, the system knows when the soil is dry enough to be watered, for this sensor....   That sensor stays with that plant for it's entire life cycle... (I can recalibrate at any time)

So, the Sensor Modules scan their sensors every 15 minutes, and write the data to a MySql database...

The maintenance module runs it's tasks every 15 minutes or so (times are all configurable) and compares the current sensor readings to their calibrated "auto" readings... 

If the current reading is equal to, or lower than the "auto" level, it notes that this plant "might" need watering, and waits for one more reading that confirms it. This will prevent bad data from triggering a watering. Note, this is simply a defensive measure, I have not had a false trigger yet.

Now it has determined the plant needs water...  it looks in the database to see if a pump has been assigned to this plant, and if so, notifies the AutoWater module to automatically water the plant. I'll skip those details.. If there is no pump, then it notifies me using the Blynk App on my phone.  Timing is not super critical, there is easily a window of up to 12 hours...

I go in, water the plant, then on my phone, I select it, and click a button to say that I did in fact water it.

For the Automated Watering system, once it waters the plant, it will also update the database confirming that it did water the plant.

Next time the Maintenance module runs it's tasks, it sees that I watered it, and checks the latest sensor reading to see if it has risen by a configured amount, which would mean that yes, the plant had been watered... This is to ensure that if a plant is automatically watered, the water actually went into the pot, not onto the floor or some other plant...  Just some more defensive design here, I was very paranoid about messing up with the automated watering, as it will eventually be running on all my plants, completely unattended.

Once it see it has been watered properly, it moves the data into a log table for future analysis


Whew! Still with me?  So today's big new feature, the maintenance module now just goes ahead and detects that the plant was watered, I don't have to report it via the phone app..  Just one less thing I have to do... one step closer to complete automation!


Saturday, June 22, 2019

The Misting of the Clones - A Solid Platform


Here's the last post on this project:

https://growbywire.odam2k.net/2019/06/the-misting-of-clones-reality.html


Here's a link to the DIY Page for this project. (Updated with these additions)

https://growbywire.odam2k.net/p/diy-automated-clone-misting.html


Because the servo is fairly heavy, this whole thing just tips over unless it's full of water. I'm also a little worried about how long the water will last in the bottle, probably a while, but, I decided to extend the "pickup tube" through a hole in the side of the bottle. This will allow me to put the other end in a larger reservoir of water. This also allowed me to drill a hole in the bottom of the bottle and screw the whole thing onto a block of wood which will hold everything in place.





Wednesday, June 19, 2019

GBW Serial Terminal - Update #1

Lot's of improvements...

I've added more options, and whenever you change one of those options, they are saved using the properties.settings   It also saves the form size if you change it...

During the handshake with the module, it will receive the modules name, and put it on the form title along with the com port. This helps when you have many terminals open to different modules...

I also added a {{CLS}} tag to clear the screen...  I'm sure I'll be adding many more....

Here's the latest....


This terminal offers all the features (and baud rates) that the Arduino IDE Serial Monitor does...
and more!

I still want to try making it work across the network and allow me to connect to my modules hooked up to another laptop....

You may have noticed the date, 1970/01/01 on the first line with a date...  That's because this is my development module, and doesn't have a clock on it, it gets the time from the MySql database, so until it gets on the network, it doesn't know the time... You notice the identifier on the left side [M03] is for Module 3, and the first line is [M??] because it hasn't looked itself up in the database to know it's own ID.  It looks itself up using it's MAC address...



Tuesday, June 18, 2019

GBW Serial Terminal - First Look

I took the terminal and turned it into a WinForm program, meaning it has a window to run in, not just the DOS window... It also allowed me to add buttons and checkboxes to control it rather than having to use a command line.

The first thing you will probably notice is the color... Yeah!

I used a Rich Text Box to display the data from the serial port, and as I read the data, I process it before writing it to the display. This processing looks for specific TAGS in the stream of data. At the moment, it supports three...

{{HIGHLIGHT}}

{{WARNING}}

{{ERROR}}

Pretty simple, when it sees a tag, it adds the rest of the line (up to a CR) and then SELECTs that text, changes the color, and then continues...

This is written in C# using Visual Studio 2017 Community edition (FREE)



This shows the output from the Maintenance Module, I added the three sample lines just for this screen shot. The colors will be configurable... including the terminal background and text color...

Within the Maintenance Module Code, it's simple to add the color to a line...

Anywhere I want to highlight something...

Serial.print(logDateTime());
if (colorSerialOutput) Serial.print("{{HIGHLIGHT}}");
Serial.println("This is a Highlight");

The boolean colorSerialOutput is set during a handshake between the terminal and the module. Whenever the terminal connects, and it receives data, it will send a command sequence to the module identifying itself, thus enabling any custom features I end up implementing.

I will also try adding the ability to connect to the RPC Server and interact with the serial ports on the laptop in the grow room.Basically right now the RPC server runs the commands to upload firmware to the arduino modules, and takes the output and sends it back to the main program here on my workstation. Having the RPC server open a com port and send/receive data will be exactly the same as I'm doing it here, except instead of sending the data to the rich text box on the form, it will send it back to the workstation via the RPC network pipe...

Since the modules remain plugged in all the time, they are always on the same com ports, even after rebooting everything. It CAN change, but usually only when you plug into a different port... So, that means I can create a database table to hold the com port connection info for each module, and then rather than selecting a com port t the bottom, you will select a module to connect to...

THAT will be cool :)


Monday, June 17, 2019

Monitoring Serial output from all these arduino's

In the grow room I have 4 Arduinos hooked up through a USB hub to a laptop. I can remote desktop to that laptop from my workstation, and run the Arduino IDE to monitor the serial output of any of those 4 modules. In fact, I can load 4 copies of the IDE and monitor all 4 modules at the same time...

Now that I'm programming Windows again, I decided to write my own terminal program to monitor the output...  It's very simple, all it does is open the serial port and anything it receives, it prints out... Other than grabbing the Com Port, Baud Rate, and DtrEnable flag from the command line, that's all there is to it.



I'll have to add the ability to type into it so I can set up credentials, but that should be pretty simple.

Now, the beauty is I can take this code, add it to the RPC Server which runs on the laptop in the grow room, and it can send the serial output back to the Desktop App, how cool is that :)

I can also add color so certain items stand out... maybe even cursor positioning.. I love having so many choices :)

Sunday, June 16, 2019

The Misting of the Clones - A Reality!

Here's my original post:

https://growbywire.odam2k.net/2019/05/the-misting-of-clones.html

Here's a link to the DIY Page for this project.
https://growbywire.odam2k.net/p/diy-automated-clone-misting.html

The point of this little project was to find a way to automate misting the clones to keep the humidity up while they are rooting...   Right now I do it whenever I think of it, probably every 6 hours or so...

I wanted to find a way to automate it so it could just give a couple spritz's every hour or so...

It looks like this will work, I'll need to set up something on the "switch module" I guess, that sounds like a logical place, it will just toggle a servo to/from set points every x minutes...

Anyhow, here it is...





Saturday, June 15, 2019

Watering Time Predictions - Final Thoughts

Knowing  how long I have until a plant will need to be watered, even a rough idea, will allow me to be comfortable going away for a couple days, even without the automatic watering. While the accuracy of these predictions is still up in the air, I'll get an idea of how accurate they are over time when they are actually watered.

In the mean time, I've added the "Time Until Watering" to the bottom of each of the information boxes for the plants on the web page showing the grow room overview (text in blue)...


Watering Time Predictions - More of a guideline....

Turns out that getting very accurate predictions is beyond my ability, mathwise... well, at least I don't know how to calculate the time because the soil moisture depletion is not linear as I had thought...

If you look at any of the graphs, you will see this (this is the monthly graph)


From the peaks (plant was just watered) to the lowest point (plant needs to be watered) it's a straight line, or a linear decline.  I based my calculations on this decline being steady, and linear...

You can see a sharp drop at the beginning on some... That means for the first bit the drop off is very fast, which means the calculation of average decline will be skewed...


Now, lets look at a weekly graph of the same plant...



This is the most recent watering cycle, the one our calculations would be based on. You can see the initial decline is faster, then it steadies out... It looks like a fairly significant drop... (I haven't looked at the log files yet)

There are also some flat spots, which means the value didn't change for a period of time...  This causes the prediction to waver. Let's look at an example...

Just making up some numbers here...

  • At 4am the sensor reading is 270 and the autowater trigger is 250, so 20 more to go... After looking at the average decline, it determines it will need watering in 3 hours, at 7am
  • At 4:15 the sensor reading is the same, there is still 20 more to go, and it will still take 1 hour, and need watering at 7:15
  • At 4:30 the sensor reading is the same, there is still 20 more to go, and it will still take 1 hour, and need watering at 7:30
  • At 4:45 the sensor reading is the same, there is still 20 more to go, and it will still take 1 hour, and need watering at 7:45


You can see how the predictions can waver during times when the reading doesn't change... Keep in mind, the soil is still drying out, this is just a limitation of the sensors sensitivity.


Now let's look at the Daily graph for the same plant...


Wow, it's sure flattening out at the end...  that's really causing the predicted time to slide... Here's the actual predictions from the log...



In just over 13 hours of logging, the prediction has slid 7 hours...  

The plant was actually flagged for watering at 3:37am

So, since trying to figure out the math to accommodate the non linear moisture decline is beyond me, I'll just leave it as is, and consider if more of a guideline... :)  It will make a useful tool just to give me a heads up of what's going to need watering over the next couple days... This will be handy if I want to go away for a couple days, I can top up all the plants, and then see that I've got x number of days (roughly) and if AutoWater is set up, that will take care of the first couple that need watering...

All in all, I think it's still a very cool feature.

Ooops...

I recently ran a registry cleaner on my computer, and while I don't know if it caused it, but I started getting a weird message whenever I compiled c++ programs for the ESP8266 using Visual Micro and VS2017.


arduino\java\bin>rem cannot sign on windows

I have no idea what it means, and I can't find anything on google... 
Programs still compiled, and worked fine, but I hate when something changes and I don't understand it... I have no idea why it happened, or what it will affect. Obviously it will affect something, or they would not have had it display that message, right?

Well, I figured I'd re-install the esp8266 boards in the board manager and see if it fixes the problem...

It did!   The message is no longer displayed...

However, I had modified the HTTPUpdateServer class to display some extra info when I do an upload/update. Here's the nice screen...






and with the re-install, I'm back to this:





This doesn't affect the windows desktop program that I just wrote to do these OTA updates, so I'm not really planning on using the web browser unless I need to for some reason. The reason I made the changes to the library in the first place was so I could ensure I was uploading the right firmware to the right modules...  It was a good visual check to compare the filename selected against the name displayed...

I don't need those visual clues any more since the desktop program knows which file to send to which module, it's apparently smarter than I am :)


Friday, June 14, 2019

Watering Time Predictions - Better results?

I'm not absolutely sure why that didn't work better, the theory seems good...


So I grabbed a piece of paper, and started figuring it out on paper, I tend to do that a lot. Model the problem in layman's terms without a computer. Turn it into a word problem, and then it's a lot easier to turn it into a computer function...

So, here's the new plan...

All of this information can come directly from the database...

AutoWaterSensorReadingTarget: 220
CurrentSensorReading: 439
TimeSinceLastWatering: 7437 minutes ago
SensorReadingAfterLastWatering: 708



With that information, we can calculate the rest.

Definitions:

ChangeSinceWatered: how much has the sensor value changed since it was last watered
ChangePerMinute: on average, how much does the value change every minute
UnitsToGo: how many Sensor Reading "units" to go until we reach AutoWater Trigger
MinutesToGo: how many minutes until we reach AutoWater Trigger

Calculations:

ChangeSinceWatered = SensorReadingAfterLastWatering - CurrentSensorReading
ChangeSinceWatered = 708 - 439
ChangeSinceWatered = 269

ChangePerMinute = ChangeSinceWatered / TimeSinceLastWatering
ChangePerMinute = 269 / 7437
ChangePerMinute =  0.0361704988

UnitsToGo =  CurrentSensorReading - AutoWaterSensorReadingTarget
UnitsToGo = 439 - 220
UnitsToGo = 219

MinutesToGo = UnitsToGo / ChangePerMinute
MinutesToGo = 219 / 0.0361704988
MinutesToGo =6054 (Roughly 4 days))


I think this will work better, I'll let it go for a while and watch the logs...


Watering Time Predictions - will it work?

Hmm, not looking good... but it was the very first iteration,..



Considering this was only a 4 hour window, there's a lot of fluctuation in the estimates.

I have no idea why this is so....

I will have to do some extra logging so I know how it is arriving at those estimates...


Watering Time Predictions update

I just couldn't let this go, so tonight I've been playing with the idea of predicting when a plant will need to be watered.

Here's the output from my maintenance module....

[MS] 2019/06/14 00:40:20  Processing Plants - Check Watering Status
[MS] 2019/06/14 00:40:21  Plant #81 will need watering in 07h 51m
[MS] 2019/06/14 00:40:23  Plant #87 will need watering in 8d 17h 14m
[MS] 2019/06/14 00:40:38  Plant #86 will need watering in 1d 00h 15m
[MS] 2019/06/14 00:41:25  Plant #69 will need watering in 1d 08h 35m
[MS] 2019/06/14 00:41:36  Plant #83 will need watering in 6d 02h 07m
[MS] 2019/06/14 00:41:46  Plant #85 will need watering in 2d 11h 20m
[MS] 2019/06/14 00:41:46  Finished Processing Plants


Keep in mind, this is a first shot at this, and I have no way of knowing how accurate this will be until I let it run for days, or weeks, logging all the estimates, and actually comparing them to the actual time it determines they need watering.

I am pretty confident in the numbers, however something I had not considered originally is this...
Current Value: 450
Trigger Value: 200

The difference is 250, so we add that to the current value and get 700
What if the max value for that sensor in the log is 650? There will be no readings in the log file from which we can extract a date and time.

We cannot predict the time remaining if the sensor is reading more than about half way between the configured automatic watering trigger value, and the max reading in the log which would generally be when it was watered.

The closer we get to the watering time, I think the more accurate it will be, but we'll know once I start logging it and then looking to see how close it is, and whether the accuracy does change over time.

I'll log the plantId, the currentValue,  estimatedTime, and the actual date/time it is predicting... 
I'll be able to watch that last date/time to see how it fluctuates... and at what point, if any, was it not accurate.

So, it looks like another successful adventure, at least so far!

Thursday, June 13, 2019

Watering Time predictions...

Since the system is not yet doing the automatic watering, it just notifies me when a plant needs to be watered. Auto Watering is just waiting on funds for the rest of the pumps etc...

The issue I had with the notifications was while I'm working away, usually in the middle of the night, when, coincidentally, the lights are out in the flower tent, it would remind me every 30 minutes to water the plant... Well, I can't, it's lights out time...   So, for each "location" (Clone, Veg, Flower) I added a flag for "restrictedAccess"  and a start and end time, soif the lights are off, it won't send me the reminder... but as soon as the lights come on, it starts again :)  Great feature...

Anyhow, to get back on topic here, I'm thinking that rather than waiting for a notification to pop up, I think I can actually predict an ETA until it's time to water...

Since I'm logging sensor readings every x minutes (every 15 minutes right now) and I know the current sensor reading, and the reading which will trigger the watering notice, I can deduce how many "units" are left until watering is triggered..

Current Sensor Reading:  224
AutoWater Trigger Reading: 200

So we have 24 to go until it triggers the watering notice.

If our log, going back in steps of 15 minutes, looks like this:

Now: 224
-15 min: 227
-30 min: 230
-45 min: 235
-60 min: 239
-75 min: 243
-90 min: 248
-115 min: 253


We can see that the current reading (224) PLUS 24 = 248 - this puts us exactly in the middle right now, so the time since it was 248 should be the same as the time it will take to go the rest of the way to the trigger value...  We can see it was 248 an hour and a half ago (90 minutes)

So, we can safely estimate this plant will need to be watered in 90 minutes...

That will scale up, so we will be able to determine how many days it will be, not just minutes...

Want to know if you can go away for two days? Grow By Wire just might be able to tell you :)

Wednesday, June 12, 2019

One less thing to worry about...

I picked up a brand new 600W HPS Light (Magnetic Ballast) to replace a very old 400W MH Magnetic Ballast Light.

The new 600 HPS went into the Flower Tent (replacing a 400W HPS Light with Digital Ballast), and what a difference! I can almost watch the buds grow :) 

The 400W HPS that was in the flower tent is now in the Veg area with the MH bulb in it since it's interchangeable... I do need a new MH bulb, I can see this one is much dimmer than it should be...

My old ballast got really hot, I actually ran it on a Fireproof LIPO Battery Charge Bag, and it was a good thing too...

1819829


I keep in in this little plastic tub to ensure it doesn't get wet...

But, the heat melted through the tub, and really baked the plastic...

1819832



Monday, June 10, 2019

C# - let's look sharp!

The windows desktop program is only a couple days old, and it's already getting to be a mess...  Sometimes I get a little excited when first trying something out, and I don't always take time to do things the right way, I tend to take shortcuts.

I need to clean it up before I get too far gone! 

I need to think about the architecture before it's too mangled...

First job is to create a proper Data Access Layer. Keep in mind, my knowledge of best practices is over 10 years old, so I'm not familiar with newer methodologies, nor am I interested in learning them... (famous last words)

I was a big fan of tableAdapters, however, the MySql connector for Visual Studio causes an error when you try to create tableadapters using the wizard.

So, next best thing, I'm creating data access classes, one per table (or object, like  Plant) These will be separate dll's and present methods which return data in various ways, encompassed in a DataSet, DataTable, or DataRow.

To get a data table containing all plants, with all fields, simply instantiate the Plant class, and call the getPlants() method:







This saves the repeated overhead of managing database connections in the main program whenever it needs to load data. The Plant class will also provide data resulting from views combining Pant data with other tables, such as mapping which sensor is used, where the plant is located, etc, so different methods can provide different table schemas, but they are all strongly typed.

Saturday, June 8, 2019

GrowByWireDT - Edit Plants

One of the features of the web pages that I use the most is working with plants in the database. I need to be able to easily add new plants when I take clones, and assign sensors to them, assign them to a plot in the garden, etc. 

Here is the new Windows Desktop version...  I'll be able to add/modify plants, module, sensors, and location data.   So far, it just loads the plants data, and allows me to edit it, but not save changes yet...



Here is the Web Page... This will probably be removed to conserve code space on the web server...

first, select a plant



then view/edit the plant...


It can be quirky, but it does work...





Friday, June 7, 2019

GrowByWireDT - Windows Desktop Interface

The windows program, now officially called GrowByWireDT (where DT=DeskTop), in addition to updating firmware, will eventually become the primary interface into the system.

The Web Server will continue to provide the ability to "see" what is happening, but I won't be doing any more development on editing configuration data.  Right now, the WebServer code is just barely over 50% of the size of available memory. This means I am unable to do OTA firmware updates over WiFi, since it needs room to upload the new file, as well as maintain the old version until the new one is in place. If I can remove a bit of code used to configure stuff, then I can go back to OTA updates...

So the windows program will probably be my focus over the next little bit, at least till I get bored and move on to something else :)

Updates to updates on the updater...

This firmware updater is amazing, it will save me so much time, and I never have to worry about uploading the wrong software to a module.

I managed to get it to spit back the output from avrdude.exe to the Windows Client, line by line, in real time. Originally it would send it as a large string AFTER it actually completed. This left a huge lag where you had no idea if it was doing anything...  Now, as soon as you click the button, you see some output from the other computer...

If life was all rosey I suppose I'd be done, however, there's a problem (isn't there always?)...

It's a little flakey....  On the client side, after a few loops (requests for updates) it seems to want a keypress to continue...  Now, there is a spot that checks to see if a key has been pressed, and if so, reads it. If it's an ESC key, then the program closes the network connection and quits... There is nowhere in the code that it would block, waiting for a keypress...  I've had a really quick look for the problem, but I'll have to spend some time on this one, either that, or perhaps I'll just stumble across the answer :)


The buttons have been moved to the left side, this way I can fit up to 21 buttons, actually, they already exists, but are hidden unless I need them. When this program loads, it checks the tbl_modules table in the database to see which modules support OTA updates, and which have batch files set up for firmware updates. So the buttons are dynamic, you can modify their behavior in the database.


I suspect in the future, I may want to allow it to contact multiple RPC servers so it could update modules on different remote computers...


Thursday, June 6, 2019

OTA Firmware Updates Update...

Yep, an update about the updater... :)

As you can see, when doing an OTA update of an ESP8266, it is now grabbing the response from the ESP module to confirm that the update was received correctly, and the module is rebooting... Same response you see when you use a browser.



All in all, not bad for a days work considering I haven't used C# in over 5 years. 

Surprisingly switching between C# and C++ has been seamless...


Success: Arduino Firmware Updates on remote computer...

Some screen shots...

The welcome screen...




Uploading firmware to the httpUpdate server on the ESP8266 via WiFi. Currently there is no info returned, so you don't even know if it was successful. I'll look into that in the near future...



Finally, my pride and joy, updating firmware on a Arduino Mega 2560 which is hooked up to a USB port on a computer in the other room.


This actually returns the output from the batch file run on the remote server so you can see exactly what happened.

At this point, I'll add some more buttons, set up a config table for it so I'm not hardcoding anything, give it a quick test, and then find something else to work on for a while...

Update: Arduino Firmware Updates on remote computer...

On the left, the main windows program for updating firmware on the modules...  The right, is the server running on the laptop in the growroom.



That laptop has a USB hub attached, and all modules in the grow room are plugged into it. This includes

Sensor Module #1
Sensor Module #2
Switch Module
Auto Water Module

I'll be able to click a button on my main windows machine (dev laptop), and it will do an RPC (Remote Procedure Call) to the laptop in the grow room and call avrdude to update the module with the right parameters...

At this point, you can see that the main program does in fact call the server and passes it the info on which module to update. It is hardcoded for module #1 right now, but it does actually run the batch file which in turn runs avrdude, and it DOES UPDATE the arduino!

This is a game changer for me...  I can attach any arduino to any computer on my network, and remotely maintain the software on them. I'm sure once I've thought about it, I'll find lots of other things I can do too...


Wednesday, June 5, 2019

Arduino Firmware Updates on remote computer...

In order to update the Arduino code via USB on the remote computer, I've created GBW_RemoteServer.exe, a console app written in C# which is an RPC Server, and when it boots up, it gets its local IP address, updates a table in the database with it's IP Address and then sets up the listener on the machine, and waits for a command from the main program telling it to run avrdude with the parameters required to update a specific module...

1814818


Got the server working up to the point of waiting for a command from the main windows program running on another computer (see previous post)

It will be simple for now, no security (my network is not exposed) and a simple command with a moduleId, which will be used to look up the full command line for avrdude to upload the proper file to the proper module, on the proper com port. Once it's functioning, then I'll add some simple security, and maybe more functionality...

OTA Updates made even easier...

I do OTA updates on my ESP8266 units in the grow room, and currently do so using my browser. This entails going to the right URL, picking a file to upload, then clicking the button...  That's pretty simple, but it means having to pay attention to which module you are updating, and getting the right bin file to upload, since they are all in different folders, you generally need to go to another folder to find the right file.

If you end up installing the wrong code, you simply reinstall the correct code, no harm done...

To make this process even easier, I'm writing a Windows desktop application in c# which will, at the push of a button, upload the correct file to the correct module. 

I have a console app right now that does the update, this is my Proof of Concept, and now I'll spend some time trying to remember C# (I used it for years when I was working) and create a simple form with buttons for each module, which call code to update the module with the correct software...

I expect I should have something functional tomorrow to post screen shots.

Activity Journal - keeping track of the little things...

A while back, I created a table in the database, just as a place to go manually enter stuff I didn't want to forget, such as info about clones, plants, sensors, almost anything.

Recently, I decided to add the ability to view, and create new entries via the web server.

Here is a Table of Contents view, the threads are listed newest to oldest...



There is a place at the top to enter a NEW thread...   If you want, you can view the replies to a thread via the link on the far right.  If there are no replies, then it will allow you to reply to the original thread... If there are replies, you will see the following screen...



This will list all entries in a thread, listed oldest to newest... At the bottom is where you can enter a new post in this thread.

This is a very basic system, and while it may expand in the future, I kind of doubt it, it functions, and does what it needs to do...






Sunday, June 2, 2019

Continue the Code Review

It's been half a week, I'm continuing with my so called "Code Review" which has basically turned into "Go through all the code, and clean it up, make it more efficient, use less memory, and move more methods into the Utility library".

I've also standardized the boot up screens displayed to the Serial monitors:

=> Grow by Wire Sensor Module
=> Mega 2560 Code Compiled on Jun  1 2019 at 06:53:57
============================================================================
=> You have 10 seconds to enter a C to Configure credentials
=> Times Up!
============================================================================
[M??] 1970/01/01 00:00:14 > ESP8266 Code Compiled on Jun  1 2019 at 05:15:48
[M03] 2019/06/02 10:40:42 >   Free Memory : 1.20KB
[M03] 2019/06/02 10:40:42 >          SSID : odam2k_primus
[M03] 2019/06/02 10:40:42 >     Host Name : SensorModule3
[M03] 2019/06/02 10:40:42 >   MAC Address : CC:50:E3:0C:7C:07
[M03] 2019/06/02 10:40:42 >   IP Address  : 192.168.1.23
[M03] 2019/06/02 10:40:42 >   Subnet Mask : 255.255.255.0
[M03] 2019/06/02 10:40:42 >    Gataway IP : 192.168.1.1
[M03] 2019/06/02 10:40:42 >   RSSI        : -58dBm (84%)
[M03] 2019/06/02 10:40:42 >   Sensors     : 0
----------------------------------------------------------------------------



All modules now use the configuration screen to set and store connection related credentials so nothing is hardcoded, with the exception of the Blynk local Server IP and Port, which I will store in the MySql Database.