If you say so.
… and something is wrong with your system if delay fails to work with the compact format 00:01:00. Could just be the tip of the iceberg.
Out of curiosity, which version of Home Assistant are you using?
Latest versjon, just upgraded so I had to redo a lot of the climate stuff because of the changes. But I don’t think that’s the reason. As for iceberg, there’s not much iceberg here. All the heavy processing is done in EventGhost and Girder on my server, I use Home Assistant to send messages to and from the Z-Wave network. I use Node-RED for the same with RFXtrx and Tellstick Duo, and I did use that for Z-Wave too in the beginning, but the implementation of locks in Node-RED is not working well for my ID Lock, which is why I started using Home Assistant. So my full Automations are only around 20, most of them a few lines.
This is a typical automation for me, turning on and off Bluetooth-spekakers in different zones:
- alias: Brytere for lyd av
action:
data_template:
entity_id: switch.zwavebryter_lyd_{{trigger.payload}}
service: homeassistant.turn_off
condition: []
id: '15261358986'
trigger:
platform: mqtt
topic: ZWaveBryterLydAv
OK, a new run and there’s no doubt. After the long error with “Task exception was never retrieved” the script with multiple delays that should fire every minute does not fire again. With MQTT triggering exactly the same script there is only the “Service not found” error, without anything about task exception, and that can be triggered as many times as I like. So if the delay way isn’t possible I’d just have to send a message on startup of Hass to my main automation server, so that it could trigger once a minute in 2-8 minutes. But I can’t really understand why the multiple delay script doesn’t work when the same script works triggered by MQTT.
If you say so. You also said this:
If delay completely failed to fire then it implies Home Assistant didn’t know how to handle:
delay: '00:01:00'
which is … not good.
FWIW, the tests results I posted were performed with 0.96.3.
And you’re sure that the service exists at the time the service is supposed to fire? I don’t care about MQTT I care about the service you are expecting to fire after the delay.
@123 Thanks for the sarcasm. You still assume I know what I’m doing, which I specifically said in the first post that I don’t. I ment that there’s nothing much of an iceberg with my code. And Hass has been installed the recommended way from fresh. It was actually @Mariusthvdb who said
“also, and that has been documented elsewhere on the community, using delay like this can cause mishaps. If you still run into issues try:”
Maybe I misunderstood him, but I took that as that it doesn’t always work.
Delays always work. If you fire the same automation that contains delays twice+, then you run into issues.
I wasn’t being sarcastic when I said it may be the tip of the iceberg if you’re observing incorrect behavior with delay (and the compact form of representing time).
I can’t comment on what Marius said because without details it amounts to conjecture. I’ve used the short form of delay for several versions and it just works.
@petro No! For the third time (I think), I KNOW that the Z-Wave service does not excist when I start to fire it. But that doesn’t explain why the EXACT same non-excisting service errors out nicely in about a second with “service not found” when fired by an MQTT TRIGER, but takes a minute or two to error out with “Task esception was never retrieved” when fired by a delay TRIGGER. Also I see, so it’s with multiple delays the problems may arise with the standard format.
@123What I took as sarcasm was:
Why does any of this matter with your end goal? It’s why I keep asking the damn question. You don’t understand how frustrating you are. Why fix something that doesn’t need to be fixed when you can make your automation work and be done with it? Jesus.
There could be many reasons why it works in MQTT and not in the start up script. Startup triggers may pass different information down which causes actions to behave differently. Without debugging into it, it’s all up in the air.
To be brutally frank my reply was dismissive as opposed to sarcastic.
If delay isn’t working as documented, that’s not something to be brushed aside. The unusual behavior suggests either a bug or, if it’s only happening on one system, possibly corruption of the system itself. So, yeah, tip of the iceberg, and maybe other things aren’t working properly.
Because I would like it to do on itself it without needing the trigger from the other computer, in case that’s on a reboot cycle when Home Assistant starts up. So using an MQTT trigger adds another moving part which shouldn’t be necessary if the delay script worked. But I see, if there may be different info from the same script triggered by different triggers, I guess that’s the problem. I thought a trigger only passed the info that was in the script, I had no idea it would pass anything else.
I see. I took that particular sentence as sarcasm, but that’s probably environmental damage from too much contact with brits.
I encourage you to try the compact form of the delay again. If it genuinely does not work correctly, I would give serious consideration to the possibility something is flawed with your installation of Home Assistant. Either that or delay has developed a bug in 0.96.4.
I did just now. It triggers, at least the first time. I have no idea why it didn’t before, but I’m guessing it was an indentation or something. The weird thing was that it didn’t complain when reloading the automation module, but maybe that doesen’t happen on all kinds of errors? So sorry, as I said YAML is so far from my language.
But of course it still says “Task exception was never retrieved”. So I guess what’s happening is that when the automation is triggered by MQTT, Hass will at once say that “this service is not here, so no use in trying”, but when triggered by startup and then delay for some reason it doesn’t get that error at once, and it keeps chewing until it errors out in a less graceful way and that blocks the execution of the rest of the automation.
Edit: The task exception error comes after around one minute, it seems. Maybe there’s a timer that stops automations that has locked up for a minute?
I don’t know what you automation looks like now but I will assume it has a 1-minute delay then calls the zwave.test_network service.
Here’s my theory: after one minute has passed, it calls a service whose underlying integration isn’t ready yet so the service call fails and an error message is generated.
If that theory is correct, to achieve what you want, which is to wake up a random node at startup, you’ll have to delay for at least as long as it takes the zwave integration to fully initialize.
It has a one minute delay, and then a two minute delay, but only the first one fires. I know that it will work if I set it long enough, but I would like the system to be tested and up and running as fast as possible. The thing with your theory is that if the underlying integration isn’t ready when triggered by a delay, why should it be ready when I trigger with an MQTT message?
So if only the error system had worked the sam way for the delay trigger as for the MQTT trigger, I would have been done with this hours ago. But it doesn’t seem to do that. Because as I said with the MQTT trigger I can run that automation as many times as I like, until the service is up and running. So it seems like there is a difference in what the delay trigger sends and what the MQTT trigger sends, as @petro said.
without going into the details and why’s of the failing automation/service, did you try to use several automations, each with their own (longer) delay?
Also, and please forgive me if I say something completely stupid… you mentioned the Zwave network is ready after about 7 minutes.
Isnt it to be expected than that the automation will error out with the delays using a much shorter time than that? Why not have a first delay of 00:07:30 and see what happens?