Is it possible to use the timeout filter to activate an uart.write??
Something like this?
binary_sensor:
- platform: template
name: "Power"
icon: mdi:power
id: "power"
filters:
- timeout:
timeout: 30s
uart.write:
id: uart_onkyo
data: "!1PWRQSTN"
Not like that. You would need an on_timeout trigger.
There isn’t one for sensors or sensor filters. Only these:
- on_value (Optional, Automation): An automation to perform when a new value is published. See on_value.
- on_value_range (Optional, Automation): An automation to perform when a published value transition from outside to a range to inside. See on_value_range.
- on_raw_value (Optional, Automation): An automation to perform when a raw value is received that hasn’t passed through any filters. See on_raw_value.
However, when timed out the value changes to NaN
So use an on_value trigger, with a lambda condition:
binary_sensor:
- platform: template
name: "Power"
icon: mdi:power
id: "power"
filters:
- timeout:
timeout: 30s
uart.write:
on_value:
then:
- if:
condition:
lambda: |-
return id(power).state = NaN;
then:
uart.write:
id: uart_onkyo
data: "!1PWRQSTN"
Untested.
You may be able to replace return id(power).state with just x.
NaN my need quotes but I don’t think so.
Well, the filter is there for a sensor component, but not for a binary_sensor or a text_sensor.
The only example given is for a value to be set for that sensor.
For a sensor I could of course set the value to something arbitrary and then have a filter again with on_raw_value to call the uart followed by a filter_out filter to make sure that value would never be published.
It would be convoluted, but probably work, but it would only be for a sensor and not for a binary_sensor or text_sensor.
You don’t need to. See my sneaky updated post above.
But it does not look like the timeout filter exist for a binary sensor.
Oh. crap. Yeah I misread the component you were using as sensor as binary_sensor has no filters.
The answer as fas as I can see is “no”.
You could maybe jigger something up with a template sensor that follows the binary sensor state.
I think I will just go with the interval component.
It will do some extra pulling, but it will have to do. 
Maybe with some smart multiclick timing.
on_multi_click:
- timing:
- ON for at most 1s
- OFF for at least 30s
then:
The value might not change at all.
The issue is that I have experienced electrostatic noise that sometimes affect the communication.
The noise is short, but enough to, at times, scramble the communication on my uart, so I miss updates.
The idea was to re-verify the state at times, when no updates have been made for a while.
I’m not sure if I follow perfectly. Anyway, it should trigger if you have 30s without input, aka “timeout”.
Can I ask what you are trying to achieve?
I will look into it. Thanks
Control my Onkto amplifier over uart.
There are multiple already made projects for that. Is there a reason you are not using one of them?
It is pretty much that project I am doing, but I tailor it to my device and setup.
The protocol is fine, but each device model is different and there is no way to detect model or features in the protocol.
I have all the files on the the protocol.
I can also do some more this way, like using my own names for the inputs, so they fit what is displayed on the device display.
It is mostly ESPHome that is the problem here, since it is like 25 years since I last looked at C/C++ code and the documentation of ESPHome is not always that deep.
It is a way to get deeper into ESPHome, which I need for some upcoming projects anyway.
Do you mean you are trying to configure ESPHome using YAML to work with your receiver or are you trying to do something more advanced?
Because if you are thinking of making a new external component for ESPHome, then I would recommend just porting the eiscp_bridge that I linked. The way it works, is it packages all the commands in EISCP packets and forwards them.
That way you can just use the standard Onkyo integration with it, and get all the features working automatically. Including naming your input sources too.
If that is beyond your abilities, then just using eiscp_bridge by itself is probably the easiest route. It is not ESPHome, but after you flash it, it should just work with the standard integration.
I am just trying to configure ESPHome using YAML to work with my receiver and handle all the logic on the ESP device, including renamed inputs, extra state pulling and the command set that is specific to my receiver model and my needs.
The eiscp communication have been handled long time ago with just the uart interface.
That part was like 30 YAML lines with mulmcu’s code here used as inspiration.
That’s interesting. I wasn’t aware of this UART debug hack, that’s good to know.
I would still like that in the long term someone created an ESPHome component that makes it possible to interact with the standard Onkyo integration directly. That way the efforts could be combined, instead of everyone just repeating the same thing over and over.
But if the current solution works for you, then that’s all that matters. Sorry I couldn’t be of more help with your timeout problem.
The uart hack does the same as the onkyo integration.
It sends the onkyo command to HA and HA can send an onkyo command the other way.
The difference is that the uart hack gets it in the ESPHome text_sensir, which is just seen as a simply sensor in HA and the command to the onkyo device is handle with an action.
The onkyo solution use a tcp server on the ESP device and might need the Onkyo integration installed and setup to get the same sensor and action.