Tutorial: Single scene instance / Event model

[jgab 2,642]

1 hour ago, domin12 said:

true, I'll try to explain.

now = 11:58

BlindTimeC = 12:00

I want to push specific VD button witch close my blinds  at BlindTimeC time, let say at 12:05, 

so i need on my VD press the '+' button 5 times to reach this time (increase minutes),

every click ('+") change the time, it means that BlindTimeC will be set up (reschedule) as 12:01, 12:02, 12:03, 12:04, and the last 12:05,

this causes the button to be pressed in time (12:01, 12:02, 12:03, 12:04 and the last 12:05) not only at 12:05.

My blinds trying to close every one minute  

 

Ok, it was actually my intention that it should behave like in your example, but my testing was insufficient.

I pushed fix19 that behaves like below. It cancels the previous schedules and only run the last - which will in this case be the 12:03

Please login or register to see this code.

with log output (only gives the "Rescheduling..." log message if _debugFlags.dailys=true)

Please login or register to see this code.

 

[FrankT 0]

@jgab  I am using HC2 4.530. And yes, the triggers in the geader are wrong, I copied my Alarme-scene and only change the main-function, forgot the header! Thank you for your help.

 

/F

On ‎1‎/‎24‎/‎2019 at 4:41 PM, FrankT said:

@jgab I’m running v 1.11, fix 13. No error message.

Quote

 

I was more thinking of the HC2.  Is it the latest 4.530?

btw, in the scene you declare number of properties value triggers at the top that doesn’t seem to be the lights. What kind of devices are those? I’m asking because triggers in the header is what starts new instances of the scene.

/J

 

 

 

 

 

[domin12 9]

1 godzinę temu, jgab napisał:

 

Ok, it was actually my intention that it should behave like in your example, but my testing was insufficient.

I pushed fix19 that behaves like below. It cancels the previous schedules and only run the last - which will in this case be the 12:03

Please login or register to see this code.

with log output (only gives the "Rescheduling..." log message if _debugFlags.dailys=true)

Please login or register to see this code.

 

@jgab not working for me at all, sorry

triger is : CyrkulacjaTime

this is my rules:

Please login or register to see this code.

 

and in debug window, I have only smile

Please login or register to see this code.

 but if i change rules for this by adding 19:30 :

Please login or register to see this code.

then in debug:

Please login or register to see this code.

 

Edited January 25, 2019 by domin12

[jgab 2,642]

2 hours ago, domin12 said:

@jgab not working for me at all, sorry

triger is : CyrkulacjaTime

this is my rules:

Please login or register to see this code.

 

and in debug window, I have only smile

Please login or register to see this code.

 

Did you add CyrkulacjaTime under %% globals?

If I run this on the HC2 and ZBS (fix19)

Please login or register to see this code.

I get this output (HC2)

Please login or register to see this code.

(I have 324 hours uptime  )

It reschedules the scene 3 times (the smileys) but only starts the scene 21:30:50, which is correct. If you turn on _debugFlags.dailys=true, you will see the schedules that are logged.

Could it be that the time was too far off in the future so you never saw it?

Also, if you reschedule a time in the morning and the current time is in the afternoon, you will not see any message as the time will be reschedule at midnight for the next morning.

 

[domin12 9]

6 minut temu, jgab napisał:

I get this output (HC2)

Please login or register to see this code.

@jgab shouldn't be their info about rescheduling as before

Please login or register to see this code.

and please try to call some rule after setup new value in the variable CyrkulacjaTime

rule([[@time($CyrkulacjaTime)  => log('Scena %s',$CyrkulacjaTime)]])

and check if it's calling, for me no...  

 

and Yes, I have CyrkulacjaTime under %% globals

[jgab 2,642]

4 minutes ago, domin12 said:

@jgab shouldn't be their info about rescheduling as before

 

Only if you set _debugFlags.dailys=true. It was too noisy before...

 

4 minutes ago, domin12 said:

Please login or register to see this code.

and please try to call some rule after setup new value in the variable CyrkulacjaTime

rule([[@time($CyrkulacjaTime)  => log('Scena %s',$CyrkulacjaTime)]])

and check if it's calling, for me no...  

 

and Yes, I have CyrkulacjaTime under %% globals

 

rule([[@time($CyrkulacjaTime)  => log('Scena %s',$CyrkulacjaTime)]])  only runs when time is time($CyrkulacjaTime). If you test in ZBS and _SPEEDTIME maybe you can more easy check it.

[domin12 9]

@jgab

 

will test it tomorrow, I found interesting dependencies, function change the time(reschedule) if it's later than now, this can be confusing. But if it working in that way, probably all will be ok .

 

 

 

Edited January 25, 2019 by domin12

[jgab 2,642]

9 hours ago, domin12 said:

@jgab

 

will test it tomorrow, I found interesting dependencies, function change the time(reschedule) if it's later than now, this can be confusing. But if it working in that way, probably all will be ok .

 

@<time expression> => log('hupp')

The "semantics" of the daily/redaily functions are something like this:

A) It is always rescheduled at midnight. The reason behind that is that if the <time expression>  involves sunset/sunrise it needs to be calculated at the right day (I use fibaro's built-in sunset/sunrise and it is updated at midnight ) 

B) Now with the new "redaily" function,  if you change the <time expression> to a time later the same day, we cancel the old scheduled time and we need to reschedule to the new time because it is happening later  today (before midnight).

