Design: Massive Device Model about powered-up HOT 3 CLOSED

Well, I'd say that for most trains, you could have one of the following setups:

1 hub + 1 train motor
1 hub + 1 train motor + 1 light
and additionally for some more advanced train mocs it could be:
1 hub + 2 train motors
2x (1 hub + 1 train motor)

I do agree that in most cases, one would not be very interested in the hubs at all. But for the case having 1 hub + 2 train motors, if they are attached to a standard train plate, the motors are most likely oriented opposed to one another due to cabling possibilities. This results in the 2 motors needing to run in opposing direction. In this specific scenario, I feel it might be useful to have perfect control over what each device does.

I do agree that for trains or otherwise larger installations it would make sense to have some layer on top of what is currently in this library, so that the powered up protocol & BLE is completely abstracted away. It would be rather nice to have some method to simply discover 'a train' and have some sensible way to control it.

I'm interested in what your thoughts are on the intentions/goals of this library. Personally I think it makes sense to keep this library as purely an implementation of the LWP and keep stuff that deals with managing of larger combined installations maybe in a seperate library and/or package?
Most important reasoning for me would be preventing an endless stream of discussions about if configuration 'x' (eg 1 technic hub + 1 l motor on port B + 1 xl motor on port C) should be represented as an entity. For example 'a train' could be rather straightforward, but are you going to create profiles/models for actual lego sets for example or for common scenario's/applications, hard to draw a line maybe about what and what not to include?

from powered-up.

To keep it close to the protocol and the devices and keeping the applications out is surely a goal. This is surely an onion architecture with the domain and - to some extend - service layer.

However doing Hub-Port-Device implementation is a very OO oriented way of representing the state of the LEGO model. One of the Python libraries was a attribute-mvc-alike mapping of incoming data. This library should not block something like that. Maybe, if relevant, also provide something like that. That is the reason, why the protocol interface is used everywhere and not a hub handed around (devices e.g. do not talk to the hub but the protocol).

So far, no one showed interest in different ways of doing (and most friends in the library space doing the OO stale of things).

from powered-up.

Closed as no precedence or interest in it.

from powered-up.