RF and the Smart Solar Home

[svetz]

Synopsis
This thread is a journey starting with how to remotely control a humble ceiling fan, but will hopefully grow over time to figure out how to run the hot water heater and charge the eCar when the grid is down automatically using only excess solar power (i.e., only turns some things on when there's excess power available).

Premise
The quest to resolve Light Switch Replacements hasn't been fruitful as I couldn't find a Smart Things type 3 speed fan and light switch that would replace my existing one (one possibly $$ exception). As I was putzing around with the monitoring software to read an Itron RF utility meter via the rtl_sdr it dawned on me the fan controller used RF. ding ding ding!

Technology
Could I use the RTL-SDR dongle to record and playback the RF signals, thereby controlling fans from the computer? Could this be taken farther to control Z wave devices? More stuff to play with in the ultimate quest for the smart solar house. As it turns out the RTL_SDR dongle I have is a receiver and while it does transmit...it's more by accident via leakage so has a very short range.

So hardware ... what's needed for remote control is a transmitter and a controller. There are some commercially available and they use a variety of technologies. From the Smart Solar/Battery thread we have:

• X-10 - uses the house's wiring to send signals. Might have issues as Enphase changes the frequency or interference with powerline communications to inverters. No acknowledgements.
• Z-Wave - 908.42 MHz radio frequency (U.S.), mesh network, doesn't interfere with WiFi
• Zigbee - 2.4 GHz meshed, could interfere with bluetooth and WiFi
• LoRa - Low power and long range
• Bluetooth - poor range
• WiFi - increasing devices decreases overall throughput

The SmartHome market has a dizzying array of inexpensive devices from plugs and switches, to more costly 40 Amp switches for turning your water heater on or off. WiFi Circuit breakers would be ideal, but AFAIK those aren't available yet to retrofit old load centers (but you can get them for din-mounted sub panels).

Commercial and opensource options are: SmartThings hub, Alexa, Hubitat, OpenHub, a Z stick, Home.Assistant running on an Rpi, or even software running on a pc and controlling wifi devices.

Fan Update: Most fans are pretty easy to handle with standard devices. Who knew this first step would be so hard? The problem with Hampton Bay fans like I have operate at a frequency (303.85 MHz) you can't easily purchase an RF development board or ready to go SmartHome devices for it. There are chips, but haven't seen a 304 MHz SAW. The Bond seems to be the best off-the-shelf solution, it's like a self-learning remote, but it also has an API that let's you control the radio for OOK. So, the devil is in the details, but if this can be conquered DIY fashion anything should be possible.

Acknowledgements: Many of the ideas and links are ideas/input from other enthusiasts from other threads including: tictag, jwu_cc, Steve_S, tim0shel, sunloverjt, and everyone else that has posted about home automation, thank you!

 

[svetz]

I believe a lot of RF controllers are at 433 MHz... so this 433 MHz RF Transmitter and Receiver Link kit might interest Ardruino hobbyists.
Example arduino project. Example NodeMcu project

 

[svetz]

Starting with google I found the typical RF fan controller frequencies: 315 & 433
With SDRSharp I found the exact Frequency 303.85 MHz (this is common to Hampton Bay fans)
With Signal Safari and rtl_433 I found the transmit codes.

That was all really easy!

Now here's the rub... It's 304 MHz and while I see cheap 315 MHz transmitters; I'm not finding them for 304 MHz. Wonder if it's as simple as replacing the oscillator?

 

[Steve_S]

It's really great you started this thread, I think there is a good call for this subject matter, now linking Advanced Home Automation to Solar / Renewable Energy generation and your completely Golden ;-) context of the forum being DIY Solar.... hehehe.

You know what, I think your travelling on a pre-trodden path here. I gave you a link to Andreas Speiss on YouTube, he covers a LOT of different things and Home Automation is one of his biggies and he's playing with all sorts of things. Now if you look at who he subscribes to and such, you will discover a Huge Treasure Trove of people doing similar things. OKAY, He's Swiss and European Focused but still a large art of what he covers can apply here in North America as well. Especially the home automation bits. Peter Scargill and Andreas share a lot of stuff as well as doing their own thing and Peter is another Treasure in his own right, as well as other connected to Andreas channel.

Link to Andreas Spiess Playlists for the curious souls.

Andreas Spiess

Small electronic projects , tutorials, and reviews for sensors, ESP8266, Arduino, Raspberry Pi, and ESP32

www.youtube.com

Link to Peter Scargill's YouTube Channel.

Peter Scargill

This channel, in the main, is about home automation and general tech reviews - but I am generally interested in computing and electronics (gadgets) so you ma...

www.youtube.com

And Peters Tech Blog here: https://tech.scargill.net.

If searching for things on Google and coming up short ?
Try DuckDuckGo search engine, it's awesome ! https://duckduckgo.com/

 

[svetz]

TI's CC110L transceiver chip is only ~$3, interestingly it supports frequency Bands: 300–348 MHz, 387–464 MHz, and 779–928 MHz. So, it covers not only the typical RF remote control frequency range...but also Itron's RF meter (918 MHz). Not sure if any h/w switching needs to occur for frequency changes.

ST's spirit1 is even cheaper at $2.86 and covers the same range, and they have an UNO ready board but its at a bad preset frequency.

I also found an article on altering the frequency of a 433 MHz module and was thinking it might be possible to purchase a remote for the fans and then reuse/scavenge it as the base for the transmitter.

Update:
Found two additional chips that support OOK: Silicon Lab's Si4055 (284~960 MHz) and Maxim's MAX41461GUB+ (286MHz ~ 960MHz).
Also found the SCU EFR32MG12 which supports bluetooth, ZWave, and OOK at MHz ranges: 110-574, 584-717, 779-956, 2400-1483.5

 

[svetz]

Don't have one, but according to the Amazon Q&A the bond bridge supports 303.2 MHz

According to this, the Bond V2 now has an even a lower frequency range: 285.5 - 505.5 MHz, versus 300 - 450 MHz on Snowbird (V1?); so either should work.

The V2 supports a local API:

The Local API is made possible by V2 firmware, which is already on ZZ units, and soon to be available publicly for serials starting A/B. Docs here: docs-local.appbond.com

If you're 433 MHz, Sonoff has a $12 transmitter.

Broadlink is also a $40 IR and 433 MHz RF bridge.

Banggood has the CC1101 chip (above) on a 868MHz RF module for $21 for 5 and a $7 433 MHz module.

 

[svetz]

You can find ready to go transmitters like the Yard-1 for $100 that work in the 300-348MHz, 391-464MHz, and 782-928MHz frequencies, ideal for most RF operations.

But honestly, how hard can it be? This isn’t AM/FM. This is On-off keying (OOK). Could you use an Arduino to turn on/off power to a coil/capacitor set to oscillate at 303 MHz? Hartley, Colpitts, or a 7417? What about a Voltage Controlled Oscillator like the $25 CVC055CL? Or, as mentioned earlier, the $3 CC110L transceiver chip (there’s an UNO lib for it! And, it’s been done before, see ref).

The $14 Uno has a clock speed of 16 MHz, can it be used to transmit the RF pulses needed to mimic the fan controller? 16 MHz is 16 million instructions per second, so turning something on/off in the microsecond range should be possible. How long is each OOK pulse?

RTL_433 gives me:

*** signal_start = 15602894, signal_end = 15667294, signal_len = 64400, pulses_found = 104
Iteration 1. t: 120    min: 79 (67)    max: 162 (37)    delta 20
Iteration 2. t: 120    min: 79 (67)    max: 162 (37)    delta 0
Pulse coding: Short pulse length 79 - Long pulse length 162

Short distance: 84, long distance: 166, packet distance: 2878

p_limit: 120
bitbuffer:: Number of rows: 8
[00] {13} 78 40     : 01111000 01000
[01] {13} 78 40     : 01111000 01000
[02] {13} 78 40     : 01111000 01000
[03] {13} 78 40     : 01111000 01000
[04] {13} 78 40     : 01111000 01000
[05] {13} 78 00     : 01111000 00000
[06] {13} 78 00     : 01111000 00000
[07] {13} 78 00     : 01111000 00000

Some of that makes sense, 8 rows of 13 bytes = 104 pulses. We know a short pulse is 84 and a long is 166, the packet distance 2878 and the signal length is 64400 … but what are the units?

For one row Audigy reveals a ~1ms timespan for digits that is a 0 (short pulse, .3ms) or a long pulse(.63 ms) or 1.00 ms. The 13 bits take 13ms to send:

​

So, a 16 MHz processor should be able to turn a transmitter on/off fast enough to generate pulses. While it would work with a home-made oscillator, in looking at the CC110L datasheet it has OOK support, so the digits could probably just be sent via the serial interface....much simpler!

For optimum operation, the antenna length must be related to the wavelength (λ) of the signal. Common antenna sizes are one-quarter (λ/4) and one-half (λ/2) wavelength at the operating frequency. The higher the frequency, the shorter the wavelength and thus the smaller the antenna.

So, for 303.85 MHz, λ x f = c; so if the frequency is 300 MHz, then the wavelength must be Wavelength 0.98664623m. or at ¼ wavelength 247mm (9.7“)

For $20, you could get this (see right image) But suspect it would need some modification to work at 303.85 MHz. I’ll have to read the TI guide next…. Update: Same thing for $6? $5 on ebay Arduino pinout For $6 TI has an MCUTx/Rx version

From the CC110L datasheet, it supports 3 selectable frequency bands: 300–348 MHz, 387–464 MHz, and 779–928 MHz. A 26 MHz crystal is for bands under 869 MHz and a 27 MHz for bands above 869. The base frequency is set by setting 3 registers (internally that sets the VCO) which becomes the center of the lowest channel frequency to be used. With a 26 MHz crystal the maximum channel spacing is 405 kHz and the channel is set with another 8 bit register. The carrier frequency is:



It's all temperature sensitive, but they have a self-calibration built it and recommended it be set to automatic.

 

[svetz]

Yardstick & Bond, Bridge Bond

In lieu of building a transmitter, how about buying an RF hub? There don't seem to be a lot around in that frequency range. From above we know the $100 Bond bridge has the right frequencies. Turns out the API also supports an RF transmit function. That's pretty exciting as it allows you to transmit any OOK message via a restful API. YouTube has several videos on the product (none on the API AFAIK).

Next up the RF transmitters is the $100 yardstick one, it's a USB wireless transceiver that has the correct frequencies. It's similar to an SDR, but not and uses the TI CC1111 discussed above. It doesn’t send the I/Q samples to the host over USB (it's a restriction of the TI CC1111), only decoded data - so no raw data. Instead of using SDR tools, you'd use python or RfCat to set the frequency and transmit data. If you're a windows user there are a few hurdles to overcome to install RfCat from Linux coders although a binary is available. (video)

For a full SDR system, there's the $340 SDR compatible HackRF One. Might be some transmitters elsewhere in there. I'll update this if I come across any.

 

[svetz]

If Only I had a Brain

At some point we’re going to need a brain to control things and it's worth some thinking now as the brain might influence other decisions. The brain's "role" would be to query the solar components to find out how much power was available and then tell the RF Transmitter (Bond Bridge?) to transmit a code on an RF frequency/protocol that would turn the devices (e.g., water heater, eCar) on/off.

The brain needs enough CPU/RAM...but what else does it need? The grid is down so we'd want low power. Internet might be down, so it should process locally. If the RF is built into it then range is important unless it's a meshed protocol (e.g., ZWave). Let's look at what's out there and idle power states:

• Propeller .02W (100 MHz)
• Stamp board < 0.04W
• Seeed - .07 watts
• Celllphone .1 W
• NodeMCU D1Mini .185W
• Arduino (Uno .3W, nano .1W) [less if you remove the LEDs]
• Compute Stick (linux) 2.6 W
• Teensy - .33W at 600 Hz
• Raspbery Pi Pico 0.33 W
• Raspbery Pi 3.4W
• SmartThings 10 watts, 50-130’, zigbee, Z-wave, but may not work if internet down
• Hubitat - 10W, Zigbee, Z-Wave, local
• PC 50 W

Running it off a PC is easiest, but also takes the most power. Hubs like the Hubitat seem to fit into intermediate power use.

I particularly like the idea of reusing an old Android cellphone as I have some old ones laying about, there's a lot of support for writing Android apps, and with the radios/screen off they use very little power. If would have to be an old phone though, using your current phone means the system wouldn't work if you traveled.

 

[svetz]

My brain could be on Fire

I got to thinking about the android cellphone as the h/w for a DIY smart home hub in the previous post and it occurred to me that plugged into my TV was the $39 Amazon Fire Stick. It consumes 2 watts idle, has a quad core 1.3 GHz CPU, 8 Gb RAM, bluetooth, WiFi, and ADB all built in. There's also a lot of information that Amazon provides for people to build apps for it. In fact, it might be cool to see and manage your Solar Smart Home from the TV. Surely someone has built a wifi smart home app for it, right? Not one? Really?

Just because no one has done it (or that I found) doesn't mean it won't work. Could it run in the background without messing up TV viewing? If anything, this is probably why it's not been done. Well, since google has let me down there's only one way to find out.

I installed Android Studio, borrowed some code from Features for the Perfect Monitoring Software for a Residential System, and after a day of learning to use the tools, commenting out sections, and getting rid of lambda expressions (uses an older version of Java) had a little program that accessed the envoy api using a TV simulator... so next up is to see if I can get it working on the actual hardware as a background program and what it does to TV performance. Even if it does affect TV performance, still cheaper than a PI, wonder if can work not hooked up to a TV?

 

[offgriddle]

Whole Home | Control4 Smart Home Systems

What is a smart home? It’s a home automation system that makes all the devices in your home work together. Learn about Control4’s smart home products.

www.control4.com

 

[erik.calco]

I went crazy on X10 20 years ago. Lights, appliances, security, computer integration. You name it. I probably have 10 remotes. It has been my dream since I was a kid to build a smart home. None of this Google or Alexa cloud crap. Those are dumb homes, analogous to dumb terminals in the 80s. The intelligence should be IN the home.

When I bought my house, it never left the boxes. I loved it. But, was just a lot of maintenance. Times are changing now. I have LED light bulbs I control with my phone via bluetooth. Issues with X10 included quality (things quit working), changing batteries (mostly on security devices), and socket A not being able to talk to socket B in the house (possibly on different phase).

That said, when I'm done with my core solar install, the next phase is automation and intelligence. I'm looking into PLC for controlling and sensing. I'll also be looking into lots of other things. For instance, there is a $3 microchip that includes USB for power and built-in wifi that can do insane things for IoT. One guy uses it for solar. He's also into automation and is using open source to control it and put in if-this-then-that logic.

I don't have much on this web page yet, but that's where I'll be adding links and videos.

 

[svetz]

I'm really not into the whole home automation thing (other than the pet peeve of automatically turning off the fans); I just don't want to be a slave to the PV system when the grid goes down. My goal is turning on/off the water heater & eCar based on if there's surplus solar power; anything else (e.g., fans) is just a bonus or something I did to investigate the technology.

Also found a fire TV app, so it has been done before!

 

[erik.calco]

I'm really not into the whole home automation thing (other than the pet peeve of automatically turning off the fans); I just don't want to be a slave to the PV system when the grid goes down. My goal is turning on/off the water heater & eCar based on if there's surplus solar power; anything else (e.g., fans) is just a bonus or something I did to investigate the technology.

Also found a fire TV app, so it has been done before!

That's exactly my goal with PV automation. Those of us with grid are balancing two competing goals. Maximizing PV utilization and having UPS for when grid is down. When grid is down, we than want to go into critical load conservation. And that may be in multiple stages. For instance, since most grid-down instances are under an hour, perhaps we want some normalcy for the first hour IF our batteries are full.

As for mobile apps, my bluetooth light bulbs that only cost $15 each but solved a host of problems came with an Android and iPhone app. I only have Android. When they quit releasing their Android app, I had to use another app to get the APK off one phone to install on another. Then that app blew up every time it tried to sync to the lights on all my phones. I might get lucky and dim a light after 5-10 minutes of trying. A light I have on a physical timer has to be dimmed every night because they start at 100% when power comes on.

Then I found a Cordova app on Github, which is a mobile development platform that included my light brand among many. In this case, I now had the source code and compiled it. And it works great. I have it on all my phones now. But, the important lesson here is I won't depend on an app I can't change and compile. And, likewise, I won't buy hardware that I can't control with an app I have the source code for anymore.

There are countless stories of vendors withdrawing support for products. The cloud dependency ones are the worst. My Yamaha receiver came with internet radio built in. Worked great for 10 years. Then, the company hosting the server for it quit supporting it for free, and wanted an annual payment. Many of these services go dark, even from the major companies like Amazon. This is why I do not want cloud dependencies. They are the worst form of vendor dependency, as you need them to be there every day. You are at their mercy.

 

[svetz]

...There are countless stories of vendors withdrawing support for products....

I hear you! I'm assuming the internet would be out anyway, so locally run is a must. The SmartThings runs most stuff locally once setup, but I'm not sure where the dividing line is (other than ZWave).

Ideally, all the devices are RF or WiFi controllable so if they don't have an API you can sniff it out (WiFi with WireShark and RF with an SDR as described above). Then you're definitely not at anybodies mercy. <sigh> Wish I could find WiFi circuit breakers compatible with my Square D load center.

Sideloading the app on a FireTV was pretty easy... since it never happened without a photo... here's a photo. I wonder if makes sense to look at the open source projects or just go from scratch, the PI projects might have an acceptably small footprint. That's probably the next thing to check.

​

 

[erik.calco]

I wonder if makes sense to look at the open source projects or just go from scratch, the PI projects might have an acceptably small footprint.

This is the utopian project:

- Think about it for months if not years. Plot out how you will program it. Get excited about it. Then procrastinate because of so much work.
- Then look for free open source software (FOSS). Be shocked and amazed! There's 30-90% of your work done for you!

And today, think beyond the PI. I need to do research on the $3 chip. You have to check it out if you are willing to solder. Watch the video on that page I linked to. He only uses it to control a relay to turn his inverter on/off, but the possibilities for that chip are endless.

 

[erik.calco]

Had to hunt around for the video where he covered that chip.

It is the NodeMCU Mini. Updated the automation page.

 

[svetz]

Updated the post above with the NodeMCU Mini information.

...Think about it for months if not years...

Too much work. More like minutes...if not an hour... Considering I don't have any experience at this, version 1 is bound to be a mess no matter how much planning I do. But, it should be a good learning experience and lay the ground work for version 2.

Ruled out OpenHab as it's bells and whistles were on the UI, something that needs to be super simple when the UI is a TV you use with a remote. It looks like the focus is more a tablet interface to control things. Home Assistant looks a lot more promising it's concept of triggers-> conditions-> action seem close to what I want. Ideally the interface could be run on a PC and the data files pushed to the fire, which possibly only runs a small thread to control the automation defined by the datafiles. Not liking their trigger list though...needs more investigation.

Update: OpenHab also has rules/actions, so if can be split into a configuration and automation piece it might be a candidate afterall (also has an android version).

 

[erik.calco]

For UI, I'll build a web interface which makes it accessible from any computer and mobile device. I use responsive web design (RWD) to make my UIs mobile friendly. I've been building information systems for 80% of my life, since I was a kid and throughout my entire adult life, so it's natural for me.

If what I create is re-usable by others, I'll publish it. Can you browse web pages with your Fire stick?

Here I kinda touch on architecture including UI:

MPP Solar LV2424 kicks butt!!!

NOTE: Using this thread to track progress on tweaking LV2424 settings so that hopefully, in the future, someone with an LV2424 or similar MPP Solar inverter can benefit from it. _____________________________________ I'll say, when I bought it, I had high hopes I could optimize for my...

diysolarforum.com

 

[svetz]

...I'll build a web interface...

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

...Can you browse web pages with your Fire stick?....

There's an app for that and what I did in my test was a call to a restful API.

 

[erik.calco]

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).

 

[svetz]

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:

[{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:

[...
{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:

[
{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:

<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:

[{name, <condition>, [devices], action}]

where <condition> would be a recursive object:

{ device, message,  testOperator, testValue, conditionOperator, <condition>}

So, that's a start anyway....

 

[erik.calco]

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:

[{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:

[...
{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:

[
{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:

<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.

 

[svetz]

...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.

 

[svetz]

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:

$ 3 120v WiFi Relay​

$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.