C) However, if you change the <time expression> to a time that have already passed today, it mean that its next time will happen tomorrow. We then don't need to do anything as it will be rescheduled at midnight per step A)

 

It's shouldn't be more confusing than changing the alarm on your clock - except that you need to kick the clock for the new alarm to be set, and there is a ghost kicking it at midnight...

 

[jgab 2,642]

I have uploaded a new scene, "Supervisor.lua" on GitHub.

 

The scene when started will look through all the scenes on the HC2 and collect the ones based on the EventRunner framework.  Then it will start pinging them and if there is no response try to restart them. After 3 attempt to restart a non-response scene it will "disable" the scene and optionally send a push message to the administrators phone.

There are other "watchdog" scenes out there but EventRunner scens are special in the way that they always responds to events if they are alive. This gives a "foolproof" way to know if the scene has crashed without any error message or is just "sleeping"

 

To recognise an EventRunner based scene, there is a "magic" constant in the framework, and it has been there since v1.7 (at least). The constant is 

Please login or register to see this code.

...and if you have an old scene based on EventRunner you can check if it's there. It also needs to respond to PING events. There was a bug introduced there but since v1.12 I think it is correct. It should have a line that looks like:

Please login or register to see this code.

I have updated the iOSLocator scene and pushed it to GitHub too. It was only the constant missing there.

 

The scene needs to be set to "Automatic" (sceneRunConfig=="TRIGGER_AND_MANUAL") also. The supervisor will ignore scene that are "DISABLED" or only set to "MANUAL".

When a scene doesn't responds to restart attempts, the Supervisor will set its sceneRunConfig to "MANUAL" and then ignore it. Fix the scene and set it back to automatic and it will be pinged again.

 

I have used this for a while and it seems to do its tasks. Good safeguard against bugs in rules, bugs in the EventRunner framework, and bugs in the HC2...

I'm happy to receive feedback on ways to tweak the behaviour.

There are some variables in the beginning that decides how and when it polls

Please login or register to see this code.

 

The scene could be more sophisticated and I have some ideas on additional tasks it could do.

• A logger for EventRunner scenes with optional notification service - or that integrates with existing notification scenes.
• A publish/subscribe hub so scenes could connect easier. Ex. the iOSLocator tells the Supervisor that it can provide location events (publish). Other scenes that startup tells the Supervisor that they want to receive location events (subscribe). So, scenes only need to be aware of the Supervisor to start to send events to each other.
• A restart service. Sometimes scenes want to restart. Tell the Supervisor to kill me and restart me. Good when ex. the HomeTable has updated and the scene needs to be re-initialised.
• A startup service that start up scenes in a specific order with delays. Inspired by @petrkl12

So this scene will evolve over time.

 

Who supervises the supervisor? No one, but a scene that gets pinged could try to start the Supervisor if it isn't being pinged in a certain amount of time... but that's optional.

Edited January 26, 2019 by jgab

[jgab 2,642]

The Supervisor scene in the previous post catches when the "engine" inside the EventRunner scene dies, the main event loop that reads and dispatches triggers to rules and Lua handlers.

When there is an error in a rule or handler it is usually caught by the framework as all invocations of rules and handlers are done within a 'pcall'. If there are an error the rule handler is disabled to not cause more trouble. The supervisor will not react on this as the framework has not crashed and is still running, executing the remaining rules and handlers and answering pings.

 

However, if a rule gives an error it can be good to be notified. The framework will log these errors, but it will also post these error as events

Please login or register to see this code.

and that event can then be caught by declaring an "error handler"

Please login or register to see this code.

