Exec binding and echo, netcat, a pipe, carriage return and quotation marks

hmmm ok, I’m gonna try to chown everything myself. Then try to delete everything again and apt-get install again (this time making sure I delete the openhab user and group as well). THEN i’ll just reflash a raspbian issue and start from scratch again…ugh. Well thanks again for all your help…

Oh stupid me, when I was “testing” the setpermissions.sh i was running it as my Pi’s only user (that can log in), which is not openhab. That def makes that make a whole lot more sense. Alas chmoding and chowning all the folders listed did not cause the WebGUI to show up when I point my computer at http://ipaddressofpi:port/openhab.app?sitemap=mysitemap. I even tried to change the corresponding line in /etc/default/openhab to root:root (from openhab:openhab) and that didn’t work either. I’m currently writing a new image to a new SD card, but I still say this is something little I’m not understanding.

That may be, but if the apt-get worked as it should have, you shouldn’t have to understand anything. It should just work. At a minimum you should be getting logs.

Alright, you were right. After a fresh install i have a logback.xml file AND a /etc/default/openhab. Give me a short bit and maybe I’ll get ALL the way back to where I was when I started this thread:)

Thanks again for everything so far

edit: just to clarify. I had done a fresh install many times before, this was on a fresh install of raspbian.

fwiw, I think the issue with my install not launching was duplicate openhab.service files. One in /lib/systemd/system (that I put in there) and one in /usr/lib/systemd/system (that I didn’t know was installed with the apt-get package). Seems to me a conflict in those files might explain some of the odd behavior.

So I’m now 100% back to before I decided to switch over to apt-get. I’ll attack the “exec binding action as a rule” thing tomorrow.

Hurray! Glad you are back up and running!

haha yes, I’m quite happy. However, what we started on: getting my non-working exec item to fire as a rule when a click a button on the sitemap, still doesn’t seem to be sending any info to the log. At least not the openhab.log (the main one). Everytime the button is flicked i get this line:
[.w.internal.servlet.CmdServlet] - Received command 'TOGGLE' for item 'ExecTest', but the item does not exist in the registry
and I get this error when opehHAB reloads/refreshes (and always four times):
2016-03-19 17:56:13.663 [ERROR] [o.u.i.items.ItemUIRegistryImpl] - Cannot retrieve item ExecTest for widget org.openhab.model.sitemap.Switch 2016-03-19 17:56:13.665 [ERROR] [o.u.i.items.ItemUIRegistryImpl] - Cannot retrieve item ExecTest for widget org.openhab.model.sitemap.Switch 2016-03-19 17:56:13.666 [ERROR] [o.u.i.items.ItemUIRegistryImpl] - Cannot retrieve item ExecTest for widget org.openhab.model.sitemap.Switch 2016-03-19 17:56:13.667 [ERROR] [o.u.i.items.ItemUIRegistryImpl] - Cannot retrieve item ExecTest for widget org.openhab.model.sitemap.Switch

I believe you stated before, that these lines mean there is an error in my items file, and that nothing will work past that, but the only line in there for this item is:
Switch ExecTest

Am i looking in the right log (/var/log/openhab/openhab.log)? Is there some setting that much be enabled to log the results, perhaps in logback.xml? Maybe to just test my ability to right a rule, is there a very simple rule I could write to simply test that I’ve got that aspect correct?

For completeness, this is the line in my sitemap:
Switch item=ExecTest label="Exec Test"
And this is the rule I’m using:
import org.openhab.core.library.types.*

rule "ExecTest"
	Item ExecTest received command
	val results = executeCommandLine("echo -e \"POWR1   \\r\" | nc 10002", 5000)
	logInfo("ExecTest", results)

haha i got to the end of the message and realized that I had named my rule with a .rules extension and not a .rule. Though changing it doesn’t seem to have made any difference in what shows up in the log when the button is toggled.

When OH first starts do you see a line saying that OH loaded whatever .items file that Switch is in? Are there any errors after that line or in stead of that line?

For example if you Switch is defined in the file test.items you should see a line in openhab.log that says something along the lines of “Loaded test.items”.

That is the right one.

You can copy the logback-debug.xml to the logback.xml and restart OH, but really the things we should be seeing do not require debug logging.

I don’t think the problem is with your rules (yet). Try creating some more Items and put them on your sitemap. Rules are pointless until we can get that working.

.rules is correct for rules files. Items should be in a .items file. So for example, your ExecTest Item should be declared in an items file (e.g. test.items) in the items folder and the rule in a .rules folder (e.g. test.rules) in the rules folder. And any time you edit these files you should shortly thereafter see a log statement in openhab.log indicating the file was loaded.

