When properly set up solar panels can generate a lot of energy, especially due to the fact that energy tends to be cumulative such that in most setups the bottleneck tends to be energy storage rather than energy generation. This page will showcase a setup involving some very cost-effective solar panels, an MPPT controller and various other IoT devices that can be used to generate energy.

Hey, it's all about diversifying your energy portfolio!

Depending on the requirements, solar panels can be used to power devices in a self-sufficient manner, where it is possible to disconnect from the mainframe energy grid altogether. Similarly, another alternative is to use solar panels in conjunction with the energy grid in order to just buffer the energy costs and reduce them. The distinction between the two hinges upon the limitations of the environment where such a setup would be placed. That being said, due to our constrictions, we have opted for using solar as a buffer and not a self-standing solution, in order to just buffer up the energy yet still resort to the mainframe in case the energy consumption peaks over our current energy generation capbabilities.

The money will be distributed by not reducing the budget for vital systems, such as the solar panels, the solar panel controller or the inverter, yet low-cost IoT devices will be used to reduce the costs for tasks that can be accomplished trivially without needing industrial equipment.

For this setup, two monocrystaline solar panels have been chosen, each being rated at a maximum of . Typically, one should expect the energy generation from such solar panels to be far, far less yet it is important to remember that energy generation is cumulative such that even if the solar panels do not reach their peak production potential, the cumulative energy generated over time, even in non-perfect setups, tends to be sufficient in order to power a lot of low cost and low-consuming devices. It is, in fact, very rare to have such a perfect setup, and a perfect clear sky such that the solar panel would reach its max production potential.

solar panels are rather cheap and their flexible variant, for instance, the solar panels meant to be used with cars or RVs have an extra guarantee due to their flexibility of being more difficult to break.

For the ones that Wizardry and Steamworks has been using, the solar panels are rated at , typically above in order to ensure that voltage does not drop below , and have a peak output of . A perfect orientation for these panels is towards the south and at an angle of such that, in ideal circumstances, the sun rays fall perpendicular to the surface of the solar panel.

Similarly, solar panels can be wired together in series or parallel, depending on the requirements and the available hardware. Using Ohm's law, solar panels can be wired in series in order to increase the voltage output, or in parallel in order to increase the amperage. Unless there is a reason why a battery cannot be used and the voltage must be increased, it only makes sense to wire the solar panels up in parallel in order to increase the amperage and hence the energy production. It may be that in some setups the voltage must be doubled, setups when the hardware requires more voltage than the rated voltage of the solar panels, but it does not make much sense to double the voltage output when one really seeks to generate and store energy.

Here is what we found out using these flexible moncrystalline solar panels, using an imperfect setup where the angle of incidence of the sun is not perfectly adjusted to match , and the solar panels are crudely suspended:

