updateState(..., NaN)

How can I assign a NaN to a channel with a Number type? Before it is assigned any value, it has a NaN state so it should be possible somehow to assign it later even after it had been assigned a number, if this number is not up to date anymore.

You should pass UnDefType.UNDEF as the state. NaN is just what paperUI displays for NULL or UNDEF states.

@pacive, thank you for your fast reply. From the description, this indeed seems the right class to use. However, when I do this: updateState(name, UnDefType.UNDEF); it returns an error because updateState() does not support UnDefType as second argument. Any idea what might help?
I also think it is strange that no ver.2 binding uses UnDefType.UNDEF at all… only some ver.1 bindings. Is it possible that nobody has the requirement of setting a channel to undef?

I use it in the smhi binding in certain cases:

    private void updateChannel(Channel channel, @Nullable BigDecimal value) {
        String id = channel.getUID().getIdWithoutGroup();
        State newState = UnDefType.NULL;

        if (value != null) {
            switch (id) {
                case PERCENT_FROZEN:
                    // Smhi returns -9 for spp if there's no precipitation, convert to UNDEF
                    if (value.intValue() == -9) {
                        newState = UnDefType.UNDEF;
                    } else {
                        newState = new QuantityType<>(value, SmartHomeUnits.PERCENT);
        updateState(channel.getUID(), newState);

Try updateState(name, (State) UnDefType.UNDEF); and see if that helps.

You need org.eclipse.smarthome.core.types.UnDefType

That was it. Before, it had included org.openhab.core.types.UnDefType, and it did not work. With ‘your’ smarthome class it works perfectly. Thank you!

Just for completeness. The org.openhab.core.types.UnDefType is from the openHAB 1 compatibility layer. In Eclipse this library is in the path and therefor you can end up using that class.

With openHAB 3 the namespace org.eclipse will be gone, as well as the openHAB 1 compatibility layer. As a result in openHAB 3 you would actually do need to include org.openhab.core.types.UnDefType, but it’s the class that is currently in org.eclipse namespace.