[danfossairunit] Filter lifetime management

[jlaur]

I recently changed my filters as automatic response to a notification about remaining filter life being 0%. This time I had some additional time to be curious about the algorithm for determining when filter replacement is due, which turned out to be based on the most simple algorithm of all:

i.e. time-based and linear without any sensors or other more sophisticated logic (like volume of air going through since last filter replacement).

This time I purchased new filters with no plastic frame and more filter area, which should last longer than my previous filters. So I wondered how to manage this, as my Danfoss Air A2 will still ask me to replace filter after nine months.

I did some digging in this document:
https://docs.google.com/spreadsheets/d/1FnWGzeicXrBhMg_jaHFM7jzVb_5aiflNTMsUz-j_rRo/edit#gid=0

and found three interesting registers:

Name	Endpoint	Number	Value	Type	Flags	CCM ver.
Filter Period	1	5225	9	TIME_MONTH	Writeable	2
Filter Period Min	1	5227	3	TIME_MONTH	ReadOnly	2
Filter Period Max	1	5228	9	TIME_MONTH	ReadOnly	2

So I decided to examine them, which I did by experimentally adding new channels for them, respectively DanfossHRV_Service_FilterPeriod, DanfossHRV_Service_FilterPeriodMin and DanfossHRV_Service_FilterPeriodMax.

Initially:

• [openhab.event.ItemStateChangedEvent ] - Item 'DanfossHRV_Service_FilterPeriod' changed from NULL to 9
• [openhab.event.ItemStateChangedEvent ] - Item 'DanfossHRV_Service_FilterPeriodMin' changed from NULL to 3
• [openhab.event.ItemStateChangedEvent ] - Item 'DanfossHRV_Service_FilterPeriodMax' changed from NULL to 9

As min and max are readonly I thought they probably defined the boundaries for the period to be set. But let's try to probe and see if this is actually the case:

Find actual minimum:

• [openhab.event.ItemCommandEvent ] - Item 'DanfossHRV_Service_FilterPeriod' received command 1
• [penhab.event.ItemStatePredictedEvent] - Item 'DanfossHRV_Service_FilterPeriod' predicted to become 1
• [openhab.event.ItemStateChangedEvent ] - Item 'DanfossHRV_Service_FilterPeriod' changed from 9 to 1
• [openhab.event.ItemStateChangedEvent ] - Item 'DanfossHRV_Service_FilterPeriod' changed from 1 to 9
• [openhab.event.ItemCommandEvent ] - Item 'DanfossHRV_Service_FilterPeriod' received command 2
• [penhab.event.ItemStatePredictedEvent] - Item 'DanfossHRV_Service_FilterPeriod' predicted to become 2
• [openhab.event.ItemStateChangedEvent ] - Item 'DanfossHRV_Service_FilterPeriod' changed from 9 to 2
• [openhab.event.ItemStateChangedEvent ] - Item 'DanfossHRV_Service_FilterPeriod' changed from 2 to 9
• [openhab.event.ItemCommandEvent ] - Item 'DanfossHRV_Service_FilterPeriod' received command 3
• [penhab.event.ItemStatePredictedEvent] - Item 'DanfossHRV_Service_FilterPeriod' predicted to become 3
• [openhab.event.ItemStateChangedEvent ] - Item 'DanfossHRV_Service_FilterPeriod' changed from 9 to 3

So it seems that minimum number of months allowed to be set is 3.

Find actual maximum:

• [openhab.event.ItemCommandEvent ] - Item 'DanfossHRV_Service_FilterPeriod' received command 12
• [penhab.event.ItemStatePredictedEvent] - Item 'DanfossHRV_Service_FilterPeriod' predicted to become 12
• [openhab.event.ItemStateChangedEvent ] - Item 'DanfossHRV_Service_FilterPeriod' changed from 3 to 12
• [openhab.event.ItemCommandEvent ] - Item 'DanfossHRV_Service_FilterPeriod' received command 13
• [penhab.event.ItemStatePredictedEvent] - Item 'DanfossHRV_Service_FilterPeriod' predicted to become 13
• [openhab.event.ItemStateChangedEvent ] - Item 'DanfossHRV_Service_FilterPeriod' changed from 12 to 13
• [openhab.event.ItemStateChangedEvent ] - Item 'DanfossHRV_Service_FilterPeriod' changed from 13 to 12

