For me personally it was some effort to get the binding accepted. However, I learned a lot during the process! To get something “working” can be totally diferent to make something work like it should work (that way other are able to take-over afterwards).
As for the marketplace, your binding could be used by others the same way as you posted without even publishing it on the marketplace. When you publish your (intermediate) work on github and file a pull request (PR), other can see the code and take the .jar from there.
As for your crazy idea: This “some sort of loose organization” is the open source community, which works only if people are wiling to contribute, no one “makes” them do it. If YOU decide to contribute, YOU do, if not…
It is certainly to be expected that there’s always room for code improvement, especially when it involves a project as complicated as OpenHAB. My primary concern is good stewardship of my limited time: I don’t want to go down a potentially endless tunnel trying to contribute something officially and have it end up going nowhere. I’ve been there before and it’s pretty unsatisfying. It’s certainly fair to argue that I may have too many irons in the fire, as the saying goes, but it’s the unfortunate reality I inhabit.
It’s possible the roadblock I ran into when submitting things to the IOT marketplace was easily resolved, but I just haven’t gotten back to it. I think that the market place is a good middle ground: making things visible and easily install-able without having the potential overhead (or hassle if you are a cynic) of contributing it directly to openhab/esh. It would be especially nice if there were a maven plugin that could facilitate publishing once a new version was validated…
My crazy idea was really about suggesting an opportunity for division of labor… especially if there are people who want to help but who don’t consider themselves coders. I’ve written a bunch of code that others may or do find helpful and have made it easily available, which I think is a meaningful contribution. I’m not not sure it makes sense for me personally to spend the time required from taking these bindings from “drop it in your addons folder” to showing up in the IOT marketplace or having it incorporated as part of the openhab or esh distribution.
I hope that this doesn’t sound like I’m not interested in participating in the openhab community; far from it. I’m just trying to find the balance that works for me (so that I don’t ignore the others that I contribute to).
The only thing I will add to opus’s comments is if you release a binding to the IoT Marketplace you probably drop your audience of potential users down to 10-20% of all OH users. If you distribute it yourself like this the audience of potential users probably drops below 1%.
If you want this binding to actually be used and useful for the wider OH community, it will need to be at least made available in the IoT Marketplace.
If you are worried about whether or not the binding would be accepted create a new issue, mark it as WIP and discuss it there.
This is admittedly an unusual binding and the ESH folks may already have an alternative way to integrate capabilities like this that do not involve bindings.
For me, there are not enough docs and examples here or at Bitbucket to test it out.
Well, if you consider that every weather app provides measurements derived from the basic observations, it’s not that unusual to want to save each weather station binding from having to implement them all. It’s possible that the way I chose to solve the problem is a bit unusual in the larger scope of things OpenHAB-wise, but it seems to solve the problem in a fairly elegant way. I’m not aware of another approach used elsewhere (and there is an open discussion about how to provide this sort of facility).
Size of audience isn’t really something I’m terribly concerned about; it’s nice if people find it useful and all, but if not, that’s okay, too. If someone else feels strongly enough that they want to take a role in expanding its visibility, I’m open to hearing from them.
It’s still a work in progress, so formal documentation isn’t ready yet. However, there really isn’t much to explain about its use, it’s installed and added in the standard way, and the configuration values are pretty self explanatory. The only potentially complicated thing is that you have to provide the names of the Channels that provide the data to be used in calculations. You will have to copy the channel name for temperature/pressure/etc from the appropriate thing… it will vary depending on what weather sensors you are using.
For example, my temperature item is called weatherflowsmartweather:air:HB-000XXXXX:AR-00XXXXX:temperature.
That is all I meant. And because of that there might be a different approach that the maintainers are working towards. There is in work a units conversion service (e.g. separates out conversion between C and F for example) and they might feel that is more appropriate there. That is why I recommended opening an issue labeled as WIP.
Since you have no interest in going through the effort the whole argument is moot anyway.
I don’t use PaperUI for this sort of thing. So how do I write a Thing in a .things file? I’m assuming that your “then add an instance of a Weather Calculations thing” is referring to that. There are at least five different ways to add a Thing in OH.
But again, the argument is moot. I’m just here to help out where I can. I like the idea of this binding but have no use for it personally.
But that is just my point. I think lots and lots of people would find the binding incredibly useful. But only making it available in this way cuts off that vast majority of those people from being able to benefit.
I’ve uploaded a new snapshot of the Weather Calculations module.
Some new features:
Supports Units of Measurement, so should be able to display data in Metric or Imperial units.
Includes a first attempt to provide Atmospheric Pressure Trend
Should be possible to specify the various data sources using Channel ID (ie the identifier visible in PaperUI with colons) or Item Name (which appear in the log files and separate components with underscores).
This version requires OpenHAB 2.3. As always, comments and suggestions are welcome!
The Event warning is harmless. It’s a side effect of a feature that isn’t completely finished yet [the ability to support multiple Weather Calculation things, for multiple weather stations]. Restarting the bundle should make it go away. I’ve put a temporary Event filter clear in the code so that future test versions shouldn’t generate this message.
I’m still working on the binding, and putting those messages in TRACE would cause a lot of other messages to be generated that I don’t necessarily want to have filling the logs. When major development is finished, those messages will be set down to debug.
I’ve uploaded a new version of this binding… it fixes a few minor problems, adds a pick list for source Item selection, and adds support for i18n (translations), though english is the only language I have included. Translation assistance is welcome, please drop me a note if you’d like to help.
Note: It’s possible you may have to remove and re-add your Weather Calculation thing as some of the channel data has changed. Hopefully this is the last time that will happen.
The download url is listed earlier in this conversation.
I have, but have not had time to make a new build: I’m out of town and will be back in about a week. If you have the JDK and Maven installed, you can produce a build; the project is designed so that these are the only things required. Just run the command “mvn clean package” from the project directory and the binding will be produced in the “target” directory.
I actually just had a few moments and have uploaded a version that (hopefully) has less logging. Please give it a try and let me know what you think. The only change in this version of the JAR should be less logging.