In all the years I’ve been using OH and supporting it on this forum this is the first I’ve encountered anyone trying to use the Exec persistence. I have no idea whether or not it actually works, though I have no reason to believe it wouldn’t work. And unfortunately the docs leave much to be desired. As far as I can tell your .persist file is correct though.
Have you installed the Exec persistence addon? It might be the case that you need to also install the legacy Exec 1.x version addon as well. Some of the older niche addons like this have a dependency on a correctly installed and configured 1.x version binding. Usually that is documented in the readme but as you’ve seen, the readme for this particular addon is pretty spare.
Access writes and file ownerships for which user, openhabian or openhab?
Thanks, I’ve been able to select the “exec” persistency in paper UI configuration once the legacy addons package has been installed (apt-get install openhab2-addons-legacy)
but still nothing, I’m continuing to try to understand why. For information, I want to use the exec persistence service just to send items value changes to a Kafka server, and I thought it was quite an easy way to do it, … in theory.
Log4j2 has a Kafka appender. You should be able to configure the events logger to output straight to Kafka.
There is a whole host of things that could go wrong here. You need to narrow the problem down. Create a Rule that calls the script using executeCommandLine. This will tell you whether or not the problem is related to permissions.
# cat debug.rules
rule "exec persist debug"
Item TEMPERATURE_HUMIDITY64769_Temperature received update
executeCommandLine("/bin/sh /etc/openhab2/persistence/exec-persist.sh "+TEMPERATURE_HUMIDITY64769_Temperature.state)
so with a rule it run fine and I can get the item temperature in the results.log file, in the logs I get
Rules may become an interesting work around to my Exec persist issue, but it looks like the rule engine is quite more limited than the one I’m using almost everyday which is “drools”. But by using group (member of “group” trigger) I might be able to create 1 rule to trigger my command line for each sensors…
But comparing relatively general purpose programming languages to a BRMS is really more of an apples to oranges comparison. OH Rules are not intended to address that problem space.
Indeed, you can use a Group and Member of Trigger to implement this. But don’t jump too far ahead. This was just an experiment to eliminate the root cause of the problem being that the openhab user was unable to execute the script for some reason. It was never intended to be an alternative solution. But if you are planning on using an alternative solution anyway that’s fine too.
thanks for all your answers, it helps me to understand OH as I’m a new user one last question, in which git repo/branch can I take a look if I want to help to fix the root issue ? I did some git clone on some repos and some find exec grep… but didn’t find any clue of where the exec persistence mechanism is implemented.
We have to identify what’s actually the root issue first. At this point all we really know is that it isn’t that openHAB doesn’t have permission or is otherwise unable to execute the script. There can be a whole host of other problems including:
the add-on is simply broken
the add-on wasn’t actually installed or installed correctly
there is an undocumented dependency that’s not installed
there was a problem with the .persist file that isn’t being reported
There is a lot more that would need to be done to determine whether the problem is caused by configuration or by a bug.
You didn’t say if that actually resulted in the data arriving at the remote service.
Just because the log said the command line wasexecuted doesn’t mean it did anything useful. If there was an error response, your rule chooses to ignore it.