Refactor Ventura #12

silverailscolo · 2025-09-24T11:54:26Z

Fresh PR on master, replaces #4

For dynamic model support:

Refactor existing models, init, node
In BRDG add 3 methods te get models() info ~~fields to bridge_data~~
Add VMD-base, vmd_07rps13 (Ventura)
Remove const ProductId enum, replaced by per model product_id()

Add const OffOnMode, U8Register, used in Ventura

For CLI to work:

move model print_status() to model files, VMD-base
parse entered values from str to int (example: "do_set_co2 800")

Left out the Access Flag to IntEnum change

scabrero

Awesome work! I really like the dynamic loading of supported models and the idea of passing this info to the home-assistant integration.

src/pyairios/node.py

scabrero · 2025-09-25T21:22:20Z

src/pyairios/models/brdg_02r13.py

        return f"BRDG-02R13@{self.slave_id}"
+        # node method doesn't work for Bridge module in CLI (contains the path too)
+
+    async def load_models(self) -> int:


This is a "library" functionality not related bridge device. There are other bridge models like BRDG-02EM23 which is Ethernet instead of RS485. I would move supported models loading to class Airios

From general structure I can follow that, but in particular the CLI has no way to access the Airios class. So collecting this info would cause quite a lot of code duplication.
When a second bridge model will be added, it seems better to add the models loading to a "bridge-base" module that all bridges are based on.
I did change the HA components access to the model info by calling the Airios api directly and added methods to get this info (from the bridge, for now).
If you can suggest a way to get the supported models to the CLI I will use that (the info is still in BridgeData and that should not be necessary)...

Added bridge_base.py, and by doing so the CLI can access the models info for print status report (only).
This is mainly a service to the user, as the CLI bind is done by entering the product_id by hand (it doesn't need the models info for that, but I was looking in a lot of places to collect that number, convert it to dec etc. Hence the printout. Common bridge info is also in the bridge_base, as is the whole glob.glob to collect models from disk). Looks better, isn't it?

scabrero · 2025-09-25T21:38:23Z

src/pyairios/__init__.py

+        prids = brdg_data["product_ids"]
+        if prids is not None and brdg_data["models"] is not None:
+            for _node in await self.bridge.nodes():
+                for key, _id in prids.items():


This needs to be reversed. Instead of iterating the supported models first, iterate the bound nodes and then check if it is supported or not (iterating prids). The reason is that you can have several physical machines bound, all of them with the same product id but with its own virtual modbus device on the bridge.

If reversed, it means awaiting every loop. As is, we await just once, and fetch a matching model (might be the same as in previous loop): same result

scabrero · 2025-09-25T21:41:39Z

src/pyairios/models/vmn_05lm02.py


-class VMN05LM02(AiriosDevice):
-    """Represents a VMN-05LM02 remote node."""
+class NodeData(AiriosDeviceData):


Suggested change

class NodeData(AiriosDeviceData):

class VMN05LM02Data(AiriosDeviceData):

The name NodeData kind of break the hierarchy:

Node --> Device --> VMN05LM02

Changed it to DeviceData to align.
This class is really just data for the Module called VMN_05LM02. Having to write (almost) the same string twice invites for hard to spot errors once we get 10+ models, was my reasoning.

scabrero · 2025-09-25T21:52:13Z

src/pyairios/models/vmn_05lm02.py

+    return "Siber 4 button Remote"
+
+
+class Node(AiriosDevice):


I don't like having the same class name in different files. I guess it is to have a common entry point to instantiate without knowing the final class name.

I think we need to implement a factory pattern, E.g. https://medium.com/@amirm.lavasani/design-patterns-in-python-factory-method-1882d9a06cb4

Each supported model file could have a static variable "factory":
factory = VMN05LM02Factory()

And then in do_node() do node_module = brdg_data["models"][key].factory.create_node()

Good idea with implementation, thanks. Haven't built the (abstract_)factory yet.

scabrero · 2025-09-25T21:54:06Z

src/pyairios/models/vmn_05lm02.py

        result = await self.client.get_register(regdesc, self.slave_id)
        return Result(VMDRequestedVentilationSpeed(result.value), result.status)

-    async def fetch_vmn_data(self) -> VMN05LM02Data:  # pylint: disable=duplicate-code


I would keep VMN05LM02Dta.

See above. Even naming fetch_vmn_data() vs fetch_vmd_data() might become an unnecessary source of confusion/errors in the long run. Wouldn't fetch_device_data() do the trick?

src/pyairios/registers.py

Pair-Programmed-With: Egbert Broerse <dcc2@ebroerse.nl> Signed-off-by: Samuel Cabrero <scabrero@orica.es>

silverailscolo · 2025-10-02T20:21:59Z

Fixed call of supported models in __init__ for HA integration

… tweak vmd_base default for cli)

silverailscolo added 12 commits September 24, 2025 13:37

refactor models, init, BRDG, add VMD-base, const OffOnMode, U8Register

c338f29

fix registers, no shadowing, CLI entry to int

94befdb

refactor CLI

d50d939

Ventura RegisterAccess like existing models

9249c0b

lint line too long

7f64cf8

assert mod not None

8f65e39

productId is int

3b95a08

VMDPresetFansSpeeds field default

d15b99a

unnec. comprehension

a5b9c73

BRDG None raises Ex

cbc4a76

more BRDG None checks

924811d

even more None checks

1568da5

silverailscolo mentioned this pull request Sep 24, 2025

Refactor, add Ventura support #4

Closed

12 tasks

scabrero requested changes Sep 25, 2025

View reviewed changes

silverailscolo and others added 7 commits September 30, 2025 22:08

fix supply_temp register

dbca4f2

Add U8Register, clamp to UINT8 range

e518c3a

Pair-Programmed-With: Egbert Broerse <dcc2@ebroerse.nl> Signed-off-by: Samuel Cabrero <scabrero@orica.es>

Clamp register value to datatype range on writes

055aa1c

Pair-Programmed-With: Egbert Broerse <dcc2@ebroerse.nl> Signed-off-by: Samuel Cabrero <scabrero@orica.es>

Add U8Register, clamp to UINT8 range

c77655f

Pair-Programmed-With: Egbert Broerse <dcc2@ebroerse.nl> Signed-off-by: Samuel Cabrero <scabrero@orica.es>

apply comments

8f85f79

add 3 util methods

1ffa5e2

api access to airios_models etc

d932856

silverailscolo added 5 commits October 3, 2025 11:33

create brdg_base.py, move models function there from brdg_02r13 (must…

c1328d1

… tweak vmd_base default for cli)

brdg_base print to cli

a24bb94

init without brdg_data[models] etc

a8a09ec

remove brdg_data[models] etc, fix AiriosData

f58a0cc

tweak init.fetch AiriosData type

0701045

	class NodeData(AiriosDeviceData):
	class VMN05LM02Data(AiriosDeviceData):

Refactor Ventura #12

Are you sure you want to change the base?

Refactor Ventura #12

Uh oh!

Conversation

silverailscolo commented Sep 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

scabrero left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

silverailscolo Oct 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

silverailscolo commented Oct 2, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

silverailscolo commented Sep 24, 2025 •

edited

Loading

silverailscolo Oct 1, 2025 •

edited

Loading