Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 53.80%. Comparing base (4d8b5ed) to head (5b9c9b7).
Report is 1729 commits behind head on dev.

@@            Coverage Diff             @@
##              dev    #7421      +/-   ##
==========================================
+ Coverage   53.70%   53.80%   +0.09%     
==========================================
  Files          50       50              
  Lines        9408     9812     +404     
  Branches     1654     1353     -301     
==========================================
+ Hits         5053     5279     +226     
- Misses       4056     4207     +151     
- Partials      299      326      +27     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

There is some debate about whether "H-Bridge" is the right name for this. It certainly matches OpenBeken, and the feature requests such as esphome/feature-requests#1690 and #4087 so it looks like it would be well-named for users to actually find it?

Not sure it's strictly technically accurate though, and maybe it would be better as platform: bistable or something like that?

Adding a delay time for on and off signal would be great.

About the name well If i search anything related with the reverse of polarity I look for h-bridge keyword.

Bistable solenoid is only a usecase but there could be more (open and close motorized valves for istance)

Adding a delay time for on and off signal would be great.

Can you help me understand what you need that pulse_length and wait_time don't already cover? (I have now added them to the example YAML above.)

Docs at
https://deploy-preview-4233--esphome.netlify.app/components/switch/hbridge.html

Adding a delay time for on and off signal would be great.

Can you help me understand what you need that pulse_length and wait_time don't already cover? (I have now added them to the example YAML above.)

Docs at
https://deploy-preview-4233--esphome.netlify.app/components/switch/hbridge.html

Sure they are perfect. For some reason I didn't see those values before!!

GS1102

The function I hope for is:
The H-bridge component specifies the zero crossing detection IO and enables the zero crossing trigger function. Whether the H-bridge switch is turned on or off, pin_forward or pin_deverse is in a waiting state until the zero crossing detection IO is triggered by the low-level zero crossing signal of GS1102. After a custom delay time, pin_forward or pin_deverse outputs the relay drive signal

Do we need to build that into the H-Bridge switch component? Wouldn't that be a useful thing for any switch, using a separate zero-detection? I'm imagining a generic switch-when-zero switch type, which takes a slave switch type and a trigger GPIO input, and sets the slave to match its own on/off state whenever the zero trigger is asserted?

That is to say, the H-bridge component has two options:

1. Directly triggered, like the current function, whether the H-bridge switch is turned on or off, pin_fforwards or pin_deverse will directly output the driving signal
2. Zero crossing trigger, specifying the zero crossing detection IO and setting a delay time. Whether the H-bridge switch is turned on or off, pin_forward or pin_deverse is in a waiting state until the zero crossing detection IO is triggered by the low-level zero crossing signal of GS1102. After a custom delay time, pin_forward or pin_deverse outputs the relay drive signal

Because magnetic holding relays are energy-saving and do not generate heat, they are now quite popular, and this H-bridge switch component is perfect for showcasing its capabilities.

Sure, but the zero-crossing thing is surely orthogonal to that? What if we build a generic implementation of that?

 switch:
   - platform: trigger
     name: "Zero-triggered switch"
     trigger_pin: GPIO10 # The zero detection pin
     subordinate_switch_id: the_real_one # Either an hbridge switch or any other type
     trigger_delay: 10ms
   - platform: whatever
     id: the_real_one
     …

I'd knock up an implementation of that to play with, but contributing to ESPHome isn't sufficiently feeding my dopamine addition because things are taking so long to get merged :)

Sure, but the zero-crossing thing is surely orthogonal to that? What if we build a generic implementation of that?

 switch:
   - platform: trigger
     name: "Zero-triggered switch"
     trigger_pin: GPIO10 # The zero detection pin
     subordinate_switch_id: the_real_one # Either an hbridge switch or any other type
     trigger_delay: 10ms
   - platform: whatever
     id: the_real_one
     …

I'd knock up an implementation of that to play with, but contributing to ESPHome isn't sufficiently feeding my dopamine addition because things are taking so long to get merged :)

It looks pretty good and I can't wait to try it out. I wonder if this series control method can accurately and quickly respond,Because the zero crossing point of alternating current changes too quickly

I think this looks good -- @dwmw2 any chance you'd be willing to consolidate the tests into a single common.yaml file? Have a look at the bme280 for a hint.

ISTR I had deliberately made the tests different, to exercise different combinations of options. Will take a look...

ISTR I had deliberately made the tests different, to exercise different combinations of options. Will take a look...

You can still accomplish that -- use extend and/or remove if necessary.
Thanks for working on this! 🍻

Attempted the common template in 49c8ab5

ISTR I had deliberately made the tests different, to exercise different combinations of options. Will take a look...

You can still accomplish that -- use extend and/or remove if necessary. Thanks for working on this! 🍻

@kbx81 I had to do the !include differently to the bme280 example you gave, because it wasn't managing to extend the configuration. But it should now be working with that latest 'Make tests actually pass...' commit.

I wonder if this series control method can accurately and quickly respond,Because the zero crossing point of alternating current changes too quickly

Yes, as I said above you probably want hardware assistance. But even with hardware assistance for the trigger I'm not sure a latching H-Bridge switch will work well for that use case. These things typically have a pulse length of 100ms — meaning that a 50Hz signal will have completed five full cycles (crossing zero ten times) in the time it takes to know that the switch has completed its movement.