InsightsManager not working for HP2016 or HP2019

[skogsaas]

Issue

It is not possible to retrieve Insights log entries for HP16 or HP19 while using the AthomCloudApi.

Example

The following example code works when running against a HP23. But when running against a HP16 or HP19, it returns log_not_found.

const devices = await homey.insights.getDevices();
const insight = devices['some device id'].insights[0];
const entries = await homey.insights.getLogEntries({ id: insight.id, uri: insight.uri, resolution: 'today' });

When running on a HP23 the insight object has the properties: id: homey:device:08e2fbfb-1578-467c-b0b5-b05f4050ab94:energy_power uri: homey:device:08e2fbfb-1578-467c-b0b5-b05f4050ab94

When running on a HP16 or HP19, the insight object has the properties: id: measure_ap_pm10 uri: homey:device:c16f0599-ff1b-4eb6-91dc-84cb603458ee

It would seem the issue is that HomeyAPIV2 has the following adapter code to make it work with the same interface as the HomeyAPIV3. The adapter ignores the uri parameter when targeting a HP16/HP19 and compiles it from the id. The problem is that the id is not as the adapter expects it to be. The adapter expects the id to be equal to the one from HP23, which is basically uri + id for HP16/HP19.

// HomeyAPIV2/ManagerInsights.js
async getLogEntries({ id, resolution }) {
    return this.__super__getLogEntries({
      id: id.split(':').reverse()[0],
      uri: id.split(':', 3).join(':'),
      resolution,
    });
  }

Workaround

A workaround until this is fixed is to detect if the id if from a HP23 or earlier.

const id = insight.id.startsWith('homey:') ? insight.id : insight.uri + ':' + insight.id;
const entries = await homey.insights.getLogEntries({ id:, uri: insight.uri, resolution: 'today' });

[jeroenwienk]

Issue

It is not possible to retrieve Insights log entries for HP16 or HP19 while using the AthomCloudApi.

Example

The following example code works when running against a HP23. But when running against a HP16 or HP19, it returns log_not_found.

const devices = await homey.insights.getDevices();
const insight = devices['some device id'].insights[0];
const entries = await homey.insights.getLogEntries({ id: insight.id, uri: insight.uri, resolution: 'today' });

When running on a HP23 the insight object has the properties: id: homey:device:08e2fbfb-1578-467c-b0b5-b05f4050ab94:energy_power uri: homey:device:08e2fbfb-1578-467c-b0b5-b05f4050ab94

When running on a HP16 or HP19, the insight object has the properties: id: measure_ap_pm10 uri: homey:device:c16f0599-ff1b-4eb6-91dc-84cb603458ee

It would seem the issue is that HomeyAPIV2 has the following adapter code to make it work with the same interface as the HomeyAPIV3. The adapter ignores the uri parameter when targeting a HP16/HP19 and compiles it from the id. The problem is that the id is not as the adapter expects it to be. The adapter expects the id to be equal to the one from HP23, which is basically uri + id for HP16/HP19.

// HomeyAPIV2/ManagerInsights.js
async getLogEntries({ id, resolution }) {
    return this.__super__getLogEntries({
      id: id.split(':').reverse()[0],
      uri: id.split(':', 3).join(':'),
      resolution,
    });
  }

Workaround

A workaround until this is fixed is to detect if the id if from a HP23 or earlier.

const id = insight.id.startsWith('homey:') ? insight.id : insight.uri + ':' + insight.id;
const entries = await homey.insights.getLogEntries({ id:, uri: insight.uri, resolution: 'today' });

The device.insights property will be removed in the future. You should use insights.getLogs and group them by device (log.ownerUri) and match them against the devices.

[skogsaas]

The api GET /api/manager/insights/log/ returns the same values for id and uri. So the issue should still be the same 🤔

[jeroenwienk]

The api GET /api/manager/insights/log/ returns the same values for id and uri. So the issue should still be the same 🤔

Which version are you using?

[skogsaas]

Tested with both 3.0.9 and 3.0.10. After I added the workaround, multiple users has reported it working ;)

[jeroenwienk]

Tested with both 3.0.9 and 3.0.10. After I added the workaround, multiple users has reported it working ;)

insights.getLogs() returns normal (with the transform) ids for 2019 for me can you share an example.

[skogsaas]

I haven't switched to use insights.getLogs() as suggested in your first comment yet, still using id and uri from device.insights. But I did originally do a request to compare result with GET /api/manager/insights/log/ on a HP16. Which responds with same id and uri as for devices.getDevices()[x].insights.

Could it be that id and uri is correct for insights.getLogs() on a HP19, but not on HP16?

[jeroenwienk]

I haven't switched to use insights.getLogs() as suggested in your first comment yet, still using id and uri from device.insights. But I did originally do a request to compare result with GET /api/manager/insights/log/ on a HP16. Which responds with same id and uri as for devices.getDevices()[x].insights.

Could it be that id and uri is correct for insights.getLogs() on a HP19, but not on HP16?

Well if you are doing the raw request it has the data without transforms ofcourse. homey-api's getLogs for 2019 returns the correct id. There is also a method on a device called device.getLogs() that returns the device logs. Like I said we will remove device.insights so we wont fix that.

[skogsaas]

Ah, of course! Didn't think/know about the transformation when reading data 🤦 I will refactor and use insights.getLogs() as suggested in first comment. Thank you for clearing this up!

On a sidenote, anywhere I can read about planned changes to the API, like removing device.insights ?

[jeroenwienk]

Ah, of course! Didn't think/know about the transformation when reading data 🤦 I will refactor and use insights.getLogs() as suggested in first comment. Thank you for clearing this up!

On a sidenote, anywhere I can read about planned changes to the API, like removing device.insights ?

No it's not documented.

[skogsaas]

Darn! 🙁

Please try to think of some way to have a public roadmap the community can snoop into. If you're using GitHub internally in Athom. Maybe make a public project as a roadmap or something?

No response needed, just think about it ;)