Hello,
I recently upgraded from 2.4 to 2.5. My rules have many sendMail() calls. To use the new 2.5 Mail binding, it looks like I need to replace
sendMail() with
getActions("mail","mail:smtp:xxxxx").sendMail()
Is there a way to make this more simple so that I don’t have to search and replace across multiple files when the Mail Server thingID (the xxxxx above) changed or in future upgrades?
Thank you.
Using scripted automation, you could go from something like an Item> linked Channels> Thing> ThingID. But you can’t do this in the rules DSL.
@5iver, thanks for responding to my question. Honestly, your answer is way above my head. I have no idea what you mean by
Could you show me an example? or point me to a link that I can read?
I am familiar with defining Things using Discovery in the Paper UI, creating items in a file and linking them to channel ids, and writing simple rules. Anything else is outside of my comfort zone.
There really isn’t anything that you can do now to avoid doing the work of replacing sendMail with the new action everywhere it currently is in your rules. But the question is what do you replace it with to make it less work next time?
First let me say that Mail binding Things are all manually created. Given that, you have full control over the ID that is used. So if the Thing ID changes at any point, it’s because you chose to create/recreate the Thing with a different ID.
As for future upgrades, who can say. I doubt that there will be any significant changes to the basic Mail binding Actions in the foreseeable future.
But there are things you can do so the calls to the Mail action do not appear in so many places throughout your rules. For example, Design Pattern: Separation of Behaviors. If you are using UI generated rules in OH 3 or scripted automation in OH 2.5 you can put the calls to the Mail Action into a library function so there is only one place where you’d have to change the Thing ID should you choose at some point in the future to change the Thing ID.
Hi @rlkoshak Rich,
Thank you for responding to my question. I think I might understand what you and @5iver Scott are trying to tell me. If I stick with the OH rules (aka Rules DSL), I have to manually search and replace all sendMail() entries.
If I use the scripted automation then I could define getActions("mail","mail:smtp:xxxxx").sendMail() into a new function() which I could then use in various scripts? (not sure if it is the right terminology here).
I think when you wrote Scripted Automation, you referred to this https://www.openhab.org/docs/configuration/jsr223.html#javascript capability, correct? If yes, I have zero experience on it and will need to learn more.
If I decide to dive into Scripted Automation, which language (Jython, Javascript, Groovy) should I use? I’m looking for the popular one used in this forum. So when I run into an issue I could find help easier
Another question is can Scripted Automation scripts(?) interact with existing rules/items and vice versa.
Again thank you for your time. I really appreciate it.
Most of what I described can be done in Rules DSL too. Read the link to the design pattern I posted. It shows how to do the notification stuff (email in your case) from one rule that other rules trigger by sending the message as a command to a String Item.
But no matter what, you will have to find and replace all current occrances of send mail in your current rules. Nothing is going to save you from that work now. All you can do is make it so next time it’s less work.
In OH 2 there are two rules engines, Rules DSL’s engine and Scripted Automation which supports Jython, JavaScript, and Groovy. In OH 3 there is just Scripted Automation and Rules DSL had been ported to work on it. Rules DSL had limitations that make it easier to learn but harder to do certain things in the long run, like making libraries. So if you stick to Rules DSL you need to use the Separation of Behaviors DP and global lambdas. If you move to one of the other languages, you have the ability to create libraries if functions that can be reused across all your rules.
You can run your old Rules DSL times along side Scripted Automation rules. and if course Scripted Automation interacts with Items. But you can’t write a Jython library function and import that into a Rules DSL Rule…