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

When an apt-get install works properly an openhab user and group is automatically created for you (if it doesn’t already exist), default config files are placed in the various directories that they need to be placed in (if they don’t exist) and those files are chown’d to openhab:openhab. The program is also configured to start as a service running under the openhab user.

You are missing files and those files that do exist do not have the right permissions. Therefore the apt-get install failed and failed hard. Furthermore, we tried to do a forced reinstall of openHAB through apt-get and you are still missing files and still having permission problems. Something is fundamentally, inexplicable, and drastically wrong with your system that is causing apt-get to fail.

I believe that if you had someone like kai, teichsta, or watou sitting at your machine they could probably figure out what went wrong and how to fix it but I have no confidence that you or I will be able to solve the problems at this point with you being new to OH and I not sitting at your system (not to mention I’m not one of the developers so don’t really know where to look).

Personally I would take this opportunity to figure out how to automate the configuration and deployment of what you have running on the Raspberry Pi and build up the system from scratch.

In answer to your specific questions:

Not really. If the apt-get install worked correctly everything should have the correct ownership and permissions. The issue I have in github is that additional files that I add to openhab directories (e.g. ssh keys to ~openhab) have their permissions automatically changed by the setpermissions.sh script when OH starts which breaks my exec scripts which ssh to another machine. The issue does not cause any problems with OH itself. If you are seeing setpermission.sh errors it is because the files do not have the correct ownership or permissions to allow the openhab user to change them.

It does but that is a symptom of your problems, not the root cause of your problems. I have no confidence at this point that finding and changing the permissions of the files generating the errors will result in a working OH server.

That was actually watou and it was an issue similar to what I had. Watou has some additional files in ~openhab and the setpermissions.sh script was blindly changing the permissions on all files in ~openhab, even those which need different permissions like those in ~openhab/.ssh or executable scripts.

Because either the files it is trying to change do not exist or they are owned by someone other than the openhab user. In either case it means a severely broken installation.

OK, I understand and am with you for the most part, at least until here. Granted there are 2 files that don’t exist, the users.cfg and ssh, but all the others, specifically for sure the ones that I wrote down DO exist AND are owned by openhab:openhab. And that’s where I feel like there is something small but fundamentally wrong with the USER. Afterall, those files being owned by another user shouldn’t be an issue for chown right? Since that’s what it’s supposed to do, change ownership?

Somewhere in one of the folders listed in /usr/share/openhab/bin/openhab.in.sh there are files that are not owned by openhab.

If the files are owned by someone other than openhab and permissions are such that openhab is not allowed to write to those files then chown will fail. Only root is allowed to change the ownership of a file that it doesn’t explicelt have write permissions to and the setpermissions.sh script runs as openhab.

Ok, that makes sense, but if setpermissions.sh runs as openhab what exactly is it expecting to be able to change? Wouldn’t it only have the ability to change something that’s already owned by openhab and thus not really change anything at all?

It chowns AND chmods and I think the main point is the chmod part.

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"
when
	Item ExecTest received command
then
	val results = executeCommandLine("echo -e \"POWR1   \\r\" | nc 192.168.1.28 10002", 5000)
	logInfo("ExecTest", results)
end

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:
http://pastebin.com/zSZB16bJ
and my sitemaps:
http://pastebin.com/7642QbhM

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:
http://pastebin.com/YLPJyT8A

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 192.168.1.28 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 192.168.1.28 10002", 5000
logs:
" | nc 192.168.1.28 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 192.168.1.28 10002", 5000
then in the log i see:
2016-03-20 18:52:00.054 [INFO ] [g.openhab.model.script.ExecLog] - POWR1 | nc 192.168.1.28 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: