Using Attiny with RCSwitch and RemoteSwitch

It is possible to use the RCSwitch library in combination with an Attiny85

/* 
Example for different sending methods
http://code.google.com/p/rc-switch/ 
*/ 
#include <rcswitch.h>
RCSwitch mySwitch = RCSwitch();
 
void setup() {
   // Transmitter is connected to Attiny Pin PB3  <--
   // That is physical pin2
  mySwitch.enableTransmit(3);
 
  // Optional set pulse length.
  // mySwitch.setPulseLength(320);
  // Optional set protocol (default is 1, will work for most outlets)
  // mySwitch.setProtocol(2);
  // Optional set number of transmission repetitions.
  // mySwitch.setRepeatTransmit(15);
}
 
void loop() {
  /* See Example: TypeA_WithDIPSwitches */
  mySwitch.switchOn("10101", "10000");
  delay(1000);
  mySwitch.switchOff("10101", "10000");
  delay(2000);
 }

The sketch uses 4754 bytes of program memory (has 8k) and 203 bytes (has 512 bytes) of SRAM.

The other main 433MHz library, the RemoteSwitch library, does not compile for the Attiny because even when transmitting, a call is made to the receiver library, that has SerialPrint routines. These will not compile for the Attiny85. However, the modification of the RemoteSwitch library made by Jeroen Meijer, does compile on, and works with the Attiny 85 and 45

/*
Switches the 3 devices from the Elro AB440
and 3 devices of the SelectRemote1728029
*/
#include <RemoteSwitch.h>
// declaration of the Elro AB440 creator
ElroAb440Switch ab440Switch(3);
//declaration of the SelectRemote creator
BlokkerSwitch3 blokkerTransmitter(7);
void setup() {
}
void loop() {
//Switch on SelectRemote 1728029 device 1
blokkerTransmitter.sendSignal(1,true);
blokkerTransmitter.sendSignal(2,true);
blokkerTransmitter.sendSignal(3,true);
//Switch on AB440-device B on system code 29.
//dip switch 1-5 is on-off-on-on-on = 10111... but is read as 11101='29'
ab440Switch.sendSignal(29,'A',true);
ab440Switch.sendSignal(29,'B',true);
ab440Switch.sendSignal(29,'C',true);
delay(2000);
blokkerTransmitter.sendSignal(1,false);
blokkerTransmitter.sendSignal(2,false);
blokkerTransmitter.sendSignal(3,false);
ab440Switch.sendSignal(29,'A',false);
ab440Switch.sendSignal(29,'B',false);
ab440Switch.sendSignal(29,'C',false);
delay(2000);
}

This program compiles in 2622k of program memory and 61 bytes of dynamic memory

