service.call() is not generated in pyscript_builtins.py

[ryan-fessler]

The function service.call() is not generated in pyscript_builtins.py.

This likely conflicts with the @service decorator, so I'm not sure how it would be handled.

There are some cases where I need to use service.call() instead of calling the service directly with domain.name(). For instance, I can't call light.turn_on() with transition set to a float because it expects an int, so I need to use service.call() instead.

[ALERTua]

@dmamelin your part of the code :) thank you <3

[dmamelin]

You’re right, service.call() isn’t included in pyscript_builtins.py due to a conflict with @service.

For instance, I can't call light.turn_on() with transition set to a float because it expects an int

selector:
  number:
    min: 0
    max: 300
    unit_of_measurement: seconds

transition in light.turn_on() is documented as an int. The UI also treats it as an integer and throws an error if you try to enter a non-integer value.
But in reality, you can pass a float — the service will accept and process it correctly.

[ryan-fessler]

@dmamelin That's understandable about the conflict with @service. I will just specify service.call() as a builtin through Ruff.

For light.turn_on(), transition is definitely documented as an int in seconds — no argument there. That being said, I can pass a float to it (e.g., 0.2) and it will work correctly with my Philips Hue lights connected through zigbee2mqtt. I don't think there's anything that needs to be fixed there. I was just highlighting why I'm using service.call() instead of light.turn_on().

[RussEaton]

I resolved this by having two distinct imports, service_module and service_decorator, then you just import whichever you need as "service". If you need both in a file just re-import as required. As one type is already implemented the non-decorator could be added in this or a similar way, although it might be more consistent to duplicate the decorator under a corresponding name too.