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.
I should probably turn the semi-colon linter off since I really dislike the semi-colons everywhere, but it's probably too late for that at this point in the project.
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.
Close the finder when we've found a unit.
Request and handle each piece of data in sequence instead of requesting it all at once and then closing when the last expected message comes through. This is potentially slightly slower, but much clearer and 'safer'.
