Posts made by Dan S.

@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).

@stevebus Since you receive from the sensor and post on the Vera, your gateway loop and radio are working which means the problem is probably not the Arduino. The Ethernet is sending to the vera but not receiving. When you reboot the setup code is run through again, the Ethernet is reinitialized and then it is ok for a short while (If I correctly understood your problem description). Thinking maybe a problem with wiznet board. Do you have one to substitute?

@stevebus There have been discussions here about using UI7 and I am assuming there are some members of this forum who have an Ethernet gateway up and running. If it is a UI7 specific problem, I recommend you start a new entry such as "Help with Vera Edge UI7 Ethernet gateway problem" so that you attract UI7 users with your title.

@stevebus My Vera is on UI5. If you are on UI7 that may make a difference.

@stevebus One other thought. If you hit the reload button on Vera it will give and error message when it executes the lua code associated with the gateway it can't communicate with the gateway. Do you get an error message when you do that?

@stevebus I don't have an inclusion button on my gateway so I can't speak from experience there, but l do know that it sometimes takes several presses of the vera inclusion button and multiple sensor resets to get the sensor included. Have you tried to include a sensor this way via the vera button and not pushing the gateway button?

@stevebus I typically have to hit the inclusion button several times while rebooting the sensor before it is completely included in Vera. I consider that normal operation. Sometimes when the inclusion doesn't work right I delete it and start over. When you change the metric setting did you hit the vera reload button after doing that? You may also need to restart the sensor after that. It's been a while since I changed that setting to what I wanted.

Using standard Arduino internet shield (wiznet) plugged directly into (and powered by) UNO. Radio powered by separate power supply with 3.3v regulator. See picture below. All is in enclosure. The black plug in near the top of the case is the separate radio power.

@stevebus I have basically the same setup as you connected to Vera and it's rock solid. The only difference is that my radio is powered separately with it's own power supply. I think asking the Uno to power both the Ethernet module and the radio is asking too much.

@NeverDie All I can say is that after adding the watchdog I have not had a lockup in 2+ months. Before that, like you, I had random lockups. Based on this positive experience I also added a watchdog to the one repeater I have in my system. Had a brief power outage the other day and everything came back online by itself with no problems.

Would not recommend adding the watchdog until you have a relatively stable gateway, e.g. you have addressed any power/radio issues etc. Otherwise you will have the watchdog constantly tripping in response to issues that are best addressed by other means, i.e., proper troubleshooting.

@BulldogLowell
Here's the code. Should be the same as standard except that I didn't use ip address input.

In
/*
 * Copyright (C) 2013 Henrik Ekblad <henrik.ekblad@gmail.com>
 * 
 * Contribution by a-lurker
 *
 * This program is free software; you can redistribute it and/or
 * modify it under the terms of the GNU General Public License
 * version 2 as published by the Free Software Foundation.
 * 
 * DESCRIPTION
 * The EthernetGateway sends data received from sensors to the ethernet link. 
 * The gateway also accepts input on ethernet interface, which is then sent out to the radio network.
 *
 * The GW code is designed for Arduino 328p / 16MHz.  ATmega168 does not have enough memory to run this program.
 * 
 *
 * COMPILING WIZNET (W5100) ETHERNET MODULE
 * > Edit RF24_config.h in (libraries\MySensors\utility) to enable softspi (remove // before "#define SOFTSPI").
 *
 * COMPILING ENC28J60 ETHERNET MODULE
 * > Use Arduino IDE 1.5.7 (or later) 
 * > Disable DEBUG in Sensor.h before compiling this sketch. Othervise the sketch will probably not fit in program space when downloading. 
 * > Remove Ethernet.h include below and include UIPEthernet.h 
 * > Remove DigitalIO include 
 * Note that I had to disable UDP and DHCP support in uipethernet-conf.h to reduce space. (which means you have to choose a static IP for that module)
 *
 * VERA CONFIGURATION:
 * Enter "ip-number:port" in the ip-field of the Arduino GW device. This will temporarily override any serial configuration for the Vera plugin. 
 * E.g. If you want to use the defualt values in this sketch enter: 192.168.178.66:5003
 *
 * LED purposes:
 * - RX (green) - blink fast on radio message recieved. In inclusion mode will blink fast only on presentation recieved
 * - TX (yellow) - blink fast on radio message transmitted. In inclusion mode will blink slowly
 * - ERR (red) - fast blink on error during transmission error or recieve crc error  
 * 
 * See http://www.mysensors.org/build/ethernet_gateway for wiring instructions.
 *
 */

