@@ -189,8 +189,6 @@ Serveral `*Device` methods accept a `responseHandler` parameter, which is a `pac
The `sendPacket` and `sendText` methods accept a `responseHandler` as well as an `ackHandler` function as part of their parameters. (Both of these are of type `packetHandler`.) Supplying these implicitly sets `wantResponse` and `wantAck` to `true`, respectively. (Setting `wantResponse` and `wantAck` to `true` but omitting the handlers is also possible.)
The `sendEncrypted` method accepts an `ackHandler` function as part of its parameters, with the same behaviour as in `sendPacket` and `sendText`.
*Handlers***override***callbacks*. If a handler has been supplied to any of these methods, the handler will be called when an `ack` or `response` has been received, and the callback for that type of message *will not be called*. However, if there are both an `ackHandler` and a `responseHandler`, both of those *will* be called. So if you do this:
@@ -161,8 +161,6 @@ Serveral `*Device` methods accept a `responseHandler` parameter, which is a `pac
The `sendPacket` and `sendText` methods accept a `responseHandler` as well as an `ackHandler` function as part of their parameters. (Both of these are of type `packetHandler`.) Supplying these implicitly sets `wantResponse` and `wantAck` to `true`, respectively. (Setting `wantResponse` and `wantAck` to `true` but omitting the handlers is also possible.)
The `sendEncrypted` method accepts an `ackHandler` function as part of its parameters, with the same behaviour as in `sendPacket` and `sendText`.
*Handlers***override***callbacks*. If a handler has been supplied to any of these methods, the handler will be called when an `ack` or `response` has been received, and the callback for that type of message *will not be called*. However, if there are both an `ackHandler` and a `responseHandler`, both of those *will* be called. So if you do this: