On Thu, Jan 2, 2014 at 7:49 PM, Colin Reese <[email protected]> wrote: > The more intelligent way would be to bring it up and push a notification to > the server telling it that it is online and ready. Server receives > notification, reads (or not), and replies that it is done with the node. Node > goes back to sleep. This method would benefit from associating an io device > with each node's ID, so that it would not need to poll the bus to see what's > on there.
Btw, this is exactly what the WiFly module does. It will connect to a server/port you've configured and then over that connection you can send commands. You'll have to architect your reading differently in that case you'll need two different interactions: A) Between the sensor and the central server 1- The sensor alerts the server its awake 2- The server connects to the sensor, opens the 1wire interface and issues any commands it has stored (reads a temperature, opens a relay, whatever). B) Between your clients and the central server 1- The client connects to the server and asks for a temperature or for setting a relay to a given state 2- For the reads the server can reply from the cache from the previous interaction with the sensor. For the writes the server stores them to issue next time around This is the interaction I'm planning to implement in saal[1] to deal with not-always-online sensors/actuators. Pedro [1] https://github.com/pedrocr/saal ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ Owfs-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/owfs-developers
