# RPiAqua (Raspberry Pi Light Controller - In Progress)



## Wobblebonk (Feb 13, 2018)

Fun... my dumbass wanted to save work by getting a premade controller and somehow now I'm rewriting their firmware for them. I probably should have just built one but hindsight and all that...
What the heck is fast forward?


----------



## ChrisX (May 28, 2017)

I can think of a few similar projects in the DIY section; Pi + wifi shield. 

The one guy shared the hardware config, had a PCB printed (can be built without pcb) and uploaded his code to github. It might be worth checking out. You will get much farther with your limited time leveraging his code base.

I was going to build it but then sanity struck and I realized a $30 controller does what I need and that my time is worth much more than .05/hour.


----------



## f-fish (Jul 18, 2009)

Very nice .. any plans for adding some mqtt functionality? Is the idea that this will be an end node or also a basic hub for other sensors and features? 
Fully agree with No Online Accounts .... 

Later Ferdie


----------



## jeffkrol (Jun 5, 2013)

no, no no,, these projects fall down a rabbit hole and never finish...or get lost in endless revisions/confusion/demands..

KISS...KISS..


----------



## Wobblebonk (Feb 13, 2018)

I'm nearly done with my little side project but that has very limited ram/program space limitations... well side project #1 anyways :/


----------



## Kaiede (Sep 11, 2017)

Wobblebonk said:


> Fun... my dumbass wanted to save work by getting a premade controller and somehow now I'm rewriting their firmware for them. I probably should have just built one but hindsight and all that...


Yeah, in my case, the Pi was sitting around already. And targeting the Zero W makes it surprisingly cheap, while giving more wiggle room than an Arduino or similar. 



Wobblebonk said:


> What the heck is fast forward?


Demo/Preview/etc. Play the schedule very quickly. Feel free to mock my inability to name things. 



ChrisX said:


> I can think of a few similar projects in the DIY section; Pi + wifi shield.
> 
> The one guy shared the hardware config, had a PCB printed (can be built without pcb) and uploaded his code to github. It might be worth checking out. You will get much farther with your limited time leveraging his code base.


I assume you are referring to FishNet, yes? Took a quick look, it's interesting, but building it pretty much exclusively in Node-Red makes some things easier, and some things harder. I looked at Node-Red myself, but decided python was going to be fairly straight-forward and could be bolted onto a front-end built in some other way once it was time for that. Node-Red-Dashboard would be an interesting stop-gap for a web front-end, but not really ideal. 

There's a good reason he went the route he did, but there's a good reason I decided against that route. Node-Red just isn't flexible enough for the thing I'm looking to build. It's a great sandbox, and a great way to make it easier for someone to play with the IoT. But not really ideal once you hit the edges of the sandbox. 

I also looked at iAqua/iAqua Lite. But if you are referring to something different, and my search didn't catch it, I'd be happy to take a peek. 

And yeah, this probably should be moved to the DIY section, whoops. I'll see if I can get a mod to do that. 



ChrisX said:


> I was going to build it but then sanity struck and I realized a $30 controller does what I need and that my time is worth much more than .05/hour.


I wish that were true for what I wanted. 



f-fish said:


> Very nice .. any plans for adding some mqtt functionality? Is the idea that this will be an end node or also a basic hub for other sensors and features?
> Fully agree with No Online Accounts ....
> 
> Later Ferdie


Plans should be driven by a need, and a goal. Right now the need I have is to have a controller that I can use to dim my Twinstar light (and my second Twinstar down the road), and have better timing configuration than the Storm/HurricaneX or the Bluefish, but isn't tied to Windows-only software that seems to break for me like the TC-420 does. 

That's the need. That's the thing I _will_ deliver, since it's mostly done already. 

The goal though, is more that I want to chase the AI Prime's configurability. That's the north star.

Now, if I can deliver on that goal _with_ the web UI is a good question (The REST API is effectively the path to get to a Web UI). But with the prototyping I've done so far, it should be possible to at least capture the feature set, using a JSON config file at a minimum without too much work being done. 

If you approach this as expecting a single-mode TC-420 that you can more easily build to what you need, and configure it without proprietary software, you won't be disappointed. If you want this to become the next iAqua, I doubt it. The only automation I do on my tanks is lighting. 



jeffkrol said:


> no, no no,, these projects fall down a rabbit hole and never finish...or get lost in endless revisions/confusion/demands..
> 
> KISS...KISS..


I hear ya. I want to focus as much as possible on providing smaller chunks of functionality that can be used as early as possible.

Personally, I was _hoping_ to be able to hook this up on one of my tanks this weekend and let it run through the week to see how well it works. I was set back a little bit on prototyping the scheduler. Technically, I could still do it right now, but I wasn't happy with how much timing drift I was seeing with the super-dumb sleep method I was using to space apart events.


----------



## Wobblebonk (Feb 13, 2018)

Kaiede said:


> Demo/Preview/etc. Play the schedule very quickly. Feel free to mock my inability to name things.


I think hurricanex calls it "sim" mode and that code probably was carried over from storm x code though I don't have a stormx to confirm or the original source for that though I'm pretty sure that's using a gpl license so not too hard to get the code. Heh

I have some crazy ideas for app control / assigning channels to rgb for bluetooth/wifi control but I hate working on iphone apps so they might be sol for a while... though all of that won't be for a while anyhow also. But stuff I want for myself I will find the time to do :/


----------



## ChrisX (May 28, 2017)

Kaiede said:


> Plans should be driven by a need, and a goal. Right now the need I have is to have a controller that I can use to dim my Twinstar light (and my second Twinstar down the road), and have better timing configuration than the Storm/HurricaneX or the Bluefish, but isn't tied to Windows-only software that seems to break for me like the TC-420 does.


I have the TC421 which has android/iOS software. Granted its not sexy, but it does work and adjustments can be made directly from the phone. Windows software could be run from Coot Camp or Wine. Its not something that you will be looking at much once it's set up.

BTW, I dont think we are referring to the same DIY build, but there are so many of them.

If you only need five channels with full ramping and automation, then TC421 is a decent choice.


----------



## Kaiede (Sep 11, 2017)

Wobblebonk said:


> I think hurricanex calls it "sim" mode and that code probably was carried over from storm x code though I don't have a stormx to confirm or the original source for that though I'm pretty sure that's using a gpl license so not too hard to get the code. Heh
> 
> I have some crazy ideas for app control / assigning channels to rgb for bluetooth/wifi control but I hate working on iphone apps so they might be sol for a while... though all of that won't be for a while anyhow also. *But stuff I want for myself I will find the time to do :/*


iOS is partly my bread and butter. I'd have a far easier time putting together an iPhone app than a web app. But you are spot on with the bolded bit. That's probably the best lesson I've learned since college. I will do it if I want it, and I will not do it if I don't. So learn how to keep what I _want_ and what _would be cool_ separate for projects like this. You'll be much more honest about what you can accomplish with it, and be more focused. 

Second most important thing: Don't engineer the whole thing before you start. I've seen too many projects evaporate under the weight of designing too much too quickly. 



ChrisX said:


> I have the TC421 which has android/iOS software. Granted its not sexy, but it does work and adjustments can be made directly from the phone. Windows software could be run from Coot Camp or Wine. Its not something that you will be looking at much once it's set up.


I had this big rant planned about _how_ I got here, but decided to cut it, there's plenty of tidbits in my post history here and there. I had the TC-420. Stopped being able to update it, spent too much time trying to figure out why. Not going down that rabbit hole again. Tried multiple other controllers. Still reached this conclusion.

I'm not really sure what you hope to gain here by pushing this idea that I should just do something else? Forgive me if I'm blunt, but this is starting to come off as a bit patronizing. Please stop.


----------



## ChrisX (May 28, 2017)

Kaiede said:


> I'm not really sure what you hope to gain here by pushing this idea that I should just do something else? Forgive me if I'm blunt, but this is starting to come off as a bit patronizing. Please stop.


OK.

There are products that meet your requirements, and also other fully actualized DIY projects that do the same.

When you said you had "limited time" to work on this, thats when I thought you could use a dose of reality. Just trying to save you alot of work. If your time genuinely is limited, there are other ways for this to go.

If you are *aware* of all the other solutions, if you've gone 20 pages deep in the DIY forum and have seen those projects, then you are operating from an informed place. Two open source projects that do the same thing not as strong as one project with multiple contributors.

You never made a case why the other projects wouldnt work, besides a preference for working in a specific language.

Good luck with your project.


----------



## Wobblebonk (Feb 13, 2018)

Kaiede said:


> iOS is partly my bread and butter. I'd have a far easier time putting together an iPhone app than a web app. But you are spot on with the bolded bit. That's probably the best lesson I've learned since college. I will do it if I want it, and I will not do it if I don't. So learn how to keep what I _want_ and what _would be cool_ separate for projects like this. You'll be much more honest about what you can accomplish with it, and be more focused.
> 
> Second most important thing: Don't engineer the whole thing before you start. I've seen too many projects evaporate under the weight of designing too much too quickly.


I'm not doing the hardware at all that's being sent to me free(& maybe possible compensation/credit) for writing firmware / software so it's not exactly my project per se. Even if I get frustrated and give up theres a small team of people working on it. Though I'm sure I can suggest hardware changes provided ample reasoning, they had already asked if I wanted hardware changes to the existing device but I decided against it since they're working on a new one anyhow.

I hate using macs / xcode. I have to sometimes for work but I would prefer not to vs ubuntu or windoze. Personal problems.


----------



## Kaiede (Sep 11, 2017)

Wobblebonk said:


> I hate using macs / xcode. I have to sometimes for work but I would prefer not to vs ubuntu or windoze. Personal problems.


To each, their own. I enjoy working on many platforms. The only one I hate working on is Win32 (the API). Give me .NET any day, but I do wish Microsoft had a modern framework for native developers that didn't require the level of contortion that using C++ .NET from a legacy app seems to require.

----



ChrisX said:


> There are products that meet your requirements, and also other fully actualized DIY projects that do the same.
> 
> When you said you had "limited time" to work on this, thats when I thought you could use a dose of reality. Just trying to save you alot of work. If your time genuinely is limited, there are other ways for this to go.
> 
> You never made a case why the other projects wouldnt work, besides a preference for working in a specific language.


This bit right here is the problem. If you think that serving up a "dose of reality" is the right approach when you don't know someone's background, don't know their experiences to date, and generally haven't interacted with them before... Maybe you should think a bit on a better way to approach things. Maybe interrogating them over the internet is not the best use of either person's time. Thankfully, I don't need to justify my time spent to you to achieve what I am setting out to do. And I'm not inclined to spend my time regurgitating my pages of notes in order to convince you. Believe whatever you like.

Hell, the thing is, you may even be right 90% of the time and the project dies on the vine. Who cares? Hopefully that person at least tried and learned something. The road to success is paved in failures and lessons learned.


----------



## Wobblebonk (Feb 13, 2018)

I can agree with the win32 nonsense, honestly my problems with macs is just using the ui / having to update / apparent shoddiness of the store updating / them constantly(more like once a year) patching out the crap I did from ios so I have to find a new way/ the licensing gauntlet for ios apps... I'm tired of explaining to a new rep (from other companies that license a product from my work) how to update the licenses that expire every year. I probably don't like it because if I have to touch it at all it's only for licenses expiring or they broke crap for a new ios version (usually they did it intentionally).


----------



## f-fish (Jul 18, 2009)

Think the approach of doing one thing well and keeping it sensible and focused plays well when creating building blocks. You say just automating lights, but it is more than just on / off so well worth the effort. Keen to understand, are you or do you plan on running multiple tanks or is your current need to only do this for 1 tank? Reason I ask, I have found that monitoring before automation plays a bigger drive when you have multiple tanks and need to have that single view of what is actually going on. Having looked at several all-in-one aquarium projects, I have also opted for purpose build solution blocks that can be operated centrally but that actually function autonomously for that one function.

Looking forward to seeing it on github ... 

Later Ferdie


----------



## staticicarus (Nov 4, 2017)

Wobblebonk said:


> I'm tired of explaining to a new rep (from other companies that license a product from my work) how to update the licenses that expire every year.


It's simple. You explain that enterprise support is a reasonable monthly fee which includes making sure these sorts of unfortunate annoyances are dealt with.


----------



## Kaiede (Sep 11, 2017)

Tonight, I got the scheduler implemented, along with the schedule preview tool. Not terribly happy with the state of the code, as it isn't as clean as I normally like to keep it. But I did manage to slip in a couple tweaks I wasn't originally intending to tonight:


Gamma Support (fixed at 1.8 for now)
Configurable PWM frequency (Supports any multiple of 480 Hz, up to 2880 Hz for the built-in PWM hardware)

Interesting thing is that I noticed that neither the Bluefish or Fluval does any sort of gamma correction. Their behaviors are completely linear. Neat.

I've kicked off the schedule, and hooked the thing up to one of my tanks to see if it actually works. Unfortunately, there are still bugs with it not moving onto the next part of the ramp once one finishes. I think I have a rough idea what's going on, and I'll go ahead and make the fix tomorrow. 

I've also moved it out from where I host my private repos to GitHub. So it is available to poke at. But there aren't any instructions yet. I'll be looking at that once I stabilize things a bit and fix the issues that remain.

https://github.com/Kaiede/RPiLight



f-fish said:


> Think the approach of doing one thing well and keeping it sensible and focused plays well when creating building blocks. You say just automating lights, but it is more than just on / off so well worth the effort. Keen to understand, are you or do you plan on running multiple tanks or is your current need to only do this for 1 tank? Reason I ask, I have found that monitoring before automation plays a bigger drive when you have multiple tanks and need to have that single view of what is actually going on. Having looked at several all-in-one aquarium projects, I have also opted for purpose build solution blocks that can be operated centrally but that actually function autonomously for that one function.
> 
> Looking forward to seeing it on github ...


In my case, I have two tanks, and if I could put them near each other, and use a single controller, I would. But they aren't, so the plan is to use two controllers. 

It would be nice to have central control, and deploying individual config/schedule JSON blobs out to each RPi. But seeing as having the front-end is kinda far out there at the moment, I'm not putting any effort into thinking about this right now.


----------



## Kaiede (Sep 11, 2017)

And now for the fun bit. I'm pretty confident that I've fixed the issue with scheduling. I've hooked up the Twinstar 600E I've got to it and will see how the controller works. I'll be keeping an eye on it for the next few days to make sure things are reliable. But unless there's remaining bugs, it can handle a 24-hour ramp just fine. It already handles being started in the middle of the schedule, so no real worries there.

I've got a couple more tasks to do, which are tracked on GitHub. This is the remaining work I consider important enough for the first release. But right now it should be usable, but has a couple dependencies that need to get installed before it works on a fresh Raspbian install. 

If there's interest, I can put together a small demo video this weekend of it driving a Fluval Vista LED strip.


----------



## jeffkrol (Jun 5, 2013)

Always interested....


----------



## Kaiede (Sep 11, 2017)

Some good news and some weird news.

The good news is that after fixing an off-by-one bug (plus some typos) in my PWM controller code, the adafruit PWM expansion board works perfectly for driving the MOSFET switches. Thank you, PCA9685 datasheet.

The weird news is that I also got a Pi Zero W in, and the performance I'm seeing is a little bit concerning, but not a huge problem in the short term. The Pi 3B with apscheduler was able to stay under 30% CPU while updating the PWM duty cycle 100 times a second. Excessive, but the idea was to have the rate high for quick ramps, and low for longer ones, using "just enough" CPU. But that setting on the Pi Zero causes it to max out the CPU just running the loop. Oops.

Short term, I can keep CPU usage below 30% just by changing the cap to something more reasonable. 

Longer term, I may have to rethink the use of apscheduler. It's overhead in my case is enormous on the Pi Zero. It adds seconds of boot time when running any of the scripts. Starting a scheduler lags for a couple seconds before it starts handling jobs. At 24 updates a second, it consumes nearly 30% CPU just writing out "datetime.now()" in a loop. Doing the same myself uses 2.5-6%. It's perfectly fine on the 3B, though, which meant I didn't run into this until I had the Zero in hand. And it's not a python 2 vs 3 issue either. As I said, it's weird.


----------



## Kaiede (Sep 11, 2017)

So, I decided to jettison apscheduler entirely. I was still getting some race conditions with it, since apscheduler apparently doesn't guarantee much in the way of ordering of tasks if two of them happen to have the same date/time for firing. Great. So I figured since I was also seeing perf issues, it was going to about as complex to write a custom (but simple) event loop where I can guarantee ordering and behavior, than try to fix the race conditions. It also opened up a couple more ways to further reduce CPU use during flat parts of the schedule.

I did some experiments with coroutines just for grins, and the perf was not all that much better than apscheduler. Better, but not quite as performant as my solution. I don't think I can quite hold to single digit CPU use during fast ramps, but its under 15% worst case, which is still a huge improvement.

While watching the log stream from my prototype scheduler this morning, I put together some documentation. It may be missing some things, and it can probably be massaged a bit to be easier to follow, but it is a full brain dump on how things work. That's available on the GitHub repo. 

I can't quite put together a video yet. Mostly because all my MOSFET switches are wired up and in use. I have more showing up today, and hopefully I can integrate the new scheduler (it's been looking really good so far) in short order. Mostly I just broke the test/preview scripts, which relied on behavior I haven't duplicated in the new scheduler (didn't need it). I think tomorrow I can put together a quick demo video showing the quick ramp behavior and previewing a schedule.


----------



## Kaiede (Sep 11, 2017)

It's a simple demo, but I threw it together. The test ramp intentionally "hiccups" in the middle of the second ramp, to test overlapping segments. The preview ramp is a simple schedule (the one included in the examples folder) that includes a "morning" and "evening" period around a bright period. Unfortunately, it's also a bit difficult to capture a test rig like this without blowing it out from all the light. 

YouTube - RPiLight Demo


----------



## jeffkrol (Jun 5, 2013)

Thanks, I'd say things are looking good, but I only understand about a tenth of what you say...LOL..


----------



## Kaiede (Sep 11, 2017)

jeffkrol said:


> Thanks, I'd say things are looking good, but I only understand about a tenth of what you say...LOL..



I sometimes forget tech-savvy doesn’t always mean engineer, or the same kind of engineer. This sort of project is relaxing compared to the complexity of projects I do for work.

Anyhow, I tagged v0.1 for release this morning before having to tag v0.1.1. There was a nasty bug that showed up when the tool was started early in the morning.

But it does have a release that anyone can try if they really want.

It’s not exactly friendly to those who aren’t tech-savvy enough to muck with Linux and do a bit of wiring, but it’s been running my Twinstar 600E for a couple days straight now. It’s handling that core functionality about as well as a TC-420. Just more DIY, and less proprietary software involved. I won’t miss PLed.

Since I’ve been burning the candle at both ends this week, I am going to take a break and see if any bugs show up while I’m not making changes. Next weekend I’ll see where things are and start looking at the next set of additions.

At first, I think I’ll do some smaller, but useful tweaks before trying to tackle a larger feature. Things I’d like to be able to configure without code changes, like custom gamma, or being able to tell the software when a channel shuts off. The Twinstar starts behaving oddly when at about 0.2%, with the red and green LEDs turning off before the blue and white do. It’d be great to have the controller account for that sort of thing if told about it.


----------



## doylecolmdoyle (Sep 22, 2015)

Cool project, FYI you can run PLED on osx via Wine, it works like a charm!


----------



## Kaiede (Sep 11, 2017)

doylecolmdoyle said:


> Cool project, FYI you can run PLED on osx via Wine, it works like a charm!



You aren’t even the first person to tell me that in this thread. I had problems with PLed. It stopped working because of some update at some point. Already spent too much time on that rabbit hole.


----------



## Kaiede (Sep 11, 2017)

Okay, now folks can call me crazy. I just about rewrote the v0.1 from scratch solely to get better performance.

The python version I wrote isn't terribly great when it comes to CPU. A single on-board PWM channel was enough to run the CPU at full load if I updated frequently enough. By updating less frequently, and also by replacing the scheduler library with a custom loop, I was able to get the CPU use down to about 14% for that single channel. But what about when using the Adafruit PWM board, which has 16 channels on it? Those extra channels cost CPU time, as does the communication with the board. Maybe not 16x, but it would still rise noticeably. I just wasn't really happy with where this was going. That 14% didn't include the extra 5-9% the GPIO daemon was using in the background for things that didn't benefit the project. 

So when I noticed that Swift works on these boards, I figured I'd do some prototyping, just in case. There's a couple good things about Swift in this space that would make it easier to do this sort of time-based programming, I'm familiar with it, and bootstrapping projects with it is faster than with C/C++ (which was my next choice). 

The good news is that the prototyping was very promising. That single channel test was looking really good, and the numbers for 24 updates per second looked like:

 Python: 28% CPU
 Python (Optimized): 14% CPU
 Swift: 1.3% CPU

Because of the huge improvement, I decided to do some real stress testing. Up the rate to 100 updates per second, and look at different channel counts:

 On-Board (1 Ch): 4.9%
 On-Board (2 Ch): 6.8%
 Adafruit PWM (1 Ch): 7.5%
 Adafruit PWM (2 Ch): 12%
 Adafruit PWM (4 Ch): 19%
 Adafruit PWM (16 Ch): 26%

The end result is that I can update 16 channels, 4 times as frequently as before, and still use a little less CPU to do it. These numbers in general are much closer to what I was hoping to be able to achieve. I can probably shrink the gap between the On-Board and the Adafruit PWM a bit, since the communication could be made more efficient, but that would need a bit of work. For now, since these sort of bursts of rapid updates should be rare, this is a sort of worst-case situation, and I'm okay with 16 channels needing that much CPU briefly. At least for now.

But it does mean I've spent a couple days this week rewriting everything in Swift, and I'm not quite done yet before I'm back at parity with v0.1. What's left is fairly small, routine stuff though.


----------



## Kaiede (Sep 11, 2017)

I just posted 0.1.6 to GitHub. This is the version re-written in Swift. It does have a better install process, and the config files are almost entirely backwards compatible. I did merge the config.json and schedule.json into a single file though, and I renamed the channels to be a bit shorter. Figure it'd be easier to break configs for the 2 people even taking a look at this now than later. 

It uses a decent chunk of RAM because of libraries (20MB), but that could be a whole lot worse. It's under 5% of the available RAM on the Pi, and won't grow all that much as I add new features in. 



Wobblebonk said:


> Fun... my dumbass wanted to save work by getting a premade controller and somehow now I'm rewriting their firmware for them. I probably should have just built one but hindsight and all that...


Since you are also messing around with this. Would you mind if I picked your brain around gamma? 

The thing I did, and I'm starting to think may have been boneheaded, was apply gamma to the entire brightness range. So if I ask for 50% brightness, I am actually asking for more like 30% output due to applying gamma correction. But this actually makes certain things harder, despite making the ramp look nicer to my eyes.

Say I've got a light that produces 100 PAR at the substrate. If I put the PWM at 50% duty cycle, I'm going to read 50 PAR at the substrate. This is all well and good, and how someone in the hobby concerned about PAR will be thinking. So, knowing they want their photoperiod at 50 PAR, they put in 50% brightness. Now because my code is applying gamma correction, 50% brightness becomes ~30% intensity when using a gamma of 1.8. This means that they are actually getting closer to 30 PAR at the substrate, not the 50 they were expecting. This is not a great experience. But it's also possible I'm mis-applying gamma correction here, compared to computer displays. 

So here's my question. Does this track with your implementation/thinking? 

I'm wondering if I should make one of the following changes: 


 Make the schedule work in intensity instead of brightness, or even let the user specify which they want. So folks aiming at a particular PAR use intensity, folks who want a particular apparent brightness use that. I can still use apparent brightness when calculating the ramp if we want a ramp that looks linear to the human eye. 
 Abandon gamma if the goal is a curve that rises quickly and early when turning on, or tapers off more rapidly at the end. Because the math is being done in floating point, it's easier to do something like 0.4% intensity to get that full moon effect.


----------



## Wobblebonk (Feb 13, 2018)

OSX IS THE DEVIL.

but uh, I actually took out the cie1931 thing for the hurricanex because the lut took up too much memory (there's 2kb ram... hah) and I could have moved it to program space but they requested to show %s and it's a neat feature for manual modes and such when you're playing around but when setting it up I think actual intensity makes more sense.

When there is more memory available I may make it like a user option in the control gui (iphone / android app?) but it's like a neat feature that is less practical most of the time.


----------



## jeffkrol (Jun 5, 2013)

Kaiede said:


> I just posted 0.1.6 to GitHub. This is the version re-written in Swift. It does have a better install process, and the config files are almost entirely backwards compatible. I did merge the config.json and schedule.json into a single file though, and I renamed the channels to be a bit shorter. Figure it'd be easier to break configs for the 2 people even taking a look at this now than later.


Funny.. 






Kaiede said:


> I'm wondering if I should make one of the following changes:
> 
> 
> Make the schedule work in intensity instead of brightness, or even let the user specify which they want. So folks aiming at a particular PAR use intensity, folks who want a particular apparent brightness use that. I can still use apparent brightness when calculating the ramp if we want a ramp that looks linear to the human eye.
> Abandon gamma if the goal is a curve that rises quickly and early when turning on, or tapers off more rapidly at the end. Because the math is being done in floating point, it's easier to do something like 0.4% intensity to get that full moon effect.


Initial choice would be the choice.. 
An option of gamma vs linear is brilliant..
Number of separate curves or just one is debatable..If calculated.. not an issue if LUT then ??


Sometimes there is a fine line between too much and too little user adj...


Gamma dimming is becoming more "popular" in industry.. so there is that new car smell effect..
coupled w/ the higher Hz is better getting some traction...
1) https://www.gammalighttherapy.com/blog/how-to-build-a-gamma-40-hz-led-dimmer
2) https://www.lrc.rpi.edu/programs/solidstate/assist/recommends/dimming.asp



Arguable that it is "needed" (gamma dimming) in our use but certainly "proper"..


----------



## Kaiede (Sep 11, 2017)

jeffkrol said:


> Funny..


But pretty accurate. GitHub does show some statistics on traffic for projects, so I know how few people are poking at it. 



jeffkrol said:


> Initial choice would be the choice..
> An option of gamma vs linear is brilliant..
> Number of separate curves or just one is debatable..If calculated.. not an issue if LUT then ??


I've got a change now that makes it so that you can specify intensity or brightness for any point in the schedule, and it will still do the math in terms of brightness and so changes will follow the gamma correction curve. So you get the linear looking ramp, while also being able to set your peak light levels based on the PAR you want to hit more easily. It also lets you specify the gamma to be something other than 1.8, but some of the juggling of state here is starting to get a little gnarly, so I'm hoping to not make it any more complicated than this without a chance to clean things up long-term. But if you want a ramp that behaves like the Bluefish, Fluval, or TC-420 ramps, you can just set the gamma to 1.0 and call it a day.

