No. An Item can only have one State at a time. It is certainly possible that an Item could change state while a Rule is running and that can cause some problems when people do not plan for that or expect it. It can also take some time for an Item to reach a state after it has been commanded or updated which causes some people problems (e.g. sendCommand to an Item then immediately log our the state of that Item and see in the log that the Item is still in the old state because the Item hasn’t finished processing the command yet).
But none of those cases are present in OP’s Rule and the error he saw had to do with type.
The reason it was confusing was because it says “Could not cast 7.7 to DecimalType” meaning that the 7.7 is getting to the Rule somehow which should eliminate the possibility that the Item is NULL. And a number Item can only have a DecimalType or NULL as its state so the error really doesn’t make sense. Something else weird is going on, perhaps having to do with the calls to doubleValue, but there again I would have expected the error to be different.
Now the problem that I discussed in that thread you linked to is different. In Object Oriented Programming, There are two relationships: “is a” and “has a”. What that post is showing the “is a” relationships for the DecimalType class. The tl;dr is that DecimalType is also a Number. The one Object (instance of a Class) is both types at the same time.
Given that, let’s say we have the following sendCommand methods on the NumberItem class:
- sendCommand(String cmd)
- sendCommand(DecimalType cmd)
- sendCommand(Number cmd)
Now lets say I call sendCommand with a DecimalType. The Rules Engine gets confused because DecimalType is both a DecimalType and a Number. Consequently two of the three sendCommand methods are valid and it doesn’t have any other information to go on to tell it which one is the one it should call. Both are equally valid. So it generates an error; a different error from here that says something like “Ambiguous method call blah blah blah”.
This is why I recommend never casting to DecimalType in Rules and always casting to Number. In your Rule you want to treat the State as a Number anyway and it avoids this specific error.
But, like I said, that error is not what OP experienced above. Why there was an error and why just casting to Number instead of DecimalType fixed it.
I’ve been toying with the idea of a “just enough programming tutorial to write OH Rules” but it’s a really big problem. How much is just enough? How much is too much? Is it really appropriate to create and maintain as part of the OH docs themselves? Should I write a book?