[EDGE] Handle UNDEFINED_VALUE as null in ModbusRecordChannel#3601
[EDGE] Handle UNDEFINED_VALUE as null in ModbusRecordChannel#3601Sn0w3y wants to merge 2 commits intoOpenEMS:developfrom
Conversation
This commit updates the ModbusRecordChannel to interpret UNDEFINED_VALUE as null for numeric types (FLOAT64, FLOAT32, UINT16, UINT32, UINT64). This change ensures that when a Modbus record contains a value that is designated as undefined or not applicable, it is correctly handled as a null value in the system, rather than being processed as a valid numeric value. This is crucial for avoiding incorrect data interpretation and ensuring data integrity in applications that rely on Modbus communication.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## develop #3601 +/- ##
=============================================
+ Coverage 58.50% 58.53% +0.03%
Complexity 104 104
=============================================
Files 3095 3095
Lines 134204 134215 +11
Branches 9872 9871 -1
=============================================
+ Hits 78501 78547 +46
+ Misses 52778 52749 -29
+ Partials 2925 2919 -6 🚀 New features to boost your workflow:
|
sfeilmeier
left a comment
There was a problem hiding this comment.
Thanks - did you try this? We'll definitely need proper JUnit tests here - maybe by moving the switch-case to a testable static method.
Probably it would be also better to compare the byte-array with UNDEFINED before converting the value to an Object. That way we could avoid the type-casting.
This commit refactors the value parsing mechanism in ModbusRecordChannel to improve code readability and maintainability. Previously, the code used a ByteBuffer to convert the writeValueBuffer directly within the writeValue() method, which included manual buffer management and type-based value extraction. Now, the parsing logic is extracted into a separate, static parseValue() method, which simplifies the writeValue() method by directly converting the writeValueBuffer to a byte array and then parsing it according to the ModbusType. This change not only makes the code cleaner by separating concerns but also adds support for parsing STRING16 types, which was marked as a TODO in the previous implementation. Additionally, the commit includes comprehensive unit tests for the new parsing method, ensuring that all ModbusType values are correctly handled, including the special case of UNDEFINED values.
I in fact did not try this - maybe we could make a call out in community or use the FEMS Customer in community as tester if possible on your side? :) |
No sorry, that would be a lot of effort. Most of this code should be quite easily testable with Simulated ESS directly in the IDE. |
This commit updates the ModbusRecordChannel to interpret UNDEFINED_VALUE as null for numeric types (FLOAT64, FLOAT32, UINT16, UINT32, UINT64). This change ensures that when a Modbus record contains a value that is designated as undefined or not applicable, it is correctly handled as a null value in the system, rather than being processed as a valid numeric value. This is crucial for avoiding incorrect data interpretation and ensuring data integrity in applications that rely on Modbus communication.