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.
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
* 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
This avoids unnecessary allocations/reallocations while decoding a message by pre-sizing the buffer to the amount we know it will require. I feel like there's probably a better way to handle this, but this works for now.
This just returns the extra amount needed to add onto the string/array.
Also fixed up writeSLArray() not adding slack like it should have been. This wasn't an issue previously because the only place that currently uses this function is the password feature which is a fixed 16byte length, so it was already aligned. An upcoming commit will be using this, however, so I needed the alignment to be correct.
Finally, the read/write string functions were doing unnecessary conditional checks so I removed them. skipWrite() already does nothing if you tell it to skip 0, and adding 0 to readOffset won't do anything, so neither conditional is necessary at this point.
This password encoder was decompiled from the Android app then manually cleaned up and ported to Javascript. It ain't pretty, but it works.
I don't know that this is all necessarily the most correct or idiomatic way to implement these features, but I wanted to make sure the functionality got committed to help out people wanting to use this for smart home appliances (#1).