#include <DigitalIO.h>     // This include can be removed when using UIPEthernet module  
#include <SPI.h>  
#include <MySensor.h>
#include <MyGateway.h>  
#include <stdarg.h>

//watchdog version of gateway
#include <avr/wdt.h>

// Use this if you have attached a Ethernet ENC28J60 shields  
//#include <UIPEthernet.h>  

// Use this fo WizNET W5100 module and Arduino Ethernet Shield 
#include <Ethernet.h>   


#define INCLUSION_MODE_TIME 1 // Number of minutes inclusion mode is enabled
#define INCLUSION_MODE_PIN  3 // Digital pin used for inclusion mode button

#define RADIO_CE_PIN        5  // radio chip enable
#define RADIO_SPI_SS_PIN    6  // radio SPI serial select
#define RADIO_ERROR_LED_PIN 7  // Error led pin
#define RADIO_RX_LED_PIN    8  // Receive led pin
#define RADIO_TX_LED_PIN    9  // the PCB, on board LED

#define IP_PORT 5003        // The port you want to open 
//IPAddress myIp (192, 168, 1, 14);  // Configure your static ip-address here    COMPILE ERROR HERE? Use Arduino IDE 1.5.7 or later!
// Commented out IPAddress to use DHCP router assigned address, Cannot check program with serial monitor with this
//since the DHCP address will not be available till plugged into ethernet.
// The MAC address can be anything you want but should be unique on your network.
// Newer boards have a MAC address printed on the underside of the PCB, which you can (optionally) use.
// Note that most of the Ardunio examples use  "DEAD BEEF FEED" for the MAC address.
byte mac[] = { 0x00, 0xAA, 0xBB, 0xCC, 0xDE, 0x02 };  

// a R/W server on the port
EthernetServer server = EthernetServer(IP_PORT);

// No blink or button functionality. Use the vanilla constructor.
MyGateway gw(RADIO_CE_PIN, RADIO_SPI_SS_PIN, INCLUSION_MODE_TIME);

// Uncomment this constructor if you have leds and include button attached to your gateway 
//MyGateway gw(RADIO_CE_PIN, RADIO_SPI_SS_PIN, INCLUSION_MODE_TIME, INCLUSION_MODE_PIN, RADIO_RX_LED_PIN, RADIO_TX_LED_PIN, RADIO_ERROR_LED_PIN);


char inputString[MAX_RECEIVE_LENGTH] = "";    // A string to hold incoming commands from serial/ethernet interface
int inputPos = 0;

void setup()  
{ 
  Ethernet.begin(mac);

  // give the Ethernet interface a second to initialize
  delay(1000);

  // Initialize gateway at maximum PA level, channel 70 and callback for write operations 
  gw.begin(RF24_PA_LEVEL_GW, RF24_CHANNEL, RF24_DATARATE, writeEthernet);

  // start listening for clients
  server.begin();
  
  //set the watchdog
  watchdogSetup();
  
}

// This will be called when data should be written to ethernet 
void writeEthernet(char *writeBuffer) {
  server.write(writeBuffer);
}

//WatchDog setup function
void watchdogSetup(void)
{
cli();
wdt_reset();
/*
WDTCSR configuration:
WDIE = 1: Interrupt Enable
WDE = 1 :Reset Enable

WDP3 = 1 :For 8000ms Time-out
WDP2 = 0 :For 8000ms Time-out
WDP1 = 0 :For 8000ms Time-out
WDP0 = 1 :For 8000ms Time-out
*/
// Enter Watchdog Configuration mode:
WDTCSR |= (1<<WDCE) | (1<<WDE);
// Set Watchdog settings:

//no interrupt, reset enable
WDTCSR = (0<<WDIE) | (1<<WDE) |

//8 second timer
(1<<WDP3) | (0<<WDP2) | (0<<WDP1) |
(1<<WDP0);
sei();
}



