5 Commits

Author SHA1 Message Date
89b8775ce3 Add support for specifying the sender id to each call
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
2020-08-11 22:20:58 -05:00
ed99d411b2 Minor optimization to set buffer size appropriately
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.
2020-02-10 21:36:13 -06:00
3c6b8ebcc7 Linter fixes 2018-04-28 23:06:11 -05:00
0bbae0446b Removed debug logging
Added verification of broadcast response message size
Added clearer handling of message types

I'm sure there's a better way to do debug logging, but I don't really feel like adding a dependency on another module just for that.
2018-03-30 20:35:24 -05:00
3262ac428b Added chem data
Added salt cell config
Added system version
Tweaked pool status to pre-adjust values

Chem data uses big endian encoding for most of its values (but not all) while everything else (so far) has used little endian. Chem data also encodes bits like whether there's a system error or not inside other pieces of data like salt levels. There are also bytes in the returned data that I don't know the significance of just yet.
Pool status was tweaked such that asking for pH is corrected down to its proper float representation (e.g. 7.60) instead of the integer representation that is sent by the system (760). Same for water balance/saturation. Salt now returns the proper value (scaled up by 50) instead of the value sent over by the system, which I guess is the maximum precision the system can provide.
2018-03-30 19:59:17 -05:00