As promised, here's a link to the project.

It took three weeks to build, but here it is: a device that will easily connect almost any 433Mhz device to your smart home.

The 433 Hub can do two things:

• You can teach it a signal, and from then on it will be able to detect it.
• You can teach it a signal, and from then on it will be able to replay it.

Both of these features come in 'single signal' and 'on+off" versions. So for example:

• You could copy the ON and OFF button from a remote for your 433Mhz sockets, and from then on switch the socket from your smart home controller.
• You could teach it to detect window sensors that have both on and off states.
• You could teach it to detect the alarm signal from a wireless smoke detector.

For each signal that you teach it to recognise, a door sensor will be presented your controller.
For each signal that you teach it to replay, an on/off switch will be presented to your controller.

Signals take between 8 and 28 bytes to store, depending on complexity and if they are simple or on+off signals. This means an Arduino Nano can store between 20 and 60 signals in just half of it's eeprom (512 bytes).

HARDWARE

• Arduino
• 433Mhz receiver & transmitter
• OLED screen (optional)
• Keypad (optional)

You can trigger the learning sequences from 4 virtual buttons that the device creates (detect simple, detect on+off, replay simple, replay on+off). But it works best if you add a small OLED screen and an analog keypad. With a 12 button keypad you can easily replay 10 signals. The last two buttons are used to navigate and make selections in the menu system.

Using the menu you can delete the last recorded signal, or delete all recorded signals.

It's designed to work with the upcoming Candle privacy friendly smart home, and the Candle Manager. More on that later this year.

CODE
https://github.com/createcandle/devices/blob/master/433-hub/433-hub.ino

Are there no clever hacks for this?

Arduino doesn't seem to complain about this:

for( byte replayableID=1; replayableID < 100; replayableID++ ){
  present(replayableID, S_BINARY, (const char*)replayableID); wait(RADIO_DELAY);
}

In that case they might try Google/DuckDuckGo, and still find it anyway.

I search the MySensors forum quite a bit, and often the first hits are from 4 years ago. They are almost never useful, as the code and often the concepts are outdated.

Would it be possible to set the default search window to just 2 years ago? Or whenever MySensors 2.0 was released?

Advanced search could still be used by anyone that wants to find older posts. But in general I think this could be a 'sane default'.

@davidzh So if I understand correctly you've hardcoded the sensors on the controller side? Interesting move. I guess that only works if you don't need to automatically add new sensors.

I have another question:

I'm trying to make the child name in the presentation function generative.

For example, let's say I want to present 30 on/off buttons to the controller. I'm trying to automatically name them "BUTTON_1", "BUTTON_2", etc in a loop.

But I can't get it to work:

  // We loop over all the recognised signals.
  for( byte recognisedID=10; recognisedID < 10 + (amountOfStoredSignals - amountOfStoredReplayableSignals); recognisedID++ ){
    char childName[2]; childName[0] = (char) recognisedID;
    Serial.println(F("Presenting sensor ")); Serial.println(childName);
    present(recognisedID, S_DOOR, childName); wait(RADIO_DELAY);
  }

I've tried a lot of variations..

How can I generate names for the presentation function?

Another question, just to be sure: the children don't need to have consecutive ID's right? And the only child ID that is off limits is 255, in case it also functions as a repeater?

Indeed. I just moved them into present, and it worked fine.

I didn't so much mean to say that it was technically not possible, more that the convention is to do things like "Serial.begin" in the setup function. So in a way, for beginners like me, it can also create some slight confusion/insecurity about what all those extra Present and Before functions do, and how vital it is to keep things in those functions.

I'm working on a 433Mhz signal cloner. This device learns new 433Mhz signals, and then allows the user to replay signals.

For each new copied ON/OFF signal pair I want to present a binary switch to the controller. That works fine.

But the user also has the ability to delete the last copied signal.

In this case I would like to tell the controller to remove (or display as disabled) the related switch.

Looking through the API I didn't see any 'internal signal' to do so. But perhaps there is a way?

@mfalkvidd Thanks for the replies, they cleared things up.

To andwer your question: the benefit of presenting in the setup function would be that the Serial output is usually started in setup. That was I could find out while debugging how many devices have been created.

Another "advantage" would be that more variables are available. For example, I have a function that reads from eeprom how many 433Mhz signals have been stored. For each signal a corresponding button must be presented.

In other words: there are some things I need during the presentation phase that are usually initiated in the setup function.