Hbridge christmas light #1251
Hbridge christmas light #1251
Conversation
There was a problem hiding this comment.
Hi @DotNetDann Please check your branching as you are pulling in commits that are unrelated. Try rebasing your branch from the latest esphome dev branch.
Thanks
Can be used for Christmas lights that use 2 wires to run 2 different strings of lights using a hbridge driver.
DotNetDann
force-pushed
the
hbridge-christmas-light
branch
from
3afa8d6
to
e3741d2
Compare
| cv.GenerateID(CONF_OUTPUT_ID): cv.declare_id(HBRIDGELightOutput), | ||
| cv.Required(CONF_PIN_A): cv.use_id(output.FloatOutput), | ||
| cv.Required(CONF_PIN_B): cv.use_id(output.FloatOutput), | ||
| }) |
There was a problem hiding this comment.
Im not 100% sure about this, but you could try also extend polling_component_schema so users can override the update_interval in config to speed up and slow down the switching since you are already extending PollingComponent. You can set the default 1s in the config and remove the constructor from the .h file
| }) | |
| }).extend(cv.polling_component_schema('1s')) |
There was a problem hiding this comment.
I tried polling_component_schema originally however it is not fast enough. I actually need the loop to run as fast as it can
There was a problem hiding this comment.
Ah I was getting confused about the PollingComponent and how you were using it.
So with this, both "sets" of lights would always be on?
It loops about 60 times a second because the ESPHome loop is 16ms intervals, so your update method will only be called once every 16ms even with the 1ms time on the PollingComponent
There was a problem hiding this comment.
Have you tried changing it to extend Component instead of PollingComponent and then override loop instead of update?
There was a problem hiding this comment.
Is this the recommended approach?
I am happy with the refresh rate. The only problem is that it can flicker when it is running other background tasks like MQTT or WIFI things. However, I don’t want to impact these tasks so was happy with it.
There was a problem hiding this comment.
Yeah, there is no point in setting a PollingComponent unless it can be overridden by the user in yaml. And if you want it to switch between them as fast as possible, then using loop is better as there is more logic around the PollingComponent update times etc that has to do calculations. I guess you could tie into effects like string A on for 1 second then string B on for 1 second (looping) later on. But this currently would just appear as all lights being on right? Can you post a video of what it currently looks like?
There was a problem hiding this comment.
The PollingComponent is used for consistency. I was unable to stop flickering with the Component.
Here is a video of what it is and does - https://youtu.be/_sU-UKU6fV8
There was a problem hiding this comment.
I have changed my flag to a boolean and also fixed a bug that was caused from #947
| cv.GenerateID(CONF_OUTPUT_ID): cv.declare_id(HBRIDGELightOutput), | ||
| cv.Required(CONF_PIN_A): cv.use_id(output.FloatOutput), | ||
| cv.Required(CONF_PIN_B): cv.use_id(output.FloatOutput), | ||
| }) |
There was a problem hiding this comment.
I tried polling_component_schema originally however it is not fast enough. I actually need the loop to run as fast as it can
bringing Christmas lights into esphome
Description:
Little Tuya modules are now in Christmas lights. These normally have a hbringe so they can skimp on the long cable costs.
e.g. https://mirabellagenio.net.au/festive-lights
Pull request in esphome-docs with documentation (if applicable): esphome/esphome-docs#733
Checklist:
tests/folder). (NOT TESTED!!)If user exposed functionality or configuration variables are added/changed: