@nca78 You can't really add one more battery, or you fry the radio which can handle only 3 and some Volts, right? If doing so, one needs to add step down regulator, so again loosing voltage. Or am I wrong?

Just to give an update anyone building similar setup. I managed to find a day to fix the systems. I thought the step-up booster is causing noise, so I added a capasitor to step-up output. It stabilised it enough so PIR doesn't give false alarms any more. Pheeeew... Finally working properly.

Thanks a lot for sharing this! I already did the Arduino and MySensors stuff, and started thinking of writing program for it. I'm glad I found this, it fit exactly what I was doing. Here's your code a bit modified, and added some different kind of lamps for the next one looking for references: https://github.com/ikke-t/Arduino-RGB-leds-and-lightbulbs/blob/master/README.md

The additional piece here is how to command this from OpenHAB, as that's my controller. One needs to modify the RGB info via rules, it's there for reference:

https://github.com/ikke-t/Arduino-RGB-leds-and-lightbulbs/raw/master/src/rgb.rules

There are links within that file to references for how to create similar rules for RGB mangling.

@Ngwpower after 10 months experience, I've modified things a bit. I never got to smaller batteries, as my access to 3D printer is quite rare. I have run into some problems with this setup.

1. PIR sensor is picky about the voltage. It starts soon creating false alarms after batteries get a bit lower on voltage. It expects good 3.3V. To fix this I added voltage boster to suck out all the power from batteries to keep it in steady 3.3V. It worked (for a while).

2. The 2.4Ghz radio is not a good idea in concrete house, along with neighbors wifis. I have lost signal from 1/3 sensors. I don't know really why, I suspect the radio signal strength and interference.

3. I think batteries won't last now for so long after putting in the voltage pump. I really don't know why, I haven't investigated, but devices disappear after some weeks. The one without voltage pump stays there for months.

4. PIR sensors again give false alerts. I don't know if it's due the heating during the winter, or dirty voltage that the voltage pump outputs.

It could be that I should just change the batteries and reboot all of them, but I haven't got around to do it now. But if you add the voltage pump, make sure to add capacitor to steady the radio power.

Temperature and door open/closed circuit works well. I wish I get the motivation to fix all the above one day soon

Good luck, and report back the enhancements!

Excellent, thank you. It's too long since I've done serious coding, I didn't remember that. atoi -> atol fixed it.

The point in the above is, the Serial.print converts it correct, the atoi doesn't.

Thanks, now it looks different, doesn't still work though. Perhaps the atoi doesn't do longs properly?

Received something of type: 32
V_IR_SEND command received...
V_IR_SEND data invalid: 16236607, ircode: 4294950975

that turns out to be:

echo "obase=16;4294950975"|bc
FFFFC03F

How does it come up with that? Need to hurry to work now, later...

Hi,

I'm puzzled how message receive happens. I am building a infrared transmitter. I decoded the NEC signals from original remote, they look like this (hex): 0xF7C03F. This is power on command.

Now I want to send those signals over MQTT, which mysgw transfers over NRF24L01+ to arduino. But how to convert messages so that they look alike at both ends? is that number too big to send (3 bytes)?

As I send that exact command from arduino:

#define CMD_ON        0xF7C03F
...
send(msg_ir.set(CMD_ON));

it looks like this on MQTT looking from mosquitto_sub:
MySensorsGW/out/7/1/1/0/32 16236607

When I send that back:
mosquitto_pub -h droidcam.ikenet -p 1883 -t MySensorsGW/in/7/1/1/0/32 -m 16236607

the code:

uint32_t ircode;
ircode = atoi( message.data );
...
        Serial.print( "V_IR_SEND data invalid: " );
        Serial.print( message.data );
        Serial.print( ", ircode: " );
        Serial.println( ircode );

prints it out like this:
V_IR_SEND data invalid: 16236607, ircode: 4294950975

the numbers don't match. 16236607 is not the original CMD_ON code.

This is the receive function:

// IR remote command codes
#define CMD_BRIGHTER  0xF700FF
#define CMD_DIMMER    0xF7807F
#define CMD_OFF       0xF740BF
#define CMD_ON        0xF7C03F
#define CMD_FLASH     0xF7D02F
#define CMD_STROBE    0xF7F00F
#define CMD_FADE      0xF7C837
#define CMD_SMOOTH    0xF7E817
#define CMD_RED       0xF720DF
#define CMD_RED1      0xF710EF
#define CMD_RED2      0xF730CF
#define CMD_RED3      0xF708F7
#define CMD_RED4      0xF728D7
#define CMD_GREEN     0xF7A05F
#define CMD_GREEN1    0xF7906F
#define CMD_GREEN2    0xF7B04F
#define CMD_GREEN3    0xF78877
#define CMD_GREEN4    0xF7A857
#define CMD_BLUE1     0xF7609F
#define CMD_BLUE      0xF750AF
#define CMD_BLUE2     0xF7708F
#define CMD_BLUE3     0xF748B7
#define CMD_BLUE4     0xF76897

void receive(const MyMessage &message)
{
  uint32_t ircode;
  Serial.print( "Received something of type: " );
  Serial.println( message.type );

	if (message.type == V_IR_SEND) {
		Serial.println( "V_IR_SEND command received..." );

		ircode = atoi( message.data );
    //ircode = message.data;
    switch (ircode) {
      case CMD_BRIGHTER:
      case CMD_DIMMER:
      case CMD_OFF:
      case CMD_ON:
      case CMD_FLASH:
      case CMD_STROBE:
      case CMD_FADE:
      case CMD_SMOOTH:
      case CMD_RED:
      case CMD_RED1:
      case CMD_RED2:
      case CMD_RED3:
      case CMD_RED4:
      case CMD_GREEN:
      case CMD_GREEN1:
      case CMD_GREEN2:
      case CMD_GREEN3:
      case CMD_GREEN4:
      case CMD_BLUE1:
      case CMD_BLUE:
      case CMD_BLUE2:
      case CMD_BLUE3:
      case CMD_BLUE4:
      {
        Serial.print( "V_IR_SEND code received: ");
        Serial.println( message.data );
        send_ircode(ircode);
        ack_ir_to_controller(ircode);
        break;
      }
      default:
      {
        Serial.print( "V_IR_SEND data invalid: " );
        Serial.print( message.data );
        Serial.print( ", ircode: " );
        Serial.println( ircode );
			  return;
		   }
    }
  }
  for (int i=0; i<5; i++) {
    digitalWrite(LED_PIN, HIGH);
    wait(100);
    digitalWrite(LED_PIN, LOW);
    wait(100);
  }
}

I suppose it has to do with data length and auto conversion of variables. It perhaps worked if I use smaller numbers to set the IR code value. But however, I'd like to understand how this is supposed to work?

BR,
-ikke

PS, this is IR controlled LED light bulb from LIDL, and commands do work with the given codes.

I'm going to test how long such would work with button batteries (CR2032, 3V), and if it's long time, I could make smaller case. So far it's been on about half an year at least with two AA batteries.

One could actually stack e.g. three of those CR2032 batteries and wire them parallel in half of the size casing. Creating like "Shelves" for the batteries in the case, where they could slide in.

No I don't mind, I'm happy if someone finds it useful. Go ahead