Add contact sensor state option for garage doors

[jmnovak50]

Adds an opt-in per-device setting for ckmkzq garage doors where switch_1 remains true persistently.

When garageDoorUseContactSensorForState is enabled:

• CurrentDoorState is derived from doorcontact_state
• TargetDoorState mirrors doorcontact_state
• commands still use switch_1
• default behavior is unchanged

Build passes. Full test suite has existing local-config-dependent failures when ~/.homebridge-dev/config.json is not present.

[jmnovak50]

All tests are passing now. I also confirmed the opt-in behavior locally on a Tuya ckmkzq garage controller that keeps switch_1=true persistently: HomeKit now reads state from doorcontact_state while commands continue to use switch_1.

[tassy-h]

Hi! @jmnovak50
Thank you for the PR.

The changes you made look good, and it seems like everything should work correctly.
However, I have a feeling that the contact sensor state might actually be obtainable through the API.

Could you check whether your device’s schema includes a dpcode such as doorcontact_state (or something similar)?
If that dpcode exists, it would be better to retrieve the state directly through the API rather than enabling it manually through the plugin settings.

Since I don’t have the actual device here, it would be extremely helpful if you could look into this and make the necessary adjustments.

[jmnovak50]

Yes, I checked the Tuya API output for my device and it does expose doorcontact_state. The relevant schema/status includes: - switch_1 - doorcontact_state - door_control_1 - door_state_1 The issue is that the current GarageDoorAccessory already maps CURRENT_DOOR_STATE to doorcontact_state, but it also uses switch_1 as TARGET_DOOR_STATE when determining CurrentDoorState. On my controller, switch_1 remains true persistently, so the current logic interprets doorcontact_state=false + switch_1=true as OPENING forever. So the proposed option is not adding a manual state override; it tells the plugin to trust the API-provided doorcontact_state as the source of truth for HomeKit state, while still using switch_1 only for commands. I can adjust the implementation/name/docs to make that clearer if preferred. One such improvement that could be renaming the option to something clearer. ie. garageDoorUseDoorContactStateOnly?: boolean or garageDoorTrustDoorContactState?: boolean (I like the second option better). I hope this helps clarify the problem! Best Regards, Jason

…

On Wed, Jun 10, 2026 at 8:38 AM tassy-h ***@***.***> wrote: *tassy-h* left a comment (homebridge-plugins/homebridge-tuya#32) <#32 (comment)> Hi! @jmnovak50 <https://github.com/jmnovak50> Thank you for the PR. The changes you made look good, and it seems like everything should work correctly. However, I have a feeling that the contact sensor state might actually be obtainable through the API. Could you check whether your device’s schema includes a dpcode such as doorcontact_state (or something similar)? If that dpcode exists, it would be better to retrieve the state directly through the API rather than enabling it manually through the plugin settings. Since I don’t have the actual device here, it would be extremely helpful if you could look into this and make the necessary adjustments. — Reply to this email directly, view it on GitHub <#32?email_source=notifications&email_token=AS7LHN77BRJJNF6G7WDFDN347FQFNA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRXGA4DGMBVGEY2M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4670830511>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AS7LHN7PMPSER4C7PYXTAS347FQFNAVCNFSNUABGKJSXA33TNF2G64TZHMYTAMZXGM3TCOBQGA5US43TOVSTWNBWGI3DMNZZHAYDRILWAI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[tassy-h]

I see — I finally understand the issue now.

On your device, the switch_1 value that represents the current contact state does not return the expected values.
If this is a device‑specific behavior, I think the existing deviceOverrides feature might help.
By overriding switch_1 with doorcontact_state, it should behave as expected.
Do you think this approach would work for your device?

That said, I agree that it would be much more convenient if users could simply enable this with a checkbox.
It would definitely help others who use the same device, so let's include this feature in the plugin.

Since English is not my native language, I’ll leave the naming of the setting to your sense — I trust your judgment.

[jmnovak50]

Thanks, that makes sense. I did consider whether deviceOverrides could solve this by remapping switch_1 to doorcontact_state. My concern is that switch_1 serves two purposes in the current implementation: It is used as TARGET_DOOR_STATE when calculating the HomeKit state. It is also used by onSet() to send open/close commands to the device. On my controller, doorcontact_state is already available through the API and correctly reports the physical door position. The issue is that switch_1 remains true persistently after the door is opened, so the current logic interprets: doorcontact_state=false switch_1=true as OPENING indefinitely. I’m not sure that overriding switch_1 with doorcontact_state would preserve command behavior, since switch_1 is also the DP used for control. I can certainly test a deviceOverrides-based solution if you think that is the preferred direction. My goal with the new setting was mainly to provide a simple opt-in solution for devices where switch_1 behaves this way, while still keeping switch_1 as the command DP.On Jun 11, 2026, at 9:05 AM, tassy-h ***@***.***> wrote:tassy-h left a comment (homebridge-plugins/homebridge-tuya#32) I see — I finally understand the issue now. On your device, the switch_1 value that represents the current contact state does not return the expected values. If this is a device‑specific behavior, I think the existing deviceOverrides feature might help. By overriding switch_1 with doorcontact_state, it should behave as expected. Do you think this approach would work for your device? That said, I agree that it would be much more convenient if users could simply enable this with a checkbox. It would definitely help others who use the same device, so let's include this feature in the plugin. Since English is not my native language, I’ll leave the naming of the setting to your sense — I trust your judgment. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[jmnovak50]

Validated locally with both garage controllers. After restart, both ckmkzq devices now show Closed correctly in HomeKit with garageDoorUseContactSensorForState enabled. Commands still use switch_1.

Also verified with Homebridge’s npm:
/opt/homebridge/bin/npm run build passes
/opt/homebridge/bin/npm test -- test/sanitizeName.test.ts passes

[tassy-h]

Thank you for the fix!
I’ve released v2.3.0 with your changes, so I’ll go ahead and close this issue.

[jmnovak50]

Thank you!  🙏 On Jun 12, 2026, at 8:55 AM, tassy-h ***@***.***> wrote:tassy-h left a comment (homebridge-plugins/homebridge-tuya#32) Thank you for the fix! I’ve released v2.3.0 with your changes, so I’ll go ahead and close this issue. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>