Convert "null" to "0"

Item gets sometimes value Null but this Item is Number (float) and this Nulls do not save in it.
I understand that i can make “if” check, but i am sure that it can be converted much easier like .toFloat (but this do not work).
U would like to ask you, which syntax do i need to use to get a “0” from “null”?

Thanks a lot!

Hi Michael,

in most cases null is not the value 0 but the information that there´s no value at all.

kind regards

Is it NULL or Null or null?
Because they are different

In my case is 0 and the question how to convert it)))


Write a rule

rule "change from Null to 0"
    Item MyItem changed to 'Null'

I can make it with “if” but rule is even worse (slower) as “if” i thing or?

No other “faster” way?


I asked what is faster - one more rule like yours or

If (item.state == null) item.postUpdate(0)

inside of existing rule?

item.state will never be null. There is no such thing as Null unless you mean the String “Null”. An Item’s state can be NULL. Case very much matters in OH.

As Michael indicates, NULL means no state, or more specifically, that the Item has not received an Update since OH loaded the Item. NULL has no numeric value. It is not 0. So you need to either:

  • Write a Rule that runs at System started and if the Item ever changes to NULL that updates it to 0
  • Add if conditions to the Rules that use this Item to check for NULL and use a 0 instead of the Item’s state
  • Treat the NULL for what it is in your Rules, an indication that you don’t know what state this Item is in and maybe just generate a warning in your Rule or otherwise skip out of your Rule. You probably don’t want to be running automations based on uninitialized Items.

NOTE: You also need to handle UNDEF which indicates that the binding has determined it does not know what state the device is in.

As for what’s faster? That’s irrelevant. Speed doesn’t really matter in this context. Unless you are doing something really inefficiently, you can’t do anything in a Rule that will have any impact on runtime performance.

Faster to write? Again, that’s irrelevant, because the proper approach that you need choose from the list above should not be driven by what’s fast to write. There are subtle differences in the three choices which makes each one more or less appropriate based on what your ultimate goal is. Thus, this post is really more of an XY Problem.