Zehnder ComfoAir Filter Runtime in Weeks

Hi Guys, happy new year!

Just a short question, I’m using the comfoair binding since OH 1.8 without any issues.

There is however one topic after the 2.5 upgrade that annoys me a bit. In the past there was a rule in the documentation to translate the returned hours into weeks (to clean/exchange the filters every 12 weeks)

That thing got lost during the upgrades and I failed to create one on my own.

The new documents just put a
comfoairFilterRuntime_Message into the site map but the items only provides the regular
comfoairFilterRuntime (in hours)

Is anyone else using this binding and eager to share a solution here?

The old rule that’s no longer working was documented here btw: Samples Comfo Air Binding · openhab/openhab1-addons Wiki · GitHub

Merci.

Are you still on OH 2.5?

If so I’m not sure you’ll find much help. So much has changed since then :person_shrugging: .

If you are on OH 4, you have several options. It looks like the channels use a Number:Time. So you can just set the unit metadata on the Item to “week” and what ever the binding sends will be converted to weeks before the Item is updated.

Assuming Rules DSL you can convert the state to weeks with

(MyTimeItem.state as QuantityType<Time>).to unit("week") > 4|week

It’s easier in the other rules languages.

You can leave the state of the Item alone and set the state description pattern to %d week and it will be shown as weeks on the UI (but only on the UI, charts and in Rules well use what ever the Item’s unit metadata says to use).

The rule in the docs probably for removed because it’s not necessary.

No, I’m using the latest version in a container.

My use case is the basicUI only, all configs are stored within the corresponding config files.
So your examble does not work out of the box in a rules file.

And yes, a rule is required to devide the number of hours by 168 somehow.

Good, then you have the latest changes to UoM.

OK, so assuming it’s a Number:Time Item, everything I said above still applies. In addition you can set the label on the Item or sitemap element the same as I showed above for the state description pattern.

Yes, assuming a Number:Time Item it does work out of the box.

No, that’s the whole purpose of UoM. You didn’t have to convert between units in a time yourself. You just have to indicate what units you want and the UoM subsystem does the math for you.

If you have just a Number Item without a type or units though, you are responsible for doing everything yourself through rules or transformations. But the preferred/recommended approach is to use UoM.

Number:Time MyTimeItem { unit="weeks" }
rule "Get time in different units"
when
then
    val curr = MyTimeItem.state as QuantityType<Time>
    logInfo("units", "Default: " + curr) // weeks
    logInfo("units", "Days: " + curr.toUnit("d")) // converted to days
    logInfo("units", "Seconds: " + curr.toUnit("s")) // converted to seconds

    // compare 28 to days, the Item's state is in weeks, the UoM handles conversion to do the comparison for you
    if( curr > 28|d ) {
        logInfo("units", "MyTimeItem is over 28 days: " + curr)
    }

   // Add 7 hours to the Item, remember the Item's state is in weeks and the UoM subsystem converts between units as needed
  MyTimeItem.postUpdate(curr + 7|h) 
end

Show the time as weeks on Sitemaps

Number:Time MyTimeItem { unit="weeks" } // Item's state will always be weeks, therefore the default unit shown will be weeks, any update to the item not in weeks will be converted to weeks automatically

Number:Time MyTimeItem "Duration [%d week]" // item state is in seconds, system default, but shows on Sitemaps in weeks

In your sitemap.

Text item=MyTimeItem label="Duration [%d week]" // no matter the unit metadata or the Item label, display the Item's state as weeks for this element

In this case, if there is no unit metadata, the Item carries seconds which is converted to weeks by the sitemap automatically.

Notice there isn’t a divide by 168 anywhere. That’s handled by the UoM subsystem. You just have to tell OH what unit you want. Give it a try.

Hey, thanks for your reply at these times.

What I’ve currently done is defined an item as below:

Number:Time comfoairFilterRuntime  "Filter runtime [%.0f week]" (ComfoAir)   {channel="comfoair:comfoair:myComfoAir:times#filterHours"}

That leads to “7 week” (s is missing) but better then before for the purpose.
I was playing with your other suggestions, adding the

{ unit="weeks" }

into the above line generates an error,

2025-01-01 23:34:05.940 [WARN ] [penhab.core.library.items.NumberItem] - Unit 'weeks' could not be parsed to a known unit. Keeping old unit 's' for item 'comfoairFilterRuntime'.
2025-01-01 23:34:39.833 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'comfoair.items'
2025-01-01 23:34:39.844 [WARN ] [penhab.core.library.items.NumberItem] - Unit 'weeks' could not be parsed to a known unit. Keeping old unit 's' for item 'comfoairFilterRuntime'.
Number:Time comfoairFilterRuntime  "Filter runtime " (ComfoAir)   {unit="weeks", channel="comfoair:comfoair:myComfoAir:times#filterHours"}

results in the default “1127 h” so not sure if UoM is supported by comfoair then?
(Log shows: Unit ‘weeks’ could not be parsed to a known unit. Keeping old unit ‘s’ for item ‘comfoairFilterRuntime’.)

I also tried

Number:Time comfoairFilterRuntime  "Filter runtime " (ComfoAir)   {unit="week", channel="comfoair:comfoair:myComfoAir:times#filterHours"}

Log is happy, but result is still 1127h.

The unit is literally “week” if you want something else you have to add that outside the unit.

In this case it might work too just tack the “s” on after the ].

[%d week]s

The table at the link above shows all the supported units.

UoM is part of core. All bindings support UoM.

But you are using the non-existent unit “weeks” here.

I would have expected to see the value in seconds, not hours. The binding myst be pushing a stateDescription pattern to show the state as hours if you don’t override that.

Because you’re label doesn’t include the state (i.e. the [ ] part) it’s using the SD pattern.

Same reason. By using "Filter runtime " as the label you are telling. the sitemap renderer you’ll just use the default. And the default was set by the binding to hours.

So you can either set the state description pattern or set the state formate on the label.

"Filter runtime [%d week]s"