If I define the interval with a fix value it works:
interval:
- interval:
seconds: 30
then:
I also tried to copy the value from interval_length to a global variable (it worked) but I could not use the global variable either to set the interval length (same error).
Or is it impossible to change the interval time during runtime?
Well, unfortunately, it does not work. Nothing happens. I’ve not used exactly your code, I have the logger block before the lambda block but I cannot imagine that this changes anything.
I also tried adding call_setup() from this post: Dynamically change update_interval - #10 by 0x3333
Then something happens: In every loop run (at least it seems to me) the interval is triggered. In my case this means a direction is changed from forward to reverse.
So, this does not seem to be the right approach, either.
Ok… First of all if the Number entity is controlling another entity created in Esphome, then you should create the Number in Esphome too.
The only difference between the two ways is if you use Esphome then you can use it in both HA and Esphome but it having the number and delay, you can use both irregardless of HA and will continue working without HA.
If you create it in HA and then import it into Esphome, you then need both HA and Esphome. If HA is down then yon wont have a Number to set your delay.
Thanks again, @robertklep ! Now, it works.
I just wonder where the documentation for such functions as set_update_interval() or call_setup() can be found? It seems to me like a well hidden treasure.
@Poo_on_myShoe : I don’t get it completely what you mean.
My interval definition looks like:
In my case, the device is placed somewhere with bad wifi coverage. So it resets every now and then. I don’t mind too much if it has some default values which make sense. And to me it seems (from what I have observed) that the 30 seconds are such a default value.
How do you think, it should be done differently? Could you please explain a bit more in detail as I’m relatively new to esphome and HA?
What I’m saying is if you have an entity, like an Interval/Delay and a second entity, like a Number entity that allows you to dynamically change another entity, then it’s best to keep both entities together in either HA or Esphome, you don’t want to unnecessarily split them up between two platforms if you don’t have to do that, it just introduces reliability risks because when you make one in Esphome and the other in HA, then to be able to use the Number entity to set your delay Interval, it requires both Esphome and HA to be online and working. If either Esphome or HA is down/unavailable etc, you cant do any simple tasks like setting a delay because, you made it less dependable by splitting it up.
If you keep them together, it will still work and appear identically to how it does now in your HA Dashboard and there’s actually no differences as far as how it functions or works, you’re just making it it less likely to break.
Think of it like putting your spare tire in your wifes car… You’ve still got a spare tire if you need it but, if your wife isn’t in her vehicle following you around, then it makes no sense to seperate them. You want the spare tire in your car so that if you have a flat, you won’t be stuck broken down and waiting for your wife to bring it… So, in that story you’re Esphome, your wife is HA and then your car is Number and the spare tire is Interval. See how it makes more sense to keep the spare with and inside of the car it goes to, instead of putting it somewhere else?
If HA ever breaks or something happens, you will still have fully functioning Esphome nodes that you can access, control/configure entities, and won’t lose any Automations that are created on them because Esphome is made to be used 100W% independent of HA.
Here is an example. I’ve accessed one of my Esp nodes through a browser and not using HA at all. I can set that Dynamic Update Inverval (delay) through the node itself or from within HA. Here is accessing it from it’s url address.
And like I said, It makes no difference at all as far as HA because you have the identical entity in HA and doesn’t matter if you created it in HA or in Esphome, it’s just better to use Esphome because, it’s more versatile and more dependable.
Here is an arguably better way to do a dynamic interval because this will automatically check and set the interval time on_boot and this way allows you to create a general purpose dynamic interval like you made or the same method can be used to make any entities “update_interval” dynamic instead of a fixed value that usually requires you to edit your config and reflash the esp board if you wanted to change your update_interval from 10s to 60s… This method allows you to change any update interval from your HA dashboard if you need too. So, changing the Number will change the update interval of the sensor, “id: Bright” which is a Lux/light sensor in this example.
Many thanks, @Poo_on_myShoe !
Your code example is extremely helpful. The main idea, if I understand correctly, is to use
number:
- platform: template
instead of
number:
- platform: homeassistant
because the first one is always present and also appears in HA (and can be changed from there, too).
I got this now. And for the rest of your very detailed posts, I think it will take some time to digest all the little details.
it results in the exact same HA Number entity as you would get if you made it in HA itself by creating an Input Number Helper from the HA UI. The only differences are where your making the entities or where they are stored at. Your Number entity is for setting the value of your Interval delay that you made in Esphome so if you need to control an Esphome entity with a Number, you should probably also have it in that same esp program where they can be together and 1 device with all the necessary entities inside of it, rather than 1 here, 1 there and then we’ll import an entity from HA that we need to configure our Interval/Timer and gain nothing at all, except additional and unnecessary complications as well as decreased reliability and dependability.
Not to sound like a dic^ but, some of these things start becoming more clear over time and make much more sense. It will really make sense if you’ve ever had your HA crash and it takes EVERYTHING down with it! You’ll understand immediately the value of having options available for simple things like turning on a light because if everything and every automation is stored on and executed by HA, then you’re exposing yourself to a whole lot of risk!
Doing it the way I’ve been suggesting will limit that risk and if you additionally duplicate the automations in your HA to relevant esp devices and set simple conditions for one to only trigger if it’s counterpart on the other system, either Esphome or HA is offline. Doing additional simple things like that will protect a large chunk of your home automations in the event of a HA crash too.
I learned my lesson from only 1 raspberry pi SSD failing and HA failing with it, as long as basic stuff like security lights, morning alarm didn’t function, lights couldn’t be controlled, door bell didn’t Chime, Cameras didn’t snap photos, etc, etc… It’s a nightmare.
