[bondhome] New binding: Bond Home #7260

SRGDamia1 · 2020-03-31T04:34:53Z

New Binding for Bond Home bridge and devices

A new binding for RF and IR remote control devices controlled by a Bond Bridge. (https://bondhome.io/products/bond-bridge/)

TravisBuddy · 2020-03-31T04:55:02Z

Travis tests were successful

Hey @SRGDamia1,
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 · 2020-03-31T15:29:55Z

Travis tests were successful

Hey @SRGDamia1,
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 · 2020-03-31T17:17:54Z

Travis tests were successful

Hey @SRGDamia1,
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 · 2020-03-31T17:32:55Z

Travis tests were successful

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

digitaldan · 2020-03-31T17:51:55Z

Hi @SRGDamia1 , i had never heard of Bond Home, cool product.

I took a minute to look at their api, i notice you mention you needed to manually find your Bond's IP address, but according to their docs, they support standard mDNS, and openHAB makes that very easy to add to your binding for auto discovery.

http://docs-local.appbond.com/#section/Getting-Started/Finding-the-Bond-IP

you can find a ton of examples from other bindings:
https://github.com/openhab/openhab-addons/search?l=Java&q=mdns

Good Luck!

SRGDamia1 · 2020-03-31T18:44:06Z

@digitaldan - I'm pinging for the IP from the serial number, but using mDNS would probably be better to get the bridge into the inbox. I'll look into it.

TravisBuddy · 2020-03-31T22:53:56Z

Travis tests were successful

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

SRGDamia1 · 2020-04-01T05:12:17Z

@digitaldan Implemented!

TravisBuddy · 2020-04-01T05:31:08Z

Travis tests were successful

Hey @SRGDamia1,
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 · 2020-04-02T04:07:24Z

Travis tests were successful

Hey @SRGDamia1,
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 · 2020-04-04T05:22:13Z

Travis tests were successful

Hey @SRGDamia1,
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

I saw that you put a lot of effort into this binding. Please take a look if you (or any user) really need all the trace log messages or if they can be replaced by using the debugger.

bundles/org.openhab.binding.bondhome/README.md

fwolter · 2020-05-21T10:36:07Z

bundles/org.openhab.binding.bondhome/README.md

+| shadeChannels      | openShade                | Switch   | Opens or closes motorize shades            | Motor Shades |
+| shadeChannels      | hold                     | Switch   | Tells a device to stop moving               | Motor Shades   |


Did you consider using the Rollershutter item-type?

Yes and there was some reason I decided not to use it. I don't remember why. I'll look into it again.

fwolter · 2020-05-21T12:19:52Z

...b.binding.bondhome/src/main/java/org/openhab/binding/bondhome/internal/api/BPUPListener.java

+        return packetIsDuplicate;
+    }
+
+    private void datagramSocketHealthRoutine() {


You should add a grace period of a few seconds here, to prevent hammering on the network (and local resources) when the error is persistent.

I'm sorry. What's the best way to implement that?

Since you run in your own thread, you can simply use Thread.sleep().

bundles/org.openhab.binding.wizlighting/.classpath

bundles/org.openhab.binding.wizlighting/.project

.project

bom/.project

bundles/.project

TravisBuddy · 2020-06-07T04:55:03Z

Travis tests have failed

Hey @SRGDamia1,
please read the following log in order to understand the failure reason. There might also be some helpful tips along the way.
It will be awesome if you fix what is wrong and commit the changes.

TravisBuddy · 2020-06-07T04:56:48Z

Travis tests have failed

Hey @SRGDamia1,
please read the following log in order to understand the failure reason. There might also be some helpful tips along the way.
It will be awesome if you fix what is wrong and commit the changes.

TravisBuddy · 2020-06-07T04:56:54Z

Travis tests have failed

Hey @SRGDamia1,
please read the following log in order to understand the failure reason. There might also be some helpful tips along the way.
It will be awesome if you fix what is wrong and commit the changes.

TravisBuddy · 2020-06-07T05:10:08Z

Travis tests have failed

Hey @SRGDamia1,
please read the following log in order to understand the failure reason. There might also be some helpful tips along the way.
It will be awesome if you fix what is wrong and commit the changes.

SRGDamia1 · 2020-06-07T05:10:24Z

Thank you so much for your time. I'm sorry I've been really slow to respond. And, obviously, java isn't my native tongue.

I've fixed the quick and easy things.

When implement asynchronous http requests, can I still make the function call "synchronous" so that no two requests to the bridge can overlap? That is, can I make sure I got a response to the last request before sending a new one?

TravisBuddy · 2020-06-07T05:29:45Z

Travis tests were successful

Hey @SRGDamia1,
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 · 2020-06-07T08:31:12Z

Travis tests were successful

Hey @SRGDamia1,
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 · 2020-06-07T19:49:13Z

When implement asynchronous http requests, can I still make the function call "synchronous" so that no two requests to the bridge can overlap?

Yes, you can do that, but I don't think this is natively supported by HttpClient. So, you have to write the synchronization code yourself. Using async HTTP requests is not a requirement. You could stick to your current implementation, if network timeouts are kept low (<=10sec). The disadavantage is blocking a framework's scheduler thread as long as the code waits for the remote (or the network). But many bindings do it this way.

TravisBuddy · 2020-06-09T23:23:14Z

Travis tests were successful

Hey @SRGDamia1,
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 · 2020-06-21T21:22:45Z

Travis tests have failed

Hey @SRGDamia1,
please read the following log in order to understand the failure reason. There might also be some helpful tips along the way.
It will be awesome if you fix what is wrong and commit the changes.

TravisBuddy · 2020-06-22T16:34:17Z

Travis tests were successful

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

openhab-bot · 2020-09-21T00:30:59Z

Automatic code migration to openHAB 3 succeeded.

The resulting code can be found at https://ci.openhab.org/job/openHAB-Addons-Migration/78/artifact/bundles/.

You can download the migrated code from there and create a new PR against the master branch of the openhab-addons repo to contribute it for being included in openHAB 3.x.

Please see this issue about the details on how to proceed with your existing PR.

kaikreuzer · 2020-12-23T23:27:22Z

If I want to make the changes by hand, is there a proper way to merge/rebase/cherry pick commits onto the new shrunken repo?

This indeed need to be brought into a non-conflicting state. The easiest might be to check out the new 2.5.x branch, copy your code to it and do a single commit. Just name your branch bondhome (rename your old one first to have no name clash) and do a force push to Github.

Signed-off-by: Sara Damiano <[email protected]>

Mostly new null checks Signed-off-by: Sara Damiano <[email protected]>

Signed-off-by: Sara Damiano <[email protected]>

Hilbrand

Thank you for your contribution. The code looks great, I've made some general comments and some openHAB specific comments.
Additional, The readme needs to be written and please remove the jar file from this pr. If you want to provide a jar you can make a release on your GitHub fork of openHAB. This can be done on a branch. You can attach the jar file to this release. Than point people to this release tag page (not the jar). This gives a consist url. You can later edit the release and add an updated jar, without having to give a new url.

Also run mvn spotless:apply on your binding to auto-format the code, and also auto update the copyright year. (You might need to rebase to the latest code of this repo).

Hilbrand · 2020-09-04T21:22:14Z

...ing.bondhome/src/main/java/org/openhab/binding/bondhome/internal/BondHomeHandlerFactory.java

+@NonNullByDefault
+@Component(configurationPid = "binding.bondhome", service = ThingHandlerFactory.class)
+public class BondHomeHandlerFactory extends BaseThingHandlerFactory {
+    private Logger logger = LoggerFactory.getLogger(BondHomeHandlerFactory.class);


Suggested change

private Logger logger = LoggerFactory.getLogger(BondHomeHandlerFactory.class);

private final Logger logger = LoggerFactory.getLogger(BondHomeHandlerFactory.class);

Hilbrand · 2020-09-04T21:22:57Z

...b.binding.bondhome/src/main/java/org/openhab/binding/bondhome/internal/api/BPUPListener.java

+    private final Logger logger = LoggerFactory.getLogger(BPUPListener.class);
+
+    // To parse the JSON responses
+    private Gson gsonBuilder;


Suggested change

private Gson gsonBuilder;

private final Gson gsonBuilder;

Hilbrand · 2020-09-04T21:23:32Z

...b.binding.bondhome/src/main/java/org/openhab/binding/bondhome/internal/api/BPUPListener.java

+
+    public @Nullable String lastRequestId;
+    private long timeOfLastKeepAlivePacket;
+    private Boolean shutdown;


Suggested change

private Boolean shutdown;

private boolean shutdown;

Hilbrand · 2020-09-04T21:27:22Z

...nding.bondhome/src/main/java/org/openhab/binding/bondhome/internal/api/BondDeviceAction.java

+    // State Variables
+    // power: (integer) 1 = on, 0 = off
+    // Actions
+    TurnOn("TurnOn", CHANNEL_GROUP_COMMON, CHANNEL_POWER_STATE),


Enum's should be uppercase:

Suggested change

TurnOn("TurnOn", CHANNEL_GROUP_COMMON, CHANNEL_POWER_STATE),

TURN_ON("TurnOn", CHANNEL_GROUP_COMMON, CHANNEL_POWER_STATE),

Hilbrand · 2020-09-04T21:32:49Z

.../main/java/org/openhab/binding/bondhome/internal/discovery/BondMDNSDiscoveryParticipant.java

+ *
+ * @author Kai Kreuzer - Initial contribution
+ */
+@Component(service = MDNSDiscoveryParticipant.class, immediate = true)


Suggested change

@Component(service = MDNSDiscoveryParticipant.class, immediate = true)

@Component(service = MDNSDiscoveryParticipant.class, configurationPid="discovery.mdns.bondhome")

Hilbrand · 2021-01-02T22:29:50Z

....bondhome/src/main/java/org/openhab/binding/bondhome/internal/handler/BondDeviceHandler.java

+            logger.info("Current version is {}, prior version was {}.", CURRENT_BINDING_VERSION, lastBindingVersion);
+
+            // Update the thing with the new property value
+            final Map<String, String> newProperties = new HashMap<>(thing.getProperties());


Suggested change

final Map<String, String> newProperties = new HashMap<>(thing.getProperties());

final Map<String, String> newProperties = editProperties();

Hilbrand · 2021-01-02T22:31:18Z

....bondhome/src/main/java/org/openhab/binding/bondhome/internal/handler/BondDeviceHandler.java

+            final ThingBuilder thingBuilder = editThing();
+            thingBuilder.withProperties(newProperties);
+            updateThing(thingBuilder.build());


Why not updateProperties(newProperties) here?

Hilbrand · 2021-01-02T22:34:49Z

....bondhome/src/main/java/org/openhab/binding/bondhome/internal/handler/BondDeviceHandler.java

+
+    private synchronized boolean wasThingUpdatedExternally(BondDevice devInfo) {
+        // Check if the Bond hash tree has changed
+        config = getConfigAs(BondDeviceConfiguration.class);


When the config changes initialize is called again and that already sets the config. Therefor it's not needed to set config again here? Or did I miss some behavior here?

Hilbrand · 2021-01-02T22:38:19Z

....bondhome/src/main/java/org/openhab/binding/bondhome/internal/handler/BondDeviceHandler.java

+                if (api == null) {
+                    updateStatus(ThingStatus.OFFLINE, ThingStatusDetail.COMMUNICATION_ERROR,
+                            "Bridge API not available");
+                    initialize();


It should not be needed to call initialize here. If some code in initialize needs to be called this should be put into a separate method. initialize is generally called when the thing itself is initialized by openHAB. So the binding should not do that itself.

Hilbrand · 2021-01-02T22:40:15Z

....bondhome/src/main/java/org/openhab/binding/bondhome/internal/handler/BondDeviceHandler.java

+            logger.trace("Update Time for {}: {}", this.getThing().getLabel(), (new DateTimeType()).toFullString());
+
+            updateState(CHANNEL_POWER_STATE, updateState.power == 0 ? OnOffType.OFF : OnOffType.ON);
+            updateState("timer", new DecimalType(updateState.timer));


Put timer in a constant, like the other channels?

kaikreuzer · 2021-09-20T05:41:02Z

No feedback since January, so I guess we should close this. If anyone picks it up in future, I'm happy to re-open the PR again.

from openhab#7260 Signed-off-by: Cody Cutrer <[email protected]>

openhab-bot · 2022-09-29T19:13:00Z

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/bond-home-bondhome-io/46654/62

* First commit on newly created branch, taking code from c8b8e21 * [bondhome] update snapshot version, and some typos * [bondhome] Address (most) comments from prior review from #7260 * [bondhome] simplify channels * lastUpdate is unnecessary; turn on persistence or add a rule on update if you care to keep track of it * use a single string command channel for all shoot-and-forget commands, instead of multiple switch channels * use a rollershutter channel for shades (accepting UP, DOWN, STOP, 0%, and 100%) * on all dimmer channels, accept ON and OFF, as well as 0% to imply OFF, instead of having to write rules to control ON/OFF state separately. * if the dimmer channel exists, prune the corresponding power channel, since the dimmer channel is now a pure superset of its functionality * overload fan#speed to be ceiling fan or a fireplace's fan, depending on the device type * [bondhome] add bundle to the BOM pom * [bondhome] clean up BondDeviceHandler a bit * there's no need to delay initialization; ThingManager won't even attempt to initialize a child thing until its bridge is online * Remove some extra initialization checks that can never be false * slightly refactor some methods to return early, rather than nest a giant `else` * remove some info logging that will get triggered in normal usage * [bondhome] fix bridge discovery * Bridge property and config serial number need to be the same name * Don't arbitrarily delay the BPUPListener * Automatically update the IP if the BPUPListener finds it * Provide the new bridge with its discovered IP to avoid an additional DNS query * Don't get the bridge version after every keep-alive response * [bondhome] trigger end-device discovery as soon as the bridge comes online * [bondhome] remove internal binding version * [bondhome] change addr property to string Certain values seen in the wild when interpreted as a long are too big for that storage. Also, the Bond API documentation describes the addr property on a device to be a string. OpenHAB already has infrastructure to have things update their channel definitions when a binding is updated. * [bondhome] ignore any device that starts with _ In v3 of their API, Bond added a new special entry of __. Because no valid device id would start with an underscore, ignore everything that starts with an underscore to fix v3 and maybe futureproof. * address review comments mostly adding i18n to error states, and cleaning up error handling of HTTP requests. * use builtin translation services instead of plumbing our own provider through * use System.nanoTime instead of currentTimeMillis so that it will be a monotonic clock, not (as) susceptible to the clock changing * [bondhome] ignore BPUP messasges that aren't state In recent firmware, bond is now sending action messages via BPUP as well as state. This change ignores all messages that aren't state. * [bondhome] Improve error handling, and remove dummy constants Just use a single BondException class to communicate any sort of error from within bond, and avoid throwing, catching, and re-throwing the same (or slightly modified) exception. Also remove dummy constants that might give the wrong impression of the details of your Bond device. Then implement proper null checks, especially setting a configuration error if key config properties aren't set on the thing. * [bondhome] avoid setting device status when bridge just went offline * address static analysis tool problems Also-by: Sara Damiano <[email protected]> Also-by: Keith T. Garner <[email protected]> Signed-off-by: Cody Cutrer <[email protected]>

* First commit on newly created branch, taking code from c8b8e21 * [bondhome] update snapshot version, and some typos * [bondhome] Address (most) comments from prior review from openhab#7260 * [bondhome] simplify channels * lastUpdate is unnecessary; turn on persistence or add a rule on update if you care to keep track of it * use a single string command channel for all shoot-and-forget commands, instead of multiple switch channels * use a rollershutter channel for shades (accepting UP, DOWN, STOP, 0%, and 100%) * on all dimmer channels, accept ON and OFF, as well as 0% to imply OFF, instead of having to write rules to control ON/OFF state separately. * if the dimmer channel exists, prune the corresponding power channel, since the dimmer channel is now a pure superset of its functionality * overload fan#speed to be ceiling fan or a fireplace's fan, depending on the device type * [bondhome] add bundle to the BOM pom * [bondhome] clean up BondDeviceHandler a bit * there's no need to delay initialization; ThingManager won't even attempt to initialize a child thing until its bridge is online * Remove some extra initialization checks that can never be false * slightly refactor some methods to return early, rather than nest a giant `else` * remove some info logging that will get triggered in normal usage * [bondhome] fix bridge discovery * Bridge property and config serial number need to be the same name * Don't arbitrarily delay the BPUPListener * Automatically update the IP if the BPUPListener finds it * Provide the new bridge with its discovered IP to avoid an additional DNS query * Don't get the bridge version after every keep-alive response * [bondhome] trigger end-device discovery as soon as the bridge comes online * [bondhome] remove internal binding version * [bondhome] change addr property to string Certain values seen in the wild when interpreted as a long are too big for that storage. Also, the Bond API documentation describes the addr property on a device to be a string. OpenHAB already has infrastructure to have things update their channel definitions when a binding is updated. * [bondhome] ignore any device that starts with _ In v3 of their API, Bond added a new special entry of __. Because no valid device id would start with an underscore, ignore everything that starts with an underscore to fix v3 and maybe futureproof. * address review comments mostly adding i18n to error states, and cleaning up error handling of HTTP requests. * use builtin translation services instead of plumbing our own provider through * use System.nanoTime instead of currentTimeMillis so that it will be a monotonic clock, not (as) susceptible to the clock changing * [bondhome] ignore BPUP messasges that aren't state In recent firmware, bond is now sending action messages via BPUP as well as state. This change ignores all messages that aren't state. * [bondhome] Improve error handling, and remove dummy constants Just use a single BondException class to communicate any sort of error from within bond, and avoid throwing, catching, and re-throwing the same (or slightly modified) exception. Also remove dummy constants that might give the wrong impression of the details of your Bond device. Then implement proper null checks, especially setting a configuration error if key config properties aren't set on the thing. * [bondhome] avoid setting device status when bridge just went offline * address static analysis tool problems Also-by: Sara Damiano <[email protected]> Also-by: Keith T. Garner <[email protected]> Signed-off-by: Cody Cutrer <[email protected]> Signed-off-by: Ben Rosenblum <[email protected]>

* First commit on newly created branch, taking code from c8b8e21 * [bondhome] update snapshot version, and some typos * [bondhome] Address (most) comments from prior review from openhab#7260 * [bondhome] simplify channels * lastUpdate is unnecessary; turn on persistence or add a rule on update if you care to keep track of it * use a single string command channel for all shoot-and-forget commands, instead of multiple switch channels * use a rollershutter channel for shades (accepting UP, DOWN, STOP, 0%, and 100%) * on all dimmer channels, accept ON and OFF, as well as 0% to imply OFF, instead of having to write rules to control ON/OFF state separately. * if the dimmer channel exists, prune the corresponding power channel, since the dimmer channel is now a pure superset of its functionality * overload fan#speed to be ceiling fan or a fireplace's fan, depending on the device type * [bondhome] add bundle to the BOM pom * [bondhome] clean up BondDeviceHandler a bit * there's no need to delay initialization; ThingManager won't even attempt to initialize a child thing until its bridge is online * Remove some extra initialization checks that can never be false * slightly refactor some methods to return early, rather than nest a giant `else` * remove some info logging that will get triggered in normal usage * [bondhome] fix bridge discovery * Bridge property and config serial number need to be the same name * Don't arbitrarily delay the BPUPListener * Automatically update the IP if the BPUPListener finds it * Provide the new bridge with its discovered IP to avoid an additional DNS query * Don't get the bridge version after every keep-alive response * [bondhome] trigger end-device discovery as soon as the bridge comes online * [bondhome] remove internal binding version * [bondhome] change addr property to string Certain values seen in the wild when interpreted as a long are too big for that storage. Also, the Bond API documentation describes the addr property on a device to be a string. OpenHAB already has infrastructure to have things update their channel definitions when a binding is updated. * [bondhome] ignore any device that starts with _ In v3 of their API, Bond added a new special entry of __. Because no valid device id would start with an underscore, ignore everything that starts with an underscore to fix v3 and maybe futureproof. * address review comments mostly adding i18n to error states, and cleaning up error handling of HTTP requests. * use builtin translation services instead of plumbing our own provider through * use System.nanoTime instead of currentTimeMillis so that it will be a monotonic clock, not (as) susceptible to the clock changing * [bondhome] ignore BPUP messasges that aren't state In recent firmware, bond is now sending action messages via BPUP as well as state. This change ignores all messages that aren't state. * [bondhome] Improve error handling, and remove dummy constants Just use a single BondException class to communicate any sort of error from within bond, and avoid throwing, catching, and re-throwing the same (or slightly modified) exception. Also remove dummy constants that might give the wrong impression of the details of your Bond device. Then implement proper null checks, especially setting a configuration error if key config properties aren't set on the thing. * [bondhome] avoid setting device status when bridge just went offline * address static analysis tool problems Also-by: Sara Damiano <[email protected]> Also-by: Keith T. Garner <[email protected]> Signed-off-by: Cody Cutrer <[email protected]> Signed-off-by: Andras Uhrin <[email protected]>

* First commit on newly created branch, taking code from c8b8e21 * [bondhome] update snapshot version, and some typos * [bondhome] Address (most) comments from prior review from openhab#7260 * [bondhome] simplify channels * lastUpdate is unnecessary; turn on persistence or add a rule on update if you care to keep track of it * use a single string command channel for all shoot-and-forget commands, instead of multiple switch channels * use a rollershutter channel for shades (accepting UP, DOWN, STOP, 0%, and 100%) * on all dimmer channels, accept ON and OFF, as well as 0% to imply OFF, instead of having to write rules to control ON/OFF state separately. * if the dimmer channel exists, prune the corresponding power channel, since the dimmer channel is now a pure superset of its functionality * overload fan#speed to be ceiling fan or a fireplace's fan, depending on the device type * [bondhome] add bundle to the BOM pom * [bondhome] clean up BondDeviceHandler a bit * there's no need to delay initialization; ThingManager won't even attempt to initialize a child thing until its bridge is online * Remove some extra initialization checks that can never be false * slightly refactor some methods to return early, rather than nest a giant `else` * remove some info logging that will get triggered in normal usage * [bondhome] fix bridge discovery * Bridge property and config serial number need to be the same name * Don't arbitrarily delay the BPUPListener * Automatically update the IP if the BPUPListener finds it * Provide the new bridge with its discovered IP to avoid an additional DNS query * Don't get the bridge version after every keep-alive response * [bondhome] trigger end-device discovery as soon as the bridge comes online * [bondhome] remove internal binding version * [bondhome] change addr property to string Certain values seen in the wild when interpreted as a long are too big for that storage. Also, the Bond API documentation describes the addr property on a device to be a string. OpenHAB already has infrastructure to have things update their channel definitions when a binding is updated. * [bondhome] ignore any device that starts with _ In v3 of their API, Bond added a new special entry of __. Because no valid device id would start with an underscore, ignore everything that starts with an underscore to fix v3 and maybe futureproof. * address review comments mostly adding i18n to error states, and cleaning up error handling of HTTP requests. * use builtin translation services instead of plumbing our own provider through * use System.nanoTime instead of currentTimeMillis so that it will be a monotonic clock, not (as) susceptible to the clock changing * [bondhome] ignore BPUP messasges that aren't state In recent firmware, bond is now sending action messages via BPUP as well as state. This change ignores all messages that aren't state. * [bondhome] Improve error handling, and remove dummy constants Just use a single BondException class to communicate any sort of error from within bond, and avoid throwing, catching, and re-throwing the same (or slightly modified) exception. Also remove dummy constants that might give the wrong impression of the details of your Bond device. Then implement proper null checks, especially setting a configuration error if key config properties aren't set on the thing. * [bondhome] avoid setting device status when bridge just went offline * address static analysis tool problems Also-by: Sara Damiano <[email protected]> Also-by: Keith T. Garner <[email protected]> Signed-off-by: Cody Cutrer <[email protected]>

* First commit on newly created branch, taking code from c8b8e21 * [bondhome] update snapshot version, and some typos * [bondhome] Address (most) comments from prior review from openhab#7260 * [bondhome] simplify channels * lastUpdate is unnecessary; turn on persistence or add a rule on update if you care to keep track of it * use a single string command channel for all shoot-and-forget commands, instead of multiple switch channels * use a rollershutter channel for shades (accepting UP, DOWN, STOP, 0%, and 100%) * on all dimmer channels, accept ON and OFF, as well as 0% to imply OFF, instead of having to write rules to control ON/OFF state separately. * if the dimmer channel exists, prune the corresponding power channel, since the dimmer channel is now a pure superset of its functionality * overload fan#speed to be ceiling fan or a fireplace's fan, depending on the device type * [bondhome] add bundle to the BOM pom * [bondhome] clean up BondDeviceHandler a bit * there's no need to delay initialization; ThingManager won't even attempt to initialize a child thing until its bridge is online * Remove some extra initialization checks that can never be false * slightly refactor some methods to return early, rather than nest a giant `else` * remove some info logging that will get triggered in normal usage * [bondhome] fix bridge discovery * Bridge property and config serial number need to be the same name * Don't arbitrarily delay the BPUPListener * Automatically update the IP if the BPUPListener finds it * Provide the new bridge with its discovered IP to avoid an additional DNS query * Don't get the bridge version after every keep-alive response * [bondhome] trigger end-device discovery as soon as the bridge comes online * [bondhome] remove internal binding version * [bondhome] change addr property to string Certain values seen in the wild when interpreted as a long are too big for that storage. Also, the Bond API documentation describes the addr property on a device to be a string. OpenHAB already has infrastructure to have things update their channel definitions when a binding is updated. * [bondhome] ignore any device that starts with _ In v3 of their API, Bond added a new special entry of __. Because no valid device id would start with an underscore, ignore everything that starts with an underscore to fix v3 and maybe futureproof. * address review comments mostly adding i18n to error states, and cleaning up error handling of HTTP requests. * use builtin translation services instead of plumbing our own provider through * use System.nanoTime instead of currentTimeMillis so that it will be a monotonic clock, not (as) susceptible to the clock changing * [bondhome] ignore BPUP messasges that aren't state In recent firmware, bond is now sending action messages via BPUP as well as state. This change ignores all messages that aren't state. * [bondhome] Improve error handling, and remove dummy constants Just use a single BondException class to communicate any sort of error from within bond, and avoid throwing, catching, and re-throwing the same (or slightly modified) exception. Also remove dummy constants that might give the wrong impression of the details of your Bond device. Then implement proper null checks, especially setting a configuration error if key config properties aren't set on the thing. * [bondhome] avoid setting device status when bridge just went offline * address static analysis tool problems Also-by: Sara Damiano <[email protected]> Also-by: Keith T. Garner <[email protected]> Signed-off-by: Cody Cutrer <[email protected]> Signed-off-by: Andras Uhrin <[email protected]>

cpmeister added the new binding If someone has started to work on a binding. For a new binding PR. label Mar 31, 2020

cpmeister changed the title ~~New binding: Bond Home~~ [bondhome] New binding: Bond Home Mar 31, 2020

fwolter requested changes May 21, 2020

View reviewed changes

SRGDamia1 force-pushed the bondhome branch from 6e16765 to 86cea49 Compare June 7, 2020 04:37

SRGDamia1 requested a review from a team as a code owner June 7, 2020 04:37

SRGDamia1 force-pushed the bondhome branch from 5e9723e to 2c5baa4 Compare June 7, 2020 05:26

kaikreuzer force-pushed the 2.5.x branch from 536fc42 to 3ab1af1 Compare June 21, 2020 16:12

SRGDamia1 force-pushed the bondhome branch from d770c0c to bb3784d Compare June 22, 2020 16:30

kaikreuzer added migrate to OH3 and removed migrate to OH3 labels Sep 21, 2020

SRGDamia1 added migrate to OH3 and removed migrate to OH3 labels Dec 23, 2020

SRGDamia1 mentioned this pull request Dec 23, 2020

Migrating existing PRs to "main" branch for openHAB 3 #8512

Closed

SRGDamia1 changed the base branch from 2.5.x to main December 28, 2020 02:01

SRGDamia1 force-pushed the bondhome branch from b57e495 to 3daa21a Compare December 28, 2020 02:04

SRGDamia1 added 3 commits January 1, 2021 20:53

First commit on newly created branch, taking code from c8b8e21

cea0e75

Signed-off-by: Sara Damiano <[email protected]>

Some changes based on java 11

1db06d0

Mostly new null checks Signed-off-by: Sara Damiano <[email protected]>

Version bump

0532cad

Signed-off-by: Sara Damiano <[email protected]>

SRGDamia1 force-pushed the bondhome branch from cfb758c to 0532cad Compare January 2, 2021 01:53

New jar

47aa3b2

Signed-off-by: Sara Damiano <[email protected]>

Hilbrand requested changes Jan 2, 2021

View reviewed changes

kaikreuzer removed the migrate to OH3 label Jan 12, 2021

cpmeister added the awaiting feedback Awaiting feedback from the pull request author label Feb 7, 2021

hmerk added the stale As soon as a PR is marked stale, it can be removed 6 months later. label Aug 11, 2021

kaikreuzer closed this Sep 20, 2021

ccutrer added a commit to ccutrer/openhab-addons that referenced this pull request Sep 29, 2022

[bondhome] Address (most) comments from prior review

f570631

from openhab#7260 Signed-off-by: Cody Cutrer <[email protected]>

ccutrer mentioned this pull request Sep 29, 2022

[bondhome] Initial contribution #13459

Merged

		\| shadeChannels \| openShade \| Switch \| Opens or closes motorize shades \| Motor Shades \|
		\| shadeChannels \| hold \| Switch \| Tells a device to stop moving \| Motor Shades \|

	private Logger logger = LoggerFactory.getLogger(BondHomeHandlerFactory.class);
	private final Logger logger = LoggerFactory.getLogger(BondHomeHandlerFactory.class);

	TurnOn("TurnOn", CHANNEL_GROUP_COMMON, CHANNEL_POWER_STATE),
	TURN_ON("TurnOn", CHANNEL_GROUP_COMMON, CHANNEL_POWER_STATE),

	@Component(service = MDNSDiscoveryParticipant.class, immediate = true)
	@Component(service = MDNSDiscoveryParticipant.class, configurationPid="discovery.mdns.bondhome")

	final Map<String, String> newProperties = new HashMap<>(thing.getProperties());
	final Map<String, String> newProperties = editProperties();

[bondhome] New binding: Bond Home #7260

[bondhome] New binding: Bond Home #7260

Conversation

SRGDamia1 commented Mar 31, 2020

New Binding for Bond Home bridge and devices

TravisBuddy commented Mar 31, 2020

Travis tests were successful

TravisBuddy commented Mar 31, 2020

Travis tests were successful

TravisBuddy commented Mar 31, 2020

Travis tests were successful

TravisBuddy commented Mar 31, 2020

Travis tests were successful

digitaldan commented Mar 31, 2020

SRGDamia1 commented Mar 31, 2020

TravisBuddy commented Mar 31, 2020

Travis tests were successful

SRGDamia1 commented Apr 1, 2020

TravisBuddy commented Apr 1, 2020

Travis tests were successful

TravisBuddy commented Apr 2, 2020

Travis tests were successful

TravisBuddy commented Apr 4, 2020

Travis tests were successful

fwolter left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TravisBuddy commented Jun 7, 2020

Travis tests have failed

TravisBuddy commented Jun 7, 2020

Travis tests have failed

TravisBuddy commented Jun 7, 2020

Travis tests have failed

TravisBuddy commented Jun 7, 2020

Travis tests have failed

SRGDamia1 commented Jun 7, 2020

TravisBuddy commented Jun 7, 2020

Travis tests were successful

TravisBuddy commented Jun 7, 2020

Travis tests were successful

fwolter commented Jun 7, 2020

TravisBuddy commented Jun 9, 2020

Travis tests were successful

TravisBuddy commented Jun 21, 2020

Travis tests have failed

TravisBuddy commented Jun 22, 2020

Travis tests were successful

openhab-bot commented Sep 21, 2020

kaikreuzer commented Dec 23, 2020

Hilbrand left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Hilbrand Sep 4, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kaikreuzer commented Sep 20, 2021

openhab-bot commented Sep 29, 2022

Hilbrand Sep 4, 2020 •

edited

Loading