Number Item setting by rule does not work

Hi, i’m sorry to ask this question but its not possible to set an item variable (type number).

I have a solar plant that takes the collector temperature from the controller. i would like to set the collector temperature at midnight every day to Zero (0) by a time rule.

i tried “CollectorTemp=0” which seems to be not so smart / correct. So i changed it after several readings to CollectorTemp.sendCommand(0) but this does not work either.

Any idea what i still do wrong to set a number item manually by rule?
Thanks a lot

Hi

If your “CollectorTemp” item is a Number type, that command should work as is.

You could try
CollectorTemp.sendCommand("0")

Could you post your complete rule (in code fences </>) so that we can see the context your command is used in.

In openHAB, commands are quite different from states.
Depending on how your mystery Item is configured, commands may have no effect on its state.

If you want to update an Item’s state, then update it -
myItem.postUpdate(0)

I’m not sure what the purpose of trying to force zero onto a temperature sensor reading is? What do you expect to happen when the sensor next sends a real temperature?

Hi, thanks for the information. Will try postupdate but still a mystery to me about whiy sendCommand not works. e.g. in Selection it works great.

The reason for sending a Zero (maybe you have a way better idea) is that the SOLAR controller will turn OFF every day arroudn 4pm when there is no sun anymore. So the last value of maybe 40°C will stay in the system all night long. If i look in the morning and still see a value arround 40°C i have no first sight idea of if its offline or already online and 40°C is the actual value. if i reset the value to a dummy Zero i see in the morning immediately if its still dummy or a real temperature from the roof. a little stupid but at least could work for myself…

will provide the rule when i’m home tonight. Thanks again. Norbert

Oh, maybe you want to use the expire binding. Find out how often your sensor usually updates your Item, and use expire of double the time to set state UNDEF when updates fail to arrive.

UNDEF is better than 0 because your rules can distinguish between invalid value and frost.

expire looks nice, did not know it and would perfectly fit my idea of setting values to an item not updating anymore…

Setting FROST instead of UNDEF was anyhow not my best choice.

Expire is an OH1 binding, does there exist an updated version 2?

Nope. Expire 1.x works fine on OH2, but knows nothing about things and channels, so you must link it to Items in the old fashioned way in curly brackets { }
You’d need to enable 1.x binding support in OH2 if this is your first.

UNDEF is a recognized state within openHAB, generally used to populate e.g. a sensor reading Item when there there is a problem like a communication failure. So it’d be consistent to use it in this case, although expire will let you set what you want e.g 9999

I just started the binding and changed the item accordingly…now waiting to trigger after 15mins :slight_smile:
Maybe you know this, what happens if UNDEF is set to the graph…how will an UNDEF be displayed in a graph?

No idea, probably depends what persistence and graphing you are using.
I’ve got a simplistic sitemap Chart from rrd4j data and it just plots a line between valid data

Thanks,
is there any additional config required for this binding, - the docu does not say so. Asking because after 15mins nothing happens…at least still the same old valid value is presented in classic UI.

Can you say how UNDEF looks like in ClassicUI? is it a “----”?

Number CollectorTemp "Collector Temp  [%.1f °C]" <temperature> (SolarTherm) {channel="resol:device:f50fd4d6:DeltaSol_MX-Regler:Temperature_sensor_1",expire="15m"}

hm, i’m confused or somehow i start understanding why sendCommand and PostUpdate did not work…

Because after not working properly (expire) at all, i now did a manual update via HTTP from the browser…the values simply do not change…so could it be the case that for whatever reason this RESOL binding does block external manipulation???

http://192.168.1.11:8080/classicui/CMD?CollectorTemp=29

Well, it looks like … UNDEF It’s a predefined “system constant”, like ON and OFF for switches.

There’s no configuring for the binding, but the expire in each Item needs you to define what you want it to do.

CollectorTemp "Collector Temp [%.1f °C]" &lt;temperature&gt; (SolarTherm) {channel="resol:device:f50fd4d6:DeltaSol_MX-Regler:Temperature_sensor_1",expire="15m, state=UNDEF"}

Never trust command to update an Item. That’s not what it is for. If you want to force a state, force an update. You can do this from REST API and also read back the actual value in the system. From the description so far, you might be looking at a failure to refresh in the UI. Look in the event.log for changes.

I’ve no idea how your resol binding works - if it keeps updating Item even when device is offline, that’s a problem.