Number of instances of scene has been reduced due to exceeding limit.

[Mib 15]

I get now since I have updated to 4.058 Beta this message:

 

 To many instances | Scene: Licht BEW
Number of instances of scene has been reduced due to exceeding limit.

 

the scene does not work anymore.

 

--[[
%% properties
620 value
%% globals
--]]
 
-- VARIABLEN Konfiguration (Bewegungsmelder muss oben unter %% properties aufgeführt sein) löst die szene aus
-----------------------------------------------------------------------------------------------------------------------------------------
local scene = 200 -- ID dieser Szene EG Vorzimmer
local motion = 620 -- ID des Bewegungssensors
local licht = 622 -- ID Lichtsensor
local switch = 769 -- ID der Lampe
 
local nachtstart = 1600 --22:00 = 2200
local nachtende = 0100 -- 07:00 = 0700
local starttimer = 60 -- licht an zeit (+ zeit des bewegungssensors - par. 6)
local lichtwert = 1 -- grenze zum nachtmodus (nur ausführen, wenn licht größer als)
-----------------------------------------------------------------------------------------------------------------------------------------
--------------------------------------------
---------------------Script-----------------
fibaro:debug("start1")
if (fibaro:countScenes()>1) then
 fibaro:debug("stop scene");
 fibaro:abort();
end
 
-- SCHALTE LICHT EIN & AUS (wenn nicht nacht)
if (tonumber(fibaro:getValue(motion, "value")) > 0 ) and tonumber(fibaro:getValue(licht, "value")) > lichtwert and (tonumber(os.date("%H%M")) >= nachtstart or tonumber(os.date("%H%M")) <= nachtende) then -- hier fehlt noch "und schalter aus"
 fibaro:debug("ausgelöst");
 --led auf wert einstellen
 fibaro:call(switch, "turnOn");
 -- timer start und einstellen
 timer = os.time();
 while os.time() - timer < starttimer do
 fibaro:sleep(1000);
 -- Timer zurücksetzen, wenn neue Bewegung erkannt wird innherhalb der Verzögerungszeit
 if (tonumber(fibaro:getValue(motion, "value"))) > 0 then
 timer = os.time();
 end
end
 -- Schalte Licht aus, wenn Timer vollständig abgelaufen ist
 fibaro:call(switch, "turnOff");
end
fibaro:debug("ende1");
fibaro:killScenes(scene);

 

 

 

[wienog 107]

I'd really like to help you, but I am a lua-only man. I really don't understand "block" scenes. So it's not that I don't want to say anything, I really don't know if there's anything tricky to that scene or not. I guess not, but... This one is for Fibaro, or a blocky-man. Sorry about that!

Peter,

 

I can assure you: there is nothing tricky with these blockscenes, neither is there with their LUA-translation. I fear the problem is entirely with Fibaro and, frankly, you have to wonder if they do any testing at all before issuing this update.

 

What is wrong is 1) that there is no distinction in the 'instance count' between the CHECKING-portion of the scene and the ACTION-portion. The IF and the THEN part, if you want.

 

A scene that is triggered by a temperature sensor and should switch on an electric heater if temperature is below 20 ° C will CHECK it's conditions whenever the temperature of the given sensor changes , even if this check shows the temperature is still higher than 20 ° C and, so, the scene is not RUN. Nonetheless an 'instance will be counted.

 

2) An other problem is that there might be a speed-problem in communication. If you have a scene that switches a light on if a motion sensor is breached and you want to prevent needless CPU and z-wave time by inserting a check to see if the light is not already on, then the scene can be triggered more than ten times already before it stops running finally when the message that the light is already on reaches the controller and is taken into account there.

 

One question though: now in this discussion it seems that many LUA-programmers start there scenes with an instance-limiting line of code. Why do you need that if your code is well written ?

[petergebruers 1,268]

In response to wienog's question: "One question though: now in this discussion it seems that many LUA-programmers start there scenes with an instance-limiting line of code. Why do you need that if your code is well written ?"

Suppose a button functions as a trigger. It starts a scene that switches on a light, sleeps a minute, switches off the light.

When you push the button, while the light is on, and your script is sleeping, a second instance is started. Because the instances can't communicate, I think the only option is to abort the second instance.

I think this is typical for scripts that time something. Many scripts on the forum start with the "countscenes, abort" incantation.

