[rfxcom] LightwaveRF mood controller: can't convert MOOD1 to SwitchItem #2095
Comments
|
Thanks @mjagdis - I've noticed your commits referenced above and built the |
martinvw
pushed a commit
that referenced
this issue
Jun 14, 2017
Not all incoming operations are appropriate to all channels. Where an incoming operation cannot be mapped to an appropriate state for a channel an exception is raised. This aborts the loop through items connected to the thing's channels. In the case of a mood change sent from an LWRF device the failed conversion of mood to switch state will abort the loop before the mood channel is considered and thus the mood channel will never produce any updates. This is fixed here by wrapping the inner body of the loop in try/catch to discard any exceptions raised. This is something of an abuse of exception handling but the changes required to to filter incoming operations based on the channel being considered would be significant and widespread so exception dumping may be the better approach. At least for now. Closes #1272 Closes #2095 Signed-off-by: Mike Jagdis <[email protected]> (github: mjagdis)
falkena
pushed a commit
to falkena/openhab-addons
that referenced
this issue
Jun 29, 2017
Not all incoming operations are appropriate to all channels. Where an incoming operation cannot be mapped to an appropriate state for a channel an exception is raised. This aborts the loop through items connected to the thing's channels. In the case of a mood change sent from an LWRF device the failed conversion of mood to switch state will abort the loop before the mood channel is considered and thus the mood channel will never produce any updates. This is fixed here by wrapping the inner body of the loop in try/catch to discard any exceptions raised. This is something of an abuse of exception handling but the changes required to to filter incoming operations based on the channel being considered would be significant and widespread so exception dumping may be the better approach. At least for now. Closes openhab#1272 Closes openhab#2095 Signed-off-by: Mike Jagdis <[email protected]> (github: mjagdis)
qvistgaard
pushed a commit
to qvistgaard/openhab2-addons
that referenced
this issue
Jun 30, 2017
Not all incoming operations are appropriate to all channels. Where an incoming operation cannot be mapped to an appropriate state for a channel an exception is raised. This aborts the loop through items connected to the thing's channels. In the case of a mood change sent from an LWRF device the failed conversion of mood to switch state will abort the loop before the mood channel is considered and thus the mood channel will never produce any updates. This is fixed here by wrapping the inner body of the loop in try/catch to discard any exceptions raised. This is something of an abuse of exception handling but the changes required to to filter incoming operations based on the channel being considered would be significant and widespread so exception dumping may be the better approach. At least for now. Closes openhab#1272 Closes openhab#2095 Signed-off-by: Mike Jagdis <[email protected]> (github: mjagdis)
jsjames
pushed a commit
to jsjames/openhab-addons
that referenced
this issue
Jul 1, 2017
Not all incoming operations are appropriate to all channels. Where an incoming operation cannot be mapped to an appropriate state for a channel an exception is raised. This aborts the loop through items connected to the thing's channels. In the case of a mood change sent from an LWRF device the failed conversion of mood to switch state will abort the loop before the mood channel is considered and thus the mood channel will never produce any updates. This is fixed here by wrapping the inner body of the loop in try/catch to discard any exceptions raised. This is something of an abuse of exception handling but the changes required to to filter incoming operations based on the channel being considered would be significant and widespread so exception dumping may be the better approach. At least for now. Closes openhab#1272 Closes openhab#2095 Signed-off-by: Mike Jagdis <[email protected]> (github: mjagdis)
reyem
pushed a commit
to reyem/openhab2-addons
that referenced
this issue
Jul 1, 2017
Not all incoming operations are appropriate to all channels. Where an incoming operation cannot be mapped to an appropriate state for a channel an exception is raised. This aborts the loop through items connected to the thing's channels. In the case of a mood change sent from an LWRF device the failed conversion of mood to switch state will abort the loop before the mood channel is considered and thus the mood channel will never produce any updates. This is fixed here by wrapping the inner body of the loop in try/catch to discard any exceptions raised. This is something of an abuse of exception handling but the changes required to to filter incoming operations based on the channel being considered would be significant and widespread so exception dumping may be the better approach. At least for now. Closes openhab#1272 Closes openhab#2095 Signed-off-by: Mike Jagdis <[email protected]> (github: mjagdis)
Markinus
pushed a commit
to Markinus/openhab2-addons
that referenced
this issue
Jul 2, 2017
Not all incoming operations are appropriate to all channels. Where an incoming operation cannot be mapped to an appropriate state for a channel an exception is raised. This aborts the loop through items connected to the thing's channels. In the case of a mood change sent from an LWRF device the failed conversion of mood to switch state will abort the loop before the mood channel is considered and thus the mood channel will never produce any updates. This is fixed here by wrapping the inner body of the loop in try/catch to discard any exceptions raised. This is something of an abuse of exception handling but the changes required to to filter incoming operations based on the channel being considered would be significant and widespread so exception dumping may be the better approach. At least for now. Closes openhab#1272 Closes openhab#2095 Signed-off-by: Mike Jagdis <[email protected]> (github: mjagdis)
ppieczul
pushed a commit
to ppieczul/openhab2-addons
that referenced
this issue
Jul 2, 2017
Not all incoming operations are appropriate to all channels. Where an incoming operation cannot be mapped to an appropriate state for a channel an exception is raised. This aborts the loop through items connected to the thing's channels. In the case of a mood change sent from an LWRF device the failed conversion of mood to switch state will abort the loop before the mood channel is considered and thus the mood channel will never produce any updates. This is fixed here by wrapping the inner body of the loop in try/catch to discard any exceptions raised. This is something of an abuse of exception handling but the changes required to to filter incoming operations based on the channel being considered would be significant and widespread so exception dumping may be the better approach. At least for now. Closes openhab#1272 Closes openhab#2095 Signed-off-by: Mike Jagdis <[email protected]> (github: mjagdis)
reyem
pushed a commit
to reyem/openhab2-addons
that referenced
this issue
Jul 3, 2017
Not all incoming operations are appropriate to all channels. Where an incoming operation cannot be mapped to an appropriate state for a channel an exception is raised. This aborts the loop through items connected to the thing's channels. In the case of a mood change sent from an LWRF device the failed conversion of mood to switch state will abort the loop before the mood channel is considered and thus the mood channel will never produce any updates. This is fixed here by wrapping the inner body of the loop in try/catch to discard any exceptions raised. This is something of an abuse of exception handling but the changes required to to filter incoming operations based on the channel being considered would be significant and widespread so exception dumping may be the better approach. At least for now. Closes openhab#1272 Closes openhab#2095 Signed-off-by: Mike Jagdis <[email protected]> (github: mjagdis)
aogorek
pushed a commit
to aogorek/openhab2-addons
that referenced
this issue
Jul 5, 2017
Not all incoming operations are appropriate to all channels. Where an incoming operation cannot be mapped to an appropriate state for a channel an exception is raised. This aborts the loop through items connected to the thing's channels. In the case of a mood change sent from an LWRF device the failed conversion of mood to switch state will abort the loop before the mood channel is considered and thus the mood channel will never produce any updates. This is fixed here by wrapping the inner body of the loop in try/catch to discard any exceptions raised. This is something of an abuse of exception handling but the changes required to to filter incoming operations based on the channel being considered would be significant and widespread so exception dumping may be the better approach. At least for now. Closes openhab#1272 Closes openhab#2095 Signed-off-by: Mike Jagdis <[email protected]> (github: mjagdis)
Markinus
pushed a commit
to Markinus/openhab2-addons
that referenced
this issue
Sep 8, 2017
Not all incoming operations are appropriate to all channels. Where an incoming operation cannot be mapped to an appropriate state for a channel an exception is raised. This aborts the loop through items connected to the thing's channels. In the case of a mood change sent from an LWRF device the failed conversion of mood to switch state will abort the loop before the mood channel is considered and thus the mood channel will never produce any updates. This is fixed here by wrapping the inner body of the loop in try/catch to discard any exceptions raised. This is something of an abuse of exception handling but the changes required to to filter incoming operations based on the channel being considered would be significant and widespread so exception dumping may be the better approach. At least for now. Closes openhab#1272 Closes openhab#2095 Signed-off-by: Mike Jagdis <[email protected]> (github: mjagdis)
hillmanr
pushed a commit
to hillmanr/openhab2-addons-pollytts
that referenced
this issue
Dec 6, 2017
Not all incoming operations are appropriate to all channels. Where an incoming operation cannot be mapped to an appropriate state for a channel an exception is raised. This aborts the loop through items connected to the thing's channels. In the case of a mood change sent from an LWRF device the failed conversion of mood to switch state will abort the loop before the mood channel is considered and thus the mood channel will never produce any updates. This is fixed here by wrapping the inner body of the loop in try/catch to discard any exceptions raised. This is something of an abuse of exception handling but the changes required to to filter incoming operations based on the channel being considered would be significant and widespread so exception dumping may be the better approach. At least for now. Closes openhab#1272 Closes openhab#2095 Signed-off-by: Mike Jagdis <[email protected]> (github: mjagdis)
markus7017
pushed a commit
to markus7017/openhab-addons
that referenced
this issue
Aug 12, 2023
* fix some typos in Readme Signed-off-by: Stefan Höhn <[email protected]> * replace outdated ui event doc link Signed-off-by: Stefan Höhn <[email protected]> --------- Signed-off-by: Stefan Höhn <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello,
I'm trying to set up a Lightwave RF mood controller remote with openhab2. Unfortunately once set up, pressing any buttons (except for 'off') causes errors like this:
I've tried setting this up both using Paper UI and manually via config files but the result is the same. I've captured some DEBUG level logs:
The GROUP_OFF command is being correctly interpreted as OFF but all the other buttons are causing conversion errors even though this device should be using CHANNEL_MOOD. This is working as expected in openhab1 but I can't get it to work neither with the latest 2.0.0 docker image nor 2.1.0-snapshot.
I've had a look in the community forums and it looks like someone else has had what looks like the same issue: https://community.openhab.org/t/openhab2-lightwaverf-mood-controller/17792.
Here's the remote in question: http://w3.siemens.co.uk/buildingtechnologies/uk/en/building-automation/room-controls/Documents/Master-Wall-Switch.pdf. It's set up in 'mood' mode as with openhab1 the on/off + mood mode was causing conversion errors (due to sending ON/OFF/MOODn rather than MOODn/GROUP_OFF commands).
The text was updated successfully, but these errors were encountered: