Ok thats a example its not really relevant here as I don’t know what I should be doing and I am asking for advice and maybe someone that has done the same thing. I am glad we have some many people willing to help with the semantics of ticket creation but not the actual issue.
I want to to see and example of how you would replicate similar behavior to the 1.x binding on 3.0 binding that does not seem hard to understand. Maybe before so many breaking changes are introduced this should be expected? All the attempts I tried a replicating this failed the documentation is obviously not clear as I have been staring at it for 3 days if it was I would not be asking for help. I don’t see how me adding my failed examples will help other than some sort of test to show I did something?
We are all volunteers here with a very limited amount of time to answer questions on this forum. Unfortunately, when the person asking appears to show little understanding or concern about this by posting vague requests for help lacking details and not showing any indication that they have tried to do anything themselves, this is going to be the response.
We don’t have the time to do it for you if you don’t have the time to do anything for yourself. Now you may have spent hours or days on this and tried dozens of things but we have no way to know that because you didn’t tell us.
So all you are going to get are links to examples at best and requests for more details.
The exec 1 binding has been deprecated and replaced for about four years now. These concerns were taken into consideration way back when OH 2.0 was first being worked on and it’s why the 1.x version bindings remained supported in OH 2.0 through it’s entire lifetime. But at some point the old isn’t supportable any more and in OH 3 support for 1.x bindings were dropped, with the fallback of continuing to run an OH 2.x instance and using the Remote openHAB binding in an OH 3 to interact with those Items.
In short, I’m sorry you are having trouble with this but a lot of thought and effort has gone into this concern and to state otherwise is simply unfair.
Maybe show one of those attempts? Maybe tell us what specifically is failing? Show us some logs? When you take the car into the mechanics you don’t say “car no go, fix it”. You have to give them details. Without those details all we can provide are links to examples like rossko57 provided because we don’t know what else to do.
Because we don’t know what you don’t understand. We don’t know what specifically is failing. We don’t know how you are going about configuring the binding. We don’t know what you are seeing. Maybe it’s a syntax error. Maybe you’ve a permissions problem. Maybe you have a misunderstanding on what the Channels are used for.
We are now 7 posts in and no closer to having nearly enough information to help you. We are not going to do it all for you. But if you give us some details we can usually home in immediately on the root of the problem and straighten it out. Demanding us to just do it for you shows a profound lack of respect for the time of the people on this forum who are ready and willing to help.
I do not even know where to start the documentation is not clear, I have a pretty advanced setup and have run openhab since the beginning and on this I am completely stuck I moved all my MQTT stuff no issues etc this I have no starting point there are no good examples moving from 1.x syntax so yes we are starting at the beginning. I am sure I am not the only one that has faced this. So here is what I have. 1 script for on, 1 script for off. When the item receives the off command run the off script. when the item receives on execute the on script? I am sorry but I looking for very basic stage one help. I would be happy to help with documentation once this is worked out because for this its really bad.
Unfortunately the Exec 3 binding doesn’t work like that and your original post wasn’t clear that is what you are asking (it really has been four years since the last time I’ve seen an Exec 1.x config on the forum).
And I’m not certain it can be made to work like that. Each script gets its own Thing. Each Thing has two Channels that can cause the script to run, the run channel which is linked to a Switch Item and the input Channel which is linked to a String Item where you can pass arguments to your script.
You can’t have a single Item linked to two Exec Things so that it executes one script when it receives an ON command and another script when it receives an OFF command.
So if you want to use the Exec 3 binding you’ll have to change your approach. Options include:
modifying your scripts to accept command line arguments and you’ll command “ON” and “OFF” (or whatever makes sense) and the script will be called with what ever you commanded the input channel to
using a Proxy Switch Item and a rule to call a different script based on what command the Proxy Item received, at which point you may as well use the executeCommandLine Action in the rule
It very much seems that the problem is you are expecting the Exec binding docs to tell you how to do something the Exec binding is simply unable to do.
The exec binding doc shows you how to substitute the Item command into your exec command using the %2$s method. It would be easy to call pwrON.sh or pwrOFF.sh if that will serve.
I don’t think helps you much, because you need a String type Item to do that.
So you could use an intermediate String Item that commands ‘on’ or ‘off’ for the substitution. And a little rule to convert Switch ON/OFF commands to String on/off.
By the time you’ve done that, you might as well do it directly in the rule with executeCommandLine().
I’m not at all sorry to have given you an example of someone converting OH1 exec usage to OH3 exec usage in response to “are there any examples”.
I hadn’t thought of that. That’s a good idea. So the command would just be the path to the folder containing the script and the %2$s would be the name of the script to call. That’s a really clever idea!
It depends on the way the Item is displayed and interacted with. You could configure a Switch on a sitemap with a mappings which will give you buttons that can send the actual name of the script to the String Item. Something similar could be achieved in a custom widget for MainUI as well.
I wonder if sendCommand is smart enough to convert anything passed to it to a String for String Items. Then you could continue to send ON/OFF as the command and it will work without error. Then you could continue to use the String Item as if it were a Switch. That’ll require someone to experiment though.
Maybe the transform Profile could be used with the Map transformation instead of a rule as another alternative. One of the problems was/is that the profile only works with String Items, but in this case that’s exactly what we want.