With the ARM chips in the Raspberry Pi, you've got hardware floating point available. On top of that, the Zero _is_ a 1Ghz SoC. I'm not currently bothering with a LUT, and instead doing the math directly. The costs of talking to the PWM controller is more expensive than the math being done so far. I2C for the 16-channel PWM controller is kinda slow.



jeffkrol said:


> Arguable that it is "needed" (gamma dimming) in our use but certainly "proper"..


I guess it is more if you want the ramp going from off to on to _look_ linear, or to follow some other curve. If you want to follow a different curve, then in some cases, the short-hand can be to just not use gamma correction at all. 

I'm used to working with gamma for displays and photography, but when applying it here, I found it was difficult to create the schedule I wanted, because I couldn't think in terms of PAR like I wanted. I'd have to do the math myself to apply an inverse correction and get the brightness, when I had the intensity. That is not a great experience. 

And I'm noticing that at least with the Fluval, Bluefish, TC-420 and quite a few others, it all operates on intensity (and calls it brightness). So the nomenclature is a bit of a mess in this space, I wanted to at least make sure I'm not losing my mind on doing it this way.


----------



## Kaiede (Sep 11, 2017)

Wobblebonk said:


> OSX IS THE DEVIL.


Good thing this builds straight on the Pi without OSX, eh? 

I could have done straight-up C/C++, but boost isn't something I'm personally familiar with (I work on too much legacy code to get exposed to boost). While the Foundation and Dispatch libraries in Swift are enough for this project, and cut the CPU use massively compared to the Python implementation, while still providing a good framework to start from. libDispatch is practically tailored for this sort of work.

But as long as the goal was to fit the performance available on the Zero, it would have been rough to stick with Python, as much as I would have preferred it (more popular as a language). C# with Mono is another option, but performance is generally a bit slower all things being equal (i.e. ignoring library performance, which can favor .NET in certain cases or with certain 3rd party libraries). It was worth trying, anyways.

That said, Swift still has some absurdly good type-safe behavior that I like. It's one of the reasons I was able to rewrite it this quickly, despite having to debug/fix 2 existing 3rd party libraries, and write a module to talk to the PCA9685.



Wobblebonk said:


> but uh, I actually took out the cie1931 thing for the hurricanex because the lut took up too much memory (there's 2kb ram... hah) and I could have moved it to program space but they requested to show %s and it's a neat feature for manual modes and such when you're playing around but when setting it up I think actual intensity makes more sense.
> 
> When there is more memory available I may make it like a user option in the control gui (iphone / android app?) but it's like a neat feature that is less practical most of the time.


Yeah, this is another reason I went for the Pi I already had. Despite having to statically link the Swift runtime, and the general bloat from working with a higher level language, I'm using <5% RAM at the moment, and I'd be surprised if it doubled by the time I'm done. 

The cost of the headroom is the extra power consumption. But I should be able to keep it under a watt or so, which is fine.


----------



## jeffkrol (Jun 5, 2013)

Yea good point.. brightness of a green LED could equal the brightness of a blue LED but at 2x the "intensity" on the blue driver..
So lets go w/ the linear is a PAR dimming curve and gamma corrected dimming is a "natural" curve..  
With the 2 choices there is no need for most to "worry" about err 'irregular" PAR changes in the dim cycle.

Biggest problem is not the ramp up because many do do that rather quickly in the overall scheme of things.

Few, though some, wouldn't go from say 100% to 95% dim as a PAR adjustment..I don't believe.
For those that critical.. a $200 Seneye will help.. 

YEA.. goofy language..
e.g


> This table remaps linear input values (the numbers we’d like to use; e.g. 127 = half brightness) to nonlinear gamma-corrected output values (numbers producing the desired effect on the LED; e.g. 36 = half brightness).


https://learn.adafruit.com/led-tricks-gamma-correction/the-quick-fix

127= half intensity..  Brightness is relative to the human eye response, if I got all this right.

OK for my pet peeve.. We don't measure "PAR" but "PPFD"..
If I have to live w/ PAR you need to live w/ "brightness"... 
like 18% grey................ 


> Your eyes are logarithmic detectors. That is, if a source gets brighter by a factor of 4, it will only seem brighter by a factor of 2 to you. If it increases by a factor of 32, it will only seem brighter by a factor of 5. If it increases in brightness by a factor of 128, it will only seem 7 times brighter to you.
> 
> The above are not the actual numbers. As you can imagine, measuring how bright things seem to people is very tricky, and varies from person to person. The important thing is that it is this weird logarithmic nature of your eyes that keeps middle gray from being 50%.


https://photo.stackexchange.com/que...onsidered-to-be-in-the-middle-for-photography
Industry is no help either..


> The LI-190R measures Photosynthetically Active Radiation (PAR, in µmol of photons m-2 s-1).


https://www.licor.com/env/products/light/quantum.html

It's not "just PAR".. Par over time and distance is PPFD..


> Most light meters measure the instantaneous photosynthetic photon flux density in µmol m-2 s-1 and yet plant growth is determined by the integrated daily photosynthetic photon flux density in mol m-2 d-1.


https://www.apogeeinstruments.com/conversion-instantaneous-ppfd-to-integrated-ppfd/

won't even get into Genus and "species" thing.. 
Sorry Monday, and ranting..

Hmm back to the orig "issue"
OK to do linear readouts at the "PAR" scale in %'s
Now what about the "natural" scale..
If you want to keep the scale it needs to be dependent on the calc. value..
https://learn.adafruit.com/led-tricks-gamma-correction/the-quick-fix

Using this table say at 8/14 (step 216)...is "50%"
both would be intensity.. nobody will care if we call it brightness.

ADDENDUM:
Want to get real fancy add a DLI caculation:
https://www.apogeeinstruments.com/conversion-instantaneous-ppfd-to-integrated-ppfd/
Cumulative "PAR" based on scale over time..
Need to input "starting" PAR.
Nobody really uses it ..yet..except indirectly like "decrease your hours on".

On second thought.. too much work since youd need to integrate every channel ect.but food for another day and when built in PAR sensors are on lights..


----------



## Wobblebonk (Feb 13, 2018)

The osx is the devil thing was something I typed a ways back when people were still suggesting you use wine etc and it amused me so I just left it when I came back to make a reply.

I mean on my current project boost would be so unworkable... but I'm battling memory space more than anything. I was just trying to fix it for myself originally... because it was what I had on hand. I certainly wouldn't choose to have 2kb ram if I was designing it... but I didn't think it was worth it for them to redesign it if they're coming out with a new model anyhow (they actually offered to up the ram etc)

The vast majority of what I do for work is c++ or python, so I'm pretty happy to use those. I'm actually fine with using most programming languages I just dislike using xcode specifically.


----------



## Kaiede (Sep 11, 2017)

jeffkrol said:


> Few, though some, wouldn't go from say 100% to 95% dim as a PAR adjustment..I don't believe.
> For those that critical.. a $200 Seneye will help..
> 
> YEA.. goofy language..
> ...


What I hit was the issue that I wanted to get half intensity to hit a certain target for light level at the substrate, and immediately put in 50% brightness not realizing it was really more like 68% brightness that I needed to set. So operating in terms of brightness isn't terribly intuitive or accurate. If you are just trying to wing it and tweak, it is probably okay.

Yeah, that's about right in the context of that example. 



jeffkrol said:


> OK for my pet peeve.. We don't measure "PAR" but "PPFD"..
> If I have to live w/ PAR you need to live w/ "brightness"...


That's fine, except when you start needing to talk about the relationship between brightness and intensity, it gets messy because the relationship is non-linear and so using one as short-hand for the other complicates things. Harder to reason about. I wonder how linear the relationship between PAR and PPFD is. 



Wobblebonk said:


> The osx is the devil thing was something I typed a ways back when people were still suggesting you use wine etc and it amused me so I just left it when I came back to make a reply.
> 
> <snip>
> 
> The vast majority of what I do for work is c++ or python, so I'm pretty happy to use those. I'm actually fine with using most programming languages I just dislike using xcode specifically.


Eh, no worries, I figured it was a friendly jab. 

Xcode is certainly... a thing. It's fine for projects like this, but the bugs get both hilarious and depressing on larger projects. I picked Swift more because I could easily compile/test/run on Linux/Mac desktop as well as the Pi without doing too much #ifdef-esque nonsense. Xcode integration just makes the debug loop a little easier since I'm not a huge CLI jockey. I didn't even know it was possible until after I finished the early prototype.


----------



## jeffkrol (Jun 5, 2013)

PAR and PPFD are photon counts, there is no difference in linearity..

PAR per m2 per sec is PPFD.
Unfortunately photon detectors have varying sensitivity to wavelengths and so not really perfect recorders..
They get close w/ a lot of massaging of the input..
see the Li-Cor design..

https://www.advancedaquarist.com/2013/2/equipment
Field scout looks pretty much like a bare photodiode..



Problem is 100PAR of red light is not as "bright" as 100PAR of blue-green Light, yet will contain the same number of photons..

Theoretically PAR and PPFD is a completely linear measurement across the visible spectrum, yet perceived brightness certainly changes w/ "color".

W/ plants all PAR isn't exactly equal either so they "use" PUR which accounts for some differences in quantum capture..
Minor point is there are already a whole bunch of systemic errors anyways.. 

Regardless of curves sticking w/ a "power scale" 

to be honest, brightness really is unimportant as a plant metric. Only intensity and to a lesser extent bandwidth count.
For you and me of course a different story..

not planning any 100PAR deep red tanks 100% of the day..

If one uses power as the scale (integer pairing) then the apparent brightness will be egual for any scale.. Only the number of points getting there will be different..


----------



## Wobblebonk (Feb 13, 2018)

Heh I've spent days (well not really but I couldn't figure it out in the time I spent) trying to figure out how the F I had introduced a bug that messed with my stored intensity values/lookup... but apparently I commented out where it sets the cloud mode to off on initialization so it was just a random # that wasn't 1 or 0. They declared it as a byte instead of boolean, anyhow my day period would be randomly dark(er) and I was all WTF. but sigh so dumb... oops. So I guess I've been running with cloud mode all along (well for a while after loading custom firmwares anyhow) wondering to myself who actually uses this stuff heh.

The if statements were such that it had to appear as 1 to show that it was enabled but as long as it was != 0 it would be in effect heh. I thought I must have introduced a memory leak somewhere or something...

Now is when I discover cloud mode has been saving me from algae all along :/


----------



## Kaiede (Sep 11, 2017)

Anyhow, got most of the work around 0.2 done today since I’m taking a couple days off this month. The errors when there are problems with the configuration file are better, it supports brightness and/or intensity in the schedule, you can tweak the gamma used to convert between the two, and it supports a form of minimum intensity per channel. 

The last one needs tweaks later this week, but I’ll probably start looking at what it would take to do moon phases at the same time. 

Because I can set the light levels very low, it could be interesting to play with moon phases where full moon is something like 0.5% intensity.


----------



## Kaiede (Sep 11, 2017)

Wobblebonk said:


> The if statements were such that it had to appear as 1 to show that it was enabled but as long as it was != 0 it would be in effect heh. I thought I must have introduced a memory leak somewhere or something...
> 
> 
> 
> Now is when I discover cloud mode has been saving me from algae all along :/



That sort of stuff is fun. I’ve worked in codebases where ‘int’ was used for true/false. All sorts of goofy stuff there to try to avoid problems with that. Also a very old codebase.

I need to start adding time/intensity back into my tank myself. I finally kicked my algae to the curb by finding out which nutrient was deficient, and I can start seeing how much I can kick it up before it starts to appear again.


----------



## Wobblebonk (Feb 13, 2018)

Well, I can tell you that they were just calculating moonphase from a library that they would put the date/lat/long into and just multiplied the value by the night pwm settings, the value was 0 for a new moon ->1(00%) for a full moon


----------



## Kaiede (Sep 11, 2017)

Wobblebonk said:


> Well, I can tell you that they were just calculating moonphase from a library that they would put the date/lat/long into and just multiplied the value by the night pwm settings, the value was 0 for a new moon ->1(00%) for a full moon




That’s my intent, as well. Just a bit more generic and simplistic perhaps. 

The code to figure out the moon phase itself isn’t too difficult, and I was planning on keeping it simple at first by not having to think about timing of when the moon rises and sets.

But I see a JS (and Python) library that does most of this under the MIT License that would be simple to port to Swift. May just start by porting that as an exercise in understanding the math.


----------



## Kaiede (Sep 11, 2017)

I finished up the last issues that were preventing 0.2 from going out the door. So that's now available.

Improvements:


Prints details of hardware configuration on start
Somewhat improved error reporting when loading the configuration
Supports more than the Pi Zero / 1 GPIO, using a new configuration option
Can configure the gamma used for calculating brightness
Can set a channel's brightness (uses gamma) or intensity (raw light percentage) for any event in the schedule
Ability to set a minimum intensity for a channel


----------



## Kaiede (Sep 11, 2017)

0.2.1 now detects which Raspberry Pi board is being used, so most folks won't need to set the hardware configuration option. It's still there in case something does come out that breaks the detection as a workaround.

