Using classes and inheritance cause problems with lingering triggers

[carlolars]

So I tried to be clever and structure my code into classes. It works, kind of.
My use case is I have a few ZigBee devices of the same type in different rooms for which I wait for events and then do stuff.

I created a base class for the zha event, then classes for different devices that inherit from the base class, and then I created instanses of the classes in several script files (pyscript/scripts/).

The base class creates a list of triggers that is attached to self, so I expected those triggers to be destroyed when the reference to the class instance is lost, ie when reloading the script that creates the class instance and has the reference to it.
But that is not happening, instead every time I reload the script it just adds more triggers without destroying the previous ones. I have to reload the file that contains the definition of the base class for the triggers to be destroyed.

But if I don't have a reference to the instance (remove ws_hallway below) then nothing happens when I push the switch which I assume is because the triggers have been destroyed when the instance was not referenced anymore.

What am I missing here?

---

This is basically how I implemented it:

pyscript/modules/zha.py:

class ZhaEventBase:
    def __init__(self):
        # Cannot use `super().__init__()` so use `zha_event_base()` instead
        pass

    def zha_event_base(self,
                 device_id:str,
                 command_callbacks:dict):
        """
        `command_callbacks` is a flat dictonary with `"command": callback`.
        """
        self.triggers = []

        for command, callback in command_callbacks.items():
            if callback is not None:
                log.debug(f"Registering command '{command}'")
                @event_trigger("zha_event", f"device_id == '{device_id}' and command == '{command}'")
                def zha_event_callback(device_id=None, command=None, args=None, **kwargs):
                    callback(device_id, command, args)

                self.triggers.append(zha_event_callback)

pyscript/modules/philips_hue.py:

from zha import ZhaEventBase

class WallSwitch(ZhaEventBase):
    def __init__(self,
        device_id:str,
        command_callbacks:dict):
        self.zha_event_base(device_id, command_callbacks, debug)

pyscript/scripts/hallway.py:

from philips_hue import WallSwitch

def wall_switch_toggle(device_id, command, args):
    log.debug(f"wall_switch_toggle, {command=}")

ws_hallway = WallSwitch("123456778888888888",
           {
            "left_press_release": wall_switch_toggle,
           })

[DerekLamberti]

Just to add my 2 cents because I've tripped over this recently so I can confirm this still happens.

The issue as far as I can tell is with how destructors work....or rather don't work. In a basic class you can add @pyscript_compile decorators to the destructor (and explicitly call del , however for classes with inheritence, this trick still doesn't work. Even constructors dont work in this instance.

My suggestion is to avoid calling the constructor in the global scope of the module. This is because it will be called when the module is loaded which can lead to issues depending on load order wrt entites. Instead, construct the objects in a startup function.

@time_trigger("startup")
def on_startup():
    global ws_hallway
    ws_hallway = WallSwitch("123456778888888888",
           {
            "left_press_release": wall_switch_toggle,
           })

Then similarly have a on_shutdown trigger function that explicitly calls a clear() function on the class that clears the triggers.

For some or other reason, the derrived dtor will never call into a base class function....or at least I couldn't get it to work without @pyscript_compile. Seems Pyscript is missing too much class functionality here including super(). It's concerning that it doesn't fail in any obvious way. The code is just never run. The unfortunate consequence of using @pyscript_compile is that native HA functionality doesn't work in those functions....such as logging, which also makes debugging this tricky.