[+] Added OSC (Open Sound Control) Device, Task Action, and Trigger for OSC Device control
[+] Added Serial Devices to the Device Tab
[+] Added Device Send Action as a general action for sending and receiving data from TCP, UDP and Serial Devices
[-] Depreciated the Serial Send Action. The Device Send action should be used instead, but will continue to work until the workspace is upgraded
[-] Depreciated the TCP Send Action. The Device Send action should be used instead
[-] Depreciated the TCP Receive Action. The Device Send action should be used instead
[+] Added (Device_name)_buffer in scripting. To be used in the Device Send action. Bytes returned from the Device with the specified name inside of the (Device_name)_buffer value are returned
[+] Added hexutils.bytestohex() in scripting. Formats bytes received from the (Device_name)_buffer value to Hex format
[+] Added string.frombytes() in scripting. Formats bytes received from the (Device_name)_buffer value to String format
To get more information on anything in Tasker, you can visit the Tasker help manual from the Tasker Web Page. Select the help drop-down and click “Help”.
[+] variables that start with $$ are global variables. These are global WITHIN the workspace.
[+] added Control Panel Switch implementation
[+] added a tasks.get WebSocket handler
[+] added a task.list WebSocket handler
[+] added http post functionality
[!] scheduling changes take effect immediately when a workspace is reloaded
[+] validation on task names, device names, logger names, signal names, trigger names, and schedule names to prevent spaces and bad characters. Names can only be alphanumeric and can include underscores.
3.9, 18 nov 2020
[!] fix error where parameters used to have to be named starting with $.
3.8, 07 oct 2020
[!] fix error for only handling 8 output triggers.
[!] fix error where a temp probe couldnt be assigned to a variable.
[+] added http post functionality.
3.7, 02 oct 2020
[+] Added tracking the parent workspace name so that all of the tasks can be removed from the collection that belong to a workspace that is updated or removed.
3.6
[+] Added a tasks.get handler.
[+] Added a tasks.list message.
3.5
[+] Added a user.alert message.
3.4
[+] removed the requirement for the schedule start day.
[+] fixed the schedule reloading so that the new schedule takes effect and does not require a reboot.
It has been a while since Tasker was released. Tasker was a quick attempt at making a replacement for the Task Manager application that has been around for more than a decade, starting on the Series 3.
Ample time has now been taken to create a fully capable application that will be every bit as functional as Task Manager but offer the benefits of a rewrite, using configuration files and the latest web technology.
Some of the changes and new features are as follows:
Faster– The tasks are executed much faster and the triggers and schedule are monitored in real-time instead of once every 5 – 10 seconds.
Workspaces - Separate configuration logic into multiple workspaces. Then multiple workspaces can be loaded on the JNIOR at the same time.
Tasks are now separate from triggers. In Task Manager a Task was created and a Trigger was configured to get the Task to execute. In Tasker 3.0 Tasks are a separate entity that can be executed several different way including manual execution from the configuration page and being requested via an ASCII TCP connection.
Tasks can now send data via an Ethernet connection. To do this, a Device must be created so that the action can specify which device to send the data to. Multiple devices can be configured.
New Actions – We implemented actions that were previously available in Task Manager but are introducing many new actions like external module control, TCP communication and control structures.
Drag n Drop – Drag and Drop functionality makes it easier to design your Task logic.
Signals are now created to assign a specific property of a I/O point or sensor a name. The name can then be used in Tasks, Triggers or Loggers.
Loggers can be created to define the file name and schema or what data should be logged to that file. Each line in a Logger will be prepended with a timestamp followed by a comma. Loggers also allow you to define the number of files that should be kept with the given naming pattern. Name patterns can include date patterns. This will help you create a file per day for example.
Schedule – The schedule has additional options.
JSON Configuration files are used now instead of registry keys. Registry keys were limiting in size. The Series 3 could only store 255 characters in a registry key. It is much easier to upload configuration files to other JNIORs to replicate setups.
User Interface – The User Interface is now a native HTML application that uses the latest web technology. The latest web technology uses native HTML controls and Web-sockets to communicate with the JNIOR from your browser. This will allow accessibility over remote connections as long as port 80 is available. This is now consistent with the communication method used by the DCP. Task Manager had always used Java Applets. The Java Applets have not been able to launch in browsers for several years as they became frowned upon as security vulnerabilities.
This was just a short list of changes and new features. The documentation for Tasker should explain these topics as well as many others. If there is anything you don't understand please reach out to us for help. Additionally, if you have any suggestions or need the JNIOR to do something specific for you, please let us know.
We use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it.OK