I also turned on automated builds because I could. Also did some other small cleanup/hygiene. This is mostly to make it easier to catch problems in the future, and test the waters on newer versions of Swift. 

I've been poking around at libraries to calculate moon/sun position. Not a whole lot of luck. Many simpler libraries are not documented enough to fix issues that show up when porting their code. I could wrap a library like libastro, or drag out my old book on the subject and do it myself, since I only need a small subset of libastro and wrapping C libraries is hit or miss with Swift. It could be easy, or it could be hard. Not entirely sure which direction I'll go.


----------



## jeffkrol (Jun 5, 2013)

Still dangling my toes in Pi water...
Along w/ 3 other tanks and various COB's..

Too many choices, too many toys..


----------



## Kaiede (Sep 11, 2017)

I did some playing around with cleaning up the install a bit. Instead of unpacking the Swift compiler into /usr, it does it in /opt/swift now, behaving like a better Linux citizen. I also fixed a missing dependency needed to build/install. Right now, the install process is about as simple as it will get without starting down the route of custom SD card images.

I also put together the core of a library that will back the Lunar Cycle feature. Enough that I can start writing the feature. But I'll probably not get back to it until this next weekend. Need to be able to attack some other projects this week. 

At some point I also need to split out the PCA9685 PWM interface into its own project. It should be a library that anyone can use.



jeffkrol said:


> Still dangling my toes in Pi water...
> Along w/ 3 other tanks and various COB's..
> 
> Too many choices, too many toys..


Of course.


----------



## jeffkrol (Jun 5, 2013)

Need to pick your brain on some hardware choices:
1)Pi ZeroWH or Pi-3?
2) bonnet or hat (btw whats the difference?)


> Adafruit 16-Channel PWM / Servo Bonnet for Raspberry Pi





> Adafruit 16-Channel PWM / Servo HAT for Raspberry Pi - Mini Kit


do cases fit hats/bonnets?


----------



## Kaiede (Sep 11, 2017)

The Zero WH is what I’m using on my tank currently and I use a 3 for development. The 3 is a lot faster, but it is bigger and uses more power. 

For now, the Zero W is plenty for this particular project. But if you want to be able to tool around and experiment, the 3 has more performance if doing a lot of building. Peak CPU use in a worst case scenario is <30% at the moment, generally in the low to mid single digits in most realistic cases when changing the light brightness.

Going forward, perf on the Zero should still be reasonable, but I may be forced into providing pre-built packages for it because of bloating build times. Right now a build of debug isn’t too bad, release is tolerable. But if I start letting config changes come in over the network, the initial build times will bloat a lot from the libraries required. Think 10-15 minute range. Updates should still be reasonable though.

The risk with the Zero is that ARMv6 is old now, and the Swift compiler folks seem uninterested in the older CPU. So it’s a little uncertain what the future holds. Android support could help prop it up, maybe not. Who knows. But the impact on my project is a couple years out in either case. At 15$, it’s hard to worry too much on if I’ll get 2 or 5 years out of the hardware. Sadly.

The bonnets are smaller and cheaper, about the size of the Zero. The hat is better if you need to use stands on the Pi 3. I’d go with the Bonnet pretty much every time, myself.


----------



## Mike! (Mar 26, 2018)

This was fun to read through. Only a little sad when I saw python dropped halfway through. In a previous job I got to play with Arduinos and RPis a out half the time. I'm the guy who actually enjoys fitting a program into the memory of an Arduino.

If I didn't fear my non-existent EE-skills in close proximity to water, I'd be all over this kind of thing.


----------



## Kaiede (Sep 11, 2017)

Mike! said:


> This was fun to read through. Only a little sad when I saw python dropped halfway through. In a previous job I got to play with Arduinos and RPis a out half the time. I'm the guy who actually enjoys fitting a program into the memory of an Arduino.


I would enjoy it more if I wasn’t already doing something similar for work. 




Mike! said:


> If I didn't fear my non-existent EE-skills in close proximity to water, I'd be all over this kind of thing.


Mine are out of practice. With a project box, this is no worse than the ones you can buy. None of them are really protected from water. They rely on you having drip loops.


----------



## Mike! (Mar 26, 2018)

Kaiede said:


> Mine are out of practice. With a project box, this is no worse than the ones you can buy. None of them are really protected from water. They rely on you having drip loops.


Maybe I missed it in the thread. Any particular kind of project box you like?

If I'm being honest, I'm less of afraid of water and more afraid of starting a fire. When I did it for a job, I had controls engineers to wire and solder after the prototype...


----------



## Kaiede (Sep 11, 2017)

jeffkrol said:


> do cases fit hats/bonnets?



This is were I’m learning too. I have a couple of these on the way I’m going to try to use, it has room for a bonnet for the Zero. Hard to find in the US, but shipping from Canada was reasonable.

https://www.buyapi.ca/product/unipicase-zero-tall/

A properly sized ABS project box would work here too.



Sent from my iPad using Tapatalk


----------



## Kaiede (Sep 11, 2017)

Mike! said:


> Maybe I missed it in the thread. Any particular kind of project box you like?
> 
> 
> 
> If I'm being honest, I'm less of afraid of water and more afraid of starting a fire. When I did it for a job, I had controls engineers to wire and solder after the prototype...



I’m still figuring the box part out. I’ll know by the end of the week if the one I ordered works well.

The soldering here is pretty minimal, and in my case was entirely on the 3.3v logic side (headers on pre-populated boards so I can just wire them up). I understand the worry, I’m pretty conservative about this too. But in this case, depending on your setup, it’s a lot closer to assembling a mini PC than putting together a custom circuit.


----------



## jeffkrol (Jun 5, 2013)

I went for years w/ a Stves Typon board taped to the top of a meanwell driver board stuffed into an old computer ps box.. 

I was more worried about shorting things than water ..

When I bought the Bluefish mini, I bought a box.. crummy boxes but at least I wan't taping it to something...

BTW: Really leaning to the 3, only thing is I really like that color coded header that.. someday.. you can get from Adafruit..
3 of course, has the black one attached..

Figures. then again why DIY is always enticing.. Everything is made "wrong".

Watched a vid on a UK site w/ the hammerable headers.. Of course just black..

https://shop.pimoroni.com/products/gpio-hammer-header?variant=35643241098

OK add it's only available overseas or made wrong..
Solderless headers I can get I guess.. missed it.


----------



## Mike! (Mar 26, 2018)

Kaiede said:


> I’m still figuring the box part out. I’ll know by the end of the week if the one I ordered works well.
> 
> The soldering here is pretty minimal, and in my case was entirely on the 3.3v logic side (headers on pre-populated boards so I can just wire them up). I understand the worry, I’m pretty conservative about this too. But in this case, depending on your setup, it’s a lot closer to assembling a mini PC than putting together a custom circuit.


Any pics of the build in progress?


----------



## Kaiede (Sep 11, 2017)

jeffkrol said:


> I went for years w/ a Stves Typon board taped to the top of a meanwell driver board stuffed into an old computer ps box..
> 
> BTW: Really leaning to the 3, only thing is I really like that color coded header that.. someday.. you can get from Adafruit..
> 3 of course, has the black one attached..



Heh. My hope is that I can drill a couple holes in the case I linked for the power leads for the light, and then Velcro the box to the inside of the cabinet. Should have enough room to do two channels down the road if I want. 

I’m partial to this thing: https://www.adafruit.com/product/2263. Takes more space, but useful when doing the prototyping, and then goes away. But I can see the usefulness of the color coded header. But when using a Bonnet or HAT, it’s all moot. 

Yeah, if I could only have one, it’d be the 3B (or the 3B+). But since I can have more than one, I want the “deployment” hardware to be the Zero because of the price and the fact that I think I can get it down to around half a watt if I disable HDMI and the activity LED. The 3B I’ll keep using for testing before it goes onto my tanks. 



Mike! said:


> Any pics of the build in progress?



It hasn’t really changed much since I posted the video. I’ve mostly been working on the software. I’m really just building a pair of these to drive Twinstar lights over a pair of tanks.

I’ve been under the weather today, so I haven’t done anything, and I’m trying to not burn the candle at both ends for too many nights in a row. So I’ll probably be sitting on this project until the weekend. I will put up some pics then, if that’s okay. 



Sent from my iPad using Tapatalk


----------



## Kaiede (Sep 11, 2017)

The UniPi cases showed up today. It’s a bit tight for 2 channels but I think it is doable if I ditched the headers on the MOSFETs and shortened the wires I used. This is about as small as this project can go I think. Not too bad though. Can Velcro it to the inside of my tank stand to keep it out of the way.

Because I’m running 6A for the 900E, and I’m paranoid, heatsinks on the MOSFETs.


----------



## Kaiede (Sep 11, 2017)

I took a look at the AI freshwater settings thread a couple days ago out of curiosity. I was curious how the schedules were defined in their settings, and it gave me an idea. Right now a schedule for two channels looks like this:


```
{
    "hardware" :{
        "board": "PiZero",
        "pwmMode": "hardware",
        "freq": 960,
        "channels": 2
    },

    "schedule" : [
        {
            "time" : "08:00:00",
            "channels" : [
                { "token": "PWM0-IO18", "brightness": 0.0 },
                { "token": "PWM1-IO19", "brightness": 0.0 }
            ]
        },
        {
            "time" : "08:30:00",
            "channels" : [
                { "token": "PWM0-IO18", "brightness": 0.25 },
                { "token": "PWM1-IO19", "brightness": 0.30 }
            ]
        },
        {
            "time" : "12:00:00",
            "channels" : [
                { "token": "PWM0-IO18", "brightness": 0.25 },
                { "token": "PWM1-IO19", "brightness": 0.30 }
            ]
        },
        {
            "time" : "14:00:00",
            "channels" : [
                { "token": "PWM0-IO18", "brightness": 0.50 },
                { "token": "PWM1-IO19", "brightness": 0.30 }
            ]
        },
        {
            "time" : "18:00:00",
            "channels" : [
                { "token": "PWM0-IO18", "brightness": 0.50 },
                { "token": "PWM1-IO19", "brightness": 0.30 }
            ]
        },
        {
            "time" : "20:00:00",
            "channels" : [
                { "token": "PWM0-IO18", "brightness": 0.10 },
                { "token": "PWM1-IO19", "brightness": 0.15 }
            ]
        },
        {
            "time" : "22:30:00",
            "channels" : [
                { "token": "PWM0-IO18", "brightness": 0.10 },
                { "token": "PWM1-IO19", "brightness": 0.15 }
            ]
        },
        {
            "time" : "23:00:00",
            "channels" : [
                { "token": "PWM0-IO18", "brightness": 0.0 },
                { "token": "PWM1-IO19", "brightness": 0.0 }
            ]
        }
    ]
}
```
*But... *it could look like this:


```
{
    "hardware" :{
        "board": "PiZero",
        "pwmMode": "hardware",
        "freq": 960,
        "channels": 2
    },

    "schedule" : {
        "PWM0-IO18" : [
            { "time": "08:00:00", "brightness": 0.0 },
            { "time": "08:30:00", "brightness": 0.25 },
            { "time": "12:00:00", "brightness": 0.25 },
            { "time": "14:00:00", "brightness": 0.50 },
            { "time": "18:00:00", "brightness": 0.50 },
            { "time": "20:00:00", "brightness": 0.10 },
            { "time": "22:30:00", "brightness": 0.10 },
            { "time": "23:00:00", "brightness": 0.0 },
        ],
        "PWM1-IO19" : [
            { "time": "08:00:00", "brightness": 0.0 },
            { "time": "08:30:00", "brightness": 0.30 },
            { "time": "12:00:00", "brightness": 0.30 },
            { "time": "14:00:00", "brightness": 0.30 },
            { "time": "18:00:00", "brightness": 0.30 },
            { "time": "20:00:00", "brightness": 0.15 },
            { "time": "22:30:00", "brightness": 0.15 },
            { "time": "23:00:00", "brightness": 0.0 },
        ]
    }
}
```
I quite like the second form, but I do wonder how messy it would make the controller. Right now it expects all channels follow the same schedule, a bit like the TC-420. It helped keep things performing well when it was in python. This change would break that assumption, but it would make the schedule a lot easier to read. I'm tempted to make the change, but I'm curious if it just makes sense to me, or if it is genuinely better.


----------



## Kaiede (Sep 11, 2017)

With some thinking, I realized I needed to do most of the refactoring work to support lunar cycles and thunderstorms anyways. It also made it possible to simplify how previews work, and will make it easier to trigger previews using REST in the future. The configuration just gets a nice readability bonus as part of the deal, and it manages to fix a bug with previews as well. As yet another bonus, it looks like I managed to lower CPU usage a little bit on the Zero doing it this way. Not a huge amount, but I'll take the win. 

I also wrote a bunch of tests along the way to try to make it possible to do the refactor as quickly as possible. Right now it's running on my extra Pi Zero so I can see how well it is working while I go back to the lunar cycle work. I'll move it over to my live tank once it has proven that it can run a full 24-hour cycle.

It may seem like it's taking a while to get to the next big feature, but at the same time, this core functionality is what I think folks will be interacting with much more frequently. Making sure it is as easy to use as possible, stable, and will accept the new features without turning into a complete mess is worth it IMO. And this particular piece of work actually made lunar cycles easier to implement, so it still helped move towards that goal.

Here's what the new form of the configuration will look like after this work for an example 2-channel configuration:


