@iotearoa I have that same setup for my gateway and it works. Not sure what version of Arduino IDE you are using, but I use version 1.6.7 (or older) because of an issue with the IDE and the W5100 shield. It's a known issue and there are several threads on the forum about the problem.
The only odd thing I have is it takes about 1-2 minutes for the the ethernet to connect (to my Vera), but after it connects it's all good.
Agreed - updated the subject by removing the "solved"
Turns out there's something in Arduino IDE v1.6.10 that's causing the problem I was experiencing. The GW is working after compiling and uploading the sketch with Arduino IDE v1.6.7.
The problem is repeatable w/ Arduino IDE 1.6.10.
Joe
Everything has been working rock solid with v1.5 on VeraPlus U17. However, I am not having success with v2.0.0 and not sure what else to check or what I might be missing. I've been using MySensors successfully since 2013 and typically able to troubleshoot problems on my own, but could use some help.
The GW is wired to use the Soft SPI and have double checked my wiring against the documentation, but then again it all works fine with v1.5.
Below is the serial output for the W5100 ethernet GW in server mode. The Arduino Uno is restarting continually. Nothing shows in the the log file on the Vera (LuaUPnP.log).
0;255;3;0;9;Starting gateway (RNNGA-, 2.0.0)
0;255;3;0;9;TSM:INIT
0;255;3;0;9;TSM:RADIO:OK
0;255;3;0;9;TSM:GW MODE
0;255;3;0;9;TSM:READY
IP: 192.168.x.x
0;255;3;0;9;Starting gateway (RNNGA-, 2.0.0)
0;255;3;0;9;TSM:INIT
0;255;3;0;9;TSM:RADIO:OK
0;255;3;0;9;TSM:GW MODE
0;255;3;0;9;TSM:READY
IP: 192.168.x.x
.... just repeats
When configuring the W5100 ethernet GW in client mode I am able to get output in the serial console, but still nothing at the VeraPlus or in the LuaUPnP.log file. Sensor 6 is running v2.0.0 as well.
// Controller ip address. Enables client mode (default is "server" mode).
// Also enable this if MY_USE_UDP is used and you want sensor data sent somewhere.
#define MY_CONTROLLER_IP_ADDRESS 192, 168, x, x
0;255;3;0;9;Starting gateway (RNNGA-, 2.0.0)
0;255;3;0;9;TSM:INIT
0;255;3;0;9;TSM:RADIO:OK
0;255;3;0;9;TSM:GW MODE
0;255;3;0;9;TSM:READY
IP: 192.168.x.x
0;255;3;0;9;No registration required
0;255;3;0;9;Init complete, id=0, parent=0, distance=0, registration=1
0;255;3;0;9;TSP:MSG:READ 6-6-0 s=1,c=1,t=0,pt=7,l=5,sg=0:80.2
0;255;3;0;9;TSP:SANCHK:OK
Any help or suggestions are greatly appreciated.
Regards,
Joe
Just to report back my findings .....
After reloading the sketch onto node-3 repeater my RF network of sensors have worked flawlessly. No GW freezes. There were no changes made to the GW or any other node except node-3.
Node-3 went from code 1.4 to 1.4.1 after the sketch reload, but not aware of any changes in 1.4.1 that would have made a difference(?).
So in conclusion the problems were mostly caused by the repeater node-3 and reloading the sketch fixed it.
Joe
"What happens if you send in values with one decimal?"
Around my house I have four separate climate nodes that use the DHT22 sensor. Each node uses the same code and reports temperature with one decimal point (ex: 73.8) and humidity reports with no decimal point (ex: 25). I am not seeing problems with 3 of the 4, but node-3 is the only repeater of the bunch and suspect as it's the last node communicating with the GW when it freezes.
"dtostrf is used to convert float value string. Not sure how it reacts when you specify 0 for precision but I hope it behaves as expected!"
I'll have to investigate further ... although this code works I now question the round() because it's a double and humidity is a float (single precision). Not sure if there's an occasional problem as a result.
humidity = dht.getHumidity();
humidity = round(humidity);
if (humidity != lastHum) {
gw.send(msgHum.set(humidity, 0));
lastHum = humidity;
}
The purpose of the code is to just use whole numbers when comparing previous reading and reporting back to GW. Greater accuracy isn't needed with humidity.
Thanks,
Joe
Thanks for your suggestion. I'll work on using a separate power supply on the GW to see if it helps some.
"Is it always zeroes?"
No, never - only see zero's when GW freezes. Below is another example from the last freeze. Not sure if the problem is with the GW or node-3 which is a "repeater node"? Thinking maybe the repeater is sending a bad/corrupted message to GW causing it to freeze.
50 5:21:33.186 luup_log:107: Arduino: Log: read: 3-3-0 s=0,c=1,t=5,pt=7,l=5:148.0002400000000000000000 <0x2e0fe680>
Thanks,
Joe
Not positive what's going on and hope others could help with troubleshooting. The nano GW locks-up/freezes - it can be seen the Arduino log messages stop in the LuaUPnP.log file on the Veralite. Pushing the "reset" button on the nano clears the condition and everything then works as expected.
The log messages right prior to the GW not working are shown below. Strange behaviour because the node-2 message is received twice via the "repeater node" (node-3) and the second message value is peculiar as it's showing a floating point with many zero's. All other times the sensor value is only sent once and in the proper format (meaning no zero's added).
My sketch only sends the value once and with no decimal value, as shown here: gw.send(msgHum.set(humidity, 0));
50 15:00:14.245 luup_log:107: Arduino: Log: read: 2-3-0 s=0,c=1,t=1,pt=7,l=5:31 <0x2deb4680>
50 15:00:14.246 luup_log:107: Arduino: Set variable: 2;0;1;0;1;31 <0x2deb4680>
50 15:00:14.247 luup_log:107: Arduino: Setting variable 'CurrentLevel' to value '31' <0x2deb4680>
50 15:00:14.247 luup_log:107: Arduino: urn:micasaverde-com:serviceId:HumiditySensor1,CurrentLevel, 31, 119 <0x2deb4680>
50 15:00:16.255 luup_log:107: Arduino: Log: read: 2-3-0 s=0,c=1,t=1,pt=7,l=5:31.00000000000000000000000 <0x2deb4680> ==> last log message from GW
Any idea's as why the value received has zero's added, then causing the nano to freeze up? And, why the message was sent twice within 2secs of each other? It works most of the time w/o problems until this condition occurs.
Regards,
Joe
I am having a similar problem. U15 GUI has the same "Lua Startup Failure" message and Vera says "Choose the Serial Port". However, everything is working fine ... Vera is communicating to the serial port.
I've been using this code from the very start (v1.2 days). I first saw this problem after upgrading to v1.4 from 1.4beta. I was able to fix it though by recreating the gateway device and reconfiguring the serial port in U15.
This morning I loaded "EventWatcher" mios plugin and now seeing the problem again. However, this time I cannot clear the error - even after recreating the gateway device and serial port. But everything is working fine - meaning the serial gw is working.
Not sure what else to try to clear or fix the error messages?
Thanks,
Joe
I am in process of upgrading to 1.4b1 - have most things working. I noticed that my status consistently fails during setup() when presenting sensors AND also never receive a return message from controller after a time request. It's always the same two failures.
Everything works after adding a 100ms delay between calls. Not sure if there's a timing problem somewhere.
Hek - as always thanks for ALL your contributions. 
Joe K.
SERIAL CONSOLE OUTPUT:
sensor started, id 4
send: 4-4-0-0 s=255,c=0,t=17,pt=0,l=15,st=ok:1.4b1 (18848a2)
send: 4-4-0-0 s=255,c=3,t=6,pt=1,l=1,st=ok:0
send: 4-4-0-0 s=255,c=3,t=11,pt=0,l=11,st=ok:LCD Display
send: 4-4-0-0 s=255,c=3,t=12,pt=0,l=3,st=ok:1.0
send: 4-4-0-0 s=0,c=0,t=7,pt=0,l=15,st=ok:1.4b1 (18848a2)
send: 4-4-0-0 s=1,c=0,t=6,pt=0,l=15,st=fail:1.4b1 (18848a2)
send: 4-4-0-0 s=2,c=0,t=8,pt=0,l=15,st=ok:1.4b1 (18848a2)
send: 4-4-0-0 s=255,c=3,t=1,pt=0,l=15,st=fail:1.4b1 (18848a2)
CODE in setup():
// Send the Sketch Version Information to the Gateway
gw.sendSketchInfo("LCD Display", "1.0");
// Register all sensors to gw (they will be created as child devices)
gw.present(CHILD_ID_DHT_HUM, S_HUM, true);
delay(100); // needed otherwise status may come back as failed
gw.present(CHILD_ID_DHT_TEMP, S_TEMP, true);
delay(100); // needed otherwise status may come back as failed
gw.present(CHILD_ID_BMP085_BARO, S_BARO, true);
delay(100); // needed otherwise status may come back as failed & time request doesn't work
// request time
gw.requestTime(receiveTime);