Don't do what I did

[ivory420]

Good quality electronics, when used properly, ARE the difference between a Hobby Grow and a Professional Grow. The setup described is fairly advanced and I would not classify it as a Hobby Grow.
If you want to grow like a professional then you have to embrace the latest techniques in horticulture.
The below will help the grower to maintain control over the growing environment:

• automating your lights
• automating your feeding/watering
• automating the airflow
• automating the environmental controls

So DO embrace automation and technology to make your life easier
BUT
DON'T DO WHAT THE ORIGINAL POSTER DID!
In Order of Importance:

1. Don't use untested technology - unless you're the one testing it and then you cannot complain about the results.
2. Do have a reliable backup when testing new technology
3. Do post your results for peer review and so people know what works and what doesn't

 

[Bishop12]

In Order of Importance:

1. Don't use untested technology - unless you're the one testing it and then you cannot complain about the results.
2. Do have a reliable backup when testing new technology
3. Do post your results for peer review and so people know what works and what doesn't

@ivory420 great advice! From my own experience, I would also add that when investing in any tech that collects data, make sure that it allows you access/download your data in some format (e.g., csv, json, etc...). In other words, try to stay away from products that lock you into proprietary data formats or make you pay additional fees to access your data.

 

[craggin]

It's a Raspberry Pi 4 model B. I had originally started with a RPi Zero W, which works great, but I've been playing around with using Redis to store the sensor data for the dashboard and Redis requires a 64-bit OS.

I first started with RPi 3B+, but recently switched to a 4B (4G). BTW - Redis does run on 32-bit. Maybe it's because I opted to run it in a Docker container. In either case, 64bit on RPi4 provides the best performance given all the processes I'm running. I've also moved TSD out of Redis and into QuestDB. Both running in Docker so I don't have to actually install the bits directly. Like you - I write all my own code...

 

[Bishop12]

I first started with RPi 3B+, but recently switched to a 4B (4G). BTW - Redis does run on 32-bit. Maybe it's because I opted to run it in a Docker container. In either case, 64bit on RPi4 provides the best performance given all the processes I'm running. I've also moved TSD out of Redis and into QuestDB. Both running in Docker so I don't have to actually install the bits directly. Like you - I write all my own code...

That's awesome! I'm going to look into QuestDB. I've been thinking about switching from redis to InfluxDB, which MyCodo uses. Do you have any experience with that db? It's the darn RedisTimeSeries module that doesn't quite work with 32-bit board. In hindsight, I probably should have just picked a db designed for time series. Live and learn!

Recently I've been playing around with PID controllers-- very cool. I've recently started to try training machine learning models to integrate into the PID (inspired by this: https://towardsdatascience.com/emulating-a-pid-controller-with-long-short-term-memory-part-1-bb5b87165b08). Progress has been slow, but fun.

 

[craggin]

That's awesome! I'm going to look into QuestDB. I've been thinking about switching from redis to InfluxDB, which MyCodo uses. Do you have any experience with that db? It's the darn RedisTimeSeries module that doesn't quite work with 32-bit board. In hindsight, I probably should have just picked a db designed for time series. Live and learn!

Recently I've been playing around with PID controllers-- very cool. I've recently started to try training machine learning models to integrate into the PID (inspired by this: https://towardsdatascience.com/emulating-a-pid-controller-with-long-short-term-memory-part-1-bb5b87165b08). Progress has been slow, but fun.

Yeah, I've used InfluxDB a little bit, but thought of it as too heavy for my use case. I stumbled on the QuestDB and giving it a serious look. If it doesn't play out well, then I may go back to Influx.

 

[MAGpie81]

This year I decided to leverage cloud-based automation in my grow room, and it turned out to be an absolute failure. Here are the issues I encountered in case anyone else has similar non-brilliant ideas.

1) I wanted to use a smart plug to monitor power usage plus schedule on/off times using a Kasa (TP-Link) plug. While the monitoring was cool, it only really made sense for the first couple days since the values won't change. 12 on 12 off uses the same power every day. Herin lies the first bad experience. 2 nights ago, the schedule did not kick off, so the girls were left in the dark all night. Back to mechanical and I won't look back.

2) This issue was even worse than #1. I had a space heater on a smart plug and a Netatmo weather station in the room. Once the weather hits 78 degrees Fahrenheit IFTTT sees it and shut off the plug hooked to the heater and once it hits 72 it turns the heater back on. Well, IFTTT appeared to not be functioning properly since 12/7/21 @ 11:45 PST while the heater was on damn near frying my plants. IFTTT just lost a subscriber for life. Once "MATTER" is a thing IFTTT will become irrelevant Imo. Cool service though.

Fortunately, I had many alerts setup using other IoT devices to notify if temps are off and caught it.

