The development branch is even more ahead.
I’m at a point where I need core bundles to support all the advanced features of this interface.
Unfortunately the entire openHAB core distribution is basically frozen until the migration to the new buildsystem is finished, so I can’t contribute my developed bundles.
That’s why I got involved in that process. And while I migrated the hue emulation service I thought it would be awesome to have Hue scene, rule, schedule support. And that’s what I’m doing at the moment.
So this project is definitely not forgotten, I just can’t distribute it without those missing core bundles.
Old Textual modes with a UI front-end should be the way to go. I you remove the old textual mode then you are removing many OH users. Personally, I spent a few days clicking around to get the new MQTT 2.4 working, however I went back.
Think about Windows and Linux. In Linux you still can use the command and many scripts.
UI driven programming is good for newcomers without coding experience, but not if you have already ~100 items.
I do not want to stop upgrading, however if old textual configuration vanish, I will.
My proposal here is a lot more sophisticated. I have identified problems in the backend http interface, proposed new API endpoints, modernized and simplified OH core code. But OH core development is slow as hell. (The core maintainers are busy fighting Java. I can understand that. They do not have time to develop new features or replace grandpa-aged subsystems.)
I’m no longer participating in core development and I’m developing my own smarthome system for my personal uses. My UI has been moved to my repository and is no longer OH compatible.
Absolutely. Jan and Jochen (HomeAssistant MQTT) are doing all the important bits and pieces right now. MQTT v2.5 will be a very good release as far as I can tell.
Though I of course understand your arguments, but I’d love to see not only small PRs from you. Would love to see some of your ideas making it into core for the next major release @David_Graeff