Jump to content

Welcome to Smart Home Forum by FIBARO

Dear Guest,

 

as you can notice parts of Smart Home Forum by FIBARO is not available for you. You have to register in order to view all content and post in our community. Don't worry! Registration is a simple free process that requires minimal information for you to sign up. Become a part of of Smart Home Forum by FIBARO by creating an account.

 

As a member you can:

  •     Start new topics and reply to others
  •     Follow topics and users to get email updates
  •     Get your own profile page and make new friends
  •     Send personal messages
  •     ... and learn a lot about our system!

 

Regards,

Smart Home Forum by FIBARO Team


2 Screenshots

About This File

AOQ can control any other Fibaro system HC3, HC2, HCL (master/slave concept) Before migrating your devices to HC3, AOQ could be the solution to make it smooth and simple.

If you've found yourself with too many Lua and Block scenes and need more automation, this QA is the right solution for you.

The QA is designated to control and monitor your home system. QA automatically identifies the type of elements in the system. (Z-wave device, Nice, QA device, scene, automatic scene (Block and Lua). Any valid Z-wave,Nice and QA devices property and their values could be monitored, controlled and execute commands accordingly

AOQ supports custom events, active profile setup and controls alarm zones while every breached zone or sensor in the zone could be identified and execute actions accordingly.

 

The first time you use All-in-One QA, jM {} hash table must be defined. Each line in the table has two mandatory and two optional fields.

jM={ {      15,              "137|630",       {timeSlot={“12:00~18:00”},state="value=true",     trueAct={“|230|”, “turnOn”,””}}}   }

           Time span      IDs list                                   Criteria & Rules                                               Action tables

 

Time span   a period of time (in minutes) within which some activity must be performed by device or scene. Additional two options could be defined:

  1. time span = 0   defines the line as activity only.
  2. time span = ‘negative number’   line is suspended (remarked)

IDs list   given list of devices/scenes/QA/global/keywords. Use under score for scene IDs. (“_45”).

  • global variable – add an ampersand sign & to System, QA and Local variable names: &varName
  • keyword – add a dollar sign $ to keyword variable: $name

Note: To use & and $ characters for other purpose , add % after the character.

Criteria & Rules  (optional) property, state, time slot, active rules…

Action tables      (optional) tables of commands to be executed.

 

To avoid using device IDs  jS2n{} array could be defined. If device ID changed because of re-inclusion it requires to change ID in one place only.

for example:

jS2n= {boiler=137, dryer=630, light=230} device name must be included within back apostrophe sign in jM{} hash table.

Now jM{} hash table above will look like that:

jM={ { 15,  "`boiler`|`dryer`",{timeSlot={“12:00~18:00”},state="value=true",     trueAct={“`light`”, “turnOn”,””}}}   }

 

1. Monitor option

Some time the scenes or QA devices are stuck w/o any understandable reason. Some devices suddenly stop to send reports or don’t change state. In most of the cases we don’t aware about the problem till something goes very wrong.  The monitor option will send an alert in case of defined states are timed out.

Example to set watchdog timer for devices, scenes, QA devices, global variables and keywords

jM={     

{8, "_17|_545",{timeSlot=”10:00~22:00”}},  -- within every 8 min.  between 10am to 10pm, scenes 17, 545 must be active. If not alert sent.

{3,"134|618|_556|_588"},  -- within  every 3 min. devices 134,618 and scenes 556,588 must be active. If not auto-alert sent.

{10,”132|145”,{property=”power”}}, -- within every 10 min. devices in list must to report new power value. If not auto-alert sent.

{30,”470”,{state=”power>10”}}, -- if device’s power greater than 10 over 30 minutes, auto-alert sent.

{20,”&HomeStatus|$iDoor”}} -- if global variable HomeStatus or keyword iDoor didn’t change within 20 min., auto-alert sent.

 

2. Control option

Execute actions based on device state, status or value changes. QA supports option like on-line calculations, time modifications, IF THEN and WHEN THEN statements and other features for fully home automation just with one QA (which even doesn’t trigger by the system). 

Following action tables are available:

  1. trueAct{} - executed when state status is true.
  2. falseAct{} - executed when state status is false.
  3. trigAct{} - executed on every value change at any mode, true or false
  4. timeoutAct{} - Disables auto-alert notification and executed when elapsed time exceeds time span. Time span counting restarted after state status back to true.
  5. timeLoopAct{} - Disables auto-alert notification and executed when elapsed time exceeds time span. Time counting restarted immediately.
  6. InitAct{} - Set of specific actions to be executed on startup only.
  7. errAct{} - Set of specific actions to be executed if verification failed.
  8. okAct{} - Set of specific actions to be executed if verification succeded.

 

Here is an example of most common scenario, to turn on light when motion sensor breached and turn off light when sensor back to safe after few minutes (3 min. in this example)

jM={0,”`mSensor`”,{state=”value=true”,trueAct={“`lightSw`”,”turnOn”,””},falseAct={“`lightSw`”,”turnOff”,”180”}}}

Since no need to turn on light during the day, timeslot could be defined

jM={0,”`mSensor`”,{state=”value=true”,timeslot=”18:00~07:00”,trueAct={“`lightSw`”,”turnOn”,””},falseAct={“`lightSw`”,”turnOff”,”180”}}}

But now could be an issue to turn off the light, if sensor breached few seconds before end of timeslot and back to safe is out of defined time slot, falseAct{} won’t be executed. In this case, turning light off action should be part of trueAct{} table

jM={0,"`mSensor`”,{state=”value=true”,timeslot=”18:00~07:00”,trueAct={{“`lightSw`”,”turnOn”,””},{“`lightSw`”,”turnOff”,”180”}}}

Z-wave devices, global variables and keywords could be defined at several lines (no limit). Scene could be defined one time only.

For more details please download

AOQ Advanced User’s Guide - complete instructions and information

AOQ Quick Guide – syntax format reference and examples

AOQ HC-WebEye Viewer – AOQ browser viewer guide

 

 QA Advantages:

Spoiler

Advantage.thumb.png.543867a5af7b640e4ae83016eb2254f3.png

 

Debug window view:

On the first run follow information will be displayed at debugger 

Spoiler

image.thumb.png.df6af44b67e465502925c03d921f0fec.png

During normal operation every executed command showed at debugger.

Spoiler

image.thumb.png.16c62fd7a0e9ee01c432bc41a0b16470.png

following data shown for every command:

jM line number: device name: state value and status by color (green - true  |  pink - false); command executed.

The debug information has special tag "AOQ<QA-ID>" and "TRACE" / "WARNING" / "ERROR" type for filtering.

AOQ table preview:

Spoiler

image.thumb.png.d9688881e436821f1a67a3f9b241418d.png

 

Table's header includes:

  • startup time stamp, script current version, scene Name, LED as displayed at HC3 front panel, sunrise/set hours.
  • Current home mode (@home or @vacation)
  • System's current profile mode.
  • Elapsed time
  • Total Z-wave events
  • Min, average and max Z-traffic

Table columns are:

  • Type – device type (Z.Device, G. Variable, Keyword, QA, luaScene, blockScene).
  • ID: Description – room name: device ID: device name. Z-wave devices sorted by rooms, then by device ID.
    • Battery capable device have green background according to current battery level.
    • If device included in alarm circle icon appears before name. green circle - armed, red circle - breached
    Spoiler

    Alarm.thumb.png.08d46f8ee529993ed11eebc8cdf47e58.png

  • Value – items current value.
  • Criteria – state of evaluation to determine true or false status. If formula included, the state displayed on green background.
  • in State– elapsed time since last status change.
  • Alert – by default this column isn’t shown. If any devices have been alerted the column will be shown.
    • Please notice that in some cases the device could be alerted, but after while it could back to normal activity. For example, if motion sensor is breached over specified time-span, alert notification will be sent. But after a while the sensor back to safe and alert is canceled, “back to normal” notification will be sent.  At header of alert column shown current number of alerts
  • Time Span – time span to monitor state of items.
    • If time span set to 0, then this line acts as activity, no timeout alerts reported.
    • If time span set to negative number, this line is suspended and no actions executed.
  • Time Slot – Time slot range to execute related actions. Timestamp to execute specific action at specific time. Active (in range) time slot shown in green fonts.
  • trueAct – list of actions to execute when the state is true.
  • falseAct – list of actions to execute when the state is true.
  • trigAct – list of actions when the value changes
  • timeoutAct – list of actions to execute when time-span reached.  Timer will be restarted when device state changed again to true.
  • timeLoopAct – list of actions to execute when time-span reached.  Timer restarted immediately after actions table executions.
  • initAct – list of actions to execute on QA startup.
  • Active Rules – non default defined rules (initOnStartup, Vacation, timeSpanOn, onClock, lineState, trigAll)
  • jM{#} - line number in jM{} hash table
  • jM{ hash table line} – shows device location in jM{} hash table.

 

At the bottom of the table two execution lines show:

  1. list of up to 60 last executed actions (in order of execution) are displayed. (like CNN news line).
  2. list of delayed commands to be executed (and time left to execute)

 

All global variables, their values and last modification time shows below the table.

 

What's New in Version 19.5   See changelog

Released

Hotfix

An error occurred during loading Quick App Lua files. (found by user @PSi,  thanks)

 

 

 

New features requested by users.

Added devPrt global parameter to define format of the device shown on the debug console

devPrt="room:nameid"   shown as Entrance:Main Door'hc2

Added new operators for statement and conditions:

>>                  pattern doesn’t found in the device’s state or the property, based on LUA find()

 

Added  dbgCalc  global parameter to display detailed formula calculations of command's parameters. Default value is false.

 

New features

  1. Major "face lifting" on console view
  2. set subjective (individual) condition(s) for specific device. No need to re-write same condition over and over
  3.  Improved else case in conditions to replace part of the statement and not to re-write the entire statement.
  4. List of given IDs could be separated by "|" "and" ","   "|456|" or "456" or "456|607" or "|456|607|" or "456 and 607" or "456,607" or "345|_45 and &varname,$RAM"
  5. please download AOQ Advanced User's Guide and use hyperlinks (right after index table) to review new features. 

 

 

Bugs Fix

  1. QuickAPP functions could be used as commands (without using add sign +) 

  2. Minor bug fixes and improvements

 

Update Procedure

New users:

Download AOQ-v19.5.fqa and add to the system as QA device

 

 Exist users:

Download AOQ-main-v19.5.txt and copy to main file in your QA.

Please add new global parameters in user_data file. Refer to Advanced User's Guide.

 

Please backup your previous QA.

  • Like 3


User Feedback

Recommended Comments

AR27690

Posted

Hi cag014

I cannot find AOQ HC-WebEye Viewer?

Thanks

Guest cag014

Posted

Sorry... somehow forgot to upload the file..

Will be added today.

 

Guest cag014

Posted

AOQ HC-WebEye Viewer? has been uploaded.

 

AR27690

Posted

Hi,

Thank you for your code. I migrating mine All-in-One from HC2 and have noticed that setArm and forceArm commands are not supported? 

Another question - I have few QA devices with sliders but I don't find any way to use their values in AOQ!? Can you please take a look on that?

Thanks for the scripts, made the migration to HC3 very smooth and 95% is working!!

Guest cag014

Posted

Thanks for input.

Regarding setArm and forceArm, these commands are not supported by HC3 because fibaro has decided not to control every sensor but to use alarm zones instead.

By the way today if sensor breached there is no indication on UI about that and you need to work hard to monitor which sensor breached. (same for arm/disarm states).

It has been quite a challenge to integrate new alarm concept into AOQ. Please take a look on how to use alarm.. https://forum.fibaro.com/topic/51320-hc3-all-in-one-qa-how-to-do-it-better/

Regarding slider value, I'll see what I can do...

Again, thanks for an input

Guest cag014

Posted

On 8/7/2020 at 9:17 AM, AR27690 said:

Hi,

Thank you for your code. I migrating mine All-in-One from HC2 and have noticed that setArm and forceArm commands are not supported? 

Another question - I have few QA devices with sliders but I don't find any way to use their values in AOQ!? Can you please take a look on that?

Thanks for the scripts, made the migration to HC3 very smooth and 95% is working!!

Regarding sliders - currently there is a bug and slider value doesn't updated properly. You can see when you open new tab the slider value is zero!

Let's hope next release Fibaro will fix the issue.

 

gabes

Posted

Hi @cag014,

Actually migrating my own HC2 scripts to my new HC3 box, i discovered your AOQ quickapp, and after reading your multiple docs, i'am very happy of your work, and first of all i want to thank you for your big work at this quickapp.

 

For the story and feedback to other users, at first i have tried to migrate my environnement with ZWave 3 engine, but i need to say that this was a nightmare because my modules, the majority of whom are now a few years old, are not correctly recognized (or in a too generic way to use your framework greatly) or simply not working correctly working in new engine (door sensor are the most problematic)

 

I restarted then my migration to use Engine 2, and now it's working a lot better.

However, I still have a problem now with the trigAct event on sceneActivation events... a this time i have this problem on 2 differents modules (fibaro flush dimmer with scenario enabled, and nodon  wallswitch in sceneactivation mode > for this on in centralscene event the module is working correctly with AOQ).

The problem is : sometimes (one to two times out of five) the action is triggering twice (so if the trigAct is toglle, the device turn on and turn off in one second).

 

I'am thinking you have a bug in watching this event triggering in you engine, because if i make a specific scene in HC3 without using your AOQ, i dont have this problem, the scene triggers only once.

 

So i'am asking you, if you have a little time to check this problem ?

As you can imagine, i dislike the idea for me to use your AOQ for only some devices, because i'am liking your centralization concept 

 

Keep me informed, and thanks in advance

cag014

Posted

Hi,

First of all, thank you for your compliments. 😀

 

Could you please post your lines and I'll test it, to make sure it works properly.

gabes

Posted (edited)

On 1/8/2023 at 10:08 AM, cag014 said:

Hi,

First of all, thank you for your compliments. 😀

 

Could you please post your lines and I'll test it, to make sure it works properly.

 

Yes, i share you my config and log lines with the simplest use case where the bug occurs, configuration is : 

 

{0,"`CuisineIpilPoutre`",{state="sceneActivation=26",trueAct={"`CuisineBar`","toggle",""}}},
 

in this test case i will press 1 time the device every 10 sec during 1 minute to illustrate

 

[12.01.2023] [22:37:23] [TRACE] [AOQ246]: jM{9}A   Cuisine:80:Cuisine Telco IPIL Poutre[26] ➯ toggle{CuisineBar)
[12.01.2023] [22:37:23] [TRACE] [AOQ246]: jM{9}A   Cuisine:80:Cuisine Telco IPIL Poutre[26] ↪ toggle{CuisineBar)
[12.01.2023] [22:37:32] [TRACE] [AOQ246]: jM{9}A   Cuisine:80:Cuisine Telco IPIL Poutre[26] ↪ toggle{CuisineBar)
[12.01.2023] [22:37:33] [TRACE] [AOQ246]: jM{9}A   Cuisine:80:Cuisine Telco IPIL Poutre[26] ↪ toggle{CuisineBar)
[12.01.2023] [22:37:43] [TRACE] [AOQ246]: jM{9}A   Cuisine:80:Cuisine Telco IPIL Poutre[26] ↪ toggle{CuisineBar)
[12.01.2023] [22:37:43] [TRACE] [AOQ246]: jM{9}A   Cuisine:80:Cuisine Telco IPIL Poutre[26] ↪ toggle{CuisineBar)
[12.01.2023] [22:37:52] [TRACE] [AOQ246]: jM{9}A   Cuisine:80:Cuisine Telco IPIL Poutre[26] ↪ toggle{CuisineBar)
[12.01.2023] [22:37:53] [TRACE] [AOQ246]: jM{9}A   Cuisine:80:Cuisine Telco IPIL Poutre[26] ↪ toggle{CuisineBar)
[12.01.2023] [22:38:03] [TRACE] [AOQ246]: jM{9}A   Cuisine:80:Cuisine Telco IPIL Poutre[26] ↪ toggle{CuisineBar)
[12.01.2023] [22:38:03] [TRACE] [AOQ246]: jM{9}A   Cuisine:80:Cuisine Telco IPIL Poutre[26] ↪ toggle{CuisineBar)
[12.01.2023] [22:38:13] [TRACE] [AOQ246]: jM{9}A   Cuisine:80:Cuisine Telco IPIL Poutre[26] ↪ toggle{CuisineBar)
[12.01.2023] [22:38:13] [TRACE] [AOQ246]: jM{9}A   Cuisine:80:Cuisine Telco IPIL Poutre[26] ↪ toggle{CuisineBar)
[12.01.2023] [22:38:22] [TRACE] [AOQ246]: jM{9}A   Cuisine:80:Cuisine Telco IPIL Poutre[26] ↪ toggle{CuisineBar)
[12.01.2023] [22:38:23] [TRACE] [AOQ246]: jM{9}A   Cuisine:80:Cuisine Telco IPIL Poutre[26] ↪ toggle{CuisineBar)

 

as you can see, the event is triggered two times on every press. The consequence in real usage is that sometimes the toggle change the state to the opposite value, and sometimes not. I thing this is going so :

consider the device is off :

if the first and the second toggle instruction cames exactly at the same instant the result of the two toggle would be to turn the device on, to nothing is visible only the duplication in console log

- on some other press i thing that when the second toggle comes a little milliseconds later that the first the device status is already refreshed so the toggle take it to off state again and the light flashed briefly because first event has turn it on and second off.

 

anyway for me there should only be one trigger event in the log at every press and not two ...

 

Edited by gabes
cag014

Posted

You're absolutely correct...

The dimmer in HC3 has two children light and remote...

Please try attached version

AOQ-main-v15.4.txt

 

Is anyone having keyfob to see if sceneActiviation works fine for remotes also, then please download and test.. thanks

 

gabes

Posted

On 1/15/2023 at 1:48 AM, cag014 said:

You're absolutely correct...

The dimmer in HC3 has two children light and remote...

Please try attached version

AOQ-main-v15.4.txt 230.03 kB · 2 downloads

 

Is anyone having keyfob to see if sceneActiviation works fine for remotes also, then please download and test.. thanks

 

 

It's working ! Thanks a lot... I will now try to set-up more complex scenario with your framework ! 

 

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...