sendCommand vs postUpdate

Hi,

I would like to know when should I used each of them? Please, can you explain?

thanks,

-> Update only changes the value, Command sends it to the binding.

3 Likes

I’ve been trying to understand this better myself. I’ve read a bunch of documentation, and I’m still a little confused.

I have the following rules for a servo which I plan to control my blinds:

// Servo
rule Servo
when
	Item Servo received command
then	
	if(receivedCommand==UP){
		sendCommand(Arduino, "105;10;1;1;29\n")
		}
	if(receivedCommand==DOWN){
		sendCommand(Arduino, "105;10;1;1;30\n")
		}
	if(receivedCommand==STOP){
		sendCommand(Arduino, "105;10;1;1;31\n")
		}

I also have a rule to open the blinds at 0700:

rule "OpenBlinds0700"
when
	Time cron "0 0 7 * * ?" // every day at 0700 (format 'second minute hour day-of-month day-of-week year(optional)')
then
	sendCommand(Arduino, "105;10;1;1;29\n")
	println("Blinds Opened at 0700")
end

In my OpenBlinds0700 rule, could I just use a postUpdate(Servo, UP) and have that change trigger my ‘Servo’ rule? I think this would require changing the ‘Servo’ rule from:

 when
    	Item Servo received command

to:

 when
    	Item Servo received update

Am I understanding this correctly, or is there a better way to do what I’m trying to do?

Semantically you’re doing the right thing by sending a command. Your cron rule sends a command to your Servo item and you have a rule which acts when your Servo item receives a command to forward it on to the Arduino.

You could change the cron rule and Servo rule to use postUpdate/received update but personally I would leave it as is.

This is a bit of a simplification, but should help explain:

If you want to tell something to change (turn a light on, change the thermostat to a new temperature, start raising the blinds, etc.), then you want to send a command to an item. If your items’ states are not being updated by a binding, the autoupdate feature (see below) or something else external, you will probably want to update the state in a rule, using postUpdate.

When you click on buttons, sliders or other widgets in the UI, that sends commands to items. Usually this causes the state of the item to update automatically at the same time (using the default autoupdate feature), but there are causes where autoupdate is not performed, depending on the binding or configuration in your .items file if autoupdate="false" is present. Commands can also be sent other ways, such as the REST API and CMD servlet.

Your rules can trigger on items receiving commands, items’ states updating, or items’ states changing to a different value.

3 Likes

After a bit more testing, I seem to have found an easier way to do what I was attempting:

rule "OpenBlinds0700"
when
	Time cron "0 0 0 * * ?" // every day at 0700 (format 'second minute hour day-of-month day-of-week year(optional)')
then
	sendCommand(Servo, UP)
	postUpdate(Servo, UP)
	println("Blinds Opened at 0700")
end

The problem was exactly what you stated - the state was not updating on my openHAB app, although the command was being sent. As I understand it, the above sends the servo-up command which is received by my ‘Servo’ rule and processed. I’m thinking I could even remove the postUpdate line from the above command since the ‘Servo’ rule typically autoupdates the state. I have not tried this, but I think it would work.

1 Like

@watou I thought this simple explanation could be very helpful to beginners and have put it on the wiki page about Actions with a link back to this page. Please let me know if this is a problem. Thanks

Not a problem, but please consider removing the link to the forum, my user name, the quote formatting, “This is a bit of a simplification, but should help explain:”, the sub entry in the table of contents, and fixing my typos like “there are causes where”. So just the minimal helpful parts are left. :slight_smile:

Thanks for thinking to share helpful info.

Can anyone elaborate the difference between “send” and “sendCommand”?
I can do this:
group.send(switch.state)
and it sends a command with the state (ON/OFF) to every item in the group.
This is tested and works very well.
However, the openHAB designer shows me following error:
Incompatible types. Expected org.openhab.core.types.Command but was org.openhab.core.types.State
Am I missing a cast? Why is it shown as an error when during runtime it works without issues?
Thank you!

Here are the rules, extracted from source:

  • interface Command extends Type
  • interface State extends Type
  • interface PrimitiveType extends Type
  • enum OnOffType implements PrimitiveType, State, Command

But the method group.send needs a Command, not a State. But you can see that OnOffType is both a Command and a State, so it’s no harm to cast it:

import org.openhab.core.types.Command  // not sure if needed
...
group.send(switch.state as Command)
1 Like

Thanks for tidying it up. You are right that it should probably be in a different part of the wiki, but it is a start that it is in the most relevant part at the moment.

Whilst the original technical descriptions on their own are accurate. The additional explanations you have written help make it easier to understand the differences. Thanks.

On a side note, I really like the way that MDN (Mozilla Developer Network) write their docs (example link). With a good mix of technical definitions, explanations and examples, with a helpful “see also” section at the bottom. It is approachable and relevant to all skill levels.

Whilst it is unrealistic to expect the same level of documentation with openHAB. Adding more simplified explanations is a big start and really helps make it more approachable. Which is great considering the growing interest in home automation and IoT is exposing openHAB to more people from all skill levels.

Thanks again

I agree with your points, and appreciate your additions to the documentation. There is obviously much more to be done in that department.

Hello,

sorry for resurrecting the thread, but I still am not 100% sure I got the difference. Did I get it right that any sendCommand will trigger rules with received command, while a postUpdate will not trigger those rules but only those that trigger on received update?

I’m asking to make sure that a postUpdate actually does not trigger a rule but just changes the state of some items to a default value on system startup. Obviously when setting defaults I don’t want to trigger rules that actually only should be triggered when the user interacts with the system.

Does that make sense?

I believe that the answer is: Yes

What do you mean here? How do you “set defaults”? (are you referring to Persistence and restoreOnStartup or something else like a rule?)

Hello @Dim,

thanks for the help :slight_smile:

I set the defaults through a rule that is triggered by system started and which would possibly override a previous user choice; thus I don’t want it to trigger rules but just put the switch for the user into a particular state.

Got it :slight_smile:

So, to summarize (also for others): I believe that if you use postUpdate in the rule that is triggered by system started, you shouldn’t trigger any other rules which depend on received command. The other rules that are triggered by received update will be fired since the State will be updated from the postUpdate.

Of course: you should try these stuff out to make sure :slight_smile:

2 Likes

Check out the updated openHab documentation here : Its much more clear now: A table shows what the effect is of manipulating items:

  Command \ Rule Trigger    received update     received command    changed
  postUpdate                  ⚡ rule fires        ❌               (depends)
  sendCommand                   ❌              ⚡ rule fires       (depends)
  Change through Binding      ⚡ rule fires      ⚡ rule fires       (depends)
2 Likes