Adding APIRest queries to Gladys

[Terdious]

Hello @pierre-gilles,

Would it be possible to add requests to the Rest API:

• Retrieve the states of a feature from date to date. The goal would be to be able to retrieve data from a feature or a device once a day / week / month / year (example: energy consumed) and to be able to perform calculations in node red, the goal being to use the raw values and not the aggregations (in the same way as « /api/v1/device_feature/aggregated_states » but with all the values).
• A « PATCH » route to be able to modify device and device_feature data.
  Concrete example, a Philips Hue bulb has changed its device name (bulb modified from room), but the feature name has remained that of the old location

In image

Another example, today it is impossible to modify the unit in the MQTT service once the feature is created. This would allow it to be done^^

Thanks for your answer if it’s possible^^

[pierre-gilles]

@Terdious

Would it be possible to add requests to the REST API:

When you talk about the REST API, it’s the local API of Gladys, right? Not via Gladys Plus?

@Terdious

Retrieve the states of a feature from date to date.

Ok, that’s clear.

However, I don’t know where to put this request, because if we create a feature request, given the number of requests and the few developers, it will be done in 1 year / 2 years at best.

In Github it doesn’t necessarily make sense because it’s not a bug..

Since you are a long-time paying customer, I would like to do it as a priority (it’s only normal, those who support the project are prioritized), but there are other features requested by long-time paying customers that I also have pending… Well, I’ll think about it, I want to be fair with everyone ^^

Not easy to prioritize !!

@Terdious

A “PATCH” route to be able to modify device and device_feature data.

This route already exists, look at what happens in the browser when you edit a device

[Terdious]

@pierre-gilles

When you talk about the REST API, it’s the local API of Gladys, right? Not via Gladys Plus?

We are totally in agreement ^^ the goal is really to work locally on this subject, node-red is on a pi next door

@pierre-gilles

As you are a long-time paying customer, I would like to do it for you as a priority (it’s only fair, those who support the project are prioritized), then there are other features requested by long-time paying customers that I also have pending… Well, I’ll think about it, I want to be fair with everyone ^^

Not easy to prioritize!!

The offer is super nice, but no worries!! There are priorities, it will come when it comes ^^ After if it’s possible, I can look into it to do it, but I would just need the first tips if you have the possibility. Otherwise it will wait ^^

@pierre-gilles

This route already exists, look when you edit a device what happens in the browser

Oh my bad!! I’m too silly ^^
Thank youuuuu

[pierre-gilles]

@Terdious

The proposal is really nice, but no worries!! There are priorities, it will come when it comes ^^ After if it is possible, I can look into it to do it, but I would just need the first leads if you have the possibility. Otherwise it will wait ^^

At the limit create a feature request so that we have the request somewhere.

Otherwise if you want to look on your side, there are 4 places to look:

1. Create a function in lib/device → Gladys/server/lib/device at master · GladysAssistant/Gladys · GitHub

The function will take 3 parameters: deviceFeatureId, start, end (something like that)

2. Create a controller here to declare the API route: Gladys/server/api/controllers/device.controller.js at master · GladysAssistant/Gladys · GitHub

3. Create a test of the lib function here: Gladys/server/test/lib/device at master · GladysAssistant/Gladys · GitHub

4. Create a test for the controller here: Gladys/server/test/controllers/device/device.controller.test.js at master · GladysAssistant/Gladys · GitHub

Normally I think it can be done quickly!!

Do not hesitate if you have questions if you look, and otherwise I will look but I admit that I have a list of PR to review as long as my arm, same side Github issue, and the feature requests I do not even talk about…

[Terdious]

@pierre-gilles

At the limit, create a feature request so that we have the request somewhere.

Yes, let’s do that!!

@pierre-gilles

Otherwise, if you want to look into it, there are 4 places to check:

1. Create a function in lib/device → Gladys/server/lib/device at master · GladysAssistant/Gladys · GitHub

The function will take three parameters: deviceFeatureId, start, end (something like that)

2. Create a controller here to declare the API route: Gladys/device.controller.js at master · GladysAssistant/Gladys · GitHub
3. Create a test for the lib function here: Gladys/server/test/lib/device at master · GladysAssistant/Gladys · GitHub
4. Create a test for the controller here: Gladys/device.controller.test.js at master · GladysAssistant/Gladys · GitHub

Normally, I think this can be done quickly!!

I admit I started looking at your PR with the new request on aggregation… and it’s fine, I had pretty much unrolled it like that.

@pierre-gilles

Don’t hesitate if you have questions if you look into it, and otherwise I’ll look into it, but I admit I have a list of PRs to review as long as my arm, same on the GitHub issue side, and I won’t even talk about feature requests…

Héhé no worry ^^ Do what you have to do and I’ll see to it as soon as I’ve got my WSL and dev machine in order ^^

Thanks again for your time!!