InsteonPLM excessive delay between Motion Sensor to Dimmer

Hi Steve,

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

Here is that folder:

ls -la /usr/share/jython/
total 28
drwxr-xr-x   3 root root  4096 Jul 27 06:37 .
drwxr-xr-x 123 root root  4096 Jul 27 06:37 ..
drwxr-xr-x  14 root root 20480 Jul 27 06:37 Lib
lrwxrwxrwx   1 root root    23 Oct  7  2014 registry -> /etc/jython/jython.conf

Is this the correct value for the python.home variable?

Is there anything else I am probably doing incorrectly?

thanks,
craig

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")

this is what i get within jython

>>> from java.lang import System
>>> System.getProperty("python.home")
u'/usr'

seems odd.

i don’t see it loading my jython rules in the logs.

here is my scripts folder

drwxr-xr-x   5 craigh  staff  170 27 Jul 13:54 .
drwxr-xr-x  14 craigh  staff  476 27 Jul 07:32 ..
-rw-r--r--   1 craigh  staff  230  5 May 10:23 README
-rw-r--r--   1 craigh  staff  306 27 Jul 07:13 rule.py
-rw-r--r--   1 craigh  staff  168 27 Jul 07:17 test.jy

this is what is in test.jy

item = ir.getItem("TestString")
oh.logInfo("TEST", str(type(item)))
oh.logInfo("TEST", str(dir(item)))

# no rules in this script
def getRules():
  return RuleSet([])

I agree that “/usr” is odd.

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?

Steve,

First, thanks for the help.

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.

thanks,
craig

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.

I am NOT seeing python logged as an available scripting engine.

Everything looks the same as before I tried to enable python/jython scripting.

oh, and I have changed the extension to py

ok, put org.openhab.core.jsr223 into my addons folder and i now get this

2016-07-27 16:01:21.848 [INFO ] [o.o.c.j.i.e.s.ScriptManager   ] - Available engines:
2016-07-27 16:01:21.853 [INFO ] [o.o.c.j.i.e.s.ScriptManager   ] - Oracle Nashorn
2016-07-27 16:01:21.859 [INFO ] [o.c.j.i.e.scriptmanager.Script] - Loading Script example.py
2016-07-27 16:01:21.860 [WARN ] [o.o.c.j.i.e.s.ScriptManager   ] - No Engine found for File: example.py
2016-07-27 16:01:21.862 [INFO ] [o.c.j.i.e.scriptmanager.Script] - Loading Script rule.py
2016-07-27 16:01:21.863 [WARN ] [o.o.c.j.i.e.s.ScriptManager   ] - No Engine found for File: rule.py
2016-07-27 16:01:21.864 [INFO ] [o.c.j.i.e.scriptmanager.Script] - Loading Script test.py
2016-07-27 16:01:21.865 [WARN ] [o.o.c.j.i.e.s.ScriptManager   ] - No Engine found for File: test.py

Looks closer, but jython not avail as an engine.

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.

just as an fyi for the next person, i did get python working within the docker container, I had to add (as mentioned in tutorial)

-Xbootclasspath/a:/opt/jython2.7.0/jython.jar

to the openhab.conf file used by supervisor

Bernd,

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.

thanks,
craig

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.

Bernd,

Can I just comment out the:

sendExtendedQuery(f, (byte)0x2e, (byte) 00);

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.

thanks,
craig

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.