[somfytahoma] Add closure channel and scaling for RS100 shutter motors

[HenmusZev]

No description provided.

[octa22]

Hello,
thanks for the contribution. The initial version of this binging had a separate channel for controlling the closure, but we decided to merge it into a common "control" channel several years ago. Take inspiration from SomfyTahomaRollerShutterHandler, there is already the ClosureState getting/setting.
Thanks

[HenmusZev]

"Hi @octa22, thank you for the feedback! That makes a lot of sense. I see now that the control channel should be the single point of contact for both commands and state. I will revert the changes to shutter.xml and update the SomfyTahomaShutterHandler.java to link the CONTROL channel to core:ClosureState and implement the setClosure command logic as suggested. I'll push the updates as soon as I've tested them."

[HenmusZev]

"I have updated the PR following the feedback:

• Removed the additional closure channel from shutter.xml.
• Refactored SomfyTahomaShutterHandler to use the existing CONTROL channel for both state (core:ClosureState) and commands.
• Implemented the setClosure logic within the handler, following the RollerShutter model.
• Verified that both binary commands and percentage positioning work correctly with RS100 hardware.

Ready for review!"

[Copilot]

Pull request overview

Updates the Somfy Tahoma shutter handler to better integrate Rollershutter control semantics by wiring the control channel to a closure-related state and by sending setClosure commands for numeric inputs.

Changes:

• Map the control channel to core:ClosureState via stateNames.
• Rework handleCommand() to cancel current executions on STOP and to send setClosure with parameters for numeric commands.
• Change getTahomaCommand() visibility/signature and adjust its default mapping behavior.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[HenmusZev]

"Regarding the scaling: I've verified with the actual RS100 hardware that the states are already correctly reported as 0-100% in openHAB (likely handled by the base handler). Therefore, additional scaling in updateState is not required. I have, however, updated handleCommand to explicitly separate DecimalType from other commands to prevent unsupported commands from being sent as setClosure [0]."

[HenmusZev]

I don't want to push but is the review waiting on me?

[lsiepel]

Thanks for providing a patch to the openHAB project. Looks like this is your first contribution here. Welcome!

Previously @octa22 did a review and commented on the design. The PR is adapted and some changes where applied. It would be nice if @octa22 can do another check.
From my side this LGTM