HC3 Kill running scenes

[Keithlambley 3]

I am having a problem killing a running scene.

 

I can kill other scenes, e.g. I have a LUA scene which runs in a loop to semi randomly turn lights on and off in the house for security reasons when I am away, as the times when this is required is variable, the scene starts at sunset and then I have another LUA scene to kill the first one at a specific time using    hub.scene("kill", {174})    this works fine, strangely it takes around 40 seconds to react, see to examples of the output from the console.

 

[18.04.2022] [13:04:54] [DEBUG] [SCENE175]: Scene 'Hall Light Random Stop' activated     (NB Print function added to scene so I know when it runs)

[18.04.2022] [13:05:37] [ERROR] [SCENE174]:

 

[18.04.2022] [13:06:36] [DEBUG] [SCENE175]: Scene 'Hall Light Random Stop' activated     (NB Print function added to scene so I know when it runs)

[18.04.2022] [13:07:17] [ERROR] [SCENE174]:

 

I made another test scene with nothing in it but print statements and I can stop that as well.

 

The problem scene is more complicated, it runs for 7 hours and "presses" buttons in contact sensor quick apps to trigger a morning alarm routine in Alexa.

This one I cannot stop no matter how long I wait ! in fact if I try to restart the scene for a second time it crashes the scenes functionality in my HC3 and I have to reboot it.

I think this crashing is linked with the fact that I cannot manually kill the scene, HC3 is supposed to automatically kill the previous scene when restarting a scene.

 

Has anybody experienced a similar problem ?

 

I don't know if the problem relates to the LUA code in the scene (my programming skills are very limited but I am learning slowly to do simple tasks)

 

Here is what's in the scene.

 

DECLARATIONS

Please login or register to see this code.

ACTIONS

Please login or register to see this code.

Edited April 18, 2022 by Keithlambley

[ivhansen 6]

First: Detecting running scenes is not exactly easy on HC3 - in HC2 you could monitor running scenes (and count) in the UI. In HC3 you can use the Swagger API: http://yourIP/api/scenes/yourScene#

 

You'll get something like: 

 

Please login or register to see this code.

 

Next: Your kill syntax is correct and should work. I've struggled a bit with it too, but till now always found it was I who made a mistake... typically a device or a scene that respawned the scene I tried to kill.

 

An error in the console might indicate an error in the killing scene, so that the kill statement is never executed?

"An error in the console might indicate an error in the killing scene, so that the kill statement is never executed?"

 

Sorry rubish - just read your console output again...

[Keithlambley 3]

Thanks for your answer

 

On this forum I found some code to check which scenes are running and display this in the console, I also added some "print" statements to my scenes to show the start and finish in the console.

 

SO I did some more tests with my "test" scene which only contains a "print" statement followed by a "sleep" time then another "print", I also have a kill scene to run whilst the test scene is timing out.

 

Scene - "Sleep Test"

Please login or register to see this code.

Scene -"Kill 263"

Please login or register to see this code.

 

THE RESULTS ARE VERY INTERESTING !

 

Here is the console printout for a scene with a 40 second sleep timer (ignore scene 260 which is running, thats the scene which is doing the checking). I think the "ERROR" is when the scene is stopped. You can see that the scene is not being stopped by the kill command but something is happening as it returns an error.

 

[19.04.2022] [09:18:26] [DEBUG] [SCENE263]: Scene Sleep Test - Started - Time delay 40s

[19.04.2022] [09:18:29] [DEBUG] [SCENE260]: ID260 Scene is running

[19.04.2022] [09:18:29] [DEBUG] [SCENE260]: ID263 Scene is running

[19.04.2022] [09:18:31] [DEBUG] [SCENE264]: Scene 'Kill263' activated

[19.04.2022] [09:19:06] [ERROR] [SCENE263]:

 

On this one the sleep timer is 15 minutes, again you can see that the scene is not being stopped by the kill command but something is happening as it returns an error.

 

[19.04.2022] [09:29:35] [DEBUG] [SCENE263]: Scene Sleep Test - Started - Time delay 15min

[19.04.2022] [09:29:39] [DEBUG] [SCENE260]: ID260 Scene is running

[19.04.2022] [09:29:39] [DEBUG] [SCENE260]: ID263 Scene is running

[19.04.2022] [09:29:49] [DEBUG] [SCENE264]: Scene 'Kill263' activated

[19.04.2022] [09:44:35] [ERROR] [SCENE263]:

 

