Tutorial: Single scene instance / Event model

[jgab 2,642]

55 minutes ago, fastvd said:

Again. The new function does determine if the controller is online or not...but the next rule, which is supposed to restart the slave controller, then it doesn't work(((

Remove

id='$id'

in the rule, I have done it in the previous post.

[fastvd 7]

On 2/8/2023 at 1:00 PM, jgab said:

Remove

id='$id'

in the rule, I have done it in the previous post.

deleted the ID... but the reboot rule still doesn't work... here on the screen you can see that in 14.50 the main function saw that one of the controllers was false, but nothing happened after that! no further rules started...or maybe I don't understand something?

 

Please login or register to see this attachment.

[michalt 3]

I have a little gambit that I struggle to understand.

Why 2nd #lightsFrontOn event despite triggering rule Rule:12 produces turrOff when rule executes turnOn - bug maybe ?

 

Testing:
rule("post(#lightsFrontOn,+/00:00:10)")
rule("post(#outsideSafe,+/00:00:20)")
rule("post(#lightsFrontOn,+/00:00:30)")

 

Output:
[11.02.2023] [21:20:15] [DEBUG] [QUICKAPP187]: [{"type":"lightsFrontOn"}]>>'Rule:12[#lightsFrontOn => outside.roof:on & outside.nightLights:on & outside.mainDoors:o...]'
[11.02.2023] [21:20:15] [DEBUG] [QUICKAPP187]: fibaro.call(153,"turnOn") => nil
[11.02.2023] [21:20:15] [DEBUG] [QUICKAPP187]: fibaro.call(61,"turnOn") => nil
[11.02.2023] [21:20:15] [DEBUG] [QUICKAPP187]: fibaro.call(60,"turnOn") => nil
[11.02.2023] [21:20:15] [DEBUG] [QUICKAPP187]: fibaro.call(154,"turnOn") => nil
[11.02.2023] [21:20:15] [DEBUG] [QUICKAPP187]: fibaro.call(130,"turnOn") => nil
[11.02.2023] [21:20:15] [DEBUG] [QUICKAPP187]: fibaro.call(54,"turnOn") => nil
[11.02.2023] [21:20:25] [DEBUG] [QUICKAPP187]: [{"type":"outsideSafe"}]>>'Rule:16[#outsideSafe => outside.all:value = outsideLampsStateBeforeEvent]'
[11.02.2023] [21:20:25] [DEBUG] [QUICKAPP187]: fibaro.call(153,"turnOn",true) => nil
[11.02.2023] [21:20:25] [DEBUG] [QUICKAPP187]: fibaro.call(60,"turnOff",false) => nil
[11.02.2023] [21:20:25] [DEBUG] [QUICKAPP187]: fibaro.call(154,"turnOff",false) => nil
[11.02.2023] [21:20:25] [DEBUG] [QUICKAPP187]: fibaro.call(130,"turnOff",false) => nil
[11.02.2023] [21:20:25] [DEBUG] [QUICKAPP187]: fibaro.call(54,"turnOff",false) => nil
[11.02.2023] [21:20:25] [DEBUG] [QUICKAPP187]: fibaro.call(48,"turnOff",false) => nil
[11.02.2023] [21:20:25] [DEBUG] [QUICKAPP187]: fibaro.call(61,"turnOn",true) => nil
[11.02.2023] [21:20:35] [DEBUG] [QUICKAPP187]: [{"type":"lightsFrontOn"}]>>'Rule:12[#lightsFrontOn => outside.roof:on & outside.nightLights:on & outside.mainDoors:o...]'
[11.02.2023] [21:20:35] [DEBUG] [QUICKAPP187]: fibaro.call(153,"turnOff") => nil
[11.02.2023] [21:20:35] [DEBUG] [QUICKAPP187]: fibaro.call(61,"turnOff") => nil
[11.02.2023] [21:20:35] [DEBUG] [QUICKAPP187]: fibaro.call(60,"turnOff") => nil
[11.02.2023] [21:20:35] [DEBUG] [QUICKAPP187]: fibaro.call(154,"turnOff") => nil
[11.02.2023] [21:20:35] [DEBUG] [QUICKAPP187]: fibaro.call(130,"turnOff") => nil
[11.02.2023] [21:20:35] [DEBUG] [QUICKAPP187]: fibaro.call(54,"turnOff") => nil

 

