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

Hi home automators,

I thought I share back my case here from thingiverse for those who do want to monitor home with sensebenders and alike. I draw and 3d printed this case for my sensebender and motion + door trap sensors. One of them is running with arduino pro mini, as I didn't have sensebender for that. It's a bit tight for that, but does it's job. Feel free to modify it, and please notify me if you enhance it, so I'll get the enhancements as well

http://www.thingiverse.com/thing:2144946

The angle on the motion sensor allows me to point the PIR range to certain parts where I want it, by placing the case in different ways. Turn to left, right or put it above the door to aim all over.

It's not state of art, but my first 3d drawing and my first arduino job. Code is pretty much copy paste from here. The device sleeps until sleep timer hits, or motion or door trap interrupts the sleep. To get the interrupt for both, you need to leave arduino pin 2 unused from the NRF24L01+ radio, as that reserves the edge interrupt pin from sensebender. There are only 2 edge interrupt pins on those arduinos.

The code is here for the devices, like said mostly copy paste (fork): https://github.com/ikke-t/sensebender

Mysensors GW on raspi forwards the traffic as MQTT forward to my node-red. That then sends gtalk messages of events if alarm is on. I recently also added openhab to listen to MQTT bus just out of curiosity.

My sample is here, unfortunately I didn't see this thread before starting it
It works for temp, humidity, door and motion, and interrupts for door and motion, otherwise sleeps the intervals:

https://github.com/ikke-t/sensebender

There is also pro-mini to code to monitor only door and motion.

This is also for 2.0 MySensors.

Hi,

please share your experience of setting MQTT to work with Domoticz and MS GW. Should the traffic be changed to json format or what's the deal?

I got the MySensors Raspi GW work ok, sending stuff to remote MQTT mosquitto server. The config is this:

./configure --my-gateway=mqtt --my-controller-ip-address=192,168,1,32 --my-port=1883 --my-mqtt-client-id=22 --my-mqtt-publish-topic-prefix=domoticz/in --my-mqtt-subscribe-topic-prefix=domoticz/out --my-rf24-pa-level=RF24_PA_LOW 

Unfortunately it won't show anything in Domoticz. I googled a bit and someone wrote Domoticz reads data in json format? Is that true? Sounds a bit weird in case of MQTT.

I'm rather close now getting things to work, please any tips welcome, too tired to google more tonight...

MQTT part is fine:

$ mosquitto_sub -t domoticz/in/# 
23.0
40

nevermind. now after all upgrades AND BATTERY CHANGE to sensebender it's all fine