So the kill command does not seem to be working at all

 

Surely the kill command should stop the scene immediately ?

 

Did some more tests, this time with a test scene with multiple 20s sleep timers

Please login or register to see this code.

This time when I kill the scene it stops after the first sleep timer, i.e. after 20s

 

[20.04.2022] [10:30:37] [DEBUG] [SCENE263]: Scene Sleep Test - Started - Time delay 20s

[20.04.2022] [10:30:40] [DEBUG] [SCENE260]: ID260 Scene is running

[20.04.2022] [10:30:40] [DEBUG] [SCENE260]: ID263 Scene is running

[20.04.2022] [10:30:42] [DEBUG] [SCENE264]: Scene 'Kill263' activated

 

[20.04.2022] [10:30:57] [ERROR] [SCENE263]:

 

So I would say the kill command is working but not when a sleep timer is active.

 

I dont know if this is how Fibaro "designed" it but it makes the kill command useless.

 

There is still the problem of retriggering scenes with sleep timers crashing my HC3

 

I have submitted a support ticket

Edited April 20, 2022 by Keithlambley

[_Wilco_ 3]

@Keithlambley

Try "killing" this one, it seem to work:

Please login or register to see this code.

 

[Keithlambley 3]

10 hours ago, _Wilco_ said:

@Keithlambley

Try "killing" this one, it seem to work:

Please login or register to see this code.

 

Yes

 

That works, thanks.

 

I dont know what the difference is between "fibaro.sleep(delay)" and "fibaro.setTimeout(delay, function)" ? or which one you should use ?

 

They are both described in the Fibaro LUA documentation

Please login or register to see this link.

(see below)

 

The kill command should work for both, so maybe it is a bug ? will await response from Fibaro Support, but dont hold your breath !

 

fibaro.setTimeout

fibaro.setTimeout(delay, function)

Performs the function asynchronously with a delay. Parameters:

• delay - delay in milliseconds after which the specified function will be performed,
• function - function, which will be executed with the delay.

Examples:
Execute function with 30s delay which turns on the device (ID 40) and sets profile 1 as active.

 

1 2 3 4

fibaro.setTimeout(30000, function()     fibaro.call(40, "turnOn")     fibaro.profile("activateProfile", 1) end)

fibaro.sl

eep

 

fibaro.sleep(delay)

 

Pauses the script execution for the set time (in milliseconds).

Examples:
After 30s delay turn the device on (ID 30) and set profile 1 as active.

 

1 2 3

fibaro.sleep(30000) fibaro.call(30, "turnOn") fibaro.profile("activateProfile", 1)

[jgab 2,009]

The scene is actually stopped immediately in both cases. Stopping a scene that sleeps causes the scene to throw an error - I think it's because they don't just kill the Lua process, but they try to throw an error to unwind the call stack and it probably lacks an error message - thus the ERROR:<blank>. They should of cause wrap the whole scene action in a pcall and display something understandable - like "[19.04.2022] [09:44:35] [WARING] [SCENE263]:Interrupted"

A scene with a setTimeout doesn't throw an error because coroutines that crash/errors don't print their error messages.... (which is a bug IMHO)

 

There is a long discussion in the below thread about the erratic behaviour of scenes and errors

 

 

Edited April 21, 2022 by jgab

[_Wilco_ 3]

@jgab 

So there is no proper way to kill/stop a running scene?

[jgab 2,009]

No - not if the scene is sleeping. 

 

So, there is a the problem as noted above that the sleeping scene seems to be running until the sleeps end. I would say that it's actually dead/stopped - it can't do anything else -  but it is of course a problem - especially if you want to spin up a new instance.

 

Actually, let me refine my theory. fibaro.sleep blocks all events in the scene thread so the kill event will not arrive until after the sleep is finished. (I still think they throw an error though with a missing error message)

The setTimeout does not and thus the quicker terminate.

 

Edited April 21, 2022 by jgab

[jgab 2,009]

...so if you want to write scenes like you did on the HC2 - use a QA instead. 

Edited April 21, 2022 by jgab

[jgab 2,009]

Because they choose the design that sleeps blocks all events I guess they can't do much about it without some more elaborate redesign. QAs also suffers from this as buttons and calls are not handled while the code sleep.

They could have chosen to run the scene action in a coroutine and let fibaro.sleep just pause the running coroutine and thus allow the scene to handle other events in "parallel" - like handling a kill event.

