Sounds like you’ve been figuring out these Great to have some feedback and get the common usage issues/solutions documented! I do get your point and surely groups can help in many cases.
After looking at the code now, my case was actually a bit different than explained previously. Not sure if it should be opened in this topic but I do understand that basically everything can be made to work with Xtext with bit of re-organization. Certainly there are ways to go around these issues but did not really see it worth the effort as there was JSR approach available around the corner. Also I’m worried that some of the changes might be sacrificing readibility “just to make it work”.
You are right that the programming background might actually make things worse. For example, I would like see the actual triggers as shallow wrappers calling “library” of re-usable functions. With this approach it is easy to follow the “main story” of the triggers themselves as they would be just calling other functions.
Sounds like we are really close to OH2 having JSR scripting, looking forward experimenting with that!
I can see this but in my experience I find my updated code to be more readable rather than less readable. However, that is primarily because the little lightbulb went off in my head so I expect to see it coded in this way now and when I see a more procedural approach being used I find that harder to read.
It could just be me. Though I will admit that the hack I use to get the Item that triggered the event is just that, a hack and not at all satisfactory. But I keep it around because it really really helps cut down and simplify my code.
An interesting idea. I’m not sure what I think about that. I’ve not seen that approach tried in other similar event driven programming environments I’ve used (e.g. Tasker, Asterisk, HomeGeni) so I don’t know if no one has thought of it or if there is some technical reason why it doesn’t work well.
I am pretty sure that would not be possible in the rules engine as it is currently written.
I personally kind of like having the rules triggers and the rules logic together as it helps to self document the context of the logic. With a separation like that I the context involved when the logic is called is not as apparent. Though if they are generic the context shouldn’t matter that much. Then again, in my entire configuration I have only three situations where the logic is ever going to be anything but specific to one event.
Something to ponder.
This wouldn’t be the first thread that drifted to some other topic. If you want to pursue it you can do it here, open a new thread, or send me a PM. I enjoy looking at other people’s code and recommending improvements.
-bash: -Dpython.home=/home/openhabian/jython2.7.0: No such file or directory
or
/usr/bin/openhab-cli: 27: /etc/default/openhab2: -Dpython.home=/home/openhabian/jython2.7.0: not found
for example when opening an ssh connection to my openhabian raspi or opening a connection to the karaf console? The folder is existing since my rules are working.
Great to have some feedback and get the common usage issues/solutions documented! I do get your point and surely groups can help in many cases.