I am trying to get Jython/JSR223 working within a 1.8 docker container. I am installing jython via apt-get. It’s not really clear to me what python.home should be set to because I am not getting an /opt/jython folder.
I added the following to the command to start openhab:
-Dpython.home=/usr/share/jython -Dpython.path=configurations/scripts/lib
I don’t know exactly what Jython loads from python.home (other than Python system libraries). I’m assuming those are in the Lib directory. Are you seeing errors when you load Jython rules?
You could run Jython from the command line and query the python.home value.
from java.lang import System
System.getProperty("python.home")
I know the wiki says you can use a “.jy” extension for scripts but I’ve never done it. I don’t have access to my system to try it, but looking at the Jython source code I see the following…
public List<String> getExtensions() {
return Collections.unmodifiableList(Arrays.asList("py"));
}
That seems to imply that only “.py” extensions are recognized as Jython scripts for JSR223 (might be different than file associations for the operating system). Do you see the Jython script engine being logged as available?
Do I have to be enabling a binding or anything for this? Or just make those changes to the executable, link the jar, etc, and then drop the files into the scripts folder?
I am seeing no errors from files put in scripts, and no logging either. No change really.
If you are seeing Jython logged as an available scripting engine, then the addon is loading correctly. I’d try changing the test.jy to test.py. The OH ScriptManager should at least log something about trying to load the test.py file if the Jython scripting engine is available. If you haven’t done it already, also be sure to enable debug logging for the JSR 223 bundle.
So, it’s possible that JSR223 is not compatible with an apt-get installation of Jython. In my installation, not only is the Lib directory in python.home directory but the jython.jar is also there (and I think that’s how the engine is located and loaded). The first thing to do is locate where the the jython.jar file was installed. You can use “dpkg -L <package-name>” to do that. Set python.home to that directory and see if the engine is loaded. If so, you’ll probably still have issues with the Python standard libraries not being loaded. If so, set python.path to include the /usr/share/jython/ directory.
Back to the delay with motion sensors turning on lights. I did remove the query for the extended info when the motion sensor goes OPEN.
Do you think it is feasible to modify the message dispatcher for the insteon devices so that somehow messages can be prioritized and sent as fast as possible to the plm, and not subject to the 500 ms wait? I’m thinking that if something like motion is detected, then the resulting ON command to a dimmer really needs to be sent as soon as possible.
I haven’t spent any time down at the streams accessing the plm, so I am curious about your thoughts as the expert here.
The first thing would be to find out if the 500ms wait even is the problem.
There is a good reason for the 500ms wait between messages. If you send them closer, a fair amount of them gets lost. No idea where (the modem ack’s them), maybe they never go on the network, maybe the modem eats them.
That delay should not matter unless a message was sent immediately prior to it. Can you post a log file of your delays (implement the fix mentioned above before you run the timings):
I was able to reduce the delay to about 1-2 sec by using Bernd’s suggestion of eliminating the motion sensor battery/light reading and replacing it with m_feature.getDevice().doPoll(0);
Then we can see in the log if the spacing out of the messages really causes the delays.
lines? Or do I have to add that poll method call? As of right now, I don’t care at all about battery or light level. I was thinking the way I use motion sensors, I could later add that extendedQuery call back to the motion off contact handler, because I don’t need anything to happen in a particularly timely fashion on the off state change.
You can just comment out for now, but eventually I want the poll call to happen as outlined above. Don’t know what you mean with “adding the extendedQuery call back to the motion off contact handler”. I definitely don’t want the battery/light level disabled permanently. The poll should not add to latency because the poll message should go out after the light on/off command. Would be great if you could confirm that in testing (rather than just removing sendExtendedQuery(f, (byte)0x2e, (byte) 00)) that would be great.