feature: verify device mapping using manufacturer query api

[beesaferoot]

IManufacturerDeviceInfo interface is added to compose a Manufacturer class with device info retrieval logic

Brief summary of the change made

Are there any other side effects of this change that we should be aware of?

Describe how you tested your changes?

Pull Request checklist

Please confirm you have completed any of the necessary steps below.

• Meaningful Pull Request title and description
• Changes tested as described above
• Added appropriate documentation for the change.
• Created GitHub issues for any relevant followup/future enhancements if appropriate.

[dmohns]

I'm not sure I like the UX here (or, I don't understand fully understand the use case). Right now, we are simply adding a button. It's not really clear to me, under which circumstances a user would ever click that.

What I can imagine is we are looking for some way to confirm we can actually control a given device from MPM. But if this is the case I would consider a different approach:

• On the device model we could add two fields liked mapped_with_manufacturer_api (or similar) and last_checked. - We could then nicely add these information to a Device Detail overview. Also, Device Overview and search filter + export
• When new devices are added, we immediately run the check.
• On Device Details view, the button you added would run the check as above.

In terms of API design another questions... We have a couple of feature requests regarding ad-hoc device management, for example

• [Feature Request]: Manual maintenance for individual SHS via Tokens #490
• [Feature Request]: Sending on/off commands to a given Calinmeter #743

I imagine there will be some overlap with the work you are doing here. Have you considered if there will be some synergy between the two works streams?

[beesaferoot]

I'm not sure I like the UX here (or, I don't understand fully understand the use case). Right now, we are simply adding a button. It's not really clear to me, under which circumstances a user would ever click that.

What I can imagine is we are looking for some way to confirm we can actually control a given device from MPM. But if this is the case I would consider a different approach:

• On the device model we could add two fields liked mapped_with_manufacturer_api (or similar) and last_checked. - We could then nicely add these information to a Device Detail overview. Also, Device Overview and search filter + export
• When new devices are added, we immediately run the check.
• On Device Details view, the button you added would run the check as above.

In terms of API design another questions... We have a couple of feature requests regarding ad-hoc device management, for example

• [Feature Request]: Manual maintenance for individual SHS via Tokens #490
• [Feature Request]: Sending on/off commands to a given Calinmeter #743

I imagine there will be some overlap with the work you are doing here. Have you considered if there will be some synergy between the two works streams?

You make good points; I will be looking further into it with your feedbacks. Thanks

[dmohns]

This look very good 👍 Only slight concern I have is about naming

• There is some in consistency, sometime you are referring to it as ManufacturerMapping sometimes as DeviceMapping. Could we decide on on terminology and stick with it?
• I personally find the word "mapping" not specific enough, it's more of an implementation detail than descriptive (i.e. some manufacturer say a device is mapped to an API key but other manufacturer might totally avoid this naming). I'm not really sure what would be better 🫣 Sometime along the lines of device management? Or Remote device management? Any ideas?

[beesaferoot]

This look very good 👍 Only slight concern I have is about naming

• There is some in consistency, sometime you are referring to it as ManufacturerMapping sometimes as DeviceMapping. Could we decide on on terminology and stick with it?
• I personally find the word "mapping" not specific enough, it's more of an implementation detail than descriptive (i.e. some manufacturer say a device is mapped to an API key but other manufacturer might totally avoid this naming). I'm not really sure what would be better 🫣 Sometime along the lines of device management? Or Remote device management? Any ideas?

Device mapping here only represents the verification on the manufacturer level. Device Management was the intended name for the abstraction that includes work from #490, #743 but left it at mapping on this PR.

I could make it uniform by using "Device management" for the section header already.

[dmohns]

Device mapping here only represents the verification on the manufacturer level. Device Management was the intended name for the abstraction that includes work from #490, #743 but left it at mapping on this PR.

I could make it uniform by using "Device management" for the section header already.

Yeah, I understand what you mean with "Device Management" and it makes sense. This can be expanded later.

My point is, what we are currently calling "mapping" is really checking if we have permissions to call the management API (or remote management permission). Mapping generally refers to combine or link to entities, which doesn't make sense from our point of view (It does make sense from the manufacturer point of view, they are mapping an API key to a device, which gives it permissions).

But maybe I'm being way too nit-picky here 🫣

[beesaferoot]

Device mapping here only represents the verification on the manufacturer level. Device Management was the intended name for the abstraction that includes work from #490, #743 but left it at mapping on this PR.
I could make it uniform by using "Device management" for the section header already.

Yeah, I understand what you mean with "Device Management" and it makes sense. This can be expanded later.

My point is, what we are currently calling "mapping" is really checking if we have permissions to call the management API (or remote management permission). Mapping generally refers to combine or link to entities, which doesn't make sense from our point of view (It does make sense from the manufacturer point of view, they are mapping an API key to a device, which gives it permissions).

But maybe I'm being way too nit-picky here 🫣

For me Mapping here simply implies that the device unit exists on the Manufacturer platform which then allows for operations on that unit i.e unlocking, credit unit, device control etc.

It doesn't care about the means that we verify this on the manufacturer side. If the unit gets removed on the Manufacturer side, then we can correctly flag this as such using the button.

We can go with this for now and refactor to a better name if a better suggestion surfaces.