Added support for remote asynchronous messages - sensors and switches

[temecom]

Remote devices can generate their own events (ZIGBEE_TRANSMIT_REQUEST) without coordinator requests. There needs to be a means of monitoring them in a long running promise and resolving them when they occur. This first pass effort works but I have not extensively tested it with combined monitor/promise, transmit/promise situations. I think that they should co-exist since the serial port should dispatch to both and the monitor looks for frame.type===TRANSMIT_REQUEST messages from the remote device where as the transmit/promise matches against frame.type and frame.id.

Added:

• xbee-api.js
  • remote monitor method
  • remoteTransmitNoPromise method
  • consolidate send and buildFrame functions Updated:
• Readme.MD
  • Update to add methods

[101100]

@temecom Thanks for the change. I'll look it over in more detail later. The ability to listen for a packet of a specific type is useful.

I think I'd rather just have an example that ignores the promise rather than a separate command for remote transmit. Something like:

this.handleMessage = function(message) {
    var settings = {
        destination64: this.device.serialNumber,
        data: JSON.stringify({
            response:"OK"
        })
    };
    this.xbee.remoteTransmit(settings);
}

Are you worried about the memory used for the unused promises?

[temecom]

Jason,

There are use cases for an open ended transmit that is not expecting a response or handles it through the monitor promise. Some devices may not respond with the frameId or may you may get several responses to one request eg:

a broadcast 'get status' could instruct all devices to send back individual status messages as they are resolved. With a strict request/response scenario every device would have to be polled sequentially.

I think that xbee-promise is a great node that really cleans up asynchronous message processing. I adopted the technique to integrate nedb and q to create a promise based database. Using this and the changes I made to xbee-promise my sensors can now send data samples every X seconds that get saved to a database then sent over a MQTT topic to a cloud service.

 xbee.monitorPromise()
     .then(function (message) {
         return database.insert(message);
     }).then(function (message) {
         this.send(topic, message);
     }).fin(function () {
         // go back to monitoring
     });

A couple of thing need to be solved yet:

1. There is a monitoring gap while processing data
   • we may be able to keep monitoring on and use multi-thread processing.
2. Switching between monitor and request/response.
   • haven't tried this yet
3. I may have broken the tests. How do you run them locally? I will be able to fix it when I can step debug.

Thanks

Chris

On 07/22/2015 01:18 PM, Jason Heard wrote:

@temecom https://github.com/temecom Thanks for the change. I'll look it over in more detail later. The ability to listen for a packet of a specific type is useful.

I think I'd rather just have an example that ignores the promise rather than a separate command for remote transmit. Something like:

this.handleMessage = function(message) { var settings= { destination64: this.device.serialNumber, data: JSON.stringify({ response:"OK" }) }; this.xbee.remoteTransmit(settings); }

Are you worried about the memory used for the unused promises?

— Reply to this email directly or view it on GitHub https://github.com/101100/xbee-promise/pull/7#issuecomment-123850342.

[101100]

npm test should work to run the tests locally.

I understand the usefulness of an open ended transmission, but the promise returned by remoteTransmit can be ignored in that case.

[temecom]

If there is no .then or .fin etc will the promise be removed or will it wait until it expires? If it just evaporates then the ignored promise will work - I will refactor for that .

Thanks

Chris

On 07/23/2015 08:43 AM, Jason Heard wrote:

|npm test| should work to run the tests locally.

I understand the usefulness of an open ended transmission, but the promise returned by |remoteTransmit| can be ignored in that case.

— Reply to this email directly or view it on GitHub https://github.com/101100/xbee-promise/pull/7#issuecomment-124146230.

[101100]

The promise is still created, but will have no effect when it is finished since you have no .then or other call. Also, the promise is not returning the result of the message, but whether the ZigBee reports that the message was sent correctly. Someone using the library can ignore that, but I don't think we should optimize for that.

As for the monitoring gap, the solution would be to use Reactive Extensions which work a lot like promises except that the stream can result in many calls instead of just the one in a promise.

[temecom]

Jason,

If it RemoteTransmit resolves with a TransmitStatus then stops monitoring I think we are Ok.

I will try continuously monitoring (not removing the listener when resolved). The issue there would be turning it off when done. We would need a reference to the callback.

Christopher Smith Temecom, Inc. 8052760598

---- Jason Heard wrote ----

The promise is still created, but will have no effect when it is finished since you have no .then or other call. Also, the promise is not returning the result of the message, but whether the ZigBee reports that the message was sent correctly. Someone using the library can ignore that, but I don't think we should optimize for that.

As for the monitoring gap, the solution would be to use Reactive Extensions which work a lot like promises except that the stream can result in many calls instead of just the one in a promise.

— Reply to this email directly or view it on GitHub.

[101100]

@temecom I've updated the library to use the latest packages and also to fix two minor bugs with how the serialport was used. I've also finished my side project of getting all of the old functionality from this library into an RxJS version. That is available on GitHub. I'm going to add the ability to get a stream of incoming transmissions to that library next.