OH2 is a little different - it has some different concepts (eg Things), but, if you’re using an OH1 binding, then it will work the same way as it does in OH1…
Let’s cover this point first…
If these are OH1 bindings, and by “show up” you mean you want to see them in the bindings list in the UI, then you won’t see this. As above, an OH1 binding will only do what it does in OH1 - so in this case, it doesn’t show up in the OH2 bindings list in the UI. Likewise, items needs to be configured in the same way as they are in OH1 - ie by manually editing the items text files.
Things are devices (or something else that could be physical, or maybe a website, or something). So, if we compare it to a ZWave device, the device is a thing. So for 4 in 1 sensor - this is the thing, and the 4 sensors are the items. Just to confuse you slightly, in the OH2 model, bindings actually export channels, not items - channels are effectively the ‘real’ output from a device (thing) - voltages, temperatures, light switches etc, and you then attach a channel to an iteml. An item is in then what you use in your sitemaps, rules etc…
Well, if you’re running OH1 bindings under OH2, then it works the same, so you can use OH2 runtime in the same way as OH1. I suspect your problem (or part of it) is that you’re expecting OH1 bindings to work like an OH2 binding, and this isn’t the case. I can understand how this is confusing, but I think if you remember this point, you might get a better understanding of what’s happening…
In my system, I use OH2 but still have a lot of OH1 bindings etc. I configure all the OH1 ‘stuff’ in the normal way (editing the text files) and configure all the OH2 bindings through the user interfaces - it works pretty well, so long as you keep in mind the difference in OH1 and OH2 bindings, otherwise, you’ll get confused…
I hope that helps a little at least…
Chris