Start/stop instance in Home Assistant

With such a Controller maybe...
€ 2,76 30%OFF | Magie Hause DC5V 12V 24V Bluetooth Wireless WiFi Controller,RGB/RGBW IR RF LED Controller für 5050 WS2811 WS2812B Pixel led streifen
https://a.aliexpress.com/_BOOEKo

You

Zitat von sp3cialck

Anybody knows if there's a way to Start/Stop an Hyperion instance using home assistant? I'd like to make an automation which should activate the instance to sync with the selected lights!
Thx

might want to have a look here, specifically the WebServer and JSON requests part :
https://docs.hyperion-project.org/en/json/#http-s-json

I maintain the Hyperion home assistant component.

I think it should be possible to implement this in the stock component, e.g. a Hyperion instance creates a light and a switch. Turning the switch off disables the instance, or something like that.

I'd like to learn more about the usecase though -- why is simply turning the light on/off not sufficient for the described behavior?

Here's one example of calling the Hyperion (NG) JSON API through Home Assistant and toggle Hyperion completely. You should be able to automate just about everything. Can also be rewritten to use curl.

switch:
  - platform: command_line
    switches:
      hyperion:
        command_on: "echo '{\"command\":\"componentstate\",\"componentstate\":{\"component\":\"ALL\",\"state\":true}}' | nc {IP_OF_HYPERION} 19444"
        command_off: "echo '{\"command\":\"componentstate\",\"componentstate\":{\"component\":\"ALL\",\"state\":false}}' | nc {IP_OF_HYPERION} 19444"

I actually use WLED (since I use that for the LEDs) integration to stop receiving a signal (+ a Power Plug Switch to disable the source).

@Puck -- but why not just use the Home Assistant Hyperion integration? Turning the light on/off with that integration turns the LEDDEVICE component on/off, which should have an end effect quite like the one you described (except without needing to send JSON via the command line.

This was literally just an example :). I don't need any automations for Hyperion myself (anymore) and didn't know about the official integrations. Seems like the way to go indeed if you need to control it from HA

Thanks @Puck!

@sp3cialck -- curious for your thoughts, and whether or not there's a usecase for the native Home Assistant component supporting start/stopping an instance. Thanks!

Hello @Dermot Duffy
I'm using Hyperion on a Pi Zero and the CPU load is obviously high while Hyperion runs. When I turn only the LEDs off the load stays high but if I click on the "Deactivate Instance" button in the Hyperion UI the load decreases.
Therefore it would be better if the Home Assistant "off switch" deaktivates the whole instance instead of just turning the LEDs of. This should reduce the temperature of the Pi (Running 24/7 at 90% load versus running a couple of hours) and also improve power consumption. If it's a quick change if would definitely prefer to deactivate the LED instance instead of just turning it off.

Hi @CalvinS ,

Thanks for the idea. I fear that is not at all easy to implement. When an instance is stopped, the Hyperion API no longer reports any state about it. Home Assistant relies on this state (so it can know if the light is on/off/brightness/color/effect). In fact, when an instance is stopped, the current version of Home Assistant will actually remove the entity entirely because of this (and add it back when the instance is re-enabled).

What you describe is definitely not impossible, just quite difficult, so unless it was heavily sought after by others it may not get done. It might be good to open a bug against Hyperion itself (https://github.com/hyperion-project/hyperion.ng) as a simpler fix might be for Hyperion to not do whatever processing it is doing when the output is disabled (but keep the API available).

Zitat von CalvinS

Hello @Dermot Duffy
I'm using Hyperion on a Pi Zero and the CPU load is obviously high while Hyperion runs. When I turn only the LEDs off the load stays high but if I click on the "Deactivate Instance" button in the Hyperion UI the load decreases.
Therefore it would be better if the Home Assistant "off switch" deaktivates the whole instance instead of just turning the LEDs of. This should reduce the temperature of the Pi (Running 24/7 at 90% load versus running a couple of hours) and also improve power consumption. If it's a quick change if would definitely prefer to deactivate the LED instance instead of just turning it off.

For this you can use the direct API command switch I posted above Start/stop instance in Home Assistant

Zitat von Dermot Duffy

When an instance is stopped, the Hyperion API no longer reports any state about it.

I don't think this is true
I'm not currently using the default integration (but would love to) and I'm using

curl -sS -X POST -H 'Content-Type:application/json' -H 'Accept:application/json' -d '{"command": "serverinfo"}' http://192.168.3.244:8090/json-rpc | jq '.info.components[] | select(.name == "ALL") | .enabled' | grep -q 'true'

To get the status of hyperion.

It works even if hyperion had "component: ALL" set to false, which shuts down the capture and is equivalent to "Disable instance" in UI, afaik

EDIT: The integration seems fine when manually changing the component: ALL, btw.
IMO, all it takes is

diff --git a/homeassistant/components/hyperion/light.py b/homeassistant/components/hyperion/light.py
index e2989cb973..3d42e6db4c 100644
--- a/homeassistant/components/hyperion/light.py
+++ b/homeassistant/components/hyperion/light.py
@@ -487,11 +487,11 @@ class HyperionLight(LightEntity):
  async def async_turn_off(self, **kwargs: Any) -> None:
  """Disable the LED output component."""
  if not await self._client.async_send_set_component(
  **{
  const.KEY_COMPONENTSTATE: {
-  const.KEY_COMPONENT: const.KEY_COMPONENTID_LEDDEVICE,
+  const.KEY_COMPONENT: const.KEY_COMPONENTID_ALL,
  const.KEY_STATE: False,
  }
  }
  ):
  return

EDIT2: Yep, works fine, afaict

Done: https://github.com/home-assistant/core/pull/44390

That being said, I agree with Dermott that there is room for fine-tuning in Hyperion itself.
I don't see a use-case for having the grabbers running when output is off, or if a lower-priority source is active, so in those case the grabbers could be paused, to save resources.

But I might miss something.