
Meine Erfahrung mit Autodiscovery sind eher gemischt. Zum einen gibt es OH2-Bindings, die trotzdem kein Autodiscovery bieten (z.B. knx), einfach, weil die zugrunde liegende Technik das nicht unterstützt, zum anderen gibt es Bindings, die immer und immer wieder Bridges und Things finden, die aber schon im System vorhanden sind. Das betrifft natürlich über Things-Dateien angelegte Devices, aber im Zweifel habe ich gute Gründe, die von Hand anzulegen (z.B. weil ich kurze sprechende Namen bevorzuge), und ich will nicht ständig in der Inbox auf Geräte stoßen, die schon da sind und gut funktionieren.
Auf der anderen Seite habe ich auch einen Samsung Fernseher, der sich hartnäckig nicht korrekt manuell einrichten lässt (also, erst geht es, aber nach einem reboot plötzlich nicht mehr). Da das Gerät aber ohnehin nicht vom Binding unterstützt wird (und ich leider nicht genug Ahnung habe, um das zu ändern), ist dieses Problem für mich nicht so wichtig.
Mit meiner Warnung vor der Vermischung von Konfigurationswegen meinte ich auch eher, dass es keine gute Idee ist, eine Bridge mit ein paar Things über eine Textdatei anzulegen, weitere Things dann über Paper UI an die Bridge zu pappen und zum Schluss vielleicht auch noch die Verlinkung zu verschiedenen Items da wie dort (am besten über Kreuz) zu erledigen. Man sollte sich - zumindest pro Binding - für einen Weg entscheiden.
Die Items betreffend sehe ich dank VSCode und halbautomatischer Erzeugung von Items keinen Sinn, hier über Paper UI zu gehen, denn OH1 Bindings können nur mit .items Dateien an ein Item gebunden werden, ebenso ist meines Wisssens das Tagging bisher nur über die Textdatei möglich.
Auf der einen Seite hat das Autodiscovery sehr viel Komfort gebracht. Eine Zeile für ein Thing (oder auch nur das Abnicken der Inbox), und schon hat man eine ganze Latte an Channels, die auf Verwendung warten.
Auf der anderen Seite hat das alles sehr viel komplizierter gemacht, und das kann man auch an den diversen Fragen und Problemen sehen, die die Leute haben.
Ich habe auch den Eindruck, dass openHAB2 extrem viel mehr Zeit braucht, um in einen konsistenten Zustand zu kommen. Ich habe immer noch eine OH1.8.0 laufen, und die OH2.4.0 ist nicht annähernd so stabil, obwohl sie weitgehend die gleichen Bindings verwendet (es fehlen sogar ein paar) und ein Großteil der Automation (also die Rules) noch gar nicht umgezogen sind; OH2 hat also eigentlich viel weniger zu tun, trotzdem braucht es mehrere Minuten, um zu starten - Beide Versionen laufen jeweils in einer VM auf demselben Host, gleiches OS, gleiche (virtuelle) Hardware.