Reworking CUL Config

tarioch · January 18, 2016, 9:32pm

I would like to rework the way config is done in CUL Transport.

Any binding should allow the global configuration such as serial parameters and not each binding implement this on its own (e.g. intertechno binding does not implement baudrate, fs20 does)

In this I would like to get

and

done.

Is anyone else currently working in this area?
Should I just do the changes and send a pull request or is there interest for more up front discussion here?
Anything else besides what’s written here

github.com

openhab/openhab-distro/blob/master/CONTRIBUTING.md

# Contributing to openHAB

Before reporting an issue, please check the [openHAB forum](https://community.openhab.org) for solutions and help. More people will see your issue when it is posted in the forum and community members may be able to help you find known solutions/workarounds for your issue.

When no solution was found, use the table below to determine where your issue should be logged:

Issue | Where to report
------|----------------
Problems and feature requests for openHAB 1 addons | [openHAB1-addons](https://github.com/openhab/openhab1-addons/issues)
Problems and feature requests for openHAB 2 addons | [openHAB2-addons](https://github.com/openhab/openhab2-addons/issues)
Issues related to the runtime environment, IDE and packaging | [openHAB-distro](https://github.com/openhab/openhab-distro/issues)
Issues related to the core openHAB bundles that are not from Eclipse SmartHome | [openHAB-core](https://github.com/openhab/openhab-core/issues)
Issues related to Eclipse SmartHome addons and core runtime | [Eclipse SmartHome](https://github.com/eclipse/smarthome/issues)

But do not worry - if you are not clear, which category your issue belongs to - we will redirect you, if necessary.

## Contribution guidelines

### Pull requests are always welcome

This file has been truncated. show original

?

rlkoshak · January 19, 2016, 2:15am

This sounds like it would require changes to the core of openHAB 1. Development on the core of OH 1 has been frozen so this change is unlikely to be considered there. However, many changes are being made to how configuration is done in OH 2. Development discussions for OH 2 are taking place on the Eclipse SmartHome forum. That is probably a better place to ask this question.

Though I will admit I don’t use any of these bindings nor do I completely understand the problem or the proposed solution. But I do know if it touches the core, you need to discuss it on the OH 2 development forum.

tarioch · January 19, 2016, 6:19am

It actually doesn’t touch any of the core. There’s a transport bundle that the other bundle use and so that one plus the bundles using it would be touched.

dirkc · January 20, 2016, 7:17pm

Patrick,

I am using CUL with FHT, FS20, among others. Unfortunately I am not able to get the IDE up and running, so do you plan to enhance the FHT binding, too? If so, I have some requirements and I will offer support with testing and analysis of missing features.

tarioch · January 21, 2016, 7:17pm

My first goal is to at least clean up the config to allow me to configure serial parameters for intertechno. Depending on my time I could probably help doing some other changes if needed, but I only have hardware for intertechno right now.

tarioch · January 21, 2016, 10:14pm

I started now on the refactoring

https://github.com/openhab/openhab/compare/master...tarioch:2358_configurable_serial_settings_for_cul?expand=1

would be great to get some feedback.

I’m also thinking to move the device name into the CULConfig as well that way everything that’s part of the common CUL layer is handled there instead of in each binding. In addition this would make it possible to run some validation based on the type already when the config is done instead of only when the CULHandler is created.