void loop()
{
  // if an incoming client connects, there will be
  // bytes available to read via the client object
  EthernetClient client = server.available();

  if (client) {
      // if got 1 or more bytes
      if (client.available()) {
         // read the bytes incoming from the client
         char inChar = client.read();

         if (inputPos<MAX_RECEIVE_LENGTH-1) { 
           // if newline then command is complete
           if (inChar == '\n') {  
              // a command was issued by the client
              // we will now try to send it to the actuator
              inputString[inputPos] = 0;

              // echo the string to the serial port
              Serial.print(inputString);

              gw.parseAndSend(inputString);

              // clear the string:
              inputPos = 0;
           } else {  
             // add it to the inputString:
             inputString[inputPos] = inChar;
             inputPos++;
           }
        } else {
           // Incoming message too long. Throw away 
           inputPos = 0;
        }
      }
   }  
   gw.processRadioMessage();  
 //reset watchdog
 wdt_reset();  
}

`

@BulldogLowell

I got my basic info and code for a watchdog timer from a pdf by Nicolas Larson titled "Basic Watchdog Timer" at this site:

http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CB4QFjAA&url=http%3A%2F%2Fforum.arduino.cc%2Findex.php%3Faction%3Ddlattach%3Btopic%3D63651.0%3Battach%3D3585&ei=lc6ZVYiiM8PigwTVx4HYCQ&usg=AFQjCNEBfr1yZ_g44GdxaNVmH4zKyTz3nA&bvm=bv.96952980,d.eXY

Yes, I am using the stock gateway code with the watchdog code outlined in the pdf added. His code includes a lot of details in the setup that can probably be streamlined but I liked operating at the elementary level to better see what is going on.

Will post the whole gateway sketch. What's the best way to go about posting it?

It's been over 6 weeks since I added an 8 sec watchdog to my Ethernet gateway (to Vera) and have not had to reboot the gateway since then. Before adding the watchdog, the most it ever lasted before without rebooting was 4 weeks. So for now I have to assume that the watchdog is doing its job and automatically restoring the gateway. If so, then it is providing the gateway dependability that I wanted. Time will tell.

@hek Please disregard my prior message. I looked further and see that the watchdog reset is part of the sensor wait routine and is in the current 1.4 version of MySensors.cpp

@hek I assume this is with the intent to allow a watchdog reset on sensor sketches in the future, but does not apply to the Ethernet gateway sketch?

Added a 8 sec Watchdog to my ethernet gateway and it's up and running now. Time will tell if it cures the occaisional lockups by automatically resetting. Will report back the results

@maha Don't know. But your question did trigger the thought of using milils() to periodically trigger a reboot. Rather than check for a lockup with a watchdog routine I may try just rebooting it at a shorter time interval, e.g., every 2 weeks, than I have experienced the lockups using millis to measure the interval.

@BulldogLowell Any progress on this? My Ethernet gateway is quite reliable after solving power supply issues and implementing soft spi. But about once a month it stops and rebooting it makes it operative again. The failure seems to be periodic--once a month. May be a clue there--something reaching a limit? At any rate, any failure rate where I can't start it up without physically rebooting is too much.

@Corvl Should work the way you described the connection. May be a problem with the onboard voltage regulator which is supposed to provide 5 volt from the 12 volt input. When you connect USB you are inputing 5 volts. I would recommend you try connecting the adaptor via the UNO power input connector with a proper power plug rather than soldering it. I have a 9 volt adapter connected that way to my UNO and it works fine.

@Corvl Just follow the directions for connecting the radio to pins 5, 6, A0,A1 and A2 is indicated in the build instructions on the my sensors home site. You can connected them directly to the top ethernet module pinouts since the pins on the module are identified as the same pins that plug into the arduino. They pass through the same connections and are identified the same as if you connected directly to the Arduino. Just make the software RF24_config.h change specified to make soft spi work

@Corvl I am using the WizNET (Ws5100) ethernet module. Just plug it in to the Arduino like you suggested and everything will be connected properly except for the radio. That's where you have to worry about connecting it properly to the Arduino pins so that it does not use the same SCK/CK/MISO/SO/MI.MOSI as the Ethernet module, hence the use of soft spi so that you can connect the radio toA2, A1 etc. and not interfere with the Ethernet module. Also make sure that you have separate power supply for the radio since you cannot power everything from the Arduino alone.

@olaeke Your occasional stop/restart is most likely related to your power supply. From your pix it looks like you are supplying everything from one power input. The NRF24L01 radio is notorious for causing this if it doesn't have an adequate power supply. Since I put my ethernet gateway and radio on completely separate power supplies, I haven't had a failure since. Before that it would periodically go down and need to be restarted.

You should only need softspi with something like the ethernet gateway as described here: http://www.mysensors.org/build/ethernet_gateway#wiring-things-up

It requires different radio connections in this case so as not to interfere with the ethernet module.

You should not be using softspi with the sensor setup. If you have a check wires message you probably have a radio power problem (did you try a capacitor across the ground/power connections of the radio). Your power supply may not be strong enough to meet the peak power requirements of the radio. Or lastly, the wires are not hooked up properly. Would definitely recommend you not use softspi on the sensor side.

@nanotube My ethernet gateway has a separate 5 volt power supply via the down converter to power the radio and another power supply for the uno/ethernet boards. The ethernet board Uno combination consumes quite a bit of power. Also I don't know if I would call the iPhone charger high quality. Bottom line is I think you still have a power supply issue using one charger for powering everything. Certainly it is good to have the separate down converter rather than tapping off the UNO but you are placing a lot of demand on a single power supply. I think it is best to power the radio separately (but make sure all grounds are common).

I agree that it is likely a power issue. I am using a 9v regulated power supply for the UNO/Ethernet board combo and a separate standard 5v smartphone power supply (regulated to 3.3v by an AMS117) to power the radio to try to eliminate any power issues. Maybe that's why my setup lasts longer between failures.

@BulldogLowell Happend to me recently too, but was a lot longer than 7 days of operation before it happened. Rebooted the gateway and reloaded vera to correct it. Seems like it would be very difficult to track down the cause since it happens so infrequently but the fact that it happens at all is disconcerting.

Check out comments here:
http://forum.mysensors.org/topic/124/ir-remote-control/1

I should have mentioned that the AVR library contains spi.h

When you loaded the arduino ide (the program which you run to compile/upload your arduino programs) it should have loaded some standard libraries. One such library is the AVR libraray which should be located in :

C:\Program Files\Arduino\hardware\arduino\avr\libraries

if you are using windows. So there are really 2 sets of libraries, the standard ones that are part of the IDE file structure and your own personal libraries which are usually located in you mydocuments/arduio folder--these contain the files from mysensors or any others you may download separately.

You need both libraries to compile successfully.

Here are 2 pix of sensors I built using the boards.

The first is a water sensor/alarm which in addition to triggering the Vera controller, will activate a buzzer as a warning of a water leak in the basement water heater/furnace area.

The second is a standard temp/humidity sensor augmented with an Oled display readout. The display and sensor are temporarily hooked up until I decide where/how to mount them.

@Mrlynx

I did use both the c1 and c2 (1uf) caps you supplied on all of the boards I've constructed. I was referring to an additional decoupling cap directly across ground and 3.3v terminals on the radio which is recommended to be at least 4.7 uf in mysensors.org.

Your boards seem to work fine without an additional cap across the radio, and in one test the board worked better without an additional cap. So unless advised otherwise I will dispense with using any additional cap.

I'll get some pix of my completed sensors.

@Mrlynx
I bought 5 of these as kits from the original order and am very pleased with them. Was a little apprehensive about soldering the small smd's for the 5 to 3.3 volt voltage drop down circuit but with a little practice plus the excellent instruction video referenced above, I was surprised at how easily it can be done. Do recommend using chisel point soldering tip.

The boards offer a lot of flexibility for just about any type of sensor--recently completed a temp humidity sensor (which required soldering an additional smd pullup resistor) and also hooked an Oled display to the available A4/A5 pins to display the temp and humidity.

Do have one question. Is a cap needed on the radio? I normally use one but the boards I have built seem to work fine without one (maybe because of the absence of long wire leads and the separate voltage drop down circuit)?

@hek Got it. Thanks. Hadn't thought of that.

@hek Just wondering. Is there something unique about Vera that makes for the plugin providing a sensor node when the sensor first wakes up and communicates? If the plugin could be changed (without a lot of difficulty) to keep the default 255 designation and only hand out a node id when the inclusion process is started it would be more intuitive (at least to me) and potentially reduce node id problems. I don't know enough about the plugin details to know whether this question makes sense.

@hek I take that back after rereading the text. It said the controller assigns the id which is true in the Vera case that is discussed above. My mistake was in assuming that the controller does not recognized the sensor (that it is only communicating with the gateway) until the inclusion process is started.

@hek OK. Thanks for your response. So you are saying that what happened is normal. If this is the case, the description of the sensor id process in mysensors.org is somewhat misleading.

If you are testing sensors that you have not been included, they would already have id numbers. I guess this could cause gaps in id numbers if you don't include them in the order you have tested. To override that you would have to overwrite the eeprom with the id number you want. I found that when I went to include a sensor that had been tested and had id assigned as 4, vera tried to create both a number 3 and 4 node since I had not included the sensor that was assigned id 3 yet. Think Vera got confused. I deleted the false number 3 node in Vera and all was fine, but was curious what caused that. Now I think I know.

@hek It had the node number 4 in eeprom. The eeprom contents were 401 in first 3 bytes. I know they were all 255 before I started. Since I have 3 sensors, 4 would be the right number for the next id. I guess you're saying this shouldn't happen?

When I uploaded an new sensor sketch to my newly built arduino sensor, I noticed the serial monitor showed it communicating to the ethernet gateway and it seemed to have a node id. I checked the eeprom and it did have a node id (I am sure that it did not before the sketch upload). I thought that the id was assigned during the inclusion process and I had not included the sensor in Vera yet. Am I wrong on this?

Something else I discovered in looking at the zero node issue. As soon as I download a sketch to the arduino and the sketch executes, it is given a node id by the gateway--before the any formal include process is started. I thought the node id was generated during the inclusion process. Is this right?

OK I found out what was causing my node zero. I had deleted the sensor from Vera and cleared the eeprom with a generic program I had downloaded from the internet--not the one provided on mysensors.org. Unfortunately the program I downloaded cleared the eeprom by filling it with zeros, not 255 which is the default initial value of each byte in a new arduino eeprom. The my sensors.org program correctly fills all bytes with 255.

So in effect, by filling the eeprom with zeros I had designated it as node zero--live and learn.

Anybody have any insights on what would cause the include process to create a zero node?

Yes, it's back to working now but I still don't know what caused the issue in the first place. I'm certain the on/off tripping was not the result of the sensor sending tripped/untripped messages. Am concerned it may happen again. Need more stability than that for an alarm type sensor.

@Magas:: My other sensors are light and temp/humidity and not motion sensors.

I also want to find out why I keep getting a node 0 sensor on include unless a use a static id. Didn't have this problem before and it may be related to the issue.

I appreciate the suggestions.

No. Only the the gw.begin. It should be (and is) node 3 and sensor 3.0 (and 3.1 if I had a second sensor attached to the sketch.

Tried gw.begin(NULL,3); Gave me a node 3 and sensor 3.0, but surprisingly also gave me a node 0 and sensor 0.0. I deleted node 0 and sensor 0.0 from Vera. Node 3 and sensor 3.0 appear to be working fine along with the sensor itself. All sensors appear to be working normally as before.

I cleared the eeprom and tried to reinclude the sensor and I keep getting a node of 0 rather than 3 (this is my third node). which I got when I previously included it. Don't know what is causing the node 0 assignment.

The code is below (I assume you meant post rather than upload):

#include <SPI.h>
#include <MySensor.h>

#define DIGITAL_INPUT_WATER_SENSOR 3 // Digital input did you attach your soil sensor.
#define INTERRUPT DIGITAL_INPUT_WATER_SENSOR-2 // Usually the interrupt = pin -2 (on uno/nano anyway)
#define CHILD_ID 0 // Id of the sensor child

MySensor gw;
MyMessage msg(CHILD_ID, V_TRIPPED);
int lastWaterValue = -1;
//beep delay
unsigned char delayms = 200;
// declare pin # for buzzer analogwrite output:
int buzzpin = 5; //can only analogwrite to 3, 5, 6, 9, 10, and 11

void setup()
{
gw.begin();

// Send the sketch version information to the gateway and Controller
gw.sendSketchInfo("Water Alarm Sensor", "1.0");
// sets the soil sensor digital pin as input
pinMode(DIGITAL_INPUT_WATER_SENSOR, INPUT);

//declare the buzzer pin as output
pinMode(buzzpin, OUTPUT);

// Register all sensors to gw (they will be created as child devices)
gw.present(CHILD_ID, S_MOTION);
}

void loop()
{
// Read digital soil value
int WaterValue = digitalRead(DIGITAL_INPUT_WATER_SENSOR); // 1 = Not triggered, 0 = In water
if (WaterValue != lastWaterValue) {
Serial.println(WaterValue);
if (WaterValue==0)
{
Serial.println("no water");
gw.send(msg.set(0));
}
else
{
Serial.println("WATER!");
gw.send(msg.set(1)); // Send tripped when water detected
//sound alarm with endless loop
alarm();
}
lastWaterValue = WaterValue;
}
// Power down the radio and arduino until digital input changes.
gw.sleep(INTERRUPT,CHANGE);
}

void alarm()
{
while( 1 ) // endless loop
{

analogWrite(buzzpin, 20); // Almost any value can be used except 0 and 255
// experiment to get the best tone
delay(delayms); // wait for a delayms ms
analogWrite(buzzpin, 0); // 0 turns it off
delay(delayms);
} // wait for a delayms ms
}

I took the Rain and Moisture sketch an modified it by reversing the interrupt so it triggered when water was detected rather than the no water trigger. I also added a buzzer function that was called when the interrupt was triggered. Used this as a water detector near the basement water heater. Also set Vera to email me if moisture was detected.

All went well for several days, Vera showed the water sensor as armed but not triggered. Then suddenly I started receiving multiple Vera emails notifying water detection. Checked Vera and found that the water detector trigger was being triggered on and off and if I set it to off, it triggered on again. I verified that the sensor was not detecting water and even unplugged the board but yet the node was indicating that it was being updated when the trigger status changed.

The sensor sketch as I modified it would go into an endless buzzer loop if triggered, i.e., it could not go back to untriggered status unless it was reset. So I know it was not triggered. There was no buzzer when Vera reported the triggers, and I tested and verified again that it would go off if water was detected by holding a wet finger on the sensor.

I am at a loss to explain the cause of Vera suddenly reporting multiple changes in the trigger status of the sensor even though no status change was detected or reported by the sensor.

Would appreciate any suggestions on how to proceed. I have since deleted the node/sensor from vera and will include it again from scratch to test further.

@korttoma I think I am using a different light sensor then you (AmbiLight Sensor). For my sensor it was recommended to hook a 100k resistor in series with the output to improve low end sensitivity. You may want to try that on your light sensor. Seemed to work for me. They also said if you want to improve the top end (readings max out) use a resistor in parallel with the output.

@BulldogLowell That's exactly right. You stated it more clearly than I did. It's not a problem if you're careful in how you set up your if test but its does warrant a warning to be careful in that regard to anyone using mills() for timing their sensor reads.

Revised my light sensor sketch to give it repeater capability. The key is in the millis() function which keeps track of processing time. Did some research and learned that because it is an unsigned long data type it will rollover to zero after 49 days! So unless you write the comparison statement in the if clause a certain way it will fail after 49 days. If you do a search on how do you reset millis() you will learn how to set up the if clause to take care of rollover (you can't easily reset millis and you shouldn't since it will cause major problems for other libraries that use it).

I could not find any description in http://mysensors.org/build/sensor_api#sensor-nodes on how to do this. I do think a sample combined sensor/gateway sketch would be very useful.

I have not tested my revised light sensor/repeater sketch (it does compile). Will report back on results of testing.

@tbowmo Sounds like that would work. Will try it out.

Is it best to use the radio with the separate antenna for the repeater?

My house is wooden frame with plasterboard walls so cross floor/wall commo is OK. My one sensor on the main floor is a light sensor and is not battery powered. But don't you still need it to sleep between light readings? How do you make a combination sensor/repeater? The sketch for the repeater indicates that the repeater has a unique node declaration. that is different from the sensor node declaration

@BulldogLowell Don't think I can move gateway to middle floor--the only internet connections (other than wireless) that I have are in the basement and everything including most of the basement is finished.

Did not add repeater capability to existing sensors. I thought repeater has to be separate from sensors since they can never sleep?

Now that I have a very stable ethernet gateway, I am beginning to expand my sensors. The gateway is in the basement level of the house next to my VeraLite and communicates very well with a humidity/temp sensor on that level and a light sensor on the next level above.

Looking for advice on the best way to get coverage on all levels of the house (2 living levels above the basement plus the attic). I don't think I can get that coverage without at least one repeater. Did have a little trouble communicating to the next level above till I tilted the gateway radio antenna from vertical to about a 45 degree angle. Maybe should have it horizontal to increase up/down range.

Looking for any suggestions/advice/ideas on how best to get whole house coverage with minimum extra hardware and also antenna positioning advice

Thanks in advance.

Converted my Ethernet gateway to a DHCP connection. Went without a hitch and is now listed in my Netgear's list of attached devices and operating normally. So far, so good.

OK. So if I use DHCP and tell my router to reserve a particular address for my Gateway, operationally I won't notice any difference from directly assigning it as it is currently set up. But if I use DHCP I will be able to see it listed under "attached devices" on my router which is an advantage. With the current assignment, the router doesn't "see" my gateway. So I think I will try the DHCP route as an experiment because I like the idea of the router centrally managing and recognizing all of the network clients.

@Anticimex Is there any advantage to using DHCP?

@BulldogLowell Once you sent the pin definitions in RF24_config.h as you indicated you connect the MOSI, MISO and SCK pins of the radio to A0,A1 and A2 on the Ethernet shield/UNO as niccodemi indicated. The other radio pins remain connected as they were originally.

Would like 5 too, if still available.

@BulldogLowell You are not using the antenna version but since I am, I used an entirely separate 5 volt wall wart supply to power the radio through the AMS117--did not go through the UNO power as it looks like you did in the pix. Just need to make sure that all the grounds are common if you do like I did, i.e. connect the ground from the separate supply to the UNO/shield ground in addition to the AMS117 and radio ground.

@niccodemi Very good description of what needs to be done. Only addition I would make is that you have to undo the changes you made other than to the gateway sketch when you go back to creating sensors. May be just as easy to reload the library to do that.

I used a standard (cell phone type) 5V power supply and with the AMS1117 (listed in hardware) to knock it down to the 3.3V required by the radio. If your gateway (or sensor) works for a while and then stops and then will start again when plugged back in/rebooted you can almost bet it's a radio power problem (if you are already using soft SPI for your gateway).

Use the latest sketch from the 1.4.1 library for the gateway. The soft SPI stuff is included in the latest library. I just needs to be turned on by some include statement changes in the gateway and RF24_config.h. It requires changes in the radio wiring to the arduino also. I used the instructions provided by Anticimex that are contained in the link I posted above. It's a long thread but the instructions are in there. Probably needs to be broken out as a separate how to posting.

Oh, and make sure you use 1.4.1 library.

Might want to check:http://forum.mysensors.org/topic/466/ethernet-gateway-problem.
I had the same problem but after addressing SPIO and radio problems it's been rock steady over a week now. Had to use separate power supply for the antenna version.

@karenbobiv Congratulations!!!

Gateway and sensors updated. Running fine.

Since it is a change to Mysensor.cpp, then I assume all sketches are the same but every sketch that uses Mysensor.cpp (which is all sensors and the gateway) need to be compiled/uploaded again after downloading the new library?

I always interpreted the GW startup message to mean that the radio part of the gateway is working. So you've made good progress. When you start it up and plug it into the network, what happens when you hit reload on Vera. If it reloads with no errors, I always took that to mean that the ethernet part is working and the gateway is talking to Vera. For push the include button on the vera plugin and for as long as the inclusion person lasts continue to start and restart the sensor until the plugin says it is detected. Sometimes takes a couple of tries. But your posting of the sensor messages says the gateway is not talking to the sensor. But first you need to get it included and it may take a few tries. Hope this helps.

@niccodemi I am using a genuine arduino uno and arduino ethernet shield which is similar to the one you reference, but don't think that should make any difference if you are using soft spi. Currently I have a light sensor and a temp/humidity sensor reporting to the gateway and all are working fine. Plan to expand more now that it is working so dependably.

@niccodemi I should mention that in the new master there is a comment in the gateway code that says:

"Remove UIPEthernet include below and include Ethernet.h." In other words the default is not Wiznet. If you don't change the default (which I didn't at first) then you will have a commo problem since it is for ENC28J60 shield.

@korttoma Took your advice about including to get node and it worked! Also when the node appeared in Vera I noted my termp sensor was now reporting in farhrenheit!

Thank you!

Just noted that when I included the temp/humidity sensor the sensors showed up with their readings, but I did not get a separate Arduino node for the temp/humidity sensor in Vera like I did for my light sensor. This may be related to the temp reading in centigrade problem. Is there a way to create the Arduino node without going through the include process all over again?

I used these instructions from anticimex:

Patch RF24_config.h to enable softspi, uncomment
//#define SOFTSPI
and select pins to use with
const uint8_t SOFT_SPI_MISO_PIN = 15;
const uint8_t SOFT_SPI_MOSI_PIN = 14;
const uint8_t SOFT_SPI_SCK_PIN = 16;
The setting above mean MOSI on A0, MISO on A1 and SCK on A2 on an Arduino Nano.

So when you use soft spi and and change the statements in RF24_config.h as above, the wires for mosi, miso and sck as shown in the ethernet radio diagram are changed and go to A0, A1 and A2 respectively on the UNO (be careful not getting miso and mosi mixed). you need to get the gateway started message from the serial monitor rather than the check wires message to proceed. Recommend you take a break and hit it tomorrow--I know how I got when going though this. Mine is still working going on over 3 days now without a hitch. Also make sure you have the ip and port address entered in the advanced tab of the plugin on the vera when you are ready to finally hook it up, otherwise vera will give you a luup error.

Thank you all--still going strong without any hiccups.

At any rate, those are library errors so that's why suggested you download and use the latest basic library.

@jocke4u The biggest number that can fit in the register that holds the light sensor value is integer 1023 (based on the register size). Given the range of 0-1023, the formula will return a value of 1 to 100. For my light sensor I changed it to a direct read with no modification, because I like you was more interested in accuracy for lower light level values. Maybe in direct sunlight you would get 1023, but indoors my max is about 500.

My temp reporting on my temp/humidity sensor is in centigrade. Made sure that imperial was selected in Vera gateway plugin and rebooted sensor, but still get centigrade. From the code, it looks like the sensor is supposed to query whether metric is true from the controller on startup. Saw that this was an issue on previous thread and there was a correction made. Am running 4.1 plugin. Was correction before or after plugin was first created, i.e., do I need to load newer plugin?

@karenbobiv When I redid my gateway, I just downloaded the latest version of the regular my sensors library which already includes all that is need for soft spi and used the ehternet gateway sketch from the library. Did not use the "fix for W5100." Did not move the gw.begin. Need to include Digital.IO in gateway sketch as you did. Also make sure you define the include statement for using the W5100 version of the ethernet (if I remember right the other one is the default). Also note that the some of the wiring of the radio to the UNO is different in soft spi--see anticmex's directions which include some numbers that need to be changed in the radio file plus defining soft spi as you did.

After over 2 days of continuous operation without a hitch, I believe all my gateway problems (all of which related to the radio) are solved. If I had known early on that the radio libraries are set up to stop if an error is detected in radio operation, I would have focused on it from the start.

In the interest of others having similar problems, the successful UNO/Ethernet shield gateway includes:

Soft SPI--enabled using the latest iteration of the mysensor library and Ethernet gateway software which includes the proper RF24 componenets and DigitalIO library required for its implementation. See anticimex's instructions above on how to implement. Think this was the biggest factor in stability.

Separate 5 volt power supply fed through the AMS1117 to provide 3.3v power to the radio (with common ground to UNO/shield). The onboard 3.3V feed cannot be depended upon to provide enough peak current to power the radio.

Also downloaded and used latest Arduino IDE 1.5.8

Finally I can move on to sensor building! Thanks for all the help provided by this forum.

Going on 27 hours of continuous operation of the ethernet gateway. Close to declaring success, but having been bitten before....