52b7b7981f
* First commit on newly created branch, taking code from c8b8e210dfd23f98526763782eadbca49509baf9 * [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 <sdamiano@stroudcenter.org> Also-by: Keith T. Garner <kgarner@kgarner.com> Signed-off-by: Cody Cutrer <cody@cutrer.us> |
||
|---|---|---|
| .github | ||
| bom | ||
| bundles | ||
| features | ||
| itests | ||
| licenses/epl-2.0 | ||
| src/etc | ||
| tools/static-code-analysis/checkstyle | ||
| .gitattributes | ||
| .gitignore | ||
| CODEOWNERS | ||
| CONTRIBUTING.md | ||
| LICENSE | ||
| README.md | ||
| crowdin.yml | ||
| logo.png | ||
| pom.xml | ||
README.md
openHAB Add-ons
This repository contains the official set of add-ons that are implemented on top of openHAB Core APIs. Add-ons that got accepted in here will be maintained (e.g. adapted to new core APIs) by the openHAB Add-on maintainers.
To get started with binding development, follow our guidelines and tutorials over at https://www.openhab.org/docs/developer.
If you are interested in openHAB Core development, we invite you to come by on https://github.com/openhab/openhab-core.
Add-ons in other repositories
Some add-ons are not in this repository, but still part of the official openHAB distribution. An incomplete list of other repositories follows below:
- https://github.com/openhab/org.openhab.binding.zwave
- https://github.com/openhab/org.openhab.binding.zigbee
- https://github.com/openhab/openhab-webui
Development / Repository Organization
openHAB add-ons are Java .jar files.
The openHAB build system is based on Maven. The official IDE (Integrated development environment) is Eclipse.
You find the following repository structure:
.
+-- bom Maven buildsystem: Bill of materials
| +-- openhab-addons Lists all extensions for other repos to reference them
| +-- ... Other boms
|
+-- bundles Official openHAB extensions
| +-- org.openhab.binding.airquality
| +-- org.openhab.binding.astro
| +-- ...
|
+-- features Part of the runtime dependency resolver ("Karaf features")
|
+-- itests Integration tests. Those tests require parts of the framework to run.
| +-- org.openhab.binding.astro.tests
| +-- org.openhab.binding.avmfritz.tests
| +-- ...
|
+-- src/etc Auxilary buildsystem files: The license header for automatic checks for example
+-- tools Static code analyser instructions
|
+-- CODEOWNERS This file assigns people to directories so that they are informed if a pull-request
would modify their add-ons.
Command line build
To build all add-ons from the command-line, type in:
mvn clean install
Most of the time you do not need to build all bindings, but only the binding you are working on.
To simply build only your binding use the -pl option.
For example to build only the astro binding:
mvn clean install -pl :org.openhab.binding.astro
If you have a binding that has dependencies that are dynamically as specified in the feature.xml you can create a .kar instead of a .jar file.
A .kar file will include the feature.xml and when added to openHAB will load and activate any dependencies specified in the feature.xml file.
To create a .kar file run maven with the goal karaf:kar:
mvn clean install karaf:kar -pl :org.openhab.binding.astro
To improve build times you can add the following options to the command:
| Option | Description |
|---|---|
-DskipChecks |
Skip the static analysis (Checkstyle, FindBugs) |
-DskipTests |
Skip the execution of tests |
-Dmaven.test.skip=true |
Skip the compilation and execution of tests |
-Dfeatures.verify.skip=true |
Skip the Karaf feature verification |
-Dspotless.check.skip=true |
Skip the Spotless code style checks |
-o |
Work offline so Maven does not download any updates |
-T 1C |
Build in parallel, using 1 thread per core |
-pl :<add-on directory> |
Build a single add-on |
For example you can skip checks and tests during development with:
mvn clean install -DskipChecks -DskipTests -pl :org.openhab.binding.astro
Adding these options improves the build time but could hide problems in your code. Parallel builds are also less easy to debug and the increased load may cause timing sensitive tests to fail.
Translations
Add-on translations are managed via Crowdin. The English translation is taken from the openHAB-addons GitHub repo and automatically imported in Crowdin when changes are made to the English i18n properties file. When translations are added or updated and approved in Crowdin, a pull request is automatically created by Crowdin. Therefore translations should not be edited in the openHAB-addons repo, but only in Crowdin. Otherwise translation are overridden by the automatic process.
To fill the English properties file run the following maven command on an add-on:
mvn i18n:generate-default-translations
This command can also update the file when things or channel are added or updated.
In some cases the command does not work, and requires the full plug-in name. In that case use:
mvn org.openhab.core.tools:i18n-maven-plugin:3.3.0:generate-default-translations
Code Quality
To check if your code is following the code style run:
mvn spotless:check
To reformat your code so it conforms to the code style you can run:
mvn spotless:apply
Integration Tests
When your add-on also has an integration test in the itests directory, you may need to update the runbundles in the itest.bndrun file when the Maven dependencies change.
Maven can resolve the integration test dependencies automatically by executing:
mvn clean install -DwithResolver -DskipChecks
The build generates a .jar file per bundle in the respective bundle /target directory.
How to develop via an Integrated Development Environment (IDE)
We have assembled some step-by-step guides for different IDEs on our developer documentation website:
https://www.openhab.org/docs/developer/#setup-the-development-environment
Happy coding!