350Mhz RF Remote. I know there is 315mhz and 433mhz.

The LED doesn't always blink. Do you have the module wired up already? If so, the library is meant to output to the serial port. So, you have to open the Serial Monitor in Arduino.

Yeah I know I have to have serial monitor open. I though a little program together that would write hello world 100 times then stop, and it worked. So I know that serial monitor is working.

At this point I think I'd like to somehow test that pin 2 can read anything with RCSwitch receive running.

ok, so you are using the RCswitch library with no modifications and have the data pin of the module connected to pin 2 on the Arduino?

You could connect an LED to this as well that will flicker when data is being received by the module. To check this with the Arduino, try a little sketch like this:

void setup(){
  Serial.begin(9600);
  attachInterrupt(0,test,FALLING);
}

void loop(){

}

void test(){

Serial.println("Pin went low!);

}

oh, and make sure that you have the ground on the transmitter connected to the ground on the arduino. Otherwise, a high or low may not be valid voltage levels.

I am using the example code with no modifications. I did play around with pins other than pin 0 (pin 2) just for fun.

If I run this code (which I found online)

/*
  DigitalReadSerial
 Reads a digital input on pin 2, prints the result to the serial monitor 
 
 This example code is in the public domain.
 */

// digital pin 2 has a pushbutton attached to it. Give it a name:
int pushButton = 2;

// the setup routine runs once when you press reset:
void setup() {
  // initialize serial communication at 9600 bits per second:
  Serial.begin(9600);
  // make the pushbutton's pin an input:
  pinMode(pushButton, INPUT);
}

// the loop routine runs over and over again forever:
void loop() {
  // read the input pin:
  int buttonState = digitalRead(pushButton);
  // print out the state of the button:
  Serial.println(buttonState);
  delay(1);        // delay in between reads for stability
}

I see just
0
0
0
0
0
0
many times.

then when I hook up the remote and press a button I do see it change, like
1
0
1
1
1
0

then it will go either
0
0
0
0
0

or

1
1
1
1
1
1
on and on and on

So I know it's reading something.

Even if I load SoftwareSerials TwoPortRecieve example and run it I see:

Data from port one:

Data from port one:

Data from port one:

Data from port two:

over and over again. Maybe something is wrong with the Arduino? Or my setup?

I'm running the board off of arduino power. I've tried both the regular ground near the power and the other ground on the digital side.

using the example ReceiveDemo_Simple, you aren't even getting "Unknown Encoding?"

That's correct.

When I ran your code I got

Pin went low! <when I touch to grond
Pin went low! <when I touch to gournd
Pi

stop. Then I'd have to close and reopen the serial viewer.

I suspect that's because it is generally not a good idea to do a serial print in the middle of an interrupt. So, the pin is working and the interrupt is working. Try my code with the remote connected. It is similar to the code you already tried, but uses an interrupt instead. It may freeze up, but if you get some stuff flowing, at least you know the remote is able to trigger an interrupt.

When I say stop. I mean the screen printout stops. I issue no command.

Could this be a FloatingPin Problem that I've read about?

I knew what you meant. It freezes completely. Only a reset brings things back to life.

I have had this happen when I didn't connect grounds together and I have had it happen when I have put serial commands inside of interrupts (though it doesn't always freeze up.) What is the floatingpin thing you have read about?

The Dout voltage from the transmitter could be too high or too low. It should be held high when not transmitting. Do you have a multimeter to check it?

I could check it.

I also have some interesting progress.

I found some code. Got inspired and did this.

int forwardPin = 12;

void setup()
{
  Serial.begin(9600);
   pinMode(forwardPin, INPUT);
   digitalWrite(forwardPin, HIGH); // Turn on the pullup resistor.
}

void loop()
{
  int forwardState = digitalRead(forwardPin);
  if (forwardState == HIGH)
  {
    Serial.print("1");
  }
  else
  {
    Serial.print("0");
  }
}

When I run this I get a nice stream of 1s. No random variations. When I connect pin 12 to the signal pin, they change to 0s. Then when I press the button for light on, I get this.
000000011010000000001101101000000001101000000000001101000000001100110100000000110100000000000110100000000110110110000000011010000000000011010000000011011010000000001101000000

