Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[homematic] Expansion of virtual data channel for all window/door contacts #15641

Merged
merged 2 commits into from
Oct 18, 2023

Conversation

niclas18
Copy link
Contributor

The HomeMaticIP series includes, among other things, numerous different window and door contacts. The corresponding binding "homematic" from this repo establishes a connection to the headquarters of this product series (via an API). However, this only provides the current status (open or closed) for these sensors as a string, which is difficult to process. For example, for further integration via Openhab to Amazon Alexa, a special conversion rule is required (necessary for each sensor).

For this reason, a virtual controller was built into the add-on, which converts the strings from the API into a normal data channel (ON or OFF). This currently checks whether it is the HMIP-SWDO model and then adds the corresponding data channel. However, in recent years there have been significantly more variants of these sensors on the market, for example the HMIP-SWDM model. However, these are not assigned the virtual channel, although they have the same API return and therefore a problem-free conversion is possible (tested myself, as I own both models).

The manufacturer of HomeMatic products follows clear naming, so that all products with the model number SWD should also have this virtual data channel. This is why the simplification as stated in the PR.

The problem has been reported in #4614, the german Openhab forum and other repos, among others.

Update StateContactVirtualDatapointHandler.java

Signed-off-by: niclas18 <[email protected]>
@niclas18 niclas18 requested a review from gerrieg as a code owner September 23, 2023 19:47
@lsiepel lsiepel added the enhancement An enhancement or new feature for an existing add-on label Sep 24, 2023
@lolodomo
Copy link
Contributor

lolodomo commented Oct 8, 2023

@FStolte @gerrieg @mdicke2s : can one of you please confirm that the change makes sense ?

@lolodomo
Copy link
Contributor

This binding is apparently no more maintained. Let's assume your change is correct.

Copy link
Contributor

@lolodomo lolodomo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@lolodomo lolodomo merged commit d63934b into openhab:main Oct 18, 2023
2 checks passed
@lolodomo lolodomo added this to the 4.1 milestone Oct 18, 2023
querdenker2k pushed a commit to querdenker2k/openhab-addons that referenced this pull request Oct 21, 2023
…tacts (openhab#15641)

* make VirtualDatapoint belonging ContactSensor for more devices available

---------

Signed-off-by: niclas18 <[email protected]>
querdenker2k pushed a commit to querdenker2k/openhab-addons that referenced this pull request Oct 29, 2023
…tacts (openhab#15641)

* make VirtualDatapoint belonging ContactSensor for more devices available

---------

Signed-off-by: niclas18 <[email protected]>
Signed-off-by: querdenker2k <[email protected]>
austvik pushed a commit to austvik/openhab-addons that referenced this pull request Mar 27, 2024
…tacts (openhab#15641)

* make VirtualDatapoint belonging ContactSensor for more devices available

---------

Signed-off-by: niclas18 <[email protected]>
Signed-off-by: Jørgen Austvik <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement An enhancement or new feature for an existing add-on
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants