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


Tiny QuickApp Emulator (TQAE)


Recommended Posts

Please login or register to see this link.

35                                     -- Main emulator, loads other modules

 

Please login or register to see this link.

                        -- timers with fake asynchronous IO

Please login or register to see this link.

                      -- timers with asynchronous IO based on cops

Please login or register to see this link.

                     -- copas.* functions

Please login or register to see this link.

                          -- net.* functions

Please login or register to see this link.

                          -- api.* and web api

Please login or register to see this link.

                        -- json library

Please login or register to see this link.

                     -- fibaro.* functions

Please login or register to see this link.

                      -- class function

Please login or register to see this link.

                        -- support for loading files, *.lua and *.fqa files

Please login or register to see this link.

               -- QuickApp classes

Please login or register to see this link.

                -- device templates

Please login or register to see this link.

             -- web server for remote calls (ex. from proxy)

Please login or register to see this link.

                     -- creates QA proxy on the HC3 for funnelling back onAction and UIevents

Please login or register to see this link.

                           -- Local Web UI for QA

Please login or register to see this link.

                       -- Time manipulation - changing start time...

Please login or register to see this link.

       -- /refreshStates support

Please login or register to see this link.

                   -- Initial support

Please login or register to see this link.

                   -- Support for local shadowing resources. Currently /globalVariables

Please login or register to see this link.

                   -- Standard (simulated) devices

 

Please login or register to see this link.

           -- Web - Main emulator page

Please login or register to see this link.

               -- Web - QuickApp info

Please login or register to see this link.

                -- Web - QuickApp UI

Please login or register to see this link.

         -- Web - list of active timers

Please login or register to see this link.

      -- Web - editor for configuration file

 

Please login or register to see this link.

       -- Example, Simple QuickApp

Please login or register to see this link.

                      -- Example, Hue QuickApp with QuickAppChildren

Please login or register to see this link.

            -- Example, Simple minute based scheduler

Please login or register to see this link.

                      -- Example, Ping QuickApp that loads Pong QuickApp and exchanges fibaro.calls...

Please login or register to see this link.

Please login or register to see this link.

                  -- Test scene   

Please login or register to see this link.

           -- Test scene  with Date condition

Please login or register to see this link.

                        -- Non-QA code that backs up QuickApps from the HC3 to the local filesystem as *.fqa files

Please login or register to see this link.

     -- WebSocket example controlling my Samsung TV

Please login or register to see this link.

           -- TCPSocket example with emulated responses 

 

Please login or register to see this link.

 -- Every file in one archive

 

Installation

The source for the emulator is available at the Fibaro forum link or directly from my GitHub <

Please login or register to see this link.