There is an alternative implementation, that doesn't need the incantation. You'll find it in "autostart" scripts.

The previous example can be written as an autostart script. The script has a never ending loop. Typically, it sleeps for at least one second. If someone pushes the button (long enough) the script switches on the light and starts counting. At the count of 60 it switches off the light. Then we are back at the beginning.

I prefer the event triggered approach in this situation, but I do use the second approach to time some wall plugs.

Scripts can, of course, have "autostart" and other triggers combined. But if you stay in a loop, new triggers mean new instances.

Is this an answer to your question?

What do you mean by "well written"?

[Morcegolas 6]

Hi people, this is one of many of my scripts that have this problem. I use it to check if any motion sensor is armed, then change global variable. I already changed the max running instances to two but still getting the error message:

Please login or register to see this code.

it's not an autostart scene checking every minute or so, it activate when any of this values changes.

[petergebruers 1,268]

Wild guess. Have to try this when I'm home. You accept four 'armed' triggers. Maybe they come so fast, that the script isn't compiled on time, and doesn't abort itself on time. So worst case for instances start. But you limit it to two. Does the message disappear when you increase the limit to four?

[robmac 173]

In response to "One question though: now in this discussion it seems that many LUA-programmers start there scenes with an instance-limiting line of code. Why do you need that if your code is well written ?"

<snip>

 

Hi Peter,

 

I use it for a couple of special purposes but agree that in a lot of cases it is no longer needed with this new feature.

 

As an example of when this feature will not work. I have a few scenes that I use to prevent short cycling of my heating pumps and boiler.

 

Once it turns on or off the scene stays active to prevent the boiler or pump being turned on/off too often.  Each of the thermometers or thermostats that are used to monitor/control trigger the scene so without this I could get a situation where the boiler is rapidly switched. An alternative would to be use a fibaro global variable but that is even more ugly and less reliable as at restart it could be left at the wrong state.A LUA global would be the ideal but sadly not happening.

 

If I use this feature as it currently works I will be flooded with notifications of too many instances. I am sure the feature currently has bug just now as I can see from my debug that the count of scenes is never greater than 2 but I get a notification with the max set to 3. That does not make sense.

 

The feature would be even better if you could turn off the notification if it is not needed. I could even use it for the above case then..

 

Robert

[petergebruers 1,268]

Hi Robert, I think that's a nice example of something that needs multiple triggers and causes multiple instances. I think an event queue, that can be dequeued in the scene, would be nice. Sort of "global variable" like you said, but with depth. If the scene count displays 2, the limit is 3 and the notification is logged... Hmmm, need to test that. Is it possible that the display is too slow, and you happened to have 2 running instances and then 2 events arrived at the same time? Nah, that would give 3 running instances plus the notification. Unless that third scene stopped before you looked at the counter. Nope, no idea!

[dw89 8]

Hi guys,

I know that this will be blatantly obvious to some but, perhaps, not others so thought I would just mention it.

Obviously there are some scenes where we 'need' multiple instances running concurrently (though Intry to avoid this where possible). If this is the case I do remember Krikroff coding a good example of multi threading and that may help.

However if you're not wanting multiple instances, say as Peter says with a timed scene, one can just kill the second instance via Fibaro:abort. For example I have a number of scenes that control lights in conjunction with motion. Quite simply it runs a count scenes check first and then, based on motion, turns on a light for say ten minutes. It does this via a loop so that if, within that ten mins, there's more motion it resets the ten mins to the start until there's no more motion, the ten mins run out and light finally goes out. Obviously every time there's a motion breach or motion safe message from the sensor another instance will be created. Quite simply, in that case and within the code, I have multiple checks and abort any other instances whilst the light is still on. As far as I know it works but it will be good to test and see!

KR, Dave;)

[fi-bar-oh 47]

Why the hell has everything become over complicated for an end user!

Block scenes!

If motion then turn my light on

If no motion turn it off

Why do we need more than one instance of each?

[northyorks 35]

+1 Very complicated for an end user. I have block scenes and keep getting notifications. I have read everything on here and still don't fully understand instances count. 

 

I don't think I truly know what an instance is, and I'm not sure any end user getting his HC2 out of the box and setting up would easily grip this either.

 

I have scenes that have always worked with no issue, but now these notifications step in.

[fi-bar-oh 47]

