Computing stuff tied to the physical world

Remote node discovery – code

In Software on Jan 16, 2013 at 00:01

Ok, time to try out some real code, after yesterday’s proposal for a simple node / sketch / packet format announcement system.

I’m going to use two tricks:

  • First of all, there’s no need for the node itself to actually send out these packets. I’ve written a little “announcer” sketch which masquerades as the real nodes and sends out packets on their behalf. So… fake info to try things out, without even having to update any nodes! This is a transitional state, until all nodes have been updated.

  • And second, I don’t really care about sending these packets out until the receiving end actually knows how to handle this info, so in debug mode, I’ll just report it over serial.

Note that packets get sent to “node 0″, which cannot exist – so sending this out is in fact harmless: today’s RF12 listeners will ignore such packets. Except node 31, which sees these new packets come in with header byte 64 (i.e. 0x40). No RF12 driver change needed!

Here’s the essence of the test sketch:

Screen Shot 2013-01-15 at 15.12.08

With apologies for the size of this screenshot – full code is on GitHub.

Note that this is just for testing. For the actual code, I’d pay far more attention to RAM usage and place the actual descriptive data in flash memory, for example.

And here’s some test output from it on the serial port:

Screen Shot 2013-01-15 at 15.09.51

Yeah, that looks about right. Next step will be to pick this up and do something with it. Please give me a few days for that, as the “HouseMon” server-side code isn’t yet up to it.

To be continued soon…

PS. Another very useful item type would be the maximum expected time between packets. It allows a server to automatically generate a warning when that time is grossly exceeded. Also a nice example of how self-announcement can help improve the entire system.

  1. What is exactly the problem we are trying to solve here?

    Looking at my daily tasks as a Jeenode network admin ;-) The time I spend on adding new ‘standard’ nodes to my network that would benefit from remote discovery is negligible. It is a fairly static setup with mostly custom nodes. More time is spend on changing batteries.

    When I do add a new type of node most time is taken by developing new sketches, upgrading and fine tuning these preferably insitu (some are in hard to reach locations). For this a nice remote sketch update system would be nice along with some easy to use framework to set parameters over rf.

    Perhaps it is a good idea to turn the mechanism around? Why don’t we set the sketch and sketch parameters from within housemon instead of trying to discover what sketch is running (you still need to verify the actual sketch running of course)?

    New nodes should be assigned a group/node id using rf12demo and the rest can be done from housemon which provides the correct sketch and parameters to the jeenode at its request?

    This could improves the experience of setting up new jeenodes and changing parameters for novice users and improves development of custom nodes as well.

  2. I am building a system that is driven off an internet appliance, and used by non-computer literate folks. In my case, they need to be able to buy a new node, simply plug it and turn it on without having to know about RF12, demo sketches etc. So having a new node announce itself is very important.

  3. Does your system need to now the data format? Or only an ID and version to hook it up into the appliance?

    And wouldn’t it be a great improvement if your system would be able to configure and upgrade nodes over RF for those novice users?

Comments are closed.