@tekka Thanks! Exactly what I needed

Is there a list of the features of 2.0 that are not available with 1.41 which would help be to decide when to upgrade to use them?

My Mysensors network with Vera controller constructed with 1.41 library has been operating very reliably for almost 2 years now. I have been very pleased with it. I recently added an IR emitter/dc relay node so I could control my stereo receiver and HD FM tuner. The relay is to turn on and off a bluetooth connection between the Receiver and a recently acquired Amazon echo Dot which communicates with Vera via a separate HA bridge. Having voice control over on/off sensor functions is a great advantage.

So, given my current situation, would like to know if there are enough advantages to 2.0 to warrant me updating my gateway and all the associated Mysensor nodes or should I leave well enough alone and enjoy what I have under 1.41? Would like to know any specific advantage an update would incur.

I should add that I use a vera scene to turn the receiver on and select a particular preset for the Hd FM tuner. I just select device off for the receiver in vera to turn everything off.

Here's the code you asked for. Turns receiver on and off and sends preset number for either of 2 stations that are on my FM HD tuner attached to the receiver. I put the hardware with the ir transmitter in the cabinet containing the receiver and tuner. Works great.

/**
  *The code for discret on/off for my receiver could not be found in any of the online listings.
  *The code on line showed 46 and 47 for on and off respectively. Made an error in decoding from hex
  *that resulted in turning off the receiver. Thus I discovered that the on off codes for my receiver
  *are 93 and 94 respectively.
*/
  
#include <MySensor.h>
#include <SPI.h>
#include <IRLib.h>

#define NumChildDevices 2

typedef struct IRCode {
  IRTYPES brand;
  unsigned long onIRcode;
  unsigned long offIRcode;
  unsigned int bits;
} ir;
  
ir childIR[NumChildDevices];
IRsend iremitter;

MySensor gw;
MyMessage child1Msg(1, V_VAR1);
MyMessage child2Msg(2, V_VAR2);

void setup() {
  //specify node 7
  gw.begin(incomingMessage, 7);
  gw.sendSketchInfo("Radio IR", "0.1");
  
  // Initialize children devices  
  // 1. Sony Receiver: On power on, off power off
  gw.present(1, S_LIGHT);
  childIR[1] = {SONY, 0xBA0C, 0x7A0C, 15};
  
  // 2. HD Tuner: On select preset 4, off select preset 1
  gw.present(2, S_LIGHT);
  childIR[2] = {SONY, 0xC0BC8, 0xBC8, 20};
  
}

void loop() {
  gw.process();
}

