Because home automation is a complex matter and that requires a complex system to handle that matter well.
OH is as simple as it can get because it is the most flexible of all of them, to cover so many potential use cases, and that is very much intentional and way more important to attract people and make them happy with it in the long run than to save some 10s of minutes on reading docs, but seems you didn’t get that point.
OH is meant to work for a large number of users of different knowledge level. It is your own job to invest the time it takes to find out how a config and ruleset would need to look like that matches your knowledge and needs. Noone can do that but yourself.
So even now that I pointed you at it, you didn’t read the text carefully enough. See that part below the table, it IS actually giving that guidance to newbies.
But bottom line is there is no single config, naming scheme, ruleset to fit all or even just all basic-most requirements/use cases. We won’t sacrifice flexibility by mandating and writing down you must do it one specific way or another which is what most (all?) other HA systems do. There is no fast, effortless success. If that’s what you’re looking for stick with Vera, SmartThings and the like and see/understand why they fail to provide proper solutions to so many people.
So there’s an official statement from the docs and someone’s personal statement in some forum.
Now guess which one I will tell you to believe in ? Or do you want us to censor forum posts ?
Do you reckon the naiveness how you and the others you refer to are approaching this whole HA SW universum ? That’s not the OH way.
No [sic].
And as David pointed out, you completely missed the point that this thread is not on UIs or usability.
And it isn’t meant to discuss OH principles.
Person conducting the presentation is using simple item linking as well is using PaperUI rules to do basic things. He moves to files editing once he wan’t to do something more advanced. Setting up heater at 6:00 in the morning seems to be rather trivial case to do. Looking at the video I would say this is why many of new users can think that things should be done in such way (there are more examples like that one).
It was said that it’s hard to keep up to date documentation - I can only agree with that one. In the same time I can’t be sure that documentation that is for stable release is actual for snapshot that I had to use.
The only thing I’m asking you is to make the learning curve little bit easier. As a user I’m at the very beginning fighting on to many fronts:
with OH (binding/links/rules),
devices (heater turning on below set heat point/device not updating status / node disconnecting / ghost devices),
finally time because I’m working on living organism.
It is really challenging to figure out what docs you are following or looking at. You mention a wiki but the only wiki is for OH 1.x and is no longer maintained. It says that on the wiki.
Where are you seeing five columns with five approaches?
Almost certainly not. Or if that time comes there will be an automated migration script or some such. PaperUI had a long way to come still before anyone can even think about this though.
There is a beginners tutorial. While it is admittedly incomplete, it does present one approach for your initial set up and configuration.
It does say right at the top of the docs for the ERE
Note: If you use it, this is at your own risk. Especially, you should not expect any documentation besides what is available on the Eclipse SmartHome website.
The ERE is the future but so are a lot of things. That doesn’t mean they are ready for general use. Hence the name Experimental. There are maybe five people on this entire forum who can make it do much of anything right now.
But again, there will be an automated or semiautomated migration from Rules DSL to the ERE before the Rules DSL ever gets deprecated. Kai himself stated this. So those of us with lots of Rules DSL code will be fine.
But that should not be taken to mean we don’t care about making usability improvement too. They just are out if scope for this particular thread.
For the purposes of this thread the core framework I understand to mean the OH server up to the REST. All of the UIs are built on top of the REST API and are therefore it off scope. There are a few cross cutting features that will need support from both the core and UIs that were mentioned which is why I believe they remain in scope.
Needs a startup sequence that can be define in config file or something like that. In OH 2 startup, rules can start before items files are loaded and scripts called before they are loaded. Map files are loaded when ??? For me, this is a problem.
My 2cent, having used OpenHAB now for a bit. No really big project, just a few devices, but enough to get an impression.
My number one gripe ist the scripting engine. Sorry to say that, but the current one is a PITA. Spent hours to do things which should be obvious, like adding two numbers… Glad to hear, that this point will be solved with 2.4. If I got it right. Standard languages like Python or JS are a great step forward! Though if I read terms like JSR223, Jython, Nashorn Javascript, I get worried again, if this might be some awkward dialects … Also the simple examples on https://github.com/eclipse/smarthome/wiki/Scripted-Rule-Support lack a lot of clarity and seem to involve lots of boilerplate code. Maybe this could be hidden behind an interface like the current rules, just with the bodies in JS instead of the current language? Also I think there should be a clear number 1 scripting language, probably JS.
Another point is to make it easier to create reusable components, of items and rules, maybe UI. There are many design patterns with describe solutions to achieve this, written with the best intent. But really they are just creative workarounds. And if I read many of them I only want to scream and run away, wondering why it has to be so complicated And usually they require a complete redesign of what you just created. Leave alone that maintenance will be a nightmare, when you get back to such code years later trying to figure it out again. Maybe some sort of templating? Where you can write your items and rules once, test it, make it work, and then turn it into a template which I can instantiate multiple times with a different name and a set of parameters. Basically the engine in the background is taking care of the replication logic.
Simplification. My other number one, actually. Common things should be simple, more advanced things should be possible. There is no single point or single answer here, and this probably goes through many layers not just what you call the core. But I’m sure some things also touch the core. This is really a pain point, esp. for new users, as others already wrote here. Already relatively simple things take a lot of reading, time and effort to get implemented. Although OH looks simple on the first look, it has a steep learning curve. Sure, there is a lot of documentation (That’s a clear for the project!), and I’ve read quite a bunch of it. And you usually have to read it more than once. Still there are core concepts not entirely clear to me. And sometimes this is also just a sign that something is more complicated than it should or could be, or that something is conceptually wrong or could be improved. Take for instance implicit variables, like receivedCommand. I did that wrong first, and accessed the <item>.state, probably just like many other first time users, getting weird behavior, hard and time consuming to debug. If the rule had a forced (or at least optional) parameter with the received command instead, my code would have likely been correct the at first time. Without even thinking about it. Or call the rule after the item was updated and I can just use <item>.state. And zap, you can remove that part of documentation. Or this awkward thread locking I need to do. Shouldn’t be needed => doesn’t need to be documented. So telling the user he’s wrong and point him to some lengthy doc is not always the answer.
No one is expected to write the JSON by hand. There is a UI in PaperUI for creating Rules and eventually there will probably be a couple of choices.
All three of the JSR223 languages as well as legacy Rules DSL Rules will be supported.
If one is already using JSR223 Rules, they are already using the base NGRE.
JSR223 is just a name for the mechanism that allows one to run non-java programming languages in the Java Runtime Environment (JRE). Nashorn is the JSR223 implementation of JavaScript. Jython is a version of Python that runs on the JRE. OH is a Java application. Whatever language Rules are written in must run in that environment.
The Rules DSL is its own language and it has its own preferred way of structuring code. This is true of any programming language. The DPs are not work arounds. They illustrate the proper way to structure Rules DSL code. Indeed, if you try to structure your solution in a different way, you will probably have to restructure your approach, sometimes significantly. You sound like a programmer and for years I have pushed programmers away from the Rules DSL and to JSR223 Rules because most of the time people who already know how to program cannot or will not structure their code in a way that works well in Rules DSL.
NGRE has support for Rule templates (I’m not sure how it works yet) as well as libraries. But this will only be for Rules. You will have to manage your Items separately.
In the NGRE Rules can call Rules, Rules can be enabled and disabled, and of course there is support for libraries. But in Rules DSL, you shouldn’t have any duplicated code either. Using Groups, Member of triggers, and the like you should only need the one Rule in the first place.
In neither the Rules DSL nor the NGRE should there be replication of logic.
The NGRE takes a really different approach to implicit variables. They are still there but not you have an event Object that encapsulates everything you can know about the event that caused the Rule to trigger. For convenience, some of those properties are exposed as variables (e.g. on a changed triggered Rule there will be a newState and previousState variable populated).
I’m not sure I understand what you are suggesting though by a forces parameter with received command. Regardless, there is a reason why it is the way it is. There are circumstances where one needs received command to work exactly like it currently does. Any change to this breaks those cases. For example, imagine you have a device that always reports it’s new state. With such a device one will likely want to use autoupdate=false which will prevent the Item itself from being updated or changing state on the command and instead waiting until the device reports back that it changed state. So, in this case, you can’t rely on an update to trigger your Rule and you can’t rely on a state change to trigger your Rule when you need to have a Rule triggered when the Item receives a command but you don’t want to or need to wait for the state change. The only way to trigger a Rule in this circumstance is to trigger it based on the actual received command event independently of what the Item’s state is doing. But this also means you can’t rely on MyItem.state in that Rule, hence the variable.
Sometimes the complexity is deliberate, well thought out, and required.
You shouldn’t be doing much locking. It’s dangerous and prone to errors. If you need the locking then my recommendation would be that there might be a better approach or you should be using JSR223 Rules.
One can counter with just because one doesn’t understand why something is complicated doesn’t mean it can be made simpler.
I’m not arguing that there are not areas where OH can’t use some simplification and it has frankly come a really long way in only a couple of years. But it needs to support a lot of use cases and that adds complexity.
Based on the description I really think you would be better off using JSR223 Rules or, if you are adventurous you can start to experiment with the NGRE. There are a few things it can’t handle just yet but it’s pretty capable.
As @rlkoshak, I’m in favor of Dynamic Scheduler, but I’d like to extend this idea.
I’d like to give the non-developer user (my wife) the ability to change some scheduled tasks.
As an example, I’d like to have a scheduler for temperatures or scheduler with on/off status for Christmas lights.
Right now I must use CRON so setup thing and when I want to change timing I must edit rules.
Take a look at Sonoff, You are able to define scheduler in which You want to turn on the light, or in heating systems, You are able to specify a lower temperature for Your house when You are at work.
All of this is done using UI, not in code or scripts.
I agree. This feature is missing. But we have been talking about this subject within this topic and linked topics. It needs to be defined what timers are, maybe separate them from “delay”/“delayed execute”. There is a Github issue already to keep track of this feature.
@David_Graeff could You link this issue here? I’d like to subscribe to notifications.
I’m a C# developer, but I can help with basics. I must start with something
One suggestion, which came up in another thread I’d started related to some weirdness with sending commands via a rule – I think the ESH metadata defining channels needs to be updated to have the concept of a primary type and supported types, and the framework should send commands of supported types through to the binding directly. The “as()” conversions should be deprecated, and the system needs to log appropriately when a command of the wrong type is sent to a binding.
Right now you’ve got conversions running in the framework from some types to some other types which may or may not be appropriate to the binding, and a situation where a conversion not happening causing a type mismatch doesn’t trigger anything in the logs – the event just vanishes.
My use case was a little more specific, but to be more generic about it, an example would be a channel representing a dimmer state. Right now a dimmer state may take a PercentType, and if you send an OnOffType, the system down in OnOffType will convert that to a PercentType(100). The binding therefore has no idea the user sent ON, just that they sent 100. The binding may want ON to mean something else, so you end up having two channels that can take ON – one that is interpreted as ON and can do something binding specific (restore to prior state, for example) and one that receives 100, and the user needs to know the difference (which isn’t obvious, because both will take either command type) The inverse is even weirder, because the as implementation in PercentType is different for OnOffType vs OpenClosedType, for example. (Only 100 is OPEN, but anything non-zero is ON).
What I’d really like to see – both from the standpoint of a binding author and a binding consumer – is the ability to tell the framework “this channel is a PercentType, and if you ask my state, that’s what you’re getting, but I’ll accept an OnOffType”. Then I can do a binding-specific interpretation of the other types rather than hoping the type conversions and logic in the defined item type matches my behavior, rather than having to define multiple channels that do almost-but-not-quite the same thing.
Hm. If I understand you correctly, you want to bind a channel to a switch item and a dimmer item. And in the binding you will receive either a PercentType or an OnOffType command (whereas you currently only receive a PercentType)?
Hm. If I understand you correctly, you want to bind a channel to a switch item and a dimmer item. And in the binding you will receive either a PercentType or an OnOffType command (whereas you currently only receive a PercentType)?
Well, that’d be an example of it. What I more specifically want to do is be able to register a channel to receive more than one type, rather than having the ESH framework do ad-hoc type conversions that may or may not match what I expect to see. (Like I said, the behavior of the code in PercentType is inconsistent, as just one example).
In the other thread where I mentioned it, I suggested the channel metadata could be extended so you could give an item-type and a item-type-supported entry, as one possibility.
Basically tell the framework “this is a PercentType channel, but if you call handleCommand for this channel and pass me an OnOffType, I’ll know what to do with it”. And then not run the as() conversion on OnOffType to generate a PercentType(100). Then in the code, I could do an instanceof check and OnOffType.ON could be a “turn on to last level”, rather than “turn on to 100”.
That’s just one example. Skimming bindings, there’s gobs of examples where a single real-world behaviors are split among channels. Now, an argument could be made that a conceptual purity is maintained by having a “On/Off” channel and a “dimmer level” channel, except that purity is blurred once some item types can be converted to others via fairly arbitrary rules, so I’m not sure how realistic of an argument that is. If that kind of purity was desired, than On/Off should toggle something on/off, and a dimmer PercentType should set the level if the device is on, not turn it on if its not, and certainly not infer anything from an ON state. So to turn a light on to a given level, you’d send dimmerLevel.sendCommand(50%) followed by dimmerPower.sendCommand(ON) or something. I don’t think people would like that, though, so I get why there’s a conversion so dimmerLevel.sendCommand(ON) works.
What tripped me up with it, before I read through the ESH code, was two things – first, there’s no logging if a type-conversion does’t exist. So sendCommand(ON) to a PercentType, or a DecimalType works (they’ll get 100 or 1 respectively) but sendCommand(ON) to a StringType silently fails. And secondly, there’s no consistent documentation, if any really, about what type conversions happen, what the conversion behaviors are, and what the implications of them are (like needing to double up dimmer channels).
I’m still trying to make heads or tails of the ESH code – it looks to me like that actually is supported to some limited extent already in CommunicationManager, but the default ThingTypeProvider for thing types, which reads from the ESH-INF just doesn’t support it. ChannelType only holds a String for itemType, and via some mechanism that seems to work its way down into CommunicationManager. But basically, the system should let you register multiple supported types in the thing definition, and toAcceptedType should skip conversion to any of the supported types for a channel, handleEvent() should also log all three debug lines in it as WARN, so when a channel doesn’t support any of the types the provided event can be converted to, it actually gets logged in a useful way for users.
Honestly, if I knew enough about ESH to feel comfortable making the change, I would. But I’m not even remotely comfortable that I understand the nuances of what its doing in this code, and I don’t really have a ton of time to dig into it at the moment.
The reason I think the two (the item-type and item-type-supported) need to be different is that caller code may want to know the type they’re going to get when the state is retrieved. Ie, you can updateState or sendCommand with any of the types, but the state will always be the item-type. That also helps with backwards compatibility because any code talking to any channel that previously was interacting with a given channel would continue to get the type they were expecting.
There are a number of Items which accept multiple state data types, for example DimmerItem , which accepts OnOffType and PercentType , RollershutterItem , which accepts PercentType and UpDownType , or ColorItem , which accepts HSBType , OnOffType and PercentType
I’m not familiar with the implementation of updateState or sendCommand but it seems to me the problem is with those commands.
Kind of – the issue is that, like the State conversions, the supported combinations are baked in as far as I can tell. That means frequently trying to map logical behaviors to name that don’t really match them (and thus are confusing to end users), and those types don’t seem to be extendable in metadata, just in code.
I did some more research. It looks like a binding does get the OnOffType but has to decide how to implement it. Hence some implement it as 100%. and there is nothing forced. If a binding doesn’t implement OnOff, it won’t be handled.
I agree that if arguments passed to like sendCommand, that can’t be handled, should give some warning and not be silent.
There’s a bit of conflict there - IF commands get passed as-is to bindings (without conversion), there is no way to know if one of the bindings might handle it correctly, and a warning is unwarranted.
If I got it right. Standard languages like Python or JS are a great step forward! Though if I read terms like JSR223, Jython, Nashorn Javascript, I get worried again, if this might be some awkward dialects … Also the simple examples on 
And usually they require a complete redesign of what you just created. Leave alone that maintenance will be a nightmare, when you get back to such code years later trying to figure it out again. Maybe some sort of templating? Where you can write your items and rules once, test it, make it work, and then turn it into a template which I can instantiate multiple times with a different name and a set of parameters. Basically the engine in the background is taking care of the replication logic.