```
{
    "hardware" :{
        "pwmMode": "hardware",
        "freq": 960,
        "channels": 2
    },

    "PWM0-IO18" : [
        { "time": "08:00:00", "brightness": 0.0 },
        { "time": "08:30:00", "brightness": 0.25 },
        { "time": "12:00:00", "brightness": 0.25 },
        { "time": "14:00:00", "brightness": 0.50 },
        { "time": "18:00:00", "brightness": 0.50 },
        { "time": "20:00:00", "brightness": 0.10 },
        { "time": "22:30:00", "brightness": 0.10 },
        { "time": "23:00:00", "brightness": 0.0 },
    ],

    "PWM1-IO19" : [
        { "time": "08:00:00", "brightness": 0.0 },
        { "time": "08:30:00", "brightness": 0.30 },
        { "time": "18:00:00", "brightness": 0.30 },
        { "time": "20:00:00", "brightness": 0.15 },
        { "time": "22:30:00", "brightness": 0.15 },
        { "time": "23:00:00", "brightness": 0.0 },
    ]
}
```


----------



## Kaiede (Sep 11, 2017)

Work on the lunar cycle behavior is going quite well, thanks to the work I did this last weekend. I can probably get it done this next weekend, I think. 

In the meantime, I played around with a little experiment: packaged binaries. I posted a set of binaries up on GitHub under the 0.2.2 release. Grab the armv6l version for the Pi Zero and 1. Grab the armv7l version for the Pi 2 and 3. You will also need the matching swift 3.1.1-uraimo package also provided. Install it using 'sudo dpkg --install' on both deb files. 

This should make it a bit easier for some folks. Or at least faster to update. So far it seems to work, but it is still somewhat experimental. 

I started thinking about how to make it possible to start doing a mobile app to discover/configure instances of RPiLight on a local network. The easiest answer is to use an existing framework. Swift has a growing server-side presence, so there's a few options, with a couple big ones being Kitura and Vapor. These would also make it possible to host a micro-website off the Pi for configuration as well. The problem is that these are not fast projects to build. Kitura took 9 minutes, and Vapor took a whopping 30 minutes to build on the Pi Zero. And release builds are even slower. I can get away with making people run a script to build from source for now, but not when a project takes 15-20 minutes to build.


----------



## Mike! (Mar 26, 2018)

Kaiede said:


> The UniPi cases showed up today. It’s a bit tight for 2 channels but I think it is doable if I ditched the headers on the MOSFETs and shortened the wires I used. This is about as small as this project can go I think. Not too bad though. Can Velcro it to the inside of my tank stand to keep it out of the way.
> 
> Because I’m running 6A for the 900E, and I’m paranoid, heatsinks on the MOSFETs.


Nice! The complete lack of solder here has my mind racing with plans...


----------



## Kaiede (Sep 11, 2017)

Mike! said:


> Nice! The complete lack of solder here has my mind racing with plans...


I did have to solder the headers onto the MOSFET triggers. But those are also the cheapest part, where I can get them for a buck each on the slow boat. 

----

I'm now running lunar cycles on my aquariums to test it. There's at least one bug so far, but the early results are looking good.


----------



## Kaiede (Sep 11, 2017)

Interesting thing I learned about the Fluval 3.0 today. The driving of the LEDs is surprisingly good, and there isn’t really much in the way of PWM effects. Bubbles from air stones being the easy way to notice them in controllers that use frequencies <1kHz. 

It does look like the Fluval 3.0 does use PWM, but it is up in the 10kHz range, as the best estimate I could make. Give or take a couple kHz. 

Out of pure curiosity, I was able to push the Twinstar up to about 16kHz using the MOSFET trigger and the on-board PWM Hardware. The air stone bubbles looked better than the Fluval 3.0, but just barely. Bringing it back down to 10kHz got an effect almost identical to the 3.0. And it seems stable.

Considering so many dimming controllers use <1kHz PWM, I’m surprised to see such a high frequency here. Nice going, Fluval.


----------



## jeffkrol (Jun 5, 2013)

Thought you were hardware restricted to below 10kHz..


> Adjustable PWM from 480 Hz - 2.8 KHz (Adafruit limited to 1.4 KHz)


----------



## Kaiede (Sep 11, 2017)

jeffkrol said:


> Thought you were hardware restricted to below 10kHz..



Only because it hadn’t been tested, and I didn’t think there was much benefit at the time. Especially when Meanwells can’t accept PWM input faster than 1kHz. The 2.8kHz was picked through experiment as a reasonable limit to try to limit the damage folks could do to their kit accidentally.

But seeing how the Fluval behaves with an air stone added made me wonder about what was going on and revisiting things. I thought they must also be using PWM, so why did the bubbles look so much better?

The MOSFET triggers can handle up to 20kHz on the input. The PWM channels are driven by a 250Mhz clock (PLLD on the Pi). As you ramp up the PWM frequency you lose resolution in the duty cycle. That’s because you tell it how many ticks of the clock is a cycle, and how many ticks the signal should be high. But you keep 12-bit resolution up to about 60kHz.

So I removed the limit locally and started playing. I’ve even checked in the revised limits to the repo. So you can use up to 16kHz if using the two hardware channels.

The 1.5kHz limit on the PCA9685 is hardware though. It was built as an LED controller, and they didn’t think lighting benefited from going higher. They aren’t wrong in the general case, anyhow.


----------



## Kaiede (Sep 11, 2017)

v0.3 is just about done. I'm watching the behavior for the next day or so to make sure the last bug is fixed, and then I'll tag the release and build binaries. This release is quite a bit bigger than I originally planned:


 Can enable a Lunar Cycle to dim parts of your schedule based on the current phase of the moon.
 New, compact configuration file format (w/updated examples).
 Limits increased for PWM frequencies. 16 kHz for built-in, 1.5 kHz for the PCA9685. 
 Service now only runs as root on launch. It needs it to access the PWM hardware on the Pi, but can now switch to a lower-privilege user ('pi') 
 Updated build scripts that can produce debian/raspbian packages. 
 Under the hood work along with new tests to try to keep things stable, and lay the groundwork for future features. 

Because the service no longer needs root except when it configures the hardware on startup, this will improve security a bit. It also will allow me to start writing a REST API down the road without worrying quite so much about the security issues of an HTTP server running as root. 

Going forward, the plan is to hit 0.4 with Thunderstorm events, and then look at what work is needed to get to 1.0. 1.0 is meant to be complete in the sense of it has the core feature set, but it doesn't support REST/Web configuration. After that, we'll see. I suspect I'll stay actively involved long enough to put together the REST API and put together a simple mobile app for iOS.


----------



## Kaiede (Sep 11, 2017)

f-fish said:


> Very nice .. any plans for adding some mqtt functionality? Is the idea that this will be an end node or also a basic hub for other sensors and features?


So, now that I'm further along, I'm starting to think about what remote control looks like. The more I think about it, the more that MQTT does seem like a good idea. The libraries are simpler, and having a separate broker makes me a little less nervous about running a full HTTP server as part of the controller daemon. Plus, there's client-side JS libraries so it wouldn't make a web front end any more difficult than REST. And there appears to be multiple client libraries on iOS and Android. So it should handle the job well without adding too much bloat.

It also opens opportunities for folks to contribute modules for things like say, temperature monitoring, without having to integrate into mine directly. They can just co-exist as subtopics under the same aquarium path using the same broker. I like it.

----

I've also been playing around with Debian Buster for 64-bit ARM on the Raspberry Pi 3B. I'm mostly looking at it for long-term planning. I want to have an "exit plan" in case Swift 4 doesn't really materialize on the Pi Zero, and Swift on 64-bit ARM gets more attention than 32-bit ARM. 

It looks like it works with only one change needed, so that's good news. It would be easy to migrate RPiLight. It'd be a shame to ditch support for the Zero being 20$ cheaper than the 3B, but we'll see where things are in a few months. 

----

Also did a little work towards thunderstorm support. Still trying to zone in on the right approach to the flash patterns. Not a ton of existing documentation on doing stuff like this to work from.


----------



## Kaiede (Sep 11, 2017)

Couple random questions in case folks are lurking:

1) Does anyone other than me actually intend to use the Zero? I've been going back and forth with folks, and it looks a lot like it will be easier to focus on the Pi 3B going forward. So if nobody but me is using it, I may just bail on it now rather than spend too much more time keeping it going. 

2) Am I the only one that thinks it could use a better name?


----------



## f-fish (Jul 18, 2009)

Fully agree mqtt - would be a great next step. 

Personally - Pi3B or B+ is the way to go, zero is cool for a very explicit use-case and small form factor, but the out the box, slightly larger foot print of the 3B's with the little extra capacity to add other services makes the 3B's a more natural choice - but this is just how I am using these devices. 

As for the name ... add some numbers - it always makes the project feel more mature. 

Later Ferdie


----------



## Kaiede (Sep 11, 2017)

f-fish said:


> Fully agree mqtt - would be a great next step.
> 
> Personally - Pi3B or B+ is the way to go, zero is cool for a very explicit use-case and small form factor, but the out the box, slightly larger foot print of the 3B's with the little extra capacity to add other services makes the 3B's a more natural choice - but this is just how I am using these devices.


Yeah, if tinkerers are going to mess with it, the 3B is probably a better choice. But the Zero had some nice advantages, like half the cost, and half the power draw. But the 3B will be supported for longer.

---

Welp, I found my first _nasty_ bug here. I accidentally introduced an integer overflow that shows up during the lunar period. Didn't catch it because my tests don't check for 32-bit overflows. Awesome. There's now a hotfix for that and a new test for overflow.


----------



## jeffkrol (Jun 5, 2013)

Second the Pi3..

Pi zero, like Aduino is a better choice if one is doing a commercial product (cheaper parts) 
and power draw (unless specifically regarding internal heating) seems irrelevant for aquarium uses where 500W heaters and 100W lights are being used..










https://raspi.tv/2016/how-much-power-does-raspberry-pi3b-use-how-fast-is-it-compared-to-pi2b


----------



## Kaiede (Sep 11, 2017)

jeffkrol said:


> Second the Pi3..
> 
> Pi zero, like Aduino is a better choice if one is doing a commercial product (cheaper parts)
> and power draw (unless specifically regarding internal heating) seems irrelevant for aquarium uses where 500W heaters and 100W lights are being used..


When I run a 33W light at 60% intensity, going from 1.4W to 0.7W is still saving about 3.3% of the total power consumption for the lights. Not huge, but nothing to sneeze at. That was the math I was using based on charts like that one for supporting the Zero. But yeah, the writing is on the wall. 32-bit ARM is the past, 64-bit ARM is the future, but it isn't _quite_ here yet for the Raspberry Pi.

So here's what I'm planning on doing: I'll be focusing on the 3B with my development and targeting it. The Zero, at least for the time being will still be "supported", but not "actively developed". So if it breaks, I'll fix it, but beyond what automation finds for me, I'm not going to be looking for those issues myself. I'm still stuck on Swift 3 in the short term, even on the 3B, so it doesn't quite make sense to cut it off completely. I'm just not going to burn time on it like I am now, suffering through the slow builds. I bet the Zero will still be supported when I reach 1.0 though. 

I'll be keeping an eye on 64-bit Debian Buster on the 3B/3B+. It works on the 3B (minus bluetooth). The 3B+ also kinda works, but Wifi is also broken. RPiLight already runs on the preview build on a 3B, so that's neat. Buster is just not quite stable enough to jump over to yet. But it will be easier to poke at this from time to time if I'm not actively juggling ARMv6 and ARMv7 builds. 

...

Anyhow, this weekend I'm going to be messing a bit with some LED strips and a test bed for writing thunderstorm behavior. I've got a couple ideas on how to build the algorithm, but I need to play around with the constants involved. Once that algorithm is worked out, it will be pretty easy to add to the controller. I have been looking around, but folks who have done this sort of thing before me, haven't really made their work easy to find via Google.

This is the last big feature before pushing towards 1.0. I want to do some cleanup and quality of life work, but I think it is a good place to call it "ready for production". 

I'm also a bit surprised how stable things have been. Other than the issue I fixed last night, I haven't had to worry about it up and crashing at all in the last few weeks. I tend to update the controllers running my two tanks once a week. Otherwise they run 24/7 for me.


----------



## jeffkrol (Jun 5, 2013)

Request a "photography" setting which throws all channels on full.
It's in the BF mini..and kind of took a shine to it..
Startiling to fish though..


----------



## Kaiede (Sep 11, 2017)

jeffkrol said:


> Request a "photography" setting which throws all channels on full.
> It's in the BF mini..and kind of took a shine to it..
> Startiling to fish though..


I'd like to do something like that too. But there's two things that make it _so much easier_ though: A way to communicate with the app, and the concept of behaviors/modes that act as overrides. The neat part is that thunderstorms share a lot in common with that second part, but don't need the first.

MQTT and the sort of utility it enables is what post-1.0 looks like. Something like a photo / check-up mode would be very good early test of MQTT, I think. 

Best part is that I think a super-fancy fade between the current light level and the full light level would be very easy. It helps when time is simply an input to your calculations, so you can replace it with any point in time you like.


----------



## jeffkrol (Jun 5, 2013)

3B or 3B +.. ?


3B's can be had for cheaper than the Pi Zero.

do you need the servo "hat" for the 3b or can it natively (looks like at 3.3V) do multi-channel PWM ?


----------



## Kaiede (Sep 11, 2017)

jeffkrol said:


