EventRunner 5

[jgab 2,641]

7 hours ago, bonhomme said:

Hi again

 

I'm trying to set up some rules to synchronise state between devices. For context, these devices are roller blinds that are not directly connected to the Fibaro, they are Somfy so they are directly controlled by a Somfy bridge, which is linked to the HC3 via a Skaro Automation Bridge. Basically every device is a QA and the functions like "up", "down" etc are mapped to API calls against the Automation Bridge (which then somehow sends them over the Somfy cloud API in a way that is not transparent to me). 

 

In a room I have 7 blinds in total, and each of them have individual devices. When called as a group (e.g. {blind1, blind2}:up) the Somfy bridge will loop through them and send the commands with some delay between each blind. This is OK most of the time except when you are trying to precisely position them using timing. However, it's also possible to group blinds at the radio level by associating a group of blinds with one channel on the bridge (similar to how groups work on a standard Somfy multichannel remote) - in this case it's not that the remote or bridge knows anything about a group, it simply sends out a frame with a command and a channel number and controllers in radio range that are programmed to respond to that channel number will execute the command. This method always achieves near-perfect sync between multiple blinds.

 

So in my case I have both the individual devices, and a group device which is exported by the bridge (the bridge doesn't know the difference - for it, that group is just another blind). 

 

(Aside: you can also create groups on the Somfy bridge but those still have the laggy loop behaviour so aren't helpful or relevant here). 

 

What I want to do is synchronise the status between the grouped device and individual device, so for example if all blinds are open, and I "close" the group device, the 3 individual devices in the group have their status changed to "closed" without sending another "close" command to them. 

 

I've tried

 

Please login or register to see this code.

This generates a runtime error:

 

Please login or register to see this code.

 

I have also tried using setValue(0) instead of updateProperty, with the same result, even if I go to the quickapps and add a definition for setValue

 

Please login or register to see this code.

 

Any ideas?

Try

... _int_living_group_1_4_5:prop={'value',0}

2 hours ago, lux said:

Please login or register to see this code.

@jgabIs this rule still retained？

Yes, it should work. Any issues?

[bonhomme 4]

22 hours ago, jgab said:

Try

... _int_living_group_1_4_5:prop={'value',0}

That worked, thanks!

 

However, now it is working it has shown up a design error in the rules on my part.

 

When I open or close the grouped device (_int_living_group_1_4_5), the other 3 update correctly.

 

When I open or close one of the member blinds individually, it bumps the status of the grouped device (following the logic "if any of the individual blinds are open, it should be open, if all of them are closed it should be closed"), and that in turn updates the statuses of the other two individual blinds (I don't think it sends them the corresponding command so it puts them out of sync. 

 

Is there a better way to do this - maybe changing the trigger to be based on an event rather than the status?

[jgab 2,641]

On 1/29/2024 at 11:37 PM, bonhomme said:

 

Please login or register to see this code.

 

So it looks something like this now?

You have an "ER" group  - _int_living_group_1_4_5

and you have a "linked radio" group - blinds.living.living_group_1_4_5

 

Both individual blinds and the radio group are represented by QAs...?

 

Do you get feedback on the individual blinds (:isClosed) ?

Do you not get feedback from the radio group (you said it was fire and forget?)

blinds.living.living_group_1_4_5:close

should result in that the individual blinds (QAs) report :isClose o?

 

[bonhomme 4]

2 hours ago, jgab said:

You have an "ER" group  - _int_living_group_1_4_5

and you have a "linked radio" group - blinds.living.living_group_1_4_5

Correct. I also have the individual devices e.g. blinds.living.living_1, blinds.living.living_2 etc.

 

2 hours ago, jgab said:

Both individual blinds and the radio group are represented by QAs...?

Also correct.

2 hours ago, jgab said:

Do you get feedback on the individual blinds (:isClosed) ?

Do you not get feedback from the radio group (you said it was fire and forget?)

I get feedback* from both, the quickapps are identical except one controls a group and the others control an individual blind each. However, there is a footnote on "feedback" - the Somfy RTS protocol doesn't allow for the blind controller to report its current position. The Automation Bridge app simulates open/closed and reports it in a way that the HC3 picks it up (not sure of the mechanics of this actually, there's no code related to it in the Lua that it generates - these quickapps are automatically created by Automation Bridge although nothing stops me editing them afterwards). Within the Automation Bridge UI, there is a way you can change the 'status' of a blind manually in case it is out of sync (without having to actually open or close physical blinds). However, that's not accessible programmatically AFAIK, that's a GUI in a web page.

 

However, from the HC3's point of view, it's as if the devices are reporting their status? Actually I don't know if that is what is happening, or if the HC3 does it internally. 

 

If I do blinds.living.living_group_1_4_5:close, the individual blind statuses are updated by the rules. 

If I then do, e.g. blinds.living.living_1:open then blinds.living.living_group_1_4_5 status is set to :isOpen by the rule 

Please login or register to see this code.

However, this causes a chain reaction because then this change in turn triggers

Please login or register to see this code.

Which also sets blinds.living.living_4 and blinds.living.living_5 to :isOpen, when they are not - putting the virtual status out of sync with the physical reality.

[ChristianSogaard 71]

Jan I have really strange things in my HC3 these days,

My Velux windows has started opening at strange times,

Some log searching - and it shows its a power trigger that triggers a EV5 rule

 

Please login or register to see this spoiler.

Please login or register to see this attachment.

 

 

this is new- these rules has been working since ev4 (with minor adjustment to EV5)

 

has something changes ?

It seems that the power rules now triggers at both the current usage and "total report" 

 

 

 

 

[jgab 2,641]

1 hour ago, ChristianSogaard said:

Jan I have really strange things in my HC3 these days,

My Velux windows has started opening at strange times,

Some log searching - and it shows its a power trigger that triggers a EV5 rule

 

Please login or register to see this spoiler.

Can you post the rule?

[ChristianSogaard 71]

12 hours ago, jgab said:

Can you post the rule?

its in the post  just unhide 

[jgab 2,641]

13 hours ago, ChristianSogaard said:

Jan I have really strange things in my HC3 these days,

My Velux windows has started opening at strange times,

Some log searching - and it shows its a power trigger that triggers a EV5 rule

 

Please login or register to see this spoiler.

 

The rule trigger on 1129's 'value' property. Which I assume is current usage.

Either 1129 fluctuates a lot (have temporary spikes) and that is what you see in the event log - and that would also trigger the ER rule. I think I saw someone else in the forum talking about strange power spikes...

 

- or the event log shows both current and total value in two entries (the log don't tell us from what property the value comes from), and in that case ER should only trigger on the current value (the lower value in the log).

 

[ChristianSogaard 71]

4 hours ago, jgab said:

 

The rule trigger on 1129's 'value' property. Which I assume is current usage.

Either 1129 fluctuates a lot (have temporary spikes) and that is what you see in the event log - and that would also trigger the ER rule. I think I saw someone else in the forum talking about strange power spikes...

 

- or the event log shows both current and total value in two entries (the log don't tell us from what property the value comes from), and in that case ER should only trigger on the current value (the lower value in the log).

 

Its indeed strange power spikes - 90.000 (90Kw) is a lot and not possible at all. Pretty sure it came very recently.
ill search the forum for strange power spikes, and perhaps create a support case

Edited February 3, 2024 by ChristianSogaard
Typo

[jgab 2,641]

8 hours ago, ChristianSogaard said:

Its indeed strange power spikes - 90.000 (90Kw) is a lot and not possible at all. Pretty sure it came very recently.
ill search the forum for strange power spikes, and perhaps create a support case

You could in the rule check if the value is over some unrealistic value and ignore it...

[Neo Andersson 230]

@jgabHello Jan

Can we get in rule, all climateZone's IDs? I want to set all of them to OFF mode.

[Neo Andersson 230]

@jgab Another question

 

Trying to utilize async function engine

 

I have a function shs.getWeatherData() that takes the daynumber argument (how far ofr the future the forecast should go) and returns a table from weather servers. It is working nicely, tested with several QAs for years.

I want to use it in a rule.

But this doesn't work

 

Please login or register to see this code.

 

 Runtime: calling 'getAsyncWdata' - ./include/engine.lua:404: async callback not asyncronous called
@09:00 => local w = getAsyncWdata(); 
                    ^^^^^^^^^^^^^

[jgab 2,641]

But is 

Please login or register to see this code.

asynchronous? or does it return the value directly?

If it was asynchronous it would probably have it's own calllback?

 

If it's synchronous it's just

Please login or register to see this code.

 

Edited February 6, 2024 by jgab

[jgab 2,641]

3 hours ago, Neo Andersson said:

@jgabHello Jan

Can we get in rule, all climateZone's IDs? I want to set all of them to OFF mode.

Please login or register to see this code.

 

[Neo Andersson 230]

2 hours ago, jgab said:

If it was asynchronous it would probably have it's own calllback?

It is a simple http.get call with a success function callback

 

 

17 minutes ago, jgab said:

Please login or register to see this code.

So i can use cid inside a fibaro.climateModeMode(id,mode) call? Will it set all of them to OFF mode? like

Please login or register to see this code.

 

Edited February 6, 2024 by Neo Andersson

[jgab 2,641]

22 minutes ago, Neo Andersson said:

It is a simple http.get call with a success function callback

Please login or register to see this code.

 

 

22 minutes ago, Neo Andersson said:

 

 

So i can use cid inside a fibaro.climateModeMode(id,mode) call? Will it set all of them to OFF mode? like

Please login or register to see this code.

 

No ,you have to loop over the ids.

[ChristianSogaard 71]

On 11/18/2023 at 11:24 AM, jgab said:

Debugging

 

When rules don't compile (at startup), hopefully ER5 will give some indication what is wrong with the rule.

Giving good error messages are more difficult than one would expect so sometimes it can be difficult to know - please feel free to post the problem in this forum and I can see if I can improve the error detection for the specific problem you encounter.

 

When rules are running, they can still misbehave and not do what is expected of them. 

Then there is a couple of approaches that can be tested:

 

Inspect rule triggers

If the rule doesn't trigger on events in a way that is expected - check what events the rule actually triggers on.

Add .info() at the end of the rule definition to get a console log of what triggers the rule

Ex.

Please login or register to see this code.

It gives

Please login or register to see this code.

Here we see that the rule will trigger on the global-variable event for a global with the name 'Day'.

It also triggers on device id 77 changing the property 'value' - which happens when the devices goes on and off.

There is also a daily that is set to 15:15 every day.

The Timer entry is just the timers that are active for the rule. In this case for the Daily on the line before - so we don't need to concern ourselves with that (or the fact that the sun goes down in Stockholm 15:15 this time of the year)

 

Look at the events - these are the only events that will trigger the rule - are we ok with that?

Note, that in some cases we may see more events than what we really are interested in.

In the example above, we want to trigger the rule at sunset and no more, but it also triggers on device 77 and the global variable 'Day'. In this specific example that doesn't matter because if it's not sunset the condition will not be true and the action not run. But beware that you may see in the console log that the rule was triggered by the device or the global.

In most cases this doesn't matter and it makes the rule clear to keep all the conditions tests on the left side of the '=>'.

However, we could move the device and global test to the right hand side of the '=>'. Then they would not be triggers of the rule.

Please login or register to see this code.

Please login or register to see this code.

 

Enable debug flags 

er.debug.ruleTrue = true

er.debug.ruleFalse = true

These flags are enabled by default and will log a true or false if the condition of a rule succeeds. In production it can be convenient to disable these flags so the console log becomes a little cleaner.

 

However, we can enable the flags for individual rules - the rule we have problem with.

Please login or register to see this code.

Here we have 2 rules that trigger on the event #fopp. The first rule succeeds and the second will fail (5 is not equal to 2). 

We add the options to log true and false condition (assuming it's disabled globally).

IN the output we see

 

[18.11.2023] [14:01:54] [TRACE ] [QUICKAPP5000]: Posting #fopp{} at Sat Nov 18 14:01:54 2023 (ER)

[18.11.2023] [14:01:54] [TRACE ] [ER5000 ]: [Rule:1:1]>> TRUE #fopp{} -> #fopp => log('fopp1')

[18.11.2023] [14:01:54] [DEBUG ] [QUICKAPP5000]: fopp1

[18.11.2023] [14:01:54] [TRACE ] [ER5000 ]: [Rule:2:1]>> FALSE #fopp{} -> #fopp & 5==2 => log('fopp2')

 

Here we see that rule 1 condition succeeded - the green TRUE,

and the rule 2 condition failed - the red FALSE.

We also see the event that triggered the rule - the #fopp{} before the arrow '->'

This will give us reasonable good idea why the rule failed or not.

 

It can still be so that the condition is TRUE, but the action after the '=>' is faulty. That needs o be checked differently...

 

er.debug.sourceTrigger = false 

er.debug.refreshEvents = false

The sourceTrigger and refreshEvents debug flags works globally and not per individual rules. They are set to false as default.

er.debug.sourceTrigger set to true will log all sourceTrigger posted to the system. It can be useful to see that devices and globals are generating sourceTriggers when they change state. 

 

er.debug.refreshEvents set to true will log all incoming events from api /refreshStates. It's kind of a lower level sourceTrigger and will show some more info. If you don't get an expected sourceTrigger it can be worthwhile checking if the refreshEvents are coming in...

 

er.settings.logFibaro = false

er.settings.logApi = false

er.settings.logFibaro set to true will log all fibaro.call's done by the ER engine.

A device:on in a rule will translate to a fibaro.call(device,"turnOn"). It can be worth making sure that the actions you have specified does the expected calls to the HC3.

er.settings.logApi set to true will log all api.* calls done by the ER engine. Can also be good to see what is communicated to the HC3.

 

 

Add your own debug checks

If the condition doesn't become true in a way that we expect, we can add log statements to the condition part.

Ex.

Please login or register to see this code.

and we add a log statement to check the temperature

Please login or register to see this code.

Note that we need to add the log statement before we test it so it will be logged even if the condition is false.

Note also that log() returns the string so it is always true, which allow us to add it with &'s in the condition test.

 

It can be a bit boring to wait until sunset before see the result, so we can force to triggering of the rule by adding .start() to the rule definition.

Please login or register to see this code.

 

Trigger rules with delayed expressions

We can sometimes trigger our rules "manually" by changing device states.

Ex. if we have a switch and a rule that triggers on the switch

Please login or register to see this code.

we can explicitly trigger that rule a second after we started it by turning on the switch

Please login or register to see this code.

 

A sensor we can't turn on, but we can work around that

Please login or register to see this code.

Here we create a trigger variable 'testTrigger' and make our rule trigger on either the trigger var or the sensor being breached.

By setting the trigger variable to true we trigger our rule and can watch the actions...

 

However, it can be better to create a simulated device to test these kind of rules...

 

Use simulated devices with rule

We can easily make simulated devices to test with

Please login or register to see this code.

They create devices of type com.fibaro.binarySwitch and com.fibaro.multilevelSwitch and their return the deviceId assigned to them.

The simulated devices only exists inside ER5 and are not visible to other QAs on the HC3.

The difference between them is that the binary device has a boolean true/false value and the multilevel a number 0-99

We can use them as sensors in our rules too.

 

Ex.

Please login or register to see this code.

Testing this way and making sure it works, we can then switch the sensor id to our real sensor.

 

A more complex example.

 

We have some rules to turn on light in bathroom if sensor in bathroom is breached. There are also logic to not turn off the light if the door is closed and the sensor becomes false (we assume that no one can escape a closed room, so there's still someone there)

Please login or register to see this code.

Redefine the sensors and lights 'Livingbath_x" with simulated binaryDevices.

er.createBinaryDevice() creates a simulated binary device and returns the assigned deviceId.

 

Then we have the bathroom rules as usual - now using our simulated devices.

 

Thence setup a remote/keyfob so key presses toggles the door and motion sensor and logs a message what new state they have.

We also setup debug options so the console output is not so noisy

Please login or register to see this code.

Then we can lean back, press the remote to toggle the state of the door and the sensor and see how the rules are triggered...

Without having to run to the bathroom and open and close any door or breach any sensor  

 

Run rule at simulated time

If we know that sunset happens at 15:15, we can set a simulated time for ER.

Please login or register to see this code.

It will set a "fake" time for ER to 15:14:50, and we just need to wait 10s before the rule hopefully triggers.

 

The simulated time is used by all ER functionality (incl. os.time() ) - However, it doesn't change the real time of the HC3.

 

Speed up time for scheduled rules

An experimental feature is to run ER5 faster than realtime.

If we set

Please login or register to see this code.

it will speed run the emulator for 24 hours. The speeding will start after rules are loaded and QuickApp:main() returns.

This can be useful if we want to check how scheduled rules behave over a certain time period. Combined with setting the simulated time it can be a powerful tool to get this hard to find bugs (will the lights turn on on New Years Eve next year?)

When we speed run fibaro.call are disabled and api.put and api.post

The reason is that otherwise, if you are turning on/off lamps they will blink a lot while you speed run  

In any case, use this with caution, and be prepared that a lot of rules will trigger and run during a short period of seconds....

 

Use Terminal5 to interact with the rules

By getting the

Please login or register to see this link.

up and running we can type EventScript expressions and inspect values and interact with our rules by triggering them like in earlier examples

Ex. print a list of all devices currently on

Please login or register to see this code.

 

Run EventRunner5 offline and debug it

ER5 QA is fully developed offline using the

Please login or register to see this link.

environment and is the easiest way to test and develop rules quickly...

 

Hi Jan

Can a explain a detail for the bathroom examble, special the 

rule("Livingbath_sensor:breached => Livingbath_door:safe & (inlivingBathroom = true); Livingbath_light:on")

 

When "Livingbath_door:safe & (inlivingBathroom = true);" is after the => what effect does it have ?

 

I uses two sensors

var.Livingbath_sensor = {236, 1122} - but then Livingbath_sensor:last<=3

fails...

[11.02.2024] [11:52:30] [ERROR] [ER1961]: [Rule:47:6]>> [Rule:47:Livingbath_door:safe & Livingbath_sensor:last<=3 => inlivingBathroom = true] Runtime: ./include/vm.lua:88: attempt to compare nil with number lte
Livingbath_door:safe & Livingbath_sensor:last<=3 => inlivingBathroom = true
                                                                      ^^

 

 

Please login or register to see this code.

 

 

[jgab 2,641]

16 minutes ago, ChristianSogaard said:

 

Hi Jan

Can a explain a detail for the bathroom examble, special the 

rule("Livingbath_sensor:breached => Livingbath_door:safe & (inlivingBathroom = true); Livingbath_light:on")

 

When "Livingbath_door:safe & (inlivingBathroom = true);" is after the => what effect does it have ?

 

Things after => doesn't trigger the rule.

Livingbath_door:safe & (inlivingBathroom = true) on the left hand side of => would trigger the rule every time Livingbath_door:safe changes.

 

16 minutes ago, ChristianSogaard said:

 

I uses two sensors

var.Livingbath_sensor = {236, 1122} - but then Livingbath_sensor:last<=3

fails...

[11.02.2024] [11:52:30] [ERROR] [ER1961]: [Rule:47:6]>> [Rule:47:Livingbath_door:safe & Livingbath_sensor:last<=3 => inlivingBathroom = true] Runtime: ./include/vm.lua:88: attempt to compare nil with number lte
Livingbath_door:safe & Livingbath_sensor:last<=3 => inlivingBathroom = true

:last applied to a list of sensors will return a list of last values. You have to decide what number in that list you want to compare with.

If you want the max value of the sensors (which I think make sense in this case) do

Please login or register to see this code.

 

[ChristianSogaard 71]

1 hour ago, jgab said:

 

Things after => doesn't trigger the rule.

Livingbath_door:safe & (inlivingBathroom = true) on the left hand side of => would trigger the rule every time Livingbath_door:safe changes.

 

:last applied to a list of sensors will return a list of last values. You have to decide what number in that list you want to compare with.

If you want the max value of the sensors (which I think make sense in this case) do

Please login or register to see this code.

 

 

Thank you Jan

i know that "Things after => doesn't trigger the rule." so i probally didnt ask my question wrong.

 

Livingbath_door:safe from the 
rule("Livingbath_sensor:breached => Livingbath_door:safe & (inlivingBathroom = true); Livingbath_light:on")

 

this part was confusing me - Livingbath_door:safe

overwrites the real sensor value, right ?

Why is that ? - is this because is people dont close the door, you still want to turn on the light ?

 

Edited February 11, 2024 by ChristianSogaard
Typo

[jgab 2,641]

1 hour ago, ChristianSogaard said:

 

Thank you Jan

i know that "Things after => doesn't trigger the rule." so i probally didnt ask my question wrong.

 

Livingbath_door:safe from the 
rule("Livingbath_sensor:breached => Livingbath_door:safe & (inlivingBathroom = true); Livingbath_light:on")

 

this part was confusing me - Livingbath_door:safe

overwrites the real sensor value, right ?

Why is that ? - is this because is people dont close the door, you still want to turn on the light ?

 

Livingbath_door:safe & (inlivingBathroom = true)

is the same as

if Livingbath_door:safe then inlivingBathroom = true end

So we set the variable inlivingBathroom to true if the door is safe.

 

The logic is that if the sensor is breached and the door is safe, then someone is in the bathroom and we set the variable so we don't turn off light even when if becomes safe again. We assume here that the sensor is inside the bathroom.