# Status of a device based on pulse frequency

Hi everyone

I was hoping someone could point me in the right direction for something I am trying so achieve:

My sliding gate motor has a status LED output which I am measuring with an ESP that is configured with ESP Home. It provides pulses of 4.5 V which I run throug a voltage divider to bring it down to a safe voltage to use as a digital input on the ESP.

The output of the motor controller changes based on the status of the gate as follows:

1. Continuous pulsing at about 1 pulse per second means the gate is busy opening
2. Continuous pulsing at about 2 pulses per second means the gate is busy closing
3. Intermittent flashes of 2 pulses every 2 seconds means the mains power is off - it goes: flash-flash-off, flash-flash-off, repeat
4. Intermittent flashes of 3 pulses every 2 seconds means the battery is low (flash-flash-flash-off, repeat)
5. No pulses means the gate is fully closed
6. Continuous on means the gate is fully open

I have tried using the pulse meter to get numbers 1 and 2 to work but as soon as the gate starts to move the frequency of pulses that is reported fluctuates, starting at a high value and then briefly stabilizing just before the gate stops moving. My guess is that the sensor averages the pulses/min and only gets more accurate after receiving a large-ish number if pulses.

5 and 6 I can detect using a binary sensor with an on_off_delay filter that only shows a 1 or 0 once the pulses stop.

What Iâm trying to achieve is have one entity to show me the status of the gate at any given time based on conditions 1-6 above.

Any advice will be greatly appreciated.

I think a statistics sensor on the entity could give you something.

Just to be clear, each âstateâ takes two seconds to complete?
So from off to flash, flash, flash then back to off is three seconds?
How long does it stay off?
I mean what is the complete cycle that is common between them that can be used as the time to use in the statistics sensor?

Just to have something to write the I will assume the number is two seconds.

So ser up a statistics sensor looking back two seconds.
Now the statistic sensor will have a mean value that should be different depending on what the state is.

The only ones that wonât work is 5 and 6.
I think you could use a if âonâ/âoffâ for: 2 seconds could get those.

1 Like

@Hellis81 Thank you for your response.

States 1 and 2 are continuous, so once the gate starts moving the output starts pulsing until the gate stops: Once per second for state 1 and twice per second for state 2. The duty cycle seems to be 50% but I will need to somehow measure it to confirm.

States 3 and 4 repeat over a 2 second cycle. As far as I can tell the pulses take one second, stops for a second and repeats.

A common time to use for these states can indeed be 2 seconds, but states 1 and 3 will both show 2 pulses over 2 seconds since state 1 pulses once per second, so 2 per 2 seconds and state 2 also flashes 2 times over the 2 second period, with their average frequency over 2 seconds also being the same.

State 2 will output 4 pulses over 2 seconds and state 4 will give 3 pulses over 2 seconds so they will provide distinct measurements.

I agree that it might be best to handle states 5 and 6 separately as they canât be measured as pulses.

Thank you for the suggestion. I will play around with the statistics sensor and see what can be achieved. It seems to be a step in the right direction.

What if you make it three seconds then?
Will that make 1 and 3 display a different value?

Perhaps you need one statistics sensor on one second and one on two seconds and perhaps they will give something that will differentiate them?

Iâm sorry to just toss out ideas instead of real proper working ideas but itâs so much easier to test with real data in these cases.

Have you looked at the section under Binaryl Sensor Automation? I have in the past used various `on_click:`, `on_double_click:` and `on_multli_click:` combinations to detect various patterns.

With a bit of fiddling it can be quite useful.

1 Like

Duty Cycle or pulse width? ESPHome â ESPHome

1 Like

No reason to apologise. I appreciate any advice or ideas and these definitely help me to consider solutions that I havenât thought of before. In the end I will inevitably need to fiddle and do some real-world testing before a solid solution can be achieved. The manual doesnât give exact figures since the flashing output is intended to be used with an LED as a visual indicator.

I have had a chance to do some testing though:

I attached a binary sensor to the status pin and ran 3 tests: opening, closing, and power loss. The low battery state will be a bit difficult to simulate, so I made some assumptions for now. The results are as follows:

Opening Sequence:

Closing Sequence:

Power Loss:

Assumed low battery based on power loss output:

It turns out the reason why the pulse meter takes a while to provide a steady output is that the signal contains a bunch of garbage at the beginning and end of the opening and closing sequences. This must be when the motor accelerates and decelerates, but that data is of no use to me and it only adds a level of complexity to the problem as I now also have to determine what type of data to ignore.

The low power sequence graph shows that the â2 flashes every 2 secondsâ shown in the manual is also inaccurate as the actual sequence seems to repeat every 3.2 seconds.

Your initial assumption was therefore spot-on:

So from off to flash, flash, flash then back to off is three seconds?

I couldnât simulate a low battery, but for now Iâm just going to assume that it just adds a pulse to the low-power sequence.

Now, these readings are still only a rough indication since the binary sensor doesnât show the width of the pulse. Just by looking at the onboard status LED on the controller (which is linked to the output), I can i.e. see that while the gate is opening the LED is on for roughly the same duration as it is off. I will need to play with different sensors in ESP Home to get a complete picture of each state.

The next step will be to set up a statistics sensor and see what data it returns.

Thanks again for your inputs.

This is a great idea, thank you for pointing it out. It should work perfectly for the intermittent flashes (states 3 and 4); I will just need to play around with the timing. It should also be easy to add states for continuous on and continuous off (states 5 and 6) to the same sensor. I will definitely give it a shot during my experimentation process.

I will then just need to use a different sensor for the continuous pulsing states (1 and 2) and ultimately figure out a way to bring them together.

This could work perfectly for the continuous flashing states (1 and 2). During recent testing, I found that the output isnât very consistent during those 2 states, though, so the pulse width and duty cycle components might also output varying readings over the sequence. Itâs worth giving a shot, though, so thank you for the suggestion.

For battery level, why not connect the battery to an adc pin on the esp?

I would prefer using the built-in functions of the controller as it already provides all of the information without the need for more hardware and wires. Itâs a 12V battery, so I will need to add another voltage divider as well. I think if I get the other functions to work the battery monitor function shouldnât add more complexity, but if all else fails I will definitely consider it as an option, thank you.