Xiaofan Chen wrote: > On Fri, Jun 20, 2008 at 6:37 PM, Gerhard Fiedler > wrote: >> Xiaofan Chen wrote: >>> What I need is a simple console program to connect to the board and then >>> based on the option, turn on/off the LEDs, etc. >> If you don't necessarily want to write it yourself, you probably can use a >> telnet terminal program and run it with some arguments to run a macro, >> which then runs the TCP commands. Or one of the CLI programs meant to talk >> http. > > If I do not want to write the program, I prefer to use IE/Firefox. ;-) (I may be hijacking this topic, but it seems related and may be interesting to Xiaofan and others, so I'll keep the subject line.) I've got a small network of ZigBee nodes at home that talk to each other and to a PC. The PC side connects via USB with an FTDI virtual COM port, then to a Delphi program under Windows. The remote nodes use PICs connected to XBees. The "glue" layer that specifies sensor information types, commands sent to remote nodes, etc. is my own proprietary thingy I call SprinkleNet (named after my daughter's stuffed giraffe Sprinkles as well as for "sprinkling" the nodes around the house). For various reasons, I'd like to rework the architecture. New requirements, none desperately urgent but all with some specific use-case in mind: - Run as a Windows service, so if the power goes out, when it comes back it can connect again without having Windows auto-login to a user account. - Use a central server app to talk to the virtual COM port, so the PC's radio can be shared among multiple applications without contention for the port. Starting to sound like a network driver. - Add a TCP/IP gateway, so other machines on the LAN (and possibly the Internet) can exchange data with the remote nodes as well. Sounds even more like a network driver. - Add a simple HTTP wrapper, so nodes' status, sensor values, and parameters can be browsed and configured in some generic, low-level way through a browser. - Cross-platform would be best. I'm thinking Python though of course there are many other possibilities. This is what Xiaofan's problem reminded me of. And it makes me feel like there's a lot of wheel-reinventing going on. If you add the possibility of remote nodes connecting via Ethernet instead of ZigBee, it ends up looking like a generic tool to communicate low-bandwidth data (typically single variables at a time) among PC apps and small embedded nodes communicating in a variety of ways. So my first question is - is this already out there? I've looked at SNMP, and it looks fairly similar in some ways, but it also seems huge, monolithic, and possibly incompatible in focus - though I'm not sure. Ideally, I'd picture a combination of firmware and PC-side libraries that would allow you to add a new microcontroller-based node (connected by RS232, USB, ZigBee, Ethernet...) and immediately read its status and tweak its settings via a browser. Then you could also easily write a PC app to provide a more customized UI to it if necessary. The details of node discovery and status tracking, a dictionary of properties per node, and transport would be abstracted. Thoughts? -- Timothy J. Weber http://timothyweber.org -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist