Badly parsed values?

[buczo23]

Ok, you asked me to create an issue with problems mentioned in the previous bug, so here it comes :)

UI output:

The readings at console/log level:

Does the UI output seem to be wrongly parsed? As you can see. Filter output from API changed as for now API returns "initUsagePeriod: 87102227," which seems to be not countable by /60/60/24 anymore as we get huge value and period counted later reach minus values (180-1008).

I'm using Blueair 280i.

If you want more logs please drop me a line.

[mylesagray]

Looking at the UI output - that matches the data pulled back.

In addition the initUsagePeriod shows the length of time in seconds since you last changed the filters in your purifier - so in this case, about 3 years.

That seems to be correct - have you ever run the routine on your purifier to "change" the filters?

If not, it may be worth doing that and see that return to 0 to confirm.

[buczo23]

Strange, as native app shows proper values estimated time and status that filter is ok. If you do not finish change procedure the purifier will constantly alert you with the information that you have to change your filter.

[buczo23]

@mylesagray any updates? I've recently reset filter and got the same values, so for sure it is something which is wrongly parsed as my BlueAir app shows correctly 180 days left after "filter counter reset".

[mylesagray]

So I reset my filter timer today and in the app I see that the numbers are reset, as expected.

In the Eve app I see that filter change is set to "Not Needed", however the filter status remains at 0% - when I check the initUsagePeriod I'm getting about 667 days - which is around about how long ago I bought and installed it...

I have a Postman collection built here: https://github.com/mylesagray/homebridge-blueair#postman-collection-and-environment

Can you run through that in order until you get to the "Get BlueAir info" request and post the output? Mine looks like this:

{
    "uuid": "{MY ID WAS HERE}",
    "name": "Living Room BlueAir",
    "timezone": "Europe/London",
    "compatibility": "classic_680i",
    "model": "1.0.6",
    "mac": "{MY MAC WAS HERE}",
    "firmware": "1.1.37",
    "mcuFirmware": "1.0.35",
    "wlanDriver": "V10",
    "lastSyncDate": 1581332077,
    "installationDate": 1519225355,
    "lastCalibrationDate": 1579514261,
    "initUsagePeriod": 57683545,
    "rebootPeriod": 10998,
    "aimUpdateDate": 1545038783,
    "roomLocation": "kitchen"
}

There must be another API that I haven't scoped out with Charles that does the get/set of filter state, if we can find the API I can add it to the code.

M

[mylesagray]

So interestingly, I hooked up my phone to Charles again and issued the filter reset command on the BlueAir - it looks like the BlueAir itself communicates to the server and POSTs to an API, which tells the phone (via a push somehow) that the filter was changed. The API requests are entirely opaque to the proxy, so they are going out of band somehow - whether the BlueAir is communicating directly with the phone over LAN, I'm not sure.

Needs more investigation.

I have a feeling this fan_usage API call may be related:

{
    "userId": 23064,
    "uuid": "2504776C658038B1",
    "scope": "device",
    "name": "fan_usage",
    "currentValue": "0;0;0;0;0;51840",
    "defaultValue": ""
}

[buczo23]

Hello, any updates in the investigation? :-)

Wiadomość napisana przez Myles Gray notifications@github.com w dniu 10.02.2020, o godz. 12:20:

 So interestingly, I hooked up my phone to Charles again and issued the filter reset command on the BlueAir - it looks like the BlueAir itself communicates to the server and POSTs to an API, which tells the phone (via a push somehow) that the filter was changed. The API requests are entirely opaque to the proxy, so they are going out of band somehow - whether the BlueAir is communicating directly with the phone over LAN, I'm not sure.

Needs more investigation.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[mylesagray]

I’d need your API outputs from the above call to compare, I can’t really progress this investigation without some comparisons.

If you can run through the postman collection above and post the outputs, I can work on it.

[JeffGoldner]

Is this the same issue? (Blueair 480i). App shows correct value of 119 days remaining.

[7/11/2021, 12:28:27 PM] [homebridge-blueair] This plugin generated a warning from the characteristic 'Filter Life Level': characteristic value expected valid finite number and received "undefined" (undefined). See https://git.io/JtMGR for more info. [7/11/2021, 12:28:27 PM] [homebridge-blueair] Error: at FilterLifeLevel.Characteristic.characteristicWarning (/usr/local/lib/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:2038:105) at FilterLifeLevel.Characteristic.validateUserInput (/usr/local/lib/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:1931:16) at /usr/local/lib/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:1533:24 at /usr/local/lib/node_modules/homebridge/node_modules/hap-nodejs/src/lib/util/once.ts:9:18 at BlueAir. (/homebridge/node_modules/homebridge-blueair/index.js:959:6) at BlueAir.getBlueAirInfo (/homebridge/node_modules/homebridge-blueair/index.js:475:8) at BlueAir.getFilterLife (/homebridge/node_modules/homebridge-blueair/index.js:958:10) at FilterLifeLevel.emit (events.js:375:28) at /usr/local/lib/node_modules/homebridge/node_modules/hap-nodejs/src/lib/Characteristic.ts:1508:14 at new Promise ()