unit.getHistoryData(fromTime, toTime) will request data about sensor and circuit changes over time, then `getHistoryData` will be emitted when the data is ready to be handled.
Fixes#59
There may be some value in providing a read version of this as well, but
it is comprised of so many properties that I'm leaving that out for now.
If it becomes a need in the future, it will be straightforward to add.
Fixed `addClient` and `removeClient` events returning `SLCancelDelay` objects. This shouldn't really make a difference as there are no properties to worry about on one or the other, but it was still incorrect and could cause bugs if stuff was added to those messages in the future.
This parameter is optional, so compatibility shouldn't be affected. Each SLMessage can set its own sender ID which is present on the returned message. This allows callers to fire multiple requests at once, even of the same type, while being able to identify which response went with which request. If not specified, the default value is 0.
Also went ahead and documented some of the helper functions present on SLMessage (so, available on all message instances).
Finally, since I was in and messing with each message anyway, I simplified and removed some repeated code from each derived message and had it call into the super to take advantage of shared decoding functionality.
The lambdas ("arrow functions") in test functions were removed per advice from Mocha's documentation where the implicit `this` rebinding can apparently cause problems. This should probably have been its own commit, but, again, I was already in there messing with stuff, so...oh well.
Closes#43
I had local changes to the example script that inadvertently were pushed to npm as part of 1.6.0, so that release on npm didn't match the repo's contents.
These change frequently and it's probably not worth documenting anyway. I'm pretty sure these versions were no longer valid anyway since, for example, Mocha no longer supports node v8.
* initial code to interpret valveDataArray
* Some additional comments on the valveDataArray decoding message
* Adds decodeSensorData, decodeValveData, decodeDelayData, decodeMiscData
* reverts unintended change to index.js
* Refactor / rename variables
- renamed variables to better describe their use
- created a helper function 'isValvePresent' to simplify code
- changed while loop to for loop
* - Fixes bug in decodeValveData where only last valve's data was returned
- renames some variables based on testing to more descriptive names
- add CIRCUIT_NAME_VALUE_MAP for fixed values that the system uses (determined by testing on my system)
* refactored decodeMiscData to simplify code
* - Changed CIRCUIT_NAME_VALUE_MAP to array of objects
- Refactored getCircuitByDeviceId
- Added getCircuitsMap as helper to getCircuitByDeviceId and as a utility function to help in UI development
* initial code to interpret valveDataArray
* Some additional comments on the valveDataArray decoding message
* Adds decodeSensorData, decodeValveData, decodeDelayData, decodeMiscData
* reverts unintended change to index.js
* Refactor / rename variables
- renamed variables to better describe their use
- created a helper function 'isValvePresent' to simplify code
- changed while loop to for loop
* added helper methods for decode/encode dayMask
* moved isBitSet to SLMessage.js as this method is needed for several message types
* Refactored reusable functions to SLMessage
I find these console logs valuable for development but don't want them on all the time for everyone. It's cumbersome to comment/uncomment them continually, so this package helps nicely. I generally don't like adding dependencies, but this one seems wildly popular and itself only has one dependency (and that dependencies doesn't depend on anything else). So it seems acceptable to use.
I also enabled these debug logs by default when running the example configuration from VSCode.
