[RFXCOM] Make LWRF mood buttons work #2366
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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)
|
Split from PR #2103 (rfxcom-commands) due to ongoing discussion. This is the bare minimum required to make LWRF mood buttons (and quite possibly some other similar things) do anything useful. |
|
Thanks, will you or shall I address the logic which seems to convert the channelType enum to different types but does not actually do that? |
martinvw
approved these changes
Jun 14, 2017
holmes
added a commit
to holmes/openhab2-addons
that referenced
this pull request
Jun 16, 2017
* master: [senseBox] Forgot to add binding to feature.xml (openhab#2371) [Kodi] Fix audio sink (openhab#2301) (openhab#2303) Initial contribution of a Niko Home Control binding. (openhab#1589) [keba] fixed typo (openhab#2370) Removed utilisation of org.apache.http.client (openhab#2369) [RFXCOM] Make LWRF mood buttons work (openhab#2366) [senseBox] Switch caching to ESH ExpiringCacheMap (openhab#2361) Fixed problems found by AuthorTagCheck in the cometvisu bundle (openhab#2364) Added author tag where missing. (openhab#2351) [RFXCOM] Fix chill temperature (openhab#2362) initial contribution Windcentrale binding (openhab#1535) Tesla : reset the Even Stream connection to the Tesla Back-end if the event time stamps differ too much from the current system time (openhab#2358) Homematic: Some updates (openhab#2346) [RFXCOM] Support all data from wind sensors (openhab#2329) Gardena: Optimized refresh after command (openhab#2353) Fix some javadocs. (openhab#2349) Some small non-standard copyright banners which we missed while reviewing (openhab#2347)
falkena
pushed a commit
to falkena/openhab-addons
that referenced
this pull request
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 pull request
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 pull request
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 pull request
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 pull request
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 pull request
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 pull request
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 pull request
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 pull request
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 pull request
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)
Flole998
pushed a commit
to Flole998/openhab-addons
that referenced
this pull request
Dec 30, 2021
* New translations SystemProfiles.properties (German) * New translations SystemProfiles.properties (Hebrew) * New translations SystemProfiles.properties (Dutch) * New translations SystemProfiles.properties (Italian) * New translations SystemProfiles.properties (Finnish) * New translations SystemProfiles.properties (Hebrew) * New translations SystemProfiles.properties (Italian) * New translations SystemProfiles.properties (Dutch)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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)