[WIP] InfraredDevice as manual device

[J0EK3R]

It’s really annoying that every time you scan for devices, the four infrared devices are automatically added (if your smarphone supports ir).

I’ve moved them to the list of manual devices.

WDYT?

[vicocz]

It’s really annoying that every time you scan for devices, the four infrared devices are automatically added (if your smarphone supports ir).

I’ve moved them to the list of manual devices.

WDYT?

What if the phone / Windows does not support them? Adding something what is not supported looks weired.
How about adding some settings to disable IRDA (if it's supported) so as you can have it disabled if it annoys you?

[J0EK3R]

Adding something what is not supported looks weired.

Yes, of course — it’s still [WIP] 😉

My suggestion would be to hide this device on the manual‑selection page whenever IRDA isn’t supported.

I mainly wanted to get your opinion on the approach and see whether you’d consider merging it before I invest more time.

---

Right now it’s only a LEGO IRDA implementation.
As a manually selectable device, it could later be extended with additional IRDA protocol implementations.

I.e. I have two Prio trains that are controlled via IRDA.

[J0EK3R]

Now the IRDA devices are shown in the ManualDeviceListPage only if IInfraredService.IsInfraredSupported == true.

WDYT now? ;)

[vicocz]

Now the IRDA devices are shown in the ManualDeviceListPage only if IInfraredService.IsInfraredSupported == true.

WDYT now? ;)

Yeah, better, now, this is something acceptable now. Just smoke test it please, I gues have no phone capable of IRDA at the moment.

[Copilot]

Pull request overview

This PR stops Infrared (PF IR) “devices” from being auto-added during device scanning and instead exposes them as manually addable devices, while hiding them on platforms that don’t support IR.

Changes:

• Removed IR “scan” behavior so scanning only discovers Bluetooth devices.
• Introduced vendor/device-factory availability gating (IsAvailable) and filtered the manual-device list accordingly.
• Added an IR vendor module that registers PF IR devices as manual device factories.

Reviewed changes

Copilot reviewed 10 out of 10 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
BrickController2/BrickController2/UI/ViewModels/ManualDeviceListPageViewModel.cs	Filters manual device entries to only show available device factories.
BrickController2/BrickController2/DeviceManagement/Vendors/Vendor.cs	Adds a virtual IsAvailable flag to vendor modules.
BrickController2/BrickController2/DeviceManagement/InfraRedDevice/InfraRedDeviceVendor.cs	New vendor module that registers PF IR manual devices and an IR device manager.
BrickController2/BrickController2/DeviceManagement/InfraRedDevice/InfraredDeviceManager.cs	Moves IR manager into IR-specific namespace and removes scan-based discovery.
BrickController2/BrickController2/DeviceManagement/InfraRedDevice/InfraredDevice.cs	Makes IR device conform to IDeviceType<> for vendor-based registration.
BrickController2/BrickController2/DeviceManagement/InfraRedDevice/IInfraredDeviceManager.cs	Removes IDeviceScanner inheritance to reflect no scan support.
BrickController2/BrickController2/DeviceManagement/IDeviceFactoryData.cs	Adds IsAvailable so UI can filter manual device factories.
BrickController2/BrickController2/DeviceManagement/DI/DeviceManagementModule.cs	Removes direct IR registrations (now handled via vendor module scanning).
BrickController2/BrickController2/DeviceManagement/DeviceManager.cs	Drops IR scanning from the overall scan flow.
BrickController2/BrickController2/DeviceManagement/DeviceFactoryData.cs	Implements IsAvailable by delegating to the vendor.

Comments suppressed due to low confidence (1)

BrickController2/BrickController2/DeviceManagement/InfraRedDevice/InfraredDevice.cs:21

• TypeName is used as a user-facing label in the manual device list (e.g., "VendorName - DeviceTypeName"). "InfraredDevice" is inconsistent with other TypeName values (they include spaces) and will render poorly in the UI.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[J0EK3R]

The next step should be to give all type names more specific labels — something along the lines of “Lego Power Functions”.
If we introduce another device in the future that also uses IRDA, a generic name like “InfraredDevice” could lead to naming conflicts. Using more descriptive names now helps avoid such collisions later.

WDYT?

[vicocz]

The next step should be to give all type names more specific labels — something along the lines of “Lego Power Functions”. If we introduce another device in the future that also uses IRDA, a generic name like “InfraredDevice” could lead to naming conflicts. Using more descriptive names now helps avoid such collisions later.

WDYT?

I doubt any IRDA device are going to be yet used.
But you can try to rename it now.

[J0EK3R]

Usually you go (silently) to some of your goal step by step :)

Thank you for the flowers! 😉

Do you have any vendor in your mind?

Not really - the only toys I know that work with IRDA are the BRIO trains.

But my motto is “think big” and I’m a bit of a Monk 😉 — so once I touch that part of the code, I want to do it properly.

[J0EK3R]

In the code I noticed several places like this:

            if (Device.DeviceType != DeviceType.Infrared)
            {
                if (!await _deviceManager.IsBluetoothOnAsync())

and

            if (_devices.Any(d => d.DeviceType != DeviceType.Infrared) && !await _deviceManager.IsBluetoothOnAsync())
            {

Here the logic directly checks against DeviceType.Infrared.

My suggestion is to introduce the interfaces IBluetoothDevice and IIRDADevice to distinguish the communication technique instead of relying on explicit DeviceType comparisons.

I didn’t implement IIRDADevice because it wouldn’t be used at the moment — and I wanted to avoid your inevitable criticism. ;)

Then the code looks like this:

            if (Device is IBluetoothDevice)
            {
                if (!await _deviceManager.IsBluetoothOnAsync())

and

            if (_devices.Any(d => d is IBluetoothDevice) && !await _deviceManager.IsBluetoothOnAsync())
            {

[J0EK3R]

Now it looks like this: