New Binding Questions

Development Add-ons
1

I have mentioned that I would like to make sure that there is Insteon support in OH3. This means a 2.x series binding has to exist. I’m a software engineer, and I have Insteon and Java, I should be able to make this happen.

I have gotten the IDE downloaded and working, and used the skeleton to create a new binding - those changes seem to have stabilized, so I’m feeling like it might be possible to continue.

First question:

Is this forum the best place to talk to developers and ask development questions?

I haven’t done work with Java in ages, and never OSGi or even Maven (our Java project was a small part of a big Unix project, and used that project’s Makefiles because unix geeks) and have a lot of learning curve.

I’m reading everything I can find, some of which is even starting to make sense, but I’m sure I’ll need to ask a whole lot of simple stuff. I’d like to know the best places and ways to do that. IRC? Discord? Here? Elsewhere?

Second question:

For Insteon, would it make sense to change the name to insteon instead of insteonplm? If it supports all the same things as the old binding, it should support serial and the hubs, and the deprecated hub binding can be forgotten. I think it would also make migrating clearer, as the names will be different.

Third question:

Insteon is a fairly complicated binding. I’m considering doing a port of a well understood, stable binding first. I’d consider doing the alarmdecoder binding, for several reasons. (A> I have one. B> I want a 2.x binding for it. C> It has similar communication styles, IE Serial, network, or file., D> It’s a lot simpler than Insteon.)

Does doing a simpler binding to get used to the binding environment and OH communication make sense?

Fourth question:

Are there documents I haven’t found yet that describe the differences between a 1.x and 2.x binding, and might help in determining what parts of the old bindings I could reuse?

I know that asking more than one question means they don’t all get answered, but I’m trying not to fill the forum with a lot of one-liners.

2 Likes
2

It may if the simpler binding allows you get results quickly to encourage you to continue. I would just jump into Insteon and break it down into smaller chunks/goals.

I am looking at revamping the serial binding soonish so it is a good idea to write what your plans are in a thread that will catch other peoples attention and to give it time for others to see and post. I am yet to do this for the serial binding but shortly this will be the biggest blocking thing to get my house automated due to having created a huge custom protocol of my own that needs implementing.

The best place to start is to look at other bindings code that is similar and to have a play.

3

@Laufeyjarson welcome thanks for offer! I love the idea of converting insteon as I a an insteon user also!!

Can’t answer your questions but I can be part of the welcome aboard committee!

4

I’d definitely take that approach. There is a good learning curve that you will need to accomplish and that would be much easier with a simpler binding and then adding to that knowledge on a harder binding later…

5

@Laufeyjarson. I’m in a very similar position to you. I’m a C++/Unix guy and I’ve only taken a cursory look at Java and know very little about the Java environment, eg maven, OSGi and now bnd (and Gradle, Groovy, JUnit, etc, etc, etc…) and I don’t even use Eclipse that much. It’s a very steep learning curve with an ever expanding list of acronyms to look up.

Some time ago I started writing a 2.x binding for Insteon using an Eclipse UML modeling project called Papyrus and generating the code from the model. I didn’t get much further that logging in to the hub and getting some config information from it. Then everything changed again so I was waiting until it all calmed down which it seems to be doing now. In the meantime, I’ve been learning about Maven.

As for asking questions, I think the forum is the best place although my experience is that it is a bit “hit and miss” with getting answers. I’ve also tried IRC but that was no better.

I agree that the binding should just be called “Insteon”. I think the binding should be able to detect what it is connected to (exactly how is TBD) and report if the device is not supported.

As for your third question, my approach was to start with the basics and build up from there. First get the communications established. Next get and display some hub data. After that get device ping working, etc, etc.

I think that the documentation we need is out there but it’s not always easy to find.

I’ll help getting the binding to the OpenHAB 2/3 level whereever I can.

Steve

6

This is what the category is for and so far many developers have been successful in getting answers from maintainers in this category. I think it’s a good place. I can’t say if it’s the best place.

Traditionally the new binding has the same name as the old binding, though there are notable exceptions (e.g. Network Health 1.x became Network 2.x). Even if they have the same name, they are kept distinct by appending a 1 to the 1.x binding. You will find that all 1.x bindings have a 1 after their ID.

Personally, name it whatever makes the most sense for what the new binding does or is planned to do.

7

The reason I ask about Insteon, is that there is a deprecated insteonhub binding, and then the v1 insteonplm binding. insteonplm is also used for hubs now, which makes the name a little outdated. I thought a simpler “insteon” name would be best so that it could acknowledge it handles both.

