Differences
This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
|
user:kluong:feature_idea_-_two_way_communication [2021/03/25 17:37] kluong created |
user:kluong:feature_idea_-_two_way_communication [2021/09/19 21:59] (current) |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== Feature Idea - Two way communication ====== | ====== Feature Idea - Two way communication ====== | ||
| + | |||
| + | One thing that might be useful is two way communication between the coordinator and end devices. In a serial console on the server or a command line program, you should be able to send a command to and end device and get a response. Here's how it could work: | ||
| + | |||
| + | <code> | ||
| + | python weatherbox-console.py | ||
| + | |||
| + | Enter your command here: ACKREQ 8888 | ||
| + | ... | ||
| + | Reply from node 8888: | ||
| + | OK | ||
| + | |||
| + | Enter your command here: ACKREQ 9999 | ||
| + | ... | ||
| + | Reply from node 9999 timeout. | ||
| + | |||
| + | Enter your command here: | ||
| + | |||
| + | </code> | ||
| + | |||
| + | Note this is a communication layer that exists on top of the zigbee/xbee layer. | ||
| **why it might be useful** | **why it might be useful** | ||
| - | One thing that might be useful is two way communication between the coordinator and end devices. It might be useful for a couple of things like: | + | It might be useful for a couple of things like: |
| - | * Checking that the firmware is in a good state (if it responds to a request from the coordinator, it's probably okay) | + | * Checking that the firmware is in a good state (if it responds to a request from the coordinator, it's probably okay) |
| - | * Remotely setting the RTC | + | * Remotely setting the RTC |
| - | * Tell the box to stop transmitting | + | * Tell the box to stop transmitting |
| - | * Ask for the current GPS coordinates (to update the box's location information somewhere) | + | * Ask for the current GPS coordinates (to update the box's location information somewhere) |
| - | * Change the node id (not sure how often this is needed). | + | * Change the node id (not sure how often this is needed). |
| - | * Turn on power conservation mode | + | * Turn on power conservation mode |
| There could be more things, but in general, if there's some state that needs to be managed then it might be useful to have the ability to do them remotely. These things are easily accomplished with the command mode through serial, but it can be a pain once there are dozens/hundreds of nodes everywhere. | There could be more things, but in general, if there's some state that needs to be managed then it might be useful to have the ability to do them remotely. These things are easily accomplished with the command mode through serial, but it can be a pain once there are dozens/hundreds of nodes everywhere. | ||
| Line 21: | Line 41: | ||
| * The gateway needs to be modified to allow outgoing packets (it doesn't have any logic for that right now) | * The gateway needs to be modified to allow outgoing packets (it doesn't have any logic for that right now) | ||
| - | **implementation notes* | + | **implementation notes** |
| It would be good to start with something simple, like an ACKREQ command that once the node receives it responds with an OK or something. Other features can be built on top of this once the system is proven to work. | It would be good to start with something simple, like an ACKREQ command that once the node receives it responds with an OK or something. Other features can be built on top of this once the system is proven to work. | ||