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
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 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.
* added GetPumpStatus / SetPumpFlow commands
* Updated README.md with GetPumpStatus / SetPumpFlow information
* rename `setPointType` to `isRPMs`
* renamed val0 to pumpType and val1 to isRunning
* added `unknown command` case
* fixed lint error
* Renamed unknown values to pumpUnknown1 and pumpUnknown2
* renamed 30 to unknownCommand
I am not documenting this in the readme just yet because I don't really know how to interpret the data provided, but it seems to be necessary if we want to be able to change pump speeds in the future or read any historical data about the equipment. I'm not sure how much I'm going to be able to figure out about these arrays since the data appears random to me at the moment, but perhaps others will be able to figure out what's in here.
This implementation is barebones and only does what I was able to find easily in the official app's source code. I'd love to do more with this, so any pull requests adding functionality would be welcomed.
Closes https://github.com/parnic/node-screenlogic/issues/4
We shouldn't be trying to read the message length out of the middle of a message when there are multiple segments.
Fixes https://github.com/parnic/node-screenlogic/issues/5 (for real this time, I hope...I don't have a way to test)
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).
On my RPi3 I'm seeing a failure to find units because send() is demanding a Buffer or String. Uint8Array works for me in every other environment I've tried, but something about the RPi wants this to be a buffer. Having it as a buffer also works in other environments, thankfully.
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.
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.
Much better organization and ease-of-use now that the proof of concept is established. Still an awful lot to do here, but I'm getting the hang of the whole node.js thing.
Also moved the actual test functionality out to a test script so the module itself doesn't execute anything.