Thanks in advance!
MT

[jgab 2,642]

It looks really strange...

Can you post the whole rule 12 and the one triggering on #outsideSafe

Which rule saves outsideLampsStateBeforeEvent ?

 

8 hours ago, fastvd said:

deleted the ID... but the reboot rule still doesn't work... here on the screen you can see that in 14.50 the main function saw that one of the controllers was false, but nothing happened after that! no further rules started...or maybe I don't understand something?

 

Please login or register to see this attachment.

Ok, so you don't get the ip of boxes that are offline - which is kind of logical...

[michalt 3]

10 minut temu, jgab napisał:

It looks really strange...

Can you post the whole rule 12 and the one triggering on #outsideSafe

Which rule saves outsideLampsStateBeforeEvent ?

 

Ok, so you don't get the ip of boxes that are offline - which is kind of logical...

 

@jgab thanks for having a look.

 

The rules in detail 

rule("once(nvrsmartmotion:breached) | #frontGateOpen | #garageDoorOpen => outsideLampsStateBeforeEvent = outside.all:value") -- rule that saves the value before automation.

rule("#lightsFrontOn => outside.roof:on & outside.nightLights:on & outside.mainDoors:on & outside.front:on &outside.topFront:on & outside.right:on") -- turn on front and right 

rule("trueFor(nvrsmartmotion:isOff,00:00:30,sunset+00:30..sunrise-00:45) & frontGate:value == 0 & garageDoor:value == 0 => post(#outsideSafe)") -- rule that triggers restore

rule("#outsideSafe => outside.all:value = outsideLampsStateBeforeEvent") -- rule that restore state after automation event expires. 

 

There is one other rule that might be issue 

rule("outsideLampsStateBeforeEvent = outside.all:value") -- save lamps state before on startup

 

 

 

[fastvd 7]

11 hours ago, jgab said:

It looks really strange...

Can you post the whole rule 12 and the one triggering on #outsideSafe

Which rule saves outsideLampsStateBeforeEvent ?

 

Ok, so you don't get the ip of boxes that are offline - which is kind of logical...

no, i'm not talking about ip addresses...
I speak for the logic of how the rules work:
1) authorize on the main controller - everything is ok
2) authorize the slave - everything is ok
3) see who is offline - everything is ok
4) give the reboot command - not everything is ok

[jgab 2,642]

Yes, but you see in the log you posted that the ip address comes back as a "function: 0x...", which actually means that the value from the json returned by the api call was "null"

Edited February 12, 2023 by jgab

[fastvd 7]

5 minutes ago, jgab said:

Yes, but you see in the log you posted that the ip address comes back as a "function: 0x...", which actually means that the value from the json returned by the api call was "null"

api call was "null" - what does this mean?

[jgab 2,642]

That the call did not return the ip address of the box, because it was offline I guess.

(the json returned was "ip":null )

[jgab 2,642]

12 hours ago, michalt said:

 

@jgab thanks for having a look.

 

The rules in detail 

rule("once(nvrsmartmotion:breached) | #frontGateOpen | #garageDoorOpen => outsideLampsStateBeforeEvent = outside.all:value") -- rule that saves the value before automation.

rule("#lightsFrontOn => outside.roof:on & outside.nightLights:on & outside.mainDoors:on & outside.front:on &outside.topFront:on & outside.right:on") -- turn on front and right 

rule("trueFor(nvrsmartmotion:isOff,00:00:30,sunset+00:30..sunrise-00:45) & frontGate:value == 0 & garageDoor:value == 0 => post(#outsideSafe)") -- rule that triggers restore

rule("#outsideSafe => outside.all:value = outsideLampsStateBeforeEvent") -- rule that restore state after automation event expires. 

 

There is one other rule that might be issue 

rule("outsideLampsStateBeforeEvent = outside.all:value") -- save lamps state before on startup

 

Well, what I'm seeing from your log is kind of impossible. A x:on can't result in a fibaro.call(x,"turnOff")

so there must be some other rule kicking in turning off the lights

 

Btw, the trueFor rule has the wrong syntax, should be.

Please login or register to see this code.

 

[jgab 2,642]

22 minutes ago, jgab said:

That the call did not return the ip address of the box, because it was offline I guess.

(the json returned was "ip":null )

I have modified the post Feb 6 to check for missing ip and warn about it

 

[michalt 3]

25 minut temu, jgab napisał:

 

Well, what I'm seeing from your log is kind of impossible. A x:on can't result in a fibaro.call(x,"turnOff")

so there must be some other rule kicking in turning off the lights

 

Btw, the trueFor rule has the wrong syntax, should be.

Please login or register to see this code.

 

@jgab yes it looks odd, I prepared some test code, removed other rules to avoid interference

 

Please login or register to see this code.

  The result is the same:

[12.02.2023] [11:48:10] [DEBUG] [QUICKAPP187]: --------------------------------------------- Running ---------------------------------------------

[12.02.2023] [11:48:15] [DEBUG] [QUICKAPP187]: [{"type":"A0"}]>>'Rule:1[#A0 => outside.nightLights:on]'

[12.02.2023] [11:48:15] [DEBUG] [QUICKAPP187]: fibaro.call(61,"turnOn") => nil

[12.02.2023] [11:48:20] [DEBUG] [QUICKAPP187]: [{"type":"A1"}]>>'Rule:2[#A1 => outsideLampsStateBeforeEvent = outside.all:value]'

[12.02.2023] [11:48:25] [DEBUG] [QUICKAPP187]: [{"type":"A2"}]>>'Rule:3[#A2 => outside.roof:on & outside.nightLights:on & outside.mainDoors:on & outside...]'

[12.02.2023] [11:48:25] [DEBUG] [QUICKAPP187]: fibaro.call(153,"turnOn") => nil

[12.02.2023] [11:48:25] [DEBUG] [QUICKAPP187]: fibaro.call(61,"turnOn") => nil

[12.02.2023] [11:48:25] [DEBUG] [QUICKAPP187]: fibaro.call(60,"turnOn") => nil

[12.02.2023] [11:48:25] [DEBUG] [QUICKAPP187]: fibaro.call(154,"turnOn") => nil

[12.02.2023] [11:48:25] [DEBUG] [QUICKAPP187]: fibaro.call(130,"turnOn") => nil

[12.02.2023] [11:48:25] [DEBUG] [QUICKAPP187]: fibaro.call(54,"turnOn") => nil

[12.02.2023] [11:48:30] [DEBUG] [QUICKAPP187]: [{"type":"A3"}]>>'Rule:4[#A3 => outside.all:value = outsideLampsStateBeforeEvent]'

[12.02.2023] [11:48:30] [DEBUG] [QUICKAPP187]: fibaro.call(153,"turnOff",false) => nil

[12.02.2023] [11:48:30] [DEBUG] [QUICKAPP187]: fibaro.call(60,"turnOff",false) => nil

[12.02.2023] [11:48:30] [DEBUG] [QUICKAPP187]: fibaro.call(154,"turnOff",false) => nil

[12.02.2023] [11:48:31] [DEBUG] [QUICKAPP187]: fibaro.call(130,"turnOff",false) => nil

[12.02.2023] [11:48:31] [DEBUG] [QUICKAPP187]: fibaro.call(54,"turnOff",false) => nil

[12.02.2023] [11:48:31] [DEBUG] [QUICKAPP187]: fibaro.call(48,"turnOff",false) => nil

[12.02.2023] [11:48:31] [DEBUG] [QUICKAPP187]: fibaro.call(61,"turnOn",true) => nil

[12.02.2023] [11:48:35] [DEBUG] [QUICKAPP187]: [{"type":"A2"}]>>'Rule:3[#A2 => outside.roof:on & outside.nightLights:on & outside.mainDoors:on & outside...]'

[12.02.2023] [11:48:35] [DEBUG] [QUICKAPP187]: fibaro.call(153,"turnOff") => nil

