[Feature Request] Update/migrate lucid

[openhab-scripters]

[Feature Request] Update/migrate lucid

[fastlorenzo]

Let me know if some help is needed there

[5iver]

I have the bulk of it migrated, but there are a lot of customizations in rule.py that I'm vacillating on what to do with them. Same with the utils.py. I'll get some specifics together for discussion. Testing help will be much appreciated. You can check progress here (but not ready for testing yet).

[fastlorenzo]

Great, let me know if needed for testing / helping

[besynnerlig]

Hi there @openhab-5iver

As I wrote on our slack channel I've been quite busy but I'm slowly getting a little bit more time that I can spend on my HA system.

Anyway I'm still on OH2.3 here and I thought I will try to recap what's happened and the status of openhab2-jython, lucid and ideAlarm. I've found that you've made a new branch for it but it's quite hard for me to get a grip of it.

Would you care to brief me shortly about the status, what's going on, plans and if I can be of any help at all. Thanks for your kind help.

Cheers!

[besynnerlig]

Anyway, I've started to work with this today. :)

[5iver]

Strange... I saw your first post and thought I had replied!

I've committed most (all? I need to check my local repo) of my changes to the lucid-migration branch. When I saw you posting in the forum about upgrading OH, I cringed because this was not done yet. I'm working on a Jython addon, but will put that down and move this to first in my queue. IIRC, everything but some of the utils.py and rules.py were left. My plan was to make /community/lucid/ directories for any modules and scripts that did not fit into core. Autoremote, ClickaTel and Sonos should be complete, and IdeAlarm should be close.

Here are my current priorities for this repo:

1. Wrap up the lucid, IdeAlarm and WeatherStationUploader migrations. The branches will need to be rebased on master. It would probably be easier to wait until after 2 and 3 are done, but I'd like to get this into master now so that people can use it without having to upgrade to a post-ESH reintegration OH build. However, I may be able to make those changes backwards compatible, and if so, then I'd rather push this to after 3.
2. There are changes needed in master to get Jython 2.7.1 to work (just needs to be committed and merged).
3. There are changes needed in master required for compatibility with the ESH reintegration (just needs to be committed and merged).
4. I plan to cut branches and build out releases for the original <=OH 2.3, the pre-ESH reintegration (current), and then the post-ESH reintegration. This will make it easier for people to download from the repo and to add a version check.
5. I'd like to get the organization and repo renamed, but I want to get all PRs merged first, to avoid any possible issues.

I'll get back to work on lucid tonight. Give me... 2 days, and then you should take a look at it (or whenever you're available 😄), and provide your feedback. Hopefully, it will be in a state for testing. If you don't like how it's looking, we can make changes or start over. My main concern has been backwards compatibility, but since people will have to modify their scripts and modules to work with the API changes anyhow, I'm not sure how big of a concern this really is.

[besynnerlig]

I'm so happy to know about the progress and your plans. I'm sure it will be really great. I believe that as long as there will be a "release notice" users won't mind any breaking changes. After all, major benefits are introduced.

I will prioritize testing and contributing (whenever I am able to) and it seems that I'll have the time to do it the coming days. Please just say where you think that I can be of any kind of help. I,ve set up my environment here and I have 2 OH installations that I can switch between.

I have also reinstalled the Slack app on my cellphone so I'll get instant notifications when communicating on openHAB Jython Scripting on Slack

2 questions. (Can also be discussed on Slack if you wish)

1. Can the example config file in the repo be renamed to example_configuration.py to avoid overwriting the customized private configuration file? That would need an instruction in the initial setup instructions to create configuration.py based on example_configuration.py

2. In my OH installation, I make soft links to directories on my local git repo. It gives me a good work flow and I can run tests , make changes, commit and easily commit them to my own openHab2-jython fork. It works great but I need a .gitignore file to avoid uploading sensitive data and have git not to track binary files etc. Can I add a .gitignore file in the repo root directory? E.g.

*.py[cod]
*$py.class
configuration.py
!example_configuration.py
MY_PERSONAL_NOTES.md
personal/
jython-standalone-2.7.0.jar

Thanks for all the work you are doing Scott.

Cheers!

[5iver]

Can the example config file in the repo be renamed to example_configuration.py to avoid overwriting the customized private configuration file?

The community configuration files are done like this and use the name configuration.py.example, so it makes sense to do the same in core. I've just added that to my local and will update the docs.

Can I add a .gitignore file in the repo root directory?

Yes, but please submit a PR so we can discuss the content... I don't think the jar and personal notes need to be in there.

I've synced the lucid-migration branch with master and have committed my changes from the last couple days. I need to take a break and run over to help a friend setup OH(!). I'll keep working on this tomorrow. I have not tested much, but most things should be functional. If you have time, your testing and feedback would be very much appreciated! Check out the PR too... #91.

[besynnerlig]