I rephrase my last comment... Unnecessarily complicated considering they pipe on about ease of use using there block scene editor on marketing! 

[Morcegolas 6]

Wild guess. Have to try this when I'm home. You accept four 'armed' triggers. Maybe they come so fast, that the script isn't compiled on time, and doesn't abort itself on time. So worst case for instances start. But you limit it to two. Does the message disappear when you increase the limit to four?

 

Nice catch, it worked!

Please login or register to see this image.

/emoticons/default_wink.png" alt=";)" srcset="https://forum.fibaro.com/uploads/emoticons/[email protected] 2x" width="20" height="20" />

[fuuss 25]

Hi

 

I have also a problem with a scene , jumping always after a day with a limit of 10

Thanks in advance for any help

Please login or register to see this code.

 

[alex88 71]

 

Hi

 

I have also a problem with a scene , jumping always after a day with a limit of 10

Thanks in advance for any help

Please login or register to see this code.

 

Without looking too closely at your code, if you have sleep commands with a scene that is triggered by a change in the value of a device AND you are not including an abort or kill command in your scene you will probably trip the limit of 10 instances at some point.

 

I had to modify a scene that had a 30 second sleep in it that was tripping a limit of 3 instances that I had set.

 

All I did was covert it to 30x one second sleeps in a loop with a check in the loop for duplicate scenes. On finding a duplicate it would abort the current instance.

 

I guess this would solve your issue as well.

Sorry I can't paste the code here.. not at home right now.

[Joacim 11]

@fuuss

Every time value changes you start a new instance of the scene. But there also a sleep in there so there will be times when you create many instances and that is not allowed. I haven't really followed the thread but I think this code still works?

Please login or register to see this code.

[alex88 71]

@fuuss

Every time value changes you start a new instance of the scene. But there also a sleep in there so there will be times when you create many instances and that is not allowed. I haven't really followed the thread but I think this code still works?

 

Please login or register to see this code.

 

That code will work, but you need to consider whether to break up the sleeps, that are 10sec for instance, into smaller chunks to allow the code you suggested to work.

 

if there is a situation where more than 10 value changes can occur in less than 10 seconds, even with your suggested code in place, you would hit the limit.

 

I wonder what is the max number of value changes per second that a device can send to the controller to trigger a scene? All of a sudden this becomes an important fact to know 

Please login or register to see this image.

/emoticons/default_icon_razz.gif" alt=":-P" />

[petergebruers 1,268]

An RGBW in 'input' mode can send several updates per second. I haven't got an exact number but I once had a noisy input and my module set to max sensitivity. The thing filled my log... I think power measurement can do this too...

[fuuss 25]

Thank for the answer , I think i see the problem now too,

 

As you say it would be very important to know how many changes per second the device triggered

 

I my debug log it get something like that

Please login or register to see this code.

But even with this we really don't know the value ,

 

I think the problem is the first sleep(5000)

 

I added this one to be sure that the power value is high enough after a second check because it fell off after TV starts until the whole rest started .

Hmmm So I need to find a solution for that one

 

 

I would be great if FIbaro where added like a kind of Poll intervall for devices like this

[petergebruers 1,268]

I think you can assume there are at least as many triggers, as you can find in your log. Many times, there is only 1 or 2 seconds in between, so during the sleep you get extra instances. I'm not at home and I don't have such a script in production. But I do want to setup a test, mayby tonight or tomorrow. I think, if we can find a good solution, similar problems can be solved.

[fuuss 25]

Ok i just keep everything more simple 

 

Here is my new code , 

Please login or register to see this code.

So I just changed directly a variable so that other instances might not run 

 

The Debug log still says that there were 2 instances running marked by the xxxxxxxxxxxxx

 

[DEBUG] 18:00:30: xxxxxxxxxxxxxx

Please login or register to see this code.

 

But 2 are better than more than 10

Please login or register to see this image.

/emoticons/default_icon_smile.gif" alt=":-)" />

[alex88 71]

before this line: 

Please login or register to see this code.

why don't you add a line to abort the scene if there is more than one instance running? That way, you get rid of the second instance. I don't see why you would want a second instance running if the first one passed your initial test.

Alternatively, if you want to check the next condition first: 

Please login or register to see this code.

Then add the abort after this. Either way you will stop the 2nd instance from running through the entire script.