Home automation with 433 MHz transmitter & receiver

Archives GrovePi
1

Hi,

I have recently been able to spend some time on one of my pet projects: building a home automation system using my Raspberry Pi and GrovePi+.
I have embedded in the GrovePi firmware the RC-Switch library to drive a 433MHz pair of transmitter / receiver.
With this, I can:

  • remotely turn on or off radio-controlled outlet sockets that can commonly be found in hardware stores or supermarkets

  • receive signals from the remote coming with these sockets

There are lots of possible applications with this, like turning on or off lights, fans, portable heaters, etc, without having to mess with relays and high currents/voltages.

My modified version of the firmware is developed here on github, and I will submit a pull request once I will have finished documentation, and the Python library and samples (I will add node.js support after that).
There are however a few points I would like to discuss with the community.

Interrupt registration
The ATMega328 has two interrupt lines, coupled with inputs D2 and D3.
Several sensors require one of these, including both the 433 TX and RX modules, as well as the dust sensor.
The current 1.2.7 firmware during its setup phase registers one of the interrupts for the dust sensor module, even if it is not present:

void setup()
{
    // Serial.begin(38400);         // start serial for output
    Wire.begin(SLAVE_ADDRESS);

    Wire.onReceive(receiveData);
    Wire.onRequestndData);
    attachInterrupt(0,readPulseDust,CHANGE);
}

In my modified version of the firmware, I removed this, and kept only an interrupt registration when one starts the dust sensor module (command 14: enable dust sensor). Does this makes sense for you? I do not have the dust sensor, so I cannot check the impact.

Firmware branch management
Firmware-wise, the git repository is organized with a folder by version.
Wouldn’t it be better to have a ‘master’ folder with the under-development version,and when a version is considered OK for general release, copy its source and the binary to a new folder?
This would make easier to identify changes made from one version to another using git (currently, you have to manually diff files in several folders), and to know on which codebase you should develop when extending the firmware.

1 Like
2

@nikkoura thanks so much for the detailed look at this! This sounds like a fantastic project and we would love to see more about it; if you have any pictures or project info, we would love to know more.

And thanks for taking the time to contribute to the firmware on github. When you’re ready we would love to review a PR and share with the rest of the community. Thanks!

Indeed, we’ve been meaning to take a hard lookat interrupts on the GrovePi firmware, we were discussing it today in context of the dust sensor.

Firmware

We’re happy to talk about a new way to organize the firmware. So far it seems to have worked well, but we would love to hear new ideas. Would it help cut down on confusion if we specifically marked out the latest release in the readme?

Thanks again for the fantastic contribution!

3

@JohnC, so far there is not much to show with photos or videos, but I will provide some elements when the project will be in a good shape.

The context: I have a light I do use very often, which is far from my couch. It is plugged on a remote-controlled socket, so I can command it while seated, but I wanted to control it from my iPhone using Apple’s HomeKit.

Same thing for a fan in my bedroom. I have a remote control that I can use to turn it on / off, but I wanted to automate this fan:

  • turn it on when I am going to bed, by combining a time range and a PIR movement sensor
  • turn it off at the night when the room’s temperature goes below a threshold
    However, I wanted commands sent from the remote to have priority over this automation.

Most of what I needed was already provided by the GrovePi, except support for the 433MHz Rx/Tx for interacting with the remote controlled sockets and the associated remote (my electronics/electricity skills are not very good, and it was never an option for me to mess with 220v / 16A with relays - don’t want to burn my house down).

As for the GitHub source tree organization: I see several difficulties with the current setup.

  • It is not clear for contributors to know which contribution will need a new firmware version, and which contribution will not. Adding support for a new sensor? Fixing a bug? Making a change which will modify an existing firmware behavior?
    For instance, in the case of the development I am making, I do not know if have to introduce a 1.2.8 or keep it on 1.2.7.
  • Looking back at the firmware change history is painful. Sometimes you want to understand why something has been written as it is, and being able to easily browse the full history of the firmware source can be of a major help to understand when and in which context this was done. Ex: https://github.com/DexterInd/GrovePi/pull/247#issuecomment-219729242
    Unfortunately, with the current way of copying the firmware sources with each version, the history is broken each time, and you have to spend lots of time to rebuild it.

My suggestion would be:

  • to remove versioning from the firmware .ino filename
  • to create a Firmware/Source/Current folder, with the source code, but not the .hex binary. All development should take place in this source tree.
  • when you decide to make generally available a firmware version:
    – create a versioned folder, with only the corresponding .hex file
    – tag the ‘current’ sources (firmware and libraries) with the version
4

I think tacking latest release on the latest release folder would be nice.