Hi there!
Are there any plans to include a UI rules designer in a future release of OH2? Something like Node-RED?
TIA
This is already included in HABmin2, but only for the ‘old’ XText rules, not the new ESH rules at the moment.
@chris, is it possible to use HABmin with OH 1.x?
HABmin 1 can be used with OH1, and the designer is also included in HABmin1…
It’s not perfect by any means, but should work for most basic rules (at least it is fine for the rules I’ve been using 
).
Wow, that’s awesome!
My rules are even simpler, but to be honest, having to write “code” is not
my idea of UX for IoT framework, specially when you want another family
member to be dealing with them eventually 
I’ll read the docs and will let you know how it goes 
Thanks!
Jose
I agree - especially when the ‘code’ is XText, and is not simple to debug…
Good luck 
There is a whole lot covered in this simple relatively off hand statement. I’ll only address a couple of them.
When designing a software based system you can:
- Make it easy to use and intuitive so the average user can figure it out without being taught
- Make it complete and flexible so it can support just about anything one can can think of and even some things that people haven’t thought of
You can’t have both. Different vendors and systems tend to move more towards one side or the other. For example, Apple’s closed echo system leans a little towards 1 at the expense of 2 whereas Linux leans a lot towards 2 at the expense of 1.
A community created and supported product, be it Linux or openHAB will always tend to lean towards 2 because one of the main things that has driven them to create the product in the first place is the fact that the products that lean towards 1 (e.g. Wink, SmartThings, etc.) do not do everything that is desired. But the more capability you build into a product, the less easy to use it will become.
All that being said, OH has a lot that they can be done to make it easier to use without sacrificing capability and OH 2 has made great strides in this regard.
Another aspect to discuss is your statement that having code be the UX for an IoT framework is not ideal. Honestly, having to write code is not the ideal interface to any framework or system. However one is again faced with the 1. verses 2. problem. At the end of the day, no matter what you do you will still be writing code whether it is through the Scratch programming language based UI chris has put together, moving icons around on a screen, or typing text into a text editor. It is ALL code. And the only way to get away from this is to neuter the framework (i.e. move away from 2 and strongly towards 1) which will make it easy to set up but greatly limit what you can do.
Finally, [quote=“jose, post:5, topic:11072”]
specially when you want another familymember to be dealing with them eventually
[/quote]
With ANY IoT framework there will be two interfaces. There is the “set it up” interface which will largely be where your “code” gets written. This is your “when this happens do that” type of stuff. You also have the interface you use to drive the home automation. In OH this is your sitemap which consists of buttons and sliders and the like.
The only users of your system that should be dealing with the “code” interface are those who will be “programming” the automation in which case they will be writing “code” anyway, be it visually in Scratch or at a text editor.
Concernng Node-Red - there is no need to include it in OH - just use it as it is for your rules and connect to OH via MQTT.
I used it already for couple of rules and it is awesome. Just for example my rule for movement-based light control looks like this:
And benefits of Node-red in addition to visual design - this flow can be easily debugged during run time and is hardware-independent.