home-climate-control / xbee-api-reactive Goto Github PK

Current State of Affairs

InputStreamThread reads from the hardware and uses PacketParser to parse incoming packets. The implementation is "upside down" - instead of instantiating clean data objects (which can eventually become Java 14 records), classes that include both code and data are "saddled" on top of the input stream and consume it in a manner that makes it impossible to convert to streaming code.

Desired Outcome

Implementation created that is capable of emitting clean data objects with no code in them.

Depends on: #11

The rest of DIY Zoning ecosystem is already on Gradle, need to bring this one up to speed, too.

Current State of Affairs

XBee exposes sendPacket() which is not thread safe and may be called out of order.

Desired Outcome

The implementation hides the details of sending XBee packets, and enforces thread safety and FIFO order of packets scheduled to send.

Related: #12

Current Gradle build issues this warning:

Deprecated Gradle features were used in this build, making it incompatible with Gradle 5.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See https://docs.gradle.org/4.9/userguide/command_line_interface.html#sec:command_line_warnings

Reference

home-climate-control/dz#241

Expected Behavior

When sending a remote request via sendSynchronous(), the response received is properly matched against the request sent.

Actual Behavior

The first response received is interpreted as the actual response.

Log

2022-10-03 10:44:52,373 INFO AbstractHvacDriver pool-21-thread-1 [run, setStage] stage=1
2022-10-03 10:44:52,378 INFO XBee pool-21-thread-1 [run, setStage, setState, write(0013A200.402D030D:D2)] Sending request to XBee: apiId=REMOTE_AT_REQUEST (0x17),frameId=1,command=D2,value=0x05,remoteAddr64=0x00,0x13,0xa2,0x00,0x40,0x2d,0x03,0x0d,remoteAddr16=0xff,0xfe,applyChanges=true
2022-10-03 10:44:52,379 INFO XBee pool-21-thread-1 [run, setStage, setState, write(0013A200.402D030D:D2)] Sending packet to XBee 0x7e,0x00,0x10,0x17,0x01,0x00,0x7d,0x33,0xa2,0x00,0x40,0x2d,0x03,0x0d,0xff,0xfe,0x02,0x44,0x32,0x05,0x3b

### Mismatched response: expecting D2, received NT, didn't realize

2022-10-03 10:44:54,558 INFO XBeeSwitch pool-21-thread-1 [run, setStage, setState, write(0013A200.402D030D:D2)] D2 response: command=NT,status=OK,value=0x00,0x3c,apiId=AT_RESPONSE (0x88),length=7,checksum=0x98,error=false,frameId=0x01
2022-10-03 10:44:54,563 DEBUG Marker pool-21-thread-1 [run, setStage, setState, write(0013A200.402D030D:D2)] marker@1e5afc2#c8142c: (write(0013A200.402D030D:D2)) completed in 2185 ms (0:00:02.185)

Expected Behavior

Adapter initializes and keeps working normally.

Actual Behavior

(observed on rev. 6198fb7)
On startup with some hardware configurations, the exception trace below is printed onto stdout, no further communication is happening.

Suspected Cause

Mismatch between the desired and the actual API state (byte values are escape (0x7D) and XON (0x11)), the packet is not properly unescaped, and the checksum is not calculated on correct payload.

Actual Cause

The checksum byte is also escaped.

Contributing Factors

The exception propagates unchecked and kills the reader thread.

Exception in thread "XBeeReader" java.lang.IllegalArgumentException: Checksum mismatch, expected 0x7D, actual 0x11
        at com.homeclimatecontrol.xbee.response.ResponseReader.verifyChecksum(ResponseReader.java:116)
        at com.homeclimatecontrol.xbee.response.ResponseReader.read(ResponseReader.java:50)
        at com.homeclimatecontrol.xbee.HardwareReader.readFrame(HardwareReader.java:90)
        at com.homeclimatecontrol.xbee.HardwareReader.processFrame(HardwareReader.java:71)
        at com.homeclimatecontrol.xbee.HardwareReader.read(HardwareReader.java:53)
        at java.base/java.lang.Thread.run(Thread.java:834)

As an Application Maintainer, I want local and CI/CD builds to produce ErrorProne reports so that they can be available on the spot without jumping through the hoops with IDE plugins.

Acceptance Criteria: Gradle build composes ErrorProne report.

Current State of Affairs

Even though the reactive code (see XBeeReactive as a starting point) is now functional, there are still pieces of old code present in the project that have not been completely ported, or retired.

Desired Outcome

• Whatever needs to be ported is ported
• Whatever is no longer needed is retired

At some point into the life of the application using xbee-api, this message starts repeating regardless of the system load. Need to verify whether this message is superfluous, or it is a sign of a bigger problem.

Looks like a missing switch statement break in SerialPortConnection. Investigating.

Same as #19 , only for reactive code.

Sometimes it's throw new IllegalStateException("not connected"); sometimes it is throw new XBeeNotConnectedException(). Need to figure out the contract and unify.

As an Application Maintainer, I want to enable test coverage calculation as a build pipeline so that I can have an idea about what code can be (somewhat) trusted.

Problem Statement

RxTx shows its age, and is in unknown development state.

Desired Outcome

• A well maintained library is identified;
• RxTx is retired and replaced by the new library.

Candidates

In no particular order

• https://github.com/Fazecast/jSerialComm
• https://github.com/openmuc/jrxtx (drop in replacement)
• https://github.com/java-native/jssc

Current State of Affairs

IXBee defines the xbee-api API, contains methods that probably shouldn't be exposed at this level of abstraction.

Desired Outcome

An API is created that contains only the methods that comply to these requirements:

• They are compatible with Reactive Streams specification;
• They do not expose internal works of the implementation.

Background

• #13 - done
• #14 - done

Desired Outcome

Now need to tie them together so that the response to a sent request can be identified in the stream being read from XBee and returned.

Current Behavior

PacketParser#parsePacket() creates stateful instances of XBeeResponse subclasses, each of which combines the data, and the code.

Desired Behavior

Data objects and parsers are separated, stateless parsers produce instances of data objects.