Added support for components/BLU devices

[DarkStarDS9]

I don't know if this functionality is actually wanted or you would implement it that way, so feel free to flat out reject it 😉

I recently added two BLU H&T Sensors to my setup and found the documentation to be quite... thin. Documentation says "every pro device can act as a gateway" - for the cloud. If you want to use BLU devices locally, it seems you need to add them as a component as well. I am assuming that all pro devices support components, so I wanted to keep this as encapsulated as possible to only require minimal changes when adding component-support to other exporters.

Anyhow... this implementation works:

And it also has a test with an example-json that shows how components look like on my pro-4pm.

Oh, and this too was done with AI support - this time GitHub CoPilot using Claude Sonnet 4 and quite a lot of guidance.

[lukassoo]

I will have a look in up to a few of days.

Currently busy with a new PCB design and testing.

If it is what I think it is, I actually had the idea of using the component approach with newer generation devices.

In the end I didn't do it since it would take some time, Gen1 devices don't support it, and the current approach is easy enough to copy->adapt most of the time to any device as long as it has a Http or Web socket endpoint.

A component approach could in theory allow for very simple per-device projects and probably even generating exporters for all devices based on the docs.

Once I have some free time I'll have a look to see 🙂

[lukassoo]

I have not forgotten about this 😄
Work took a bit longer than expected.

I had a look at the code a couple of days ago and got the main idea behind it.

I will most likely use it as a reference when I get around to implementing this.
Currently working on improving metric naming and using labels in #18.

Once that is done, and I have some time, I will try to make an exporter for the BLU H&T.
I will need help with testing since I don't have it.

I would like to keep the exporters and metrics device-specific and correctly named.

So instead of:

shellyPro4Pm_my_device_component{device_name="Keller",sensor_name="Temperature"} 20.2
shellyPro4Pm_my_device_component{device_name="Keller",sensor_name="Humidity"} 73
shellyPro4Pm_my_device_component{device_name="Keller",sensor_name="Battery"} 100

I would think of (including the mentioned correct naming and labels):

shelly_temperature_celsius{targetName="Keller",deviceModel="BluHT"} 20.2 
shelly_humidity{targetName="Keller",deviceModel="BluHT"} 73 
shelly_battery_level{targetName="Keller",deviceModel="BluHT"} 100

I may or may not go with the component approach, or go about it a bit differently.
It will probably only be a collection of classes for handling specific components that any exporter can use.
Similar to how the HTTP and WebSocket handlers are used as needed.
This will probably reduce the amount of code needed to be written in the <Device>Connection.cs files.
Writing new exporters should be faster and easier, since it will probably end up being a few lines of code to attach selected components to the correct request handler.