> 3B or 3B +.. ?
> 
> 3B's can be had for cheaper than the Pi Zero.
> 
> do you need the servo "hat" for the 3b or can it natively (looks like at 3.3V) do multi-channel PWM ?


If you can find 3Bs for 10-15$, I want to know where so I can stock up on a couple.

The 3B and 3B+ are the same SoC. The CPU is clocked a bit higher on the 3B+, it has power-over-ethernet, and faster ethernet/wifi. For my project, they are already both overkill. The 3B+ is faster, and so you will save some time if you are planning on doing a lot of building or other heavy CPU load work with it. Controlling an aquarium with it isn't really heavy on the CPU.

The native built-in PWM controller is limited to two channels. The Hat/Bonnet can do 16 channels.

It is possible to use DMA to drive PWM beyond the 2 channel limit. SwiftyGPIO (the library I use) currently doesn't have the ability, but I've already been making fixes in it (arm64 fixes, PWM fixes). It wouldn't be impossible to add support for DMA based PWM to it. I just never really looked into it. 2 channels is enough for me, and the bonnet gives very nice results up to 16 channels. DMA was always lower priority to me compared to that. I'd probably be playing around with pigpio a bit just to see what the limits were (it supports DMA PWM and comes with a command-line tool you can use to just poke at the IO pins without writing code).


----------



## jeffkrol (Jun 5, 2013)

Kaiede said:


> If you can find 3Bs for 10-15$, I want to know where so I can stock up on a couple.
> 
> The 3B and 3B+ are the same SoC. The CPU is clocked a bit higher on the 3B+, it has power-over-ethernet, and faster ethernet/wifi. For my project, they are already both overkill. The 3B+ is faster, and so you will save some time if you are planning on doing a lot of building or other heavy CPU load work with it. Controlling an aquarium with it isn't really heavy on the CPU.
> 
> ...



Pm'd you.. Was worth a chance..and since you are doing the hard work, deserve first dibs..


----------



## Kaiede (Sep 11, 2017)

Haven't gotten a lot of time this weekend to mess around with the lightning flash behavior. Made some progress, but it's not quite looking right yet. 

With the 3B, this case is working well for providing space for my MOSFET triggers, but would work well for a HAT/Bonnet too: HighPi Case.



jeffkrol said:


> 3B or 3B +.. ?


I did get a chance to double check, and the difference between the 3B/3B+ is fairly small. The CPU is not really getting me any gains that I can measure right now. Once you bring disk into the picture, the gains seem to be getting wiped out. 

At least for my purposes, the two are identical.

But because the WiFi and Ethernet is newer in the 3B+, the support outside Raspbian isn’t as good, and you pay even higher costs in wattage than the 3B. So again, trade offs, but minor ones.

I’m using 3Bs for the tanks as of today, and my dev is being done on a 3B+. I need to grab another 3B to run 64-bit Debian Buster soonish, because the 3B+ isn’t fully supported on it yet. It boots, but has enough issues I don’t want to mess around with it.

----

I got lucky and wrote some lightning behavior that looks good enough to use. I think it can be better, but I'm also not wanting to spend too much time tuning it. Now I just really need to integrate this into the controller over the next few days.

All this flashing has given me a headache though. Ugh.


----------



## Kaiede (Sep 11, 2017)

jeffkrol said:


> do you need the servo "hat" for the 3b or can it natively (looks like at 3.3V) do multi-channel PWM ?



I remember why I skipped on DMA PWM now (which would get you more than 2 channels on the built-in Hardware).

While I’m achieving at least 12-bits of dimming with both the built-in hardware and the Adafruit piHat, doing the same using DMA would be kinda messy, so I decided to sit on it. 

The issue is that the useful resolution is about 1 microsecond. This means about 1 million slices of time. Divide that by the frequency, and you get the “range” possible for dimming. So the sort of best balance I can achieve is 1kHz with 1000 steps of dimming. Definitely usable, but getting here is probably one of the more complicated things I would be messing with, and it is beaten by a 10-15$ add-on board. 

I’ve added an issue to track DMA PWM support on GitHub, but I’m currently considering it low priority, for the above reasons.


----------



## jeffkrol (Jun 5, 2013)

Found an interesting paper...
https://www.researchgate.net/profil...and-development.pdf?origin=publication_detail


> An interesting effect was obtained in the experiment, it was
> that the continuous light (without darkness period) had uPSII values
> greater than some frequencies (5 kHz, 10 kHz, 50 kHz and
> 100 kHz).


May want to keep PWM rates below 4kHz..


----------



## Kaiede (Sep 11, 2017)

jeffkrol said:


> Found an interesting paper...
> https://www.researchgate.net/profil...and-development.pdf?origin=publication_detail
> 
> 
> May want to keep PWM rates below 4kHz..


Indeed. Always useful to have data like that.

Interesting you bring this up. I recently found a bug I introduced into the math of the PWM frequency. When using the built-in PWM, the frequency was about 4x slower than what was asked for. Yikes. So when I was pushing "2880 Hz", or the "8000 Hz" I have it configured for now. It was more like 720Hz and 2000Hz. Been like that since 0.1.5.

That's a bit embarrassing, but I have a fix for it. 

I got a little sidetracked because of that bug, and the state of SwiftyGPIO. One issue I'm hitting is just the slow pace of getting changes merged back in, so I'm perpetually stuck on my personal fork of the code. The other issue is that SwiftyGPIO isn't exactly what I'd call easy to maintain. I wound up writing up a prototype library that could replace it the last couple of nights. It is already looking good, but there's a little cleanup that needs to happen before I can switch over to it.

I finally got around to adding more headers to the Servo/PWM piHat, so I can test both the built-in PWM and the add-on board without removing the add-on board. Helpful.


----------



## jeffkrol (Jun 5, 2013)

What about this "servo" board?
https://www.sparkfun.com/products/14328
Uses a PCA9685 controller chip.


> Each LED output has its
> own 12-bit resolution (4096 steps) fixed frequency individual PWM controller that operates
> at a programmable frequency from a typical of 24 Hz to 1526 Hz


OPP's same chip as the Adafruit.. my bad..
bit less soldering though..


----------



## Kaiede (Sep 11, 2017)

Yeah, that's not a bad alternative source for the board. The "Bonnet" version of the Adafruit has the Pi header soldered on for you, while this has the channels soldered for you. Both are 10$. Pick your poison, I guess. The 15$ full-size HAT version that Adafruit sells is more useful when doing dev work because it has the pin breakout and perfboard space. But the smaller version is cheaper if just building it as a kit, and just as good.

I've been tempted to pick up a Rock64 to play with. It'd be compatible with the PCA9685 boards, is 64-bit out of the box, and can be had for 25$ compared to the Pi 3B. Smaller community than the Pi, but still bigger than 64-bit on Pi. The reason I haven't jumped is that it has 4 PWM channels in the SOC, but none of them are actually usable. 2 of them are unconnected on the PCB. The other 2 share an I2C bus that is used to control the power supply chip. That's rather important. Add in needing a Wifi dongle, and it's a mixed bag for this particular project. The main benefit is the 64-bit distro support out of the box.

But price wise, a 1GB Rock64 + PCA9685 board is 35$. So even in my case where I only care about 1-2 channels, it only gets worse than the Pi 3B when I add in the WiFi dongle.


----------



## Kaiede (Sep 11, 2017)

Well, I intended to work on the integration for thunderstorm support tonight. Got distracted, but I think this particular distraction is a good one: I managed to build RPiLight using Swift 4 on Raspbian Stretch. And it runs. 

This means I have a good chance that I don't need to wait to migrate to Swift 4. At least for the Pi 3B/3B+. So that's some load off my mind about the future.

----

EDIT: Well, it's looking even better now. Fixed a bug in a core Swift library, and now it looks like we have a good 32-bit Swift 4 build that should be suitable for longer-term development. Doesn't run on the Zero/1, but the 3B/3B+ with Raspbian Stretch is covered. 

That's actually a bit of a load off my mind. Knowing for a fact the build exists means I don't have to worry too much about back porting stuff to Swift 3, which takes time. I can focus RPiLight more on Swift 4 if I want, and have more options for libraries.

This was a bit of geeking out on underlying tech the last week or so. But I'm actually feeling pretty good right now. I'm going to take a break from this and come back to it in a couple days, beyond a little tinkering here and there (I need to poke at the PWM output with an oscilloscope when it comes in). The thunderstorm support is about half done. And the remaining bit is the easiest part.


----------



## Kaiede (Sep 11, 2017)

It's been a while. 

On the RPiLight front, I've had to dig into a couple things that I wasn't really expecting to have to deal with. I've still got one bug kicking around that I need to track down where the refresh timer just stops. The service runs, but the lights stop updating. Good news is that it is deterministic, as both my tanks hit the bug at the exact same moment. I've added additional logging and a watchdog that helps get things back on track if it occurs. I'm still watching this, but it's also a bit slow going since it appears once every couple weeks.

I was attempting to make it possible to reload the configuration file automatically, but it wound up wasting some time as I used an approach that doesn't work on Linux. Whoops.

I've also been playing with migrating to Swift 4.1, now that binaries for Raspbian are coming along. Found a couple bugs in Swift's Foundation library that I've fixed, and I should be able to start the migration in the next week or so.

Now for the giant distraction. I've gotten the itch to figure out how to get Swift 4.2 working on Raspbian, since it just released, and will be the "main version" for the next year or so. I've been digging into that. I've made a lot of progress, but it's been a fair bit of work:

- Got 32-bit x86 Swift building (mostly) where it didn't build at all before
- Got 64-bit ARM Swift 4.2 working fully
- Fixed bugs in Swift's Foundation library
- Currently investigating the 32-bit breaks in 4.2

Yes, it's a distraction, but for the moment, the light controller is working well for me, so I'm okay letting it sit while I make sure there's a future path for Swift on these single board computers. There's a fairly big impact I can have doing so.


----------



## Kaiede (Sep 11, 2017)

Weather effects are almost ready. I’ve got code that looks to be ready to take over one of my tanks for testing. 

I’ve also been doing testing of Swift 4.1.3 and 4.2 on the Raspberry Pi 3. One of my aquariums is running 4.1.3 and the other is running 4.2 (Yes, I did get it working). 

I’m honestly getting to the point where I’m really wanting to move onto the next thing, and that is remote control. So the plan going forward is:

- Stabilize Weather Effects, and tag 0.4
- Do cleanup/fixes, and tag 1.0 in about a month or so once it’s demonstrated to be stable. Releases between 0.4 and 1.0 will be 0.9.x, which will be stability fixes and configuration cleanup work only. 
- Start working on post-1.0 functionality at the same time, which is still likely to be built on top of MQTT, and will drop support for Swift 3. There’s a couple existing libraries for MQTT that I want to use, but they are Swift 4 only.


Sent from my iPad using Tapatalk


----------



## Kaiede (Sep 11, 2017)

First, the bad news. I haven’t had much chance to test the thunderstorm work properly, and I’ll be honest, I’m not really all that interested in doing it. I don’t even really want the feature for myself, I just wanted to see if I can do it. At this point, I think it’s better if I shelve the work (it is on github, so it’s not lost) and move onto more productive things.

The good news is that the fixes I made at the start of Oct around the service not being stable for more than a couple weeks appears to be working. It’s been over a month without an incident on either tank, which is a good sign. 

Going forward, I’ll tag a 0.9 release with the fix, and then start working towards 1.0 with the one or two things I still want to get done. These again are mostly things aimed at making it easier to configure the controller over SSH. 

So if there’s any specific requests to get into the 1.0 release before moving onto remote control, now is the best time to get them in.


----------



## Kaiede (Sep 11, 2017)

I’m starting to do some of the initial design around how to communicate with the light controller over MQTT. Right now, it looks a bit like this:


```
Root of a specific light controller:
aquariums/<aquarium-name>/

Topics under each light controller:
./schedule
./hardware
./preview
```
The hardware topic is mostly read-only, where the controller makes configuration information about the controller available. This is information like the number and name of the channels. Things that don’t normally change. In the future, this may be where the channels could be renamed by a client. The controller will send a retained message to this topic on start.

The schedule topic is read/write. This is a JSON copy of the schedule. On start, or when a new schedule is becomes active, a retained message is sent to the topic by the controller. So a client will be able to subscribe and read the current schedule at any time. A client can publish a message to this topic with a new schedule, which the light controller will attempt to make active. 

The preview topic is used to let clients preview schedules. The controller is subscribed to it, but doesn’t send any message to the topic itself, generally. Instead, a client can write a schedule to this topic, and it will preview the schedule without making it active. Updates about the state of the preview (% complete) are sent to the topic by the controller when a preview is active.


----------



## jeffkrol (Jun 5, 2013)

Kaiede said:


