String Items set using OnOffType ON will always appear to be OFF

[auzick (Andy Uzick)]

Point taken on the logs … I was trying to reduce clutter. Here’s another set of log entries, unredacted.

2020-04-21 13:41:33.655 [ome.event.ItemCommandEvent] - Item 'DownstairsThermostat_FanTimer_Control' received command 10
2020-04-21 13:41:33.657 [vent.ItemStateChangedEvent] - DownstairsThermostat_FanTimer_Control changed from OFF to 10
2020-04-21 13:41:33.671 [ome.event.ItemCommandEvent] - Item 'DownstairsThermostatFanMode' received command 1
2020-04-21 13:41:33.671 [nt.ItemStatePredictedEvent] - DownstairsThermostatFanMode predicted to become 1
2020-04-21 13:41:33.673 [ome.event.ItemCommandEvent] - Item 'DownstairsThermostat_FanTimer_10' received command ON
2020-04-21 13:41:33.679 [vent.ItemStateChangedEvent] - DownstairsThermostatFanMode changed from 0 to 1
2020-04-21 13:41:33.681 [vent.ItemStateChangedEvent] - DownstairsThermostat_FanTimer_Status changed from  to Fan autoshutoff expected at 13:51.
2020-04-21 13:41:33.685 [vent.ItemStateChangedEvent] - DownstairsThermostatStatus changed from System: Idle.  Fan: Off.  Humidity: 46%.  Battery: 95%.   to System: Idle.  Fan: Off.  Humidity: 46%.  Battery: 95%.  Fan autoshutoff expected at 13:51.
2020-04-21 13:41:33.821 [vent.ItemStateChangedEvent] - DownstairsThermostatFanStateLiteral changed from Off to On
2020-04-21 13:41:33.821 [vent.ItemStateChangedEvent] - DownstairsThermostatFanState changed from 0 to 1
2020-04-21 13:41:33.826 [vent.ItemStateChangedEvent] - DownstairsThermostatStatus changed from System: Idle.  Fan: Off.  Humidity: 46%.  Battery: 95%.  Fan autoshutoff expected at 13:51. to System: Idle.  Fan: On.  Humidity: 46%.  Battery: 95%.  Fan autoshutoff expected at 13:51.

@rossko57

Don’t know why that happened. Are you stripping out autoupdate predictions as well? Let’s guess so.

No, the only thing I redacted was the time and source from the log entries. What do you mean by “autoupdate predictions”? The entries that say predicted to become...? I never really understood that.

@rossko57

Meantime. DownstairsThermostat_FanTimer_Control is a member of TimedFanControls , so the rule “ThermostatFanTimerStart” runs due to the change.

Intended. This “Control” is a proxy for a user interface item. This is the rule that turns the fan on or off, and sets the autoshutoff timer if needed (along with some housekeeping like creating status strings, and “cancelling” any other timer that might be running).

@rossko57

That rule seeks Item DownstairsThermostat_FanMode
(I don’t like the use of a variable called time , that looks like a reserved word perhaps.)
That eventually gets commanded ‘1’

Yes, the Honeywell thermostat uses a number of the fan mode: 0=Auto, 1=On, 2=Circulate (a predefined timed fan cycle). Agreed on the bad variable name.

@rossko57

It also seeks an Item DownstairsThermostat_FanTimer_Status
and an Item DownstairsThermostat_FanTimer_10
and that gets commanded ON.
Technically that’s an error, because it is a String type Item and you should command with a string “ON”, not an OnOffType ON.

and

@rlkoshak

It’s interesting that these are String Items. Any reason you are not using a Switch? You appear to be using it like a Switch.

I didn’t need to use Strings here; a Switch would have done. I patterned after a different use case where I needed to differentiate between a “rule” ON and a “device” ON, so I had rules posting a RESET to it which in turn tripped a rule to turn it on. Not as elegant as @rlkoshak’s design pattern for that purpose, which I use extensively (and extended to include motion sensors and manage autoshutoff).

As far as ON vs "ON" issue, I realize I’ve been inconsistent. In my head, things like ON and OFF are just enumerations representing strings. My c# thinking, there, and apparently wrong in this context.

@rossko57

Is that where we came in, DownstairsThermostat_FanTimer_10 gets a command which starts expire timing, but it’s not a valid command so it doesn’t get reflected in state?

And we have a winner! That’s at least part of my problem … changing all the ON/OFF to "ON"/"OFF" is having an effect! I need to clean up some other stuff, but that was very helpful!

@rlkoshak

Why do you have dummy Items for the timers?

Just while troubleshooting, so I could see the state of those timer items.

@rlkoshak

Honestly this smells a whole lot like an XY Problem. What are you really trying to achieve? This seems way more complex than necessary. As best as I can tell, this would probably be better implemented using a Rule Timer and a single Number Item. Send 10, 30, or 60 to the one Number Item which triggers a Rule to set a Timer for that amount of time.

Yes, this become more complex than I expected. I’ve had problems using timers in other rules. Not really understanding the scope or threading of those timers, I wound up with all kinds of unexpected results when I tried “resetting” them, or turning them “off”. After reading and using the “Proxy Item” approach in your Manual Trigger Detection design pattern, I became enamored of the approach of allowing a proliferation of items to overcome complex rules code. I asked myself why I couldn’t do that for this use case, but I wound up with complex rules code anyway. I guess I need to sharpen my understanding of timers and refactor this.

Thanks to you both for the thoughtful responses!