Feed on

I have a couple of nRF24 devices around the house like the doorbell, front door camera, the single receiver for both and I might look to expand that list in the future but re-programming the receiver when you would like it to handle a new device or perform an additional action can take a while plus the time testing that everything works.

So I thought, why not make an ESP8266 for a web interface where we can store rules and have it connected to the nRF24 to receive incoming packets, it’s similar to IFTTT but all local. The rules would all be based on a single byte packet it would receive, we could have the rules active or not, with rule actions such as sending an email, pulsing a pin for a certain amount of time, sending an nRF packet, writing data to a common variable (with a timeout when it’s reset) and reply back with that variable. We can have a button to save everything to the EEPROM (emulated on flash) and read it all back if the ESP8266 is power cycled.

Some quick use cases:
– Doorbell is pressed, you could either have it pulse the buzzer locally for a second or two and you could also have a remote buzzer anywhere else so it sends a packet to have that buzzer go off too.
– I’m thinking about adding a small sensor to the mailbox, so if it’s moved, it would send a packet, we could have it write data to a variable. Add a battery powered sensor anywhere around the house with either a buzzer or LED, to check in every few seconds and read that variable back so if it changes to a 1, the buzzer or LED goes off for a little while.

We can start off modifying the LiPo Battery Storage Monitor project as it’s got nRF24 support already working as well as a ~1 second interrupt acting as a timer.

Firstly we need to define our data structure, we have an array of 10 bytes to use for our write/read variables function as well as the timeout counter for those. We then have the state of the rule 0 or 1, the incoming byte to match on, the ruleAction is just a number between 0 to 4 and generic variables and character arrays which could be used by any rule.

Now that we have the structure, the rest is mostly simple and we can test every rule to make sure it works so we don’t have to worry about it again.

We have the new rule POST, we just store all the input in the data structure according to the rule action.

We may have to edit the rule to disable/enable it or delete it completely. When we delete a rule, we loop through all the rules starting from the rule deleted to copy them all down by one.

When we wish to save the rules, we can save them to the EEPROM which the ESP8266 doesn’t have but emulates it through the flash which is why we need to commit the EEPROM after we are finished writing to it. We’ve got 4096 bytes which is plenty for us, our structure is always going to be the same at 46 bytes each rule.

For loading from the EEPROM at start up, we just check if the DataByte is more than 1 and not 255 (blank), and if the rule action checks out, we load everything back again, easy.

For the main loop, we just check if a packet is waiting, loop all the rules, check if they are active, if the data byte matches and then the rule action to take.

For example, the pulse pin rule, we write the pin state and then store the timeout value in one of the extra variables, we’ll be letting the timer handle the delay and switch the pin back to how it was, this is so we don’t get locked up waiting for the delay, same thing goes for the common variables.

Download esp8266_nrf_rules_server_v1

And that’s about all there is to it, now you just need to write down the nRF TX/RX address of each device you put up with their specific byte to perform an action and you can have the rule do that. The only downside is that for an nRF device/sensor to transmit an event to our rule server (say doorbell pressed), it needs to have fixed a TX/RX address and it’s own unique byte on our rule server, there are over 200 possible combinations so I think that should be fine, don’t expect to have more than 10-20 sensors.

Leave a Reply