nachtravevl/simple-hydroponics-arduino

Hydruino: Simple automation controller for hydroponic grow systems using Arduino-compatible microcontrollers. Professional grade, fully configurable, open source, & 100% free. No internet connection or cloud account required.

simple-hydroponics-arduino's Issues

TODO: Complete Wiki Documentation

We really need to spend some time on the Wiki. Got a lot of pages that are blank.

BUG: Some ESP platforms can't see A16, etc.

Have a bug on some of these platforms that don't have A16 but do have an A2. Looks like I will have to do it the long way around.

TODO: Recompute various FromString handlers

Now that we have a better handle on our enums we should get the fromString functions fixed back up, which means getting the trie to run again.

BUG: System sketches preprocessor checks invalid

To make setup of the system easier we have many places where we do things like setting things to a define value that is a part of an enum, that gets ## joined together. The problem is that trying to do equality checks on these, .e.g "feature != Disabled" doesn't work because that is treated as an undefined preprocessor that is 0'ed out.

From the C Standard:
(C99, 6.10.1p4) "After all replacements due to macro expansion and the defined unary operator have been performed, all remaining identifiers (including those lexically identical to keywords) are replaced with the pp-number 0"

So we're literally being bugged by pp-numbers. Joy.

Anyways, will need to manually edit the #if defines to get around this and that is a lot to ask of end users to do so this is bugged. We'll need to revisit it later to come up with a better solution, possibly consult some folks on what we could do.

TODO: Variable/throttled pump actuator

I've delayed doing this because I wanted to be clever and put some easing functionality into it to account for speed-up/slow-down.

TODO: Remove EEPROM offset defines needing copied over

It really is pointless to do this when we can just store a 16-bit number indicating the size of the chunk at the start of the data block - essentially the creation of a more formalized chunk object. This would give us the ability to just simply define a dynamic chunk size, and have it also include things like, for instance, possibly a next-chunk #, where we can then string large segments together into a chunk-based system. Then we can do things like access the better EEPROM offsetting stuff by discounting the dynamic nature and moving to a formal static chunk size. We can still store chunks dynamically, but we can also better utilize the usage of the entire EEPROM by spreading the static chunks out using existing code in the EEPROM library we're already using.

Basically, let's do something better with our EEPROM data chunk logic to really take advantage of EEPROM writing/reading here. We can also just continue with this copy-over-the-output-of-this business. Not like we don't have SD cards/readers that are just as cheap and readily available.

TODO: Cleanup old log/data files in logger/publisher

Both logger and publisher need their cleanup methods implemented.

Deprecated items: linksCount funcs

Functions like linksCountSowableCrops and linksCountActuatorsByReservoirAndType are redundant and should be merged into scheduler. Adding them into Utils was a bit premature.

TODO: Object unresolving/caching to reduce memory footprint

You know, it's a real shame that we put all this time and effort into being able to lazily deserialize objects, and not have lazy serialization back out. I know, it's a bit more complex than that - but, is it really? Couldn't we just do a direct 1:1 copy in/out of memory to some storage cache?

I realize there are things this may not work for, but what could it work with? We have options here people! But we may need to kinda figure out what those options are and what they could look like, and what kinds of savings we could get.

If we could do this though, and the savings were worth it, we might be able to get away with much MUCH larger systems on even the smaller MCU setups, and might actually wind up dropping our memory usage to reopen smaller devices into the working category. It's a long shot, but theoretically possible. Would be worth at least some sort of investigation and costing.

TODO: Allow balancers to persist / serialization

It would have to piggy-back off the feed reservoir, but it would be a nice feature to add in. Wouldn't be too hard if we did the same sort of universal object, bonus points if it can derive values independently or with an extra value or two specified.

TODO: Add project to Arduino IDE + PlatformIO trackers

Something we need to do later on, after we get a more stable/working system, is to finally add this project to these trackers so that it can be found in these IDEs.

Will also need to test to make sure everything compiles correctly under the different ones, that way we don't have a horde of complaints from people like what happened before with another one of our libs.

TODO: Verify dosing values/speeds

We're using some default dosing values based off some info we got from a factory tour YouTube video. Probably safe to say we should do a better job of testing these values to verify that we're getting the right ones. They are definitely ballpark, but we can do better.

TODO: Expand trigger attachment to have creation abilities

Creating triggers is pretty hairy, and we should spend some time here looking into maybe moving how and where we do trigger creations. Perhaps there is a method we could create that creates a trigger more easily for an object?

TODO: Main UI

This one is going to be a big one so consider this more of a master ticket that encapsulates a variety of things that we're going to have to break down.

TODO: Do something useful/smart with the buzzer

We have the Piezo buzzer pin specified but it's not actually used by anything. We were using a simple buzzer library, but realized later on that we didn't actually need an entire separate library to do what amounts to a few functions. In fact, it would be better to build an object specifically for use in our Task system space directly, since this is something that provides a great opportunity for a mixer system to be built and take advantage of. Having a mixer would allow us to do things like do a beep code based on, say, some part of any error code, or at least provide some sort of jingle or other melody. In fact, there are entire melody libraries that do this and more, readily available, and may be an even better approach. Otherwise, we have a piezo buzzer pin, we save it and load it from JSON, and we do absolutely nothing with it. We should change that.

TODO: Multiplexing of binary I/O

One of the things that we noticed really right away is that with more minimal pin counts, such as on some of these miniature form factor MCUs, you run out of I/O pins super fast. This leads into needing some sort of multiplexing need, or some way to expand I/O through some other means, such as an i2c multiplexer.

We could probably do a much better job than what we are currently doing right now, which is providing a simple macro that is overridable that can redirect the binary input sensor pin reads and binary output actuator pin writes to a custom bit of code. Essentially it's just a customizable macro wrapper for the basic read and write operation for a pin.

We could even probably just use an extended pin # -> data segmentation/union-like refactor strategy - like force move everything to a larger PINTYPE define that separates into two numbers, one for multiplexer chip select (or something) and the other for pin number. We could still pass MCU pin checks that way (by introducing a macro proxy to filter out, or adapt to struct member value access), but either way you still have to introduce an object/union of some kind. Might as well keep it simple and do it right, whatever right looks like.

BUG: Actuator activations should be driven by handles

Right now we have actuators programmed such that they can enable and disable as their primary functions. The thing is, the places where we use the actuators are commonly such that we want to keep that actuator active while a condition is held true, and that is in addition to anything else using it.

Enter into the idea of returning a handle. This handle would be an object that, once deallocated, would release the "handle" on keeping that actuator active. This would allow an object to basically control on/off access, and can use simple ref counting baked into shared pointers to control activation.

As of right now, we can only have one place as being able to enable/disable things. We have to broker these feature out, instead of giving such direct access to it like that.