So in this case it seems that maximum number of months allowed to be set is actually 12, at least for my A2 unit. Which is fortunate, since my intention was to be able to extend the period from the standard 9 months.

When changing the FilterPeriod value I noticed that RemainingFilterLife is recalculated accordingly. For example, as starting point I was at 99.60784149169922% with period of 9 months as filter was replaced yesterday. After changing period to 3 months, it was recalculated to 98.82353210449219%. When setting period to 12 months it was recalculated to 100%. And when setting back to 9 months it was again calculated to 99.60784149169922%. So nothing it reset, and period can be changed freely.

Proposed solution

I would definitely like to be able to set the filter period through the binding. Hardcoding the boundary as between 3 and 12 seems reasonable as it doesn't seem possible to get this information from the CCM module.

Question now is how to implement it. My first thought is that thing configuration might be an appropriate place for this, while a channel seems less desirable, since it requires more from the user and is not changed frequently.

On the other hand, if this value can be set by the Air Dial, this could lead to some undesired results where Air Dial setting would override the value set when initializing the binding, and vice versa next time binding is initialized for whatever reason. So if this is the case it might be more appropriate to provide a channel, so rules could monitor and update it.

On my Link CC Controller this value cannot be set, but in the service menu I can read the property in device information: "Filter lifetime: 274 days". So now wondering if this value is hardcoded or read from the unit at some point. This was after changing it to 12 months, so for sure it didn't have any effect yet.

Other considerations

Values for channel service#filter_life should be rounded to one decimal. It's a percentage value with 255 possible values, so if we absolutely don't want to lose any updates (last updates before replacement needed): 1.1764706373214722% -> 0.7843137383460999% -> 0.3921568691730499% -> 0%

one decimal should be fine.

[jlaur]

After running this in production for a couple of weeks, time for a small update: The Link CC Controller sets this value every few days and after being rebooted. So there will be a fight. Still, providing a channel makes sense for stand-alone installations where openHAB is the only controller - and for using a rule to override the value set by Link CC or Air Dial.

[pravussum]

Hey @jlaur, thanks for your contribution. Providing it as a channel seems fine. I am still a bit unsure about the hardcoded boundaries, though. Why are you writing it's impossible to get this values from the CCM? Because it reports 9, although it is actually set back to 12 when updating it with an "invalid" value?
There might be more information in this PC tool mentioned in the original thread - maybe one can see/set the boundaries there? There is a "service mode"... but if I remember correctly, its a Windows software and I only tried it once back in 2015...

[jlaur]

Thanks for the link explaining how to run the PC tool in service mode. Just tried, and found a nice window with all registers. Filter-related values are consistent with the spreadsheet I used as reference for available registers:

The boundaries, Filter Period Min and Filter Period Max, can be read from the CCM. But in my case they were 3 and 9. So I did the binary search and found that actually I can set the period to anything between 3 and 12. So I don't really see the use of these read-only registers? The main problem is the "conflict" with the Link CC Controller or Air Dial. At least the Link CC wants to be in charge of this value. It doesn't read it, but simply overwrites it.

I'm almost at a point now where Link CC is useless to me. If my system would need to be recalibrated it would be needed of course, but for everyday use my openHAB sitemap provides all the controls I need. Since my Link CC is also used for heating control I'll keep it running, but I'll now try to let a rule override filter period whenever Link CC has been mangling with it.

[jlaur]

@pravussum - I mean, inconsistent, right?

[jlaur]