> I’m starting to do some of the initial design around how to communicate with the light controller over MQTT. Right now, it looks a bit like this:
> 
> 
> ```
> ...



Check in time...


----------



## Kaiede (Sep 11, 2017)

jeffkrol said:


> Check in time...


Yeah, I haven’t made a ton of progress here. Other aspects of life are intruding, changes in other areas, etc, so I’m not able to carve out a ton of time. I do need to get back in and finish the changes I was making to support the MQTT bits. It’s been mostly research and experiments so far, sadly.

The fact that I haven’t touched the schedule or controllers themselves in months now is another reason. No pressing bugs to fix. :|


----------



## penitent_tangent (Apr 3, 2012)

With the code in its current state, would adding a second PWM/Servo bonnet allow you to address 32 channels of PWM? I know the Adafruit site specifies that you can stack up to 62 of them together for 992 channels of control. I didn't see anything quickly looking through the source code, but I haven't really spent any time learning the syntax of Swift.


----------



## Kaiede (Sep 11, 2017)

It currently only supports a single board.

The issue is that right now, the service only supports a single output “device”. It also doesn’t support setting the I2C address of the board in the config file. 

My thoughts are that it would be best to make it possible to “combine” multiple outputs together. So you could use the built-in PWM with a board to get 18 channels, or multiple boards together to get more.

It just wasn’t high on my priorities, and I’m in the middle of splitting out the hardware configuration from the schedule configuration for the remote control features. It’d be easier to implement once that is done, I think.


Sent from my iPhone using Tapatalk


----------



## Kaiede (Sep 11, 2017)

penitent_tangent said:


> With the code in its current state, would adding a second PWM/Servo bonnet allow you to address 32 channels of PWM? I know the Adafruit site specifies that you can stack up to 62 of them together for 992 channels of control. I didn't see anything quickly looking through the source code, but I haven't really spent any time learning the syntax of Swift.


Just a follow up to my previous answer that might be interesting:

I’ve been tempted to see if I can control 0-10V light systems with this setup. Say, a Kessil light. The easiest way to prototype this would be using I2C DACs, and to control both the intensity and color spectrum channels, I would need to do the work that would make it possible to control more than one PWM Bonnet.

So this sort of hardware configurability might be something I work on pretty soon while I wait for the DACs to show up.

*UPDATE:*

I've made the changes to support multiple outputs in the vNext branch. It's not quite ready for human consumption because that branch also requires a specific build of Swift 4.1.3 when using 32-bit Raspbian as the OS, and I haven't setup the bootstrap scripts to grab the right build yet, I don't think.

I also want to run it on my tank for a little while before I declare this "good" to be tagged and released. 

This also does the work needed to split the hardware configuration from the schedule, which is needed for the MQTT work going forward. And it shouldn't take me long to write up something to support the MCP4725 0-10V DAC boards that exist. With a couple of those, I could have full control of a Kessil light or two.


----------



## Kaiede (Sep 11, 2017)

I've made some further progress. I've got the code pretty much ready to go for when I get my DAC boards to see if I can start controlling a 0-10V light like a Kessil.

So the good things coming down the pipe once I've tested this:

 Support for multiple outputs, including the ability to mix-and-match output types. So you can use the GPIO PWM along with the Bonnet at the same time (or multiple bonnets). This can be useful especially if you have 1-2 channels that make up most of your light output, you can put them on the higher frequency PWM of the GPIOs to reduce flicker effects.
 Schedule and Hardware configuration files have been split apart. This will help enable remote control using MQTT.
 You now name your channels, making the schedule a little easier to work with. 
 Support for outputting 0-10V using MCP4725 boards that output 0-10V (i.e. amplified from 0-5V on the board) from Aptinex or ncd.io. Multiple outputs is useful here since the MCP4725 is a single-channel DAC, and Kessil needs two. It's also possible to use the unamplified 0-5V breakout from Adafruit, but that requires you build your own voltage doubler.
 In progress work to support Swift 5 (just released) on the Raspberry Pi 3 using Ubuntu Bionic 64-bit. I'm not holding out much hope that Swift 5 will work on 32-bit Raspbian, but a couple folks are trying anyways.


----------



## jeffkrol (Jun 5, 2013)

What is the current available to the 10V analog output..
Had problems w/ this before w/ Meanwell drivers..
Doing passive voltage doubling led to current losses and lack of dimming..
Though this was w/ a Typhon that had 10V PWM "reversed" so a normal R/C circuit failed.
Doubling the 5v PWM and smoothing to analog created too much current loss..


----------



## Kaiede (Sep 11, 2017)

jeffkrol said:


> What is the current available to the 10V analog output..
> Had problems w/ this before w/ Meanwell drivers..
> Doing passive voltage doubling led to current losses and lack of dimming..
> Though this was w/ a Typhon that had 10V PWM "reversed" so a normal R/C circuit failed.
> Doubling the 5v PWM and smoothing to analog created too much current loss..


That's something I'll have to experiment with. While the boards available are meant to drive industrial control signals that are 0-10V, they don't specifically say what the max current of the output signal is. ncd.io in particular claims theirs is good for "light fixture controllers". So we shall see if that's true, since that is what I have on order.

To be clear though, this is control of a 12-bit DAC, not PWM. The MCP4725 itself has an embedded DAC + OpAmp to output 0-5V that can sink 25mA max. The boards themselves spend most of the circuitry ramping that up to 0-10V, and only support a single channel per board, as a result. Not the cheapest way to do it, TBH. 

The Adafruit board is pretty much useless for this unless you intend to prototype your own multi-channel output board.

EDIT: In general, the current range for the 0-10V signal I'm seeing is around 10uA to 2mA according to Lutron, which sounds about right. While my memory of voltage doubler circuits is spotty at best, it seems like there's still plenty of overhead in most cases unless someone's requiring a lot more than 2mA for some goofy reason.


----------



## jeffkrol (Jun 5, 2013)

Kaiede said:


> EDIT: In general, the current range for the 0-10V signal I'm seeing is around 10uA to 2mA according to Lutron, which sounds about right. While my memory of voltage doubler circuits is spotty at best, it seems like there's still plenty of overhead in most cases unless someone's requiring a lot more than 2mA for some goofy reason.



Pretty sure Meanwell ELN-60-48D's wouldn't work w/ that.. At least not for me..
D for dimmable, P for PWM (which worked w/ both 10vanalog and 10v PWM)

Obsolete now ..well the "d" series..

Used some IC (I'll have to dig it out) and an R/C circuit on the 5V PWM to create a pseudo-DC signal to be doubled..


Believe current ended up about 10mA or so (roughly 1/2 of a Typhon (Aduino) output.)
Didn't work though output spec'd about 9V at full. About a 1V loss w/ a Zener diode in the circuit..


So it may just "depend".. 


(Knowing just enough to be dangerous)..

HISTORY:


> I have and use both the Apex and the RKE. Four 0-10v channels (for dimming) come standard on the Apex, but for the RKE/RKL line you would need to purchase an extra module called the RKM-ALC, which has two 0-10v channels per module.
> 
> The Apex channels are also a bit more versatile than the RKM-ALC channels. For example, you can run multiple meanwells on the same channel with an Apex, but cannot with an RKE/RKL ALC module, at least not properly.
> 
> ...


----------



## Kaiede (Sep 11, 2017)

jeffkrol said:


> Pretty sure Meanwell ELN-60-48D's wouldn't work w/ that.. At least not for me..
> 
> <snip>
> 
> Believe current ended up about 10mA or so (roughly 1/2 of a Typhon (Aduino) output.)


10mA and it still didn't work? That's an awful lot of current being sunk for a dimming input. Now I'm curious what it did do when you hooked it up.

EDIT: The more I read, the weirder this gets, since the "input" in this case is really a sink to pull down the voltage that the driver should be placing on the wire. So there should be very controllable current levels running through the dimmer circuit, and those current levels are controlled by the driver, and the resistance of the dimmer circuit.


----------



## jeffkrol (Jun 5, 2013)

Sorry.. memory failed me...




> by pebe » Sun Aug 18, 2013 7:31 am
> 
> Using a 1K resistor:
> V Bat= 7.57 V
> ...


----------



## Kaiede (Sep 11, 2017)

That current level seems reasonable and doable with these boards. I’m tempted to bench test a Meanwell driver now just to see.


----------



## jeffkrol (Jun 5, 2013)

Kaiede said:


> That current level seems reasonable and doable with these boards. I’m tempted to bench test a Meanwell driver now just to see.


I abandoned Meanwell ac/dc drivers due to this "issue". and 0-10V though a "standard" is one of those things that should never have been..




Even industrially , the use of current dimming is far superior to voltage dimming..
Just another "ease of use " thing ...
http://www.ti.com/lit/an/slua119/slua119.pdf
https://automation-insights.blog/2010/06/22/analog-signals-0-to-10v-vs-4-20-ma/




> A 4-20 mA or 0-20 mA signal, on the other hand, offers increased immunity to both electrical interference and signal loss over long cable runs. And most newer industrial controllers will accept current signals. As an added bonus, a 4-20 mA signal provides inherent error condition detection since the signal, even at its lowest value, is still active. Even at the extreme low end, or “zero” position, the sensor is still providing a 4 mA signal. If the value ever goes to 0 mA, something is wrong. The same can not be said for a 0-10V sensor. Zero volts could mean zero position, or it could mean that your sensor has ceased to function.



PERSONAL vendetta.. 

FOR historical reference:
The IC I attempted to use to double the smoothed 5V PWM..
https://www.renesas.com/us/en/www/doc/datasheet/icl7660s-a.pdf


> Positive Voltage Doubling
> The ICL7660S and ICL7660A may
> be employed to achieve
> positive voltage doubling using
> ...


Oh and Schottky diodes not Zeners..


> Output voltage was :
> "no load output" from VOM of circuit using the Typhon 5v PWM outputs:
> New diodes in.. dimming down to zero w the Typhon..
> 0%=0
> ...


IF I remember correctly one could adjust the Meanwell driver to compensate for the lack of "real" 10 volts.
Like I said though... it became a current issue I believe..


----------



## jeffkrol (Jun 5, 2013)

O/T and things you generally never think about.. 

https://hackaday.com/2019/04/08/give-your-raspberry-pi-sd-card-a-break-log-to-ram/



> The fragility of SD cards is the weak link in the Raspberry Pi ecosystem. Most of us seem to have at least one Pi tucked away somewhere, running a Magic Mirror, driving security cameras, or even taking care of a media library. But chances are, that Pi is writing lots and lots of log files. Logging is good — it helps when tracking down issues — but uncontrolled logging can lead to problems down the road with the Pi’s SD card.


----------



## Kaiede (Sep 11, 2017)

When I was scrounging in the guts of Swift itself, I was noticing how many folks were burning out SD cards doing these big expensive builds (with swap files) instead of using a USB drive for the kind for stuff that thrashes the SD card. Faster too.

My dev board has a pocket USB drive hooked up to it for that reason.


----------



## jeffkrol (Jun 5, 2013)

Just because I can.. 
https://www.tomshardware.com/news/raspberry-pi-raspbian-2019-04-08-update,39037.html



> The update brings with it the Chromium 72 web browser, version 3.0.6 of the VLC media player and a grab bag of other package updates and quality of life improvements for the platform.
> 
> Phoronix said the Raspbian 2019-04-08 update also includes "SD Card Copier tweaks to reduce copy failures, various bug fixes" and the introduction of Ethtool and RNG-tools.


----------



## jeffkrol (Jun 5, 2013)

https://www.tindie.com/stores/Ranthalion/

Fun hardware..


----------



## Kaiede (Sep 11, 2017)

jeffkrol said:


> https://www.tindie.com/stores/Ranthalion/
> 
> 
> 
> Fun hardware..



Not only that, reef-pi looks like a fairly complete project at this point, beyond what I was intending. Although using some sort of pub/sub IPC to coordinate different modules with a front end would make them interchangeable and less coupled. Neat that my code likely would work with the HAT as-is, though. 

Wonder why they use channels 4-15 and ignore 0-4 on the 9685 for the HAT. Interesting.

Wish I knew more Go so I could understand what their light controller supported. Not a bad choice for a back-end though. 

At this point, my light controller has been operating without intervention for 3+ months, without a service restart. Memory usage is constant but not very low, about 23MB resident. That’s probably the main drawback.


Sent from my iPad using Tapatalk


----------



## jeffkrol (Jun 5, 2013)

Kaiede said:


> At this point, my light controller has been operating without intervention for 3+ months, without a service restart.


Cool 
kind of more amazing stuff..
https://github.com/blueacro/reefpi-pico/blob/master/reefpi_pico_v2.pdf


https://www.reef2reef.com/proxy.php...m-1.jpg&hash=5f2b8f578dd6ba28ebfcf66c6e989369


https://www.reef2reef.com/threads/reef-pi-base-boards.499890/
Pi-Zero though...

OPP's..


> Pi 3 should work fine when used with a M/F ribbon extender.


----------



## jeffkrol (Jun 5, 2013)

I have attempted to convince Reef-Pi people to add your gamma dimming to their program.. hope you don't mind..


----------



## Kaiede (Sep 11, 2017)

There’s no real magic there. More LED driving software/firmware should be accounting for gamma. So I hope they pick up the feature. But that’s me being a color management nerd.

They should just be careful about what units they use for config inputs. I found it’s easier to adjust raw “lumens” when dealing with plants/algae to dial it in. Even though you then want to interpolate along the gamma curve while dimming. Reef tanks I expect are similar.

Hmm, now I wonder about offering a setting to tweak color balance of a multi-channel light, and have it applied automatically for you to the lighting. I.e: you just ask for 50% and it figures out how much to skew the RGB channels to keep color temp close to what you want. Probably overkill, probably a pain to configure.

But maybe more valuable is being able to at least do a basic version of it. My local changes supports naming channels in the hw config file now that the schedule is its own file... maybe make it possible to merge multiple hw channels into a single software one. 


Sent from my iPhone using Tapatalk


----------



## Kaiede (Sep 11, 2017)

FYI, I'm about to deploy an updated build to my personal tank that does a few things:


 Updates to Swift 5.0.2, Raspbian Buster. This brings the environment up to date. This setup is supported by the Pi Zero, which is great news. I wasn't sure if 32-bit ARM would work with Swift 5 (it was looking pretty broken for a while).
 Splits the schedule and hardware configuration files. This will be needed for future updates.
 The PWM HAT I2C address can be specified in the configuration.
 Adds the ability to use multiple bits of hardware for LED output. So multiple PWM HATs (with separate addresses), or whatever you can make work without conflict.
 Channels are now named by the user in the hardware configuration, so schedules are now more hardware agnostic.
 Experimental support for MCP4725 boards for 0-10V analog output. (Kessil Control, Maybe?)

On a less user-facing note:

 Refactor of the LED output module. A lot of this was needed to better support the split configuration file, and the MCP4725 DAC output.
 Redid the JSON parsing code. It now uses the JSON decoder included in Swift 4 and later. One less dependency to build and track. Errors are a bit more specific, but also more confusing since I'm currently exposing the raw errors from the built-in decoder. I'll need to make these better as I start working on MQTT support.

I'll let this run for a couple weeks on my home aquarium and flushing out any bugs before I push it out, but it should be stable enough to release once that's done.

I want to see if I can implement one more feature before I mark it as "1.0" though: support for reloading the schedule.json file when the user makes changes without rebooting the service. Although maybe this isn't a huge deal compared to making people use 'sudo systemctl restart rpilight' if they are editing it by hand, if MQTT will render the feature moot? Especially since it looks like I don't need to worry about losing support for 32-bit in order to add MQTT anymore. I may just make this release the big "1.0". 

EDIT: Already found one bad bug introduced by the LED controller refactor and fixed it. Hmm, should write some tests around some of that code, I think.


----------



## Kaiede (Sep 11, 2017)

*Aug 12th Update:* Early test so far seems to be doing well. There's some work I need to do with the bootstrap script before it's ready, but it's getting close.


 Raspbian Buster shipped pulling packages from the 'testing' Debian Buster repo. It needs an 'apt-get update' before Swift 5's dependencies can get installed. So I need to update the instructions with that, or include it in the bootstrap script.
 Need to make sure Swift is in the PATH before calling the build script while bootstrapping. I've got a patch ready, just need to test it. 

But everything on the aquarium itself seems to be working fine.

*Aug 14th Update:* 1.0 is now out. It breaks Swift 3 and existing configuration files, be aware if you are running on 0.9.


----------



## Kaiede (Sep 11, 2017)

It's been a month, but I haven't been idle.

I'm in the middle of hooking up an MQTT library. I'm having to do some work building on top of the library, but that's coming along well. Once that's done, I'm going to start hooking stuff up for being able to read the state of the lighting over MQTT. Then will come the work to allow new state to be written.

Part of that will be writing a small iOS app that shows how to read/control the lights.


----------



## Jabolko (Jul 18, 2016)

Do you have any expirience with rPI and LC-LM358-PWM2V.
PWM turn voltage module 0%-100%PWM turn to 0v-10V voltage_chinalctech

I am trying to get 10V out of it but max is 9,12V. Also low PWM freq. is making it little unstable. Could be rPI PWM problem? I am using GPIO18.


----------



## Kaiede (Sep 11, 2017)

Jabolko said:


> Do you have any expirience with rPI and LC-LM358-PWM2V.
> 
> PWM turn voltage module 0%-100%PWM turn to 0v-10V voltage_chinalctech
> 
> ...



Not too familiar with that one. I have a couple I2C -> 0-10V chips I mean to test though. 

But it is possible to feed it the 1-3kHz it needs with the Pi. I drive my current setup in that range no issue. The problem is that the inputs expect 5V and the Pi uses 3.3V on the GPIO pins. I’m surprised it works at all.

I think I may have looked at boards similar to this months ago and wrote them off because they required 5V logic on the inputs.


Sent from my iPhone using Tapatalk


----------



## Jabolko (Jul 18, 2016)

Hmm yes.. could be PWM 3.3V problem. What I2C chip do you use in current setup?


----------



## Kaiede (Sep 11, 2017)

I’ve written a library to talk to the MCP4725 chip used in boards like this one: https://aptinex.com/product/aptinex-dac-module-da1c010bi-digital-to-analog-0-10v-mcp4725-i2c/

I still need to get around to testing the library with my Kessil though.


Sent from my iPhone using Tapatalk


----------



## jeffkrol (Jun 5, 2013)

Kaiede said:


> Not too familiar with that one. I have a couple I2C -> 0-10V chips I mean to test though.
> 
> But it is possible to feed it the 1-3kHz it needs with the Pi. I drive my current setup in that range no issue. The problem is that the inputs expect 5V and the Pi uses 3.3V on the GPIO pins. I’m surprised it works at all.
> 
> ...


AFAICT most take a variable range of PWM input..
Not unlike Meanwell drivers..


*



3.3P-5V 3.3V PWM Signal to 0-10V Voltage Converter D/A Digital-Analog PLC Module

Click to expand...

*


> 1. This module can convert 0-100% PWM digital signal into analog signal.
> 2. The input digital signal can be a 0-100% PWM signal of 3.3V level.
> 3. The output analog signal can be 0-10V voltage.
> 
> PWM Signal Receive Frequency Range: 100HZ-3KHZ (1-3KHZ is recommended)






eek bay thing so no link..
Just need to put a sticker on it.. 
https://www.amazon.com/KNACRO-Conversion-Digital-Industrial-Interface/dp/B079B9SWH2


----------



## Kaiede (Sep 11, 2017)

jeffkrol said:


> AFAICT most take a variable range of PWM input..
> Not unlike Meanwell drivers..


Not wrong, but they have to be designed for it. A lot of the super cheap boards here are using off the shelf budget ICs and keeping component counts down for price reasons. If they say you should feed it a minimum of 4.5V PWM, believe it.

3.3V logic to 5V logic tends to sit in the “undefined behavior” zone of most digital logic designs that use 5V. 



jeffkrol said:


> eek bay thing so no link..
> Just need to put a sticker on it..
> https://www.amazon.com/KNACRO-Conversion-Digital-Industrial-Interface/dp/B079B9SWH2



The Amazon version is similar, but I still wouldn’t expect it to be identical in behavior. It’s a gamble.


----------



## jeffkrol (Jun 5, 2013)

Kaiede said:


> Not wrong, but they have to be designed for it. A lot of the super cheap boards here are using off the shelf budget ICs and keeping component counts down for price reasons. If they say you should feed it a minimum of 4.5V PWM, believe it.
> 
> 3.3V logic to 5V logic tends to sit in the “undefined behavior” zone of most digital logic designs that use 5V.
> 
> ...



how about this one? Popular w/ the Reef Pi crowd..


https://www.tindie.com/products/ranthalion/pwm-converter-for-mars-aqua/


----------



## Kaiede (Sep 11, 2017)

*Latest Update (Nov 17, 2019):* 1.1 Released


 YAML Configuration File Support
 Daylight Savings Time Fixes (thanks rgmoorer, for reporting this)
 Updated to Swift 5.1.1

Swift 5.0.x is still supported. Swift 4.x _is not_. It made sense to try to get off Swift 4 while the getting was good, since it wasn't the greatest release on the Raspberry Pi. Swift 5 is much better, and opens up more libraries now that we've caught up with the official releases.

YAML support meant that I had to change the format of the config files slightly again. Using the new format, you can also use JSON if you really want, but if you are editing this by hand, YAML is much cleaner and faster to edit. 

----



jeffkrol said:


> how about this one? Popular w/ the Reef Pi crowd..
> 
> 
> https://www.tindie.com/products/ranthalion/pwm-converter-for-mars-aqua/


That should work fine, I think. Just needs to be fed the PWM output from RPiLight and it should do the right thing. 15$ isn't a bad price either. Maybe a little more wiring to be done by the person using it though.


----------



## Kaiede (Sep 11, 2017)

*Latest Release (Mar 25, 2020):* 1.1.1 (Link)

A Couple Important Maintainence Things

 Binary Packages Are Back
 Update to Swift 5.1.5 - Security Update

Starting with 1.1.1, Debian packages are back. These will install and run on a _clean_ Raspberry Pi. I've started using Apple's trick so that the Swift libraries I need get bundled with the service. Now it just depends on some bog-standard Raspbian libraries. And yes, it's possible to install these packages on top of a source-built copy and they will still work. 

The benefits here are: No having to build from source unless you _want_ to. Easier updates (just install the new package, your configuration will be preserved). And much faster to setup. Also, Swift now being bundled means I can focus on just supporting one version of Swift, and Swift patches will get rolled out to everyone.


----------



## jeffkrol (Jun 5, 2013)

Kaiede said:


> *Latest Release (Mar 25, 2020):* 1.1.1 (Link)
> 
> A Couple Important Maintainence Things
> 
> ...



YEA!!.. I guess.. 
Glad to see you are still moving ahead..


----------



## Kaiede (Sep 11, 2017)

jeffkrol said:


> YEA!!.. I guess..
> Glad to see you are still moving ahead..



As long as I keep using it for my tanks, I’ll at least maintain it. 

I hope that by going to binaries, I can be a little more free to make more drastic changes. Easier testing and all that.

I’m still (slowly) playing with MQTT libraries at the moment. Once I’ve settled on one it should be quick to add the remote control functionality. I am also trying to figure out where I put my 7425 boards so I can see if I can control Kessil lights...


Sent from my iPhone using Tapatalk


----------



## FischAutoTechGarten (Jul 11, 2003)

I'm doing a bit of work with a Raspberry Pi 4B (4GB version) running Raspbian Buster and Node-RED (against node.js ver 12).

Interfacing to the Atlas-Scientific EZO circuits over I2C for Temp (RTD), Flow (FLO) and pH (pH). Stuggling with some aspects of the generic i2c node available for Node-RED, like multi-byte commands, but I'll get there. For the time being, I can't ZERO the flow totalizer (so, I have a giant amount of liters gathered in it now), but the instantaneous l/min reading is working fine. I have two versions of this project going... A very basic one that will just be temp,pH and uses a Hat w/ built-in Relays triggered by the PI4's GPIO. And then a more ambitious one that uses many more input sensors over i2c, and a mess of I2C expansion boards for control and other inputs: (23008 Relay Board, 23008 Dig Input Board, PCA9685 PWM for Lighting and Wave Pump Control, PCF8591 A/D for Ultrasonic Level in the Water Prep).

If you know Node-RED, I posted the Flow here in a thread where a User was struggling with NodeRed and EZO I2C Sensors...
(you'll have to look under contributions from ODwyerPW in the thread for my stuff). 

https://discourse.nodered.org/t/pulling-readings-from-i2c-chip-into-node-red/19210/10

Anyway, I really like all the suggestions you are giving on hardware with the PI! Thanks for doing this thread!


----------



## AcidGambit (Aug 30, 2018)

I apologize if I missed it, but what is a good starting point or reference to look at for connecting this up to a Twinstar light? I currently have an in-line dimmer, but I've noticed that it sometimes changes settings. I'd also like to implement a ramp, but that's not possible with the Twinstar in-line dimmer.


----------



## jeffkrol (Jun 5, 2013)

AcidGambit said:


> I apologize if I missed it, but what is a good starting point or reference to look at for connecting this up to a Twinstar light? I currently have an in-line dimmer, but I've noticed that it sometimes changes settings. I'd also like to implement a ramp, but that's not possible with the Twinstar in-line dimmer.



A tc-420 or 421 is probably the same cost if starting from scratch w/ the pi..
https://www.tc420.net/


If not, all you need, basically is a digital high power mosfet switch circuit on the pi pwm output.
starlight: Dimming a 12V LED strip with a mosfet and PWM


----------



## Kaiede (Sep 11, 2017)

AcidGambit said:


> I apologize if I missed it, but what is a good starting point or reference to look at for connecting this up to a Twinstar light? I currently have an in-line dimmer, but I've noticed that it sometimes changes settings. I'd also like to implement a ramp, but that's not possible with the Twinstar in-line dimmer.


I should probably do a complete write up on my build at some point I guess, but here’s the rundown. 


Raspberry Pi
Mosfet Trigger Switch
Barrel Plugs

The trigger switches I used are along the lines of these:
https://www.amazon.com/High-Power-Trigger-Adjustment-Electronic-Brightness/dp/B07WTN72HF

These also look like they might work, but I haven’t used them. Their rating is a bit lower, so I’d prefer to use the above version when talking about the 900 or 1200 Twinstars, just so you aren’t pushing the limits of the specs.
https://www.amazon.com/Onyehn-Mosfet-Button-Arduino-Raspberry/dp/B07GLNCRR4

The barrel plugs need to match the Twinstar’s plugs, but they are fairly common: 2.5mm ID x 5.5mm OD DC power plugs. Just be careful of power rating on the cables if you plan on cutting and splicing an extension cable for this, since I’m seeing a couple cables available rated for 3A, but the higher end Twinstars are 4-5A. I used eBay to source some connectors for my build.

Just make sure the cables are *not* 2.1mm ID. Those are also common, and won’t fit. 

My build using a Pi Zero looked like this: https://www.plantedtank.net/forums/...light-controller-progress-4.html#post11106489

Plug it between the Twinstar’s power supply and the LED fixture, and then configure RPiLight and start the service. I’ve been running my 900E this way for well over a year now. I do get some coil whine from the Twinstar’s power supply because of the PWM though, but not much that can be done about that.


----------



## AcidGambit (Aug 30, 2018)

Thank you!


----------