> (It's a bit messy...)

First time download the archive,

Please login or register to see this link.

and unpack it in a suitable directory on your PC/Mac/Linux.
On Linux:

Please login or register to see this code.


On PC/Mac use suitable archive program to unpack the archive.

Please login or register to see this code.

Download ZeroBrane studio <

Please login or register to see this link.

>
Open ZBS and open the TQAE_QA.lua file
Set project directory in ZBS to the current file, TQAE_QA.lua (Project->Project Directory->Set From Current File)

Also set Lua interpreter to Lua 5.3 (Project->Lua Interpreter->Lua 5.3)

Now, run TQAE_QA.lua (F5 in ZBS).

The output will look something like:

Please login or register to see this code.

Note first that there is no connection to the HC3 - we are missing user,  password, and IP for the HC3.
Secondly, note the WebAPI address. 192.168.1.18 is my machine, your IP address may be different. The port is 8976.
While TQAE_QA.lua is running open http://192.168.1.18:8976/web/main in your browser. (the Web UI only works while the emulator is running)

Please login or register to see this attachment.

 

Goto [Settings] in the web page menu (upper right).

Please login or register to see this attachment.

 

Fill in User ID, Password, and IP address for the HC3. Click "Save"

Hopefully there is now a TQAEconfigs.lua file with the HC3 credentials that the emulator can use.

Go back to ZBS and stop the program (Shift-F5) and run it again:

Please login or register to see this code.

It loads the config file and doesn't complain that there is no connection to the HC3 anymore.

Great we are up and running!

 

Supported functions (v0.33)

Please login or register to see this code.

 

The idea and reason that I implement an offline emulator for the HC3 is that it is generally speaking a pain to debug a moderately complex QuickApp on the HC3. You are left to using debug statements and it slow you down as you can not set breakpoint and step through the code to understand what logic it is following.

 

With an offline emulator running on a PC/Mac you can use a modern IDE like ZeroBrane or VisualStudio to develop your QA. You can quickly put together 99.9% of your QA and the speed/productivity tripples.

When it works in the emulator you can move the code to the HC3 and it will work.

No need to develop on the HC3 and accidentally crash the whole box and make your family upset.

 

Here is a video showing a typical workflow.

(Note that the Web UI now has a button "Upload" that uploads the QuickApp when it's ready to the HC3)

 

 

Writing HC3 (HC2) emulators seems to be a hobby for me - but what better thing to do on a vacation? :-)

So far I have

  • Please login or register to see this link.

    - quite ok and feature complete, not actively developed anymore but still works well (not much has happened to the HC2 scene framework lately)
  • Please login or register to see this link.

    - gazillion of features, 9.5k lines - haven't come across any QA it can't run. Also some basic Scene support
  • Please login or register to see this link.

    - ~70 lines of Lua that can run QAs in parallel but have a very limited function support. Developed to prove that we could enhance the call model of QAs without much work

 

Well, the micro emulator got my interest and I have evolved it to a more full featured emulator - Tiny QuickApp Emulator (TQAE).

  • Runs multiple QAs in parallel - can test fibaro.calls between them
  • Supports net.HTTPClient, setTimeout, clearTimeout, setInterval, clearInterval, json.*, class, property
  • Supports QuickApp methods - self:setVariable, self.getVariable, self:updateProperty, self:updateView
  • Supports fibaro.* functions
  • Supports QuickAppChild devices
  • Supports simple web UI to test QuickApp buttons/sliders
  • Supports proxy QA on the HC3 to make to emulated QA interact with QAs running on the HC3 - Real HC3 QAs can call the QA you are running in the emulator. (and you get a real UI too)

The main idea is that the emulator could be used as a light weight playground for testing out QAs

 

The main logic is still under 1000 lines with current modules but stuff like json support and the whole fibaro.* sdk requires quite some code so it tends to swell - in any case it's modular.

Dependencies on luasocket. (I recommend the free

Please login or register to see this link.

as it comes with the necessary libraries and is a specialised development environment for Lua)

Please login or register to see this code.

 

It has an easy structure (I think). 

Please login or register to see this attachment.

 

There are very few differences between TQAE and fibaroapiHC3.lua so I mainly work with TQAE these days.

 

Advantages  compared to fibaroapiHC3.lua.

  • Easier to debug as code is not as asynchronous as it is in the fibaroapiHC3 scheduler (possibility to use a sync scheduler).
  • Uses a vanilla fibaro.* implementation only leveraging api.* and __fibaro_* calls, so it should be easy to upgrade if we get new fibaro.* calls.
  • Module structure makes it easy to add new libraries etc. It's modular.

 

Include it in your QA code

 

Please login or register to see this code.

The loadfile at the top loads in the emulator and run your QA.

The { ... } table after loadfile("TQAE.lua") is a table with configuration options to the emulator. The emulator needs ip, user and password to access the HC3.

If you don't want to type that you can store a config file for TQAE with you standard settings. The default name for the file is "TQAEconfigs.lua" and it can look like

Please login or register to see this code.

However, you still need to call loadfile("TQAE.lua"){} with and empty table. If you would like to have another name of the file you can specify that

loadfile("TQAE.lua"){ config = "myTQAEconfigfile.lua" }

 

The config is parameters for the emulator. Then you can also set "parameters" for the individual QAs that you run using --%% directives

The --%% directives in your QA code are collected into a Lua table. In the case above

Please login or register to see this code.

and if present will be used to add fields to the QA. This is the way to tell what name, id and type you want your QA to have. A special field is quickVars that will be inserted as quickAppVariables of the QA at startup. Note that each field can only be one line.

 

It's easy to startup another QA from within your code

Please login or register to see this code.

If the other file is open in the IDE you can set breakpoints in it and jump between the QAs.

In fact, hc3_emulator.installQA{id=444,file='MyThirdQA.fqa'} will load in a .fqa file directly. In that case temporary files are stored for each of the files in the .fqa.

 

This means we can do trick like this, downloading a QA from the HC3 and run it in the emulator with one line of code

Please login or register to see this code.

 

Another useful directive is

Please login or register to see this code.

that allow us to include extra files in our QA. A QA can consist of several files but it must have a 'main' file. The QA code you run in the emulator will always be the main, and then you can include extra files that will be added to the QA as "files".

Ex.

Please login or register to see this code.

 

Running and logs

When running there will be output of two types.

Standard logging that the QA does with fibaro.debug, self:debug etc,.

System debugs, that are the emulators way to inform on what is ongoing. How much the system logs depends on the configuration parameter .logLevel. 

Please login or register to see this code.

Here we se the system log (|SYS  |) that the QA is loading and then the log that it's running.

The first is when the QA code is loaded and all functions are defined. Also if you do something on top-level, outside functions it will run here. In the example the QA does a 

Please login or register to see this code.

on top-level of the QA so that is executed when loading.

Then, if the QA is successfully loaded, it will be "started, meaning that the function QuickApp:onInit() will be called if it's defined. That's the second SYS log. It's good to pay notice to this.

  • If you get an error before Loading it typically means that you have a syntactic error in the QA code - non-valid Lua code.
  • If you get an error after Loading but before Starting it's something on top-level that is run, outside of function QuickApp:onInit()
  • If you get an error after Starting, well, then it's just something wrong with your code when it runs.

 

A run-time error will look like:

Please login or register to see this code.

This tells us that the error was in the QA with id 1002 (unless you have changed __TAG)

The QA file is 'main'. A QA can consist of many files and this gives us the clue in what file the error was. If you only have one file, its name is 'main'.

Then it tells us that is was line 5 where the error occurred ([string "temp/main_16546.lua"]:5:) and then that we tried to call a global variable 'foo'

 that didn't have a value (a function)

So, in the main file look for a foo() call on line 5 - that's the error...

 

Turning up logLevel will also log modules loaded etc. It also sets a Lua global in the QA, LOGLEVEL to the level, so that variable can be used by you to also allow your code to log more or less.

 

Other features

A QA can also be saved in a .fqa format that can be uploaded to the HC3

The directive

Please login or register to see this code.

will package and save the QA to myQAs/QA42.fqa when finished. It you have included multiple files with the --FILE: directive they will also be included. A simple way to code and create multi-file QAs. 

The directive 'interfaces'

Ex.

Please login or register to see this code.

will add the interfaces as the initialInterfaces property of the .fqa. An easy way to include and extra interface in the ready .fqa.

 

Emulator options: (set in the header _=loadfile and loadfile("TQAE.lua"){...} )
user=<user>
  Account used to interact with the HC3 via REST api
pwd=<Password>
  Password for account used to interact with the HC3 via REST api
host=<IP address>
  IP address of HC3
configFile = <filename>
  File used to load in emulator options instead of specifying them in the QA file.
  Great place to keep credentials instead of listing them in the QA code, and forget to remove them when uploading codeto forums...
  Default "TQAEconfigs.lua"
debug={

  traceFibaro=<boolean>  -- default false
  QA=<boolean>,       --default true
  module=<boolean>,   --defaul false
  module2=<boolean>,  --defaul false
  lock=<boolean>,     --default false
  child=<boolean>,    --default true
  device=<boolean>,   --default true

  refreshStates=<boolean> -- default false
}
modPath = <path>, 
  Path to TQAE modules. 
  Default "TQAEmodules/"
temp = <path>
  Path to temp directory. 
  Default "temp/"
startTime=<time string>
  Start date for the emulator. Ex. "12/24/2024-07:00" to start emulator at X-mas morning 07:00 2024.
  Default, current local time.
htmlDebug=<boolean>.
   If false will strip html formatting from the log output. 
   Default true
colorDebug=<boolean>.
   If true will log in ZBS console with color. 
   Default true
copas=<boolean>
   If true will use the copas scheduler. 
   Default true.
noweb=<boolean>
   If true will not start up local web interface.
   Default false
lateTimers=<seconds>
  If set to a value will be used to notify if timers are late to execute.
  Default false
timerVerbose=<boolean>
  If true prints timer reference with extended information (expiration time etc)
  
QuickApp options: (set with --%% directive n file)
--%%name=<name>
--%%id=<number>
--%%type=<com.fibaro.XYZ>
--%%properties={<table of initial properties>}
--%%interfaces={<array of interfaces>}
--%%quickVars={<table of initial quickAppVariables>}
--%%proxy=<boolean>

--%%save=<boolean>

 

Documentation

  • Please login or register to see this link.

     and QA parameters
  • Please login or register to see this link.

     - and

    Please login or register to see this link.

  • Please login or register to see this link.

 

Notes and ToDos

Mostly developed as a playground for my own coding and it fits my workflow. I may add features/fix bugs if others are using it - but no more than 500 lines of code :-) 