33 thoughts on “Using Attiny with RCSwitch and RemoteSwitch

  1. Of course they will. I will bend them until they realize resistance is futile. BTW, I really don’t see how the receiver part is used, and I don’t think any Serial operation should be anywhere in there anyway. As I am tinkering with my DigiSpark, I am sure I can get that to work.

    1. I start to love these Attiny’s more and more. I agree, the Serial operation shouldnt be in the receiver part of that library. I dont understand why it is there, but I didnt bother to look at it any further as it was just an excercise.
      The Digisparks are nifty little buggers as well, but before I venture in to those… I still have a lot of projects and about 10 unused pro mini’s and an Atmega2560 lying around idle

  2. Hehe, I know the deal Digispark, a nano, a due with a CAN trainceiver, an ESP8266. The list is endless.

    There are references to Serial in the receiver class. Crappy debugging code. As I wrote on plus, that whole class is going away, being replaced with nifty interupt driven routines. So, I simply commented those out; didn’t bother to upload a new version. I see no referencs to the receiver or to the Serial class in RemoteSwitch. I really don’t think it should link. I will make a tiny sender sketch for the Digispark and let you know.

    1. If you dont look under the hood, RemoteSwitch is easy to use and does what it should do. But I dug into the code and I just didnt grasp the calls to serial and I got the impression receive and send libraries are not independent,
      yet kudo’s to both Suat Γ–zgΓΌr (RCSwitch) and Fuzzilogic (remoteSwitch) for their pioneering work.
      Looking forward to yr tiny sender sketch.

      1. Just to avoid misunderstandings: remoteSwitch was writen by Randy (I think that was Fuzzilogic), and I expended hugely on that code adding many, many sets. So when I talk about remoteSwitch, I actually talk about my codebase, which I have shared on my google+ page. It is not anything official, but I think it is a great code base now.

        I made, just for fun, a shetch inclusing just remoteSwitch and a loop where it sends commands to three receivers, including the mandatory silence function. I am just sending the commands to the LED pin to verify it works. I set th e.h file to include support fot Action, Kaku2 and Ener002. You will enjoy this compiler message:

        “Sketch uses 2,840 bytes (47%) of program storage space. Maximum is 6,012 bytes. Global variables use 34 bytes of dynamic memory.”

      2. Yes, I got that and indeed Fuzzilogic = Randy as far as I know (oops that sounds quite odd in english actually)
        and I understood what code you meant.
        With “if defi-ing” you indeed can save on overhead. In fact I have a completely stripped version of ‘your’ RemoteSwitch library (that is Randy’s extended library) only leaving in the stuff I need. Looking forward to yr compllete re-write with what I understood to be Oregon protocol.
        If I have some time (too many projects) I will have a look again at the Randy based code to see if i can strip out that call to the serial port… but then again RCSwitch is ok for attiny.
        No worries, didnt notice any hoorible spelling

      3. Hmmm, I guess fuzzylogic remoteSwitch expanded in a different direction then. “My” (ahem) version does not. And indeed the ifdef’s do exactly now what you did by hand, leaving out what is not used. Though I am hearing that the compiler is pretty good nowadays at leaving out unused code, so it might have been a moot exercise.

      4. Perhaps this is is not the right place but since this thread is actively monitored: Any idea why this piece of code does not work?


        #include

        #define ledG 3 // Red led
        #define ledR 0 // Green led
        #define interrupt 0 // INT0 / PB2 / physical pin #7

        RCSwitch mySwitch = RCSwitch();

        void setup() {
        mySwitch.enableReceive(interrupt); // Receiver on interrupt 0 => that is pin #2
        pinMode(ledG, OUTPUT);
        pinMode(ledR, OUTPUT);
        digitalWrite(ledG, LOW);
        digitalWrite(ledR, LOW);
        }

        void loop() {
        if (mySwitch.available()) {
        digitalWrite(ledG, HIGH);
        } else {
        digitalWrite(ledR, HIGH);
        }
        }

        The red pin always turns on.
        This makes me believe RCSwitch will compile but somehow won’t get available.
        I connected the ‘crappy’ YX-MK-5V to the INT0 pin (physical #7)
        If too much offtopic, don hesitate to make it clear to me.

        Thanx in advance!

      5. John, I am about to bring my sonto school. Will get back to you later,but just two questions: are you sing this on an Attiny?
        and second, is your intention to switch the LED on on receiving any code? coz that might be where your problem is. You check if the signal is available and it usually is, so your led might be switched on before you even press a button.
        I advise to add -even if just for testing- a line checking for the value that you send and see if that makes a difference

      6. That would be good but I just didnt see much use in including code for systems i dont think i will use and it was a good excercise in understanding the code, but there still is some stripping/optimizing left

      7. I just learned a good lesson: be aware of different versions on different computers. I seem to have a laptop with an old (undated) version of Randy’s RemoteSwitch (V2.00), that has a call to Serial in the receive cpp file, that somehow is also called from the transmit cpp file. Then I have a version of Randy’s lib that he calls NewRemoteSwitch (v1.2.0) (dated 28 jan 2014), that still has calls to Serial from the receive cpp file but not from the transmit cpp.
        and ofcourse I have a desktop with ‘your’ fork on it.
        RemoteSwitch and NewremoteSwitch seem to be two seperate developments with ‘NewRemote’ containing ‘New’ remotes such as the ‘A-series Kaku’ http://gathering.tweakers.net/forum/list_messages/1268154/5 . I havent compared them yet to ‘your’ library, that I propose to just call your library without quotes from now on.

        The compiler indeed is pretty good nowadays, but I understand that it still has some trouble with libraries called from within ifdefs. It will still try to load a library even if the ifdef isnt met. I noticed that when I tried to use ‘Wire’ vs ‘TinyWireM’ inifdefs depending on the chip being used.

  3. Hi, I came across this page looking for my attiny85 to be able to receive KAKU 433MHz using the XY-MK-5V. Can anyone help me here? I’m more like a script kiddy so when I want to modify existing libraries and see the code I suddenly eeeh.. hesitate πŸ˜‰ Thanx!

    1. the reception probably isnt a problem, but the decoding is πŸ™‚
      There is an 433 MHz library that does compile on the attiny85 and that as far as I know knows Kaku codes. Try the RCSwitch library from Suat Γ–zgur

    2. I have to violently agree with Arduino here. The XY-MK-5V ais crap. Better shop for RXB8. Trust me, that one dollar extra you won’t regret. Just make sure you get a 433MHz version, not the 315MHz.

      As for Kaku, note there are 2 versions. The self learning ones (which you probably have), and the old ones with a dial on it.

      1. i might not have expressed myself clearly. I agree that the XY-MK-5V is not a good one, but it does work. When I said the decoding might be a problem, what I meant was spacewise as in an Attiny85 there just is less space to put a lot of code in. Indeed better spend a dollar more, but he already has the YK-MK-5V so might as well give it a try πŸ™‚

      1. Hi – I’m still here. πŸ™‚ Haven’t got much time at the moment. But no – not solved yet.
        I am experimenting with NewRemoteReceiver library which does compile. However it does not respond to the old KAKU protocol. The advantage of this library is that it first determines the period length and, based on that, it goes on decoding. This makes it less clock dependent, something which I’ve seen mentioned now and then (not very stable). So I am analysing the library now. It contains a state machine and the protocol descripen seem to match the protocol I use. The more I find it strange that is does not work.

      2. yes that seems strange. i have it working but i havent used the old KAKU protocol. Should you find out what the problem is I would be eager to hear it

  4. Hello,

    Maybe RCSwitch is only valid for SENDING using a attiny85. For receive, there is a comment inside source code that says:

    // At least for the ATTiny X4/X5, receiving has to be disabled due to
    // missing libm depencies (udivmodhi4)
    #if defined( __AVR_ATtinyX5__ ) or defined ( __AVR_ATtinyX4__ )
    #define RCSwitchDisableReceiving
    #endif

    1. Thanks for your input. Good to know. To be honest I hardly use the RCSwitch library as I normally use the Jeroen Meijer fork of the RemoteSwitch library and I mostly do sending of code, although I have one project with the Attiny85 receiving Rf remote Signals

      1. A comment from Jeroen:
        It depends a bit on what you want to do. I have build a ENER (=eurodomest) receiver in a ATtiny85 that, contrary to the original receiver, can learn 4 transmitters. Just for readability I stripped out all other codec logic. The code is on codebender.cc: https://codebender.cc/sketch:142127

        Off topic: the tiny is wired to the receiver module (RXB8 of course), the enable pin of a constant current buck DC DC converter to drive the LED’s and a tiny button. The button puts it in learning mode and the number of flashes of the LED’s indicate “learned” or “unlearned”. It’s a pretty good setup.

      2. Thanks Jeroen. I can honestly say that that is a nifty little piece of software. I have that up and running for several months without glitches

    2. It depends a bit on what you want to do. I have build a ENER (=eurodomest) receiver in a ATtiny85 that, contrary to the original receiver, can learn 4 transmitters. Just for readability I stripped out all other codec logic. The code is on codebender.cc: https://codebender.cc/sketch:142127

      Off topic: the tiny is wired to the receiver module (RXB8 of course), the enable pin of a constant current buck DC DC converter to drive the LED’s and a tiny button. The button puts it in learning mode and the number of flashes of the LED’s indicate “learned” or “unlearned”. It’s a pretty good setup.

    3. == here is some extra words as wordpress seem to have had a glitch on this ==

      It depends a bit on what you want to do. I have build a ENER (=eurodomest) receiver in a ATtiny85 that, contrary to the original receiver, can learn 4 transmitters. Just for readability I stripped out all other codec logic. The code is on codebender.cc: https://codebender.cc/sketch:142127

      Off topic: the tiny is wired to the receiver module (RXB8 of course), the enable pin of a constant current buck DC DC converter to drive the LED’s and a tiny button. The button puts it in learning mode and the number of flashes of the LED’s indicate “learned” or “unlearned”. It’s a pretty good setup.

      == here is some extra words as wordpress seem to have had a glitch on this ==

    4. Message from Jeroen
      It depends a bit on what you want to do. I have build a ENER (=eurodomest) receiver in a ATtiny85 that, contrary to the original receiver, can learn 4 transmitters. Just for readability I stripped out all other codec logic. The code is on codebender.cc: https://codebender.cc/sketch:142127

      Off topic: the tiny is wired to the receiver module (RXB8 of course), the enable pin of a constant current buck DC DC converter to drive the LED’s and a tiny button. The button puts it in learning mode and the number of flashes of the LED’s indicate “learned” or “unlearned”. It’s a pretty good setup.

  5. It depends a bit on what you want to do. I have build a ENER (=eurodomest) receiver in a ATtiny85 that, contrary to the original receiver, can learn 4 transmitters. Just for readability I stripped out all other codec logic. The code is on codebender.cc: https://codebender.cc/sketch:142127

    Off topic: the tiny is wired to the receiver module (RXB8 of course), the enable pin of a constant current buck DC DC converter to drive the LED’s and a tiny button. The button puts it in learning mode and the number of flashes of the LED’s indicate “learned” or “unlearned”. It’s a pretty good setup.

    = glitch – please remove this last line =

    1. Jeroen, seems that this comment as well as the earlier comment you couldnt post, appeared in my spam folder. dont know why. I confirmed with WP you are not spam so i hope it is cured now.
      That link is indeed interesting.
      While on doorbells, I understood that there was one doorbell through which hackers by repeatedly pressing apparently could get access to yr network and another one in which a hacker by physically opening it and reading some dipswitches, also cod gain access to yr network. Obviously those were network connected bells. I like to see them try with my non-networked chinese ring-a-ding.

      I am going to read that attiny article and see what use i can make of it

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s