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

[LCN] Contact Item shows wrong state #8069

Closed
kobelka opened this issue Jul 4, 2020 · 5 comments · Fixed by #8102
Closed

[LCN] Contact Item shows wrong state #8069

kobelka opened this issue Jul 4, 2020 · 5 comments · Fixed by #8102
Labels
bug An unexpected problem or unintended behavior of an add-on

Comments

@kobelka
Copy link

kobelka commented Jul 4, 2020

In the new 2.x LCN-Binding the state of a contact item is wrong.
For Example the door is closed and in Openhab shows that the door is open.
In the 1.x Binding the state was right.
Regards
Jörg

@kobelka kobelka added the bug An unexpected problem or unintended behavior of an add-on label Jul 4, 2020
@kobelka kobelka changed the title [LCN-Binding] Contact Item shows wrong state [LCN] Contact Item shows wrong state Jul 6, 2020
@toweosp
Copy link

toweosp commented Jul 8, 2020

An LCN-BMI (at least in my environment) delivers "0" in the PCHK's Bx-status command (2.x LCN-binding: contact closed) if no motion is detected, visualized e.g. by icon motion-closed, and "1" (contact opened) if motion is detected, visualized by e.g. icon motion-opened.

In contrast the door's reed contact - which is connected to an LCN-BU4L configured as a binary sensor - in my environment delivers Bx-status "0" ("contact closed") if the door is opened - or there's no signal due to a blackout or broken wire - and "1" ("contact opened") if the door is closed. So you have to handle the "reverse mapping" when visualizing door-status by yourself.

In my opinion this is intended behavior and not a bug of the 2.x LCN binding.

@kobelka
Copy link
Author

kobelka commented Jul 9, 2020

You are right, this is the behavior of LCN, but I think Openhab should be easy for everyone, so it would be nice If you can change the behavior of the binary sensor channel directly in the paper ui, like it is with the variables channel.

image

@kobelka
Copy link
Author

kobelka commented Jul 10, 2020

Also in the 1.x Binding I didn´t had to change anything....

Contact s_haustuer "Haustür [%S]" <frontdoor> (g_fenster,g_mysql) {lcn="[myhome:BINARY_STATE.0.20.4]"}

Now in the 2.x Binding I have do to rules and virtuale contact Items to get the right state....

@toweosp
Copy link

toweosp commented Jul 10, 2020

Do you use (LCN-BMI) motion sensors and were they handled correctly in the 1.x Binding?

Because of the special behaviour of door contacts/reed sensors (see my last post) I myself would have to define rules and virtual contact items for many motion sensors in my environment - instead for 1 or 2 door sensors - if contact state handling in the 2.x binding would be reversed.

I like your idea to add a configurable option to the binary sensor channel where one could define if e.g. status "open" should correspond to "0" or "1" of the LCN bus' binary sensor state message. Alternatively we could use a checkbox "reverse open/closed". Perhaps you could change your bug report into a feature/enhancement request?

If the binding owner (@fwolter) will agree with this extension I could offer to implement such a feature (at least to try to ;-))

@kobelka
Copy link
Author

kobelka commented Jul 10, 2020

Perhaps you could change your bug report into a feature/enhancement request?

How could I do this ?

fwolter pushed a commit that referenced this issue Aug 1, 2020
…nel (#8102)

Closes #8069

Signed-off-by: Thomas Weiler <toweosp@gmail.com>
MPH80 pushed a commit to MPH80/openhab-addons that referenced this issue Aug 3, 2020
…nel (openhab#8102)

Closes openhab#8069

Signed-off-by: Thomas Weiler <toweosp@gmail.com>
Signed-off-by: MPH80 <michael@hazelden.me>
bern77 pushed a commit to bern77/openhab-addons that referenced this issue Aug 6, 2020
…nel (openhab#8102)

Closes openhab#8069

Signed-off-by: Thomas Weiler <toweosp@gmail.com>
Signed-off-by: Bernhard <bern77@gmail.com>
andrewfg pushed a commit to andrewfg/openhab-addons that referenced this issue Aug 31, 2020
…nel (openhab#8102)

Closes openhab#8069

Signed-off-by: Thomas Weiler <toweosp@gmail.com>
andrewfg pushed a commit to andrewfg/openhab-addons that referenced this issue Aug 31, 2020
…nel (openhab#8102)

Closes openhab#8069

Signed-off-by: Thomas Weiler <toweosp@gmail.com>
andrewfg pushed a commit to andrewfg/openhab-addons that referenced this issue Aug 31, 2020
…nel (openhab#8102)

Closes openhab#8069

Signed-off-by: Thomas Weiler <toweosp@gmail.com>
andrewfg pushed a commit to andrewfg/openhab-addons that referenced this issue Aug 31, 2020
…nel (openhab#8102)

Closes openhab#8069

Signed-off-by: Thomas Weiler <toweosp@gmail.com>
DaanMeijer pushed a commit to DaanMeijer/openhab-addons that referenced this issue Sep 1, 2020
…nel (openhab#8102)

Closes openhab#8069

Signed-off-by: Thomas Weiler <toweosp@gmail.com>
Signed-off-by: Daan Meijer <daan@studioseptember.nl>
CSchlipp pushed a commit to CSchlipp/openhab-addons that referenced this issue Sep 12, 2020
…nel (openhab#8102)

Closes openhab#8069

Signed-off-by: Thomas Weiler <toweosp@gmail.com>
markus7017 pushed a commit to markus7017/openhab-addons that referenced this issue Sep 19, 2020
…nel (openhab#8102)

Closes openhab#8069

Signed-off-by: Thomas Weiler <toweosp@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug An unexpected problem or unintended behavior of an add-on
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants