@John said:
@tortoisedoc The solution then would be build one with a crystal, or keep on using the lower speed. I personally had no problems with data running at 57k
@John I will definietly keep the 57 K ; it should be enough as the data transfered is minimal. I plan to add another 5 sensors at least, but I believe it should be ok.
@John both board and FTDI are from sparkfun...I believe that is the official maker? But yes, this is exactly the same type of problem I have.
@John Okay! Making progress here; after digging and digging, it appears my FTDI module is funky; as in, 115200 Baud seem to somehow be a problem for it.
I made a quick test sketch where arduino increases a counter and writes out the current value, and i have the possibility to reset the value (between 1 and 9). Well, it works properly only up to 57600 baud. Weird. I will test a version of the mysensors @ 57600 Baud now.
EDIT AND IT WORKS! COME ON :D!
This is interesting indeed. I wonder how it comes baud rate 115k fails the FTDI (note : both on PC AND RPi)...
@hek : it happens that I have currently the same setup (3.3v mini pro as serial gw via FTDI); and am suffering from exactly the same symptoms (no reaction when I push commands to the GW). Reception, however, is ok. I plan to add a capacitor for the ripple; but given incoming reception is ok, I doubt it will make a difference?
Needless to say that uploading the sketch works fine, and that upon writing the TX led flimmers.
EDIT : nevermind, solved.
@John I think I just found something interesting here, which might actually match my case:
[quote]
I've tried two different pro mini 3,3v boards, and the SerialGateway does not respond to serial commands on them. I expect 0;0;4;4; to reply the firmware version of the serial gateway. And it works fine on non-3,3V-pro-mini. The vera lua script is doing the same on startup:
[/quote]
from :
http://forum.mysensors.org/topic/66/unable-to-use-the-serialgateway-code/4
I will dig a little into this before performing more tests.
@John said:
@tortoisedoc and @ceburge The builds on the build server are still test builds regarding discovery and driver web front end API. They are getting more stable but is still a work in progress. The builds which are following up are tests to test the progress of the current development roadmap regarding these.
This is a known issue and am working on it while the development progresses.
Excuse for any inconvenience, hope to have this functionality done asap.
P.S. I'm looking into the possibility to also have the node address requests being passed to the discovery collection page, all though it is a complete different internal process trying to make it coherent.
Sounds great !
Thank you for your efforts!
@John said:
@tortoisedoc The only thing i see is a gateway ready message, i do not see any node presenting or asking for a node address. I suspect that this information is also not available in miniterm. If it is, you have to try again without miniterm cause this then is interfering.
@John Ok, here more logging:
appLog.txt
There is actually data coming in - but the visual part is empty both in the driver's section as well as the "new" section for non-discovered devices.
PS I tested this in Chrome as well as in Firefox;
and the result is empty : 
@John said:
@tortoisedoc Are you able to use the node assignment?
Unfortunately not.
See here: appLog.txt
At this point, im starting to suspect about the PI. The miniterm shows correctly the gateway startup tho.
@John thanks for the fix, will test it later today. Is the latest build still good to go?
@John Okay. Seems we have something here now; see the attached log here:
in particular :
2014-12-15 21:55:59,811 [USB-discovery] INFO org.pidome.server.system.hardware.drivers.Drivers - Something went wrong width the hardware: MEthod does not support NID to request driver.