Python Stubs for openHAB Rules

Tags: #<Tag:0x00007fc8fd45eed0> #<Tag:0x00007fc8fd45edb8> #<Tag:0x00007fc8fd45ecf0>

I have managed to generate Python typing stubs for all of openHAB Core to making writing rules much easier.

No longer will you need to always work with the documentation open or have to dig around in the openHAB code to find methods of Java objects!

You can find them in this repo. Stubs for my fork of the Helper Libraries are available in that repo, more information can be found on Ivan’s Helper Libraries - OH3, Python, JavaScript

4 Likes

Hi @CrazyIvan359,
having more support while conding in Pyhton is really great - thanks a ton for that!

I have a problem though (maybe it’s more of an annoyance than a real problem):
I get coding tips from Pylance and pylint. These are redundant, as they are duplications, but I am ok with that:
image

When using a builtin though (ON, CLOSED, etc.), pylint is fine with that (which it should be, as in .pylint.rc, these additional builtins are defined), but I get a complaint fom Pylance:

Is there a way to configure the plugins, so that Pylance either knows about the builtins or that I can disable this kind of tips from Pylance? Or maybe even configure things in a way, that only one linter is used?

I tried to find out how Pylance and pylint work in conjunction (to me they seem to have overlapping functionality here), but did not really succeed in getting information that let me understand this.

Cheers,
Bastian

Hi Bastian,

Thank you for the positive feedback! It is nice to hear from a user on these, I’ve been waiting for some feedback to know if they are helpful or broken.

Side note to anyone reading: I know that the only stubs currently available are quite outdated, I assure you I will be adding more as soon as I can, but my time is limited and I have another project that must come first right now.

You are correct that Pylance and pylint overlap, though not 100%. If you want you can disable pylint, I do not suggest that in the instructions because a lot of OH users have limited to no knowledge of Python, so the more help the better to point out mistakes.

You should read through the Usage and Reference pages in the stubs repo, they contain some examples of ways to get the most out of the stubs. In particular for your problem with the “built-ins” (actually the contents of the defaultScope in the Script Engine) you should look here.

Hi @CrazyIvan359 . thanks for the explanation. With that input I got most of my rules now set up with the typing. At the moment I am trying to reduce messages from pylint/Pylance which are not needed, so they don’t distract from the real problems.

I can control messages like “‘items’ is not defined” with this import for the typechecking:

import typing as t
if t.TYPE_CHECKING:  # imports used only for type hints
    from core.jsr223.scope import items

However: Pylance tells me “Import ‘core.jsr223.scope’ could not be resolved” and I do not get suggestions for members of ìtems.
(With “no suggestions” I mean, there is no popup, showing me the possible attributes and methods when I type items..)

Is that expected behaviour?
If not, I will doublecheck my setup vs. the available documentation to hopefully find what’s going wrong.

1 Like

No, it is not expected behaviour. The items object is included in core.jsr223.scope.


First off, it sounds like you did not add the stubs from the Helper Libraries repo (they are packaged there so that you get a version matching the HLs you just downloaded).

This error tells me Pylance can’t find {OH_CONF}/typings/core/jsr223/scope/__init__.py where items is defined. Make sure you completed step 5 of the stubs installation. Also note the path above where Pylance is looking, if you copied the Core/typings folder into {OH_CONF}/typings you may have ended up with {OH_CONF}/typings/typings/core/jsr223/scope/__init__.py.


Second thing is more just an FYI in case you hadn’t already heard/discovered this: you can no longer reference Items as attributes of the items object in Python/Jython. This behaviour was added to mimic the DSL and JavaScript behaviour of being able to reference map/dictionary keys as if they are attributes of the map/dict. It was removed a few commits before I started maintaining the HLs because it was problematic.

If you are interested, items is actually an instance of org.openhab.core.automation.module.script.internal.defaultscope.ItemRegistryDelegate, which itself is just a Map<String, State> of Item states, so don’t expect too many methods there.