• the solar panels are rated at a peak output of yet they typically reach peak production relative to the position of the sun,
• just two solar panels, tend to generate during the entire day, of power, cumulatively
• something typical of flexible monocrystalline solar panels is the fact that the solar panels tend to generate energy during the whole day regardless whether the sun is directly beaming onto them, allowing for energy to be generated even in low light conditions,
• it has been noted that just a full day tends to be sufficient to charge up a LiFePo4 battery to the brim such that, as mentioned earlier, the problem lies with energy storage (namely, when the battery is full, additional batteries, connected in parallel, would be required to store the energy surplus

And here are some empirical observations just watching the energy output of the solar panels during the day:

• the energy panels activate themselves at about 5am in the morning when the sky could be described as "dusk" rather than being sunny with the voltage peaking at in low light conditions,
• energy generation stats at about 6am with about being constantly generated
• for the rest of the day, energy generation ramps up and peaks at about 3-4pm (again, this is relative to the sun position) where until about 6pm there is a constant generation between to ,
• energy generation starts to ramp down at about 6 or 7pm (in summer) and the panels disconnect (voltage is zero) as late as 8pm

Initially, the ideal had been to use car batteries due to their availability, cheap costs and even guarantees. Given that car batteries are essential to the automotive industry, it seems trivial that they are easy to obtain, cheap and rugged enough to be used.

However, the problem with acid-lead batteries is that they are designed to be able to output a very high burst of amperage, during the car ignition, but typically a car battery is not designed to be able to sustain continuous drain. This seems fair given that, even though all the electronics within a car are powered by the battery, the car battery is, in fact, being continuously charged back by the car alternator. Car batteries are easy to damage irrevocably (such that they will never be able to be charged again) when they are discharged beyond of their capacity, and considering that fact, it seems even inefficient to rely on car batteries to be charged by solar panels.

Regrettably, the only alternative is to use LiFePo4 batteries that have no internal memory (they do not have to be discharged and recharged completely in order to use them) and thus can be discharged completely but the costs of LiFePo4 batteries is insanely higher by contrast to car batteries.

For our own use, we managed to procure a LiFePo4 battery rated at , yet even with an battery and just two solar panels rated at each, it seems that not all energy can be stored even during a single sunny day.

Battery charge tends to be estimated by measuring the output voltage of the battery. A quality battery will arrive with a manual that will contain a chart indicating the estimated battery level corresponding to the output voltage of the battery. Otherwise some general guidelines can be used, namely the offset from for a battery and anything lower than can be counted as the battery being completely depleted.

Measuring the battery voltage can be performed in many ways, for instance by using a resistor-based voltage divider and clamping to that is then fed to the analog input of an IoT micro-controller, by using a voltage sensor yet most of the time the battery will end up managed by the solar charger controller and the controller typically will provide measurements and estimates of the battery capacity.

For a solar panel setup, some solar panels, a battery and a controller is needed to complete the setup with the controller being the last piece of the puzzle that is responsible for mediating between the battery, the solar panel and the energy output.

Given raw electronics, it is perfectly viable to connect the solar panels directly to the battery, and the energy output could be drawn from the battery itself, without requiring a solar panel controller. However, a controller contains additionally safety measures and protections, a microprocessor that is capable of adjusting to the charging style required by the battery and also takes care to ensure constant current output without voltage variations on the output.

That being said, an EPEVER MPPT solar controller has been chosen that is rated (in amperes) above the rating of the solar panels and the controller has been wired to the LiFePo4 battery and the two solar panels in parallel.

One of the benefits of not reducing the budget for the vital equipment is that a quality controller such as the EPEVER MPPT controller additionally allows the user to monitor and configure the controller remotely without having to hack into the hardware as we have done previously in the past with many other types of hardware.

For the IoT part, we have gone the low-cost route instead of ordering a remote controller, by creating a wireless relay of data from the EPEVER MPPT charger to Node-Red. Using a WeMoS ESP, some Ethernet cable and a few other doohickies we've managed to push all the data to a Node-Red instance where the data is processed and depending on the data certain actions are taken. For instance, emergency-charging the battery in case the battery level drops too low.

Given common electronics knowledge, one of the showstoppers that greatly tend to cripple such a setup, is the conversion of voltage needed by various electronic devices. That being said, using green energy is not just a matter of generating energy using solar panels or wind turbines and then upscaling the output to whatever energy the various consuming devices require (ie: AC), but preferably also to change the devices themselves and swap them out for counterparts that are less consuming and, ideally, capable of being powered directly by the rated output of the controller.

For instance, typically an inverter, that is capable of converting direct current into (or ) alternative current such that devices that connect to the mains can be plugged in directly to the setup.

There are two problems regarding such inverters, aside the fact that scaling up DC to AC incurs massive losses:

• there is an ample supply on the market because they are typically used for cars to provide mains power to various devices that people might use but the quality of such inverters is really bad
  • they are noisy regarding and produce a lot of electromagnetic interference,
• they actually constantly drain the setup of energy, even when no device is plugged

As a solution, if one were to use an industrial inverter, such as Victron energy, Phoenix inverter, the inverter tends to include quality circuitry to ensure that no power is drained off the setup when no consumer is plugged in.

Similarly, such inverters have an "eco" mode, that is supposed to detect the energy drain on the output and only provide power in case there is something plugged in and ready to consume power. Unfortunately, this is not a perfect system, and in order to make the "eco" mode work, for instance, a Victron energy inverter will couple and decouple in order to check whether there is a given amount of drain on the output but in doing so, one can still expect a constant drain that is a penalty obtained just by plugging the inverter itself without any consumer.

In fact, one funny consequence that we have observed regarding the Victron energy Phoenix inverter is that in "eco" mode, the inverter requires a fairly high threshold for energy consumption in order to turn on, such that even if low-consuming alternative-current devices are plugged in, such as, for example, a light bulb, the inverter will not turn on because the consumption is below the threshold.

Otherwise, without the "eco" mode, it has been observed that a Victron energy inverter will even reach up to drain without anything being plugged in; that is, constant drain for absolutely nothing.

It becomes clear that scaling electricity up or down is not ideal and that ideally the devices should be swapped out for devices that have the capability of being powered directly by . There are plausible alternatives, for instance one could use a BeeLink mini-computer to replace devices that both consume a lot of energy as well as requiring mains power.

Cheaper in end user market price than a Raspberry Pi, a BeeLink mini-computer provides a 64-bit x86 platform that is capable of providing realistic computing power without paying for the extra requirements of inter-connectivity that a Raspberry Pi has. In our experience, a BeeLink at full load consumes between and while still being able to serve large websites such as this one given the correct optimizations.

Complex household devices such as PCs typically contain a power supply that is responsible for taking in the mains power and then breaking that mains power into a series of power lines that feed the computer such as , , and so on. One interesting alternative that can be considered posh compared to the BeeLink consists in situations such as the Apple Mac Mini M1 that has been found out to be able to be powered by directly.

Regardless of any other comments, it is important to remember that at every step of the power setup, whenever current has to be scaled either up or down, some penalty is incurred where losses are to be observed.

For instance, consider the following setup:

where is supplied by the solar panel controller, it is then upscaled to alternative current at great losses ( even without any consumer) and then the energy is fed into a PC that downscales the current to whatever the PC needs.

In such a situation, at every point on the power lines, any upscaling and downscaling will consume energy just for the sake of converting the current and not for any useful purposes. Even so, these devices are typically cheap and are made to work all the time without benefiting from an "eco" mode that would somehow sense a consumer and only then turn on. Even without upscalers or downscalers it is worth remembering that even a simple resistor that is under load, satisfies its function by radiating heat such that any device that is not in use, will still consume a certain amount of energy that might not be considered "residual" given the requirements. In minmax situations, ESP tinkerers sometimes even go as far as disabling the LEDs on very small micro-controllers and even if a small LED would incur a loss of it is still a loss that is there and serves no purpose - this, along with putting the ESP into deep sleep intermittently and only periodically waking up to perform whatever is needed to be done.

Using three separate BeeLink micro-computers mostly on full load (ie: the Wizardry and Steamworks website), an Ethernet HUB (at , regrettably), a passive inverter as well as some other IoT electronics such as the controller data logger itself and a few others, just two solar panels are able to generate enough electricity to run the system at a one-to-one ratio between energy production and energy consumption during summer. Overall, when everything is running properly, the consumption is roughly at or below in total. That is, we break even, we produce during the day and consume during both the day and the night, when no energy is being produced at all.

Even if impressive, the setup is not optimal, due to the battery not ending up charging, such that solutions would consist in adding another solar panel or charging the battery from the mains to compensate. Due to constrictions, we have opted for using a LiFePo4 charger that compensate for the gradual loss of power of the battery and during the night we charge up the battery just sufficiently. In that sense, the system is not a complete "off-grid" system, yet it reduces the energy consumption massively by combining both environmental energy generation and the energy grid mainframe as a backup.

The switching between charging the LiFePo4 battery from the mains and the energy generation via the solar panels is controlled via IoT by using Node-Red to centralize the data from the various sensors and then toggle the respective devices on or off.

In order to compensate for gradual losses, even when breaking even with the energy production vs. energy consumption a standard LiFePo4 charger is used to charge up the battery for a few hours during the night.

A straight charger was preferred, one that does not have any "advanced" features that would complicate the setup and was combined with a Sonoff basic IoT switch that we have used many times before for various automation projects in order to be able to turn the charger on or off depending on the data that is centralized by Node-Red.

It was chosen to not hack into the charger as well such that the Sonoff basic required just cutting off the power lead of the charger and then additionally connecting the grounding that was seemingly left out due to the Sonoff basic not passing through the grounding.

Calculating or estimating the capacity of the charger goes without saying and has been scaled to the Sonoff itself and the battery.

The required charging time for batteries can be calculated using the formula:

where:

• is the total charging time in hours,
• is the battery capacity in amperes-hour (),
• is the charging current in amperes ()

For example, for a battery charging at , the time required will be hours assuming that the battery is completely drained. One has to consider that the battery will hopefully never be fully discharged such that the charging time is purely empirical in this case.

At daybreak, the charger is completely disconnected via the Sonoff and the system is allowed to sustain itself by being powered by the battery and the solar panels for the whole day.

However, as it has been mentioned in the estimating battery charge section, there is no golden rule on how to approach switching between the mainframe and the green energy generation. Since we have all the data available and the system is centralized using Node-Red, it is entirely feasible to look up the battery specifications, to notice when the battery can be considered "empty" by measuring the output voltage of the battery and then starting to charge the battery based on that instead of using a day-night timer given that relying on the time of day would not compensate for rainy days or snow.

In practice, we run a typical homelab setup that has some of the most common components:

• virtualized servers (3 + 1),
• network storage / storage (1),
• a switch or hub, also with wireless (1),
• one other project (TBD)

The energy distribution obtained with the described setup can be observed from the following pie chart captured during a moderately sunny day.

It can be seen that our energy consumption () matches our energy production () and with compensatory charge that took place over the night in order to fully charge the battery. Given the amount of hardware that is powered, the result is rather impressive and shows that we manage to cut server costs in half by using solar as an energy source. Furthermore, as discussed in the previous sections, the energy footprint is also further minimized by using well-chosen hardware with low power consumption and some operating system level optimizations that are not even driven to the extreme (ie: ripping out fans and using passive copper heatsinks instead).