However, if I go run that in the binary RCSDemo. Nothing happens.

/*
  Example for different sending methods
  
  http://code.google.com/p/rc-switch/
  
  Need help? http://forum.ardumote.com
*/

#include <RCSwitch.h>

RCSwitch mySwitch = RCSwitch();

void setup() {

  Serial.begin(9600);
  
  // Transmitter is connected to Arduino Pin #10  
  mySwitch.enableTransmit(10);

  // 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() {

 

  /* Same switch as above, but using binary code */
  mySwitch.send("000000011010000000001101101000000001101000000000001101000000001100110100000000110100000000000110100000000110110110000000011010000000000011010000000011011010000000001101000000");
  delay(1000); 

 
  delay(20000);
}

I'm done for tonight. Thanks for your help.

Instead of printing the code to the screen with serial.print. Is there away to print the code to a pin?

I think I'd like to hook the button board up to the transmitter though the arduino and play from there. I dont know. Picking at straws I suppose.

sure, in the interrupt routine, you could just do this instead of serial.print:

byte value;
value = digitalRead(2);
digitalWrite(3,value);

There may be an error with digitalWrite taking value instead of HIGH or LOW. If so, try:

int value;

instead of byte.

That should relay whatever it reads on pin 2 out to pin 3. There will be a delay of course, but as long as the delay is consistent, the transmitter shouldn't care.

If you get a chance to measure that voltage, let me know. We may have to do something in-between to get it all nice and happy.

As a last resort, you could try to figure out which pins on the PT2262 that the buttons are connected to and which pins the address are set for from the circuit. That will tell you what commands are what instead of trying to read the remote output.

You could always go with your original plan to hook the buttons up directly on the remote and control it that way, but I think getting this sorted out will be more useful to you in the long run. I won't be able to mess with it much this weekend, but if you haven't figured it out by Monday, I will grab one of my remote outlets and attempt it myself to see if there are any gotchas.

Well I got home tonight and figured I'd look up all the values I've tried to use so far and come up with something. It took a couple hours, but It's a nice course in simple programming!

int inpin = 2; // makes the input pin pin 2
int outpin = 3;  // makes the output pin pin 3
int val = 0;  // sets the initial variable to 0

// the setup routine runs once
void setup() {
  Serial.begin(9600);  // initialize serial communication at 9600 bits per second:
  pinMode(inpin, INPUT);  // makes inpin the input pin
  pinMode(outpin, OUTPUT);  // makes outpin the output pin
}

// the loop runs over and over forever
void loop() {
  int inpinState = digitalRead(inpin); //reads the state of the input pin
  digitalWrite(outpin, inpinState);  //writes the state of the input pin on the output pin
  Serial.println(inpinState); //displays the value of the input pin on the screen
  delay(0); // delay in between reads for testing
}

Results:
If I physically connect the transmitters signal line to the button boards signal line the remote works. I can control the light.
If I run it though the arduino with the above code, I get nothing. I can see the binary change happening as I push the button, but the lights don't respond.

What if there is a speed mismatch between what the arduino can process and what the button board and transmitter use? So the binary doesnt get though right? Like watching my arudino set at 9600 baud with a serial monitor set at 1200 baud?

Could it be an analog signal or a sign wave? I dont know. Scrapping for ideas.

SUCCESS!!!! It works!

I just had to get rid of the serialprint line. I guess the extra little clock cycle that it took to print that line made the receiver not respond.

Now I just need to capture some codes. I guess I have two ways to do this.

  1. capture the codes using serialprint and copy paste into notepad and tinker until it works. Hardcoded codes do sound nice.

  2. put some code in the setup section that will say "press the light toggle switch" then capture that code into a variable called lighttoggle. Then prompt the user "press the fan on button" then capture that code into a variable called fanon.
    I know how to use serialprint and I know how to create variables now. What I dont know is how to make it prompt, wait for input, then know when to move on to the next section.
    Plus under option 2 I would have to store variables that were, 8, 16, however many bytes long and not just an instantaneous state change.

You just print the prompt out. Then you use this (in your loop):

if(Serial.available()){ //Someone entered something in the serial display

  byte c = Serial.read();

}