yeah here’s the relavant line, plus the one before it and a few after:
`2016-03-19 18:08:04.693 [INFO ] [c.internal.ModelRepositoryImpl] - Loading model '1309.sitemap’
2016-03-19 18:08:05.388 [INFO ] [c.internal.ModelRepositoryImpl] - Loading model '1309.items’
2016-03-19 18:08:08.691 [INFO ] [.o.u.w.i.servlet.WebAppServlet] - Started Classic UI at /classicui/openhab.app
2016-03-19 18:08:16.897 [INFO ] [.p.rrd4j.internal.RRD4jService] - Removing invalid defintion component = null heartbeat = 0 min/max = 0.0/0.0 step = 0 0 archives(s) = [] 0 items(s) = []
2016-03-19 18:08:17.079 [INFO ] [.service.AbstractActiveService] - InsteonPLM has been started
2016-03-19 18:08:17.102 [INFO ] [.service.AbstractActiveService] - Exec Refresh Service has been started

To clarify, this items file has MANY items in it that work just fine. Including many exec binding items (all related to IR blasting). for completeness, here is a pastebin of my items file:
and my sitemaps:

the items file used to have even more items, a series of items to control my TV over HTTP (the commands I’ve been trying to unsuccessfully add into openhab as exec items), but I’ve removed anything that isn’t working and nothing but the ExecTest item seems to be barfing on the log. Here is a pastebin of that:

ah, noted and changed.

So does any of that help in discovering why i’m not experiencing what you expect with this “exec item as a rule” strategy?

No, the mystery deepens.

Maybe ExecTest is a reserved word or something, as unlikely as that seems. Have you tried renaming it?

If you move the item further up in your .items file, does everything after it continue to work?

That error you are seeing is coming from the Sitemap parser. When it tries to create the part of the sitemap that represents ExecTest it can’t find the Item and bails on generating your sitemap. Until we figure out why the sitemap can’t find the Item, there is nothing we can do in the Rules to address the problem.

tried renaming it to no success, but…

This WORKED you genius you. got some weird things in my log:
" | nc 10002INFO ] [.openhab.model.script.ExecTest] - "POWR1

but its something I can work with. The only thing I can think of is maybe its something in the comment I made above the line in the .items file. Do parenthesis in comments cause issues sometimes?

It shouldn’t but I admit I never use the /* */ form for comments and use //instead. Maybe it the parser doesn’t handle multiline C style commenting as well…

So I haven’t actually solved my exec binding item question, but I did trace down the offending issue in the .items file that was causing the ExecTest item (and it would seem other items) not to be recognized. If you look at my .items file (again here: http://pastebin.com/zSZB16bJ) you’ll notice every entry is of the type “Switch” EXCEPT for one line in the Bluray section and one in DirecTV which are of the type Number.

If the Switch ExecTest was put ABOVE that Number item, no logging or error appeared for it or, it turned out, any other item listed after. Once I removed the Number items, not only was the ExecTest recognized everywhere, but it found another syntactical error in the .items file that was below the first Number item, and thus unlogged until now. So that’s the issue I WAS having, now trying to deciper how to get java to handle the whitespaces and carriage returns…

Care to elaborate? Compared to most environments Java and therefore the Rules DSL is better able to handle spaces and white space than most.

One thing I do notice in your first Number Item (AV_Bluray_IR_Number) you do not close the quotes on your label.

"Blu-ray Number

should be

"Blu-ray Number"

That would explain why everything after that fails to load. It is treating the rest of the file as if it were the label for that Item.

Your other Number Item also fails to close the quotes on the label.

Yes, I was a bit premature in chalking it up to whitespace. There is SOME issue and its definitely at least in part due to the nested double quotes of the exec command at the beginning. Some examples:

In the rules file (inside the executeCommandLine):
"echo -e \'POWR1 \\r\' | nc 10002", 5000
" | nc 10002INFO ] [.openhab.model.script.ExecTest] - "POWR1
complete with 3 spaces after POWR1. It appears that the carriage return is read and everything after is, for some reason, prepended to the loglevel bracket of the log. Can’t say I understand that at all.

If this is inside executeCommandLine in the rules:
"echo -e \"POWR1 \r\" | nc 10002", 5000
then in the log i see:
2016-03-20 18:52:00.054 [INFO ] [g.openhab.model.script.ExecLog] - POWR1 | nc 10002
And the 3 spaces, carriage return and then 4th space before the pipe are all returned as a single space.

I looked into a few more things today that I’m gonna try now, because besides there clearly being an issue with nested double quotes, in every iteration I’ve tried the pipe (|) is simply read as a pipe and doesn’t actually redirect the output of the first command into the second command. It’s here that I thought maybe my issue was the whitespace, cause in the exec binding wiki page it very vaguely says:
Sometimes the commandLine isn't executed properly. In that cases another exec-method can be used. To accomplish this please use the special delimiter @@ to split command line parameters.
and has some examples like thus:
exec="<[/bin/sh@@-c@@uptime | awk '{ print $10 }':60000:REGEX((.*?))]"
and unfortunately all input commands.

Ah of course, stupid me. That makes sense, everything after that Number item was being read as one giant label :disappointed:

Some further tests:

trying to escape out the pipe with a backslash invariably leads to an “Error during execution” line in the log

Curiously: this in the rule:
"/bin/echo -e \\x22POWR1 \\x0d\\x22 | /bin/nc 10002", 5000
yields this is the log:
" | /bin/nc 10002] [g.openhab.model.script.ExecLog] - "POWR1
which is almost identical to the original result, but with only ONE trailing space after POWR1. So weird.

This first attempt to use the “double at” delimiter:
"/bin/echo@@-e@@"POWR1@@@@@@\r\" | /bin/nc 10002", 5000
2016-03-21 17:06:34.941 [INFO ] [g.openhab.io.net.exec.ExecUtil] - executed commandLine '[/bin/echo, -e]'

Which is at least a new response. I guess I’ll play around with this some more…

You might consider writing your command as a shell script and call that script from the exec binding.

Oh, another gotcha might be that the openhab user doesn’t have a shell set. If you run:

cat /etc/passwd | grep openhab

If you see something like

openhab:x:127:137:openHAB runtime user,,,:/var/lib/openhab:/bin/false

the openhab user doesn’t have a shell. And without a shell you do not get shell commands like | . Try adding a default shell to the openhab user:

sudo chsh -s /usr/local/bin/bash openhab

YOU’RE RIGHT! I remember i discovered this while trying to solve my issues after moving back to apt-get, but didn’t make the change on the new installation. You may be right! I’ll report back soon

Quick Q:

My /usr/local/bin/ directory is empty so I instead ran:
sudo chsh -s /bin/bash openhab

That a big 'nix no-no? Or is that probably fine?

In any event, nothing changed upon first doing that, but I realized it may take a reboot. Doing that now