Edited by jgab
Change my mind and made it modular - easier to experiment with
  • Like 2
  • Thanks 5
Link to comment
Share on other sites

  • Topic Author
  • Posted (edited)

    Ok, I changed my mind and made TQAE modular. This way it's easier to experiment with additional or variants of modules

    Please login or register to see this link.

    4 is the core emulator with the __fibaro_* builtin functions

    Please login or register to see this link.

     is the api.* and net.* functions

    Please login or register to see this link.

     is the rxi json encode/decoder

    Please login or register to see this link.

     is a fibaro.* sdk only using the builtins, I believe it's close the the HC3 builtin fibaro sdk

    Please login or register to see this link.

     is functions for loading fqa's, lua files etc.

    Please login or register to see this link.

     is a simple version of the QuickApp support

    Please login or register to see this link.

     -- Every file in one archive

     

    "modules" come in 2 versions

    • global modules that are loaded into the emulators global environment  (net, json,fibaro,files), and then relevant symbols are exported to the QA's environment (it's kind of hardcoded at the moment)
    • local modules that are loaded into each QA's environment. The only module now is QuickApp.lua. fibaro.lua could be loaded here too instead of global, but it's "stateless" and we can easily use it from other models this way.

     

    ToDo: a smoother module system allowing to easily add local and global modules without having to edit TQAE.lua

    Edited by jgab
    • Thanks 2
    Link to comment
    Share on other sites

  • Topic Author
  • Posted (edited)

    v0.5.

    • Possible to setup a config file for emulator settings - see first post.
    • Smarter way to store temp files (crc16 to reuse already written temps)
    • Better structure with less cross dependencies between emulator and modules. Module system could still use a better approach - would like 0 globals...
    • https support (light, no certs)
    • verbose off by default
    Edited by jgab
    • Thanks 1
    Link to comment
    Share on other sites

  • Topic Author
  • v0.6

    • QAs can also be saved in a .fqa format that can be uploaded to the HC3 with the directive

      Please login or register to see this code.

      Ex. will package and save the QA to myQAs/QA42.fqa when finished. It you have included multiple files with the --FILE: directive they will also be included. A simple way to code and create multi-file QAs.
       
    • The directive 'interfaces'
      Ex.

      Please login or register to see this code.


      will add the interfaces as the initialInterfaces property of the .fqa. An easy way to include and extra interface in the ready .fqa.
    • Like 2
    Link to comment
    Share on other sites

  • Topic Author
  • Posted (edited)

    v0.7

    • Rewritten the module interface (almost no globals anymore :-) ) . Module comes in two flavours.
      • 'global' that add emulator "native" functions (ex. net.* or json.*)
      • local that are loaded into each QA when they start. Ex. fibaro.lua and QuickApp.lua
    • The emulator have two 'namespaces' (tables), EM that has the native emulator functions. FB that has the "fibaro functions". Everything in FB will be copied to the QA's environment.
    • There is a new 'webserver' module that can serve webpages from a directory (see web/main.html) . A start of some kind of Web UI for the emulator, but also to receive api.calls...
    Edited by jgab
    • Like 1
    Link to comment
    Share on other sites

  • Topic Author
  • Posted (edited)

    v0.8

    • Some simple web UI pages. Possible to view QAs installed and some info on individual QAs. Have a look at the web/ subdirectory.
      The server is started by default at

      Please login or register to see this link.

       and the UI at 

      Please login or register to see this link.

      /web/main
    • Support for QuickAppChild devices.

    It's a bit tricky when creating resources (QuickAppChildren) if we should create them in the emulator or on the HC3.

    For now I have solved it by introducing a call __fibaro_local(bool) that if given true, calls to createChildDevice will create them locally and if set to false (default) will try to create them on the HC3. See example below.

    QuickAppChildren are created on the HC3 if your QA has a proxy on the HC3. Can be overridden with __fibaro_local(bool).

     

    Please login or register to see this code.

     

    Edited by jgab
    • Like 1
    Link to comment
    Share on other sites

  • Topic Author
  • Posted (edited)

    v0.9

    • Faster timer queue. Was table, now double linked list.
    • Some more web UI stuff - QuickApp:Functions that take no argument can be invoked from the web UI (like turnOn, turnOff and user defined methods)
    • Home made version of inline Lua code in the html pages - see web/*
    • device library (devices.json) used for device type templates - more realistic device structures created for QAs
    Edited by jgab
    Link to comment
    Share on other sites

  • Topic Author
  • Posted (edited)

    Documentation of emulator and QuickApp parameters (will be updated as paremeters are added)

    To run QA code in the emulator you need to add an header to the QA's lua file.

    Please login or register to see this code.

    A minimum set of parameters are the user,pwd, and host parameter that is used by the emulator to connect to the HC3.

    Additional parameters can be set to affect the behaviour of the emulator.

    •   verbose=<bool>,   If set to true will log more extensively what's going on in the emulator. Default false.
    •   modPath = <path>, The path to the directory where modules are stored. Default "TQAEmodules/"
    •   temp = <path>, The path to where temporary files are stores. Default "temp/"
    •   startTime=<time>, An alternative starting time for the emulator. Ex. "05/15/2021-10:15" will start May 15 2021 at 10:15
    •   localModules = <table of modules>, List of modules that should be loaded into the QA environment. Ex. {"myModule.lua"}
    •   globalModules = <table of modules>, List of modules that should be loaded into the emulator environment. Ex.  {"UDP.lua"}
    •  paramsFile= <file path>, Path to file containing emulator parameter. Default "TQAEconfigs.lua"

    If you use the same parameter all the time it can be worth creating a parameter file named "TQAEconfigs.lua" and put in it ex.

    Please login or register to see this code.

    then you just need the header

    Please login or register to see this code.

    If you add additional parameters in the header they will overwrite the parameters in the config file if they clash.

     

    QuickApp parameters

    The above configuration affect the emulator as a whole. We also need to be able to set parameters for our QuickApp. We can't have these parameters in the header because we can run several QAs at the same time and each need their own configuration.

     

    QuickApp parameters are specified with the --%% directive in the QA's code.

    Ex. 

    Please login or register to see this code.

    sets the name of the QA. We could have derived the name of the QA from the filename but it's not always what we want and this is more flexible.

    The full set of QA parameters are

    • --%%name=<string>, name of QA
    • --%%type=<string>, fibaro type of devices. Default "com.fibaro.binarySensor"
    • --%%id=<number>, If not specified a number starting from 1001 will be assigned. Be aware if device with same ID as a QA on the HC3, the emulated QA will shadow the one on the HC3.
    • --%%info.properties=<table>, Initial properties for the QA. 
    • --%%interfaces=<table>, <table>, Initial interfaces for the QA. Ex. {"power"}
    • --%%quickVars=<table>, Initial quickAppVariables for the QA, Ex. {a=99, b = "Hello"}
    • --%%noterminate=<bool>, If true the QA will not terminate when running out of timers. It can sometimes be good that the QA doesn't self-terminate when no more timers. Ex. to be able to inspect the QA with the Web UI.
    • --%%save=<path>, If present the QA will be saved to the path as a .fqa file when it terminates. Ex. "temp/foo.fqa". How do you save a QA that doesn't terminate? In the WebUI for the QA there is a "Save" button that allows you to save a running QA to a .fqa file. You do need to specify the --%%save directive so the same to save the QA under is known.

     

    Not strictly a QA parameter directive, but very useful, is the --FILE directive that allow us to include extra files in our QA code. (when --%%saved they will be packed with the .fqa). We can include multiple files by repeating the --FILE directive.

    Ex.

    Please login or register to see this code.

    will load the file fibaroExtra.lua and call the file 'fibaroExtra' in the .fqa file.

    Edited by jgab
    Link to comment
    Share on other sites

  • Topic Author
  • Posted (edited)

    The emulator has a rudimentary Web UI that can be used to inspect the QAs running in the emulator.

    If we have this example code

    Please login or register to see this spoiler.

    It defines a QA that then define a child device.

    The main page looks like

    /web/main

    Please login or register to see this attachment.

     

    The main page tells us when the emulator started (we choose to start it at Christmas Eve 2024)

    It tells us what modules are loaded

    ...and it lists the current running QAs in the emulator. Child devices are listed as sub-bullets to the "mother" QA.

    Choosing device 1001 "Test" shows

    Please login or register to see this attachment.

    We see type and interfaces.

    Then View elements, methods, properties and quickAppVariables are listed.

    We can click on methods to invoke them. Arguments are specified as a json array without surrounding brackets.

    Ex. to invoke the self:debug method to log "Test" we just type "Test". To invoke self:setVariable we give the argument "myar","42"

    There is also a small "Reset" button that restarts the QA for us (calls plugin.restart() )

     

    If we look at the child it looks similar but with slightly different methods as the type is different. (It doesn't have any view element or quickAppVars)

    Please login or register to see this attachment.

    Clicking here on self:toggle will flip the value property in the Properties column.

     

    From the main page we can also get a list of currently running timers

    Please login or register to see this attachment.

    It show us the current time (incl. milliseconds) and it lists two timers (threads) current active.

    It gives us the time the timer expires, the ID of the QA (0 if a "system" timer) and an optional tag.

    The setTimeout in the emulator allows for a third argument being a string tag that identifies the timer. It can be useful while debugging.

     

    We see here that the web server timer already has expired but is still listed. It can happen for timers that expires while the web page is rendering. The timers are sorted in order of expiration date.

     

    It's very basic HTML layout and could be nicer with some CSS styling...

    Edited by jgab
    Link to comment
    Share on other sites

  • Topic Author
  • v0.12

    • Added support for QA Web UI
    Link to comment
    Share on other sites

  • Topic Author
  • Posted (edited)

    v0.14

    • Lots of bug fixes....
    • Examples provided.
      • Hue QA and Scheduler QA that runs in the emulator (and the HC3)
    Edited by jgab
    Link to comment
    Share on other sites

    • jgab changed the title to Tiny QuickApp Emulator (TQAE)
  • Topic Author
  • Posted (edited)

    Some notes about the implementation.

    Please login or register to see this attachment.

     

    There are two "namespaces" - where functions are defined. 

    EM = { ... } with all the emulator internal functions and datastructure

    FB = {  ...} with the "fibaro" functions that are copied to each QuickApp's lua environment

     

    Every QuickApp is loaded into it's own Lua environment. Lua's load(string,env) all us to load Lua code that has it's own environment - its' own _G or _ENV. Then we start a QA by creating a QuickApp instance in that environment. 

     

    Device structures are stored EM.Devices. It's keyed on the deviceId and contains

    Please login or register to see this code.

    The most important is the 'env' as it is the environment the device is associated to and where we find the QuickApp instance if it exists.

     

    The timer loop is the central part of the emulator. It runs a loop calling timers that are due. The timer queue uses the socket.gettime() function that return time with millisecond precision. A setTimeout() call just add a task to the timer queue. The timer queue is a sorted queue with the smallest timer first in the queue.

     

    This means that if we run several QuickApps in parallel they will share timer queue. Because they run in separate Lua environments they will not clash and fibaro.sleep() is not blocking other QAs tasks so they can still run. 

    However, if a QA runs a tight busy loop it may starve the other QAs.

     

    ...more to come...

     

    Edited by jgab
    Link to comment
    Share on other sites

  • Topic Author
  • v0.18

    • Support for refreshStates. 
      Intercepts api.get("/refreshStates...") and "http://127.0.0.1:11111/api/refreshStates..." to provide HC3 events from an internal queue.
    Link to comment
    Share on other sites

  • Topic Author
  • 1 hour ago, SmartHomeEddy said:

    (Small question: is /api/creatChildDevice is typo?)

    Yes :-)

    Searched through all the code and couldn't find 'creatChildDevice' - then I realized that someone looked at my pictures...

    Edited by jgab
    • Like 1
    Link to comment
    Share on other sites

  • Topic Author
  • Since last version the TQAE emulator supports proxy QAs.

     

    That means that when you run an emulated (local) QA in the emulator, the emulator will automatically deploy a "proxy" QA

    on the HC3 with the same type and name - and having the same functions.

    The difference is that the proxy sends all function calls back to the QA in the emulator.

    When another QA calls the proxy's fibaro.call(YourQA,"turnOn"), the proxy will send it on to the emulated QA and it's 'turnOn' function.

    Same when you press one of the proxy's UI buttons.

     

    In this way you can run and debug the QA in the emulator on a PC, and at the same time it will have a presence on the HC3 and can be interacted with from other HC3 QAs.

     

    If a QA that have a proxy creates child devices, they will also be created on the HC3 as "proxy children".

     

    You can at any time delete the proxy QA from the HC3 and it will be recreated if you turn on the proxy feature the next run.

    As long as the type or the UI doesn't change the emulator will reuse an existing proxy on the HC3 instead of creating a new (thus saving on device IDs)

     

    A consideration when running with a proxy is that the emulated QA will take on the deviceID of the proxy device on the QA, no matter if you had specified a specific ID for the emulated QA. This is a necessity as it needs to reflect and be addressed the same way in the emulator as well as the HC3.

     

    To enable the proxy feature is easy. Just add the QA directive:

    Please login or register to see this code.

    ... in the code.

     

    Even if the QA has a proxy, there will still be an emulated Web UI for the QA. However, the emulated Web UI is only a proximation of the real QA UI on the HC3 (and only supports buttons, sliders and labels) so to debug more advanced UI it's recommended to use proxies. This is especially trough for QuickAppChild devices as they can have very special UIs depending on type, types that are not supported by the emulators Web UI.

     

    Link to comment
    Share on other sites

  • Topic Author
  • An emulated QA can specify a Web UI that tries to mimic the UI you get when you design the QA on the HC3.

    Only buttons, sliders and labels are supported.

     

    To define the UI you add QA directives

    Please login or register to see this code.

    in the code.

     

    Please login or register to see this code.

    Resulting in the UI

    Please login or register to see this attachment.

    Edited by jgab
    Link to comment
    Share on other sites

  • Topic Author
  • The idea and reason that I implement an offline emulator for the HC3 is that it is generally speaking a pain to debug a moderately complex QuickApp on the HC3. You are left to using debug statements and it slow you down as you can not set breakpoint and step through the code to understand what logic it is following.

     

    With an offline emulator running on a PC/Mac you can use a modern IDE like ZeroBrane or VisualStudio to develop your QA. You can quickly put together 99.9% of your QA and the speed/productivity tripples.

    When it works in the emulator you can move the code to the HC3 and it will work.

    No need to develop on the HC3 and accidentally crash the whole box and make your family upset.

     

    Here is a movie showing a typical workflow.

     

    Note that the Web UI now has a button "Upload" that uploads the QUickApp when it's ready to the HC3.

     

     

    Edited by jgab
    • Like 3
    Link to comment
    Share on other sites

  • Topic Author
  • Here is a trick to use the emulator with an existing QuickApp - and you don't want to modify the code.

    In this example we use the GEA scheduler v 7.33

    Please login or register to see this code.

     

    We need to add the UI elements by hand and put in the correct UI ids (it's usually easy by looking at the QA editor on the HC3)

    Then we include the files that make up the QA.

    In this case 

    Please login or register to see this code.

    Normally, the file with the header - the one we are editing in the example, becomes the 'main' file. 

    However, we can, like in this case, include the file 'GEA v7.33.lua' as main. We should also include it as the last file to make sure that it's loaded last.

     

    The setup is that we have a file structure like

    Please login or register to see this code.

     

    and we set the working directory to the top-level where we have TQAE.lua.

    We can then open up ex. 'GEA v7.33.lua' in the editor and set breakpoints, and step through the code as it executes.

    Pretty nifty... :-) 

    Edited by jgab
    • Like 2
    Link to comment
    Share on other sites

  • Topic Author
  • New version, v0.30.

    Lot's of bug fixes and a better web UI.

    Here is a short installation tutorial:

     

    Installation

    The source for the emulator is available at the Fibaro forum link or directly from my GitHub <

    Please login or register to see this link.

    > (It's a bit messy...)

    First time download the archive, 

    Please login or register to see this link.

     and unpack it in a suitable directory on your PC/Mac/Linux.
    On Linux:

    Please login or register to see this code.


    On PC/Mac use suitable archive program to unpack the archive.

    Please login or register to see this code.

    Download ZeroBrane studio <

    Please login or register to see this link.

    >
    Open ZBS and open the TQAE_QA.lua file
    Set project directory in ZBS to the current file, TQAE_QA.lua (Project->Project Directory->Set From Current File)

    Also set Lua interpreter to Lua 5.3 (Project->Lua Interpreter->Lua 5.3)

    Now, run TQAE_QA.lua (F5 in ZBS).

    The output will look something like:

    Please login or register to see this code.

    Note first that there is no connection to the HC3 - we are missing user,  password, and IP for the HC3.
    Secondly, note the WebAPI address. 192.168.1.18 is my machine, your IP address may be different. The port is 8976.
    Open http://192.168.1.18:8976/web/main in your browser.

     

    Please login or register to see this attachment.

     

    Goto [Settings] in the web page menu (upper right)

     

    Please login or register to see this attachment.


    In the right hand column "Settings file", fill in User ID, Password, and IP address for the HC3.
    Scroll down to the bottom of the page and click "Save"

    Hopefully there is now a TQAEconfigs.lua file with the HC3 credentials that the emulator can use.

    Go back to ZBS and stop the program (Shift-F5) and run it again:

    Please login or register to see this code.

    It loads the config file and doesn't complain that there is no connection to the HC3 anymore.

    Great we are up and running!

    Edited by jgab
    • Thanks 2
    Link to comment
    Share on other sites

    Join the conversation

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

    Guest
    Reply to this topic...

    ×   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.

     Share

    ×
    ×
    • Create New...