Jump to content

Welcome to Smart Home Forum by FIBARO

Dear Guest,

 

as you can notice parts of Smart Home Forum by FIBARO is not available for you. You have to register in order to view all content and post in our community. Don't worry! Registration is a simple free process that requires minimal information for you to sign up. Become a part of of Smart Home Forum by FIBARO by creating an account.

 

As a member you can:

  •     Start new topics and reply to others
  •     Follow topics and users to get email updates
  •     Get your own profile page and make new friends
  •     Send personal messages
  •     ... and learn a lot about our system!

 

Regards,

Smart Home Forum by FIBARO Team


  • 0

Question

Posted (edited)

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 by Keithlambley

Recommended Posts

  • 0
Posted

@jgab

I don't want to hijack this topic, but brainstorming further on the timer kill/cancel idea, I thought I had a genius idea?

I made a "Multi level switch" QA with the following code:

Please login or register to see this code.

 

When I set the switch to a certain level, it counts down 1 level every minute and than runs the desired code. But what I was suspecting, was that when I set a new level the "do" loop would interact on this because of the "getValue". Same for the "OFF" button (level to 0), I suspected the "Do my stuff" would be skipped. 

 

Isn't LUA synchronous?

 

B.t.w. When is use a setTimeout in the "DO" loop (instead of the "sleep") the code in the "setTimeout" is never executed and the "DO" loop ends in a endless loop, crashing my HC

  • 0
Posted (edited)

Yes, Lua is synchronous. And ,no, you should not use sleep in QAs. While you sleep, button presses queue up etc, etc.

You need to do something like this (set interval to 60 gives a minute)

Please login or register to see this code.

 

Edited by jgab
  • Thanks 1
  • 0
Posted

@jgab

Great! after a small modification, it is perfect! 

I wanted the "stuff" only to run if the timer ends by its elf.

Please login or register to see this code.

 

Now I can cancel the timer or set it to any new value. Super!

 

Thanks for your help!

  • 0
Posted
W dniu 21.04.2022 o 13:16, jgab napisał:

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. 

 

But what to do when we want the program to "pause" until the something happens, and then move on. O.E. wait for the door is open, then wait for it to be closed, then turn on the lock.

How to avoid sleep() when we can't continue until the condition was met (and we have to test the condition time after time)?

 

 

 

 

 

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...