Open SPF79 opened 1 week ago
- (EDIT: I just realised, that this probably only counts for rule instantiation, not imports. Therefore omittable, whereas confirmation would be appreciated). Apart from that, relative/absolute imports don't work as expected and throw PyCharm off the rails ("from lib.xyz import blah" -> error@runtime).
You can have the class definition there but not the class instantiation. The class instantiation has to happen in a rule file.
It then works like any normal 3rd party package. To make it in PyCharm work you just have to add the library folder as an additional source folder. Then you import from lib_a import xyz
.
2. When I go by get_rule(), I can't get the typed class to be looked-up/instantiated. I work with static variables in stub classes to achieve productive code-completion and I would never want to change my style here.
get_rule()
returns the already created rule instance. I've provided an example how to make it work with type hints.
What do you suggest?
From skimming over your code it seems you mainly want to interact with each device through hsb, on/off, level and color-temp values. I still think the it's easiest when you create four HABApp internal items per device and a rule per device which listens to a command event (you can reuse the openHAB ItemCommandEvent) on the items and then publishes to mqtt accordingly. On device update from mqtt it updates all four items. Grouping then becomes a matter of grouping the items and sending the events accordingly which is easy. The rule is basically a driver and the items represent the (most used) device state.
For more exotic use cases you can still use the get_rule()
and call functions on the rule directly.
4. If I instantiate one in Item.listen_event(), it wants the event argument, but it should be optional.
For me it's fine without issues:
Alright then, I'll give it another shot and value the time you took with devotion.
At the same time, these were just demonstrating excerpts, since as I mentioned before, I hitch-hike Milight to control e.g. my awning relays. They have such nice out-of-the-box useful (handheld as well as wall-mounted) remotes (EDIT: Milight that is) to signal my hubs for MQTT-messages to OH. So please don't think that lighting is the only application. That's exactly why I want libraries to feed my implementations (and I don't use OH items as relays to bridge whatsoever, since that is just to slow, but only to keep track of the states - EDIT3: or at least that was a train of thought in between years ago, I dunno any more, but this code-base works sufficiently).
I know, that this is sort of rogue and not as intended. But well, in my sector you have to get creative to keep costs below par.
Cheers for the prompt reply and will keep you in the loop, mate!
EDIT2: And for me it doesn't:
Hey mate,
alright, I did my research on the approaches to clean libraries you mentioned here Yet, they don't provide any solution to my code. Reiterating...
Requirements
Description of the issue(s)
Example code
to be put in a library file
to be put in an implementation/configuration file
What do you suggest?