In an attempt to develop a native Insteon PLM binding for OH2 I tried to install the IDE. The development machine is a laptop with Ubuntu 16.04 installed, with Oracle Java8.
Compilation fails with "plugin execution not covered by lifecycle configuration"
then something about maven (which I have installed), and something about line 8 of pom.xml
I don’t ever use Eclipse for anything but OpenHAB development, and I hate it. It’s bloated, slow, and it’s not Emacs. Plus it takes me into a build environment that I’m totally unfamiliar with, that produces cryptic error messages that I have intuition for what they mean. This was a real headache with OH1, and it seems to be no less so for OH2. So now I’ll be the total noob and have to beg for help every time this complex environment throws me a curve ball, see above.
For OH1, the happiest day was when I discovered that I can throw the whole yoxos and IDE stuff out the window and just edit the source files directly, use mvn install (or was it mvn build, whatever). Maven would still try to download a bazillion files and fail in random places, but at least the error messages where useful enough to get it going.
After this long preamble: does anybody have cook book style instructions on how to develop a new binding without using Eclipse?
OK, looks like just git cloning the openhab2-addons repository and running “mvn clean install” works.
I’ve been able to use and compile plugins out of eclipse (with mvn install I think).
But why making our life harder when eclipse offer a welcome simplification (and some rules to fit the standards set by OpenHab2 like code formatting)?
Did you start the OH2 insteon binding? I just loaded the OH2 addons into eclipse and it doesn’t look like an insteon binding has been creayed yet.
Would you be interested in collaborating on this? Perhaps you have a plan of attack?
I use IDEA and build w/
mvn install. Works mostly fine.
I forked the oh2 addons:
And have managed to produce some skeleton code. Not yet pushed into the repo, so you won’t find anything there yet.
I’m still trying to understand how OH2 interacts with the bindings. I wanted to work on it over Christmas but got very little done due to other commitments.
I did the same. I’ll defer to your lead on this since you have much more experience with Insteon than I, but let me know if you want help with some code or you want me to research something.
I’m still trying to get my head around the openHAB terminology though.
I think that:
A “Thing” for Insteon would be a device you can buy such as a hub or a dimmer.
Then each thing as one or more “Channels”. A “Channel” seems to be like a device capability so a simple switch would have only one channel of type “Switch” whereas a sprinkler controller would have say 8 channels, one for each zone.
An “Item” is some piece of information that a “Channel” reports.
A “Sitemap” is basically a way to group various “Items”.
Do I have that about right?
@Bernd_Pfrommer Just wondering if you got anywhere with the OH2 2.x insteon binding?
Looks like the next version of OH will drop all the OH1 bindings, and Insteon compatibility with it. Most of my house is Insteon, lighting, switches etc. etc. and I have been relying on the OH1 binding for several years now.
I have been working on an Insteon to MQTT bridge with some others for a while, which is a kind of fall back plan for when OH goes away, but a 2.x binding would solve the immediate issue.
Any chance of reviving this project/
Hi, at the risk of being repetitive, as I have said this before, I would look at the ISY99 controller. Having been an Insteon user since the very first days, I have found the ISY99 to be a blessing for Insteon Network management. If you have a large network of devices, you need a way to create and manage scenes, replace broken devices and to keep the link databases intact. That is hard to achieve without the ISY99. There really isn’t any other device that can do that (AFAIK).
As far as losing OH1 bindings, that isn’t going to happen anytime soon, if ever.
Here’s the story: I started writing an OH2 version, but only a few hours into the work I gave up in despair. I have no idea how the framework works, let alone the eclipse environment. And the real reason that I don’t want to sink any more time into OH is that
- The OH1 Insteon code is a pile of crap that reflects me discovering one by one all the quirks and gotchas of the Insteon protocol. It should be completely rewritten for OH2.
- OH is structurally flawed since it is not network centric, but ties the binding developers into Java, a language that I don’t use otherwise.
So yes, I think a network based approach like MQTT is the way to go, but even for that I have very little time now. And in the end, I’m not sure how well OH2 will play with the MQTT binding.
I may just look at the ISY99 controller and see if that one suffices.
Yes, I hear you. I don’t use Java either, and the development environment for OH is so complex I’m amazed that anyone can make it work - which is why I can’t do this myself.
Knowing all the flaws and quirks is why not just anyone can write a successful Insteon Interface.
So I think going back to the Insteon-mqtt bridge is probably the only real long term solution (short of jumping to another platform).
Thanks for the update.