QAs also suffers from this but I believe most people have moved over to setTimeout in QAs (that comes with it's own challenges)

I firmly believe they should allow us to use Lua's coroutines and they should themselves use it to fix these annoying "inconveniences"

 

[_Wilco_ 3]

@jgab

I Have a "sleep" function which I "extend" this way. But would it be better to add some condition to it?

 

Something like this:

Please login or register to see this code.

 

 

On 4/18/2022 at 2:55 PM, Keithlambley said:

HC3 is supposed to automatically kill the previous scene when restarting a scene

 

Is this true?

[jgab 2,009]

1 minute ago, _Wilco_ said:

@jgab

I Have a "sleep" function which I "extend" this way. But would it be better to add some condition to it?

 

Something like this:

Please login or register to see this code.

 

 

Is your goal to run something every hour? Why you store in global variable - to survive a restart? You could have a function that fires on every hour so you don't need to remember anything.
 

Please login or register to see this code.

 

[Keithlambley 3]

Quote

On 4/18/2022 at 1:55 PM, Keithlambley said:

HC3 is supposed to automatically kill the previous scene when restarting a scene

 

Is this true?

 

Yes, look in the scenes "Basic configuration" you can select the restart action, "new instance kills" OR "protect running scene", the default is "new instance kills"

 

Please login or register to see this image.

/monthly_2022_04/image.png.aff254952ebb4466b60c0052b110fb4c.png" />

 

 

[jgab 2,009]

It should say "new instance kills, but waits politely if current scene is sleeping"  

[_Wilco_ 3]

3 minutes ago, jgab said:

Is your goal to run something every hour? Why you store in global variable - to survive a restart? You could have a function that fires on every hour so you don't need to remember anything.

 

No, I have a scene which I start when I go to sleep. But when I am stil awake after an hour, I want to extend the "sleep" function. In other words, not executing the actions in the timeout, but start over with a new timeout.

[Keithlambley 3]

17 minutes ago, jgab said:

Because they choose the design that sleeps blocks all events I guess they can't do much about it without some more elaborate redesign. QAs also suffers from this as buttons and calls are not handled while the code sleep.

They could have chosen to run the scene action in a coroutine and let fibaro.sleep just pause the running coroutine and thus allow the scene to handle other events in "parallel" - like handling a kill event.

QAs also suffers from this but I believe most people have moved over to setTimeout in QAs (that comes with it's own challenges)

I firmly believe they should allow us to use Lua's coroutines and they should themselves use it to fix these annoying "inconveniences"

 

Thanks for your comprehensive reply.

 

It’s not easy for us amateurs especially as there is not even a comprehensive LUA command reference, many years ago I taught myself to program AutoCAD AutoLisp but they had a book 30mm thick which listed every command along with usage examples !

[_Wilco_ 3]

7 minutes ago, Keithlambley said:

Yes, look in the scenes "Basic configuration" you can select the restart action, "new instance kills" OR "protect running scene", the default is "new instance kills"

 

So I probably don't even need to kill the running scene?

[Keithlambley 3]

Anyway

 

I have reported it to Fibaro Support, their response was to refer me to another person, dont know who he was, they gave me an email address but when I tried to contact him the email bounced !

 

They then closed the ticket !

 

I complained and they have reopened it but from past experiences I am not hopeful for a resolution.

[jgab 2,009]

The real problem is that fibaro.sleep also pushes setTimeouts infront of it

Please login or register to see this code.

Please login or register to see this code.

 

Here we would expect "C" to be printed at 13:10:56, but it's delayed to 13:10:57 because of the fibaro.sleep for 1s.

This is really bad as we can't trust timers - this was the drop that made me stay away from scenes... 

Note that in QAs the behaviour is the expected and the "C" is printed 13:10:56. Why?, probably because they have another/correct setTimeout implementation. 

Edited April 21, 2022 by jgab

[jgab 2,009]

In the previous example I used fibaro.sleep to push the setTimeout, but it's enough that we have code that takes time.

Ex.

Please login or register to see this code.

The loop takes ~7s on my HC3. The setTimeout I expect would print 1s after the loop finish (7+1), but instead executes 8s after the loop finish (7+8).

This means that setTimeout functions will drift willy nilly and it's impossible to do something in a scene that requires strict timing.

 

...in a QA it executes 1s after the loop as expected.

Edited April 21, 2022 by jgab

[_Wilco_ 3]

@jgab

? That's weird behavior! Not very trustworthy.