void incomingMessage(const MyMessage &message) {
  
  //Determine the child device
  uint8_t child = message.sensor;
  
  //Get the relay status for the child device
  int incomingRelayStatus = message.getInt();
  
  //Emit the appropriate IR code to the child device
  iremitter.send( childIR[child].brand, incomingRelayStatus == 1 ? childIR[child].onIRcode : childIR[child].offIRcode, childIR[child].bits);
  //If sending to HD tuner, add "enter" code after preset code
  if (child == 2){
    //Don't send the enter command immediately after the number. Must wait a bit
    delay(500);
    iremitter.send (SONY,0xCBC8, 20);
  }
}```

@Tore-André-Rosander Yes, Will be glad to. Will post it later this evening.

Re: [IR Switch for Luminara Candle Automation (repost with video](photos and final sketch))
@blacey Wanted to thank you for your sketch outline for 2 IR devices. Used it as model to create my two IR devices. One to turn stereo on and off and the other to switch between two preset stations. Only difficulty was finding the discrete on and off codes for the receiver which the remote for the receiver does not have.
Works great! Only problem I had with what you called your quick and dirty example was that the call to gw.begin did not include the incomingMessage argument. Easy fix. Overall the example was a great help.

I ordered an Echo Dot from Amazon. Won't be shipped till July, but hope to integrate it with my Vera controller to activate both my Vera z-wave and and Mysensor devices via voice control using the device.

I had that same problem, but then I carefully checked my address entry on the site and found I had made an error. Once corrected it processed OK.

Had some issues with the operation of my parking sensor which I resolved and now it seems to be working perfectly.
Thought I would pass on what I did in the hope that it might help others having the same problem.

There were 2 issues.

The first issue was random lighting of the led ring after the car was pulled out of the garage and the door was closed. My guess was that the sensor, in the absence of having the solid car to bounce off of, was picking up stray sensor ping echoes from other objects in the garage. Checking on internet revealed that others using the HC-SR04 Distance sensor had experienced this problem. Checking further, I discovered that there were updates to the NewPing library, the latest being version V1.7 and specifically that V1.6 included an update to the sonar.ping_median function used for distance measurement in the parking sensor code. The MySensors library current version is V1.5. After I updated to V1.7 I no longer had random readings when the car was not in the garage. First problem solved.
bolded textSo I would recommend updating to NewPing V1.7.

I then reinstalled the parking sensor in the garage for further testing. Everything appeared to be going well but when I returned to park my car in the garage later in the day I was greeting by the led ring flashing bright red with all its leds which is supposed to be a panic signal that the car was parked as close as it should be. But I had just entered the garage and was not anywhere near the range of being parked. Took the sensor down and brought it in for testing. Found out that everything worked fine except if it was left on in the condition where it was not sensing any object in range for an extended period of time, it went into the flashing led mode. Too me it had the symptom that given enough time, a variable was being overrun (an integer variable exceeding its capacity). Checking over the code I noted the following lines:

if (displayDist == 0) {
// No reading from sensor, assume no object found
numLightPixels--;}

So everytime the displayDist = zero (and it is zero when no object is detected) numLightPixels is decremented by 1. So if there is no car in the garage (and since I had fixed the random detection problem), the sensor returns a steady stream of zeros to indicate there is no car in the garage and the numLightPixels is decremented with no limit. Given enough time it will eventually decrement to -32,768 at which point it rolls over to +32,767 and at that point the red leds will all flash in the panic mode. To fix this, I changed the above code to read:

if (displayDist == 0) {
// No reading from sensor, assume no object found
//Make sure you don’t go below zero
if (numLightPixels>0) {
numLightPixels--;}

So now it won’t decrement numLightPixels below 0. That solved the problem.

There is also one related efficiency change I made. At the beginning of the loop there is code to skip 10 zero readings:

if (displayDist == 0 && skipZero<10) {
// Try to filter zero readings
skipZero++;
return;
}

I changed that code to skip all zero readings if numLightPixels is less the one (i.e., 0), since if numLightPixels is at zero all of the pixels are already off and if the sensor continues to read zeroes, they should all be skipped (don’t go through the rest of the loop) until a nonzero reading is obtained (something is found).

if (displayDist == 0 && numLightPixels<1) {
// Filter zero readings
return;
}

Mounted the sensor in the garage again and now everything works perfectly. Hope this helps someone else.

@msebbe Glad everything worked out well for you. Your comment made me think about changing mine to 800 also. From what I could glean from looking on the internet, 800 is more appropriate for newer devices, e.g., the led ring. So I am going to change to 800 also. Thanks.

Have one more proposed change to parking sensor code. Noticed that even when I was standing still there seemed to be quite a few changes in number of leds lit. In checking the internet, learned that variability of distance readings was particularly a problem for those using the sensor in robots. The preferred solution seemed to be taking the median of several readings.
See:
http://blog.microcentertech.com/2013/05/minipingbot-construction.html

Fortunately, the Newping library has a built in function to address this issue by taking the median of several readings (default = 5). So I modified the code as follows:

// int fullDist = sonar.ping_cm(); original code
unsigned int fullDist = (sonar.ping_median() / US_ROUNDTRIP_CM);
// Get average distance for 5 pings, convert to cm
// US_ROUNDTRIP_CM = distance sound travels in cm/sec

As a result, the jumping around of the number of leds appears to have decreased significantly and the response is much more stable. Hope this helps others.

Was checking out operation of parking sensor after changing MAX_Distance to 200 from original 100--wanted earlier start from wall. Also changed the Panic distance to 60--more space from wall during testing. Noticed that the led ring did not start from 1 pixel and increase from there as the distance closed. It started at 7 lit pixels. Examined the formula for newLightPixels and made a change which corrected this.

The current newLightPixels formula is:

int newLightPixels = NUMPIXELS - (NUMPIXELS*(displayDist-PANIC_DISTANCE)/MAX_DISTANCE);

The portion of the newLightPixels formula (displayDist-PANIC_DISTANCE)/MAX_DISTANCE) is intended to map the interval between PANIC_DISTANCE and MAX_DISTANCE to the interval (0,1). In other words, when you are at the PANIC_DISTANCE it should calculate to 0 and when you are at MAX_DISTANCE it should calculate to 1, advancing linearly between the two values as the distance closes and vice versa. Clearly when a displayDist = PANIC_DISTANCE, the numerator of the division of the formula calculates to 0. However when displayDist = MAX_DISTANCE, it does not calculate to 1.

In order to correct this I changed the portion of the formula to:
(displayDist-PANIC_DISTANCE)/(MAX_DISTANCE-PANIC_DISTANCE))
Note the only difference is subtracting the PANIC_DISTANCE from the MAX_DISTANCE in the denominator. Now when the displayDist = MAX_DISTANCE, the formula returns the value 1. So the proposed new newLightPixels formula is:

int newLightPixels = NUMPIXELS - (NUMPIXELS*(displayDist-PANIC_DISTANCE)/(MAX_DISTANCE-PANIC_DISTANCE));

I tested it both by plugging values into the formula and in operation of the Parking Sensor. Now the leds climb smoothly from 0 as you enter the MAX_DISTANCE zone. rather than starting at some number other than 1 (7 in my case).

@korttoma link text

@korttoma The online documentation I read said:

"The pin labeled PWR +5V is the power input pin, and should be connected to a suitable power supply. An input voltage of 5 V is used to power the ring, and each LED on the ring can draw up to 50 mA at 5 V when outputting white at full brightness. That means the ring could draw up to a maximum of around 1.2 A."

Although Hek's code does not operate all the pixels at full white brightness, I decided to play extra safe and use a 2A supply.

@chilump I hope so since that's exactly how I intend to use it. I will wire the arduino and the led ring directly (and separately ) to the adaptor. I don't want to have to deal with 2 separate power supplies.

@chilump I am moving from the prototype setup to the garage setup. The first picture shows the LED ring connections. I used solid copper wire because it facilitated what I wanted to do. I squeezed the ends of the wire to flatten them and bent them 90 degrees to make it a bit easier to solder to the solder pads on the led ring. The pads are marked D1,5V,GND and D0. D0 is not used in this application. These are the most difficult connections to make.

```
I mounted the ring on a square piece of 1/4 in particle board, drilling holes to feed the wires through. It only has a primer coat on it in the picture.

