For this example (not for other kind of items) is there a problem by using
PUT or POST ?
I can completely remove the PUT from my client code and use only POST
command, also for change the state of the lamps, or is there a special
condition where i need PUT ?
It seems to me that we never really need the PUT verbs.
thanks, maybe now i “see”
I tested it only with demo setup, so i cannot view the difference, now i understand that postUpdate() change only the state of the items, so example on a Classic UI i view the lightswitch change it position but the real Lamp connected to it will not switched on.
But this means also that at the end of a postCommand() automatically is called, always, a postUpdate() ?
P.S.: maybe you mean sendCommand() ? because there is no postCommand() in the Action documentation
You are probably right about action names - I was looking in the source code where postUpdate and postCommand are the methods that are called, but in the action documentation I think your naming is correct.
So this is a very important info, because example if we open a Garage whit a POST, and have a limit switch installed, we want that the /state is changed at the end of movement, when the limit switch is activated, not immediately after the POST command.
Do you know where is possible search this info, or the name for search on github code ?
Ok - this took me a while to find and it doesn’t appear to be in the wiki!
This link shows an example of how to make a pushbutton. It uses a (seemingly undocumented) command in the item definition called autoupdate="false", and it looks like this is the way to stop the status of the item automatically updating when the command has been sent. It’s not something I’ve personally used, so you might want to give it a test
I think if you want to operate your garage door as you suggest, then you will need to add this option. However, I would suggest that in your example you actually need two items - one that is the actuator that is linked to the command to open the door (and therefore shows the state of the motor that is moving the door) and the other the status of the sensor that shows if the door is fully open or not…
Many bindings are directional, such as the http and mqtt bindings, so it will depend on how your device is interfaced with openhab. In fact you can even mix and match bindings within item definitions.
For example, a device that is connected that is controlled/polled through http get requests (in this case a holding relay that needs to be turned on and off though a separate request, and a separate contact that shows the status). Notice the direction > for outbound or < for inbound: