diy solar

diy solar

RF and the Smart Solar Home

Don't know what I'm doing yet, but the UI is just XML so no big deal. Your trading app does look slick!

There's an app for that and what I did in my test was a call to a restful API.
SWEET! You are well on your way. HTML became XHTML, which makes it XML... sorta. lol XML is a common framework for building UIs, even when it's not HTML (e.g., Coldfusion).

RESTful is the way to go. Web Sockets for real-time streaming. But, worry about that later. You need to learn how to create and consume REST web services first. :) If you just learn how to create UI that consumes them, it opens a huge world, as nearly all major API providers expose their interfaces with REST (e.g., Amazon, Google, Twitter, Facebook).
 
I've temporarily ruled out open source. Figured I needed to do things the hard way to learn enough to know if one of the open source packages made sense or not. So... in thinking out loud...

Definition of Automation: When this do that

Do That
The do that part seems pretty easy so let's tackle that first. Every device has a set of actions, e.g., fan1 off, fan2 speed1; where the devices are fan1 and fan2, and the actions are off, speed1. Every RF device needs a transmitter to send the action to the device, but we'll call the transmitters controllers since these probably won't all be transmitters. So, that can easily be setup in json like structure as:
Code:
[{name, controller, actions: [{name, data}]}]
That is a list of devices, each of which have a unique name, a controller, and a set of actions and their associated data. For example fan1 and hotWaterTankmight look like:
Code:
[...
{name:fan1, controller: bond, actions: [
   {name: off,    freq: 303.85, bps:1000, bits: 0001100001211, repetition: 5},
   {name: speed1, freq: 303.85, bps:1000, bits: 0001100001310, repetition: 5}, ...]},
{name: hotWaterTank, controller: aeotec, actions: [
   {name: off, ip: 192.168.0.44, body: off},
   {name: on, ip: 192.168.0.44, body: on}],...]
The action parameters would be unique to the controller, and what the controller needs to perform the action.

When This
While polling isn't great, it's probably the most universally guaranteed way to get the state of something. For what we're doing the controllers for this are probably things like:

Code:
[
{device: envoy, actions: [gridActive, BatteryPower]},
{device: weather, actions: [solarRadiance, temperature, humidity]},
{device: clock, actions: [time]}]

You don't want to preserve state as humans can (and will) change state. You also can't get state for a lot of devices (e.g., fans). What we want is to be able to do things like:
  • when envoy gridActive *true hotWaterTank on
  • when clock time ~22:30 fan1, fan2 off
  • when envoy gridActive false && weather solarRadiance < 700 hotWaterTank off else hotWaterTank on
The first one has a problem because most times you poll envoy for the grid state it's going to come back active, which means you'd be sending a lot of ON commands. It's also dangerous... if it was a WiFi circuit breaker and you flipped it off manually to replace the element...imagine your surprise when automation turns it on again.

It seems like physical devices will need some sort of virtual representation. For example, what we really want on the Envoy is to know the one time when the grid goes from inactive to active. Since we're polling, we can use the poll time to determine new occurrences from old occurrences, and then only take action on new occurrences when desired. So, for example, the envoy.gridActive would only return true if the grid was active and has only been active for less then the polling cycle. But that's not always desirable, for example the gridActive false should always return false in the example above. So, how to tell the difference? I used the asterisk (*) in the examples above to indicate first occurrence only. Similarly, on clock time, there's a tilde (~) to indicate a +/- time around the polling cycle since it would be rare the polling occurred at exactly the matching time.

So the BNF is:
Code:
<when>      ::= <condition> [ &&,|| <condition>]  device [, device] action
<condition> ::=  [device] [action] [~ | *] [test]
<test>      ::= [< | > | <= | >= ] <value>
<value>     ::= <number> | <string> | true | false

The decision making code can't be unique to the controller, as it would preclude the ability to have multiple conditions from different controllers. So, the json structure for these rules might look something like:
Code:
[{name, <condition>, [devices], action}]
where <condition> would be a recursive object:
Code:
{ device, message,  testOperator, testValue, conditionOperator, <condition>}
So, that's a start anyway....
 
Last edited:
I've temporarily ruled out open source. Figured I needed to do things the hard way to learn enough to know if one of the open source packages made sense or not. So... in thinking out loud...

Definition of Automation: When this do that

Do That
The do that part seems pretty easy so let's tackle that first. Every device has a set of actions, e.g., fan1 off, fan2 speed1; where the devices are fan1 and fan2, and the actions are off, speed1. Every RF device needs a transmitter to send the action to the device, but we'll call the transmitters controllers since these probably won't all be transmitters. So, that can easily be setup in json like structure as:
Code:
[{name, controller, actions: [{name, data}]}]
That is a list of devices, each of which have a unique name, a controller, and a set of actions and their associated data. For example fan1 and hotWaterTankmight look like:
Code:
[...
{name:fan1, controller: bond, actions: [
   {name: off,    freq: 303.85, bps:1000, bits: 0001100001211, repetition: 5},
   {name: speed1, freq: 303.85, bps:1000, bits: 0001100001310, repetition: 5}, ...]},
{name: hotWaterTank, controller: aeotec, actions: [
   {name: off, ip: 192.168.0.44, body: off},
   {name: on, ip: 192.168.0.44, body: on}],...]
The action parameters would be unique to the controller, and what the controller needs to perform the action.

When This
While polling isn't great, it's probably the most universally guaranteed way to get the state of something. For what we're doing the controllers for this are probably things like:

Code:
[
{device: envoy, actions: [gridActive, BatteryPower]},
{device: weather, actions: [solarRadiance, temperature, humidity]},
{device: clock, actions: [time]}]

You don't want to preserve state as humans can (and will) change state. You also can't get state for a lot of devices (e.g., fans). What we want is to be able to do things like:
  • when envoy gridActive *true hotWaterTank on
  • when clock time ~22:30 fan1, fan2 off
  • when envoy gridActive false && weather solarRadiance < 700 hotWaterTank off else hotWaterTank on
The first one has a problem because most times you poll envoy for the grid state it's going to come back active, which means you'd be sending a lot of ON commands. It's also dangerous... if it was a WiFi circuit breaker and you flipped it off manually to replace the element...imagine your surprise when automation turns it on again.

It seems like physical devices will need some sort of virtual representation. For example, what we really want on the Envoy is to know the one time when the grid goes from inactive to active. Since we're polling, we can use the poll time to determine new occurrences from old occurrences, and then only take action on new occurrences when desired. So, for example, the envoy.gridActive would only return true if the grid was active and has only been active for less then the polling cycle. But that's not always desirable, for example the gridActive false should always return false in the example above. So, how to tell the difference? I used the asterisk (*) in the examples above to indicate first occurrence only. Similarly, on clock time, there's a tilde (~) to indicate a +/- time around the polling cycle since it would be rare the polling occurred at exactly the matching time.

So the BNF is:
Code:
<when>      ::= <condition> [ &&,|| <condition>]  device [, device] action
<condition> ::=  [device] [action] [~ | *] [test]
<test>      ::= [< | > | <= | >= ] <value>
<value>     ::= <number> | <string> | true | false

So, that's a start anyway....
You're well on your way to being a web developer because JSON is the standard data format there. That's part of the reason I like the Node/Angular stack. There's no need to do heavy marshalling (converting) in Javascript/Typescript (JS/TS) like we had to do in XML for years. It just becomes native objects when you receive it, and you can generate it from native objects on the fly, to send on a REST call, for instance.

I can still handle XML when it comes from a third party. But, I no longer use it internally in my systems when I can use JSON. I even persist JSON in the database.

The commands in JS/TS to convert between a string (needed for REST and DB) and an object graph are:

<string> = JSON.stringify(<object>)
<object> = JSON.parse(<string>)

A lot of the time even those conversions are done for you under the hood by frameworks.

Typescript is a superset of Javascript, and it's improvements end up becoming rolled into new versions of Javascript (aka ECMAScript or ES). It's core focus has been introducing typing to Javascript. What you are doing right now is defining types. So, if you used Typescript, you'd be using that to define your data structures.
 
Last edited:
...You're well on your way to being a web developer...the commands in JS/TS to convert...
Wouldn't want to be one! The pay sucks! The average Indian web developer is 3x faster/better than I'll ever be; but makes < $4k U.S./yr

But don't worry, coding just hasn't ever been a big challenge for me. For example, wrote a JSON parser in Features for the Perfect Monitoring Software for a Residential System just so I could have a teeny-tiny version that would be right-sized for the MCU's limited space (that and it was fun). Not worried that it'll be 20x slower than Jackson, won't ever be processing that much of it to notice the time difference.
 
So, looks like we have a good start on understanding the brain...but I'm loath to explore that more until a transmitter and protocol are locked down.

The transmitter hub you make or buy needs to handle the remote devices that you have. All the hubs handle at least one protocol, a fair number handle both ZWave and Zigbee (e.g., SmartThings, Hubitat), and the Homey handles: ZWave, Zigbee, and RF (although not the 303.85 MHz I need).

The Bond Bridge supports all the usual frequencies (300-321.5 MHz, 336-365 MHz, 365-399.5 MHz, 410.5-450 MHz, 902.5-927.502 MHz,2.402-2.48 GHz (Bluetooth), 2.412-2.462 GHz (2.4 GHz WiFi, ZigBee)) except ZWave (868.42 MHz); but it doesn't (yet) support any of the protocols beyond OOK.

Similarly, in the protocols of interest, the CC110L only supports OOK and you can't program a protocol onto it.

Other than OOK @ 303.85 MHz, WiFi handles all of my needs except for the two most important elements, 240V/40 amp switches for the hot water tank & eCar. The COTs solutions are all pricey or don't use WiFi:
  • $95 40 Amp aeotec is Z-Wave
  • $140 30 Amp 240V WiFi Wall switch? Also comes in Z-Wave and Zigbee Flavors
  • $50 Insteon X10/RF (915 MHz), downside is you’d need an insteon hub ($80)
  • $74 WiFi Smart breaker, needs a $300 Wiser Large Load Controller
How hard can it be to build one? Let's see:
$16 240V / 40 amp Contactor (inexpensive as they’re mass produced for Air conditioners and pool pumps)​
$12 project box ... anyone know of a better project box? Preferably DIN?​
===​
$31​

Anyone see a problem with that? It probably would be handy to have a contactor with A1/2 so I could change my mind later if I wanted NO vs NC.
 
Brain only OOK?

Previously we discussed a low-speed brain (16 Mhz) turning on/off an external oscillator to generate an RF OOK signal.

If the brains of the system is on a fast processor (e.g., 1.2 GHz Rpi), why can't we turn the brain into an RF transmitter by turning one of the pins +5v on/off at the desired frequency and a piece of wire (whose length is suitable for the frequency) attached to that pin? For example, if the desired frequency is 303.85 MHz that that's 303,850,000 waves per second. To produce a square wave at that frequency we'd need to cycle the pin on/off for half that amount time, or change the state every 1.64ns. Crunching the numbers , a GHz clock speed is only 1 instruction per ns which really isn't enough. The Rpi at 1.2 GHz at .833/ns which might work at short bursts for that frequency. Beyond that it get's more reasonable. So, if your brain just happens to be super fast and under utilized, this might be a cheap/easy way to go.

Update: It's been done: How to turn a Raspberry Pi into an FM radio Transmitter
 
Last edited:
The article Ampster posted about assigning value to power consumption got me to thinking of a way we could up our game a notch.

Recap
For those new to the thread, it's about how to use the renewable energy intelligently rather than a critical loads panel. The basis is software looking for when your off-grid, knowing when there's more solar than you can use, and then remotely flipping a switch to turn on/off power to devices. For example, with Enphase if the grid is down and the AC frequency is shifted we know fairly accurately how much power is being thrown away, that's power we can use by turning on devices you might otherwise have off to conserve battery (e.g., hot water heating, EV charging). It's an off-shoot of Smart Panels & Sockets.

Value Assignments
Previously we had a pecking order, for example first the hot water heater, then the EV, and so on based on personal preference. But with a value assignment, precedence could be set by logic. For example the formula's might be:
  • Hot Water = 10 + (140-T) : as the tank gets cooler the desire to turn it on becomes higher
  • EV = 10 + (Range - 20) : Once the car has a range of 20 miles, it's not as important to charge
Of course, that implies the software can communicate with a car to get range or can estimate the hot water tank temperature by knowing how long it's been without power.
 
I'd bet the hardest part of that proposal would be getting the information from the EV. But I may be wrong. It could be as simple as plugging in a Bluetooth adapter into the ODB2 port assuming EV's will continue to have them.
 
I'd bet the hardest part of that proposal would be getting the information from the EV. But I may be wrong.

Probably spot on... depends on the EV. For example, Tesla has an API. I can see the SoC for our Honda EV on my cell phone, so there's some API for the EV (never looked into it though, probably proprietary).

The North American standard (not Tesla) uses J1772. The current standard for it doesn't have a SoC for the charger, but that would have to change for some upcoming tech (e.g., V2H, V2G, VPP). .

@svetz @erik.calco I’d be interested to see this conversation, focused around the last post above, updated as surely a lot of new tech has become available in the last year.
Haven't really done much yet, possibly this winter on those cold bitter days when it gets into the low 60s? Haven't had to use it, but the current plan is to control stuff by flipping breakers and watching foghorn.

Possibly the Emporia smart charger might have something?
 
@svetz @erik.calco I’d be interested to see this conversation, focused around the last post above, updated as surely a lot of new tech has become available in the last year.
I finally bought a soldering iron recently. :LOL: As for my light bulbs, I did rewrite that app using NativeScript with Vue earlier this year, primarily so I could get to know bluetooth. I'll use that as a starting point for any mobile bluetooth app, which has become very common in IoTs. I put the source code online if you want it.

In Solar, I just haven't had much maintenance as it just runs. When I see a lot of cloudy days in the forecast, I'll enable nightly charging from grid. Otherwise, during sunny days I keep that at 2A for 1 hour just so it is easy to change later. When I'm at home, I VNC into the laptop running the solar software, so can do this from my couch.

I'm also home a lot. It is really when I'm not home that I need smarter responses to grid down to preserve battery life. Without intervention, things will drain my battery really fast running on full load. So, there is still a use-case for this.

I continue to develop apps unrelated to solar, as I've done all my life, and improve my skills there. I recommend Vue 3 for front-ends. Quasar.dev is also a nice UI framework. For backends, Java or Node.

Now that I have a new soldering iron, though, I can begin to explore electronics and play more with IoTs. IoTs continues to grow, with no end in sight. It's a good field to be in. Even in my professional life, I've done things like create an MQTT server, which is popular for IoT message collecting, and integrated LIDAR. Thus, indirectly improving skills to one day build Solar automation.

I did use my new soldering iron for XT-60 connectors :LOL: . This is cuz I recently got a Bluetti to use my extra solar panels, and wanted to run the 25A output to a DC fuse box so I can have endless options. Right now I'm outside using my "outdoor solar office" powered by the Bluetti with a 43" TV.

I love solar.
 
Last edited:
@svetz did you discover, yet, that you can make over 160k developing software? :LOL: How are your projects coming along?
 
My solar projects have all been sidetracked by other projects. But, all it will take is a hurricane and a day without power for them to become important again... ; -)

did you discover, yet, that you can make over 160k developing software?
What? People pay for that? I keep giving away stuff for free ; -)
 
Last edited:
But honestly, how hard can it be? This isn’t AM/FM. This is On-off keying (OOK)

I made a device similar to what you are looking for using an ATtiny85 microcontroller and a cheap 433 Mhz transmitter modified to transmit at 315 Mhz. The ATtiny85 chip is actually a Digispark usb module and getting the 433 Mhz transmitter to operate at 315 Mhz was a simple matter of changing the SAW resonator. My device is installed in the headlamp of my motorcycle so that when I flash my brights the gate at my development opens and I don't have to fiddle with a remote.

The controller is OOK like your fan and the software to duplicate it is a simple matter. The ATtiny simply turns the transmitter ON and OFF at the desired timing.

If you use the ATtiny or any other AVR device you can use the Arduino IDE to write and compile your software. Total cost probably less than $10.00.
 
Back
Top