Tutorial: Single scene instance / Event model

[ChristianSogaard 71]

9 hours ago, ChristianSogaard said:

Hi - I´m trying to read my Netatmo Co2 sensor

The trigger look like this - Incoming trigger:{"id":521,"value":862,"type":"device","property":"value","old":891.0}

 

Please login or register to see this code.

I tried several syntax with no luck. i could use some help

This works

c02sensor = 521

 

rule([[c02sensor:value =>

    || c02sensor:value < '900' & c02sensor:value > '800' >> 218:color={255,2,255,16};

    || c02sensor:value < '1200' & c02sensor:value > '901' >> 218:color={255,2,2,16};   

    ]])  

 

[jgab 2,642]

14 minutes ago, ChristianSogaard said:

This works

c02sensor = 521

 

rule([[c02sensor:value =>

    || c02sensor:value < '900' & c02sensor:value > '800' >> 218:color={255,2,255,16};

    || c02sensor:value < '1200' & c02sensor:value > '901' >> 218:color={255,2,2,16};   

    ]])  

 

The syntax is

Please login or register to see this code.

but your second version works. as well and may be easier to read. No need for quotes around the number values

[Sjakie 156]

Jan,

Whats wrong here? I cant detect.

<in Rule:72[#morningCurtain8 & gordijnen:value < 2  =>...]: {"src":"Rule:72[#morningCurtain8 & gordijnen:value < 2  =>...]","ERR":true,"msg":"Error executing instruction:'[\"<\",2]'","err":".\/include\/EventRunner.lua:1484: attempt to compare nil with number"}>

<  Rule.eval([[#morningCurtain8 & {woonKamer.gordijnVoor | woonKamer.gordijnOpRit | woonKamer.gordijnZijKant |     eetKamer.gordijnAchter | eetKamer.gordijnZijKant}:value < 2  =>
       {woonKamer.gordijnVoor, woonKamer.gordijnOpRit, woonKamer.gordijnZijKant, eetKamer.gordijnAchter,           eetKamer.gordijnZijKant}:value= 100;
            log('Een gordijn woonKamer was niet geopend14 - open?') ]])>

//Sjakie

 

[Sjakie 156]

Jan,

How to receive a message:

- if batery level is zero for all devices?

- if last breached of all door and window devices > 24 hours?

Thanks in advanced,

//Sjakie

 

[JcBorgs 52]

Sorry for asking, but what are actually the main advantages of using EV4 instead of individual “normal” scenes? With EV4 aren’t you “putting all eggs in one basket”? I mean, if EV4 fails for some reason, then all of my automation that I have put into EV4 are affected, if a normal scene fails then just that scene fails.

 

Do like the concept, did use GEA a lot in my HC2. Just looking for some clarifications on what the actual benefits are compared to the risk of everything failing. 

[Sjakie 156]

@JcBorgs, when I started with HC2 I used block scenes.

Fast and easy for a noob.

Some HA needed lua so users here where helping me and it was complicated for me to create scenes in LUA.

I had 150 block scenes if I proper remeber.

I was reading the Event Runner and All in One posts and thought that should be something for me. The All in One I found to difficult or I am to old.

I started with ER and afterwards I regret I didt start with it.

My HA around 80 devices was complete running in ER with 10 scenes

This all thanks to the service excellence from Jgab!!!!!

His support is fabulous.

Than HC3 came on the market.

I bought one in June and started with ER4 and some QA's

The system was not stabile and I had a great number of difficult issues to tackle.

In January I restarted the project of migration and to change from ER3 into ER 4 was very easy you do not need to rewite all the scenes you had. Now I have 6 QA's  with approximately 600-700 rules. The overview of it is much better and clear.

VD's I had one in HC2 so that was no issue either.

If ER4 fails Jgab will pick it up directly.

In case you have a working system you can switch off auto update for more relayability.

I am a very happy ER4 user!!!

Succes,

//Sjakie

 

[JcBorgs 52]

17 minutes ago, Sjakie said:

@JcBorgs, when I started with HC2 I used block scenes.

Fast and easy for a noob.

Some HA needed lua so users here where helping me and it was complicated for me to create scenes in LUA.

I had 150 block scenes if I proper remeber.

I was reading the Event Runner and All in One posts and thought that should be something for me. The All in One I found to difficult or I am to old.

I started with ER and afterwards I regret I didt start with it.

My HA around 80 devices was complete running in ER with 10 scenes

This all thanks to the service excellence from Jgab!!!!!

His support is fabulous.

Than HC3 came on the market.

I bought one in June and started with ER4 and some QA's

The system was not stabile and I had a great number of difficult issues to tackle.

In January I restarted the project of migration and to change from ER3 into ER 4 was very easy you do not need to rewite all the scenes you had. Now I have 6 QA's  with approximately 600-700 rules. The overview of it is much better and clear.

VD's I had one in HC2 so that was no issue either.

If ER4 fails Jgab will pick it up directly.

In case you have a working system you can switch off auto update for more relayability.

I am a very happy ER4 user!!!

Succes,

//Sjakie

 

Thanks Sjakie,

 

Have started looking into ER4 and looks promising, a list of available commands would be useful, searching though +2000 post takes some time…

 

Edited March 26, 2021 by JcBorgs

[Sjakie 156]

Hi,

You dont need a GV for sunrise use

sunrise..sunset >>daytime

@sunrise at sunrise

 

<Rule.eval([[@05:20 & now < sunrise => Light:on]])>

but perhaps the Master will give another advice.

//Sjakie

 

here you find usefull information

 

[JcBorgs 52]

Progressing..... a lot of simple rules now running in EV4.

 

But how do I run a rule based on date?

 

I want to do this one of two ways (second would be preferable if possible).

1. At a specific day every year set a global Parameter to 1, and then on another day set the Global Parameter to 0. This Global Parameter will then be used as a condition in another rule.

2. Use a date range as a condition in a rule, this works with time (12:35..17:48) but I can't get it to work with dates. 

    rule("button:isOn & 05/01..10/15 => Light1:off & Light2:off")

 

What I want to achieve: If a door is opened during the time frame 1st May to 15th October I want two Lights to be turned off, if the door is opened outside of these dates the light should not be turned off. 

[Sjakie 156]

@JcBorgs, I hope I do it right see enclosed file.

//Sjakie

Please login or register to see this attachment.

[jgab 2,642]

11 hours ago, JcBorgs said:

Progressing..... a lot of simple rules now running in EV4.

 

But how do I run a rule based on date?

 

I want to do this one of two ways (second would be preferable if possible).

1. At a specific day every year set a global Parameter to 1, and then on another day set the Global Parameter to 0. This Global Parameter will then be used as a condition in another rule.

2. Use a date range as a condition in a rule, this works with time (12:35..17:48) but I can't get it to work with dates. 

    rule("button:isOn & 05/01..10/15 => Light1:off & Light2:off")

 

What I want to achieve: If a door is opened during the time frame 1st May to 15th October I want two Lights to be turned off, if the door is opened outside of these dates the light should not be turned off. 

Ok, dates have been a bit neglected when it comes to comparing intervals.

Let me give you some background.

When ER sees 12:35 it is translated to 12*3600+35*60. We make it into seconds, it's done when the rule is "compiled".

There is a 'now' constant in ER rules that is the current time in the same format, so if time is 18:00 then now is 18*3600+0*60

 

The '..' operator would assume that the intervals were specified with "day seconds". It then checks if the given interval is spanning 'now' with the added complexity if we want to check 22:00..02:00. 

 

The other ways to represent time is in epoch, that is time in seconds since January 1971.

This is what is returned by Lua's built in function os.time() and what you get in ER with the function 'ostime()'

You can also get the epoch for the last midnight with the constant 'midnight' in ER

rule("midnight+now == ostime()")

should always be true.

 

So, I changed the '..' operator in ER4 fix47 so that if the intervals given are > 3600*24 then I assume that they are epoch times and I just compare <start epoch> <= ostime() and ostime() <= <end epoch>

 

There are a couple of ways to get epoch times in ER4

ostime() returns the current time

'midnight' returns the epoch time of last midnight

'2021/3/28/15:38' returns the epoch of the given date

There is a short format where the year is left out and will default to the current year

 

So your rule can now look like

  rule("button:isOn & /05/01/00:00../10/15/00:00 => Light1:off & Light2:off")

 

The reason I can't have dates look like '05/01' is that it looks like an arithmetic division....

The '..' operator is a bit more complex behind the scene. It actually triggers the rule at the start interval and then triggers the rule at 1s after the last interval.

The reason is that a rule like this 

rule("lamp:isOn & 10:00..15:00 => log('Hupp')")

triggers when the lamp is turned on. If the interval is not right nothing happens. Then time becomes 10:00 and we would like the rule to trigger again and see if the lamp is on and the carry out the action. That's why '..' also triggers.

(It also triggers 1s after the last interval so we can use logical NOT, 

 rule("lamp:isOn & !(10:00..15:00) => log('Hupp')")

is true for intervals outside 10:00..15:00)

 

For epoch intervals I do not trigger them on start and end interval now (it requires a bit tricky coding)

This means that

rule("lamp:isOn & 05/01..10/15 => Light1:off & Light2:off")

will not trigger if the lamp is on and we go into the date interval. This rule only triggers when the lamp changes state.

 

18 hours ago, JcBorgs said:

Thanks Sjakie,

 

Have started looking into ER4 and looks promising, a list of available commands would be useful, searching though +2000 post takes some time…

 

This is a good start

• Please login or register to see this link.

  .

• Please login or register to see this link.

• Please login or register to see this link.

   (

  Please login or register to see this link.

  )

[jgab 2,642]

On 3/25/2021 at 3:59 PM, JcBorgs said:

Sorry for asking, but what are actually the main advantages of using EV4 instead of individual “normal” scenes? With EV4 aren’t you “putting all eggs in one basket”? I mean, if EV4 fails for some reason, then all of my automation that I have put into EV4 are affected, if a normal scene fails then just that scene fails.

 

Do like the concept, did use GEA a lot in my HC2. Just looking for some clarifications on what the actual benefits are compared to the risk of everything failing. 

This is a good question.

What could happen is that Fibaro makes a change that makes ER4 crash, and it will take a long time for me to fix ER4 to run again. (I do this for free and as a hobby)

In fact, I almost never recommend people to use ER4. I do ER4 for myself, but I do value other people use it as it helps me evolve ER (and find bugs.  )

 

However, that is always an issue with all QAs, and even "normal" scenes. Fibaro can make changes that requires "normal" scenes and QAs to change their code too...

On the other hand, I have tried to code around known bugs and I have tried to keep rules compatible between HC2 and HC3 to some degree - so for some it have been easier than just rely on "normal" scenes.

 

ER4 can easily be divided up into several QAs that can easily communicate with each other. I have 3-4 ER4 running. One for lights, one for alarms, one for presence, and one for "experimenting".

 

The advantage is of course that rules are compact and easy to read compared to coding it from scratch.

I also really dislike Scene's conditions model and people are constantly reporting problems with it.

 

If Fibaro would do something really bad that makes ER4 impossible to run on the HC3 I have also coded a

Please login or register to see this link.

that can run ER4, so I will then move everything offline and only use the HC3 as a zwave gateway. That's my personal fallback plan 

Edited March 27, 2021 by jgab

[Sjakie 156]

@jgab, welcome back teacher!!

 

//Sjakie

[JcBorgs 52]

2 hours ago, jgab said:

Ok, dates have been a bit neglected when it comes to comparing intervals.

Let me give you some background.

When ER sees 12:35 it is translated to 12*3600+35*60. We make it into seconds, it's done when the rule is "compiled".

There is a 'now' constant in ER rules that is the current time in the same format, so if time is 18:00 then now is 18*3600+0*60

 

The '..' operator would assume that the intervals were specified with "day seconds". It then checks if the given interval is spanning 'now' with the added complexity if we want to check 22:00..02:00. 

 

The other ways to represent time is in epoch, that is time in seconds since January 1971.

This is what is returned by Lua's built in function os.time() and what you get in ER with the function 'ostime()'

You can also get the epoch for the last midnight with the constant 'midnight' in ER

rule("midnight+now == ostime()")

should always be true.

 

So, I changed the '..' operator in ER4 fix47 so that if the intervals given are > 3600*24 then I assume that they are epoch times and I just compare <start epoch> <= ostime() and ostime() <= <end epoch>

 

There are a couple of ways to get epoch times in ER4

ostime() returns the current time

'midnight' returns the epoch time of last midnight

'2021/3/28/15:38' returns the epoch of the given date

There is a short format where the year is left out and will default to the current year

 

So your rule can now look like

  rule("button:isOn & /05/01/00:00../10/15/00:00 => Light1:off & Light2:off")

 

The reason I can't have dates look like '05/01' is that it looks like an arithmetic division....

The '..' operator is a bit more complex behind the scene. It actually triggers the rule at the start interval and then triggers the rule at 1s after the last interval.

The reason is that a rule like this 

rule("lamp:isOn & 10:00..15:00 => log('Hupp')")

triggers when the lamp is turned on. If the interval is not right nothing happens. Then time becomes 10:00 and we would like the rule to trigger again and see if the lamp is on and the carry out the action. That's why '..' also triggers.

(It also triggers 1s after the last interval so we can use logical NOT, 

 rule("lamp:isOn & !(10:00..15:00) => log('Hupp')")

is true for intervals outside 10:00..15:00)

 

For epoch intervals I do not trigger them on start and end interval now (it requires a bit tricky coding)

This means that

rule("lamp:isOn & 05/01..10/15 => Light1:off & Light2:off")

will not trigger if the lamp is on and we go into the date interval. This rule only triggers when the lamp changes state.

 

This is a good start

 

• Please login or register to see this link.

  .

• Please login or register to see this link.

• Please login or register to see this link.

   (

  Please login or register to see this link.

  )

Thank you so much for the detailed explanation, makes it really easy to understand how to work with dates. Will try it out during the day and see if it work in my rule.

 

Could the month(‘sting’) be used as an alternative? Or is it not possible to use range in that type of string?

  rule("button:isOn & month(‘03..10’) => Light1:off & Light2:off")

 

 

[JcBorgs 52]

2 hours ago, jgab said:

This is a good question.

What could happen is that Fibaro makes a change that makes ER4 crash, and it will take a long time for me to fix ER4 to run again. (I do this for free and as a hobby)

In fact, I almost never recommend people to use ER4. I do ER4 for myself, but I do value other people use it as it helps me evolve ER (and find bugs.  )

 

However, that is always an issue with all QAs, and even "normal" scenes. Fibaro can make changes that requires "normal" scenes and QAs to change their code too...

On the other hand, I have tried to code around known bugs and I have tried to keep rules compatible between HC2 and HC3 to some degree - so for some it have been easier than just rely on "normal" scenes.

 

ER4 can easily be divided up into several QAs that can easily communicate with each other. I have 3-4 ER4 running. One for lights, one for alarms, one for presence, and one for "experimenting".

 

The advantage is of course that rules are compact and easy to read compared to coding it from scratch.

I also really dislike Scene's conditions model and people are constantly reporting problems with it.

 

If Fibaro would do something really bad that makes ER4 impossible to run on the HC3 I have also coded a

Please login or register to see this link.

that can run ER4, so I will then move everything offline and only use the HC3 as a zwave gateway. That's my personal fallback plan 

See that you are from Sweden, same here, where are you located?

 

I will for sure give ER4 a try, did really like GEA on the HC2 and this seems even better. Already have a fully operational automation of my home with a combination of Block and LUA scenes, think I start with moving as many as possible into ER4 and then just disable the Block and LUA scenes but keeps them as a fall back plan if ER4 for some reason would fail in the future.

 

Have seen somewhere a reference to a wiki for Event Runner, but can’t find it. Does it still exist and are available to others?

 

 

Edited March 27, 2021 by JcBorgs

[jgab 2,642]

1 hour ago, JcBorgs said:

Thank you so much for the detailed explanation, makes it really easy to understand how to work with dates. Will try it out during the day and see if it work in my rule.

 

Could the month(‘sting’) be used as an alternative? Or is it not possible to use range in that type of string?

  rule("button:isOn & month(‘03..10’) => Light1:off & Light2:off")

month() works for whole months.

rule("button:isOn & month(‘mar-jun’) => Light1:off & Light2:off")

rule("button:isOn & month(‘3-6’) => Light1:off & Light2:off")

Is true for March to June

rule("button:isOn & month(‘mar,jun-oct’) => Light1:off & Light2:off")

Is true for March or June to October.

It only work for whole month and unfortunately we can't combine it with a day.

1 hour ago, JcBorgs said:

See that you are from Sweden, same here, where are you located?

In Stockholm

1 hour ago, JcBorgs said:

 

I will for sure give ER4 a try, did really like GEA on the HC2 and this seems even better. Already have a fully operational automation of my home with a combination of Block and LUA scenes, think I start with moving as many as possible into ER4 and then just disable the Block and LUA scenes but keeps them as a fall back plan if ER4 for some reason would fail in the future.

It's always good to have a fallback plan...

1 hour ago, JcBorgs said:

Have seen somewhere a reference to a wiki for Event Runner, but can’t find it. Does it still exist and are available to others?

No, I think someone tried to do something in Korean.

It would be nice if Fibaro supported wikis - forum thread is not good for documentation.

If someone wants to maintain a wiki somewhere for EventRunner I'm happy to contribute.

[JcBorgs 52]

All went good and then suddenly BIG problem......

 

All rules that are triggered by a sensor work just fine, as an example:

  rule("door:isOpen => Light1:on")

 

But all rules that should be triggered by a certain time or sunset/sunrise have just stoped to work, as an example:

 rule("@20:15 => Light2:off")

 

Nothing happens and nothing is logged

 

Have tried with removing the EV4 (including the Global Variable it creates) rebooted the HC3 and then reinstall EV4 again, but no change.

Version of EV4 is: EventRunner4 v0.5fix47

 

Did create a simple Block scene that does the same as the rule with Light2 above and that worked just fine.

 

 

 

 

[petrkl12 228]

13 minutes ago, JcBorgs said:

All went good and then suddenly BIG problem......

 

All rules that are triggered by a sensor work just fine, as an example:

  rule("door:isOpen => Light1:on")

 

But all rules that should be triggered by a certain time or sunset/sunrise have just stoped to work, as an example:

 rule("@20:15 => Light2:off")

 

Nothing happens and nothing is logged

 

Have tried with removing the EV4 (including the Global Variable it creates) rebooted the HC3 and then reinstall EV4 again, but no change.

Version of EV4 is: EventRunner4 v0.5fix47

 

Did create a simple Block scene that does the same as the rule with Light2 above and that worked just fine.

 

 

 

 

you can try

Please login or register to see this code.

 

[JcBorgs 52]

7 minutes ago, petrkl12 said:

you can try

Please login or register to see this code.

 

Thanks for the Tip! But unfortunately it only confirms that I have an issue:

 

Here is the Output of my logg:

 

The rule gets registered as ok, then there are a lot of Incoming triggers being logged. But no "Test Time" LOG message is being logged at 20:52

 

[27.03.2021] [20:50:53] [DEBUG] [QUICKAPP789]: QA EventRunner4 - version:v0.5fix47 (QA toolbox 0.25)

[27.03.2021] [20:50:53] [DEBUG] [QUICKAPP789]: No children

[27.03.2021] [20:50:53] [DEBUG] [QUICKAPP789]: IP:192.168.1.40

[27.03.2021] [20:50:53] [TRACE] [QUICKAPP789]: Sunrise:05:29,  Sunset:18:17

[27.03.2021] [20:50:53] [DEBUG] [QUICKAPP789]: ------------------------------------- Setting up rules (main) -------------------------------------

[27.03.2021] [20:50:53] [DEBUG] [QUICKAPP789]: Rule:1[@20:52 => log('Test time')] = OK

[27.03.2021] [20:50:53] [DEBUG] [QUICKAPP789]: --------------------------------------------- Running ---------------------------------------------

[27.03.2021] [20:50:54] [DEBUG] [QUICKAPP789]: Incoming trigger2:{"property":"value","old":13.0,"type":"device","id":123,"value":12.9}

[27.03.2021] [20:50:56] [DEBUG] [QUICKAPP789]: Incoming trigger2:{"property":"power","old":138.4,"type":"device","id":727,"value":64.8}

[27.03.2021] [20:50:56] [DEBUG] [QUICKAPP789]: Incoming trigger2:{"property":"value","old":true,"type":"device","id":320,"value":false}

[27.03.2021] [20:50:56] [DEBUG] [QUICKAPP789]: Incoming trigger2:{"property":"power","old":137.9,"type":"device","id":300,"value":99.3}

[27.03.2021] [20:50:57] [DEBUG] [QUICKAPP789]: Incoming trigger2:{"property":"power","old":64.8,"type":"device","id":727,"value":112.9}

[27.03.2021] [20:50:57] [DEBUG] [QUICKAPP789]: Incoming trigger2:{"property":"lastBreached","old":1616874627,"type":"device","id":320,"value":1616874657}

[27.03.2021] [20:50:57] [DEBUG] [QUICKAPP789]: Incoming trigger2:{"property":"value","old":false,"type":"device","id":320,"value":true}

[27.03.2021] [20:50:57] [DEBUG] [QUICKAPP789]: Incoming trigger2:{"property":"power","old":99.3,"type":"device","id":300,"value":114.2}

[27.03.2021] [20:50:58] [DEBUG] [QUICKAPP789]: Incoming trigger2:{"property":"power","old":112.9,"type":"device","id":727,"value":75.9}

[27.03.2021] [20:51:01] [DEBUG] [QUICKAPP789]: Incoming trigger2:{"property":"power","old":75.9,"type":"device","id":727,"value":154.2}

[27.03.2021] [20:51:02] [DEBUG] [QUICKAPP789]: Incoming trigger2:{"property":"power","old":154.2,"type":"device","id":727,"value":66.8}

[27.03.2021] [20:51:02] [DEBUG] [QUICKAPP789]: Incoming trigger2:{"property":"power","old":114.2,"type":"device","id":300,"value":148.0}

[27.03.2021] [20:51:03] [DEBUG] [QUICKAPP789]: Incoming trigger2:{"property":"value","old":true,"type":"device","id":320,"value":false}

[27.03.2021] [20:51:03] [DEBUG] [QUICKAPP789]: Incoming trigger2:{"property":"power","old":148.0,"type":"device","id":300,"value":123.9}

[27.03.2021] [20:51:04] [DEBUG] [QUICKAPP789]: Incoming trigger2:{"property":"power","old":66.8,"type":"device","id":727,"value":126.9}

[27.03.2021] [20:51:05] [DEBUG] [QUICKAPP789]: Incoming trigger2:{"property":"power","old":123.9,"type":"device","id":300,"value":99.9}

[27.03.2021] [20:51:05] [DEBUG] [QUICKAPP789]: Incoming trigger2:{"property":"power","old":111.8,"type":"device","id":330,"value":95.0}

[27.03.2021] [20:51:05] [DEBUG] [QUICKAPP789]: Incoming trigger2:{"property":"color","old":"blue","type":"device","id":330,"value":"white"}

[27.03.2021] [20:51:09] [DEBUG] [QUICKAPP789]: Incoming trigger2:{"property":"lastBreached","old":1616874657,"type":"device","id":320,"value":1616874668}

[27.03.2021] [20:51:09] [DEBUG] [QUICKAPP789]: Incoming trigger2:{"property":"value","old":false,"type":"device","id":320,"value":true}

[27.03.2021] [20:51:18] [DEBUG] [QUICKAPP789]: Incoming trigger2:{"property":"lastBreached","old":1616873134,"type":"device","id":268,"value":1616874677}

[27.03.2021] [20:51:18] [DEBUG] [QUICKAPP789]: Incoming trigger2:{"property":"value","old":false,"type":"device","id":268,"value":true}

[27.03.2021] [20:51:20] [DEBUG] [QUICKAPP789]: Incoming trigger2:{"property":"value","old":true,"type":"device","id":268,"value":false}

[27.03.2021] [20:51:20] [DEBUG] [QUICKAPP789]: Incoming trigger2:{"property":"value","old":true,"type":"device","id":320,"value":false}

[27.03.2021] [20:51:24] [DEBUG] [QUICKAPP789]: Incoming trigger2:{"property":"lastBreached","old":1616874668,"type":"device","id":320,"value":1616874683}

[27.03.2021] [20:51:24] [DEBUG] [QUICKAPP789]: Incoming trigger2:{"property":"value","old":false,"type":"device","id":320,"value":true}

[27.03.2021] [20:51:26] [DEBUG] [QUICKAPP789]: Incoming trigger2:{"property":"power","old":126.9,"type":"device","id":727,"value":71.2}

[27.03.2021] [20:51:27] [DEBUG] [QUICKAPP789]: Incoming trigger2:{"property":"power","old":71.2,"type":"device","id":727,"value":141.9}

[27.03.2021] [20:51:28] [DEBUG] [QUICKAPP789]: Incoming trigger2:{"property":"power","old":141.9,"type":"device","id":727,"value":49.0}

[27.03.2021] [20:51:29] [DEBUG] [QUICKAPP789]: Incoming trigger2:{"property":"power","old":49.0,"type":"device","id":727,"value":137.6}

[27.03.2021] [20:51:30] [DEBUG] [QUICKAPP789]: Incoming trigger2:{"property":"power","old":137.6,"type":"device","id":727,"value":73.4}

[27.03.2021] [20:51:31] [DEBUG] [QUICKAPP789]: Incoming trigger2:{"property":"power","old":73.4,"type":"device","id":727,"value":153.8}

[27.03.2021] [20:51:32] [DEBUG] [QUICKAPP789]: Incoming trigger2:{"property":"power","old":95.0,"type":"device","id":330,"value":73.2}

[27.03.2021] [20:51:33] [DEBUG] [QUICKAPP789]: Incoming trigger2:{"property":"power","old":73.2,"type":"device","id":330,"value":91.4}

[27.03.2021] [20:51:41] [DEBUG] [QUICKAPP789]: Incoming trigger2:{"property":"energy","old":57.69,"type":"device","id":132,"value":57.79}

[27.03.2021] [20:51:53] [DEBUG] [QUICKAPP789]: Incoming trigger2:{"property":"value","old":true,"type":"device","id":320,"value":false}

[27.03.2021] [20:51:55] [DEBUG] [QUICKAPP789]: Incoming trigger2:{"property":"power","old":153.8,"type":"device","id":727,"value":75.0}

[27.03.2021] [20:51:56] [DEBUG] [QUICKAPP789]: Incoming trigger2:{"property":"power","old":75.0,"type":"device","id":727,"value":129.4}

[27.03.2021] [20:51:57] [DEBUG] [QUICKAPP789]: Incoming trigger2:{"property":"power","old":129.4,"type":"device","id":727,"value":68.1}

[27.03.2021] [20:51:59] [DEBUG] [QUICKAPP789]: Incoming trigger2:{"property":"power","old":68.1,"type":"device","id":727,"value":140.7}

[27.03.2021] [20:52:00] [DEBUG] [QUICKAPP789]: Incoming trigger2:{"property":"power","old":140.7,"type":"device","id":727,"value":62.2}

[27.03.2021] [20:52:06] [DEBUG] [QUICKAPP789]: Incoming trigger2:{"property":"power","old":62.2,"type":"device","id":727,"value":122.3}

 

 

[jwi 53]

34 minutes ago, JcBorgs said:

But all rules that should be triggered by a certain time or sunset/sunrise have just stoped to work, as an example:

 rule("@20:15 => Light2:off")

 

The same thing happened to me tonight. No lights have switched on. I thought it was me because I added a new rule.

But at 16:32 the ER4 has updated from version: v0.5fix46 to v0.5fix47.

I guess that's where the problem comes from.