* [rfxcom] Support speed for luca DC version
* [rfxcom] Handle null value for speed
* [rfxcom] Update readme and add migration channel
Signed-off-by: Martin van Wingerden <martin@martinvw.nl>
Currently, when a message is received the command will be determined only from the hard-coded set of ON/OFF commands, which means if I configure
a thing and attach it to a switch there is no guarantee that it will respond as expected to receive commands. This PR changes the message factory
to require either bytes (from the RFXcom device) or all the details required to make a transmissable message, including the confguration of the
associated Thing. At the moment, this is only used by lighting4 and raw types, but I expect it will be useful for others in the future.
The hard-coded ON/OFF commands in lighting4 are based on experimentation with different devices, and are not at all consistent. This PR deprecates the
use of those so that in a future release, Lighting4 devices will only work when configured with the correct command ids up front. This will resolve
inconsistent behaviour where devices that have been discovered may work correctly, work only for ON or OFF but not both, have ON and OFF the wrong
way around, turn ON one physical device and OFF another, or any combination of those possibilities.
Signed-off-by: James Hewitt <james.hewitt@uk.ibm.com>
This enables raw message transmission by configuring a raw thing with pulses to
send for either ON, OFF, OPEN or CLOSED commands.
To enable extended config, this includes a refactor for the RFXComHandler to
support different Configuration objects depending on the thing type, and moves
the parsing, validation, and message matching logic to the Configuration objects
where the logic is more appropriate.
To enable testing of the RFXComHandler, the RFXComMessageFactory was abstracted
out and injected as a dependency.
Signed-off-by: James Hewitt <james.hewitt@uk.ibm.com>
New firmware type reported from the community that's not in the SDK. Also,
we don't actually _use_ the firmware type or device type for anything, so
lets not crash if we don't match the bytes - lets just flag it unknown.
https://community.openhab.org/t/rfxcom-binding-unsupported-value/123615/12
Signed-off-by: James Hewitt <james.hewitt@uk.ibm.com>
Based on the RFXtrx SDK, new blind types. They mostly seem to match existing logic,
so this shouldn't break existing things.
Signed-off-by: James Hewitt <james.hewitt@uk.ibm.com>
Based on both the SDK and experimentation, this commit correctly identifies the
firmware and hardware version. A warning has been added for people with really
old firmware that may be different, but we didn't handle those different cases
well anyway.
Also includes updated firmware types and device types and support for pretty-
printing of the device and firmware type.
Signed-off-by: James Hewitt <james.hewitt@uk.ibm.com>
This is a new feature in the Pro firmwares that provides the real raw RF
pulse lengths as shorts. Good for being able to parrot switches that aren't
otherwise supported, once we add the tx support as well.
Signed-off-by: James Hewitt <james.hewitt@uk.ibm.com>
There's no reason not to read multiple bytes at a time (that I could find) so
for best practice, set the read limit to be the maximum size of an rfxcom
message. Tested fine on my system.
Signed-off-by: James Hewitt <james.hewitt@uk.ibm.com>
Without this, any message over 127 bytes reports a negative length and
fails the message start test, which puts the code out of sync with the
rfxcom leading to lots of errors, and eventually, complete loss of
connection.
Signed-off-by: James Hewitt <james.hewitt@uk.ibm.com>