so you are notified if something goes wrong.

[domin12 9]

Hi@jgab

Everything working as expected, I'm really appreciated for Your time.

 

going forward with Your framework, how to set up a role with this step:

if wallplug is on but there is no power consumption for 5 min , then off

[jompa68 121]

8 minutes ago, domin12 said:

Hi@jgab

Everything working as expected, I'm really appreciated for Your time.

 

going forward with Your framework, how to set up a role with this step:

if wallplug is on but there is no power consumption for 5 min , then off

Something like this:

Please login or register to see this code.

 

[domin12 9]

Godzinę temu, jompa68 napisał:

Something like this:

Please login or register to see this code.

 

Hi @jompa68
the rule is not triggered, the power value not changed for this wallplug when nothing is connected to them or simply the device connected to this wallplug is switched off and we on the wallplug

rule[[for(00:01,965:power==0) => log('....................heater.......................');965:off]]

 

what can I change to make this working?

----------------

I've got the solution:

rule[[for(00:01,965:value) => || 965:power==0 >> log('....................heater.......................');965:off]]

 

 

Edited January 28, 2019 by domin12

[jompa68 121]

well, rule will not trigger if attached device to plug is off. What if you set device on, will it turnoff 965 after 1 minute? 
You sure that device dont give some watts even when turned off? 

your rule will only work if power(watt) is exactly 0 for 1 minute.

[jgab 2,642]

Hi,

I got a bad case of the flue yesterday so I'm not thinking really clear at the moment. However, I think that the solution should be

Please login or register to see this code.

Testing against below 1 just to be sure - if you know that the plug reports "0" so replace with 0.

Having said that and tested it I realised that the "compilation" of triggers were a bit broken since I rewrote it some versions ago. More specifically, the rule here need to trigger on {type='property, deviceID=965, propertyName='value'} for the 965:isOn and  {type='property, deviceID=965, propertyName='power'} for 965:power. In the old version only the value trigger was got defined. 

I made a quick hack to try to restore the correct handling of triggers (1.12, fix2) and pushed it. Test it and see if it works. Otherwise I will fix it properly when I get better.

[domin12 9]

Godzinę temu, jgab napisał:

Hi,

I got a bad case of the flue yesterday so I'm not thinking really clear at the moment. However, I think that the solution should be

Please login or register to see this code.

Testing against below 1 just to be sure - if you know that the plug reports "0" so replace with 0.

Having said that and tested it I realised that the "compilation" of triggers were a bit broken since I rewrote it some versions ago. More specifically, the rule here need to trigger on {type='property, deviceID=965, propertyName='value'} for the 965:isOn and  {type='property, deviceID=965, propertyName='power'} for 965:power. In the old version only the value trigger was got defined. 

I made a quick hack to try to restore the correct handling of triggers (1.12, fix2) and pushed it. Test it and see if it works. Otherwise I will fix it properly when I get better.

Hi @jgab

I wish you a speedy recovery. Works perfectly. thanks again

[domin12 9]

Hi @jgab

on my second HC2, I've got this error message :

 

[DEBUG] 19:50:38: Error loading rules:/usr/share/lua/5.2/json/decode.lua:74: bad argument #1 to 'match' (string expected, got nil)

what does it mean?

copying the same scene to the first HC2, the error did not appear.

 

--------------------

 

solved

Edited January 28, 2019 by domin12

[domin12 9]

Hi @jgab

rdaily function stopped working on a new version of EventRunner

[jgab 2,642]

You sure? it's named 'redaily'  

It works for me and there is no change to the code that I can see. Do you have an example?

[domin12 9]

8 minut temu, jgab napisał:

You sure? it's named 'redaily'  

It works for me and there is no change to the code that I can see. Do you have an example?

I'm sure,  (true, "redaily", miss type)
for testing, I have both versions 1.11 fix 19 and the latest one 

on 1.11 everything works fine when changing the time it rescheduling entries etc, on new one nothing happens.

 

for example, this is not working on the new one but works fine on 1.11 fix 19

on both versions, I've got CyrkulacjaTime under %globals at the top of scenes.

 

R1=rule([[@{time($CyrkulacjaTime),19:30} & $w_domu=='1' & $dzien_wolny=='0' => log('Scena - Pompa Cyrkulacyjna - dzień pracujący');scene.PompaCyrkulacyjna:start]])
rule("$CyrkulacjaTime => redaily(R1);log(' Czas cyrkulacji %s',$CyrkulacjaTime)")

Edited January 29, 2019 by domin12