[kaleidescape] Kaleidescape Movie Player Binding - initial contribution

[mlobstein]

[kaleidescape] Initial contribution

This is the initial implementation of a Binding to control and retrieve information from a Kaleidescape movie player. All movie player components including the original K-Player series, M Class Players, Cinema One, Alto, and Strato are supported. As there are many good control options already available for these components, this binding focuses primarily on retrieving information for display purposes and to use in rules for controlling other Things such lighting, projector lens control, masking, etc. Any feedback or suggestions for improvement are welcome.

[mlobstein]

Test build available here:
https://github.com/mlobstein/mlobstein-beta-test/raw/master/org.openhab.binding.kaleidescape-2.5.8-SNAPSHOT.jar

If you receive an error about openhab-transport-serial, issue the following command in the openhab console:

feature:install openhab-transport-serial

[TravisBuddy]

Travis tests were successful

Hey @mlobstein,
we found no major flaws with your code. Still you might want to look at this logfile, as we usually suggest some optional improvements.

[TravisBuddy]

Travis tests were successful

Hey @mlobstein,
we found no major flaws with your code. Still you might want to look at this logfile, as we usually suggest some optional improvements.

[TravisBuddy]

Travis tests were successful

Hey @mlobstein,
we found no major flaws with your code. Still you might want to look at this logfile, as we usually suggest some optional improvements.

[TravisBuddy]

Travis tests were successful

Hey @mlobstein,
we found no major flaws with your code. Still you might want to look at this logfile, as we usually suggest some optional improvements.

[TravisBuddy]

Travis tests were successful

Hey @mlobstein,
we found no major flaws with your code. Still you might want to look at this logfile, as we usually suggest some optional improvements.

[TravisBuddy]

Travis tests were successful

Hey @mlobstein,
we found no major flaws with your code. Still you might want to look at this logfile, as we usually suggest some optional improvements.

[TravisBuddy]

Travis tests were successful

Hey @mlobstein,
we found no major flaws with your code. Still you might want to look at this logfile, as we usually suggest some optional improvements.

[mlobstein]

@fwolter
Hold off on reviewing until #7371 is sorted out. This binding's Connector classes are of the same derivative, so I will need to make the requested changes here also.

[TravisBuddy]

Travis tests were successful

Hey @mlobstein,
we found no major flaws with your code. Still you might want to look at this logfile, as we usually suggest some optional improvements.

[TravisBuddy]

Travis tests were successful

Hey @mlobstein,
we found no major flaws with your code. Still you might want to look at this logfile, as we usually suggest some optional improvements.

[TravisBuddy]

Travis tests were successful

Hey @mlobstein,
we found no major flaws with your code. Still you might want to look at this logfile, as we usually suggest some optional improvements.

[TravisBuddy]

Travis tests were successful

Hey @mlobstein,
we found no major flaws with your code. Still you might want to look at this logfile, as we usually suggest some optional improvements.

[fwolter]

LGTM

[fwolter]

LGTM

[cpmeister]

Everything looks pretty good. I was only able to find a couple of things worth pointing out.

[Hilbrand]

Thanks for yet another contribution 😄 Looks good. Nice use of enum method overriding. Not really any big review comments.

[Hilbrand]

I have used ExpiringCache with a small timout, like 3 seconds. When the cache expires it will call the method passed. You could use this channels have the same command, such that when multiple of these channels are updated they are not all sending the command. And when using a cache you can probably iterate over the channels here, check if the channel is linked (i.e. if it actually make sense to update the channel) and then call handleRefresh with the channel instead of directly sending the command here. There is also an ExpiringCacheMap to handle multiple caches.

[mlobstein]

@Hilbrand I tried using ExpiringCache but it didn't really work with the framework of sending a command and getting one or more events back. And the constant refresh upon cache timeout is not needed because the device sends unsolicited updates. I implemented a similar scheme by saving events to a map and replaying them when refresh is called.

[Hilbrand]

LGTM