[12.02.2023] [11:48:35] [DEBUG] [QUICKAPP187]: fibaro.call(61,"turnOff") => nil

[12.02.2023] [11:48:35] [DEBUG] [QUICKAPP187]: fibaro.call(60,"turnOff") => nil

[12.02.2023] [11:48:35] [DEBUG] [QUICKAPP187]: fibaro.call(154,"turnOff") => nil

[12.02.2023] [11:48:35] [DEBUG] [QUICKAPP187]: fibaro.call(130,"turnOff") => nil

[12.02.2023] [11:48:35] [DEBUG] [QUICKAPP187]: fibaro.call(54,"turnOff") => nil

 

However if you remove the #A3 from the call all seams to work normalny and lamps get on. 

It seams to me that there must be some kind of a bug/interference/race condition when setting state of light by array like in #A3

[jgab 2,642]

2 hours ago, michalt said:

@jgab yes it looks odd, I prepared some test code, removed other rules to avoid interference

 

Please login or register to see this code.

  The result is the same:

[12.02.2023] [11:48:10] [DEBUG] [QUICKAPP187]: --------------------------------------------- Running ---------------------------------------------

[12.02.2023] [11:48:15] [DEBUG] [QUICKAPP187]: [{"type":"A0"}]>>'Rule:1[#A0 => outside.nightLights:on]'

[12.02.2023] [11:48:15] [DEBUG] [QUICKAPP187]: fibaro.call(61,"turnOn") => nil

[12.02.2023] [11:48:20] [DEBUG] [QUICKAPP187]: [{"type":"A1"}]>>'Rule:2[#A1 => outsideLampsStateBeforeEvent = outside.all:value]'

[12.02.2023] [11:48:25] [DEBUG] [QUICKAPP187]: [{"type":"A2"}]>>'Rule:3[#A2 => outside.roof:on & outside.nightLights:on & outside.mainDoors:on & outside...]'

[12.02.2023] [11:48:25] [DEBUG] [QUICKAPP187]: fibaro.call(153,"turnOn") => nil

[12.02.2023] [11:48:25] [DEBUG] [QUICKAPP187]: fibaro.call(61,"turnOn") => nil

[12.02.2023] [11:48:25] [DEBUG] [QUICKAPP187]: fibaro.call(60,"turnOn") => nil

[12.02.2023] [11:48:25] [DEBUG] [QUICKAPP187]: fibaro.call(154,"turnOn") => nil

[12.02.2023] [11:48:25] [DEBUG] [QUICKAPP187]: fibaro.call(130,"turnOn") => nil

[12.02.2023] [11:48:25] [DEBUG] [QUICKAPP187]: fibaro.call(54,"turnOn") => nil

[12.02.2023] [11:48:30] [DEBUG] [QUICKAPP187]: [{"type":"A3"}]>>'Rule:4[#A3 => outside.all:value = outsideLampsStateBeforeEvent]'

[12.02.2023] [11:48:30] [DEBUG] [QUICKAPP187]: fibaro.call(153,"turnOff",false) => nil

[12.02.2023] [11:48:30] [DEBUG] [QUICKAPP187]: fibaro.call(60,"turnOff",false) => nil

[12.02.2023] [11:48:30] [DEBUG] [QUICKAPP187]: fibaro.call(154,"turnOff",false) => nil

[12.02.2023] [11:48:31] [DEBUG] [QUICKAPP187]: fibaro.call(130,"turnOff",false) => nil

[12.02.2023] [11:48:31] [DEBUG] [QUICKAPP187]: fibaro.call(54,"turnOff",false) => nil

[12.02.2023] [11:48:31] [DEBUG] [QUICKAPP187]: fibaro.call(48,"turnOff",false) => nil

[12.02.2023] [11:48:31] [DEBUG] [QUICKAPP187]: fibaro.call(61,"turnOn",true) => nil

[12.02.2023] [11:48:35] [DEBUG] [QUICKAPP187]: [{"type":"A2"}]>>'Rule:3[#A2 => outside.roof:on & outside.nightLights:on & outside.mainDoors:on & outside...]'

