openHAB 2.5.0.M1 Exec Binding issues

Dear all,

I’m running openHAB 2.5.0.M1 and have an issue with the Exec binding that does not make any sense to me. In all likelihood I’m doing it wrong so grateful for any pointers.

What I am trying to achieve is the following:
I have an air con that is controllable by Panasonic Comfort Cloud. There are python scripts that allow me to read the current status and also send commands to the air con.

I have - so far - done this with executeCommandLine - i.e. invoked the script and then used regex to populate a few items in openHAB - which has worked well but that is not a long-term solution since it leads to cron-expression based rules stopping after a few days - which based on search results is a known issue with executeCommandLine.

So I want to move to the Exec binding but I’m struggling to make this work.

My thing definition:

Thing exec:command:airConStatus [command="/home/pi/airConControl/airConStatus.sh", interval=180, timeout=30, autorun=true]

My item definition:

String airConFromExec “[%s]” {channel=“exec:command:airConStatus:output”}

My sitemap definition:

Text item=airConFromExec

My expectation is that airConFromExec should show the output of the script - which I confirm as working as the openhab user with an output appearing in the shell when I run it manually.

However, BasicUI is stubbornly showing me this:

2019-08-27T22:27:14.906+01:00

for airConFromExec, which is the (correct) lastexecution time.

Why is it showing that when I have defined the item as the output channel!?

I hope this makes sense. Grateful for all input.

Martin

No it isn’t, unless something goes wrong in whatever you are executing.

Yes, everything looks good. Only weird looking thing is no label text for your Item. I suspect you’ve just got some old settings cached somewhere.
I would try stop / clear cache / restart at first.
Keep an lookout in openhab.log and events.log for info about your runs.

2.5M1 is the old testing version replaced by 2.5M2 If there is a configuration issue, that will not help tough.

Thank you. Maybe I should have rephrased when I said “which based on search results is a known issue with executeCommandLine”. I’m referring to this thread Why have my Rules stopped running? Why Thread::sleep is a bad idea which is exactly the issue I am having.

I am running executeCommandLine with a timeout (since otherwise I am not getting any output back). And that in turn is causing (at least my cron timer based) rules to stop running after a couple of days.

Good shout. I will try the stopping / clearing cache / restarting tomorrow. There is nothing in openhab.log. Will check events.log.

So looking at events.log (thank you for the hint!) I am seeing this (edited for readability)

2019-08-27 23:22:50.034 [vent.ItemStateChangedEvent] - airConFromExec changed from 2019-08-27T23:19:45.206+0100 to {exactly the output I want}

2019-08-27 23:22:50.038 [vent.ItemStateChangedEvent] - airConFromExec changed from {output I want} to 2019-08-27T23:22:50.016+0100

So it does work in that it shows the output I want (i.e. the output of the script). But 4 ms later it changes back to the timestamp!

Huh??

I will try the restart / clearing of cache tomorrow and see whether that helps.

This was my first thought. No need for anything other then executeCommandLine. If your cron based rules are getting buggered up, it is because threads are hanging. You get 5 threads by default for your rules but only 2 for quartz timers I think so if something hangs or runs long (as you’ve read) things get sideways. Watch the logs, figure out what is going on.

oh please try to use code fences for your item and thing examples and log extracts ect. (thank you for providing) and maybe post your cron based rules and let the experts take a peek

I’ll hazard the guess that your Item is currently linked to both output and lastrun channels. (multi channels is legitimate configuration.) Probably a leftover from tinkering?

It’s worth noting that on recent snapshots the pool has been increased to 10.

1 Like