@pravussum - now reconsidering options. Having access to the filter replacement date would be optimal. In that case the binding could recalculate remaining filter life by itself from any filter period value. I didn't find such register, though. It might also be worth letting the binding "fight" for setting the filter period value when changed from the outside. Having this logic in rules has the side-effect of recalculation of remaining filter life after each override, so it will affect graphs, notifications etc. Keeping it in binding logic would make it possible to not expose remaining filter life while reapplying filter period value configured in binding. So maybe thing configuration after all? Not sure if worth it, all could even be done in rules with proper items and logic.

[pravussum]

Hm, in my opinion there should not be too much "black magic" (read: not apparent to the user) in the binding. If someone is willing to have such a logic, a rule is fine - maybe even using intermediary items that get updated with the "real" value and triggers the update of a "filtered" item by a rule that does specific magic.
That "fight" is kind of ugly. But I guess filing a bug report with Danfoss will be quite useless 😎

[jlaur]

Yes, I tried in the past to approach Danfoss giving "advice". :-) They are not into that.

Now checked logs for some timestamps of reverted FilterPeriod in relation to recalculated RemainingFilterLife. At least the FilterPeriod update seems to arrive first:

2021-10-07 01:13:40.837 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'DanfossHRV_Service_FilterPeriod' changed from 12 to 9
2021-10-07 01:13:51.339 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'DanfossHRV_Service_RemainingFilterLife' changed from 96.86274719238281 to 96.07843017578125
2021-10-09 12:45:56.653 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'DanfossHRV_Service_FilterPeriod' changed from 12 to 9
2021-10-09 12:46:09.012 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'DanfossHRV_Service_RemainingFilterLife' changed from 96.47058868408203 to 94.90196228027344

So I think I'm convinced now to go with the PR changes and introduce that channel to be used however any user sees fit. I'll try to write a rule based on this.

Maybe I'll also try to analyze collected data over time and see if it could be possible to detect filter replacement based on the unit having to work harder when filter is clogging. But not sure if it can be detected, and in a timely manner.

[jlaur]

@pravussum - I decided to abandon idea of overwriting unit/CCM value and instead calculate my own value using remaining filter life and filter period. Like this:

import java.time.temporal.ChronoUnit

rule "Danfoss calculate remaining filter life"
when
    Item DanfossHRV_Custom_FilterPeriod changed or
    Item DanfossHRV_Service_RemainingFilterLife changed
then
    val daysPerMonth = 30.436875
    var periodMonths = ((DanfossHRV_Service_FilterPeriod.state as Number).intValue)
    var customPeriodMonths = periodMonths
    if (DanfossHRV_Custom_FilterPeriod.state != NULL)
    {
        customPeriodMonths = ((DanfossHRV_Custom_FilterPeriod.state as Number).intValue)
    }
    var remainingPercent = ((DanfossHRV_Service_RemainingFilterLife.state as Number).doubleValue)
    var daysSinceReplacement = (100 - remainingPercent) * daysPerMonth * periodMonths / 100
    var int minutesSinceReplacement = Math::round(daysSinceReplacement * 1440).intValue
    var lastReplacementDate = now.minusMinutes(minutesSinceReplacement)
    var nextReplacementDate = lastReplacementDate.plusMonths(customPeriodMonths)
    var customRemainingPercent = Math::round((now.until(nextReplacementDate, ChronoUnit.HOURS) / (customPeriodMonths * daysPerMonth * 24)) * 1000 + 5) / 10

    DanfossHRV_Custom_RemainingFilterLife.postUpdate(customRemainingPercent)
end

So I'm using the channel as read-only. Being able to write to the channel is still useful for anyone using openHAB without any Link CC or Air Dial.

[pravussum]

OK, sounds reasonable. I guess we should document the behavior somewhere (that the value is overwritten, and that the CCM reports the "wrong" limits). Maybe a note section in the binding documentation? Or at the description of the channel?

[jlaur]

@pravussum - currently (in PR) filter_period is documented with description: "Number of months between filter replacements (between 3 and 12). This value affects calculation of filter_life by the unit, and might get overwritten by Air Dial or Link CC Controller."

Channels for filter_period_min and filter_period_max are not provided as they are useless, so nothing really to document?