Point is, do not, never ever rely on cloud services to automate your grow room, tent, etc. It will fail someday, guaranteed.

Thanks for the info- I thought about using one of those smart plugs, too! Glad I have not.
I did once accidentally discover that one of my Titan timers had a “random” setting (probably for house lights so burglars can’t observe on/off pattern while you’re away) that got switched on somehow.

 

[craggin]

Thanks for the info- I thought about using one of those smart plugs, too! Glad I have not.
I did once accidentally discover that one of my Titan timers had a “random” setting (probably for house lights so burglars can’t observe on/off pattern while you’re away) that got switched on somehow.

Well, I hope my foray into trying these Kasa TP-Link Smart Plugs doesn't go south! But, I'm not using the their Wifi app, nor allowing the device to talk back to their "cloud" service. Maybe that'll save my butt. I found a link (can't seem to locate it now) that showed commands you can send to the device. One of these commands allows you to point it at a fake endpoint on my own network so the "cloud" cannot interfere, nor provide the mfgr with my usage data. I'm also running them on a dedicated Wifi network provided by my controller - again, in hopes that nothing interferes with proper operation. However, this post got me to thinking about possibly never controlling anything that might cause crop failure if the device doesn't turn on/off as expected. Not even sure that's possible...

The metering data is very useful for gauging overall power consumption for all connected devices, but once your value has been identified that feature becomes less useful (someone else here already said as much).

As a side note, I'm currently coding a "bootstrap" mechanism so that if I do lose power or have a glitch that hiccups my system, it'll be smart enough to restore proper operational conditions in the moment.

 

[MAGpie81]

Well, I hope my foray into trying these Kasa TP-Link Smart Plugs doesn't go south! But, I'm not using the their Wifi app, nor allowing the device to talk back to their "cloud" service. Maybe that'll save my butt. I found a link (can't seem to locate it now) that showed commands you can send to the device. One of these commands allows you to point it at a fake endpoint on my own network so the "cloud" cannot interfere, nor provide the mfgr with my usage data. I'm also running them on a dedicated Wifi network provided by my controller - again, in hopes that nothing interferes with proper operation. However, this post got me to thinking about possibly never controlling anything that might cause crop failure if the device doesn't turn on/off as expected. Not even sure that's possible...

The metering data is very useful for gauging overall power consumption for all connected devices, but once your value has been identified that feature becomes less useful (someone else here already said as much).

As a side note, I'm currently coding a "bootstrap" mechanism so that if I do lose power or have a glitch that hiccups my system, it'll be smart enough to restore proper operational conditions in the moment.

Oh yeah- Also with my Titan timer I found it was turning on/off ten minutes before schedule, even though I checked the time and timer settings a few times. Wasn’t necessarily a problem but I had to hard-reset to go back to normal function

 

[MisterKister]

You guys should really look into the bluelab pro controller w/ connect and m4 peripods. Is it pricey yes! But does it save you hours of headaches trying to program everything yourself? Absolutely!

 

[Bishop12]

However, this post got me to thinking about possibly never controlling anything that might cause crop failure if the device doesn't turn on/off as expected

This is exactly why I moved any "mission critical" components to mechanical controllers (eg, lights and primary fan). I failed to put a check in a routine when I started and it kept the lights off with humidifier on full blast

You guys should really look into the bluelab pro controller w/ connect and m4 peripods. Is it pricey yes! But does it save you hours of headaches trying to program everything yourself? Absolutely!

That's the best part!

 

[MisterKister]

This is exactly why I moved any "mission critical" components to mechanical controllers (eg, lights and primary fan). I failed to put a check in a routine when I started and it kept the lights off with humidifier on full blast



That's the best part!

indeed it is

 

[MisterKister]

Everything is working well feeding athena pro line at 3.0 ec

 

[oldsilvertip55]

Well, I hope my foray into trying these Kasa TP-Link Smart Plugs doesn't go south! But, I'm not using the their Wifi app, nor allowing the device to talk back to their "cloud" service. Maybe that'll save my butt. I found a link (can't seem to locate it now) that showed commands you can send to the device. One of these commands allows you to point it at a fake endpoint on my own network so the "cloud" cannot interfere, nor provide the mfgr with my usage data. I'm also running them on a dedicated Wifi network provided by my controller - again, in hopes that nothing interferes with proper operation. However, this post got me to thinking about possibly never controlling anything that might cause crop failure if the device doesn't turn on/off as expected. Not even sure that's possible...

The metering data is very useful for gauging overall power consumption for all connected devices, but once your value has been identified that feature becomes less useful (someone else here already said as much).

As a side note, I'm currently coding a "bootstrap" mechanism so that if I do lose power or have a glitch that hiccups my system, it'll be smart enough to restore proper operational conditions in the moment.

i like the bootstrap back up/restart@last known settings,and times