I will connect a 100uf between the 5v and ground connectors behind the board so it cannot be seen and then mount it on the garage wall.

Hek's 22uf recommendation is probably good enough, but in reading about led ring applications an the internet 100uf was recommended for Adafruit neopixel rings. How much you need is dependent on the led intensity and how rapidly the signal will be changing--for this case 22uf should be ok.

I put the distance sensor in one of the standard cases.

As far as wiring to the Arduino is concerned Hek spells all that out on the mysensor home page if you click on parking sensor. DI of the led ring goes to D4 on Arduino, Trig and echo of the distance sensor got to D6 and D5 of the Arduino respectively. Don't wire the led 5V to the Arduino. It should come directly from the power supply since when the leds are full on they can consume more power than the Arduino can supply. I plugged the Vcc and grnd connections from the distance sensor directly into the Ardouino's pins that were so marked. To be on the safe side I plan on using a 5V 2A DC power supply for this application. All grounds must be common.

@hek Received my LED ring in the mail over the weekend. Hooked it up and ran your code. Everything looks to be working great, including the timeout code. Now need to mount and test under real world conditions, i.e,. in the garage with the car. Has anyone done that yet?

@m26872 Fortunately my experience with VeraLite is quite different from yours. I've been using it for a few years with a variety of z-wave sensors and most recently with a mysenors Ethernet gateway and multiple sensor nodes. Never had an issue with the VeraLite. Did have some initial problems setting up the gateway but they weren't Vera problems. Gateway and sensors have been going steady without any intervention from me since end of May this year. Even with an intervening power outage, Vera, the gateway and associated sensors all came back up without and issue.

@sundberg84 I approached it from the other direction, i.e., I took the SoilMoistSensor sketch and added a buzzer function to it. The basic sketch sleeps when no water is present and an interrupt that is triggered if water is detected. I used the water level sensor but could have just as well used two bare wires close together like you did (probably would be better and certainly cheaper if I did--the water level sensor was overkill for this purpose).