When are components useful to submit to Home Assistant?

Development
1

I was going through the logs of my hass install and I noticed lines like below:

You are using a custom component for media_player.yamaha_ynca which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you do experience issues with Home Assistant.

So indeed I have a few custom components and I was wondering if I should submit those to be included with Hass. I did not do this in the beginning because I was learning python and basically just porting my old scripts to Hass. But these components have been working for me for a long time now and the for the media_player.yamaha_ynca component got pretty good (I think) and I could probably fix it up a bit more to meet the Hass standards.

I find it hard to decide if my custom components would be useful for other people and I could not find guidelines on this.

FYI I have the following custom components:

  • media_player.yamaha_ynca
    This is a mediaplayer component for Yamaha receivers that support the YNCA protocol (this is a serial port protocol)
  • cover.rpi_gpio_pulse
    This is a cover component for my projector screen. The existing cover.rpi_gpio component seems to be geared to a garage door opener which did not fit my needs. I am basically pressing the buttons of my remote control with the RPi so I “press” the button with an IO line for a few 100ms and release it again (hence the pulse in the name).
  • binary_sensor.rpi_gpio_poll
    This is basically a copy of binary_sensor.rpi_gpio but instead just polls the state of the specified input pins every second instead of using the events. I never got the events version working reliably it would regularly end up in the wrong state and was very hard to get it in sync again. So I made the polling variant since that is what my old script used to do and that never failed me. It could be that there is some bouncing on the electronics side causing this issue but not sure how to measure/fix it (I tried the debounce settings on RPi gpio).

Hmm, after writing this down I guess the most useful would be the media_player.yamaha_ynca component. But does Hass need yet another Yamaha component?
There are already 2 available. Especially one that only work on Serial ports, so only for older models (mine is from 2011 I think)

Edit: here is link GitHub - mvdwetering/custom_components: Custom components for Home Assistant

2

I’m sure many people would be interested in the GPIO polling component going on the number of topics started about this problem and that the github issue is getting no response.

3

Try posting them separately in Share your projects. If enough people show some interest, then it will be worth adding them to the official code - either as new components or merging them into existing ones with new parameters.

4

I’m sorry if I misunderstood, but what does your implementation offers that cover.rpi_gpio does not? It already has relay_time, the time that the relay will be on for in seconds.

5

gpbenton
Posting Share your Projects sounds actually like a good idea, thanks for the suggestion.

tielemans.jorim
Indeed it does have a relay_time that should fit my purpose.
However looking at it again now, I remember some other issues that were there as well.

In my case I am actually pressing the UP and DOWN buttons on a RF remote, so I need separate pins to press the UP button or the DOWN button (so 2 pins for activation, 3 if I would also control the STOP button).
The rpi_gpio.cover component works differently. It only uses 1 pin which is for open and closing. So pin active==open, pin inactive==closed (or the other way around).
There seems no easy/nonbreaking way to implement both ways for control.

And another issue is that you must provide a state_pin which I cannot do because I have no feedback.
If I would just provide a dummy pin it means that effectively the state of the rpi_gpio.cover is always stuck in 1 state (open or closed). Which in turn also disables that button in the UI so that is also not useable.
This might actually be fixable by having no internal state when state_pin is not provided.

FYI I added a link to my custom_components in the first post

1 Like