BTW, I like how you both made a case for it. Very nice!

Wow, great! Its alway nice to see others using my work too. Your code improvement seem to be very helpful too. I have most recently also integrated this directly into my gateway build (see here). I am still struggling with code there though.

@NickBuilder said: Thank you @mfalkvidd for the very educational description. I thought that the check could have been as you described but I felt that it was too crude and simple. This doesn't seem to be the most typical use of "exclusive or" but I guess it does the job. There are more advanced ways. This scheme will not detect two bit errors in the same group (even or odd) and it can only detect errors, not correct them. But without knowing the reasoning behind the design it is impossible to say if it was a bad choice or not. Is it common to only include part of the transmission packet in the parity check? I would have assumed that the nib (Nib4) should be part of the bit check and that the parity bits would then be set or not set so that the complete packet is confirmed. Yes, it is common to exclude things. What things depends on the use case. From what I understand, the exact same message is always sent three times. If the z-bits were included in the checksum, a new checksum would have to be calculated for each time the message is sent. That would probably have a negative effect on the communication speed and would add complexity to the solution without adding any real benefit. If the checksum bits themselves (C) were included in the checksum calculation they would affect the checksum so the checksum would change so the checksum would have to be calculated again which would cause the checksum to change so the checksum would have to be calculated again and so on.

@C.r.a.z.y. I'm sure there's a way to use it without the MySensors stuff, but that's a little bit out of my scope. I'd imagine it would just involve writing up an Arduino sketch for a device with a 433Mhz transmitter and receiver and have it listen for serial commands. OpenHAB can send whatever you want to serial. As for transmitting, it seems to work with the arduino sketch I posted earlier, but I still need to put some kind of protection in place to prevent a feedback loop since it also listens for codes. When I make it transmit, it gets stuck sending and receiving the same code to itself. A basic example of testing the transmit (I'd unplug the receiver if you haven't fixed the loop issue) would be: rule "two-outlet ON update" when Item two_outlet_ON received update if(two_outlet_ON.state==ON) { sendCommand(Arduino, "105;0;1;0;24;" + CodeToItemsMap.get("two_Outlet_ON") + "\n") OUTLET1.state = ON } end This isn't as clean as I'd like, since I'm still basically defining the command with the exception of the code itself. But it does work!

@Heinz No need to write the code for me, I've done most of the work already but the only problems I have now is that with the sketch from this thread I can't control the 3 switches I have and the two temperature sensors are not detected by the Vera interface (I guess they aren't initialized correctly ?). I would appreciate if you could take a look at it.

@justinthegeek Also 1.4

@steets250 said: Instead of storing raw codes, you could also try using pronto codes for some of your IR devices. The pronto codes will take up less space than the longer raw codes. First, the long form Pronto codes and the irRemote library raw buffer both use 2 byte values to store on and off times, so they should in most cases be approximately the same length (Pronto codes have 8 bytes of additional header). (Of course if you stored Pronto codes in hex format they'd be much longer). And in order to use irRemote to send the pulses, it will need the raw buffer values in its expected format. I suspect one could translate stored Pronto codes into raw values in the sensuator node before calling the library, but if the Pronto code is no shorter, why not simply store the raw codes instead? It might even be possible to modify the irRemote library to send values using timing directly from PROGMEM, and not even need the RAM to buffer the raw codes (when only sending).