• 0 Posts
  • 46 Comments
Joined 1 year ago
cake
Cake day: June 14th, 2023

help-circle







  • It comes down to what are the developers willing or able to support.

    For smaller teams they usually don’t want the responsibility of maintaining the package for distros, and HA developers have chosen to not support that option themselves. In their case I see it - what’s the benefit or incentive to them to maintain packages and the associated support costs or headaches. Containers mean they get a known state and don’t have to try to support unknown environments.

    Some interested people can maintain the packages for their chosen distro - for instance I see one for Gentoo but it’s only up to 2024.6. It’s the first that came up in a search but there are likely more too supported by the community.

    In my case, I also think that using HAOS on a dedicated box has led to a more stable experience as it’s not competing for resources on my other hosts, and attaching devices to it is much simpler. I think encouraging a solid base for people means a better experience overall when to be honest it’s hard to get started with it to begin with for many people.





  • All that yes. The Wooting One (original that uses IR light) let you use buttons to simulate controller axes, change how hard you need to press to activate, and add second functions to keys. It was an interesting idea but I found the gaming part the original keyboard to be only usable in a limited set of games as it’s not as sensitive as a controller stick, and as a keyboard it wasn’t great either. Hopefully V1 problems, I know they had through another version of the IR keyboard, and then came out with the Hall effect keyboard. I like the idea but never could get used to it, and when the spacebar was loose I retired it after fixing it.



  • Then to link the entities together into a device you need to mimic the auto discovery, or you just have two split entities.

    I suppose you could create a template entity with the battery as an attribute to see it in the details view, but you still need the entities with the raw data. I’d be more inclined to create the device with auto discovery, seems like a cleaner way to go.



  • Try searching for your automation.entity_id - like in my case it’s something like automation.notify_washer_done (the original entity id of my automation, found via the developer - states tab). Then if I search using that in my YAML I’d see entity_id: automation.notify_washer_done, and add the context to see the full service call:

    service: automation.turn_on
    target:
      entity_id: automation.notify_washer_done
    data: {}
    

    Assuming it’s an automation or script your should find it in the related .yaml file and can scroll up to see the actual automation or script source.


  • Turned off or Turned on is the disable or enable action. If it’s changed by something in HA it should show what the trigger was too (like a user or other automation).

    Here’s an example - it shows the automations that enabled our disabled this automation, and their trigger.

    To prevent the automation from being changed you can rename it, that should break anything automatic that’s changing it. You can also try to chase down what’s changing it from logs (once renamed you should start seeing errors in your HA log file), or by searching for the entity_id in your yaml configuration files.




  • I have actionable notifications with notify.notify service working so I’m not sure there - something sounds off.

    I don’t think there’s issues with long timeouts, but realize that they won’t persist through restarts of Home Assistant, and depending on your automation settings you can control the number of instances. To disconnect the action from the running automation I often add the event as another trigger to the automation and then add logic to handle the normal trigger and the notification trigger separately. No wait needed in the automation then, just fire the notification and another instance of the automation handles the action.