I have noticed there is a 1 after the binding IDs, but I haven’t found where that happens. The Java seems to define the 1.x insteonplm module as insteonplm.

This means I can’t include alarmdecoder from openhab1-addons and alarmdecoder from openhab2-addons in the same Eclipse environment, which makes it trickier to keep the files open and read them side-by-side. Not a showstopper, just a little speed bump.

8

I think it happens as part of the build. Any binding that comes out of the openhab1-addons repo gets the on appended.

9

When a new OH2 versions of a OH1 binding is introduced the OH1 feature (in feature.xml) is moved to the legacy feature in the openhab1-addons repository and 1 is added to the feature name. I guess your mostly free to use the namespace that makes the most sense to you, works best for you, and using insteon seems perfectly fine.

To answer your 3rd and 4th question. I haven’t looked if there is documentation for migrating. But you should be able to reuse most logic. In a very short summary. The difference is that OH1 only works on items and OH2 with things. Configurations done in OH1 in files are typical moved to things in OH2. For example the insteon configuration of the hub is something that would be done in a Bridge. In general the whole binding interface with OH is different between OH1 and OH2. So I would start with a new project and add the code of the logic of the OH1 binding and rewrite the interfacing between the OH and the logic. In general OH classes/types, like status/command, have been replaced from the openhab namespace in OH1 to smarthome namespace in OH2. By replacing these imports it should give a good starting point. Most work might be to get the xml thing definitions. For the insteon binding, I think, the challenge will be to what to do with the way devices are specified in some custom xml vs the OH2 thing xmls.
Also for serial and http connections there have been changes since OH1 and the binding could be improved by using the new way (see other bindings, like DSMR for serial and look for HttpUtil/HttpClientFactory)

3 Likes
10

Lou, Hilbrand, is one of our most talented developers, I was hoping he would chime in with advise for you. He is also one of the binding reviewers so follow his advise!

1 Like
11

I have the IDE up and build running, and a skeleton created. I’ve spent all day reading the v1 insteonplm code, and another module or two that does serial to see how similar they are.

I’m sure I have a head full of half-understandings, and that as soon as I find the other halves it’ll make sense, but so far it’s just quiet befuddlement and the feeling of no progress. This is normal, I have to remind myself. It’s been a long time since I’ve used an environment I’m this unfamiliar with.

I’m sure I saw somewhere that plugins should not create threads, but the ones I’m seeing do. And now I can’t find that warning again. There’s been a docs update, and a bunch of the things I was reading all changed when I reloaded the page. :slight_smile:

On the hardware front, I also found my spare PLM and my test insteon switch and have those plugged in and ready to work with. I don’t have either the old hub or the new hub, but I’m nowhere near needing one yet. If I’m smart I’ll keep an eye on smarthome, amazon, and ebay to try and find a cheap one.

1 Like
12

@Laufeyjarson,
Assuming that your IDE is Eclipse, did you install from scratch or did you add whatever openHab needs to an existing installation? If it was the later would you share how you did this?

If you would like, I can give you my code that I developed for Insteon to get you started. It uses a bridge class for the hub. Also I’m not sure what is the best way to share code that is experimental.
Steve

13

The policy with threads is. If you have a short running task. For example to poll a device you should use schedule the task (calling a method) via the protected field scheduler in the parent class BaseThingHandler (or BaseBridgeHandler) of your handler. If you have a task that needs to wait for data you can create your own thread. Just make sure in case a dispose is called the thread is certainly stopped.

14

I installed from scratch, following the directions. That got me Eclipse and all the bits I needed, and the built. At one point, I started getting errors I didn’t understand, wiped it all, and did it again. Knowing how to open or build the config in an existing Eclipse might have been nice.

I did figure out how to have to instances of Eclipse running (as long as I don’t run out of RAM - old slow machine, grr) so that I can have both the v1 and v2 insteonplm modules open at the same time.

I’m always interested in seeing how people have solved this kind of problem. I’m making some progress, and think I understand what to do, but I’d be quite pleased to see what you have.

Have you got a github account? Can you just add it as a project there? Everyone on the Internet can see it, but it’s not a secret, so that should be okay. I can either browse it or clone it to my local machine to look at from there.

Thank you for that succinct description! It makes clear the things I’m seeing in the existing bindings. I’ll probably wind up with a thread receiving serial data and turning it into Insteon messages for the binding to process, and a thread taking messages from a send queue and then sending them out as the binary data Insteon needs. This is basically how the Insteon v1 binding works, and the documentation there gives several really good reasons for it to behave that way, and lets me re-use some of that existing and stable code.

1 Like