Questions on bit-decomposition support & stability of v4.1.0-dev.10 vs v4.0.0 (plus prior nil-pointer in modbusclient.go)

[AshishAvesta]

Summary

• I’m using EdgeX 4.0.0 with device-modbus-go in an IIoT project.
• I discovered that Modbus register bit decomposition is not available in v4.0.0, but appears in v4.1.0-dev.10.
• I’m considering upgrading, but I have concerns about production stability and a previous nil-pointer I hit (about a month ago) in modbusclient.go on a different tag.

I’d appreciate guidance on:

1. Whether v4.1.0-dev.10 (or a specific commit/tag in the main branch) is stable / recommended for production.
2. Status of the previous nil-pointer issue in modbusclient.go—is it resolved in v4.1.0-dev.10 or a newer tag?

Environment

• EdgeX Foundry: 4.0.0
• Device Service: device-modbus-go v4.0.0 (current), evaluating v4.1.0-dev.10
• Deployment: Binary on Ubuntu 22.04 (x86_64)
• PLC/Protocol: Modbus TCP (HOLDING_REGISTERS)
• Use case: Need to read individual bits from a 16-bit holding register (boolean flags packed into one register)

What I expected
Bit-level reads in device profile (e.g., bit: 0..15) to be supported in v4.0.0 or released with a stable version, which we can use/deploy in production.

What actually happened
In v4.0.0, the bit decomposition feature is missing. I noted that it exists in v4.1.0-dev.10.

Questions

Recommendation on which tag/commit to use now for production if we need bit-decomposition.

• Stability: Is v4.1.0-dev.10 considered stable enough for production use? If not, is there a recommended pre-release tag/commit or timeline for a stable v4.1.x with this feature?
• Nil-pointer in modbusclient.go: About a month ago, on a newer tag (not 4.0.0), I encountered a nil pointer dereference originating in modbusclient.go during reads.
  - Has this been fixed in v4.1.0-dev.10 (or later)?
  - If there’s a specific commit/PR that addressed it, could you point me to it?

Thank you for the guidance, and I'm happy to provide more logs/configs or test a candidate commit if that helps!

[cloudxxx8]

v4.1.0 is under development, and targeting the end of November to release.
Also, we are planning to release v4.0.1, and we will pick the changes you need to the Odessa branch.

Could you provide more information about the nil pointer error? Is it the same as the issue #647 we fixed in this PR?

#657

[cloudxxx8]

Sorry, I just realized bit decomposition is the new feature in the main branch, so we won't pick it to v4.0.1.
We will only pick bug fixing for the patch release.
You can wait for v4.1 release or build your own image.

[AshishAvesta]

Thanks for the clarification on the release plan @cloudxxx8 .

Since bit decomposition is only in main and won’t be backported to v4.0.1, I wanted to check one option with you:

➡️ Would it be possible to provide a separate branch (or PR) that cherry-picks just the bit-decomposition feature on top of the stable v4.0.0 branch?

Reasoning:

• For our IIoT production deployment, we need bit-level reads but also need the stability of the 4.0.x line (avoiding dev builds).
• If there’s a dedicated branch with this feature applied to v4.0.0, we could build/test it on our side and run it in production without fear of introducing unrelated changes from main.
• This would also give us confidence before moving to v4.1 when it’s GA.

I’m happy to help:

• Test such a branch in a production-like setup
• Share configs and logs for validation

If maintaining a separate branch is not feasible, would you be open to me preparing a PR that cherry-picks the bit-decomposition commits onto v4.0.0 (Odessa branch)?

That way we can move forward with production while staying aligned with upstream.

[cloudxxx8]

ok, if you can help pick the changes and execute the test, we can release it in v4.0.1
Please just open a PR against odessa branch.

[AshishAvesta]

Thanks @cloudxxx8 ! I’ll prepare a PR against odessa(4.0.0) that cherry-picks only the bit-decomposition commits, and I’ll include test results plus a sample profile.
If you can point me to the commits/canonical PR on main for this feature, I’ll use that to avoid missing anything.

[AshishAvesta]

Hi @cloudxxx8 ,

I’ve opened a PR against the odessa branch with the bit-decomposition changes applied and tested:
PR #662

I ran the tests and validated it with a sample device profile, and it works as expected.
Looking forward to your review and feedback. 🙏