So I go back to my statement from before, how can we call the next gen rules engine anything but experimental if it can’t be used?
Right now what in seeing is all this great work being done and pretty much nice if it being available to the average user. With statements like “don’t plan to check it into the core” it also appears that it will never be available to the average users. So they are all just it off luck? At best you offer me the Gentoo Linux experience where the users end up having to pick and choose each and every little feature they want to use and install it separately. Not that OHv was ever the paragon of user friendly but the isn’t exactly a step forward.
And like I said before, the details about which repo stuff gets built in and such is a don’t care to most users. But if it becomes something that users have to care about we’ve failed as a project.
I cannot imagine to how much effort it would be to maintain some “nodered-like” approach for rules, everything else is useless.
Making my first steps from DSL in jsr223 jython and it is really promising. I cannot imagine anybody need a gui, nor a gui can be that sofisticated to do stuff most need (even nodered-like)
The demand for a GUI is strong, consistent, and persistent. There is a class of users who will never be comfortable using text based configs. I spend a huge amount of time dealing with those who try to use PaperUI to build Rules only to run into some problem or limitation caused by the UI. And that’s at a point where it’s explicitly labeled “Experimental” and there are no docs what-so-ever on how to use it.
So I’ll just jump in with my $.02 as a mostly lurking user who is quite technical but has very little time to hack on stuff. I am using the NGRE with PaperUI and it is working mostly good enough for me right now. I have less than 20 rules and they are mostly absolute time of day, or sunrise/sunset stuff for lights and door locks. I also have a few that control things with scenes via remote switches. The UI has quirks and a few issues and every time I restart my OpenHAB instance (running in a docker container), I have to open and save every rule from the UI to initialize them…a PITA. But it works. I wish I had time to dig through the code and figure it out but I just don’t. I instead will go look at the JSON db files just to see what they’re doing on occasion, but I mostly trial-and-error stuff until it works and for most things it just works. I think having a UI is important and simplifies/improves the experience for even some technical people and is a must for adoption for those who don’t/won’t write code. I’m not at ALL criticizing anyone and am thankful for all the effort from the contributors - I’d just like to add my voice to that of Rich in stating that a working UI for the NGRE is important.
Thanks, 5iver. I need to bite the bullet and move to 2.5. I was on the 2.4 snapshots when I was first setting everything up and just continued with stable once it was released. I suspect I’ll have to set all my zwave stuff back up again if I move to snapshots. I may do it this weekend, but I have to be sure nothing is broken as I travel most weeks and my wife will beat me soundly if I leave stuff in a non-working state.
I’m assuming when you suggest disabling all the rules and restarting OH, that is on the snapshot version…or do you think that might also work with 2.4 stable? Was the fix back-ported?
There are no breaking changes for zwave like there were in 2.4, so it should just work.
The fix was not back ported to 2.4. In my troubleshooting of the issue, I found that UI created rules would start properly if they had all been disabled and OH restarted. It’s a one time effort too, meaning you don’t have to do this before every restart. I believe I confirmed this on 2.4, since another user was reporting it on that version, but I could be mistaken… I might have only tested it on 2.5M1 and 2.5 snapshots. Here’s the GH issue…
If your environment needs to be stable, I do not recommend a snapshot build at this time. In particular, there was a fix for zwave healing recently that is causing some trouble and will require you to disable the nightly heal or everything zwave stops responding. At least, that’s what is happening here. There are also still open issues with hueemulation and MQTT2.
Just to be clear, I’ve been having this issue with heal for quite a while. So has @digitaldan. We’ve just been reporting different symptoms of the problem. From my perspective, this PR doesn’t make things any better or any worse.
OK, got it. Thanks all. I’ll try the disable/restart/re-enable and see if that takes care of it on the most recent 2.4 stable drop. I’ll report back on this thread.
Agree, as home automation becomes more popular, more software platforms are getting created. If Openhab wants to be in the most used list we need to keep changing or be left behind and this affects the number of developers working on Openhab.
In this video Mozilla Webthings is shown how they handle rules at 8:45
That’s right! And I love these very good features that set openHAB apart from other systems. This results in a flexibility that nothing else can offer me even close to.
But it’s not about replacing one with the other. But openHAB needs both abilities in the future.
The graphic side is quite improvable but I see very good progress at present. There has been a lack of people to take care of these issues. Some new developers and also with your help the programming of the graphical editing is progressing better, I have the impression.