[12.02.2023] [11:48:35] [DEBUG] [QUICKAPP187]: fibaro.call(153,"turnOff") => nil

[12.02.2023] [11:48:35] [DEBUG] [QUICKAPP187]: fibaro.call(61,"turnOff") => nil

[12.02.2023] [11:48:35] [DEBUG] [QUICKAPP187]: fibaro.call(60,"turnOff") => nil

[12.02.2023] [11:48:35] [DEBUG] [QUICKAPP187]: fibaro.call(154,"turnOff") => nil

[12.02.2023] [11:48:35] [DEBUG] [QUICKAPP187]: fibaro.call(130,"turnOff") => nil

[12.02.2023] [11:48:35] [DEBUG] [QUICKAPP187]: fibaro.call(54,"turnOff") => nil

 

However if you remove the #A3 from the call all seams to work normalny and lamps get on. 

It seams to me that there must be some kind of a bug/interference/race condition when setting state of light by array like in #A3

yep, there was a bug introduced some time ago that indirectly got triggered by a value restore... tricky tricky.

I pushed v0.993.

Thanks for finding the bug!

[Sjakie 156]

Jan, I have a problem perhaps you can push me in the right direction.

It appear also in my old version of my previous house so I started from zero after factory restore and the same kind of error is back.

 

In HT a lot or perhaps all devices will give an error in ER4 and I have no clue how to solve.

Fa keuken.deur ID=37 in Devices you can see door isOpen or is closed 

In scene HomeTable debug:

Please login or register to see this code.

In history I see:

safe     37     deur       appartement/keuken    systeem       14:27

ER:

Please login or register to see this code.

Thanks in advance for spending your time.

Edited February 12, 2023 by Sjakie

[michalt 3]

Godzinę temu, jgab napisał:

yep, there was a bug introduced some time ago that indirectly got triggered by a value restore... tricky tricky.

I pushed v0.993.

Thanks for finding the bug!

 

OMG that was quick @jgab thanks, I did some quick test and it seams fine!

P.S. Thanks for pointing syntax issue as well.

[jgab 2,642]

2 hours ago, Sjakie said:

Jan, I have a problem perhaps you can push me in the right direction.

It appear also in my old version of my previous house so I started from zero after factory restore and the same kind of error is back.

 

In HT a lot or perhaps all devices will give an error in ER4 and I have no clue how to solve.

Fa keuken.deur ID=37 in Devices you can see door isOpen or is closed 

In scene HomeTable debug:

Please login or register to see this code.

In history I see:

safe     37     deur       appartement/keuken    systeem       14:27

ER:

Please login or register to see this code.

Thanks in advance for spending your time.

You need to show me the code where you read in the HT

[petrkl12 228]

5 hours ago, jgab said:

yep, there was a bug introduced some time ago that indirectly got triggered by a value restore... tricky tricky.

I pushed v0.993.

Thanks for finding the bug!

@jgab v0.993 is not visible via QA updater

[Sjakie 156]

Jan,

You need to show me the code where you read in the HT>> Was indeed a push in the right direction!

Thanks!!!

 

0.991 is my latest

[jgab 2,642]

17 hours ago, petrkl12 said:

@jgab v0.993 is not visible via QA updater

It took almost 24 hour before it showed up... now it's there.

 

This is strange, 

I push a new manifest (MANIFEST.json) to my GitHub repo.

Please login or register to see this link.

and I can see it almost immediately if I go to the url above with my browser.

In the QA I fetch the manifest with a net.HTTPClient:request(...)

and it usually takes around ~2-5minutes before I get the new version of the file..

This time it took almost 24 hours...

So, is it GitHub or the HC3 that I should blame?

[Sjakie 156]

Jan, In updater I see now your new version. Thanks.

- is it possible if you select one of your excellent QA's it will automatically select the latest version?

   now I need every time to select the latest (and greatest) version.

-can it stay on the QA instead of automatically jumps to the next QA

Thanks in advance

ps 2 QA's don't show the latest version number after being updated

 

Blame us for being to greedy to get the latest and greatest ER version!!!