if(c > 0){ //We have a non-null value, so do something with it
  switch(c){
     case 'm': //'m' was sent
          //run some code meant for 'm'
         break; //always break after doing the command unless you want it to "fall through"
     case 'n': //'n' was sent...
         //do some code for 'n'
         break;
      //etc...
 }

If you have multiple steps, like multiple prompts, keep a state machine (keep a count of steps) so it knows what step it is at.
In your case, it might make more sense to increment the steps based on the interrupt. That way your code knows when the button was actually pressed.

byte state = 0;
byte light_toggle;
byte fan_toggle;
#define maxStates 6 //if there will be six steps total

void loop(){

  switch(state){

    case 0:
	Serial.print("Press the light toggle switch");
	break:
    case 1:
	light_toggle = value;
	Serial.print("Light toggle command is: ");
        Serial.println(light_toggle, DEC);
        state++ //we have to increment the state here since no interrupt
	break;
    case 2:
        Serial.print("Press the fan toggle switch")
        break;
    case 4:
        fan_toggle = value;
	Serial.print("Fan toggle command is: ");
        Serial.println(fan_toggle, DEC);
        state++ //we have to increment the state here since no interrupt
        break;
     //etc... for all states
}

}



void interrupt(){
 state = state++ //increments the state counter
 
 //....do normal interrupt code here


 if(state > maxStates) state = 0; //reset the state counter
}

If your value is 8 bits use byte value in your declaration, if it will be 16, use unsinged int value

There may be some minor errors in there. I always make stupid mistakes when writing code and only catch them when I go to compile. So, you may have to mess it, of course. It's just an example.

BTW, your address part of the command will (likely) always be the same for a particular device. So you really only need to capture that part once, then just store the command part for each button.

I am very interested in home automation myself. I even have all the X0 goodies including all the software that lets you program intelligent control and control from the web, but I am currently only renting a house so I am limited in what I can do. I have always thought it would be nice to tie all the various pieces together at some point. Maybe I should start playing with it a little so I have all the chunks ready when I move on.

I tend to stay at the girlfriends over the weekend, so something like an 'away' macro that turned off all the lights, set the thermostat down, ocassionally turned on lights to make it appear that I was home, set the security system, etc.. would be nice. Also checking on the cats and being able to feed and water them remotely would be nice. Hmm... I may have to start playing again.

Oh yeah. I love this stuff. I dreamed of working on one for awhile. You need the arduino automatic cat feeder and sandbox scrapper with a little robot that will collect the doo doo and run it to the trash for you :slight_smile: I swear possibilities are only limited by a persons imagination and technical ablilty.

I tried this:

int inpin = 2; // makes the input pin pin 2
int outpin = 3;  // makes the output pin pin 3
byte state = 0;  //sets bytes vale to 0???
byte light_toggle; // creates byte light_toggle
byte value;  //creates byte value to display value
#define maxStates 6 //if there will be six steps total  (I'm not sure how this works.  There are 2 states on and off?)

// the setup routine runs once
void setup() {
  Serial.begin(9600);  // initialize serial communication at 9600 bits per second:
  pinMode(inpin, INPUT);  // makes inpin the input pin
  pinMode(outpin, OUTPUT);  // makes outpin the output pin
}

// the loop runs over and over forever
void loop() {
   switch(state){ //like an if statement

    case 0:
	Serial.print("Press the light toggle switch");
	break;
    case 1:
	light_toggle = value;  //what is this doing?  It's setting light_toggle = value.
	Serial.print("Light toggle command is: ");
        Serial.println(light_toggle, DEC);
        state++; //we have to increment the state here since no interrupt
	break;

}

}

And it prints "Press the light toggle switch" over and over again.
I'm not sure how #define maxStates 6 works. Why do you need to know this? Nothing ever references maxStates?

I think I need to somehow put the code together so that each state where we read a byte has it's own "if(c > 0)" section. I'm not even close to understanding how that piece of code works yet. It should just ignore all 0s so if it sees 0 then 0 then 0 then 0 then 0 it does nothing. But if a 1 pops up it says "hey listen up write this down" for 8 bits and call that bit light_toggle and file it away.