Yes, but please submit a PR so we can discuss the content... I don't think the jar and personal notes need to be in there.

Thanks. I've submitted a PR. I've removed the personal notes file but I've kept the jar file for now.

[besynnerlig]

I'm a bit tired after migrating my production scripts the whole day. I couldn't go all the way to OH 2.5M1 due to that cron triggers are not working. I had to downgrade.

Anyway now on OH 2.4 stable.

I might have found a bug. When using the system started trigger, the script won't trigger at all

from core.rules import rule
from core.triggers import when

@rule("Jython Hello World (cron decorators)", description="This is an example cron triggered rule using decorators", tags=["Test tag", "Hello World"])# [description and tags are optional]
@when("Time cron 0/10 * * * * ?")
@when("System started")
def helloWorldCronDecorators(event):
    helloWorldCronDecorators.log.info("Hello World!")

Am I right?

Another question, the @when("System started") if working, would also fire whenever a script is reloaded, right?

[5iver]

Another question, the @when("System started") if working, would also fire whenever a script is reloaded, right?

Correct.

I might have found a bug. When using the system started trigger, the script won't trigger at all

I just tested and it is working correctly. However, you will need S1566 or newer for 'System started', since openhab/openhab-core#520 did not get merged until after M1. That's why I had been waiting to put it in. I had been thinking that the package renaming was going to be breaking and so I'd put it in with those changes. I'm glad you brought this up, since I have not put that requirement into the documentation yet. Sorry if you spun your wheels on this!

If you don't want to use a snapshot, just add the function to the script... helloWorldCronDecorators(None).

[besynnerlig]

Thanks for the answers @openhab-5iver

Since I'm updating my production environment I'll try to find any OH version that's working. I can't do with the 2.5M1 due to the cron bug. Maybe it's possible to install a snapshot that has been proven to be quite stable.... Maybe you can recommend a version?

Is this a good place for me to bring up various questions now when I'm continuing my testing or is there a better place?

Cheers!

[5iver]

I can't do with the 2.5M1 due to the cron bug.

What cron bug?

Maybe you can recommend a version?

Actually, the current one has been good for me... 1597. I'm using it in production.

Is this a good place for me to bring up various questions now when I'm continuing my testing or is there a better place?

How about a forum post? Others may learn from it too! Maybe a call out to the other lucideers?

[besynnerlig]

I can't do with the 2.5M1 due to the cron bug.

What cron bug?

The proper name of the bug is Scheduler errors on startup

Maybe you can recommend a version?

Actually, the current one has been good for me... 1597. I'm using it in production.

Thanks. I'll try it.

Is this a good place for me to bring up various questions now when I'm continuing my testing or is there a better place?

How about a forum post? Others may learn from it too! Maybe a call out to the other lucideers?

Of course. I'll try to do that unless it's related to the update/migration of Lucid and the latest changes in openhab-helper-libraries. In the latter case, I'll just post here then.

Thanks! ;)

[besynnerlig]

I tried snapshot 1597 and things started to work well except for RFXtrx stuff that I'll have to investigate later.

I have converted almost all my personal jython scripts and things are running extremely well. I haven't really found anything that's not working. I realize how much hard work you've put into this project @openhab-5iver . This will be very valuable for the community and together with the new documentation it wouldn't surpise me if jython scripting it will be the first choise for someone interested to start with openHab.

I have thought of a few improvements, just on the idea stage ... Just ideas not yet ready to propose as enhancements. You don't have to response to these. I just write them down here.

• It would be nice if the event object provided in the rules never was None. As it is now, I will have to test for None before testing further, e.g. if event is not None and event.itemName == 'Crazy_Lights':*. It would also be nice if we had event.isCron, event.isItem etc for facilitating scripting where different triggers are mixed.

• When people will start to work with the community scripts, error messages arising from errors in personal libraries will not be so helpful. It won't tell exact in which file and at what row the actual error is. Furthermore it would be nice if we can find a way to automatically (or more easily than restarting openhab) reload the configuration for every script using it whenever the configuration file has been changed.

Wishing you a nice weekend!

[5iver]

It would be nice if the event object provided in the rules never was None.

I planned to look into this when adding/updating more ModuleTypes, including adding startup trigger into OHC. Returning event.triggerType would be nice too, so I'll see if I can't get that approved too.

Thank you for the kudos!

When people will start to work with the community scripts, error messages arising from errors in personal libraries will not be so helpful.

This is also reported in #59 and I have an open PR that will hopefully help with this. I'll need to test again, but I was pretty sure this is already resolved for errors in modules that are called from inside a rule that is created with the rule decorator.

Furthermore it would be nice if we can find a way to automatically (or more easily than restarting openhab) reload the configuration for every script using it whenever the configuration file has been changed.

I like that idea... core.utils would be a good place for it. I've opened #134 for this.