Is there anything stored on Gateway's EEPROM? Include sensor issue.

[hek]

The gateway stores routing information in EEPROM.

And yes, a repeater increases complexity and could cause missed messages but not 98%. Try to restart Vera to see if there are any hidden devices.

[MatrixIII]

Hi @hek ,

That didn't work. I restarted the Vera. When devices are deleted from Vera, is the routing also deleted from the Gateway (or is that not an issue even if it is not deleted)? While testing with various sensors using the same boards - if the sensor was originally ID 1 and was a humidity sensor, then its EEPROM cleared, now the same sensor is maybe ID 1 again but is a relay/switch. Even though it was removed from Vera, would there be challenges on the gateway side?

I went ahead and cleared EEPROM of both gateway and sensor and re-flashed them. Removed all related devices from VeraLite and restarted. At this point I have 1 gateway and 1 sensor (relay light switch) in the same room. I have added the capacitor on both radios to rule out communication issues. Sensor and Geteway sketches are untouched other than changing the IP address on gateway.

This is the log from the sensor and gateway.
[[[[Sensor]]]]...
send: 255-255-255-255 s=255,c=3,t=7,pt=0,l=0,st=fail:
req node id
send: 255-255-255-0 s=255,c=3,t=3,pt=0,l=0,st=fail:
repeater started, id 255
req node id
send: 255-255-255-0 s=255,c=3,t=3,pt=0,l=0,st=fail:
req node id
send: 255-255-255-0 s=255,c=3,t=3,pt=0,l=0,st=fail:
req node id
send: 255-255-255-0 s=255,c=3,t=3,pt=0,l=0,st=fail:
req node id
send: 255-255-255-0 s=255,c=3,t=3,pt=0,l=0,st=fail:
req node id
send: 255-255-255-0 s=255,c=3,t=3,pt=0,l=0,st=fail:

[[[[Gateway]]]]...
0;0;3;0;14;Gateway startup complete.
0;0;3;0;5;1
0;0;3;0;5;1
0;0;3;0;9;read: 255-255-255 s=255,c=3,t=7,pt=0,l=0:
0;0;3;0;9;send: 0-0-255-255 s=255,c=3,t=8,pt=1,l=1,st=fail:0
0;0;3;0;9;read: 255-255-255 s=255,c=3,t=7,pt=0,l=0:
0;0;3;0;9;send: 0-0-255-255 s=255,c=3,t=8,pt=1,l=1,st=fail:0
0;0;3;0;5;0

Any ideas? I am a bit puzzled as all of this worked yesterday and me re-flashing the sensor board again and again while testing with other sensors caused the issue. Is there a page where the meaning of the above communications is explained?

[MatrixIII]

Also, before I re-flashed both gateway and sensor, I played with Humidity, Door/Window switch, Light Relay.
I removed all these devices from Vera and restarted.
Then I cleared only the sensor EEPROM and flashed with Humidity sensor again.
When added to Vera, it found 2 Repeaters and 1 Door/Window switch (not Humidity) which makes me believe some ID's are somewhere getting cached.

[hek]

The com failures has nothing to do with Vera/routing. You must solve them first. Try some other powersource/cap size/type.

[MatrixIII]

Thanks, that helps to know that radios are not connecting to each other. I understand they are two different issues and sorry for merging them in the same thread. This all worked pretty good a couple of days ago. I will try other power supply. Come to think of it, I believe I added the capacitors later and it was working better before adding the capacitors. What other cap size I can try? - sorry I am a newbie here. Is the goal to see if the radio has a stable close to 3.3v using a multi-meter? - I am just not sure how to test if its any better (radio stability).

[hek]

I have a pack of different sizes... I usually just test some other size and sometimes switch to a ceramic variant when I see communication failures on my sensors.

But unfortunately I have no oscilloscope to be able to make a fully correct selection. Trial and horror ;)

[MatrixIII]

Thanks. I have ordered some higher uF capacitors and will Test with those when they arrive tomorrow and report my results.

[MatrixIII]

I tried with several.Up to 100uf it didn't help. The next uf up I had 330uf and that worked. Well it now works 95% of the times. I don't know if that high of the capatience will cause issues but it mostly works now.

[RJ_Make]

@MatrixIII Wow that a pretty large cap.. Are these low ESR caps? If not, you may want to pick up a few in various sizes to see if you can get to 99%

[MatrixIII]

I bought the 4.7 uF using the link on the store here. The others I have bought from here http://www.amazon.com/gp/product/B00AZG71H4/ref=oh_aui_detailpage_o02_s00?ie=UTF8&psc=1

[m26872]

Am I the only one experiencing success when using delays in the node software before sending radio messages? Even a hardware guy like me prefer that before starting to change caps.

delay(500);
gw.begin(...
delay(100);
gw.sendSketchInfo(...
delay(100);
gw.present(...

delay(100);
gw.send(...

delay(100);
gw.sendBatteryLevel(....

[BulldogLowell]

@m26872

kind of averse to using blocking code that way... I have used delay() in my setup() functions like that... for the first time I set up the devices.... The caps are really there for the day-to-day reliability of the radio. It is a power hungry little bugger.

You could also do something like this so that you didn't have the delays there once you had the devices set up in vera...

//...
#define FIRST_TIME_SETUP
//...
//...
#ifdef FIRST_TIME_SETUP
#define SETUP_DELAY 500
#else 
#define SETUP_DELAY 0
#endif


void setup()
{
  delay(SETUP_DELAY);
  gw.begin(...
  delay(SETUP_DELAY);
  gw.sendSketchInfo(...
  delay(SETUP_DELAY);
  gw.present(...
  delay(SETUP_DELAY);
}
void loop()
{
  
}